From: Florian Fainelli <f.fainelli@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: netdev@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Gregory Clement <gregory.clement@free-electrons.com>,
Russell King <linux@armlinux.org.uk>,
Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
"David S. Miller" <davem@davemloft.net>,
"moderated list:ARM SUB-ARCHITECTURES"
<linux-arm-kernel@lists.infradead.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
Date: Sun, 15 Jan 2017 09:52:16 -0800 [thread overview]
Message-ID: <a9ea1f45-b9a5-d840-68e0-9bf9bc7a6598@gmail.com> (raw)
In-Reply-To: <20170115173949.GA19268@kroah.com>
On 01/15/2017 09:39 AM, Greg KH wrote:
> On Sun, Jan 15, 2017 at 09:27:22AM -0800, Florian Fainelli wrote:
>>
>>
>> On 01/15/2017 03:06 AM, Greg KH wrote:
>>> On Sat, Jan 14, 2017 at 01:47:09PM -0800, Florian Fainelli wrote:
>>>> Now that the base device driver code provides an identical
>>>> implementation of dev_find_class() utilize device_find_class() instead
>>>> of our own version of it.
>>>>
>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>> ---
>>>> net/dsa/dsa.c | 22 ++--------------------
>>>> 1 file changed, 2 insertions(+), 20 deletions(-)
>>>>
>>>> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
>>>> index 2306d1b87c83..77fa4c4f5828 100644
>>>> --- a/net/dsa/dsa.c
>>>> +++ b/net/dsa/dsa.c
>>>> @@ -455,29 +455,11 @@ EXPORT_SYMBOL_GPL(dsa_switch_resume);
>>>> #endif
>>>>
>>>> /* platform driver init and cleanup *****************************************/
>>>> -static int dev_is_class(struct device *dev, void *class)
>>>> -{
>>>> - if (dev->class != NULL && !strcmp(dev->class->name, class))
>>>> - return 1;
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static struct device *dev_find_class(struct device *parent, char *class)
>>>> -{
>>>> - if (dev_is_class(parent, class)) {
>>>> - get_device(parent);
>>>> - return parent;
>>>> - }
>>>> -
>>>> - return device_find_child(parent, class, dev_is_class);
>>>> -}
>>>> -
>>>> struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
>>>> {
>>>> struct device *d;
>>>>
>>>> - d = dev_find_class(dev, "mdio_bus");
>>>> + d = device_find_class(dev, "mdio_bus");
>>>> if (d != NULL) {
>>>> struct mii_bus *bus;
>>>
>>> You want a peer of your device on a specific class? What is this for?
>>
>> It's not a peer of our device, it's a separate device reference from the
>> one looked up in the "net" class. In the classic, and now deprecated DSA
>> device driver model, a "dsa" platform device would represent one or more
>> Ethernet switches, connected via a MDIO bus (this reference above), and
>> one Ethernet device (the CPU/host/management interface). This was
>> completely violating the Linux device driver model and imposed
>> limitations on what bus would be used, and we did not have proper struct
>> device references (therefore no adequate hierarchy either).
>>
>> Thanks to the work of Andrew, we now have proper MDIO, SPI, GPIO, I2C,
>> PCI, platform and drivers that allow us to register with DSA as a
>> specialized kind of device (so we are now finally using the right Linux
>> Device Driver model). What we still need though, in order to our switch
>> to the networking stack is a reference to the master/host network device
>> since we mangle packets in and out of it.
>
> Ok, but where in the tree are you trying to find this other device? Are
> you just going to randomly find any device that happens to be of the
> specific class type? That seems really fragile and broken :(
The search is not really random, since the platform data for the DSA
switch we want to register gives us a reference to a device registered
via any bus type, and we know (by contract it has to) that it has to
provide a network device of some kind, we do a specific search in the
"net" class for that purpose. I agree this is not great.
>
> You should NEVER have to walk the device tree to find stuff. Why can't
> you have a pointer to the device you need to talk to some other way?
We do, I think the existing code just tries to be extra careful here and
make sure that the device reference we got is actually part of the "net"
class, indicating that the reference passed is indeed pointing to a
network device, and not a random device.
>
> What exactly is the relationship between these devices (a ascii-art tree
> or sysfs tree output might be nice) so I can try to understand what is
> going on here.
OK, let me try and let's take the case of only one Ethernet switch in
the system for all simplicity:
- switch device drivers get probed by any kind of bus allocate and
register a dsa_switch with dsa_register_switch()
- this switch device has platform data (struct dsa_chip_data) that
describes its port layout (number of ports mostly) and has one struct
device references to which Ethernet network interface these ports connect to
- a dsa_switch_tree is created, this struct dsa_switch is attached to
the dsa_switch_tree at position 0 in the tree, we invoke a bunch of
switch driver operations
- we conclude with attaching this dsa_switch_tree to the network device
we looked up and assigning the tree to the dsa_ptr member
Documentation/networking/dsa/dsa.txt has some ascii art drawing that
sort of capture what is going on.
--
Florian
next prev parent reply other threads:[~2017-01-15 17:53 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-14 21:47 [PATCH net-next v3 00/10] net: dsa: Support for pdata in dsa2 Florian Fainelli
2017-01-14 21:47 ` [PATCH net-next v3 01/10] net: dsa: Pass device pointer to dsa_register_switch Florian Fainelli
2017-01-14 21:47 ` [PATCH net-next v3 02/10] net: dsa: Make most functions take a dsa_port argument Florian Fainelli
2017-01-14 21:47 ` [PATCH net-next v3 03/10] net: dsa: Suffix function manipulating device_node with _dn Florian Fainelli
2017-01-14 21:47 ` [PATCH net-next v3 04/10] net: dsa: Move ports assignment closer to error checking Florian Fainelli
2017-01-15 10:17 ` Sergei Shtylyov
2017-01-14 21:47 ` [PATCH net-next v3 05/10] drivers: base: Add device_find_class() Florian Fainelli
2017-01-15 11:04 ` Greg KH
2017-01-15 17:39 ` Florian Fainelli
2017-01-14 21:47 ` [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class() Florian Fainelli
2017-01-15 11:06 ` Greg KH
2017-01-15 17:27 ` Florian Fainelli
2017-01-15 17:39 ` Greg KH
2017-01-15 17:52 ` Florian Fainelli [this message]
2017-01-15 19:16 ` Andrew Lunn
2017-01-16 20:01 ` Florian Fainelli
2017-01-18 7:06 ` Greg KH
2017-01-19 14:28 ` Greg KH
2017-01-19 14:53 ` Andrew Lunn
2017-01-19 16:30 ` Greg KH
2017-01-19 16:35 ` Russell King - ARM Linux
2017-01-19 16:51 ` Russell King - ARM Linux
2017-01-19 18:12 ` Florian Fainelli
2017-01-24 18:59 ` Florian Fainelli
2017-01-25 21:25 ` Greg KH
2017-01-30 22:46 ` Florian Fainelli
2017-02-10 13:02 ` Greg KH
2017-02-10 18:30 ` Florian Fainelli
2017-02-12 12:56 ` Greg KH
2017-01-14 21:47 ` [PATCH net-next v3 07/10] net: Relocate dev_to_net_device() into core Florian Fainelli
2017-01-15 11:07 ` Greg KH
2017-01-15 17:20 ` Florian Fainelli
2017-01-15 17:40 ` Greg KH
2017-01-14 21:47 ` [PATCH net-next v3 08/10] net: dsa: Add support for platform data Florian Fainelli
2017-01-14 21:47 ` [PATCH net-next v3 09/10] net: phy: Allow pre-declaration of MDIO devices Florian Fainelli
2017-01-14 21:47 ` [PATCH net-next v3 10/10] ARM: orion: Register DSA switch as a MDIO device Florian Fainelli
2017-01-15 11:08 ` [PATCH net-next v3 00/10] net: dsa: Support for pdata in dsa2 Greg KH
2017-01-15 17:40 ` Florian Fainelli
2017-01-15 17:49 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9ea1f45-b9a5-d840-68e0-9bf9bc7a6598@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=vivien.didelot@savoirfairelinux.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®