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

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]

Date: Mon, 20 Nov 2023 16:00:18 +0000
From: Min Li <min.li.xe@...esas.com>
To: Simon Horman <horms@...nel.org>, Min Li <lnimi@...mail.com>
CC: "richardcochran@...il.com" <richardcochran@...il.com>, "lee@...nel.org"
	<lee@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>
Subject: RE: [PATCH net-next v4 1/1] ptp: clockmatrix: support 32-bit address
 space

> 
> 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@MW5PR03MB6932.namprd03.prod.outlook.com/T/