linux-kernel - RE: [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF

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: <TY2PR01MB3692AE318BCCA6F987AB5CD3D8CB0@TY2PR01MB3692.jpnprd01.prod.outlook.com>
Date:   Thu, 10 Dec 2020 08:28:13 +0000
From:   Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
CC:     "marek.vasut+renesas@...il.com" <marek.vasut+renesas@...il.com>,
        Khiem Nguyen <khiem.nguyen.xt@...esas.com>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF

Hi Geert-san, Matti,

Thank you for your comments!

> From: Geert Uytterhoeven, Sent: Thursday, December 10, 2020 5:20 PM
> 
> Hi Matti, Shimoda-san,
> 
> On Thu, Dec 10, 2020 at 8:33 AM Vaittinen, Matti
> <Matti.Vaittinen@...rohmeurope.com> wrote:
> > On Thu, 2020-12-10 at 04:44 +0000, Yoshihiro Shimoda wrote:
> > > > From: Geert Uytterhoeven, Sent: Wednesday, December 9, 2020 10:30
> > > > PM
> > > <snip>
> > > > > --- a/drivers/mfd/bd9571mwv.c
> > > > > +++ b/drivers/mfd/bd9571mwv.c
> > > > >
> > > > > @@ -182,6 +272,8 @@ static int bd9571mwv_probe(struct i2c_client
> > > > > *client,
> > > > >         product_code = (unsigned int)ret;
> > > > >         if (product_code == BD9571MWV_PRODUCT_CODE_VAL)
> > > > >                 bd->data = &bd9571mwv_data;
> > > > > +       else if (product_code == BD9574MWF_PRODUCT_CODE_VAL)
> > > > > +               bd->data = &bd9574mwf_data;
> > > > >
> > > > >         if (!bd->data) {
> > > > >                 dev_err(bd->dev, "No found supported device
> > > > > %d\n",
> > > >
> > > > While BD9571MWV and BD9574MWF can be distinguished at runtime,
> > > > I think it would still be a good idea to document a
> > > > "rohm,bd9574mwf"
> > > > compatible value in the DT bindings, and let the driver match on
> > > > that.
> > >
> > > In this driver point of view, we can use such the DT bindings,
> > > however, in the board point of view, it's difficult to describe
> > > which chip is installed on r8a77990-ebisu.dts. So, I'd like to
> > > keep this runtime detection.
> 
> To clarify: I meant to document and add the compatible value, but
> treat both compatible values the same in the driver, and still do runtime
> probing.

Thank you! I understood it.

<snip>
> > ROHM wouldn't do this but still... :] ). And producing boards where DTS
> > does not allow describing the correct components sounds like asking for
> > a nose-bleed to me... If probing of IC type fails AND there is devices
> > with wrong PMIC information burned in DT - then fixing it can be a
> > nightmare. So I would really try make DTS files such that they can be
> 
> The issue we're facing is that older Ebisu-4D boards have BD9571, while
> newer boards have BD9574.  The schematics say "BD9574MWF-M (tentative
> ver:BD9571TL1_E3)", so it looks like both parts are pin-compatible
> (ignoring missing pins for AVS, LDO1, LDO2, and LDO6 on BD9574).
> Hence arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts has a device node
> compatible with "rohm,bd9571mwv".  If we have runtime probing, we can
> keep on using that for both variants.

Thank you very much for explaining this! It's very clear :)

Best regards,
Yoshihiro Shimoda