linux-kernel - Re: [RFC PATCH v4 2/5] mfd: add driver for Marvell 88PM886 PMIC

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: <CZZO2EFTAKN2.246XG441ECYYK@matfyz.cz>
Date: Thu, 21 Mar 2024 20:14:44 +0100
From: "Karel Balej" <balejk@...fyz.cz>
To: "Mark Brown" <broonie@...nel.org>
Cc: "Lee Jones" <lee@...nel.org>, "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        "Conor Dooley"
 <conor+dt@...nel.org>,
        "Dmitry Torokhov" <dmitry.torokhov@...il.com>,
        "Liam
 Girdwood" <lgirdwood@...il.com>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-input@...r.kernel.org>,
        Duje Mihanović <duje.mihanovic@...le.hr>,
        <~postmarketos/upstreaming@...ts.sr.ht>, <phone-devel@...r.kernel.org>
Subject: Re: [RFC PATCH v4 2/5] mfd: add driver for Marvell 88PM886 PMIC

Mark Brown, 2024-03-21T19:00:24+00:00:
> On Thu, Mar 21, 2024 at 07:16:43PM +0100, Karel Balej wrote:
> > Mark Brown, 2024-03-21T17:48:28+00:00:
>
> > > > They do according to the downstream driver which is my only reference.
> > > > In fact, there the driver defines the configs separately for each regmap
> > > > but with the same values.
>
> > > This is a downstream driver - are you sure it's got the best code
> > > quality?
>
> > No, that is why I have rewritten it and tried to improve on this. But
> > like I said, it is my only reference. Is there some other way to verify
> > this value (besides perhaps the datasheet)?
>
> The maximum register is whatever the maximum register we know about for
> the device is, the datasheet is generally a good reference there.
>
> > > I'm not seeing any references to registers with numbers as high as the
> > > maximum register that's there in your driver for example.
>
> > Indeed, I have performed the same check with the same findings. But that
> > doesn't necessarily mean that the maximum should be lower, no?
>
> > Do you have some specific modifications of my code in mind regarding
> > this?
>
> I would expect that if you have two separate register maps they would
> have separate configurations that describe the corresponding physical
> register maps, as far as I can tell this driver is just making up a
> maximum register number.

Alright, so I should just use a separate config for each regmap and set
the max_register value for each to whatever I can find is actually the
highest used value in the downstream code -- correct?

Thank you,
K. B.