Message-ID: <7e3c1b0b-2880-4abc-b80f-30ffc16d6158@kernel.org>
Date: Wed, 5 Nov 2025 08:05:45 +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 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!


Best regards,
Krzysztof

Powered by blists - more mailing lists