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, 6 Dec 2021 23:51:22 +0000
From:   Joel Stanley <joel@....id.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Cc:     Gabriel Somlo <gsomlo@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        Karol Gugala <kgugala@...micro.com>,
        Mateusz Holenko <mholenko@...micro.com>,
        Kamil Rakoczy <krakoczy@...micro.com>,
        mdudek@...ernships.antmicro.com,
        Paul Mackerras <paulus@...abs.org>,
        Stafford Horne <shorne@...il.com>,
        david.abdurachmanov@...ive.com,
        Florent Kermarrec <florent@...oy-digital.fr>
Subject: Re: [PATCH v1 3/3] mmc: Add driver for LiteX's LiteSDCard interface

On Mon, 6 Dec 2021 at 12:16, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> > > +       depends on OF && LITEX
> >
> > I don't like having litex drivers depend on the LITEX kconfig. The
> > symbol is not user visible, and to enable it we need to build in the
> > litex controller driver, which platforms may or may not have.
> >
> > The microwatt platform is an example of a SoC that embeds some LITEX
> > IP, but may or may not be a litex SoC.
>
> I do like the LITEX dependency, as it allows us to gate off a bunch of
> related drivers, and avoid annoying users with questions about them,
> using a single symbol.

I appreciate your concern.

We could do this:

        depends on PPC_MICROWATT || LITEX || COMPILE_TEST

It's unfortunate that kconfig doesn't let us describe the difference
between "this driver requires this symbol" as it won't build and "this
driver is only useful when this symbol is enabled". Traditionally I
write kconfig to represent only the former, whereas you prefer both.

> Originally, people told me the system controller is always present,
> hence the current logic to have LITEX_SOC_CONTROLLER visible, and
> an invisible LITEX (which is shorter to type) for individual drivers
> to depend on.

That's another option. I think LITEX either needs to become visible,
become selected by microwatt, or we adopt the proposal I made above
for the litex drivers that the microwatt soc uses.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ