This patch unregisters the gpio chip before bcma gets unloaded.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Reported-by: NPiotr Haber <phaber@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, and __devexit
from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: "Rafał Miłecki" <zajec5@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit cf0936b0 ("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: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were using wrong IRQ number so clearing wasn't working at all.
Depending on a platform this could result in a one device having two
interrupts assigned. On BCM4706 this resulted in all IRQs being broken.

Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: stable@vger.kernel.org
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Register the watchdog driver to the system if this is a SoC. Using the
watchdog on a non SoC device, like a PCIe card, will make the PCIe
card die when the timeout expired, but starting it again is not
supported by bcma.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The watchdog driver wants to set the watchdog timeout in ms and not in
ticks, which is depending on the SoC type and the clock.
Calculate the number of ticks per millisecond and provide two functions
for the watchdog driver. Also return the ticks or millisecond the timer
was set to in case the provided value was bigger than the max allowed
value.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mostly all bcma based devices have a PMU and the PMU watchdog should be
used and not the old one in chip common. This patch also calculates the
maximal number the watchdog could be set to.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For devices without a PMU the alp clock is always 20000000.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes the following warning:

  CC      drivers/bcma/driver_pci_host.o
drivers/bcma/driver_pci_host.c: In function 'bcma_core_pci_fixup_addresses':
drivers/bcma/driver_pci_host.c:555:23: error: ignoring return value of
'pci_assign_resource', declared with attribute warn_unused_result
[-Werror=unused-result]
Reported-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is required by NAND flash driver for initializing wait counters.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

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: NHauke Mehrtens <hauke@hauke-m.de>
Patchwork: http://patchwork.linux-mips.org/patch/4587Acked-by: NFlorian Fainelli <florian@openwrt.org>

Add description to the function.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Patchwork: http://patchwork.linux-mips.org/patch/4588Acked-by: NFlorian Fainelli <florian@openwrt.org>

Add functions to access the GPIO registers for pullup and pulldown.
These are needed for handling gpio registration.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Patchwork: http://patchwork.linux-mips.org/patch/4586Acked-by: NFlorian Fainelli <florian@openwrt.org>

The GPIOs are access through some registers in the chip common core.
We need locking around these GPIO accesses, all GPIOs are accessed
through the same registers and parallel writes will cause problems.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Patchwork: http://patchwork.linux-mips.org/patch/4585Acked-by: NFlorian Fainelli <florian@openwrt.org>

This will fix warnings like following when CONFIG_PM_SLEEP is not set:

        warning: 'xxx_suspend' defined but not used [-Wunused-function]
        warning: 'xxx_resume' defined but not used [-Wunused-function]

Because
	SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)

Only references the callbacks on CONFIG_PM_SLEEP (instead of CONFIG_PM).

Cc: John W. Linville <linville@tuxdriver.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Before it was tried to initialize the deactivated PCIe core in client
mode, but this causes the SoC to hang. Just do not initialize it at all
and ignore the core it is not working and nothing is connected to it
when the specific bit is set in the boardflags.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The BCM4706 has two PCIe host controller on the bcma bus. For PCIe
client mode it is assumed that there is only one PCIe controller so the
PCIe driver, like b43 and brcmsmac are accessing the first PCIe
controller when they want to issue a operation on the host controller.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Sometimes the PCIe card indicates that it has a sprom somewhere and we
are able to read the memory region, but it is empty and not valid. In
these cases we should try to use the fallback sprom as a last chance.

This is the case for the PCIe cards in my ASUS RT-N66U (BCM4706 + 2
times BCM4331) and I have heard of someone having the same problem with
an other PCIe card connected to an other Broadcom SoC.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes the code more readable
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are some devices which are able to boot from nand flash and other
are using a serial flash for booting. Add a bool to indicate that the
device is booted from that flash chip and not from some other chip also
connected to the SoC. This is needed to find the nvram, as it is stored
on the flash the devices booted from.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The PCIe host driver and the chip common initialisation accesses the
sprom struct, but it is not initialized when these functions are run.
Move the sprom parsing up in to do it earlier.
As we need the chip common core rev and some other attributes from the
chip common core, the early initialization is done before accessing the
sprom.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some parts of the initialization for chip common and the pcie core are
accessing the sprom struct, but it is not initialized at that stage.
Just do the necessary thing in the early register on SoCs and not the
complete initialization to read out the nvram from the flash chip.
After it is possible to read out the nvram, the sprom should be parsed
from it and the full initialization of the cores should be run.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When cores are unregistered, entries
need to be removed from cores list in a safe manner.
Reported-by: NStanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Signed-off-by: NPiotr Haber <phaber@broadcom.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Tested-by: NJack <x6719620@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

bcma_scan_bus allocates a bcma_core for each core found on the bus, but the
memory for cores handled by the bcma driver itself was not being freed when
the bus was unregistered. This patch adds special handling for the PCIE,
MIPS, and GBIT COMMON cores, to ensure that their memory allocation is
freed as well.

Note that this patch doesn't address the memory allocated for the CC core,
as that was corrected in my previous patch "bcma: register cc core driver,
device."

Cc: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: NSaul St. John <saul.stjohn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The functions and structs are not used in an other file and the
prototypes are in no header file, just make them static so the compiler
is able to optimize them better.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit b9562545 ("bcma: complete workaround for BCMA43224 and
BCM4313") introduced the wrong masks for setting the chip control
registers - the "mask" parameter is inverse.

It should be the mask of bits *not* changed, which is admittedly a bit
non-intuitive.

The incorrect mask not only causes the driver to not work correctly on
the chips affected (eg the BCM43224 on the Macbook Air 4,2) but the
state persists over a soft reset, causing the next boot to not
necessarily see the device correctly.
Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Tested-by: NSeth Forshee <seth.forshee@canonical.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Arend Van Spriel <arend@broadcom.com>
Cc: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Cc: Brett Rudley <brudley@broadcom.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This should fix the problem reported by Fengguang:

The coccinelle static checker emits these warnings:

drivers/bcma/scan.c:466:3-9: ERROR: missing iounmap; ioremap on line 451 and execution via conditional on line 465
drivers/bcma/scan.c:540:3-9: ERROR: missing iounmap; ioremap on line 515 and execution via conditional on line 539
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The wrong interrupts where assigned to the cores in
bcma_core_mips_init(). This caused at least my serial console not to
response to any input.

This was caused by this patch which changed the order of the cores in
the list:
commit c334e25c
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Wed Jul 11 12:37:00 2012 +0200

    bcma: add new cores at the end of list

This should be fixed properly later so that the correct interrupt
numbers are assigned to the cores independently from the ordering of
the list. This patch restores the old behavior again. I will look into
the problem more deeply later.

I also changed the order of the list with the cores and their assigned
interrupt number which gets printed to the log. Now they are printed in
the same order like all the other lists of cores and like it was done
before the patch which changed the order.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>