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

Ryan Chen ryan_chen at aspeedtech.com
Fri Nov 21 16:23:38 AEDT 2025


> 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/

Best regards,
Ryan Chen


More information about the Linux-aspeed mailing list