Commit Graph

12 Commits

Author SHA1 Message Date
Geert Uytterhoeven a733311413 bcma: BCMA_DRIVER_GPIO should depend on GPIOLIB instead of selecting it
Commit cf0936b06d ("bcma: add GPIO driver")
added BCMA_DRIVER_GPIO, which unconditionally selects GPIOLIB, causing
a Kconfig warning:

warning: (ARCH_REQUIRE_GPIOLIB && SSB_DRIVER_GPIO && BCMA_DRIVER_GPIO && MFD_TC6393XB && FB_VIA) selects GPIOLIB which has unmet direct dependencies (ARCH_WANT_OPTIONAL_GPIOLIB || ARCH_REQUIRE_GPIOLIB)

and build failure for m68k/allmodconfig:

In file included from include/linux/bcma/bcma.h:8,
                 from drivers/bcma/bcma_private.h:9,
                 from drivers/bcma/main.c:9:
include/linux/bcma/bcma_driver_chipcommon.h:582: error: field ‘gpio’ has incomplete type
In file included from include/linux/bcma/bcma.h:12,
                 from drivers/bcma/bcma_private.h:9,
                 from drivers/bcma/main.c:9:
include/linux/ssb/ssb.h:440: error: field ‘gpio’ has incomplete type
make[4]: *** [drivers/bcma/main.o] Error 1
make[3]: *** [drivers/bcma/] Error 2

Turn the select into a dependency to fix this.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-02 14:38:22 -05:00
Hauke Mehrtens cf0936b06d bcma: add GPIO driver
Register a GPIO driver to access the GPIOs provided by the chip.
The GPIOs of the SoC should always start at 0 and the other GPIOs could
start at a random position. There is just one SoC in a system and when
they start at 0 the number is predictable.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Patchwork: http://patchwork.linux-mips.org/patch/4587
Acked-by: Florian Fainelli <florian@openwrt.org>
2012-11-21 21:55:52 +01:00
Rafał Miłecki 371a00448f bcma: detect and register NAND flash device
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-08-21 16:05:53 -04:00
Rafał Miłecki d57ef3a6a2 bcma: detect and register serial flash device
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-08-21 16:05:52 -04:00
Rafał Miłecki 23cb3b2121 bcma: add place for flash memory support
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-17 15:11:40 -04:00
Rafał Miłecki e1ac4b4090 bcma: add trivial GBIT MAC COMMON driver
GMAC COMMON core is present on BCM4706 and is used for example to access
board PHYs (PHYs can not be accessed directly using GBIT MAC core).

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-07-12 15:27:18 -04:00
Paul Gortmaker 58f743ee06 bcma: fix build error on MIPS; implicit pcibios_enable_device
The following is seen during allmodconfig builds for MIPS:

drivers/bcma/driver_pci_host.c:518:2: error: implicit declaration
of function 'pcibios_enable_device' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/bcma/driver_pci_host.o] Error 1

Most likey introduced by commit 49dc957715

    "bcma: add PCIe host controller"

Add the header instead of implicitly assuming it will be present.
Sounds like a good idea, but that alone doesn't fix anything.

The real problem is that the Kconfig has settings related to whether
PCI is possible, i.e.

  config BCMA_HOST_PCI_POSSIBLE
        bool
        depends on BCMA && PCI = y
        default y

  config BCMA_HOST_PCI
        bool "Support for BCMA on PCI-host bus"
        depends on BCMA_HOST_PCI_POSSIBLE

...but what is missing is that BCMA_DRIVER_PCI_HOSTMODE doesn't
have any dependencies on the above.  Add one.

CC: Hauke Mehrtens <hauke@hauke-m.de>
CC: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-10 14:13:30 -04:00
Hauke Mehrtens 21e0534ad7 bcma: add mips driver
This adds a mips driver to bcma. This is only found on embedded
devices. For now the driver just initializes the irqs used on this
system.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-08-08 14:29:26 -04:00
Hauke Mehrtens ecd177c216 bcma: add SOC bus
This patch adds support for using bcma on a Broadcom SoC as the system
bus. An SoC like the bcm4716 could register this bus and use it to
searches for the bcma cores and register the devices on this bus.

BCMA_HOSTTYPE_NONE was intended for SoCs at first but BCMA_HOSTTYPE_SOC
is a better name.

Acked-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-08-08 14:29:25 -04:00
Rafał Miłecki 9352f69c91 bcma: detect PCI core working in hostmode
We must not init it like clientmode one, it would break device (tested
by Hauke on BCM4718). Add stub hostmode driver for now.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-07-07 13:13:34 -04:00
Rafał Miłecki 9d75ef0f8f bcma: host pci: implement block R/W operations
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-06-01 15:12:28 -04:00
Rafał Miłecki 8369ae33b7 bcma: add Broadcom specific AMBA bus driver
Broadcom has released cards based on a new AMBA-based bus type. From a
programming point of view, this new bus type differs from AMBA and does
not use AMBA common registers. It also differs enough from SSB. We
decided that a new bus driver is needed to keep the code clean.

In its current form, the driver detects devices present on the bus and
registers them in the system. It allows registering BCMA drivers for
specified bus devices and provides them basic operations. The bus driver
itself includes two important bus managing drivers: ChipCommon core
driver and PCI(c) core driver. They are early used to allow correct
initialization.

Currently code is limited to supporting buses on PCI(e) devices, however
the driver is designed to be used also on other hosts. The host
abstraction layer is implemented and already used for PCI(e).

Support for PCI(e) hosts is working and seems to be stable (access to
80211 core was tested successfully on a few devices). We can still
optimize it by using some fixed windows, but this can be done later
without affecting any external code. Windows are just ranges in MMIO
used for accessing cores on the bus.

Cc: Greg KH <greg@kroah.com>
Cc: Michael Büsch <mb@bu3sch.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: George Kashperko <george@znau.edu.ua>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Botting <andy@andybotting.com>
Cc: linuxdriverproject <devel@linuxdriverproject.org>
Cc: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-05-10 15:54:54 -04:00