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] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf5f5efb49ef6230ba5084e53316a8fb8ddedef1.camel@codeconstruct.com.au>
Date: Tue, 30 Jul 2024 13:26:21 +0930
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: Patrick Williams <patrick@...cx.xyz>, Delphine CC Chiu
	 <Delphine_CC_Chiu@...ynn.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
  Conor Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>,
 devicetree@...r.kernel.org,  linux-arm-kernel@...ts.infradead.org,
 linux-aspeed@...ts.ozlabs.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH v11 25/27] ARM: dts: aspeed: yosemite4: add RTQ6056
 support

On Mon, 2024-07-29 at 17:03 -0500, Patrick Williams wrote:
> On Tue, Jul 23, 2024 at 05:23:06PM +0800, Delphine CC Chiu wrote:
> > Add RTQ6056 (spider board 3rd source) support in yosemite4 DTS.
> > 
> > Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>
> > ---
> >  .../boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts  | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> > index f73719b3c2f1..03a1e41312e3 100644
> > --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> > @@ -1240,35 +1240,35 @@ adc@37 {
> >  	};
> >  
> >  	power-sensor@40 {
> > -		compatible = "ti,ina233";
> > +		compatible = "ti,ina233", "richtek,rtq6056";
> 
> Is this legal to have two chips both listed as compatible?  I thought
> this approach has been rejected before.

It depends on the circumstances. Does one have a superset of the
functionality of the other?

https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#compatible

Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ