Hi Krzysztof, On Tue, 26 Sep 2023 22:59:14 +0200 Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > 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. Ok, I will keep "fsl,cpm1-qmc-hdlc". The CPM1 is the co-processor present in these SoCs and it handles the QMC controller. So, it makes sense to have it in this binding. I plan to add support for other SoCs in the future and for these SoCs, the co-processor is not the CPM1. So, it makes sense to keep "fsl,cpm1-qmc-hdlc" to identify the co-processor. > > > > > 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. Right, compatible strings with SoC and co-processor will be added in the next iteration. Thanks for your feedback. Best regards, Hervé > > P.S. If you received this email twice, apologies, I have here troubles > with internet. > > Best regards, > Krzysztof >
