Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Tue, Jul 7, 2015 at 9:17 AM, Vivien Didelot wrote: > Hi Andrew, Scott, > Does this fixup http://ix.io/jxq look good to you? Yes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Tue, Jul 07, 2015 at 12:17:57PM -0400, Vivien Didelot wrote: > Hi Andrew, Scott, > Does this fixup http://ix.io/jxq look good to you? Yes, that looks good. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
Hi Andrew, Scott,
On Jul 6, 2015, at 11:46 PM, Scott Feldman sfel...@gmail.com wrote:
> On Mon, Jul 6, 2015 at 7:00 PM, Andrew Lunn wrote:
>> On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
>>> On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
>>> > Hi all,
>>> >
>>> > This patchset brings full support for hardware VLANs in DSA, and the
>>> > Marvell
>>> > 88E6xxx compatible switch chips.
>>>
>>> Hi Vivien
>>>
>>> I just booted these patches on my board, and i'm getting WARNINGS:
>>>
>>> [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
>>> switchdev_port_obj_add+0xd4/0xdc()
>>
>> Hi Vivien
>>
>> I debugged this a bit.
>>
>> The problem comes from:
>>
>> static int dsa_slave_port_obj_add(struct net_device *dev,
>> struct switchdev_obj *obj)
>> {
>> int err;
>>
>> /*
>> * Skip the prepare phase, since currently the DSA drivers don't
>> need to
>> * allocate any memory for operations and they will not fail to HW
>> * (unless something horrible goes wrong on the MDIO bus, in which
>> case
>> * the prepare phase wouldn't have been able to predict anyway).
>> */
>> if (obj->trans != SWITCHDEV_TRANS_COMMIT)
>> return 0;
>>
>> switch (obj->id) {
>> case SWITCHDEV_OBJ_PORT_VLAN:
>> err = dsa_slave_port_vlans_add(dev, obj);
>> break;
>> default:
>> err = -EOPNOTSUPP;
>> break;
>> }
>>
>> return err;
>> }
>>
>> It is being called with obj->id of 2, which is
>> SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
>> it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
>> error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
>> allowed.
>>
>> EOPNOTSUPP is considered an error, so since we don't support
>> SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
>>
>> Not sure which is cleaner. Test to see if we support the object during
>> the prepare, or allow the commit to accept EOPNOTSUPP as not being an
>> error?
>
> I think we should return EOPNOTSUPP on PREPARE, so move the trans !=
> COMMIT test inside the case for PORT_VLAN. That would future-proof
> the func when new objects are added to switchdev (and not supported by
> dsa_slave).
Does this fixup http://ix.io/jxq look good to you?
Thanks,
-v
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
Hi Andrew, Scott,
On Jul 6, 2015, at 11:46 PM, Scott Feldman sfel...@gmail.com wrote:
On Mon, Jul 6, 2015 at 7:00 PM, Andrew Lunn and...@lunn.ch wrote:
On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
Hi all,
This patchset brings full support for hardware VLANs in DSA, and the
Marvell
88E6xxx compatible switch chips.
Hi Vivien
I just booted these patches on my board, and i'm getting WARNINGS:
[ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
switchdev_port_obj_add+0xd4/0xdc()
Hi Vivien
I debugged this a bit.
The problem comes from:
static int dsa_slave_port_obj_add(struct net_device *dev,
struct switchdev_obj *obj)
{
int err;
/*
* Skip the prepare phase, since currently the DSA drivers don't
need to
* allocate any memory for operations and they will not fail to HW
* (unless something horrible goes wrong on the MDIO bus, in which
case
* the prepare phase wouldn't have been able to predict anyway).
*/
if (obj-trans != SWITCHDEV_TRANS_COMMIT)
return 0;
switch (obj-id) {
case SWITCHDEV_OBJ_PORT_VLAN:
err = dsa_slave_port_vlans_add(dev, obj);
break;
default:
err = -EOPNOTSUPP;
break;
}
return err;
}
It is being called with obj-id of 2, which is
SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
allowed.
EOPNOTSUPP is considered an error, so since we don't support
SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
Not sure which is cleaner. Test to see if we support the object during
the prepare, or allow the commit to accept EOPNOTSUPP as not being an
error?
I think we should return EOPNOTSUPP on PREPARE, so move the trans !=
COMMIT test inside the case for PORT_VLAN. That would future-proof
the func when new objects are added to switchdev (and not supported by
dsa_slave).
Does this fixup http://ix.io/jxq look good to you?
Thanks,
-v
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Tue, Jul 07, 2015 at 12:17:57PM -0400, Vivien Didelot wrote: Hi Andrew, Scott, Does this fixup http://ix.io/jxq look good to you? Yes, that looks good. Andrew -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Tue, Jul 7, 2015 at 9:17 AM, Vivien Didelot vivien.dide...@savoirfairelinux.com wrote: Hi Andrew, Scott, Does this fixup http://ix.io/jxq look good to you? Yes. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Mon, Jul 6, 2015 at 7:00 PM, Andrew Lunn wrote:
> On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
>> On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
>> > Hi all,
>> >
>> > This patchset brings full support for hardware VLANs in DSA, and the
>> > Marvell
>> > 88E6xxx compatible switch chips.
>>
>> Hi Vivien
>>
>> I just booted these patches on my board, and i'm getting WARNINGS:
>>
>> [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
>> switchdev_port_obj_add+0xd4/0xdc()
>
> Hi Vivien
>
> I debugged this a bit.
>
> The problem comes from:
>
> static int dsa_slave_port_obj_add(struct net_device *dev,
> struct switchdev_obj *obj)
> {
> int err;
>
> /*
> * Skip the prepare phase, since currently the DSA drivers don't need
> to
> * allocate any memory for operations and they will not fail to HW
> * (unless something horrible goes wrong on the MDIO bus, in which
> case
> * the prepare phase wouldn't have been able to predict anyway).
> */
> if (obj->trans != SWITCHDEV_TRANS_COMMIT)
> return 0;
>
> switch (obj->id) {
> case SWITCHDEV_OBJ_PORT_VLAN:
> err = dsa_slave_port_vlans_add(dev, obj);
> break;
> default:
> err = -EOPNOTSUPP;
> break;
> }
>
> return err;
> }
>
> It is being called with obj->id of 2, which is
> SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
> it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
> error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
> allowed.
>
> EOPNOTSUPP is considered an error, so since we don't support
> SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
>
> Not sure which is cleaner. Test to see if we support the object during
> the prepare, or allow the commit to accept EOPNOTSUPP as not being an
> error?
I think we should return EOPNOTSUPP on PREPARE, so move the trans !=
COMMIT test inside the case for PORT_VLAN. That would future-proof
the func when new objects are added to switchdev (and not supported by
dsa_slave).
Does that sound OK?
-scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
> On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
> > Hi all,
> >
> > This patchset brings full support for hardware VLANs in DSA, and the Marvell
> > 88E6xxx compatible switch chips.
>
> Hi Vivien
>
> I just booted these patches on my board, and i'm getting WARNINGS:
>
> [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
> switchdev_port_obj_add+0xd4/0xdc()
Hi Vivien
I debugged this a bit.
The problem comes from:
static int dsa_slave_port_obj_add(struct net_device *dev,
struct switchdev_obj *obj)
{
int err;
/*
* Skip the prepare phase, since currently the DSA drivers don't need
to
* allocate any memory for operations and they will not fail to HW
* (unless something horrible goes wrong on the MDIO bus, in which case
* the prepare phase wouldn't have been able to predict anyway).
*/
if (obj->trans != SWITCHDEV_TRANS_COMMIT)
return 0;
switch (obj->id) {
case SWITCHDEV_OBJ_PORT_VLAN:
err = dsa_slave_port_vlans_add(dev, obj);
break;
default:
err = -EOPNOTSUPP;
break;
}
return err;
}
It is being called with obj->id of 2, which is
SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
allowed.
EOPNOTSUPP is considered an error, so since we don't support
SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
Not sure which is cleaner. Test to see if we support the object during
the prepare, or allow the commit to accept EOPNOTSUPP as not being an
error?
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote: > Hi all, > > This patchset brings full support for hardware VLANs in DSA, and the Marvell > 88E6xxx compatible switch chips. Hi Vivien I just booted these patches on my board, and i'm getting WARNINGS: [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265 switchdev_port_obj_add+0xd4/0xdc() [ 61.119602] lan0: Commit of object (id=2) failed. [ 61.123007] Modules linked in: [ 61.124790] CPU: 0 PID: 2751 Comm: ip Tainted: GW 4.2.0-rc1-00029-g5b5313438cfd #187 [ 61.132484] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 61.137622] Backtrace: [ 61.138817] [<80012ecc>] (dump_backtrace) from [<80013118>] (show_stack+0x20/0x24) [ 61.145123] r6:804e3aa4 r5:0009 r4: r3: [ 61.149616] [<800130f8>] (show_stack) from [<804ea2e0>] (dump_stack+0x24/0x28) [ 61.155562] [<804ea2bc>] (dump_stack) from [<8001e4b0>] (warn_slowpath_common+0x98/0xc4) [ 61.162411] [<8001e418>] (warn_slowpath_common) from [<8001e51c>] (warn_slowpath_fmt+0x40/0x48) [ 61.169843] r8:0020 r7: r6:87b4d000 r5:ffa1 r4:80647708 [ 61.175345] [<8001e4e0>] (warn_slowpath_fmt) from [<804e3aa4>] (switchdev_port_obj_add+0xd4/0xdc) [ 61.182950] r3:87b4d000 r2:80647708 [ 61.185255] r4:870b3abc [ 61.186525] [<804e39d0>] (switchdev_port_obj_add) from [<804e3b9c>] (switchdev_fib_ipv4_add+0x90/0xbc) [ 61.194564] r6:0003 r5:0c00 r4:87243d80 [ 61.197949] [<804e3b0c>] (switchdev_fib_ipv4_add) from [<80491f8c>] (fib_table_insert+0x1cc/0x4cc) [ 61.205642] r7:870b3b60 r6:c0a80d00 r5:87108794 r4: [ 61.210125] [<80491dc0>] (fib_table_insert) from [<8048ce58>] (fib_magic.isra.18+0xdc/0xf0) [ 61.217169] r10:8717c6c0 r9:871c9b00 r8:0020 r7:000da8c0 r6:0018 r5:040da8c0 [ 61.223812] r4:0003 [ 61.225089] [<8048cd7c>] (fib_magic.isra.18) from [<8048defc>] (fib_add_ifaddr+0x150/0x1a0) [ 61.232168] r9:87243a00 r8:87a4 r7:040da8c0 r6:00ff r5:000da8c0 r4:87243a00 [ 61.238712] [<8048ddac>] (fib_add_ifaddr) from [<8048e500>] (fib_inetaddr_event+0x84/0xc4) [ 61.245707] r9: r8: r7: r6:87a4 r5:0001 r4:87243a00 [ 61.252284] [<8048e47c>] (fib_inetaddr_event) from [<8003892c>] (notifier_call_chain+0x54/0x94) [ 61.259716] r6:0001 r5:87243a00 r4: r3:8048e47c [ 61.264159] [<800388d8>] (notifier_call_chain) from [<80038cd8>] (__blocking_notifier_call_chain+0x58/0x70) [ 61.272633] r9:871c9b00 r8:871c9b0c r7:0001 r6:87243a00 r5:8071a720 r4: [ 61.279176] [<80038c80>] (__blocking_notifier_call_chain) from [<80038d18>] (blocking_notifier_call_chain+0x28/0x30) [ 61.288428] r7:00c5 r6:87243a00 r5:871c9000 r4:0abf [ 61.292901] [<80038cf0>] (blocking_notifier_call_chain) from [<80483674>] (__inet_insert_ifa+0x18c/0x238) [ 61.301219] [<804834e8>] (__inet_insert_ifa) from [<80484c24>] (inet_rtm_newaddr+0x188/0x3d0) [ 61.308439] r9: r8: r7:87243a00 r6:8717c6c0 r5:871c9000 r4: [ 61.315022] [<80484a9c>] (inet_rtm_newaddr) from [<80438130>] (rtnetlink_rcv_msg+0x188/0x228) [ 61.322275] r9: r8: r7:0002 r6:8717c6c0 r5:871c9000 r4:0030 [ 61.328818] [<80437fa8>] (rtnetlink_rcv_msg) from [<8044a4b0>] (netlink_rcv_skb+0xb0/0xcc) [ 61.335815] r8: r7:8717c6c0 r6:8717c6c0 r5:80437fa8 r4:871c9000 [ 61.341353] [<8044a400>] (netlink_rcv_skb) from [<80437fa0>] (rtnetlink_rcv+0x34/0x3c) [ 61.347968] r6:8709c400 r5:0038 r4:8717c6c0 r3:80437f6c [ 61.352446] [<80437f6c>] (rtnetlink_rcv) from [<80449e74>] (netlink_unicast+0x174/0x1f4) [ 61.359235] r4:878d3c00 r3:80437f6c [ 61.361596] [<80449d00>] (netlink_unicast) from [<8044a2f0>] (netlink_sendmsg+0x334/0x348) [ 61.368560] r8: r7:0038 r6: r5:8709c400 r4:870b3f4c [ 61.374100] [<80449fbc>] (netlink_sendmsg) from [<8040e928>] (sock_sendmsg+0x24/0x34) [ 61.380662] r10: r9:870b3e30 r8: r7:8773e3c0 r6: r5: [ 61.387269] r4:870b3f4c [ 61.388545] [<8040e904>] (sock_sendmsg) from [<8040f294>] (___sys_sendmsg+0x1dc/0x1e4) [ 61.395218] [<8040f0b8>] (___sys_sendmsg) from [<8040ffe8>] (__sys_sendmsg+0x4c/0x7c) [ 61.401782] r9:870b2000 r8:8000fa44 r7:0128 r6:7e9169b4 r5: r4:8773e3c0 [ 61.408331] [<8040ff9c>] (__sys_sendmsg) from [<80410030>] (SyS_sendmsg+0x18/0x1c) [ 61.414630] r6:7e9169a0 r5:0010 r4:000c [ 61.418019] [<80410018>] (SyS_sendmsg) from [<8000f8a0>] (ret_fast_syscall+0x0/0x3c) [ 61.424494] ---[ end trace 6a5447143fac0dcb ]--- This is with -rc1. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote: Hi all, This patchset brings full support for hardware VLANs in DSA, and the Marvell 88E6xxx compatible switch chips. Hi Vivien I just booted these patches on my board, and i'm getting WARNINGS: [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265 switchdev_port_obj_add+0xd4/0xdc() [ 61.119602] lan0: Commit of object (id=2) failed. [ 61.123007] Modules linked in: [ 61.124790] CPU: 0 PID: 2751 Comm: ip Tainted: GW 4.2.0-rc1-00029-g5b5313438cfd #187 [ 61.132484] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 61.137622] Backtrace: [ 61.138817] [80012ecc] (dump_backtrace) from [80013118] (show_stack+0x20/0x24) [ 61.145123] r6:804e3aa4 r5:0009 r4: r3: [ 61.149616] [800130f8] (show_stack) from [804ea2e0] (dump_stack+0x24/0x28) [ 61.155562] [804ea2bc] (dump_stack) from [8001e4b0] (warn_slowpath_common+0x98/0xc4) [ 61.162411] [8001e418] (warn_slowpath_common) from [8001e51c] (warn_slowpath_fmt+0x40/0x48) [ 61.169843] r8:0020 r7: r6:87b4d000 r5:ffa1 r4:80647708 [ 61.175345] [8001e4e0] (warn_slowpath_fmt) from [804e3aa4] (switchdev_port_obj_add+0xd4/0xdc) [ 61.182950] r3:87b4d000 r2:80647708 [ 61.185255] r4:870b3abc [ 61.186525] [804e39d0] (switchdev_port_obj_add) from [804e3b9c] (switchdev_fib_ipv4_add+0x90/0xbc) [ 61.194564] r6:0003 r5:0c00 r4:87243d80 [ 61.197949] [804e3b0c] (switchdev_fib_ipv4_add) from [80491f8c] (fib_table_insert+0x1cc/0x4cc) [ 61.205642] r7:870b3b60 r6:c0a80d00 r5:87108794 r4: [ 61.210125] [80491dc0] (fib_table_insert) from [8048ce58] (fib_magic.isra.18+0xdc/0xf0) [ 61.217169] r10:8717c6c0 r9:871c9b00 r8:0020 r7:000da8c0 r6:0018 r5:040da8c0 [ 61.223812] r4:0003 [ 61.225089] [8048cd7c] (fib_magic.isra.18) from [8048defc] (fib_add_ifaddr+0x150/0x1a0) [ 61.232168] r9:87243a00 r8:87a4 r7:040da8c0 r6:00ff r5:000da8c0 r4:87243a00 [ 61.238712] [8048ddac] (fib_add_ifaddr) from [8048e500] (fib_inetaddr_event+0x84/0xc4) [ 61.245707] r9: r8: r7: r6:87a4 r5:0001 r4:87243a00 [ 61.252284] [8048e47c] (fib_inetaddr_event) from [8003892c] (notifier_call_chain+0x54/0x94) [ 61.259716] r6:0001 r5:87243a00 r4: r3:8048e47c [ 61.264159] [800388d8] (notifier_call_chain) from [80038cd8] (__blocking_notifier_call_chain+0x58/0x70) [ 61.272633] r9:871c9b00 r8:871c9b0c r7:0001 r6:87243a00 r5:8071a720 r4: [ 61.279176] [80038c80] (__blocking_notifier_call_chain) from [80038d18] (blocking_notifier_call_chain+0x28/0x30) [ 61.288428] r7:00c5 r6:87243a00 r5:871c9000 r4:0abf [ 61.292901] [80038cf0] (blocking_notifier_call_chain) from [80483674] (__inet_insert_ifa+0x18c/0x238) [ 61.301219] [804834e8] (__inet_insert_ifa) from [80484c24] (inet_rtm_newaddr+0x188/0x3d0) [ 61.308439] r9: r8: r7:87243a00 r6:8717c6c0 r5:871c9000 r4: [ 61.315022] [80484a9c] (inet_rtm_newaddr) from [80438130] (rtnetlink_rcv_msg+0x188/0x228) [ 61.322275] r9: r8: r7:0002 r6:8717c6c0 r5:871c9000 r4:0030 [ 61.328818] [80437fa8] (rtnetlink_rcv_msg) from [8044a4b0] (netlink_rcv_skb+0xb0/0xcc) [ 61.335815] r8: r7:8717c6c0 r6:8717c6c0 r5:80437fa8 r4:871c9000 [ 61.341353] [8044a400] (netlink_rcv_skb) from [80437fa0] (rtnetlink_rcv+0x34/0x3c) [ 61.347968] r6:8709c400 r5:0038 r4:8717c6c0 r3:80437f6c [ 61.352446] [80437f6c] (rtnetlink_rcv) from [80449e74] (netlink_unicast+0x174/0x1f4) [ 61.359235] r4:878d3c00 r3:80437f6c [ 61.361596] [80449d00] (netlink_unicast) from [8044a2f0] (netlink_sendmsg+0x334/0x348) [ 61.368560] r8: r7:0038 r6: r5:8709c400 r4:870b3f4c [ 61.374100] [80449fbc] (netlink_sendmsg) from [8040e928] (sock_sendmsg+0x24/0x34) [ 61.380662] r10: r9:870b3e30 r8: r7:8773e3c0 r6: r5: [ 61.387269] r4:870b3f4c [ 61.388545] [8040e904] (sock_sendmsg) from [8040f294] (___sys_sendmsg+0x1dc/0x1e4) [ 61.395218] [8040f0b8] (___sys_sendmsg) from [8040ffe8] (__sys_sendmsg+0x4c/0x7c) [ 61.401782] r9:870b2000 r8:8000fa44 r7:0128 r6:7e9169b4 r5: r4:8773e3c0 [ 61.408331] [8040ff9c] (__sys_sendmsg) from [80410030] (SyS_sendmsg+0x18/0x1c) [ 61.414630] r6:7e9169a0 r5:0010 r4:000c [ 61.418019] [80410018] (SyS_sendmsg) from [8000f8a0] (ret_fast_syscall+0x0/0x3c) [ 61.424494] ---[ end trace 6a5447143fac0dcb ]--- This is with -rc1. Andrew -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
Hi all,
This patchset brings full support for hardware VLANs in DSA, and the Marvell
88E6xxx compatible switch chips.
Hi Vivien
I just booted these patches on my board, and i'm getting WARNINGS:
[ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
switchdev_port_obj_add+0xd4/0xdc()
Hi Vivien
I debugged this a bit.
The problem comes from:
static int dsa_slave_port_obj_add(struct net_device *dev,
struct switchdev_obj *obj)
{
int err;
/*
* Skip the prepare phase, since currently the DSA drivers don't need
to
* allocate any memory for operations and they will not fail to HW
* (unless something horrible goes wrong on the MDIO bus, in which case
* the prepare phase wouldn't have been able to predict anyway).
*/
if (obj-trans != SWITCHDEV_TRANS_COMMIT)
return 0;
switch (obj-id) {
case SWITCHDEV_OBJ_PORT_VLAN:
err = dsa_slave_port_vlans_add(dev, obj);
break;
default:
err = -EOPNOTSUPP;
break;
}
return err;
}
It is being called with obj-id of 2, which is
SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
allowed.
EOPNOTSUPP is considered an error, so since we don't support
SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
Not sure which is cleaner. Test to see if we support the object during
the prepare, or allow the commit to accept EOPNOTSUPP as not being an
error?
Andrew
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Mon, Jul 6, 2015 at 7:00 PM, Andrew Lunn and...@lunn.ch wrote:
On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
Hi all,
This patchset brings full support for hardware VLANs in DSA, and the
Marvell
88E6xxx compatible switch chips.
Hi Vivien
I just booted these patches on my board, and i'm getting WARNINGS:
[ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
switchdev_port_obj_add+0xd4/0xdc()
Hi Vivien
I debugged this a bit.
The problem comes from:
static int dsa_slave_port_obj_add(struct net_device *dev,
struct switchdev_obj *obj)
{
int err;
/*
* Skip the prepare phase, since currently the DSA drivers don't need
to
* allocate any memory for operations and they will not fail to HW
* (unless something horrible goes wrong on the MDIO bus, in which
case
* the prepare phase wouldn't have been able to predict anyway).
*/
if (obj-trans != SWITCHDEV_TRANS_COMMIT)
return 0;
switch (obj-id) {
case SWITCHDEV_OBJ_PORT_VLAN:
err = dsa_slave_port_vlans_add(dev, obj);
break;
default:
err = -EOPNOTSUPP;
break;
}
return err;
}
It is being called with obj-id of 2, which is
SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
allowed.
EOPNOTSUPP is considered an error, so since we don't support
SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
Not sure which is cleaner. Test to see if we support the object during
the prepare, or allow the commit to accept EOPNOTSUPP as not being an
error?
I think we should return EOPNOTSUPP on PREPARE, so move the trans !=
COMMIT test inside the case for PORT_VLAN. That would future-proof
the func when new objects are added to switchdev (and not supported by
dsa_slave).
Does that sound OK?
-scott
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
Hi all, This patchset brings full support for hardware VLANs in DSA, and the Marvell 88E6xxx compatible switch chips. The first patch adds the VTU operations to the mv88e6xxx code, as well as a "vtu" debugfs file to read and modify the hardware VLAN table. The second patch adds the glue between DSA and the switchdev VLAN objects. The third patch finally implements the necessary functions in the mv88e6xxx code to interact with the hardware VLAN through switchdev, from userspace commands such as "bridge vlan". Below is an example of what can be done with this patchset. "VID 550: 1t 3u" "VID 1000: 2t" "VID 1200: 2t 4t" The VLAN setup above can be achieved with the following bridge commands: bridge vlan add vid 550 dev swp1 master bridge vlan add vid 550 dev swp3 master untagged pvid bridge vlan add vid 1000 dev swp2 master bridge vlan add vid 1200 dev swp2 master bridge vlan add vid 1200 dev swp4 master Removing the port 1 from VLAN 550 is done with: bridge vlan del vid 550 dev swp1 The bridge command would output the following setup: # bridge vlan portvlan ids swp0None swp0 swp1None swp1 swp21000 1200 swp21000 1200 swp3550 PVID Egress Untagged swp3550 PVID Egress Untagged swp41200 swp41200 br0 None Assuming that swp5 is the CPU port, the "vtu" debugfs file would show: # cat /sys/kernel/debug/dsa0/vtu VID FID SID 0 1 2 3 4 5 6 550 550 0x x x u x t x 1000 1000 0x x t x x t x 1200 1200 0x x t x t t x Cheers, -v Vivien Didelot (3): net: dsa: mv88e6xxx: add debugfs interface for VTU net: dsa: add support for switchdev VLAN objects net: dsa: mv88e6xxx: add switchdev VLAN operations drivers/net/dsa/mv88e6123_61_65.c | 3 + drivers/net/dsa/mv88e6131.c | 3 + drivers/net/dsa/mv88e6171.c | 3 + drivers/net/dsa/mv88e6352.c | 3 + drivers/net/dsa/mv88e6xxx.c | 463 ++ drivers/net/dsa/mv88e6xxx.h | 29 +++ include/net/dsa.h | 9 + net/dsa/dsa_priv.h| 6 + net/dsa/slave.c | 137 +++ 9 files changed, 656 insertions(+) -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
Hi all, This patchset brings full support for hardware VLANs in DSA, and the Marvell 88E6xxx compatible switch chips. The first patch adds the VTU operations to the mv88e6xxx code, as well as a vtu debugfs file to read and modify the hardware VLAN table. The second patch adds the glue between DSA and the switchdev VLAN objects. The third patch finally implements the necessary functions in the mv88e6xxx code to interact with the hardware VLAN through switchdev, from userspace commands such as bridge vlan. Below is an example of what can be done with this patchset. VID 550: 1t 3u VID 1000: 2t VID 1200: 2t 4t The VLAN setup above can be achieved with the following bridge commands: bridge vlan add vid 550 dev swp1 master bridge vlan add vid 550 dev swp3 master untagged pvid bridge vlan add vid 1000 dev swp2 master bridge vlan add vid 1200 dev swp2 master bridge vlan add vid 1200 dev swp4 master Removing the port 1 from VLAN 550 is done with: bridge vlan del vid 550 dev swp1 The bridge command would output the following setup: # bridge vlan portvlan ids swp0None swp0 swp1None swp1 swp21000 1200 swp21000 1200 swp3550 PVID Egress Untagged swp3550 PVID Egress Untagged swp41200 swp41200 br0 None Assuming that swp5 is the CPU port, the vtu debugfs file would show: # cat /sys/kernel/debug/dsa0/vtu VID FID SID 0 1 2 3 4 5 6 550 550 0x x x u x t x 1000 1000 0x x t x x t x 1200 1200 0x x t x t t x Cheers, -v Vivien Didelot (3): net: dsa: mv88e6xxx: add debugfs interface for VTU net: dsa: add support for switchdev VLAN objects net: dsa: mv88e6xxx: add switchdev VLAN operations drivers/net/dsa/mv88e6123_61_65.c | 3 + drivers/net/dsa/mv88e6131.c | 3 + drivers/net/dsa/mv88e6171.c | 3 + drivers/net/dsa/mv88e6352.c | 3 + drivers/net/dsa/mv88e6xxx.c | 463 ++ drivers/net/dsa/mv88e6xxx.h | 29 +++ include/net/dsa.h | 9 + net/dsa/dsa_priv.h| 6 + net/dsa/slave.c | 137 +++ 9 files changed, 656 insertions(+) -- 2.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
