On 21/11/2025 06:23, Ryan Chen wrote:

quoted

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

quoted

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:

quoted

quoted

quoted

quoted

quoted

quoted

+  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

quoted

quoted

What you question about
" Please explain me how one, same SoC has optional IO address space?
I

asked to explain WHY this is flexible"

quoted

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.

quoted

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/ (local)

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