linux-kernel - Re: [PATCH v20 1/4] dt-bindings: i2c: Split AST2600 binding into a new YAML

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: <3f81e6dc-65c9-4c99-ac5a-43bea16d6e55@kernel.org>
Date: Fri, 21 Nov 2025 08:18:54 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ryan Chen <ryan_chen@...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 v20 1/4] dt-bindings: i2c: Split AST2600 binding into a
 new YAML

On 21/11/2025 06:23, Ryan Chen wrote:
>> Subject: RE: [PATCH v20 1/4] dt-bindings: i2c: Split AST2600 binding into a new
>> YAML
>>
>>> Subject: Re: [PATCH v20 1/4] dt-bindings: i2c: Split AST2600 binding
>>> into a new YAML
>>>
>>> On 13/11/2025 10:34, Ryan Chen wrote:
>>>>>>>>> +  reg:
>>>>>>>>> +    minItems: 1
>>>>>>>>
>>>>>>>> Why?
>>>>>>>
>>>>>>> Will update as following.
>>>>>>>
>>>>>>> reg:
>>>>>>>   minItems: 1
>>>>>>>   maxItems: 2
>>>>>>
>>>>>>
>>>>>> No. You changed nothing. Instead explain why this is flexible.
>>>>>>
>>>>>> See writing bindings.
>>>>>
>>>>> Sorry, I still not understand your point. Do you mean need to
>>>>> explain why reg is flexible 1 -> 2?
>>>>> If yes, I will update to following.
>>>>>
>>>>> reg:
>>>>>   minItems: 1
>>>>>   maxItems: 2
>>>>>   description:
>>>>>     The first region covers the controller registers.
>>>>>     The optional second region covers the controller's buffer space.
>>>>
>>>> After check the
>>>> https://docs.kernel.org/devicetree/bindings/writing-schema.html#anno
>>>> ta ted-example-schema I think I should update with following, am I
>>>> correct ?
>>>>
>>>>  reg:
>>>>    items:
>>>>      - description: The first region covers the controller registers.
>>>> 	 - description: The optional second region covers the controller's
>>>> buffer
>>> space.
>>>
>>> Please drop "The first region covers" and same for the second. Just
>>> say what is this - controller register and controllers buffer space -
>>> and second one is not optional now.
>>
>> Thanks, will update
>>
>> items:
>>   - description: Controller registers
>>   - description: Controller buffer space
>>>
>>>>
>>>> What you question about
>>>> " Please explain me how one, same SoC has optional IO address space?
>>>> I
>>> asked to explain WHY this is flexible"
>>>> The AST2600 i2c controller have three io,buffer,dma mode.
>>>> The AST2600 have buffer register for buffer transfer. That is 2nd reg offset.
>>>
>>> So the SoC *HAS* it. It is always there. It cannot be missing in the hardware.
>>>
>>>> If dtsi not descript it, the driver will go back to io mode
>>>> transfer. Flexible
>>> implement is in driver.
>>>
>>> Describe the hardware.
>>
>> Understood, thanks your guidance.
> 
> Hello Krzysztof.
> 	Appreciate your review.
> 	I’ve updated the reg and clock section according to your comments.
> 	Do you have any further suggestions on those updates?	https://lore.kernel.org/all/20251118014034.820988-2-ryan_chen@aspeedtech.com/

You sent it on Nov 18. Then you pinged on Nov 19, now you ping on Nov 21.

What's sort of rush is this? I don't respond well to such pressure so I
will move your patch to the bottom of review queue.

Best regards,
Krzysztof