RE: [PATCH v4 net-next 03/13] dt-bindings: net: add bindings for NETC blocks control

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

 



> On Wed, Oct 23, 2024 at 11:18:43AM +0300, Wei Fang wrote:
> > > > +maintainers:
> > > > +  - Wei Fang <wei.fang@xxxxxxx>
> > > > +  - Clark Wang <xiaoning.wang@xxxxxxx>
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    enum:
> > > > +      - nxp,imx95-netc-blk-ctrl
> > > > +
> > > > +  reg:
> > > > +    minItems: 2
> > > > +    maxItems: 3
> > >
> > > You have one device, why this is flexible? Device either has exactly 2
> > > or exactly 3 IO spaces, not both depending on the context.
> > >
> >
> > There are three register blocks, IERB and PRB are inside NETC IP, but NETCMIX
> > is outside NETC. There are dependencies between these three blocks, so it is
> > better to configure them in one driver. But for other platforms like S32, it
> does
> > not have NETCMIX, so NETCMIX is optional.
> 
> Looking at this patch (in v5), I was confused as to why you've made
> pcie@4cb00000
> a child of system-controller@4cde0000, when there's no obvious parent/child
> relationship between them (the ECAM node is not even within the same
> address
> space as the "system-controller@4cde0000" address space, and it's not
> even clear what the "system-controller@4cde0000" node _represents_:
> 
> examples:
>   - |
>     bus {
>         #address-cells = <2>;
>         #size-cells = <2>;
> 
>         system-controller@4cde0000 {
>             compatible = "nxp,imx95-netc-blk-ctrl";
>             reg = <0x0 0x4cde0000 0x0 0x10000>,
>                   <0x0 0x4cdf0000 0x0 0x10000>,
>                   <0x0 0x4c81000c 0x0 0x18>;
>             reg-names = "ierb", "prb", "netcmix";
>             #address-cells = <2>;
>             #size-cells = <2>;
>             ranges;
>             clocks = <&scmi_clk 98>;
>             clock-names = "ipg";
>             power-domains = <&scmi_devpd 18>;
> 
>             pcie@4cb00000 {
>                 compatible = "pci-host-ecam-generic";
>                 reg = <0x0 0x4cb00000 0x0 0x100000>;
>                 #address-cells = <3>;
>                 #size-cells = <2>;
>                 device_type = "pci";
>                 bus-range = <0x1 0x1>;
>                 ranges = <0x82000000 0x0 0x4cce0000  0x0 0x4cce0000
> 0x0 0x20000
>                           0xc2000000 0x0 0x4cd10000  0x0
> 0x4cd10000  0x0 0x10000>;
> 
> But then I saw your response, and I think your response answers my confusion.
> The "system-controller@4cde0000" node doesn't represent anything in and
> of itself, it is just a container to make the implementation easier.
> 
> The Linux driver treatment should not have a definitive say in the device tree
> bindings.
> To solve the dependencies problem, you have options such as the component
> API at
> your disposal to have a "component master" driver which waits until all its
> components have probed.
> 
> But if the IERB, PRB and NETCMIX are separate register blocks, they should
> have
> separate OF nodes under their respective buses, and the ECAM should be on
> the same
> level. You should describe the hierarchy from the perspective of the SoC
> address
> space, and not abuse the "ranges" property here.

I don't know much about component API. Today I spent some time to learn
about the component API framework. In my opinion, the framework is also
implemented based on DTS. For example, the master device specifies the
slave devices through a port child node or a property of phandle-array type. 

For i.MX95 NETC, according to your suggestion, the probe sequence is as
follows:

--> netxmix_probe() # NETCMIX
		--> netc_prb_ierb_probe() # IERB and PRB
				--> enetc4_probe() # ENETC 0/1/2
				--> netc_timer_probe() #PTP Timer
				--> enetc_pci_mdio_probe() # NETC EMDIO
						


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux