Message-ID: <497bb0d287474ba1dbaded0c5068569203a8691a.camel@canoga.com>
Date:   Wed, 10 Mar 2021 15:37:26 +0000
From:   "Wyse, Chris" <cwyse@...oga.com>
To:     "andrew@...n.ch" <andrew@...n.ch>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "drichards@...inj.com" <drichards@...inj.com>
Subject: Re: DSA

> > The current boot sequence is below:
> > 1. i210 driver loads
> > 2. Device Tree overlay installed (in addition to ACPI)
> >    - Includes DSA switch and ports, but master port was incorrectly
> > specified as the EMACLite IP module, which had a DT node
> >    - No DT node for the i210
> > 3. MFD driver reads DT overlay and instantiates supporting devices
and
> > the DSA driver
> >
> > My thought was to create a DT entry for the i210 in the overlay,
even
> > though the driver is already loaded via ACPI.  The DT overlay node
for
> > the i210 would provide any needed information to the DSA
driver.  It
> > would be essentially a reference to the already loaded driver.
>
> I don't think what works. The normal sequence is that the PCI bus is
> probed and devices found. At that point in time, the PCI core looks
in
> DT and finds the DT node associated with the device, and assigns
> dev->of_node to point to the DT node. The device is then registered
> with the device core. It will go off and try to find a driver of the
> device, probe it, etc.
>
> Sometime later, the DSA driver will probe. The phandle in device tree
> is turned into a pointer. And then all devices registered for the
> netdev class are walked to see if any have dev->of_node set to the
> node.
>
> So for this sequence to work, the overload needs to be loaded at the
> point the PCI bus is scanned for devices. Now, there could be some
> magic going on when an overlay is loaded, scanning the DT for devices
> which have already loaded, and assigning there dev->of_node? I've no
> idea, i've not used overlays. You probably want to add some printk()
> into pci_set_of_node().
>
> The idea with hotplug is that i guess it should rescan the PCI bus.
So
> that should cause pci_set_of_node() to be called, and now there is a
> DT node for the device.
>
> So i suggest you scatter some printk() in the PCI code, and
> of_find_net_device_by_node() and the functions it calls to see what
is
> really going on, do i have the sequencing correct.
>
Great information and ideas.  Thank you.

Currently, the PCI bus is probed at boot, and the FPGA the i210 are
detected.  The i210 driver gets loaded at boot, the DT overlays are
applied, and then we load the MFD driver for the FPGA.  The MFD driver
loads all supporting drivers, then loads the DSA driver.

I'm wondering if I could build the igb driver as a module (not quite
the same as hotplug, but seems like it would work), then load it after
the DT overlay has been added.  The PCI core would need to look for a
device tree node prior to an ACPI node (or I'd need to modify it to
work that way).  Otherwise, I believe that the DT code would be
skipped.

I _think_ that I could use something similar to your host@0 node for
the i210 DT definition and addressing.  I wouldn't need a node for the
PCIe as long as I provided the correct addressing for the i210 node.

---- Another thought ---

The loading of the device tree overlays was based on the device tree
unit test code.  From that, I created a simple device driver that takes
a dtbo file and loads it.  Instead of creating it as a module, I could
instantiate it prior to the the PCI driver.  If the PCI code favors the
DT over the ACPI, the maybe it would load the driver for me via DT
without any other changes.

----

Looking into the code now to see how these options would play out, with
emphasis on the areas you mentioned.  Please let me know if I've
misinterpreted any of your comments or if it's apparent that I've
missed a critical piece.  I'm not an expert in any of these area, and
struggling a bit to provide coherent and reasonable responses, so your
feedback is welcome.

Chris

________________________________

Canoga Perkins
20600 Prairie Street
Chatsworth, CA 91311
(818) 718-6300

This e-mail and any attached document(s) is confidential and is intended only for the review of the party to whom it is addressed. If you have received this transmission in error, please notify the sender immediately and discard the original message and any attachment(s).

Powered by blists - more mailing lists