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]

Message-ID: <CAK8P3a0gCV7CNYzJfMa4FvL_Dck_zYjhaFU7JP9Qu38VBxqrgw@mail.gmail.com>
Date:   Tue, 5 Mar 2019 09:26:33 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Nick Crews <ncrews@...omium.org>
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 Tue, Mar 5, 2019 at 1:53 AM Nick Crews <ncrews@...omium.org> wrote:
>
> 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)?

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