From: Florian Fainelli <f.fainelli@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>, Jan Kaisrlik <kaisrja1@fel.cvut.cz>
Cc: sojkam1@fel.cvut.cz, tkonecny@retia.cz, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Jan Kaisrlik <ja.kaisrlik@gmail.com>
Subject: Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.
Date: Tue, 21 Apr 2015 10:18:31 -0700 [thread overview]
Message-ID: <55368667.5030105@gmail.com> (raw)
In-Reply-To: <20150421124737.GD32294@lunn.ch>
On 21/04/15 05:47, Andrew Lunn wrote:
> Hi Jan
>
> Interesting work, but i think the architecture is wrong.
>
> DSA needs an Ethernet device, an MDIO bus, and information about ports
> on the switch.
That requirement is completely artificial as it is today, and just comes
from arbitrary limitations imposed in the initial DSA design, something
that I am still trying to get away from.
> The MDIO bus and the Ethernet need no knowledge of
> DSA. So putting your DSA configuration code in the MDIO driver is
> wrong.
I agree with that.
>
> The problem you have is where the put the configuration data. There
> are the currently two choices, using a platform driver, which you can
> find some examples of in arch/arm/mach-orion5x, or via device tree. Or
> you need a new method.
>
> Part of your problem is hotplug, since you have a USB device, and no
> stable names for the ethernet device nor the MDIO device. Your
> hardware is not fixed, you could hang any switch off the USB
> device. So it does sound like you need a user space API.
>
> I would however say that sysfs is the wrong API. The linux network
> stack uses netlink for most configuration activities. So i would
> suggest adding a netlink binding to DSA, and place the code in
> net/dsa/, not within an MDIO driver.
I suppose we could do that, but that sounds like a pretty radical change
in how DSA is currently configured (that is statically at boot time),
part in order to allow booting from DSA-enabled network devices (e.g:
nfsroot).
>
> Device tree overlays might be a solution, if you can dynamically load
> a blob as part of a USB hotplug event. What makes it easier is that
> both the Ethernet device and MDIO bus are on the same USB device, so
> all your phandles are within the blob.
>
> What is your long term goal? Is this just a development tool? Are you
> thinking of making a product which integrates both the switch and the
> USB ethernet onto a USB dongle? This could also change the
> architecture, since it makes the configuration more fixed.
My goal in reworking this weird DSA device/driver model is that you
could just register your switch devices as an enhanced
phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers
could just take advantage of that when they scan/detect their MDIO buses
and find a switch. We are not quite there yet, but some help could be
welcome, here are the WIP patches (tested with platform_driver only so far):
https://github.com/ffainelli/linux/tree/dsa-model-b53
--
Florian
next prev parent reply other threads:[~2015-04-21 17:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-21 13:26 [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface Jan Kaisrlik
2015-04-21 12:47 ` Andrew Lunn
2015-04-21 17:18 ` Florian Fainelli [this message]
2015-04-21 17:30 ` Andrew Lunn
2015-04-21 17:46 ` Florian Fainelli
2015-04-21 17:39 ` Andrew Lunn
2015-04-21 17:51 ` Florian Fainelli
2015-04-22 16:14 ` Jan Kaisrlik
2015-04-22 16:39 ` Andrew Lunn
2015-04-21 13:26 ` [RFC PATCH 1/3] net/dsa: Refactor dsa_probe() Jan Kaisrlik
2015-04-21 16:58 ` Florian Fainelli
2015-04-21 13:26 ` [RFC PATCH 2/3] net/dsa: Allow probing dsa from usbnet Jan Kaisrlik
2015-04-22 7:15 ` rajeev kumar
2015-04-21 13:26 ` [RFC PATCH 3/3] driver/net/usb: Add support for DSA to ax88772b Jan Kaisrlik
2015-04-21 13:10 ` Bjørn Mork
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=55368667.5030105@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=ja.kaisrlik@gmail.com \
--cc=kaisrja1@fel.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sojkam1@fel.cvut.cz \
--cc=tkonecny@retia.cz \
/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;
as well as URLs for NNTP newsgroup(s).