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] [day] [month] [year] [list]

Message-ID:
 <TY2PPF5CB9A1BE6B4BB7A8237EE8A125B2DF2D5A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Fri, 21 Nov 2025 07:22:50 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, "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

> 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#ann
> >>>> o 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@aspeed
> tech.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.

Hi Krzysztof,

Thank you for the reminder.

My intention was not to rush you — I apologize if my follow-ups gave that impression.
I only wanted to confirm whether I had misunderstood or failed to address any of your comments, since I was worried that I might be missing something important.

I appreciate your time and your guidance on this series.
I will wait for your review patiently.

Best regards,
Ryan