On Tue, Jul 20, 2010 at 11:54 PM, Lennert Buytenhek <buyt...@wantstofly.org> wrote: > On Tue, Jul 20, 2010 at 11:28:19PM +0200, Karl Beldan wrote: > >> >> 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? > Yes, Micrel - ksz8863.
>> >> 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? >> >> 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. > > 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. > Not rely on it of course, but let the code handle it. > (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.) > > >> 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. > The blackfin tree has a dsa driver for ksz8893, it is the only out-of-tree one I have seen so far. CCed them, I hope it is the right ML. >> > > 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. >> >> 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. > Yeah, ... I know it too much. -- Karl _______________________________________________ Uclinux-dist-devel mailing list Uclinux-dist-devel@blackfin.uclinux.org https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
