Re: RFC: Advice on adding support for Qualcomm IPQ9574 SoC Ethernet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Regards,
Bjorn




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux