netdev - Re: [PATCH v6 08/30] dt-bindings: soc: fsl: cpm_qe: cpm1-scc-qmc: Add support for QMC HDLC

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]

Date: Tue, 26 Sep 2023 22:59:14 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Lee Jones <lee@...nel.org>,
 Linus Walleij <linus.walleij@...aro.org>, Qiang Zhao <qiang.zhao@....com>,
 Li Yang <leoyang.li@....com>, Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>, Shengjiu Wang <shengjiu.wang@...il.com>,
 Xiubo Li <Xiubo.Lee@...il.com>, Fabio Estevam <festevam@...il.com>,
 Nicolin Chen <nicoleotsuka@...il.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Randy Dunlap <rdunlap@...radead.org>, netdev@...r.kernel.org,
 linuxppc-dev@...ts.ozlabs.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, alsa-devel@...a-project.org,
 Simon Horman <horms@...nel.org>,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v6 08/30] dt-bindings: soc: fsl: cpm_qe: cpm1-scc-qmc: Add
 support for QMC HDLC

On 25/09/2023 15:50, Herve Codina wrote:
>>>>> With these details, do you still think I need to change the child (channel)
>>>>> compatible ?    
>>>>
>>>> From OS point of view, you have a driver binding to this child-level
>>>> compatible. How do you enforce Linux driver binding based on parent
>>>> compatible? I looked at your next patch and I did not see it.  
>>>
>>> We do not need to have the child driver binding based on parent.  
>>
>> Exactly, that's what I said.
>>
>>> We have to ensure that the child handles a QMC channel and the parent provides
>>> a QMC channel.
>>>
>>> A QMC controller (parent) has to implement the QMC API (include/soc/fsl/qe/qmc.h)
>>> and a QMC channel driver (child) has to use the QMC API.  
>>
>> How does this solve my concerns? Sorry, I do not understand. Your driver
>> is a platform driver and binds to the generic compatible. How do you
>> solve regular compatibility issues (need for quirks) if parent
>> compatible is not used?
>>
>> How does being QMC compliant affects driver binding and
>> compatibility/quirks?
>>
>> We are back to my original question and I don't think you answered to
>> any of the concerns.
> 
> Well, to be sure that I understand correctly, do you mean that I should
> provide a compatible for the child (HDLC) with something like this:
> --- 8< ---
>   compatible:
>     items:
>       - enum:
>           - fsl,mpc885-qmc-hdlc
>           - fsl,mpc866-qmc-hdlc
>       - const: fsl,cpm1-qmc-hdlc
>       - const: fsl,qmc-hdlc
> --- 8< ---

Yes, more or less, depending on actual compatibility and SoC-family.
Maybe "fsl,cpm1-qmc-hdlc" item in the middle is not needed.

> 
> If so, I didn't do that because a QMC channel consumer (driver matching
> fsl,qmc-hdlc) doesn't contains any SoC specific part.

Just like hundreds of other drivers. :)

There is a paragraph about specific compatibles here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-schema.html

> It uses the channel as a communication channel to send/receive HDLC frames
> to/from this communication channel.
> All the specific SoC part is handled by the QMC controller (parent) itself and
> not by any consumer (child).

OK, so you guarantee in 100% for this hardware and all future (including
designs unknown currently), that they will be 100% compatible with
existing QMC channel consumer (child, matching fsl,qmc-hdlc) driver,
thus there will be no need for any quirk. Specifically, there will be no
chances that it would be reasonable to re-use the same driver for child
(currently fsl,qmc-hdlc) in different parent.

P.S. If you received this email twice, apologies, I have here troubles
with internet.

Best regards,
Krzysztof