On 13:31-20230713, Andrew Davis wrote: > On 7/13/23 1:21 PM, Nishanth Menon wrote: > > On 21:01-20230713, Jayesh Choudhary wrote: > > > > > > > > > On 12/07/23 19:48, Nishanth Menon wrote: > > > > On 15:47-20230710, Jayesh Choudhary wrote: > > > > > From: Siddharth Vadapalli <s-vadapalli@xxxxxx> > > > > > > > > > > J784S4 SoC has 4 Serdes instances along with their respective WIZ > > > > > instances. Add device-tree nodes for them and disable them by default. > > > > > > > > > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@xxxxxx> > > > > > [j-choudhary@xxxxxx: fix serdes_wiz clock order] > > > > > Signed-off-by: Jayesh Choudhary <j-choudhary@xxxxxx> > > > > > --- > > > > NAK. This patch introduces the following dtbs_check warning. > > > > arch/arm64/boot/dts/ti/k3-am69-sk.dtb: serdes-refclk: 'clock-frequency' is a required property > > > > > > > > > > Sorry for this. This property was added in the final board file. > > > I will fix it in the next revision. > > > I will add '0' as clock-property in the main file similar to j721e[1] > > > which will be overridden in the board file with required value to get > > > rid of this warning. > > > > That would follow what renesas (r8a774a1.dtsi) and imx > > (imx8dxl-ss-conn.dtsi) seem to be doing as well. Just make sure to add > > documentation to the property to indicate expectation. Unless someone > > has objections to this approach. > > > > Would it work better to disable these nodes, only enabling them in the > board files when a real clock-frequency can be provided? > > My initial reaction would be to move the whole external reference clock > node to the board file since that is where it is provided, but seems > that would cause more churn in serdes_wiz* nodes than we would want.. I would prefer that as well, but I have'nt gone around looking for similar examples on other SoCs (Jayesh, can you check?). One other approach (alipine and few other places) has been for the bootloader to update the property set in dtb as 0, which is not needed in this case to the best of what I see.. just hoping we use a technique that most board folks are familiar with across SoCs. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D