On Mon, Dec 02, 2024 at 12:07:17PM +0100, Krzysztof Kozlowski wrote: > On 02/12/2024 11:58, Siddharth Vadapalli wrote: > > On Mon, Dec 02, 2024 at 11:14:46AM +0100, Krzysztof Kozlowski wrote: > > > > Hello Krzysztof, > > > >> On 02/12/2024 11:11, Romain Naour wrote: > >>> From: Romain Naour <romain.naour@xxxxxxx> > >>> > >>> Unlike the SK-TDA4VM (k3-j721e-sk) board, there is no clock generator > >>> (CDCI6214RGET) on the BeagleBone AI-64 (k3-j721e-beagleboneai64) to > >>> provide PCIe refclk signal to PCIe Endponts. So the ACSPCIE module must > >>> provide refclk through PCIe_REFCLK pins. > >>> > >>> Use the new "ti,syscon-acspcie-proxy-ctrl" property to enable ACSPCIE > >>> module's PAD IO Buffers. > >>> > >>> Reuse the compatible "ti,j784s4-acspcie-proxy-ctrl" since the ACSPCIE > >>> buffer and its functionality is the same across all K3 SoCs. > >>> > >>> Cc: Siddharth Vadapalli <s-vadapalli@xxxxxx> > >>> Signed-off-by: Romain Naour <romain.naour@xxxxxxx> > >>> --- > >>> With this patch, we can remove "HACK: Sierra: Drive clock out" patch > >>> applied on vendor kernel for BeagleBone AI-64: > >>> https://openbeagle.org/beagleboard/linux/-/commit/ad65d7ef675966cdbc5d75f2bd545fad1914ba9b > >>> > >>> v2: > >>> - use generic style comments > >>> - use "syscon" as generic node name for "acspcie0_proxy_ctrl" node > >>> - Keep the compatible "ti,j784s4-acspcie-proxy-ctrl" since the > >>> ACSPCIE buffer and its functionality is the same across all K3 SoCs. > >>> (Siddharth Vadapalli) > >>> > >>> "The compatible "ti,j784s4-acspcie-pcie-ctrl" should be reused for > >>> J721E and all other K3 SoCs. > >> > >> No, it shouldn't and you got comment on this. You always need specific > >> compatible, see writing bindings doc. > > > > Could you please clarify in which cases reusing the compatible is > > permissible? The list of compatibles at: > > Never? You always need specific compatible. Did you read the writing > bindings document? > > > https://github.com/torvalds/linux/blob/v6.12/Documentation/devicetree/bindings/mfd/syscon.yaml#L112 > > namely, > > - ti,am62-opp-efuse-table > > - ti,am62-usb-phy-ctrl > > - ti,am625-dss-oldi-io-ctrl > > - ti,am62p-cpsw-mac-efuse > > - ti,am654-dss-oldi-io-ctrl > > - ti,j784s4-pcie-ctrl > > have all been reused for different TI SoCs since they all correspond to the > > device functionality enabled via the CTRL_MMR System Controller registers. > > If you find a bug, does it mean you can send new patch introducing the > same bug? Thank you for clarifying. Since the above compatibles have been reused, they served as an example and appeared as the norm. But as you said, the reference should be the bindings document and not the patches that got through and ended up in the bindings. I will make sure that I add new compatibles for each SoC going forward, despite what the existing implementation suggests. Regards, Siddharth.
