RE: [PATCH net-next v4 1/1] ptp: clockmatrix: support 32-bit address space

[Min Li]

> 
> I feel that I am missing something obvious, but I have a question which I
> would like to ask by way of an example.
> 
> Both before and after this patch idtcm_read() looks like this:
> 
> static inline int idtcm_read(struct idtcm *idtcm,
> 			     u16 module,
> 			     u16 regaddr,
> 			     u8 *buf,
> 			     u16 count) {
>         return regmap_bulk_read(idtcm->regmap, module + regaddr, buf,
> count); }
> 
> And so before this patch the above call to idtcm_read() ends up as a call to
> regmap_bulk_read:
> 
> 	regmap_bulk_read(idtcm->regmap, 0 + 0xa7d4, buf, count);
> 
> In particular, the 2nd argument is 0 + 0xa7d4 = 0xa7d4.
> 
> But after this patch the call to idtcm_read() becomes:
> 
> 	regmap_bulk_read(idtcm->regmap,  0x2010a7d4 + 0, buf, count);
> 
> In particular, the 2nd argument is now 0x2010a7d4 + 0 = 0x2010a7d4.
> 
> My question is, how does this patch take into account the change in this
> value from 0xa7d4 to 0x2010a7d4?
> 
> Or to the point, does the call to regmap_bulk_read() still work with the new
> value?

Hi Simon:

The regmap_bulk_read side of change is handled by the following patch. Basically
Clockmatrix has 4 bytes of offset registers and rsmu_i2c driver used to assume 
0x2010 as part of the offset and only take the lower 2 byte offset from regmap_bulk_read.
After the change, rsmu_i2c will take the full 4 byte offset from regmap_bulk_read

https://lore.kernel.org/lkml/MW5PR03MB693295AF31ABCAF6AE52EE74A08B9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/