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: <76714850-0e02-4333-acce-02c7657666b0@linaro.org>
Date: Tue, 9 Apr 2024 08:33:22 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Frank Li <Frank.li@....com>
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 08/04/2024 17:36, Frank Li wrote:
> On Fri, Apr 05, 2024 at 08:21:18PM +0200, Krzysztof Kozlowski wrote:
>> On 05/04/2024 16:46, Frank Li wrote:
>>> 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.
>>
>> Yes, we resolved it long time ago. Your bootloader can (usually easily)
>> detect revision of the board and load appropriate DTS or DTS+DTSO.
> 
> I knewn it. But the problem is one development boards A have many options,
> so create many child dts for files, A1, A2, ... An which base on A

So use DTSO, what's the problem? Other vendors, liek Rpi does not have
problem with it and it works well. No confusion.

> 
> If there are difference happen at A, create new B. then create all child
> dtb, B1, B2, ... Bn.  DTB number will increase exponent.
> 
> If change is quite bit, we have to do that. But if change is quite small,
> One dtb can cover it by driver auto detect, which will work like some
> adaptor card have not plug into boards, or some sensor or NOR-flash have
> not installed because reduce cost.

You have two boards, not 20 here!

>   
> Although boot loader can update dts or choose difference dts, It also cause
> many confusition, such as layerscape, uboot update many kernel dtb's
> information, which actually increase dependence between uboot and kernel.
> Also it confuse people, for example,  when try to debug kernel dtb, why
> change have not token affect when change dts because not realized uboot
> over write it.
> 
> What's I dide is that trying to reduce unnecessary dts.

There is no confusion. That's normal process, so if someone is confused
by having variants of board, this someone will be even more confused by
seeing non-existing hardware in his DTS.

This problem was solved long time ago and you do not bring any
reasonable new arguments. All vendors solved it (just look at ongoing
discussions on board id) but only you have problem with their solution.

NAK

Best regards,
Krzysztof