Re: [RFC PATCH 14/16] net: dsa: Add new binding implementation

2016-05-28 Thread Richard Cochran
On Fri, May 27, 2016 at 02:29:04PM -0700, Florian Fainelli wrote: > We need to set priorities here, and the highest priority is to get these > patches accepted to enable more people to utilize DSA, so once we have > more devices we can get to a longer term plan to get a better > abstraction model

Re: [RFC PATCH 14/16] net: dsa: Add new binding implementation

2016-05-27 Thread Florian Fainelli
On 05/27/2016 01:57 PM, Andrew Lunn wrote: > On Fri, May 27, 2016 at 04:39:05PM -0400, Vivien Didelot wrote: >> >> Hi Andrew, Florian, >> >> Here again, I'd suggested an implicit namespace for functions taking a >> dsa_switch_tree structure as first argument, i.e. dsa_tree_do_foo(). > > Using

Re: [RFC PATCH 14/16] net: dsa: Add new binding implementation

2016-05-27 Thread Andrew Lunn
On Fri, May 27, 2016 at 04:39:05PM -0400, Vivien Didelot wrote: > > Hi Andrew, Florian, > > Here again, I'd suggested an implicit namespace for functions taking a > dsa_switch_tree structure as first argument, i.e. dsa_tree_do_foo(). Using tree actually makes things worse, since tree is never

Re: [RFC PATCH 14/16] net: dsa: Add new binding implementation

2016-05-27 Thread Vivien Didelot
Hi Andrew, Florian, Here again, I'd suggested an implicit namespace for functions taking a dsa_switch_tree structure as first argument, i.e. dsa_tree_do_foo(). Since we are likely to spend some time in net/dsa, it'd be great to introduce the new bindings and an intuitive API at the same time

[RFC PATCH 14/16] net: dsa: Add new binding implementation

2016-05-26 Thread Andrew Lunn
The existing DSA binding has a number of limitations and problems. The main problem is that it cannot represent a switch as a linux device, hanging off some bus. It is limited to one CPU port. The DSA platform device is artificial, and does not really represent hardware. Implement a new binding