linux-kernel - Re: [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40

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: <ZhAO4YWuB8r8k+m8@lizhi-Precision-Tower-5810>
Date: Fri, 5 Apr 2024 10:46:57 -0400
From: Frank Li <Frank.li@....com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>,
	"open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <imx@...ts.linux.dev>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@...ts.infradead.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962
 and sai[0,1,4,5]

On Fri, Apr 05, 2024 at 08:41:59AM +0200, Krzysztof Kozlowski wrote:
> On 04/04/2024 18:19, Frank Li wrote:
> > imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
> > i2c bus mux to connect both i2c devices. One will probe failure and other
> > will probe success when devices driver check whoami. So one dtb can cover
> > both board configuration.
> 
> I don't understand it. Either you add real device or not. If one board
> has two devices, then why do you need to check for failures?
> 
> Anyway, don't add fake stuff to DTS.

NAK can't resolve the problem. It should be common problem for long time
cycle boards. Some chipes will be out life cycle. such as some sensor. So
chips on boards have been replace by some pin to pin compatible sensor. For
example: 
	old boards: use sensor A with address 0x1a
	new bench: use sensor B with address 0x1b.

You can treat it as two kind boards, RevA or RevB. But most user want to
use one dtb to handle such small differences. For this case, it should be
simple. Just add a super set.
	i2c
	{
		sensorA@1a
		{
		}
		sensorB@1b
		{
		}	
	}

It also depend on whoami check by i2c devices. Only A or B will probe.

wm8960 and wm8962 are more complex example.  wm8960 is out of life. But
wm8962 and wm8960 have the same i2c address. The current i2c frame can't
allow the same i2c address in one i2c bus.

You are feel to NAK my method, but I hope you also provide constructive
solution to help resolve the problem.

Frank

> 
> NAK.
> > 
> > Signed-off-by: Frank Li <Frank.Li@....com>
> > ---
> >  arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 210 ++++++++++++++++++
> >  1 file changed, 210 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> > index 8360bb851ac03..adff87c7cf305 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
> > @@ -30,6 +30,13 @@ reg_usdhc2_vmmc: usdhc2-vmmc {
> >  		enable-active-high;
> >  	};
> >  
> > +	reg_audio: regulator-wm8962 {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "3v3_aud";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +	};
> > +
> >  	gpio-sbu-mux {
> >  		compatible = "nxp,cbdtu02043", "gpio-sbu-mux";
> >  		pinctrl-names = "default";
> > @@ -44,6 +51,105 @@ usb3_data_ss: endpoint {
> >  			};
> >  		};
> >  	};
> > +
> > +	sound-wm8960 {
> > +		compatible = "fsl,imx-audio-wm8960";
> > +		model = "wm8960-audio";
> > +		audio-cpu = <&sai1>;
> > +		audio-codec = <&wm8960>;
> > +		hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
> > +		audio-routing =
> > +			"Headphone Jack", "HP_L",
> > +			"Headphone Jack", "HP_R",
> > +			"Ext Spk", "SPK_LP",
> > +			"Ext Spk", "SPK_LN",
> > +			"Ext Spk", "SPK_RP",
> > +			"Ext Spk", "SPK_RN",
> > +			"LINPUT1", "Mic Jack",
> > +			"Mic Jack", "MICB";
> > +	};
> > +
> > +	sound-wm8962 {
> > +		compatible = "fsl,imx-audio-wm8962";
> > +		model = "wm8962-audio";
> > +		audio-cpu = <&sai1>;
> > +		audio-codec = <&wm8962>;
> > +		hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
> > +		audio-routing =
> > +			"Headphone Jack", "HPOUTL",
> > +			"Headphone Jack", "HPOUTR",
> > +			"Ext Spk", "SPKOUTL",
> > +			"Ext Spk", "SPKOUTR",
> > +			"AMIC", "MICBIAS",
> > +			"IN3R", "AMIC",
> > +			"IN1R", "AMIC";
> > +	};
> > +
> > +	/*
> > +	 * This dummy i2c mux. GPIO actually will not impact selection. At actual boards, only 1
> > +	 * device connectted. I2C client driver will check ID when probe. Only matched ID's driver
> > +	 * probe successfully.
> 
> NAK
> 
> 
> Best regards,
> Krzysztof
>