net/dsa
Subsystems (2)
Hi,
I found the dsa code very handy to help manage a switch.
Yet I was surprised I had to tweak the code to simply use the phy layer state machine.
And I don't see much activity in the code nor any discussion, e.g no follow up to http://patchwork.ozlabs.org/patch/16578.
So I was wondering if there was anybody playing with this code, or having ideas about features to add (vlan/stp callbacks) ?
Karl
Quoted 1 line · Karl Beldan
Hi,
Hi Karl,
Sorry, I didn't see your mail initially -- please CC me in the future.
Quoted 1 line
I found the dsa code very handy to help manage a switch.
Ah. What particular part are you using?
Quoted 2 lines
Yet I was surprised I had to tweak the code to simply use the phy layer state machine.
You mean that net/dsa uses phy_attach() but not phy_start_machine() ? Have you seen problems arising from this?
Quoted 5 lines
And I don't see much activity in the code nor any discussion, e.g no follow up to http://patchwork.ozlabs.org/patch/16578.
So I was wondering if there was anybody playing with this code, or having ideas about features to add (vlan/stp callbacks) ?
As far as I know, the code currently in the kernel works well for what it intends to do (which is to just expose the switch ports), and I'm not aware of any bugs in it.
That said, you're right in that there are several more features that the hardware supports that the software could be extended to handle.
For one, I don't have access to any Marvell switch chip hardware anymore, so that limits my ability to play with this. Also, the relevant documentation is under a rather restrictive license, so the only way I can see net/dsa support for Marvell parts improving is if there's pressure from a large enough customer to make this happen.
If this is about non-Marvell parts, I'd welcome adding support for those into net/dsa. For one, I would really like to see Broadcom switch chip support added -- the documentation for those chips is under similarly restrictive licensing, though.
thanks,
Lennert
Quoted 4 lines · Lennert Buytenhek
Quoted 1 line · Karl Beldan
Hi,
Quoted 10 lines
Hi Karl,
Sorry, I didn't see your mail initially -- please CC me in the future.
Quoted 1 line
I found the dsa code very handy to help manage a switch.
Ah. What particular part are you using?
The whole thing but the cascading stuff.
I could even reuse a tagging format almost as is!
Quoted 7 lines
Quoted 2 lines
Yet I was surprised I had to tweak the code to simply use the phy layer state machine.
You mean that net/dsa uses
phy_attach()but notphy_start_machine()? Have you seen problems arising from this?
I did not mean that, but I do not think there would be a problem, since every in-tree driver provide their poll_link() to do the job of the phylib's state_queue, unless one does not provide its poll_link(), I guess this is what you had in mind.
What I had in mind in fact was the re-use of the phylib's interrupt based code, in this situation poll_link() is not there, but there replacing phy_attach() with phy_start_machine is not enough. Those are not big changes, but the code seems to aim at such versatile behavior (and more), I can only imagine it would be useful for the plethora of boards embedding a switch.
Quoted 10 lines
Quoted 5 lines
And I don't see much activity in the code nor any discussion, e.g no follow up to http://patchwork.ozlabs.org/patch/16578.
So I was wondering if there was anybody playing with this code, or having ideas about features to add (vlan/stp callbacks) ?
As far as I know, the code currently in the kernel works well for what it intends to do (which is to just expose the switch ports), and I'm not aware of any bugs in it.
Quoted 9 lines
That said, you're right in that there are several more features that the hardware supports that the software could be extended to handle.
For one, I don't have access to any Marvell switch chip hardware anymore, so that limits my ability to play with this. Also, the relevant documentation is under a rather restrictive license, so the only way I can see net/dsa support for Marvell parts improving is if there's pressure from a large enough customer to make this happen.
Now I understand, but still, I am surprised nobody else touched the code, with all those switches in the embedded business.
Quoted 6 lines
If this is about non-Marvell parts, I'd welcome adding support for those into net/dsa. For one, I would really like to see Broadcom switch chip support added -- the documentation for those chips is under similarly restrictive licensing, though.
Thanks,
Karl
Quoted 6 lines · Karl Beldan
Quoted 3 lines
Quoted 1 line
I found the dsa code very handy to help manage a switch.
Ah. What particular part are you using?
The whole thing but the cascading stuff.
I could even reuse a tagging format almost as is!
I meant, which silicon part, i.e. which hardware/chips? Anything with available data sheets?
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Yet I was surprised I had to tweak the code to simply use the phy layer state machine.
You mean that net/dsa uses
phy_attach()but notphy_start_machine()? Have you seen problems arising from this?
Quoted 7 lines
I did not mean that, but I do not think there would be a problem, since every in-tree driver provide their
poll_link()to do the job of the phylib'sstate_queue, unless one does not provide itspoll_link(), I guess this is what you had in mind.
What I had in mind in fact was the re-use of the phylib's interrupt based code, in this situationpoll_link()is not there, but there replacingphy_attach()withphy_start_machineis not enough.
We cannot rely on the switch's interrupt pin being hooked up -- there are many boards out where it's not wired up at all. Therefore, polling for link state changes is the only reliable and portable way.
(Of course, interrupt support can always be added, and that used instead of polling if a load-time test shows that the interrupt pin actually works.)
Quoted 3 lines
Those are not big changes, but the code seems to aim at such versatile behavior (and more), I can only imagine it would be useful for the plethora of boards embedding a switch.
Although it supports Marvell chips only for now, net/dsa was written to be able to handle other models of switch chips as well. As I said, I would love to see support for other switch chips added to it.
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
So I was wondering if there was anybody playing with this code, or having ideas about features to add (vlan/stp callbacks) ?
As far as I know, the code currently in the kernel works well for what it intends to do (which is to just expose the switch ports), and I'm not aware of any bugs in it.
That said, you're right in that there are several more features that the hardware supports that the software could be extended to handle.
Quoted 8 lines
Quoted 5 lines
For one, I don't have access to any Marvell switch chip hardware anymore, so that limits my ability to play with this. Also, the relevant documentation is under a rather restrictive license, so the only way I can see net/dsa support for Marvell parts improving is if there's pressure from a large enough customer to make this happen.
Now I understand, but still, I am surprised nobody else touched the code, with all those switches in the embedded business.
Me too..
..then again, "embedded people" tend to hack up stuff in private and ship whatever works -- they aren't exactly known for working with upstream.