linux-kernel - Re: [PATCH v6 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support

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: <20230329150605.GW2673958@google.com>
Date:   Wed, 29 Mar 2023 16:06:05 +0100
From:   Lee Jones <lee@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     "Sahin, Okan" <Okan.Sahin@...log.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Cosmin Tanislav <demonsingur@...il.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Caleb Connolly <caleb.connolly@...aro.org>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        "Bolboaca, Ramona" <Ramona.Bolboaca@...log.com>,
        ChiYuan Huang <cy_huang@...htek.com>,
        "Tilki, Ibrahim" <Ibrahim.Tilki@...log.com>,
        William Breathitt Gray <william.gray@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        ChiaEn Wu <chiaen_wu@...htek.com>,
        Haibo Chen <haibo.chen@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v6 5/5]  mfd: max77541: Add ADI MAX77541/MAX77540 PMIC
 Support

On Wed, 29 Mar 2023, Lee Jones wrote:

> On Wed, 29 Mar 2023, Andy Shevchenko wrote:
>
> > On Wed, Mar 29, 2023 at 03:36:15PM +0100, Lee Jones wrote:
> > > On Tue, 28 Mar 2023, Sahin, Okan wrote:
> > > > >On Wed, 15 Mar 2023, Lee Jones wrote:
> > > > >> On Tue, 07 Mar 2023, Okan Sahin wrote:
> >
> > ...
> >
> > > > +static const struct i2c_device_id max77541_i2c_id[] = {
> > > > +	{ "max77540", (kernel_ulong_t)&chip[MAX77540] },
> > > > +	{ "max77541", (kernel_ulong_t)&chip[MAX77541] },
> > >
> > > Just 'MAX77540' is fine.
> >
> > I tend to disagree.
> >
> > There is an error prone approach esp. when we talk with some functions
> > that unifies OF/ACPI driver data retrieval with legacy ID tables.
> > In such a case the 0 from enum is hard to distinguish from NULL when
> > the driver data is not set or not found. On top of that the simple integer
> > in the legacy driver data will require additional code to be added in
> > the ->probe().
>
> Use a !0 enum?
>
> The extra handling is expected and normal.

I've always disliked mixing platform initialisation strategies.  Passing
pointers to MFD structs through I2C/Device Tree registration opens the
doors to all sorts of funky interlaced nonsense.

Pass the device ID and then match in C-code please.

--
Lee Jones [李琼斯]