* Re: [PATCH V13 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: John Stultz @ 2011-03-28 18:07 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel, linux-api, netdev, devicetree-discuss,
linux-arm-kernel, linuxppc-dev, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner, Benjamin Herrenschmidt,
Mike Frysinger, Paul Mackerras, Russell King
In-Reply-To: <120e586f678230c5f7d6dcfe70aa4483c2d50bf5.1301206090.git.richard.cochran@omicron.at>
On Sun, 2011-03-27 at 08:38 +0200, Richard Cochran wrote:
> The eTSEC includes a PTP clock with quite a few features. This patch adds
> support for the basic clock adjustment functions, plus two external time
> stamps, one alarm, and the PPS callback.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Acked-by: John Stultz <john.stultz@linaro.org>
^ permalink raw reply
* Re: [PATCH V13 1/4] ptp: Added a brand new class driver for ptp clocks.
From: John Stultz @ 2011-03-28 18:06 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, Krzysztof Halasa, Peter Zijlstra,
Rodolfo Giometti, Thomas Gleixner, Benjamin Herrenschmidt,
Mike Frysinger, Paul Mackerras, Russell King
In-Reply-To: <86641738e4c84fbdb105d6f2eb6141d5d13c3190.1301206090.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Sun, 2011-03-27 at 08:38 +0200, Richard Cochran wrote:
> This patch adds an infrastructure for hardware clocks that implement
> IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
> registration method to particular hardware clock drivers. Each clock is
> presented as a standard POSIX clock.
>
> The ancillary clock features are exposed in two different ways, via
> the sysfs and by a character device.
>
> Signed-off-by: Richard Cochran <richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
Acked-by: John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
thanks
-john
^ permalink raw reply
* Re: poll broken (for can)
From: Oliver Hartkopp @ 2011-03-28 17:53 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger
In-Reply-To: <4D90B3B0.2010401-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 28.03.2011 18:13, Marc Kleine-Budde wrote:
> On 03/28/2011 05:55 PM, Wolfgang Grandegger wrote:
>>> BTW: I figured out why poll() wakes you up but the next write will fail
>>> with -ENOBUFS again.
>>
>> Ah, I'm curious? I also did realize that poll does burn CPU cycles
>> (instead of waiting).
>
> The poll callback checks if the used memory is less than the half of per
> socket snd buffer (IIRC ~60K). See:
>
> datagram_poll (http://lxr.linux.no/linux+v2.6.38/net/core/datagram.c#L737)
> sock_writeable (http://lxr.linux.no/linux+v2.6.38/include/net/sock.h#L1618)
>
> Because the size of a can frame (+the skb overhead) is much less then
> the ethernet frame (+overhead) the default value for the snd buffer is
> too big for can.
>
> We get the -ENOBUF from write() if the tx_queue_len (default 10) is
> exceeded.
>
> http://lxr.linux.no/linux+v2.6.38/drivers/net/can/dev.c#L435
> http://lxr.linux.no/linux+v2.6.38/net/can/af_can.c#L268
>
What would be your suggestion? Decreasing the socket send buffer for CAN by
default?
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH] cxgb3: Apply interrupt coalescing settings to all queues
From: Divy Le Ray @ 2011-03-28 17:41 UTC (permalink / raw)
To: Anton Blanchard; +Cc: netdev
In-Reply-To: <20110328135041.57cec646@kryten>
On 03/27/2011 07:50 PM, Anton Blanchard wrote:
>
>
> While testing the performance of different receive interrupt
> coalescing settings on a single stream TCP benchmark, I noticed two
> very different results. With rx-usecs=50, most of the time a
> connection would hit 8280 Mbps but once in a while it would hit
> 9330 Mbps.
>
> It turns out we are only applying the interrupt coalescing settings
> to the first queue and whenever the rx hash would direct us onto
> that queue we ran faster.
>
> With this patch applied and rx-usecs=50, I get 9330 Mbps
> consistently.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> Index: powerpc.git/drivers/net/cxgb3/cxgb3_main.c
> ===================================================================
> --- powerpc.git.orig/drivers/net/cxgb3/cxgb3_main.c 2011-03-28
> 12:36:41.775206214 +1100
> +++ powerpc.git/drivers/net/cxgb3/cxgb3_main.c 2011-03-28
> 12:41:29.892189120 +1100
> @@ -1983,14 +1983,20 @@ static int set_coalesce(struct net_devic
> {
> struct port_info *pi = netdev_priv(dev);
> struct adapter *adapter = pi->adapter;
> - struct qset_params *qsp = &adapter->params.sge.qset[0];
> - struct sge_qset *qs = &adapter->sge.qs[0];
> + struct qset_params *qsp;
> + struct sge_qset *qs;
> + int i;
>
> if (c->rx_coalesce_usecs * 10 > M_NEWTIMER)
> return -EINVAL;
>
> - qsp->coalesce_usecs = c->rx_coalesce_usecs;
> - t3_update_qset_coalesce(qs, qsp);
> + for (i = 0; i < pi->nqsets; i++) {
> + qsp = &adapter->params.sge.qset[i];
> + qs = &adapter->sge.qs[i];
> + qsp->coalesce_usecs = c->rx_coalesce_usecs;
> + t3_update_qset_coalesce(qs, qsp);
> + }
> +
> return 0;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM
From: Ben Hutchings @ 2011-03-28 17:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Eric Dumazet, David Miller, Dan Carpenter, netdev,
kernel-janitors
In-Reply-To: <AANLkTi=Qkf2qn6nQ-6AXE8LtFSD++=eZRxa6ND6KPsk1@mail.gmail.com>
On Mon, 2011-03-28 at 17:46 +0200, Javier Martinez Canillas wrote:
> On Mon, Mar 28, 2011 at 2:25 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > 1) We dont believe its Janitor material ;)
> >
> > http://thread.gmane.org/gmane.linux.kernel/680723
> >
> > http://kerneltrap.org/mailarchive/linux-netdev/2009/4/6/5417754
> >
>
> I wasn't aware of this discussion. In one hand network drivers are not
> a good source of entropy because they can be controlled externally,
> but in embedded systems with only network cards (no video, audio,
> keyboard, etc) the only source of entropy they have is their network
> cards (at the kernel level i.e: not using EGD to feed /dev/random).
It may be the only source of entropy, but given how poor a source it is
these drivers are basically telling sweet little lies to the kernel and
the applications that demand real random numbers.
This also applies to many servers just as much as embedded systems.
As you acknowledge, these systems can still get entropy using the EGD
protocol over a secure channel. (Or an entropy sampling device such as
the Entropy Key.)
> Yes this definitely is not janitor material :)
>
> I just sent the patch because I saw IRQF_SAMPLE_RANDOM in
> Documentation/feature-removal-schedule.txt. I can resend a patch
> removing the macro in the remaining network cards if the decision is
> to remove IRQF_SAMPLE_RANDOM.
It's not my call, but I would support it.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: zero copy for relay server
From: Eric Dumazet @ 2011-03-28 16:52 UTC (permalink / raw)
To: Viral Mehta; +Cc: netdev@vger.kernel.org
In-Reply-To: <D69C90565D53114396BF743585AF5A09122E61E9E7@VSHINMSMBX01.vshodc.lntinfotech.com>
Le lundi 28 mars 2011 à 21:57 +0530, Viral Mehta a écrit :
> Hi,
> I am implementing a particular application where
> my application acts nothing but like Relay Server.
>
> Relay server accepts connection from machine A.
> It also accepts connection from Machine B.
>
> Machine A and B are on different LAN/subnnets.
> Now, there are two connections.
> What server is supposed to do is RECV packets from machine A and SEND same
> to machine B.
>
> Pseudo Code is something like,
> while(1)
> {
> recvagain:
> n =3D recv(incoming_fd, &buf, 8192, ...)
> if(n < 0)
> goto recvagain;
> send(outgoing_fd, &buf, n, ...);
> }
>
> Now the question is,
> I want to avoid kernel-user copy for such application.
> I found that a syscall like "sendfile"; I wanted to know if there is any
> similar thing exists in-kernel which can take 2 socket descriptors....
>
> If not, is it possible ? I would like to implement the same if someone
> can suggest some pointers.
linux way (if you want to avoid netfilter stuff and use userland code)
is to use splice() system call, and a pipe between two sockets.
/* skeleton : must add error checking to exit the loop properly */
int fds[2];
pipe(fds);
while (1) {
splice(incoming_fd, NULL, fds[1], NULL, 65536, 0);
splice(fds[0], NULL, outgoing_fd, NULL, 65536, 0);
}
This way, messages dont cross kernel<>user boundary.
The pipe is acting as a buffer between the two sockets.
^ permalink raw reply
* zero copy for relay server
From: Viral Mehta @ 2011-03-28 16:27 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
I am implementing a particular application where
my application acts nothing but like Relay Server.
Relay server accepts connection from machine A.
It also accepts connection from Machine B.
Machine A and B are on different LAN/subnnets.
Now, there are two connections.
What server is supposed to do is RECV packets from machine A and SEND same
to machine B.
Pseudo Code is something like,
while(1)
{
recvagain:
n =3D recv(incoming_fd, &buf, 8192, ...)
if(n < 0)
goto recvagain;
send(outgoing_fd, &buf, n, ...);
}
Now the question is,
I want to avoid kernel-user copy for such application.
I found that a syscall like "sendfile"; I wanted to know if there is any
similar thing exists in-kernel which can take 2 socket descriptors....
If not, is it possible ? I would like to implement the same if someone
can suggest some pointers.
Thanks,
Viral
The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. L&T Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail"
______________________________________________________________________
^ permalink raw reply
* poll broken (for can) (was: Re: Multiple programs trying to access the socket)
From: Marc Kleine-Budde @ 2011-03-28 16:13 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <4D90AF67.1080405-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1179 bytes --]
On 03/28/2011 05:55 PM, Wolfgang Grandegger wrote:
>> BTW: I figured out why poll() wakes you up but the next write will fail
>> with -ENOBUFS again.
>
> Ah, I'm curious? I also did realize that poll does burn CPU cycles
> (instead of waiting).
The poll callback checks if the used memory is less than the half of per
socket snd buffer (IIRC ~60K). See:
datagram_poll (http://lxr.linux.no/linux+v2.6.38/net/core/datagram.c#L737)
sock_writeable (http://lxr.linux.no/linux+v2.6.38/include/net/sock.h#L1618)
Because the size of a can frame (+the skb overhead) is much less then
the ethernet frame (+overhead) the default value for the snd buffer is
too big for can.
We get the -ENOBUF from write() if the tx_queue_len (default 10) is
exceeded.
http://lxr.linux.no/linux+v2.6.38/drivers/net/can/dev.c#L435
http://lxr.linux.no/linux+v2.6.38/net/can/af_can.c#L268
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM
From: Javier Martinez Canillas @ 2011-03-28 15:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Dan Carpenter, netdev, kernel-janitors
In-Reply-To: <1301315152.3182.19.camel@edumazet-laptop>
On Mon, Mar 28, 2011 at 2:25 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> 1) We dont believe its Janitor material ;)
>
> http://thread.gmane.org/gmane.linux.kernel/680723
>
> http://kerneltrap.org/mailarchive/linux-netdev/2009/4/6/5417754
>
I wasn't aware of this discussion. In one hand network drivers are not
a good source of entropy because they can be controlled externally,
but in embedded systems with only network cards (no video, audio,
keyboard, etc) the only source of entropy they have is their network
cards (at the kernel level i.e: not using EGD to feed /dev/random).
Yes this definitely is not janitor material :)
I just sent the patch because I saw IRQF_SAMPLE_RANDOM in
Documentation/feature-removal-schedule.txt. I can resend a patch
removing the macro in the remaining network cards if the decision is
to remove IRQF_SAMPLE_RANDOM.
Best regards,
-----------------------------------------
Javier Martínez Canillas
(+34) 682 39 81 69
PhD Student in High Performance Computing
Computer Architecture and Operating System Department (CAOS)
Universitat Autònoma de Barcelona
Barcelona, Spain
^ permalink raw reply
* Re: [RFC PATCH] rtl8187: Fix led support for rfkill
From: Herton Ronaldo Krzesinski @ 2011-03-28 15:40 UTC (permalink / raw)
To: Larry Finger
Cc: Hin-Tak Leung, wu zhangjin, Herton Ronaldo Krzesinski,
linux-wireless, netdev, Roman Mamedov
In-Reply-To: <4D8FBE88.3050907@lwfinger.net>
On Sun, Mar 27, 2011 at 05:47:36PM -0500, Larry Finger wrote:
> On 03/26/2011 07:55 PM, Hin-Tak Leung wrote:
> >wu zhangjin wrote:
> >>On Sun, Mar 27, 2011 at 5:33 AM, Hin-Tak Leung
> >><htl10@users.sourceforge.net> wrote:
> >>>Wu Zhangjin wrote:
> >>>>led can not be turned off normally when rfkill is blocked, the cause is
> >>>>the led_turn_off() function exit as not expected:
> >>>Hmm. While this sounds more sensible, is it needed? And what does the
> >>>windows driver do?
> >>>
> >>>I think there are two kind of LEDs - one that comes on and off with the
> >>>rfkill switch; Larry or Herton makes the 2nd one, if there is one, blink
> >>>while there is traffic (and stay steady on otherwise).
> >>
> >>I have used this driver on the YeeLoong netbook(only support Linux),
> >>there is only one LED for rtl8187, when there is traffic, it blinks
> >>perfectly, but If press the hotkey to turn off the rf, the network
> >>interface is down, but the LED is still light, then, the users may
> >>mistakenly think the hotkey or rfkill support doesn't work or simply
> >>think the interface is still on. So, that's why we may need to fix it.
> >
> >My laptop (a Toshiba one) has the other kind of LED - the LED only comes on and
> >off in relation to the rfkill switch, and does not blink with traffic. I think
> >Herton or Larry has some devices with both types.
I had one via based netbook with proper led, but don't have it anymore.
> >
> >Hmm, I seem to have the impression that there is code somewhere for switching a
> >singular LED's behavior of the driver between one or the other, by echo'ing into
> >sysfs or some other trickery? Or would that be a desired approach if that's not
> >done at the moment?
>
> My rtl8187 devices are both external USB sticks, thus they have no
> interaction with a radio-kill switch. I will test your patch to make
> sure it does no harm to my system.
>
> I think the commit message should be revised. A simple statement
> like "the LED does not turn off when the rfkill switch is off"
> should be sufficient.
The patch should work, but I wonder if we should be fiddling with priv->vif
for this, perhaps we should not assume vif to be valid after
rtl8187_remove_interface (I don't see problems with current
rtl8187/mac80211 code on a quick look, but...)
I cleaner solution may be to use a priv->mode like p54.
>
> Larry
>
--
[]'s
Herton
^ permalink raw reply
* Re: [PATCH] net: fix ethtool->set_flags not intended -EINVAL return value
From: Stanislaw Gruszka @ 2011-03-28 14:48 UTC (permalink / raw)
To: Jon Mason
Cc: netdev, Ben Hutchings, Eric Dumazet, Jesse Gross,
Amit Kumar Salecha, Shreyas Bhatewara, Jesper Dangaard Brouer
In-Reply-To: <20110328142155.GA26423@kudzu.us>
On Mon, Mar 28, 2011 at 09:21:57AM -0500, Jon Mason wrote:
> > - if (data & ~ETH_FLAG_RXHASH)
> > - return -EOPNOTSUPP;
> > + if (ethtool_invalid_flags(dev, data, ETH_FLAG_RXHASH))
> > + return -EINVAL;
>
> The return code value is being changed, which is not relevant to this
> patch. Perhaps a secondary patch should be created to make all driver
> set_flags calls return EOPNOTSUPP for unsupported flag setting.
Linux network developers agree some time ago that EINVAL should be used
in this case.
Stanislaw
^ permalink raw reply
* Re: [PATCH] net: fix ethtool->set_flags not intended -EINVAL return value
From: Jon Mason @ 2011-03-28 14:21 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: netdev, Ben Hutchings, Eric Dumazet, Jesse Gross,
Amit Kumar Salecha, Shreyas Bhatewara, Jesper Dangaard Brouer
In-Reply-To: <20110323095415.GA7098@redhat.com>
On Wed, Mar 23, 2011 at 10:54:49AM +0100, Stanislaw Gruszka wrote:
> After commit d5dbda23804156ae6f35025ade5307a49d1db6d7 "ethtool: Add
> support for vlan accleration.", drivers that have NETIF_F_HW_VLAN_TX,
> and/or NETIF_F_HW_VLAN_RX feature, but do not allow enable/disable vlan
> acceleration via ethtool set_flags, always return -EINVAL from that
> function. Fix by returning -EINVAL only if requested features do not
> match current settings and can not be changed by driver.
>
> Change any driver that define ethtool->set_flags to use
> ethtool_invalid_flags() to avoid similar problems in the future
> (also on drivers that do not have the problem).
>
> Tested with modified (to reproduce this bug) myri10ge driver.
>
> Cc: stable@kernel.org # 2.6.37+
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> drivers/net/netxen/netxen_nic_ethtool.c | 2 +-
> drivers/net/qlcnic/qlcnic_ethtool.c | 2 +-
> drivers/net/s2io.c | 2 +-
> drivers/net/vmxnet3/vmxnet3_ethtool.c | 4 ++--
> drivers/net/vxge/vxge-ethtool.c | 4 ++--
> include/linux/ethtool.h | 1 +
> net/core/ethtool.c | 17 ++++++++++++++++-
> 7 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/netxen/netxen_nic_ethtool.c b/drivers/net/netxen/netxen_nic_ethtool.c
> index 653d308..3bdcc80 100644
> --- a/drivers/net/netxen/netxen_nic_ethtool.c
> +++ b/drivers/net/netxen/netxen_nic_ethtool.c
> @@ -871,7 +871,7 @@ static int netxen_nic_set_flags(struct net_device *netdev, u32 data)
> struct netxen_adapter *adapter = netdev_priv(netdev);
> int hw_lro;
>
> - if (data & ~ETH_FLAG_LRO)
> + if (ethtool_invalid_flags(netdev, data, ETH_FLAG_LRO))
> return -EINVAL;
>
> if (!(adapter->capabilities & NX_FW_CAPABILITY_HW_LRO))
> diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
> index 4c14510..45b2755 100644
> --- a/drivers/net/qlcnic/qlcnic_ethtool.c
> +++ b/drivers/net/qlcnic/qlcnic_ethtool.c
> @@ -1003,7 +1003,7 @@ static int qlcnic_set_flags(struct net_device *netdev, u32 data)
> struct qlcnic_adapter *adapter = netdev_priv(netdev);
> int hw_lro;
>
> - if (data & ~ETH_FLAG_LRO)
> + if (ethtool_invalid_flags(netdev, data, ETH_FLAG_LRO))
> return -EINVAL;
>
> if (!(adapter->capabilities & QLCNIC_FW_CAPABILITY_HW_LRO))
> diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
> index 2ad6364..356e74d 100644
> --- a/drivers/net/s2io.c
> +++ b/drivers/net/s2io.c
> @@ -6726,7 +6726,7 @@ static int s2io_ethtool_set_flags(struct net_device *dev, u32 data)
> int rc = 0;
> int changed = 0;
>
> - if (data & ~ETH_FLAG_LRO)
> + if (ethtool_invalid_flags(dev, data, ETH_FLAG_LRO))
> return -EINVAL;
>
> if (data & ETH_FLAG_LRO) {
> diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c
> index 81254be..51f2ef1 100644
> --- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
> +++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
> @@ -304,8 +304,8 @@ vmxnet3_set_flags(struct net_device *netdev, u32 data)
> u8 lro_present = (netdev->features & NETIF_F_LRO) == 0 ? 0 : 1;
> unsigned long flags;
>
> - if (data & ~ETH_FLAG_LRO)
> - return -EOPNOTSUPP;
> + if (ethtool_invalid_flags(netdev, data, ETH_FLAG_LRO))
> + return -EINVAL;
>
> if (lro_requested ^ lro_present) {
> /* toggle the LRO feature*/
> diff --git a/drivers/net/vxge/vxge-ethtool.c b/drivers/net/vxge/vxge-ethtool.c
> index 1dd3a21..c5eb034 100644
> --- a/drivers/net/vxge/vxge-ethtool.c
> +++ b/drivers/net/vxge/vxge-ethtool.c
> @@ -1117,8 +1117,8 @@ static int vxge_set_flags(struct net_device *dev, u32 data)
> struct vxgedev *vdev = netdev_priv(dev);
> enum vxge_hw_status status;
>
> - if (data & ~ETH_FLAG_RXHASH)
> - return -EOPNOTSUPP;
> + if (ethtool_invalid_flags(dev, data, ETH_FLAG_RXHASH))
> + return -EINVAL;
The return code value is being changed, which is not relevant to this
patch. Perhaps a secondary patch should be created to make all driver
set_flags calls return EOPNOTSUPP for unsupported flag setting.
Aside from that, it looks fine to me.
>
> if (!!(data & ETH_FLAG_RXHASH) == vdev->devh->config.rth_en)
> return 0;
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index aac3e2e..e22b046 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -643,6 +643,7 @@ int ethtool_op_set_ufo(struct net_device *dev, u32 data);
> u32 ethtool_op_get_flags(struct net_device *dev);
> int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported);
> void ethtool_ntuple_flush(struct net_device *dev);
> +bool ethtool_invalid_flags(struct net_device *dev, u32 data, u32 supported);
>
> /**
> * ðtool_ops - Alter and report network device settings
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index c1a71bb..25d1ea2 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -141,9 +141,24 @@ u32 ethtool_op_get_flags(struct net_device *dev)
> }
> EXPORT_SYMBOL(ethtool_op_get_flags);
>
> +/* Check if device can enable (or disable) particular feature coded in "data"
> + * argument. Flags "supported" describe features that can be toggled by device.
> + * If feature can not be toggled, it state (enabled or disabled) must match
> + * hardcoded device features state, otherwise flags are marked as invalid.
> + */
> +bool ethtool_invalid_flags(struct net_device *dev, u32 data, u32 supported)
> +{
> + u32 features = dev->features & flags_dup_features;
> + /* "data" can contain only flags_dup_features bits,
> + * see __ethtool_set_flags */
> +
> + return (features & ~supported) != (data & ~supported);
> +}
> +EXPORT_SYMBOL(ethtool_invalid_flags);
> +
> int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported)
> {
> - if (data & ~supported)
> + if (ethtool_invalid_flags(dev, data, supported))
> return -EINVAL;
>
> dev->features = ((dev->features & ~flags_dup_features) |
> --
> 1.7.1
>
^ permalink raw reply
* [PATCH]: linux-firmware: add myri10ge firmware
From: Andrew Gallatin @ 2011-03-28 13:43 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, Stanislaw Gruszka
Hi,
I have prepared a binary diff (hopefully correctly this time)
which adds the myri10ge firmware to the linux-firmware tree.
Due to the large size, I've uploaded the patch to the following URL
rather than attaching it:
http://www.myri.com/staff/gallatin/fw/0001-linux-firmware-add-myri10ge-firmware.patch
Thanks to sgruszka@redhat.com for teaching me how to properly prepare
the patch.
Drew
^ permalink raw reply
* RE: smatch stuff: use after free bug
From: Yevgeny Petrilin @ 2011-03-28 12:34 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110328103140.GJ1885@bicker>
> Subject: smatch stuff: use after free bug
>
> Smatch complains about this. It's not obvious to me how to fix it.
> The
> bug was introduced in b12d93d63 "mlx4: Add support for promiscuous mode
> in the new steering model.".
Thanks,
Will send a fix.
Yevgeny
^ permalink raw reply
* Re: [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM
From: Eric Dumazet @ 2011-03-28 12:25 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: David Miller, Dan Carpenter, netdev, kernel-janitors
In-Reply-To: <1301314543-3666-1-git-send-email-martinez.javier@gmail.com>
Le lundi 28 mars 2011 à 14:15 +0200, Javier Martinez Canillas a écrit :
> This flag is scheduled for removal so we shouldn't used it.
>
> Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
> ---
> v2: Initialize flags to zero suggested by Dan Carpenter.
>
> drivers/net/tg3.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
1) We dont believe its Janitor material ;)
http://thread.gmane.org/gmane.linux.kernel/680723
http://kerneltrap.org/mailarchive/linux-netdev/2009/4/6/5417754
2) If removal is accepted, we should patch all drivers at once
drivers/net/xen-netfront.c:1419: IRQF_SAMPLE_RANDOM, netdev->name,
drivers/net/cris/eth_v10.c:495: IRQF_SAMPLE_RANDOM, cardname, (void *)dev)) {
drivers/net/ibmlana.c:785: result = request_irq(priv->realirq, irq_handler, IRQF_SHARED | IRQF_SAMPLE_RANDOM, dev->name, dev);
drivers/net/qla3xxx.c:3471: unsigned long irq_flags = IRQF_SAMPLE_RANDOM | IRQF_SHARED;
drivers/net/netxen/netxen_nic_main.c:908: unsigned long flags = IRQF_SAMPLE_RANDOM;
drivers/net/atlx/atl1.c:2575: int irq_flags = IRQF_SAMPLE_RANDOM;
drivers/net/macb.c:1174: err = request_irq(dev->irq, macb_interrupt, IRQF_SAMPLE_RANDOM,
drivers/net/bcm63xx_enet.c:843: IRQF_SAMPLE_RANDOM | IRQF_DISABLED, dev->name, dev);
drivers/net/niu.c:6075: IRQF_SHARED | IRQF_SAMPLE_RANDOM,
drivers/net/tg3.c:8842: flags = IRQF_SAMPLE_RANDOM;
^ permalink raw reply
* [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM
From: Javier Martinez Canillas @ 2011-03-28 12:15 UTC (permalink / raw)
To: David Miller
Cc: Dan Carpenter, netdev, kernel-janitors, Javier Martinez Canillas
This flag is scheduled for removal so we shouldn't used it.
Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
---
v2: Initialize flags to zero suggested by Dan Carpenter.
drivers/net/tg3.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5135655..7adbf63 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8839,12 +8839,12 @@ static int tg3_request_irq(struct tg3 *tp, int irq_num)
fn = tg3_msi;
if (tp->tg3_flags2 & TG3_FLG2_1SHOT_MSI)
fn = tg3_msi_1shot;
- flags = IRQF_SAMPLE_RANDOM;
+ flags = 0;
} else {
fn = tg3_interrupt;
if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
fn = tg3_interrupt_tagged;
- flags = IRQF_SHARED | IRQF_SAMPLE_RANDOM;
+ flags = IRQF_SHARED;
}
return request_irq(tnapi->irq_vec, fn, flags, name, tnapi);
@@ -8875,7 +8875,7 @@ static int tg3_test_interrupt(struct tg3 *tp)
}
err = request_irq(tnapi->irq_vec, tg3_test_isr,
- IRQF_SHARED | IRQF_SAMPLE_RANDOM, dev->name, tnapi);
+ IRQF_SHARED, dev->name, tnapi);
if (err)
return err;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag
From: Patrick McHardy @ 2011-03-28 11:30 UTC (permalink / raw)
To: Changli Gao
Cc: Feng Gao, netdev, Eric Dumazet, Netfilter Developer Mailing List
In-Reply-To: <AANLkTimOzYG4Weh7wanYfU_qBM4tJDPz+zJZQx_H-vn0@mail.gmail.com>
On 26.03.2011 14:36, Changli Gao wrote:
> On Wed, Mar 23, 2011 at 6:49 PM, Feng Gao <kernel.goter@gmail.com> wrote:
>> Hello everyone:
>>
>> PC(A)-linux(B)-PC(C)
>> computer(linux B) with two net interface,eth0 and eth1.
>> PC(A) send syn to PC(C) though linux B.
>> then PC(C) replay a big packet with RST flag(use tcpsic or other tools).
>>
>> This RST packet(1480) come in from eth0(mtu 1500) and go out from
>> eth1(mtu 700), so this RST packet should fragment.
>>
>> BUT in tcp_packet func: if the connection has no reply packet,and
>> receive the RST packet.ip_conntrack should destroy.
>> if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
>> /* If only reply is a RST, we can consider ourselves not to
>> have an established connection: this is a fairly common
>> problem case, so we can delete the conntrack
>> immediately. --RR */
>> if (th->rst) {
>> nf_ct_kill_acct(ct, ctinfo, skb);
>> return NF_ACCEPT;
>> }
>> }
>>
>> BUT the skb->nfct is not set NULL in func nf_ct_kill_acct.
>> so when this RST packet goto ip_fragment,ip_fragment call nf_copy, in
>> __nf_copy func
>> the fragment skb->nfct point to the destory mem.
>> dst->nfct = src->nfct;
>> nf_conntrack_get(src->nfct);
>>
>> SO finally.kfree_skb call destroy_conntrack again. this may result in
>> LINUX B kernel panic.
>>
>
> Have you ever tested that? I am afraid no panic will happen.
> nf_ct_kill_acct() just drops the reference owned by the corresponding
> timeout timer to the ct if the timer is installed, so the skb still
> has the reference to the ct after nf_ct_kill_acct() returns. Thanks.
That's correct, the skb's reference is refcounted seperately and
only dropped at the final kfree_skb().
^ permalink raw reply
* smatch stuff: use after free bug
From: Dan Carpenter @ 2011-03-28 10:31 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: netdev
Smatch complains about this. It's not obvious to me how to fix it. The
bug was introduced in b12d93d63 "mlx4: Add support for promiscuous mode
in the new steering model.".
drivers/net/mlx4/mcg.c +530
remove_promisc_qp(89) warn: 'pqp' was already freed.
526 out_mailbox:
527 mlx4_free_cmd_mailbox(dev, mailbox);
528 out_list:
529 if (back_to_list)
530 list_add_tail(&pqp->list, &s_steer->promisc_qps[steer]);
^^^^^^^^^^
This list was deleted and pqp was freed at this point.
531 out_mutex:
532 mutex_unlock(&priv->mcg_table.mutex);
533 return err;
534 }
regards,
dan carpenter
^ permalink raw reply
* [PATCH v2] netdev: bfin_mac: document TE setting in RMII modes
From: Mike Frysinger @ 2011-03-28 8:33 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel
In-Reply-To: <1301296649-25603-1-git-send-email-vapier@gentoo.org>
The current code sometimes generates build warnings due to how it checks
the silicon revision, so clean it up and properly document things.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
v2
- fix thinko -- retain the bf536/bf537 check
drivers/net/bfin_mac.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index 22abfb3..68d45ba 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -1237,8 +1237,17 @@ static int bfin_mac_enable(struct phy_device *phydev)
if (phydev->interface == PHY_INTERFACE_MODE_RMII) {
opmode |= RMII; /* For Now only 100MBit are supported */
-#if (defined(CONFIG_BF537) || defined(CONFIG_BF536)) && CONFIG_BF_REV_0_2
- opmode |= TE;
+#if defined(CONFIG_BF537) || defined(CONFIG_BF536)
+ if (__SILICON_REVISION__ < 3) {
+ /*
+ * This isn't publicly documented (fun times!), but in
+ * silicon <=0.2, the RX and TX pins are clocked together.
+ * So in order to recv, we must enable the transmit side
+ * as well. This will cause a spurious TX interrupt too,
+ * but we can easily consume that.
+ */
+ opmode |= TE;
+ }
#endif
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH] netdev: bfin_mac: document TE setting in RMII modes
From: Mike Frysinger @ 2011-03-28 7:17 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel
The current code sometimes generates build warnings due to how it checks
the silicon revision, so clean it up and properly document things.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/bfin_mac.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index 22abfb3..0c68816 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -1237,9 +1237,16 @@ static int bfin_mac_enable(struct phy_device *phydev)
if (phydev->interface == PHY_INTERFACE_MODE_RMII) {
opmode |= RMII; /* For Now only 100MBit are supported */
-#if (defined(CONFIG_BF537) || defined(CONFIG_BF536)) && CONFIG_BF_REV_0_2
- opmode |= TE;
-#endif
+ if (__SILICON_REVISION__ < 3) {
+ /*
+ * This isn't publicly documented (fun times!), but in
+ * silicon <=0.2, the RX and TX pins are clocked together.
+ * So in order to recv, we must enable the transmit side
+ * as well. This will cause a spurious TX interrupt too,
+ * but we can easily consume that.
+ */
+ opmode |= TE;
+ }
}
/* Turn on the EMAC rx */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] solos-pci: Don't include pseudo-header in dump of frame
From: Philip Prindeville @ 2011-03-28 7:01 UTC (permalink / raw)
To: Netdev; +Cc: Karl Hiramoto, Nathan Williams, chas williams - CONTRACTOR
From: Philip Prindeville <philipp@redfish-solutions.com>
Don't include pseudo-header as part of frame hex-dump on transmit. We can pull-up the "struct pkt_hdr" at the
beginning of the sk_buff because it's already been used, and shouldn't be included in the output of print_buffer(),
which is the last operation we'll do on the contents of this buffer before releasing it.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
---
drivers/atm/solos-pci.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 2c4146a..968f022 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -697,7 +697,7 @@ void solos_bh(unsigned long card_arg)
size);
}
if (atmdebug) {
- dev_info(&card->dev->dev, "Received: device %d\n", port);
+ dev_info(&card->dev->dev, "Received: port %d\n", port);
dev_info(&card->dev->dev, "size: %d VPI: %d VCI: %d\n",
size, le16_to_cpu(header->vpi),
le16_to_cpu(header->vci));
@@ -1018,8 +1018,15 @@ static uint32_t fpga_tx(struct solos_card *card)
/* Clean up and free oldskb now it's gone */
if (atmdebug) {
+ struct pkt_hdr *header = (void *)oldskb->data;
+ int size = le16_to_cpu(header->size);
+
+ skb_pull(oldskb, sizeof(*header));
dev_info(&card->dev->dev, "Transmitted: port %d\n",
port);
+ dev_info(&card->dev->dev, "size: %d VPI: %d VCI: %d\n",
+ size, le16_to_cpu(header->vpi),
+ le16_to_cpu(header->vci));
print_buffer(oldskb);
}
^ permalink raw reply related
* [PATCH 1/2] solos-pci: Use VPI.VCI notation consistently throughout module
From: Philip Prindeville @ 2011-03-28 6:56 UTC (permalink / raw)
To: Netdev; +Cc: chas williams - CONTRACTOR, Nathan Williams, Karl Hiramoto
From: Philip Prindeville <philipp@redfish-solutions.com>
Use VPI.VCI notation consistently throughout the module. This is the one remaining place where the VCI
is used before the VPI in any output.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
---
drivers/atm/solos-pci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 25ef1a4..2c4146a 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -710,8 +710,8 @@ void solos_bh(unsigned long card_arg)
le16_to_cpu(header->vci));
if (!vcc) {
if (net_ratelimit())
- dev_warn(&card->dev->dev, "Received packet for unknown VCI.VPI %d.%d on port %d\n",
- le16_to_cpu(header->vci), le16_to_cpu(header->vpi),
+ dev_warn(&card->dev->dev, "Received packet for unknown VPI.VCI %d.%d on port %d\n",
+ le16_to_cpu(header->vpi), le16_to_cpu(header->vci),
port);
continue;
}
^ permalink raw reply related
* [PATCH 0/2] solos-pci: debugging fixes
From: Philip Prindeville @ 2011-03-28 6:55 UTC (permalink / raw)
To: Netdev; +Cc: chas williams - CONTRACTOR, Nathan Williams, Karl Hiramoto
From: Philip Prindeville <philipp@redfish-solutions.com>
Two patches for net-2.6 HEAD:
The first changes the one remaining instance where the VCI (virtual circuit identifier) is output before the VPI (virtual path identifier). Standard notation is VPI *then* VCI, and this is used everywhere else.
The second does a "pull" on the sk_buff to remove the "struct pkt_hdr" that prefaces the actual ATM frame data (and includes message type, message size, and VPI/VCI tuple). Logging is the last thing done before releasing the sk_buff, so the header can safely be pulled up at this point. Also, we alternate between using the term "device" and "port" in the driver, which is inconsistent and confusing. So we also change the term "device" to "port".
^ permalink raw reply
* Re: [PATCH] netxen: fix LRO disable warning
From: David Miller @ 2011-03-28 6:31 UTC (permalink / raw)
To: sgruszka
Cc: amit.salecha, eric.dumazet, netdev, ameen.rahman, rajesh.borundia
In-Reply-To: <20110328051744.GA2275@redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon, 28 Mar 2011 07:17:46 +0200
> Patch is here:
> http://patchwork.ozlabs.org/patch/88060/
>
> I could also repost rebased patch if needed.
Not necessary, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] solos-pci:Don't include pseudo-header in dump of frame
From: David Miller @ 2011-03-28 6:30 UTC (permalink / raw)
To: philipp_subx; +Cc: netdev
In-Reply-To: <4D901AF2.2040503@redfish-solutions.com>
From: Philip Prindeville <philipp_subx@redfish-solutions.com>
Date: Sun, 27 Mar 2011 22:21:54 -0700
> Don't include pseudo-header as part of frame hex-dump on transmit.
Don't add this indentation in your commit messages, please.
> Signed-off-by: Philip Prindeville<philipp@redfish-solutions.com>
Also, where is the respun patch #1?
This is getty real tiring.
We have extensive documentation about how to submit patches
properly, you can start with Documentation/SubmittingPatches
in the kernel sources.
When I ask you to make changes to a patch series, resubmit
everything because I'm just going to mark whatever you submitted
already as "Changes Requested".
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox