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

[Krzysztof Kozlowski <krzk@kernel.org>]

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