Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1357277 > unrolled thread
| Started by | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| First post | 2016-03-14 15:30 +0100 |
| Last post | 2016-03-14 17:00 +0100 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] Firmware: broadcom sprom: clarifiy SSB dependency Arnd Bergmann <arnd@arndb.de> - 2016-03-14 15:30 +0100
Re: [PATCH] Firmware: broadcom sprom: clarifiy SSB dependency Rafał Miłecki <zajec5@gmail.com> - 2016-03-14 15:40 +0100
Re: [PATCH] Firmware: broadcom sprom: clarifiy SSB dependency Arnd Bergmann <arnd@arndb.de> - 2016-03-14 16:40 +0100
Re: [PATCH] Firmware: broadcom sprom: clarifiy SSB dependency Rafał Miłecki <zajec5@gmail.com> - 2016-03-14 17:00 +0100
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-03-14 15:30 +0100 |
| Subject | [PATCH] Firmware: broadcom sprom: clarifiy SSB dependency |
| Message-ID | <rcBFn-4SW-17@gated-at.bofh.it> |
The broadcom firmware drvier calls into the ssb SPROM code if that is enabled, but it fails if the SSB code is in a loadable module because the bcm47xx firmware is always built-in: drivers/firmware/built-in.o: In function `bcm47xx_sprom_register_fallbacks': bcm47xx_sprom.c:(.text+0x11c4): undefined reference to `ssb_arch_register_fallback_sprom' This adds a Kconfig dependency to ensure that we cannot turn on the generic sprom support if the ssb sprom is in a module. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/firmware/broadcom/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/firmware/broadcom/Kconfig b/drivers/firmware/broadcom/Kconfig index 3c7e5b741e37..42f7d9bfb148 100644 --- a/drivers/firmware/broadcom/Kconfig +++ b/drivers/firmware/broadcom/Kconfig @@ -13,6 +13,7 @@ config BCM47XX_NVRAM config BCM47XX_SPROM bool "Broadcom SPROM driver" depends on BCM47XX_NVRAM + depends on SSB=y || SSB=n help Broadcom devices store configuration data in SPROM. Accessing it is specific to the bus host type, e.g. PCI(e) devices have it mapped in -- 2.7.0
[toc] | [next] | [standalone]
| From | Rafał Miłecki <zajec5@gmail.com> |
|---|---|
| Date | 2016-03-14 15:40 +0100 |
| Message-ID | <rcBP4-4Xz-29@gated-at.bofh.it> |
| In reply to | #1357277 |
On 14 March 2016 at 15:21, Arnd Bergmann <arnd@arndb.de> wrote: > The broadcom firmware drvier calls into the ssb SPROM code if that > is enabled, but it fails if the SSB code is in a loadable module > because the bcm47xx firmware is always built-in: > > drivers/firmware/built-in.o: In function `bcm47xx_sprom_register_fallbacks': > bcm47xx_sprom.c:(.text+0x11c4): undefined reference to `ssb_arch_register_fallback_sprom' > > This adds a Kconfig dependency to ensure that we cannot turn on the > generic sprom support if the ssb sprom is in a module. Can you attach your config that triggered this build error? I modified condition to the: #if IS_BUILTIN(CONFIG_SSB) && IS_ENABLED(CONFIG_SSB_SPROM) which I believe should be enough. I'm afraid your patch won't allow compiling SPROM driver with BCMA=y and SSB as a module.
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-03-14 16:40 +0100 |
| Message-ID | <rcCL8-5Fw-9@gated-at.bofh.it> |
| In reply to | #1357300 |
On Monday 14 March 2016 15:37:18 Rafał Miłecki wrote: > On 14 March 2016 at 15:21, Arnd Bergmann <arnd@arndb.de> wrote: > > The broadcom firmware drvier calls into the ssb SPROM code if that > > is enabled, but it fails if the SSB code is in a loadable module > > because the bcm47xx firmware is always built-in: > > > > drivers/firmware/built-in.o: In function `bcm47xx_sprom_register_fallbacks': > > bcm47xx_sprom.c:(.text+0x11c4): undefined reference to `ssb_arch_register_fallback_sprom' > > > > This adds a Kconfig dependency to ensure that we cannot turn on the > > generic sprom support if the ssb sprom is in a module. > > Can you attach your config that triggered this build error? I modified > condition to the: > #if IS_BUILTIN(CONFIG_SSB) && IS_ENABLED(CONFIG_SSB_SPROM) > which I believe should be enough. From inspection, I think your solution is sufficient to avoid the error. I found the bug while travelling and I'm only now catching up on the submissions, so I must have missed the fact that it was fixed. I looked at the code to see if additional patches had been applied on top, but I did not realize that you had modified the driver in place. > I'm afraid your patch won't allow compiling SPROM driver with BCMA=y > and SSB as a module. Correct. The downside of your approach is that it silently stops the machine from accessing the SSB SPROM when the driver is a module, while still allowing the generic SPROM code to be built, which may be harder to figure out for a user than a missing driver. I don't see a good solution that works either way, so the your latest code looks good enough. Thanks for the quick reply! Arnd
[toc] | [prev] | [next] | [standalone]
| From | Rafał Miłecki <zajec5@gmail.com> |
|---|---|
| Date | 2016-03-14 17:00 +0100 |
| Message-ID | <rcD4v-5Mh-19@gated-at.bofh.it> |
| In reply to | #1357365 |
On 14 March 2016 at 16:34, Arnd Bergmann <arnd@arndb.de> wrote: > On Monday 14 March 2016 15:37:18 Rafał Miłecki wrote: >> On 14 March 2016 at 15:21, Arnd Bergmann <arnd@arndb.de> wrote: >> > The broadcom firmware drvier calls into the ssb SPROM code if that >> > is enabled, but it fails if the SSB code is in a loadable module >> > because the bcm47xx firmware is always built-in: >> > >> > drivers/firmware/built-in.o: In function `bcm47xx_sprom_register_fallbacks': >> > bcm47xx_sprom.c:(.text+0x11c4): undefined reference to `ssb_arch_register_fallback_sprom' >> > >> > This adds a Kconfig dependency to ensure that we cannot turn on the >> > generic sprom support if the ssb sprom is in a module. >> >> Can you attach your config that triggered this build error? I modified >> condition to the: >> #if IS_BUILTIN(CONFIG_SSB) && IS_ENABLED(CONFIG_SSB_SPROM) >> which I believe should be enough. > > From inspection, I think your solution is sufficient to avoid the error. > I found the bug while travelling and I'm only now catching up on the submissions, > so I must have missed the fact that it was fixed. I looked at the code > to see if additional patches had been applied on top, but I did not > realize that you had modified the driver in place. I sent a separated patch for this: https://patchwork.linux-mips.org/patch/12836/ and it was folded/squashed by Ralf. -- Rafał
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web