| Message ID | 20190304200719.1382717-1-arnd@arndb.de |
|---|---|
| State | Accepted |
| Commit | 2794449576a6024e203eca5cc2c1a3ae33102b8e |
| Headers | show |
| Series | platform/chrome: fix wilco-ec dependencies | expand |
On Mon, Mar 4, 2019 at 1:06 PM Arnd Bergmann <arnd@arndb.de> wrote: > > When CROS_EC_LPC is set to =m, we get a link failure for a > builtin wilco-ec module: > > drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_remove': > core.c:(.text+0x26): undefined reference to `cros_ec_lpc_mec_destroy' > drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_probe': > core.c:(.text+0x18c): undefined reference to `cros_ec_lpc_mec_init' > core.c:(.text+0x224): undefined reference to `cros_ec_lpc_mec_destroy' > drivers/platform/chrome/wilco_ec/mailbox.o: In function `wilco_ec_mailbox': > mailbox.c:(.text+0x104): undefined reference to `cros_ec_lpc_io_bytes_mec' > > The problem with the existing CROS_EC_LPC_MEC dependency is that this > is only for a 'bool' symbol, so the information about the exported > functions being in a module is lost on the way, and we actually have > to depend on both CROS_EC_LPC and CROS_EC_LPC_MEC. Thanks for the catch Arnd. This looks like a workable solution, although it brings up a different question to me: Is it weird for a bool option (such as CROS_EC_LPC_MEC) to depend upon a tristate option (such as CROS_EC_LPC)? It seems like CROS_EC_LPC_MEC should be tristate as well. Would changing this be a better solution? > > Fixes: 7b3d4f44abf0 ("platform/chrome: Add new driver for Wilco EC") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/platform/chrome/wilco_ec/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/chrome/wilco_ec/Kconfig b/drivers/platform/chrome/wilco_ec/Kconfig > index 4a119ced4d0c..e09e4cebe9b4 100644 > --- a/drivers/platform/chrome/wilco_ec/Kconfig > +++ b/drivers/platform/chrome/wilco_ec/Kconfig > @@ -1,6 +1,6 @@ > config WILCO_EC > tristate "ChromeOS Wilco Embedded Controller" > - depends on ACPI && X86 && CROS_EC_LPC_MEC > + depends on ACPI && X86 && CROS_EC_LPC && CROS_EC_LPC_MEC > help > If you say Y here, you get support for talking to the ChromeOS > Wilco EC over an eSPI bus. This uses a simple byte-level protocol > -- > 2.20.0 >
On Tue, Mar 5, 2019 at 1:53 AM Nick Crews <ncrews@chromium.org> wrote: > > On Mon, Mar 4, 2019 at 1:06 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > When CROS_EC_LPC is set to =m, we get a link failure for a > > builtin wilco-ec module: > > > > drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_remove': > > core.c:(.text+0x26): undefined reference to `cros_ec_lpc_mec_destroy' > > drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_probe': > > core.c:(.text+0x18c): undefined reference to `cros_ec_lpc_mec_init' > > core.c:(.text+0x224): undefined reference to `cros_ec_lpc_mec_destroy' > > drivers/platform/chrome/wilco_ec/mailbox.o: In function `wilco_ec_mailbox': > > mailbox.c:(.text+0x104): undefined reference to `cros_ec_lpc_io_bytes_mec' > > > > The problem with the existing CROS_EC_LPC_MEC dependency is that this > > is only for a 'bool' symbol, so the information about the exported > > functions being in a module is lost on the way, and we actually have > > to depend on both CROS_EC_LPC and CROS_EC_LPC_MEC. > > Thanks for the catch Arnd. This looks like a workable solution, although it > brings up a different question to me: Is it weird for a bool option > (such as CROS_EC_LPC_MEC) > to depend upon a tristate option (such as CROS_EC_LPC)? No, not weird at all. > It seems like > CROS_EC_LPC_MEC > should be tristate as well. Would changing this be a better solution? No, that would actually break the code in a different way, since you have: drivers/platform/chrome/Makefile:cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o drivers/platform/chrome/cros_ec_lpc_reg.c:#ifdef CONFIG_CROS_EC_LPC_MEC drivers/platform/chrome/cros_ec_lpc_reg.c:#else /* CONFIG_CROS_EC_LPC_MEC */ drivers/platform/chrome/cros_ec_lpc_reg.c:#endif /* CONFIG_CROS_EC_LPC_MEC */ With CONFIG_CROS_EC_LPC_MEC=m, it would not get used (CONFIG_CROS_EC_LPC_MEC ends up not defined in C code), and it makes no sense to include a .o file in a loadable module based on a tristate option. Arnd
Hi, On 4/3/19 21:06, Arnd Bergmann wrote: > When CROS_EC_LPC is set to =m, we get a link failure for a > builtin wilco-ec module: > > drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_remove': > core.c:(.text+0x26): undefined reference to `cros_ec_lpc_mec_destroy' > drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_probe': > core.c:(.text+0x18c): undefined reference to `cros_ec_lpc_mec_init' > core.c:(.text+0x224): undefined reference to `cros_ec_lpc_mec_destroy' > drivers/platform/chrome/wilco_ec/mailbox.o: In function `wilco_ec_mailbox': > mailbox.c:(.text+0x104): undefined reference to `cros_ec_lpc_io_bytes_mec' > > The problem with the existing CROS_EC_LPC_MEC dependency is that this > is only for a 'bool' symbol, so the information about the exported > functions being in a module is lost on the way, and we actually have > to depend on both CROS_EC_LPC and CROS_EC_LPC_MEC. > > Fixes: 7b3d4f44abf0 ("platform/chrome: Add new driver for Wilco EC") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/platform/chrome/wilco_ec/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/chrome/wilco_ec/Kconfig b/drivers/platform/chrome/wilco_ec/Kconfig > index 4a119ced4d0c..e09e4cebe9b4 100644 > --- a/drivers/platform/chrome/wilco_ec/Kconfig > +++ b/drivers/platform/chrome/wilco_ec/Kconfig > @@ -1,6 +1,6 @@ > config WILCO_EC > tristate "ChromeOS Wilco Embedded Controller" > - depends on ACPI && X86 && CROS_EC_LPC_MEC > + depends on ACPI && X86 && CROS_EC_LPC && CROS_EC_LPC_MEC > help > If you say Y here, you get support for talking to the ChromeOS > Wilco EC over an eSPI bus. This uses a simple byte-level protocol > Applied as a fix to our chrome-platform-5.1 branch. Thanks, Enric
diff --git a/drivers/platform/chrome/wilco_ec/Kconfig b/drivers/platform/chrome/wilco_ec/Kconfig index 4a119ced4d0c..e09e4cebe9b4 100644 --- a/drivers/platform/chrome/wilco_ec/Kconfig +++ b/drivers/platform/chrome/wilco_ec/Kconfig @@ -1,6 +1,6 @@ config WILCO_EC tristate "ChromeOS Wilco Embedded Controller" - depends on ACPI && X86 && CROS_EC_LPC_MEC + depends on ACPI && X86 && CROS_EC_LPC && CROS_EC_LPC_MEC help If you say Y here, you get support for talking to the ChromeOS Wilco EC over an eSPI bus. This uses a simple byte-level protocol
When CROS_EC_LPC is set to =m, we get a link failure for a builtin wilco-ec module: drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_remove': core.c:(.text+0x26): undefined reference to `cros_ec_lpc_mec_destroy' drivers/platform/chrome/wilco_ec/core.o: In function `wilco_ec_probe': core.c:(.text+0x18c): undefined reference to `cros_ec_lpc_mec_init' core.c:(.text+0x224): undefined reference to `cros_ec_lpc_mec_destroy' drivers/platform/chrome/wilco_ec/mailbox.o: In function `wilco_ec_mailbox': mailbox.c:(.text+0x104): undefined reference to `cros_ec_lpc_io_bytes_mec' The problem with the existing CROS_EC_LPC_MEC dependency is that this is only for a 'bool' symbol, so the information about the exported functions being in a module is lost on the way, and we actually have to depend on both CROS_EC_LPC and CROS_EC_LPC_MEC. Fixes: 7b3d4f44abf0 ("platform/chrome: Add new driver for Wilco EC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/platform/chrome/wilco_ec/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.20.0