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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <TY2PPF5CB9A1BE6AA78DB1519305B565746F2C3A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Fri, 7 Nov 2025 06:35:01 +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 30/10/2025 02:48, Ryan Chen wrote:
> >> 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
> 
> How so? Binding has an example for ast2600 with address 0x40. You now claim
> the change is to adjust to ast2600. But it is ALREADY ast2600!
> 
Understood, I will keep the address.

And I can fix in previous split ast2600-i2c.yaml patch. am I right?

> 
> Best regards,
> Krzysztof