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:
 <TY2PPF5CB9A1BE6C0ACB11FE9BB209B9273F2CAA@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Fri, 14 Nov 2025 06:17:56 +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 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#annota
> > 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.

> 
> Best regards,
> Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ