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:19 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.