| Message ID | 1450875402-20740-26-git-send-email-andrew@lunn.ch |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
Le 23/12/2015 04:56, Andrew Lunn a écrit : > With the introduction of switches as linux devices and the use of the > component framework, probing has become more complex. Add some > documentation. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > --- > Documentation/networking/dsa/dsa.txt | 48 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt > index aa9c1f9313cd..376afa135a81 100644 > --- a/Documentation/networking/dsa/dsa.txt > +++ b/Documentation/networking/dsa/dsa.txt > @@ -398,6 +398,54 @@ Switch configuration > on the management interface and "hardcode"/"force" this MAC address for the > CPU/management interface as an optimization > > +Call flow > +--------- > + > +With the ability for switch devices to be true linux devices, the call > +flow is somewhat complex. The component framework is used to link the > +dsa framework as the master, with switch devices, as slaves. > + > +A switch device should add itself as a component in its probe > +function. > + > +The DSA framework can either be configured using a platform_data > +structure or from the device tree. If device tree is being used, the > +dsa framework probe function will allocate a platform_data structure, > +and populate it using the device tree, via the dsa_of_probe() > +function. Within the DSA device tree, switch devices are represented > +by a phandle to the switch device. These phandles are saved into the > +platform data so that when switch slaves register themselves, they can > +be correctly positioned in the DSA cluster. Humm, I guess I am still not clear on that, in a DT-only system, do I still need to get the DSA platform device to be probed via DT, along with references to the switches I want? If that is the case, that seems a little awkward, could not we probe the individual switches, and see if they need DSA instead? Or is that how the component framework works, just being a bit confused here. Thanks!
On Wed, Dec 23, 2015 at 12:48:28PM -0800, Florian Fainelli wrote: > Le 23/12/2015 04:56, Andrew Lunn a écrit : > > With the introduction of switches as linux devices and the use of the > > component framework, probing has become more complex. Add some > > documentation. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > --- > > Documentation/networking/dsa/dsa.txt | 48 ++++++++++++++++++++++++++++++++++++ > > 1 file changed, 48 insertions(+) > > > > diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt > > index aa9c1f9313cd..376afa135a81 100644 > > --- a/Documentation/networking/dsa/dsa.txt > > +++ b/Documentation/networking/dsa/dsa.txt > > @@ -398,6 +398,54 @@ Switch configuration > > on the management interface and "hardcode"/"force" this MAC address for the > > CPU/management interface as an optimization > > > > +Call flow > > +--------- > > + > > +With the ability for switch devices to be true linux devices, the call > > +flow is somewhat complex. The component framework is used to link the > > +dsa framework as the master, with switch devices, as slaves. > > + > > +A switch device should add itself as a component in its probe > > +function. > > + > > +The DSA framework can either be configured using a platform_data > > +structure or from the device tree. If device tree is being used, the > > +dsa framework probe function will allocate a platform_data structure, > > +and populate it using the device tree, via the dsa_of_probe() > > +function. Within the DSA device tree, switch devices are represented > > +by a phandle to the switch device. These phandles are saved into the > > +platform data so that when switch slaves register themselves, they can > > +be correctly positioned in the DSA cluster. > > Humm, I guess I am still not clear on that, in a DT-only system, do I > still need to get the DSA platform device to be probed via DT, along > with references to the switches I want? If that is the case, that seems > a little awkward, could not we probe the individual switches, and see if > they need DSA instead? Or is that how the component framework works, > just being a bit confused here. The component framework needs one master device and a number of slave devices. The master device effectively gives the framework a list of slave devices it needs. When the slave devices probe they register with the component framework. The master then asks the framework if its slaves are present, and if not returns -EPRODE_DEFERS and tries again later. So the dsa platform device is the master, and the switch devices are the slaves. It sounds like you want to 'optimise' for a DSA cluster consisting of a single switch, throwing away the D in DSA. Now the SF2 is a bit 'odd'. Since it is embedded in the SoC, you cannot have multiple of them in a cluster. So such an optimization could make sense for the SF2. But can we do this without adding too more complexity? Andrew -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 23/12/2015 14:53, Andrew Lunn a écrit : > On Wed, Dec 23, 2015 at 12:48:28PM -0800, Florian Fainelli wrote: >> Le 23/12/2015 04:56, Andrew Lunn a écrit : >>> With the introduction of switches as linux devices and the use of the >>> component framework, probing has become more complex. Add some >>> documentation. >>> >>> Signed-off-by: Andrew Lunn <andrew@lunn.ch> >>> --- >>> Documentation/networking/dsa/dsa.txt | 48 ++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 48 insertions(+) >>> >>> diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt >>> index aa9c1f9313cd..376afa135a81 100644 >>> --- a/Documentation/networking/dsa/dsa.txt >>> +++ b/Documentation/networking/dsa/dsa.txt >>> @@ -398,6 +398,54 @@ Switch configuration >>> on the management interface and "hardcode"/"force" this MAC address for the >>> CPU/management interface as an optimization >>> >>> +Call flow >>> +--------- >>> + >>> +With the ability for switch devices to be true linux devices, the call >>> +flow is somewhat complex. The component framework is used to link the >>> +dsa framework as the master, with switch devices, as slaves. >>> + >>> +A switch device should add itself as a component in its probe >>> +function. >>> + >>> +The DSA framework can either be configured using a platform_data >>> +structure or from the device tree. If device tree is being used, the >>> +dsa framework probe function will allocate a platform_data structure, >>> +and populate it using the device tree, via the dsa_of_probe() >>> +function. Within the DSA device tree, switch devices are represented >>> +by a phandle to the switch device. These phandles are saved into the >>> +platform data so that when switch slaves register themselves, they can >>> +be correctly positioned in the DSA cluster. >> >> Humm, I guess I am still not clear on that, in a DT-only system, do I >> still need to get the DSA platform device to be probed via DT, along >> with references to the switches I want? If that is the case, that seems >> a little awkward, could not we probe the individual switches, and see if >> they need DSA instead? Or is that how the component framework works, >> just being a bit confused here. > > The component framework needs one master device and a number of slave > devices. The master device effectively gives the framework a list of > slave devices it needs. When the slave devices probe they register > with the component framework. The master then asks the framework if > its slaves are present, and if not returns -EPRODE_DEFERS and tries > again later. > > So the dsa platform device is the master, and the switch devices are > the slaves. Ok, but then that means I still need to have a "marvell,dsa" node in Device Tree, that does not make sense to me with your changes, because the individual compatible and nodes for the switches are enough information to get their driver to probe, and as a consequence, register with DSA their switch devices, but let's keep following this point in the cover letter thread. > > It sounds like you want to 'optimise' for a DSA cluster consisting of > a single switch, throwing away the D in DSA. Now the SF2 is a bit > 'odd'. Since it is embedded in the SoC, you cannot have multiple of > them in a cluster. So such an optimization could make sense for the > SF2. But can we do this without adding too more complexity? The distributed case is the complex one, the one with a single switch hanging off an Ethernet MAC is the most common one and is much simpler to deal with.
> > It sounds like you want to 'optimise' for a DSA cluster consisting of > > a single switch, throwing away the D in DSA. Now the SF2 is a bit > > 'odd'. Since it is embedded in the SoC, you cannot have multiple of > > them in a cluster. So such an optimization could make sense for the > > SF2. But can we do this without adding too more complexity? > > The distributed case is the complex one, the one with a single switch > hanging off an Ethernet MAC is the most common one and is much simpler > to deal with. Sure, boards with multiple switches don't happen very often, but they do exist. If we can solve the general case, a single switch just works. The reverse is not true. Which is why i've been doing all my development work on a board with three switches. And in theory, i could even partition these into two DSA clusters! Andrew -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt index aa9c1f9313cd..376afa135a81 100644 --- a/Documentation/networking/dsa/dsa.txt +++ b/Documentation/networking/dsa/dsa.txt @@ -398,6 +398,54 @@ Switch configuration on the management interface and "hardcode"/"force" this MAC address for the CPU/management interface as an optimization +Call flow +--------- + +With the ability for switch devices to be true linux devices, the call +flow is somewhat complex. The component framework is used to link the +dsa framework as the master, with switch devices, as slaves. + +A switch device should add itself as a component in its probe +function. + +The DSA framework can either be configured using a platform_data +structure or from the device tree. If device tree is being used, the +dsa framework probe function will allocate a platform_data structure, +and populate it using the device tree, via the dsa_of_probe() +function. Within the DSA device tree, switch devices are represented +by a phandle to the switch device. These phandles are saved into the +platform data so that when switch slaves register themselves, they can +be correctly positioned in the DSA cluster. + +The DSA probe function then creates a dsa_switch_tree structure which +is the overarching structure representing a switch cluster. The probe +function then looks in the platform data for the phandles to slave +devices, and adds a component match based on the phandle. The +component master is then created. This causes the component framework +to link slaves to the master. + +If all the slave switch can be found, the masters bind function is +called, dsa_bind(). This in tern causes the switch slaves bind +function to be called. + +The switches bind function allocated memory for its own private use, +and for a dsa_switch structure, which represents one switch in a DSA +cluster. The switch then registers with the DSA framework using +dsa_switch_register(). + +dsa_switch_register() looks in the platform data and finds the +position within the cluster for the switch which is registering. The +switches dsa_switch structure is then attached to the dsa_switch_tree +structure in the correct place. + +Once all slave switches have registered, dsa_setup_dst() is used to +complete the construction of the dsa_switch_tree structure. This +starts by setting up switches which are not slave devices. The MDIO +address of the switch is passed to each switch driver to see if it can +drive the switch. If it can, a dsa_switch structure is allocated to +represent the switch and linked into the dsa_switch_tree at the +correct location. + PHY devices and link management -------------------------------
With the introduction of switches as linux devices and the use of the component framework, probing has become more complex. Add some documentation. Signed-off-by: Andrew Lunn <andrew@lunn.ch> --- Documentation/networking/dsa/dsa.txt | 48 ++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)