linux-stable/include/linux/bcma/bcma_regs.h

105 lines
5.1 KiB
C
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
/* SPDX-License-Identifier: GPL-2.0 */
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-09 16:56:46 +00:00
#ifndef LINUX_BCMA_REGS_H_
#define LINUX_BCMA_REGS_H_
/* Some single registers are shared between many cores */
/* BCMA_CLKCTLST: ChipCommon (rev >= 20), PCIe, 80211 */
#define BCMA_CLKCTLST 0x01E0 /* Clock control and status */
#define BCMA_CLKCTLST_FORCEALP 0x00000001 /* Force ALP request */
#define BCMA_CLKCTLST_FORCEHT 0x00000002 /* Force HT request */
#define BCMA_CLKCTLST_FORCEILP 0x00000004 /* Force ILP request */
#define BCMA_CLKCTLST_HAVEALPREQ 0x00000008 /* ALP available request */
#define BCMA_CLKCTLST_HAVEHTREQ 0x00000010 /* HT available request */
#define BCMA_CLKCTLST_HWCROFF 0x00000020 /* Force HW clock request off */
#define BCMA_CLKCTLST_HQCLKREQ 0x00000040 /* HQ Clock */
#define BCMA_CLKCTLST_EXTRESREQ 0x00000700 /* Mask of external resource requests */
#define BCMA_CLKCTLST_EXTRESREQ_SHIFT 8
#define BCMA_CLKCTLST_HAVEALP 0x00010000 /* ALP available */
#define BCMA_CLKCTLST_HAVEHT 0x00020000 /* HT available */
#define BCMA_CLKCTLST_BP_ON_ALP 0x00040000 /* RO: running on ALP clock */
#define BCMA_CLKCTLST_BP_ON_HT 0x00080000 /* RO: running on HT clock */
#define BCMA_CLKCTLST_EXTRESST 0x07000000 /* Mask of external resource status */
#define BCMA_CLKCTLST_EXTRESST_SHIFT 24
/* Is there any BCM4328 on BCMA bus? */
#define BCMA_CLKCTLST_4328A0_HAVEHT 0x00010000 /* 4328a0 has reversed bits */
#define BCMA_CLKCTLST_4328A0_HAVEALP 0x00020000 /* 4328a0 has reversed bits */
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-09 16:56:46 +00:00
/* Agent registers (common for every core) */
#define BCMA_OOB_SEL_OUT_A30 0x0100
#define BCMA_IOCTL 0x0408 /* IO control */
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-09 16:56:46 +00:00
#define BCMA_IOCTL_CLK 0x0001
#define BCMA_IOCTL_FGC 0x0002
#define BCMA_IOCTL_CORE_BITS 0x3FFC
#define BCMA_IOCTL_PME_EN 0x4000
#define BCMA_IOCTL_BIST_EN 0x8000
#define BCMA_IOST 0x0500 /* IO status */
#define BCMA_IOST_CORE_BITS 0x0FFF
#define BCMA_IOST_DMA64 0x1000
#define BCMA_IOST_GATED_CLK 0x2000
#define BCMA_IOST_BIST_ERROR 0x4000
#define BCMA_IOST_BIST_DONE 0x8000
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-09 16:56:46 +00:00
#define BCMA_RESET_CTL 0x0800
#define BCMA_RESET_CTL_RESET 0x0001
#define BCMA_RESET_ST 0x0804
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-09 16:56:46 +00:00
#define BCMA_NS_ROM_IOST_BOOT_DEV_MASK 0x0003
#define BCMA_NS_ROM_IOST_BOOT_DEV_NOR 0x0000
#define BCMA_NS_ROM_IOST_BOOT_DEV_NAND 0x0001
#define BCMA_NS_ROM_IOST_BOOT_DEV_ROM 0x0002
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-09 16:56:46 +00:00
/* BCMA PCI config space registers. */
#define BCMA_PCI_PMCSR 0x44
#define BCMA_PCI_PE 0x100
#define BCMA_PCI_BAR0_WIN 0x80 /* Backplane address space 0 */
#define BCMA_PCI_BAR1_WIN 0x84 /* Backplane address space 1 */
#define BCMA_PCI_SPROMCTL 0x88 /* SPROM control */
#define BCMA_PCI_SPROMCTL_WE 0x10 /* SPROM write enable */
#define BCMA_PCI_BAR1_CONTROL 0x8c /* Address space 1 burst control */
#define BCMA_PCI_IRQS 0x90 /* PCI interrupts */
#define BCMA_PCI_IRQMASK 0x94 /* PCI IRQ control and mask (pcirev >= 6 only) */
#define BCMA_PCI_BACKPLANE_IRQS 0x98 /* Backplane Interrupts */
#define BCMA_PCI_BAR0_WIN2 0xAC
#define BCMA_PCI_GPIO_IN 0xB0 /* GPIO Input (pcirev >= 3 only) */
#define BCMA_PCI_GPIO_OUT 0xB4 /* GPIO Output (pcirev >= 3 only) */
#define BCMA_PCI_GPIO_OUT_ENABLE 0xB8 /* GPIO Output Enable/Disable (pcirev >= 3 only) */
#define BCMA_PCI_GPIO_SCS 0x10 /* PCI config space bit 4 for 4306c0 slow clock source */
#define BCMA_PCI_GPIO_HWRAD 0x20 /* PCI config space GPIO 13 for hw radio disable */
#define BCMA_PCI_GPIO_XTAL 0x40 /* PCI config space GPIO 14 for Xtal powerup */
#define BCMA_PCI_GPIO_PLL 0x80 /* PCI config space GPIO 15 for PLL powerdown */
#define BCMA_PCIE2_BAR0_WIN2 0x70
/* SiliconBackplane Address Map.
* All regions may not exist on all chips.
*/
#define BCMA_SOC_SDRAM_BASE 0x00000000U /* Physical SDRAM */
#define BCMA_SOC_PCI_MEM 0x08000000U /* Host Mode sb2pcitranslation0 (64 MB) */
#define BCMA_SOC_PCI_MEM_SZ (64 * 1024 * 1024)
#define BCMA_SOC_PCI_CFG 0x0c000000U /* Host Mode sb2pcitranslation1 (64 MB) */
#define BCMA_SOC_SDRAM_SWAPPED 0x10000000U /* Byteswapped Physical SDRAM */
#define BCMA_SOC_SDRAM_R2 0x80000000U /* Region 2 for sdram (512 MB) */
#define BCMA_SOC_PCI_DMA 0x40000000U /* Client Mode sb2pcitranslation2 (1 GB) */
#define BCMA_SOC_PCI_DMA2 0x80000000U /* Client Mode sb2pcitranslation2 (1 GB) */
#define BCMA_SOC_PCI_DMA_SZ 0x40000000U /* Client Mode sb2pcitranslation2 size in bytes */
#define BCMA_SOC_PCIE_DMA_L32 0x00000000U /* PCIE Client Mode sb2pcitranslation2
* (2 ZettaBytes), low 32 bits
*/
#define BCMA_SOC_PCIE_DMA_H32 0x80000000U /* PCIE Client Mode sb2pcitranslation2
* (2 ZettaBytes), high 32 bits
*/
#define BCMA_SOC_PCI1_MEM 0x40000000U /* Host Mode sb2pcitranslation0 (64 MB) */
#define BCMA_SOC_PCI1_CFG 0x44000000U /* Host Mode sb2pcitranslation1 (64 MB) */
#define BCMA_SOC_PCIE1_DMA_H32 0xc0000000U /* PCIE Client Mode sb2pcitranslation2
* (2 ZettaBytes), high 32 bits
*/
#define BCMA_SOC_FLASH1 0x1fc00000 /* MIPS Flash Region 1 */
#define BCMA_SOC_FLASH1_SZ 0x00400000 /* MIPS Size of Flash Region 1 */
#define BCMA_SOC_FLASH2 0x1c000000 /* Flash Region 2 (region 1 shadowed here) */
#define BCMA_SOC_FLASH2_SZ 0x02000000 /* Size of Flash Region 2 */
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-09 16:56:46 +00:00
#endif /* LINUX_BCMA_REGS_H_ */