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

[Andreas Kemnade]

On Mon, 13 Oct 2025 12:27:33 +0300
Matti Vaittinen <mazziesaccount@xxxxxxxxx> 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@xxxxxxxxx> 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