linux-kernel - Re: [PATCH] platform/chrome: fix wilco-ec dependencies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Mar 2019 17:53:42 -0700
From:   Nick Crews <ncrews@...omium.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Benson Leung <bleung@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Duncan Laurie <dlaurie@...gle.com>,
        Wei Yongjun <weiyongjun1@...wei.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] platform/chrome: fix wilco-ec dependencies

On Mon, Mar 4, 2019 at 1:06 PM Arnd Bergmann <arnd@...db.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@...db.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
>