linux-kernel - Re: [PATCH] ASoC: dt-bindings: maxim,max98357a: Add compatible with richtek,rt9123

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: <68e4ce8b-68a9-47a4-88c6-a4a401f5196d@kernel.org>
Date: Wed, 19 Mar 2025 08:42:11 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: ChiYuan Huang <cy_huang@...htek.com>
Cc: Mark Brown <broonie@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Tzung-Bi Shih <tzungbi@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
 Otto Lin <otto_lin@...htek.com>, Allen Lin <allen_lin@...htek.com>,
 linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: dt-bindings: maxim,max98357a: Add compatible with
 richtek,rt9123

On 18/03/2025 12:26, ChiYuan Huang wrote:
> On Tue, Mar 18, 2025 at 09:55:48AM +0100, Krzysztof Kozlowski wrote:
>> On Tue, Mar 18, 2025 at 08:57:51AM +0800, cy_huang@...htek.com wrote:
>>> From: ChiYuan Huang <cy_huang@...htek.com>
>>>
>>> The hardware control and specification of 'richtek,rt9123' are similar
>>> with max98357 or max98360. It's no need to add the new source code. So
>>
>> Are you sure? I looked at datasheet and do not see anything about
>> SD_MODE in RT9123. Also you have two supplies, while max98360a has only
>> one. You have I2C but max98360a has no.
>>
> Sure, consider the I2C mode. Then it seems different. For the power
> supply, yes, we have one more supply and it's used for digital input
> output reference. It will always tiled to SoC digital power domain.
> It's no need to control, so I think DVDD can be ignored.
> 
> If not considering the I2C, and the DVDD power supply, for HW control
> mode, then it looks the same including sample rate. One pin to turn on
> the amplifier.
> 
> This IC is designed for 'easy to use'. For the normal condition, HW mode
> will always be suggested to the customer.
> 
> May I have your suggestion? If it can not be compatible, should I write
> two drivers, one platform driver for HW control mode, and another I2C driver
> for I2C SW control mode?


We don't talk about drivers here. I only commented that they are not
compatible based on datasheets, so compatibility should not be expressed
in the DT. Considering I2C, this should be in its own binding with full
device description (so for both HW mode and I2C).

Best regards,
Krzysztof