[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