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
