From: Mugunthan V N <mugunthanvnm@ti.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
Date: Tue, 29 Jan 2013 18:03:13 +0530 [thread overview]
Message-ID: <5107C189.1050604@ti.com> (raw)
In-Reply-To: <20130129073626.GB18272@localhost.localdomain>
On 1/29/2013 1:06 PM, Richard Cochran wrote:
> On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
>> @@ -947,6 +1042,10 @@ static const struct net_device_ops cpsw_netdev_ops = {
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> .ndo_poll_controller = cpsw_ndo_poll_controller,
>> #endif
>> +#ifdef VLAN_SUPPORT
>> + .ndo_vlan_rx_add_vid = cpsw_ndo_vlan_rx_add_vid,
>> + .ndo_vlan_rx_kill_vid = cpsw_ndo_vlan_rx_kill_vid,
>> +#endif
> These are not compile time conditionals in net_device_ops, so I wonder
> (after reading Felipe's comments) whether you can simply keep the VLAN
> code always present.
>
> As long as the driver still compiles and loads, when VLAN is missing
> from the stack, then I don't see why you can't just leave it in,
> without all the ifdefs.
>
> Thanks,
> Richard
This idea seems to be good. I will update the patch in next version.
Regards
Mugunthan V N
WARNING: multiple messages have this Message-ID (diff)
From: mugunthanvnm@ti.com (Mugunthan V N)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
Date: Tue, 29 Jan 2013 18:03:13 +0530 [thread overview]
Message-ID: <5107C189.1050604@ti.com> (raw)
In-Reply-To: <20130129073626.GB18272@localhost.localdomain>
On 1/29/2013 1:06 PM, Richard Cochran wrote:
> On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
>> @@ -947,6 +1042,10 @@ static const struct net_device_ops cpsw_netdev_ops = {
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> .ndo_poll_controller = cpsw_ndo_poll_controller,
>> #endif
>> +#ifdef VLAN_SUPPORT
>> + .ndo_vlan_rx_add_vid = cpsw_ndo_vlan_rx_add_vid,
>> + .ndo_vlan_rx_kill_vid = cpsw_ndo_vlan_rx_kill_vid,
>> +#endif
> These are not compile time conditionals in net_device_ops, so I wonder
> (after reading Felipe's comments) whether you can simply keep the VLAN
> code always present.
>
> As long as the driver still compiles and loads, when VLAN is missing
> from the stack, then I don't see why you can't just leave it in,
> without all the ifdefs.
>
> Thanks,
> Richard
This idea seems to be good. I will update the patch in next version.
Regards
Mugunthan V N
WARNING: multiple messages have this Message-ID (diff)
From: Mugunthan V N <mugunthanvnm@ti.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
<linux-arm-kernel@lists.infradead.org>,
<linux-omap@vger.kernel.org>
Subject: Re: [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
Date: Tue, 29 Jan 2013 18:03:13 +0530 [thread overview]
Message-ID: <5107C189.1050604@ti.com> (raw)
In-Reply-To: <20130129073626.GB18272@localhost.localdomain>
On 1/29/2013 1:06 PM, Richard Cochran wrote:
> On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
>> @@ -947,6 +1042,10 @@ static const struct net_device_ops cpsw_netdev_ops = {
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> .ndo_poll_controller = cpsw_ndo_poll_controller,
>> #endif
>> +#ifdef VLAN_SUPPORT
>> + .ndo_vlan_rx_add_vid = cpsw_ndo_vlan_rx_add_vid,
>> + .ndo_vlan_rx_kill_vid = cpsw_ndo_vlan_rx_kill_vid,
>> +#endif
> These are not compile time conditionals in net_device_ops, so I wonder
> (after reading Felipe's comments) whether you can simply keep the VLAN
> code always present.
>
> As long as the driver still compiles and loads, when VLAN is missing
> from the stack, then I don't see why you can't just leave it in,
> without all the ifdefs.
>
> Thanks,
> Richard
This idea seems to be good. I will update the patch in next version.
Regards
Mugunthan V N
next prev parent reply other threads:[~2013-01-29 12:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-28 20:12 [PATCH 0/2] Add CPSW VLAN Support Mugunthan V N
2013-01-28 20:12 ` Mugunthan V N
2013-01-28 20:12 ` Mugunthan V N
2013-01-28 20:12 ` [PATCH 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation Mugunthan V N
2013-01-28 20:12 ` Mugunthan V N
2013-01-28 20:12 ` Mugunthan V N
2013-01-29 23:38 ` Cyril Chemparathy
2013-01-29 23:38 ` Cyril Chemparathy
2013-01-29 23:38 ` Cyril Chemparathy
2013-01-30 4:17 ` Mugunthan V N
2013-01-30 4:17 ` Mugunthan V N
2013-01-30 4:17 ` Mugunthan V N
2013-01-28 20:12 ` [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN Mugunthan V N
2013-01-28 20:12 ` Mugunthan V N
2013-01-28 20:12 ` Mugunthan V N
2013-01-28 20:44 ` Felipe Balbi
2013-01-28 20:44 ` Felipe Balbi
2013-01-28 20:44 ` Felipe Balbi
2013-01-29 5:05 ` Mugunthan V N
2013-01-29 5:05 ` Mugunthan V N
2013-01-29 5:05 ` Mugunthan V N
2013-01-29 7:21 ` Felipe Balbi
2013-01-29 7:21 ` Felipe Balbi
2013-01-29 7:21 ` Felipe Balbi
2013-01-29 7:36 ` Richard Cochran
2013-01-29 7:36 ` Richard Cochran
2013-01-29 12:33 ` Mugunthan V N [this message]
2013-01-29 12:33 ` Mugunthan V N
2013-01-29 12:33 ` Mugunthan V N
2013-01-29 9:48 ` Jan Lübbe
2013-01-29 9:48 ` Jan Lübbe
2013-01-29 12:09 ` Mugunthan V N
2013-01-29 12:09 ` Mugunthan V N
2013-01-29 12:09 ` Mugunthan V N
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5107C189.1050604@ti.com \
--to=mugunthanvnm@ti.com \
--cc=davem@davemloft.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.