linux-kernel - RE: [PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and transfer-mode properties

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <TY2PPF5CB9A1BE62BD449193B23A22DF941F2FBA@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Thu, 30 Oct 2025 01:48:22 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, BMC-SW <BMC-SW@...eedtech.com>,
	"benh@...nel.crashing.org" <benh@...nel.crashing.org>, "joel@....id.au"
	<joel@....id.au>, "andi.shyti@...nel.org" <andi.shyti@...nel.org>,
	"jk@...econstruct.com.au" <jk@...econstruct.com.au>, "robh@...nel.org"
	<robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>, "andrew@...econstruct.com.au"
	<andrew@...econstruct.com.au>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>, "andriy.shevchenko@...ux.intel.com"
	<andriy.shevchenko@...ux.intel.com>, "naresh.solanki@...ements.com"
	<naresh.solanki@...ements.com>, "linux-i2c@...r.kernel.org"
	<linux-i2c@...r.kernel.org>, "openbmc@...ts.ozlabs.org"
	<openbmc@...ts.ozlabs.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
 global-regs and transfer-mode properties

> Subject: Re: [PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and transfer-mode properties
> 
> On 29/10/2025 10:25, Ryan Chen wrote:
> >> Subject: Re: [PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> >> global-regs and transfer-mode properties
> >>
> >> On 27/10/2025 07:12, Ryan Chen wrote:
> >>> The AST2600 I2C controller supports three transfer modes: byte,
> >>> buffer, and DMA. To allow board designers and firmware to explicitly
> >>> select the preferred transfer mode for each controller instance.
> >>> "aspeed,transfer-mode" to allow device tree to specify the desired
> >>> transfer method used by each I2C controller instance.
> >>>
> >>> And AST2600 i2c controller have two register mode, one is legacy
> >>> register layout which is mix controller/target register control
> >>> together, another is new mode which is separate controller/target
> >>> register control.
> >>>
> >>
> >> This implies your "reg" properties have now completely different
> >> meaning and this would be quite an ABI break. We discussed this probably
> 15 revisions ago.
> >> Where did you document the resolution of that discussion?
> >
> > Let me explain more about "reg"
> > The 'reg' property continues to describe the same register regions
> > (bus and buffer) as in the legacy layout. The selection between the
> > legacy and new register layout is controlled by a bit in the SoC-level
> > global register block, referenced through the new 'aspeed,global-regs'
> property.
> > Therefore, the meaning of the 'reg' property does not change and no DT
> > ABI break occurs.
> >
> > Should I add it in commit message about "reg" ?
> 
> Then why does the address change from 0x40 to 0x80. If it is the same, it
> cannot change.
> 
> You are describing the IO address space, total address space, as defined by
> datasheet. Not whatever is in the driver.

Thanks for pointing that out.

But to clarify: the address change from 0x40 to 0x80 in the example is not
arbitrary. It comes directly from the AST2600 SoC datasheet, where the
I2C controller base and buffer regions are at different offsets compared
to the AST2500 (0x80 / 0xc00 vs 0x40 / 0x200).
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/aspeed/aspeed-g5.dtsi#L589
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi#L888
the correct hardware layout rather than a driver-specific offset.

> 
> 
> Best regards,
> Krzysztof