netdev - Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55368CF5.4080900@gmail.com>
Date:	Tue, 21 Apr 2015 10:46:29 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
CC:	Jan Kaisrlik <kaisrja1@....cvut.cz>, sojkam1@....cvut.cz,
	tkonecny@...ia.cz, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jan Kaisrlik <ja.kaisrlik@...il.com>
Subject: Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB
 RMII interface.

On 21/04/15 10:30, Andrew Lunn wrote:
>> 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):
> 
> We are hijacking another thread, but...
> 
> I don't understand you here. Who calls dsa_switch_register()?

Any driver which is backing the underlying device, if this is a PCI(e)
switch, a pci_driver's probe function gets called, and then registers
with DSA a switch device, very much like this:

https://github.com/ffainelli/linux/commit/f94efc3d7b489955351c01efeafcc89939df388e

> 
> I know of a board coming soon which has three switch chips on
> it. There is one MDIO device in the Soc, but there is an external MDIO
> multiplexor controlled via gpio lines, such that each switch has its
> own MDIO bus. The DT binding does not support this currently, but the
> underlying data structures do.
> 
> How do you envisage dsa_switch_register() to work in such a setup?

I would envision something where we can scan all of these switches
individually using their respective device drivers, with the help of
Device Tree or platform_data, figure out which position in a
dsa_switch_tree they should have, and make sure that we create a
dsa_switch_tree which reflects that, taking probe ordering into account.
All of these switches would be phy_driver instances, like this:
https://github.com/ffainelli/linux/commit/4a5c6b17de36377f6a71423b91f80bc1c7fee7be

We can keep discussing the details in a separate thread, I think that
would be useful.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html