Received-SPF: pass (google.com: domain of linux-kernel+bounces-110581-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 21 Mar 2024 20:14:44 +0100
Message-Id: <CZZO2EFTAKN2.246XG441ECYYK@matfyz.cz>
To: "Mark Brown" <broonie@kernel.org>
From: "Karel Balej" <balejk@matfyz.cz>
Cc: "Lee Jones" <lee@kernel.org>, "Rob Herring" <robh+dt@kernel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
        "Conor Dooley"
 <conor+dt@kernel.org>,
        "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
        "Liam
 Girdwood" <lgirdwood@gmail.com>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-input@vger.kernel.org>,
        =?utf-8?q?Duje_Mihanovi=C4=87?= <duje.mihanovic@skole.hr>,
        <~postmarketos/upstreaming@lists.sr.ht>, <phone-devel@vger.kernel.org>
Subject: Re: [RFC PATCH v4 2/5] mfd: add driver for Marvell 88PM886 PMIC
References: <20240321154211.GA13211@google.com>
 <CZZK759UU6G7.MFPYOI0HBB6I@matfyz.cz> <20240321162045.GC13211@google.com>
 <CZZL3MNOT0QG.2WDSNX9XD2RET@matfyz.cz>
 <879296b4-5186-4170-af3f-971787d28514@sirena.org.uk>
 <CZZLDK79D5VK.2VK3X59OHIY2Z@matfyz.cz>
 <45079e37-dde9-4310-a112-7af49f35ac77@sirena.org.uk>
 <CZZLVS3T3QIS.223XHI5OZ7UBG@matfyz.cz>
 <e9c7bd38-49cd-44c2-8842-292bc0b4205f@sirena.org.uk>
 <CZZMTZBZ5S7B.2HR8A6LEY08D4@matfyz.cz>
 <bd4e96b9-1026-469b-9884-073cde1f39dc@sirena.org.uk>
In-Reply-To: <bd4e96b9-1026-469b-9884-073cde1f39dc@sirena.org.uk>

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 referen=
ce.
> > > > In fact, there the driver defines the configs separately for each r=
egmap
> > > > 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 th=
e
> > > maximum register that's there in your driver for example.
>
> > Indeed, I have performed the same check with the same findings. But tha=
t
> > 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.