[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <36e2b87f-5567-4bd6-bd1b-789623441461@kernel.org>
Date: Wed, 29 Oct 2025 12:19:44 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ryan Chen <ryan_chen@...eedtech.com>, 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
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.
Best regards,
Krzysztof
Powered by blists - more mailing lists
 
