* [PATCH] platform/chrome: fix wilco-ec dependencies
@ 2019-03-04 20:06 Arnd Bergmann
2019-03-05 0:53 ` Nick Crews
2019-03-05 11:16 ` Enric Balletbo i Serra
0 siblings, 2 replies; 4+ messages in thread
From: Arnd Bergmann @ 2019-03-04 20:06 UTC (permalink / raw)
To: Benson Leung, Enric Balletbo i Serra
Cc: Arnd Bergmann, Duncan Laurie, Nick Crews, Wei Yongjun, linux-kernel
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
--
2.20.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] platform/chrome: fix wilco-ec dependencies
2019-03-04 20:06 [PATCH] platform/chrome: fix wilco-ec dependencies Arnd Bergmann
@ 2019-03-05 0:53 ` Nick Crews
2019-03-05 8:26 ` Arnd Bergmann
2019-03-05 11:16 ` Enric Balletbo i Serra
1 sibling, 1 reply; 4+ messages in thread
From: Nick Crews @ 2019-03-05 0:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Benson Leung, Enric Balletbo i Serra, Duncan Laurie, Wei Yongjun,
linux-kernel
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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] platform/chrome: fix wilco-ec dependencies
2019-03-05 0:53 ` Nick Crews
@ 2019-03-05 8:26 ` Arnd Bergmann
0 siblings, 0 replies; 4+ messages in thread
From: Arnd Bergmann @ 2019-03-05 8:26 UTC (permalink / raw)
To: Nick Crews
Cc: Benson Leung, Enric Balletbo i Serra, Duncan Laurie, Wei Yongjun,
linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] platform/chrome: fix wilco-ec dependencies
2019-03-04 20:06 [PATCH] platform/chrome: fix wilco-ec dependencies Arnd Bergmann
2019-03-05 0:53 ` Nick Crews
@ 2019-03-05 11:16 ` Enric Balletbo i Serra
1 sibling, 0 replies; 4+ messages in thread
From: Enric Balletbo i Serra @ 2019-03-05 11:16 UTC (permalink / raw)
To: Arnd Bergmann, Benson Leung
Cc: Duncan Laurie, Nick Crews, Wei Yongjun, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-03-05 11:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-04 20:06 [PATCH] platform/chrome: fix wilco-ec dependencies Arnd Bergmann
2019-03-05 0:53 ` Nick Crews
2019-03-05 8:26 ` Arnd Bergmann
2019-03-05 11:16 ` Enric Balletbo i Serra
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.