On 10/6/2024 12:00 AM, Bjorn Andersson wrote: > On Fri, Oct 04, 2024 at 07:47:15PM GMT, Kiran Kumar C.S.K wrote: >> >> >> On 10/4/2024 12:50 AM, Bjorn Andersson wrote: >>> On Thu, Oct 03, 2024 at 11:20:03PM +0530, Kiran Kumar C.S.K wrote: >>>> On 10/3/2024 2:58 AM, Andrew Lunn wrote: >>>>> On Thu, Oct 03, 2024 at 02:07:10AM +0530, Kiran Kumar C.S.K wrote: > [..] >>> The only remaining dependency I was expecting is the qcom tree depending >>> on the clock and netdev trees to have picked up the bindings, and for >>> new bindings I do accept dts changes in the same cycle (I validate dts >>> against bindings in linux-next). >>> >> >> The only compile-time dependency from PCS driver to NSS CC driver is >> with the example section in PCS driver's dtbindings file. The PCS DTS >> node example definitions include a header file exported by the NSS CC >> driver, to access certain macros for referring to the MII Rx/Tx clocks. >> So, although there is no dependency in the driver code, a successful >> dtbindings check will require the NSS CC driver to be available. Could >> you suggest how such dependencies can be worked around? Would it be >> acceptable to defer enabling the example node for dtbindings compilation >> using its 'status' property, until the NSS CC driver is merged? >> > > You can avoid this dependency by making the example...an example. > > By using just descriptive phandles you can present an example of the > client device without creating a dependency on the specific provider. > Sure, will represent this as a descriptive phandle and nothing more. Thanks. > Regards, > Bjorn
