linux-kernel - Re: [RFC PATCH 06/13] mfd: bd71828: Support ROHM BD72720

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] [day] [month] [year] [list]

Message-ID: <20251013151900.3e4cc69f@kemnade.info>
Date: Mon, 13 Oct 2025 15:19:00 +0200
From: Andreas Kemnade <andreas@...nade.info>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Lee Jones <lee@...nel.org>, Matti Vaittinen
 <matti.vaittinen@...rohmeurope.com>, Pavel Machek <pavel@...nel.org>, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Sebastian Reichel <sre@...nel.org>, Liam
 Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Linus
 Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>,
 linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
 linux-gpio@...r.kernel.org
Subject: Re: [RFC PATCH 06/13] mfd: bd71828: Support ROHM BD72720

On Mon, 13 Oct 2025 12:27:33 +0300
Matti Vaittinen <mazziesaccount@...il.com> wrote:

> Hi Andreas!
> 
> First of all, thanks for taking a look at this!
> 
> On 10/10/2025 16:03, Andreas Kemnade wrote:
> > On Fri, 10 Oct 2025 15:09:07 +0300
> > Matti Vaittinen <mazziesaccount@...il.com> wrote:
> >   
> >>>> +static int bd72720_get_secondary_regmap(struct i2c_client *i2c,  
> >>>
> >>> Does this 'secondary' have a specific purpose or a better name?  
> >>
> >> I am not entirely sure. When I asked this from the designers they just
> >> told me that they needed more than 255 registers so they added another
> >> slave address... (I'm not sure what would have been wrong with using a
> >> page register). So, I assume they just placed stuff that didn't fit in
> >> first 255 register there. But yeah, it looks like most of the registers
> >> there are related to the charger. So, perhaps it isn't completely
> >> misleading to use "charger regmap"? The data-sheet seems to be just
> >> using "Register map 1" and "Register map 2" in the tables listing these
> >> registers. I kind of like using something which maps easily to the
> >> data-sheet, but I really have no strong opinion on this.  
> > 
> > just another idea: What about one regmap with custom functions covering
> > both these adresses? Maybe that could even be added to the regmap
> > functionality, maybe with a 0x100 offset for the second range.
> > That way the rest of the code only needs to real with one regmap
> > and properly defined registers.  
> 
> Interesting idea.
> 
> I suppose you mean something like implementing custom remap_read() and 
> regmap_write() - which would practically select the I2C adapter to use 
> based on the register address - and then doing same thing as the 
> regmap_i2c_smbus_i2c_write() / regmap_i2c_smbus_i2c_read() do?
> 
> I suppose this would mean duplicating the functionality provided by the 
> regmap_i2c_smbus_i2c_write() and the regmap_i2c_smbus_i2c_read(), which 
> are static. It'd also mean we'll lose the 1 to 1 mapping between the 
> register addresses in driver and addresses in the data-sheet. I agree 
> this wouldn't be such a huge thing if we used offset like 0x100 though.
> 
Well, you could also stack regmaps like ntxec.c is doing (but there
for some very weird reason). That would avoid duplicating code.

I have no strong opinion here.

Regards,
Andreas