* Re: [PATCH] net: phy: smsc: Implement PHY config_init for LAN87xx
From: Otavio Salvador @ 2012-09-27 18:21 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, Christian Hohnstaedt, David S. Miller, Fabio Estevam,
Giuseppe Cavallaro
In-Reply-To: <1348604262-21522-1-git-send-email-marex@denx.de>
On Tue, Sep 25, 2012 at 5:17 PM, Marek Vasut <marex@denx.de> wrote:
> The LAN8710/LAN8720 chips do have broken the "FlexPWR" smart power-saving
> capability. Enabling it leads to the PHY not being able to detect Link when
> cold-started without cable connected. Thus, make sure this is disabled.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* RE: [PATCH] net: ti cpsw ethernet: set IFCTL_A bit in MACCONTROL
From: N, Mugunthan V @ 2012-09-27 18:40 UTC (permalink / raw)
To: Daniel Mack, netdev@vger.kernel.org; +Cc: Hiremath, Vaibhav, David S. Miller
In-Reply-To: <1348746636-24156-1-git-send-email-zonque@gmail.com>
> -----Original Message-----
> From: Daniel Mack [mailto:zonque@gmail.com]
> Sent: Thursday, September 27, 2012 5:21 PM
> To: netdev@vger.kernel.org
> Cc: Daniel Mack; N, Mugunthan V; Hiremath, Vaibhav; David S. Miller
> Subject: [PATCH] net: ti cpsw ethernet: set IFCTL_A bit in MACCONTROL
>
> For RMII/RGMII mode operation in 100Mbps, the CPSW needs to set the
> IFCTL_A bits in the MACCONTROL register. For all other PHY modes, this
> bit is unused, so setting it unconditionally shouldn't cause any
> trouble.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> Cc: Mugunthan V N <mugunthanvnm@ti.com>
> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/ti/cpsw.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c
> b/drivers/net/ethernet/ti/cpsw.c
> index aa78168..b764f75 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -386,6 +386,11 @@ static void _cpsw_adjust_link(struct cpsw_slave
> *slave,
> mac_control |= BIT(7); /* GIGABITEN */
> if (phy->duplex)
> mac_control |= BIT(0); /* FULLDUPLEXEN */
> +
> + /* set speed_in input in case RMII mode is used in >10Mbps
> */
> + if (phy->speed > 10)
Please change the speed check as == 100 as it is required only for 100Mbps link
Regards
Mugunthan V N
> + mac_control |= BIT(15);
> +
> *link = true;
> } else {
> mac_control = 0;
> --
> 1.7.11.4
^ permalink raw reply
* [PATCH v2] net: ti cpsw ethernet: set IFCTL_A bit in MACCONTROL
From: Daniel Mack @ 2012-09-27 19:19 UTC (permalink / raw)
To: netdev; +Cc: Daniel Mack, Mugunthan V N, Vaibhav Hiremath, David S. Miller
For RMII/RGMII mode operation in 100Mbps, the CPSW needs to set the
IFCTL_A bits in the MACCONTROL register. For all other PHY modes, this
bit is unused, so setting it unconditionally shouldn't cause any
trouble.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/net/ethernet/ti/cpsw.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index aa78168..fb1a692 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -386,6 +386,11 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
mac_control |= BIT(7); /* GIGABITEN */
if (phy->duplex)
mac_control |= BIT(0); /* FULLDUPLEXEN */
+
+ /* set speed_in input in case RMII mode is used in 100Mbps */
+ if (phy->speed == 100)
+ mac_control |= BIT(15);
+
*link = true;
} else {
mac_control = 0;
--
1.7.11.4
^ permalink raw reply related
* Re: mlx4: dropping multicast packets at promisc leave
From: Marcelo Ricardo Leitner @ 2012-09-27 20:37 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev, Yevgeny Petrilin, Amir Vadai
In-Reply-To: <505CB2BD.4080402@redhat.com>
On 09/21/2012 03:32 PM, Marcelo Ricardo Leitner wrote:
> On 09/20/2012 12:04 PM, Marcelo Ricardo Leitner wrote:
>> On 09/20/2012 10:21 AM, Or Gerlitz wrote:
>>> On 20/09/2012 03:43, Marcelo Ricardo Leitner wrote:
>>>> I have a report that our mlx4 driver (RHEL 6.3) is dropping multicast
>>>> packets when NIC leaves promisc mode. It seems this is being cause due
>>>> to the new steering mode that took place near by commit
>>>> 1679200f91da6a054b06954c9bd3eeed29b6731f. As it seems, the new
>>>> steering mode needs more commands/time to leave the promisc mode,
>>>> which may be leading to packet drops.
>>>
>>> Marcelo,
>>>
>>> The commit you point on below 6d19993 "net/mlx4_en: Re-design multicast
>>> attachments flow" makes sure to avoid
>>> doing extra firmware comments and not leave a window in time where
>>> "correct" addresses are not attached. Its hard to say what's the case on
>>> that RHEL 6.3 system, it would be very helpful through if you manage to
>>> reproduce the problem on an upstream kernel -- BTW you didn't say on
>>
>> Okay, I understand that the commit prevents a window. I may be missing
>> something, but isn't there another one in there? Between:
>> mlx4_SET_MCAST_FLTR MLX4_MCAST_DISABLE and
>> mlx4_SET_MCAST_FLTR MLX4_MCAST_ENABLE
>> because mlx4_multicast_promisc_remove() was called just before those.
>> Otherwise I don't how is the NIC would be receiving multicast packets in
>> there.
>>
> ....
>> And then I tried 3 additional patches applied at once:
>> - 60d31c1475f2 "net/mlx4_core: Looking for promiscuous entries on the
>> correct port"
>> - f1f75f0 - mlx4: attach multicast with correct flag
>> - Yes, this one wasn't in 2.6.32-279.el6.
>> - 6d19993 - net/mlx4_en: Re-design multicast attachments flow
>>
>> And they still reported drops.
Well, neither me nor they could reproduce the drops at promisc exit
anymore. It's hard to chase a ghost, you know. I'll still track that cpu
usage, but it seems unrelated to the driver at first glance.
Thank you for your support Or, appreciated.
Regards,
Marcelo
^ permalink raw reply
* Re: mlx4: dropping multicast packets at promisc leave
From: Or Gerlitz @ 2012-09-27 20:45 UTC (permalink / raw)
To: mleitner; +Cc: netdev, Yevgeny Petrilin, Amir Vadai
In-Reply-To: <5064B905.6090906@redhat.com>
On Thu, Sep 27, 2012 at 10:37 PM, Marcelo Ricardo Leitner
<mleitner@redhat.com> wrote:
> Well, neither me nor they could reproduce the drops at promisc exit anymore.
> It's hard to chase a ghost, you know. I'll still track that cpu usage, but
> it seems unrelated to the driver at first glance.
>
> Thank you for your support Or, appreciated.
sure
^ permalink raw reply
* Re: Possible networking regression in 3.6.0
From: Eric Dumazet @ 2012-09-27 21:03 UTC (permalink / raw)
To: Chris Clayton; +Cc: netdev, gpiez
In-Reply-To: <50649567.2010704@googlemail.com>
On Thu, 2012-09-27 at 19:05 +0100, Chris Clayton wrote:
> On 09/27/12 13:14, Eric Dumazet wrote:
> > On Thu, 2012-09-27 at 12:50 +0100, Chris Clayton wrote:
> >> Just for information - I've pulled Linus' tree this morning and the
> >> problem is still present. Also, Gunther Piaz has reported, via the
> >> bugzilla entry, that he too has hit this regression.
> >
> > I tried to reproduce the bug, and my kvm guests have no problem.
> >
> > I guess you need to precisely describe how you setup your network, so
> > that I can reproduce the problem and eventually fix it.
> >
>
> You've seen the bits from my firewall setup script that relate to this
> issue. I start the WinXP client with another script:
>
> #!/bin/sh
> if [ -e $HOME/kvm/var/run/kvm-winxp.pid ]; then
> echo "winxp is already running ..." > /dev/stderr
> exit 1
> fi
>
> # make sure the kvm modules are loaded
> if test -z "$(grep '\<kvm\>' /proc/misc)"; then
> sudo modprobe kvm-intel
> while test -z "$(grep '\<kvm\>' /proc/misc)"; do
> true
> done
> fi
>
> # make sure tun module is loaded
> if test ! -e /dev/net/tun; then
> sudo modprobe tun
> fi
>
> # figure out the cpu to use
> QVER=$(qemu-kvm --version | cut -d' ' -f 4 | sed 's/,/./')
> # assumes major version is 1
> MINORVER=$(echo $QVER | cut -d'.' -f 2)
> if [ $MINORVER -ge 1 ]; then
> CPU="host"
> else
> CPU="qemu64"
> fi
>
> # set up the network interface
> TAPDEV=$(sudo tunctl -b -u $(whoami))
> sudo ifconfig $TAPDEV 192.168.200.254 netmask 255.255.255.0 broadcast
> 192.168.200.255
>
> # start Windows XP
> qemu-kvm -drive file=$HOME/kvm/winxp.qcow2,index=0,cache=none,if=virtio
> -cpu $CPU -smp cores=1,threads=2 -soundhw es1370 \
> -m 768 -net nic,model=virtio,macaddr=$(getmacaddr) -net
> tap,ifname=$TAPDEV -startdate $(date +%Y-%m-%dT%H:%M:%S) \
> -name kxplaptop -pidfile $HOME/kvm/var/run/kvm-winxp.pid $*
>
> # stop the network interface
> sudo ifconfig $TAPDEV down
> sudo tunctl -d $TAPDEV &>/dev/null
>
> # tidy up
> rm -f $HOME/kvm/var/run/kvm-winxp.pid
>
>
> The call to getmacaddr just returns the next in a sequence of mac
> addresses. qemu-kvm is a symlink to /usr/bin/qemu-system-i386. I first
> found the problem whilst running qemu-kvm version 1.1.1 although I've
> since updated to 1.2.0.
>
> By the way, I doubt it will make a difference, but, although my laptop
> has a 64bit CPU, I am running a 32 bit kernel and, obviously, user space.
>
> Let me know if you need anything else.
It works for me.
Hmm, maybe your guest is using DHCP and DHCP fails ?
Could you check ?
^ permalink raw reply
* Netfilter lacks ability to filter packets via Application-origin
From: Chad Gray @ 2012-09-27 21:04 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <COL002-W8067088C0C0B4682A10A0F39B0@phx.gbl>
Users need the ability for Linux firewall to filter packets based on what
Application they are originating from. This ability is present in Mac and
Windows firewalls, but not Linux.
For example, users would like ability to open Port 80 for Firefox, but keep
Port 80 closed for other applications.
This ability enhances Privacy & Security of the user but also helps to better
inform the user about the comings and goings of internet traffic and what
application/s are causing the traffic.
https://bugzilla.kernel.org/show_bug.cgi?id=47531
^ permalink raw reply
* Re: Possible networking regression in 3.6.0
From: Eric Dumazet @ 2012-09-27 21:17 UTC (permalink / raw)
To: Chris Clayton, David Miller; +Cc: netdev, gpiez
In-Reply-To: <1348779826.5093.1750.camel@edumazet-glaptop>
On Thu, 2012-09-27 at 23:03 +0200, Eric Dumazet wrote:
> On Thu, 2012-09-27 at 19:05 +0100, Chris Clayton wrote:
> > On 09/27/12 13:14, Eric Dumazet wrote:
> > > On Thu, 2012-09-27 at 12:50 +0100, Chris Clayton wrote:
> > >> Just for information - I've pulled Linus' tree this morning and the
> > >> problem is still present. Also, Gunther Piaz has reported, via the
> > >> bugzilla entry, that he too has hit this regression.
> > >
> > > I tried to reproduce the bug, and my kvm guests have no problem.
> > >
> > > I guess you need to precisely describe how you setup your network, so
> > > that I can reproduce the problem and eventually fix it.
> > >
> >
> > You've seen the bits from my firewall setup script that relate to this
> > issue. I start the WinXP client with another script:
> >
> > #!/bin/sh
> > if [ -e $HOME/kvm/var/run/kvm-winxp.pid ]; then
> > echo "winxp is already running ..." > /dev/stderr
> > exit 1
> > fi
> >
> > # make sure the kvm modules are loaded
> > if test -z "$(grep '\<kvm\>' /proc/misc)"; then
> > sudo modprobe kvm-intel
> > while test -z "$(grep '\<kvm\>' /proc/misc)"; do
> > true
> > done
> > fi
> >
> > # make sure tun module is loaded
> > if test ! -e /dev/net/tun; then
> > sudo modprobe tun
> > fi
> >
> > # figure out the cpu to use
> > QVER=$(qemu-kvm --version | cut -d' ' -f 4 | sed 's/,/./')
> > # assumes major version is 1
> > MINORVER=$(echo $QVER | cut -d'.' -f 2)
> > if [ $MINORVER -ge 1 ]; then
> > CPU="host"
> > else
> > CPU="qemu64"
> > fi
> >
> > # set up the network interface
> > TAPDEV=$(sudo tunctl -b -u $(whoami))
> > sudo ifconfig $TAPDEV 192.168.200.254 netmask 255.255.255.0 broadcast
> > 192.168.200.255
> >
> > # start Windows XP
> > qemu-kvm -drive file=$HOME/kvm/winxp.qcow2,index=0,cache=none,if=virtio
> > -cpu $CPU -smp cores=1,threads=2 -soundhw es1370 \
> > -m 768 -net nic,model=virtio,macaddr=$(getmacaddr) -net
> > tap,ifname=$TAPDEV -startdate $(date +%Y-%m-%dT%H:%M:%S) \
> > -name kxplaptop -pidfile $HOME/kvm/var/run/kvm-winxp.pid $*
> >
> > # stop the network interface
> > sudo ifconfig $TAPDEV down
> > sudo tunctl -d $TAPDEV &>/dev/null
> >
> > # tidy up
> > rm -f $HOME/kvm/var/run/kvm-winxp.pid
> >
> >
> > The call to getmacaddr just returns the next in a sequence of mac
> > addresses. qemu-kvm is a symlink to /usr/bin/qemu-system-i386. I first
> > found the problem whilst running qemu-kvm version 1.1.1 although I've
> > since updated to 1.2.0.
> >
> > By the way, I doubt it will make a difference, but, although my laptop
> > has a 64bit CPU, I am running a 32 bit kernel and, obviously, user space.
> >
> > Let me know if you need anything else.
>
> It works for me.
>
> Hmm, maybe your guest is using DHCP and DHCP fails ?
Yes it seems the problem. On the host I tried :
# ip ro get 8.8.8.8 from 192.168.200.1 iif tap1
8.8.8.8 from 192.168.200.1 via 172.30.42.1 dev eth0
cache iif *
So if the guest tries to send a frame to 8.8.8.8 we are going to forward
the packet to eth0
But if the guest tries to send to 255.255.255.255, we try to deliver the
packet to the host itself, instead of broadcasting to eth0
# ip ro get 255.255.255.255 from 192.168.200.1 iif tap1
broadcast 255.255.255.255 from 192.168.200.1 dev lo
cache <local,brd> iif *
David, maybe you'll have an idea ?
Thanks
^ permalink raw reply
* Re: [PATCH 0/7] Add Chelsio T4 firmware configuration file support
From: David Miller @ 2012-09-27 21:56 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm, swise, leedom, felix
In-Reply-To: <1348663182-20190-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Wed, 26 Sep 2012 18:09:35 +0530
> This patch series adds aupport for firmware configuration file for Chelsio T4
> adapters.
>
> The Firmware Configuration file was primarily developed in order to centralize
> all of the configuration, resource allocation, etc. for Unified Wire operation
> where multiple Physical / Virtual Function Drivers would be using a T4 adapter
> simultaneously.
>
> The patch series also has bug fixes which can occur while upgrading the T4
> firmware.
>
> The patch series is built against David Miller's net-next tree.
Series applied.
^ permalink raw reply
* Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
From: David Miller @ 2012-09-27 21:58 UTC (permalink / raw)
To: richardcochran; +Cc: christophe.leroy, netdev, linux-kernel
In-Reply-To: <20120925074736.GB2169@netboy.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 25 Sep 2012 09:47:36 +0200
> On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote:
>>
>> A2 chip has phy_id 0x00137a10
>> A3 chip has phy_id 0x00137a11
>
> Okay then, thanks.
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] smsc75xx: fix resume after device reset
From: David Miller @ 2012-09-27 22:00 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1348497779-10042-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Mon, 24 Sep 2012 15:42:59 +0100
> On some systems this device fails to properly resume after suspend,
> this patch fixes it by running the usbnet_resume handler.
>
> I suspect this also fixes this bug:
>
> http://code.google.com/p/chromium-os/issues/detail?id=31871
Applied, thanks.
^ permalink raw reply
* [PATCH] IB/ipoib: Add more rtnl_link_ops callbacks
From: Or Gerlitz @ 2012-09-27 22:02 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, kaber, Or Gerlitz
Add the rtnl_link_ops changelink and fill_info callbacks, through
which the admin can now set/get the driver mode, etc policies.
Maintain the proprietary sysfs entries only for legacy childs.
For child devices, set dev->iflink to point to the parent
device ifindex, such that user space tools can now correctly
show the uplink relation as done for vlan, macvlan, etc
devices. Pointed out by Patrick McHardy <kaber@trash.net>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 3 +
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 34 ++++++++++----
drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 +++++--
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 60 +++++++++++++++++++++++++-
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 24 ++++++----
include/linux/if_link.h | 7 +++
6 files changed, 118 insertions(+), 26 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 381f51b..8956f6f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -520,6 +520,9 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
int __init ipoib_netlink_init(void);
void __exit ipoib_netlink_fini(void);
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val);
+int ipoib_set_mode(struct net_device *dev, const char *buf);
+
void ipoib_setup(struct net_device *dev);
void ipoib_pkey_poll(struct work_struct *work);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 24683fd..ef6d5a3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1448,15 +1448,10 @@ static ssize_t show_mode(struct device *d, struct device_attribute *attr,
return sprintf(buf, "datagram\n");
}
-static ssize_t set_mode(struct device *d, struct device_attribute *attr,
- const char *buf, size_t count)
+int ipoib_set_mode(struct net_device *dev, const char *buf)
{
- struct net_device *dev = to_net_dev(d);
struct ipoib_dev_priv *priv = netdev_priv(dev);
- if (!rtnl_trylock())
- return restart_syscall();
-
/* flush paths if we switch modes so that connections are restarted */
if (IPOIB_CM_SUPPORTED(dev->dev_addr) && !strcmp(buf, "connected\n")) {
set_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
@@ -1467,7 +1462,8 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM;
ipoib_flush_paths(dev);
- return count;
+ rtnl_lock();
+ return 0;
}
if (!strcmp(buf, "datagram\n")) {
@@ -1476,14 +1472,32 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
dev_set_mtu(dev, min(priv->mcast_mtu, dev->mtu));
rtnl_unlock();
ipoib_flush_paths(dev);
-
- return count;
+ rtnl_lock();
+ return 0;
}
- rtnl_unlock();
return -EINVAL;
}
+static ssize_t set_mode(struct device *d, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct net_device *dev = to_net_dev(d);
+ int ret;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ ret = ipoib_set_mode(dev, buf);
+
+ rtnl_unlock();
+
+ if (!ret)
+ return count;
+
+ return ret;
+}
+
static DEVICE_ATTR(mode, S_IWUSR | S_IRUGO, show_mode, set_mode);
int ipoib_cm_add_mode_attr(struct net_device *dev)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index b3e9709..6c5c771 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1386,12 +1386,9 @@ static ssize_t show_umcast(struct device *dev,
return sprintf(buf, "%d\n", test_bit(IPOIB_FLAG_UMCAST, &priv->flags));
}
-static ssize_t set_umcast(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val)
{
- struct ipoib_dev_priv *priv = netdev_priv(to_net_dev(dev));
- unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+ struct ipoib_dev_priv *priv = netdev_priv(ndev);
if (umcast_val > 0) {
set_bit(IPOIB_FLAG_UMCAST, &priv->flags);
@@ -1399,6 +1396,15 @@ static ssize_t set_umcast(struct device *dev,
"by userspace\n");
} else
clear_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+}
+
+static ssize_t set_umcast(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+
+ ipoib_set_umcast(to_net_dev(dev), umcast_val);
return count;
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
index a7dc5ea..42f6756 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
@@ -37,8 +37,60 @@
static const struct nla_policy ipoib_policy[IFLA_IPOIB_MAX + 1] = {
[IFLA_IPOIB_PKEY] = { .type = NLA_U16 },
+ [IFLA_IPOIB_MODE] = { .type = NLA_U16 },
+ [IFLA_IPOIB_UMCAST] = { .type = NLA_U16 },
};
+static int ipoib_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+ u16 val;
+
+ if (nla_put_u16(skb, IFLA_IPOIB_PKEY, priv->pkey))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_MODE, val))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_UMCAST, val))
+ goto nla_put_failure;
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static int ipoib_changelink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ u16 mode, umcast;
+ int ret = 0;
+
+ if (data[IFLA_IPOIB_MODE]) {
+ mode = nla_get_u16(data[IFLA_IPOIB_MODE]);
+ if (mode == IPOIB_MODE_DATAGRAM)
+ ret = ipoib_set_mode(dev, "datagram\n");
+ else if (mode == IPOIB_MODE_CONNECTED)
+ ret = ipoib_set_mode(dev, "connected\n");
+ else
+ ret = -EINVAL;
+
+ if (ret < 0)
+ goto out_err;
+ }
+
+ if (data[IFLA_IPOIB_UMCAST]) {
+ umcast = nla_get_u16(data[IFLA_IPOIB_UMCAST]);
+ ipoib_set_umcast(dev, umcast);
+ }
+
+out_err:
+ return ret;
+}
+
static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
@@ -69,6 +121,8 @@ static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
err = __ipoib_vlan_add(ppriv, netdev_priv(dev), child_pkey, IPOIB_RTNL_CHILD);
+ if (!err && data)
+ err = ipoib_changelink(dev, tb, data);
return err;
}
@@ -87,7 +141,9 @@ static void ipoib_unregister_child_dev(struct net_device *dev, struct list_head
static size_t ipoib_get_size(const struct net_device *dev)
{
- return nla_total_size(2); /* IFLA_IPOIB_PKEY */
+ return nla_total_size(2) + /* IFLA_IPOIB_PKEY */
+ nla_total_size(2) + /* IFLA_IPOIB_MODE */
+ nla_total_size(2); /* IFLA_IPOIB_UMCAST */
}
static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
@@ -97,8 +153,10 @@ static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
.priv_size = sizeof(struct ipoib_dev_priv),
.setup = ipoib_setup,
.newlink = ipoib_new_child_link,
+ .changelink = ipoib_changelink,
.dellink = ipoib_unregister_child_dev,
.get_size = ipoib_get_size,
+ .fill_info = ipoib_fill_info,
};
int __init ipoib_netlink_init(void)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
index 238bbf9..8292554 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -88,17 +88,21 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
ipoib_create_debug_files(priv->dev);
- if (ipoib_cm_add_mode_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_pkey_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_umcast_attr(priv->dev))
- goto sysfs_failed;
-
- if (device_create_file(&priv->dev->dev, &dev_attr_parent))
- goto sysfs_failed;
+ /* RTNL childs don't need proprietary sysfs entries */
+ if (type == IPOIB_LEGACY_CHILD) {
+ if (ipoib_cm_add_mode_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_pkey_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_umcast_attr(priv->dev))
+ goto sysfs_failed;
+
+ if (device_create_file(&priv->dev->dev, &dev_attr_parent))
+ goto sysfs_failed;
+ }
- priv->child_type = type;
+ priv->child_type = type;
+ priv->dev->iflink = ppriv->dev->ifindex;
list_add_tail(&priv->list, &ppriv->child_intfs);
return 0;
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 24c0dd0..4491177 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -404,9 +404,16 @@ struct ifla_port_vsi {
enum {
IFLA_IPOIB_UNSPEC,
IFLA_IPOIB_PKEY,
+ IFLA_IPOIB_MODE,
+ IFLA_IPOIB_UMCAST,
__IFLA_IPOIB_MAX
};
+enum {
+ IPOIB_MODE_DATAGRAM = 0, /* using unreliable datagram QPs */
+ IPOIB_MODE_CONNECTED = 1, /* using connected QPs */
+};
+
#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1)
#endif /* _LINUX_IF_LINK_H */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next 3/3] ipv4: gre: add GRO capability
From: Jesse Gross @ 2012-09-27 22:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1348769294.5093.1566.camel@edumazet-glaptop>
On Thu, Sep 27, 2012 at 11:08 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-09-27 at 10:52 -0700, Jesse Gross wrote:
>
>> When I was thinking about doing this, my original plan was to handle
>> GRO/GSO by extending the current handlers to be able to look inside
>> GRE and then loop around to process the inner packet (similar to what
>> is done today with skb_flow_dissect() for RPS). Is there a reason to
>> do it in the device?
>>
>> Pushing it earlier/later in the stack obviously increases the benefit
>> and it will also be more compatible with the forthcoming OVS tunneling
>> hooks, which will be flow based and therefore won't have a device.
>>
>> Also, the next generation of NICs will support this type of thing in
>> hardware so putting the software versions very close to the NIC will
>> give us a more similar abstraction.
>
> This sounds not feasible with all kind of tunnels, for example IPIP
> tunnels, or UDP encapsulation, at least with current stack (not OVS)
Hmm, I think we might be talking about different things since I can't
think of why it wouldn't be feasible (and none of it should be
specific to OVS). What I was planning would result in the creation of
large but still encapsulated packets. The merging would be purely
based on the headers in each layer being the same (as GRO is today) so
the logic of the IP stack, UDP stack, etc. isn't processed until
later.
> Also note that pushing earlier means forcing the checksumming earlier
> and it consumes a lot of cpu cycles. Hopefully NIC will help us in the
> future.
It is a good point that if the packet isn't actually destined to us
then probably none of this is worth it (although I suspect that the
relative number of tunnel packets that are passed through vs.
terminated is fairly low). Many NICs are capable of supplying
CHECKSUM_COMPLETE packets here, even if it is not exposed by the
drivers.
> Using a napi_struct permits to eventually have separate cpus, and things
> like RPS/RSS to split the load.
We should be able to split the load today using RPS since we can look
into the GRE flow once the packet comes off the NIC (assuming that it
is using NAPI).
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv4: gre: add GRO capability
From: Jesse Gross @ 2012-09-27 22:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1348769990.5093.1584.camel@edumazet-glaptop>
On Thu, Sep 27, 2012 at 11:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-09-27 at 20:08 +0200, Eric Dumazet wrote:
>
>>
>> This sounds not feasible with all kind of tunnels, for example IPIP
>> tunnels, or UDP encapsulation, at least with current stack (not OVS)
>>
>> Also note that pushing earlier means forcing the checksumming earlier
>> and it consumes a lot of cpu cycles. Hopefully NIC will help us in the
>> future.
>>
>> Using a napi_struct permits to eventually have separate cpus, and things
>> like RPS/RSS to split the load.
>
> Also please note that my implementation doesnt bypass first IP stack
> traversal (and firewalling if any), so its changing nothing in term
> of existing setups.
>
> So packets that should be forwarded will stay as they are (no tunnels
> decapsulation/recapsulation)
>
> Doing this in the generic GRO layer sounds a bit difficult.
We wouldn't actually do the decapsulation at the point of GRO. This
is actually pretty similar to what we do with TCP - we merge TCP
payloads even though we haven't done any real IP processing yet.
However, we do check firewall rules later if we actually hit the IP
stack. GRE would work the same way in this case.
What I'm describing is pretty much exactly what NICs will be doing, so
if that doesn't work we'll have a problem...
^ permalink raw reply
* Re: [PATCH net-next] sparc: bpf_jit_comp: add XOR instruction for BPF JIT JIT
From: David Miller @ 2012-09-27 22:05 UTC (permalink / raw)
To: dxchgb; +Cc: netdev
In-Reply-To: <20120924215753.GA31312@thinkbox>
From: Daniel Borkmann <dxchgb@gmail.com>
Date: Mon, 24 Sep 2012 23:57:54 +0200
> This patch is a follow-up for patch "filter: add XOR instruction for use
> with X/K" that implements BPF SPARC JIT parts for the BPF XOR operation.
>
> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Looks good, applied, thanks Daniel.
^ permalink raw reply
* [PATCH net-next REPOST] IB/ipoib: Add more rtnl_link_ops callbacks
From: Or Gerlitz @ 2012-09-27 22:06 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, kaber, Or Gerlitz
Add the rtnl_link_ops changelink and fill_info callbacks, through
which the admin can now set/get the driver mode, etc policies.
Maintain the proprietary sysfs entries only for legacy childs.
For child devices, set dev->iflink to point to the parent
device ifindex, such that user space tools can now correctly
show the uplink relation as done for vlan, macvlan, etc
devices. Pointed out by Patrick McHardy <kaber@trash.net>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
removed white space damage that went in by mistake, sorry for that
drivers/infiniband/ulp/ipoib/ipoib.h | 3 +
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 34 ++++++++++----
drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 +++++--
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 60 +++++++++++++++++++++++++-
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 24 ++++++----
include/linux/if_link.h | 7 +++
6 files changed, 118 insertions(+), 26 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 381f51b..8956f6f 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -520,6 +520,9 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
int __init ipoib_netlink_init(void);
void __exit ipoib_netlink_fini(void);
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val);
+int ipoib_set_mode(struct net_device *dev, const char *buf);
+
void ipoib_setup(struct net_device *dev);
void ipoib_pkey_poll(struct work_struct *work);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 24683fd..ef6d5a3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1448,15 +1448,10 @@ static ssize_t show_mode(struct device *d, struct device_attribute *attr,
return sprintf(buf, "datagram\n");
}
-static ssize_t set_mode(struct device *d, struct device_attribute *attr,
- const char *buf, size_t count)
+int ipoib_set_mode(struct net_device *dev, const char *buf)
{
- struct net_device *dev = to_net_dev(d);
struct ipoib_dev_priv *priv = netdev_priv(dev);
- if (!rtnl_trylock())
- return restart_syscall();
-
/* flush paths if we switch modes so that connections are restarted */
if (IPOIB_CM_SUPPORTED(dev->dev_addr) && !strcmp(buf, "connected\n")) {
set_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
@@ -1467,7 +1462,8 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM;
ipoib_flush_paths(dev);
- return count;
+ rtnl_lock();
+ return 0;
}
if (!strcmp(buf, "datagram\n")) {
@@ -1476,14 +1472,32 @@ static ssize_t set_mode(struct device *d, struct device_attribute *attr,
dev_set_mtu(dev, min(priv->mcast_mtu, dev->mtu));
rtnl_unlock();
ipoib_flush_paths(dev);
-
- return count;
+ rtnl_lock();
+ return 0;
}
- rtnl_unlock();
return -EINVAL;
}
+static ssize_t set_mode(struct device *d, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct net_device *dev = to_net_dev(d);
+ int ret;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ ret = ipoib_set_mode(dev, buf);
+
+ rtnl_unlock();
+
+ if (!ret)
+ return count;
+
+ return ret;
+}
+
static DEVICE_ATTR(mode, S_IWUSR | S_IRUGO, show_mode, set_mode);
int ipoib_cm_add_mode_attr(struct net_device *dev)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index b3e9709..6c5c771 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1386,12 +1386,9 @@ static ssize_t show_umcast(struct device *dev,
return sprintf(buf, "%d\n", test_bit(IPOIB_FLAG_UMCAST, &priv->flags));
}
-static ssize_t set_umcast(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+void ipoib_set_umcast(struct net_device *ndev, int umcast_val)
{
- struct ipoib_dev_priv *priv = netdev_priv(to_net_dev(dev));
- unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+ struct ipoib_dev_priv *priv = netdev_priv(ndev);
if (umcast_val > 0) {
set_bit(IPOIB_FLAG_UMCAST, &priv->flags);
@@ -1399,6 +1396,15 @@ static ssize_t set_umcast(struct device *dev,
"by userspace\n");
} else
clear_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+}
+
+static ssize_t set_umcast(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long umcast_val = simple_strtoul(buf, NULL, 0);
+
+ ipoib_set_umcast(to_net_dev(dev), umcast_val);
return count;
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
index a7dc5ea..42f6756 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
@@ -37,8 +37,60 @@
static const struct nla_policy ipoib_policy[IFLA_IPOIB_MAX + 1] = {
[IFLA_IPOIB_PKEY] = { .type = NLA_U16 },
+ [IFLA_IPOIB_MODE] = { .type = NLA_U16 },
+ [IFLA_IPOIB_UMCAST] = { .type = NLA_U16 },
};
+static int ipoib_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+ u16 val;
+
+ if (nla_put_u16(skb, IFLA_IPOIB_PKEY, priv->pkey))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_MODE, val))
+ goto nla_put_failure;
+
+ val = test_bit(IPOIB_FLAG_UMCAST, &priv->flags);
+ if (nla_put_u16(skb, IFLA_IPOIB_UMCAST, val))
+ goto nla_put_failure;
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static int ipoib_changelink(struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ u16 mode, umcast;
+ int ret = 0;
+
+ if (data[IFLA_IPOIB_MODE]) {
+ mode = nla_get_u16(data[IFLA_IPOIB_MODE]);
+ if (mode == IPOIB_MODE_DATAGRAM)
+ ret = ipoib_set_mode(dev, "datagram\n");
+ else if (mode == IPOIB_MODE_CONNECTED)
+ ret = ipoib_set_mode(dev, "connected\n");
+ else
+ ret = -EINVAL;
+
+ if (ret < 0)
+ goto out_err;
+ }
+
+ if (data[IFLA_IPOIB_UMCAST]) {
+ umcast = nla_get_u16(data[IFLA_IPOIB_UMCAST]);
+ ipoib_set_umcast(dev, umcast);
+ }
+
+out_err:
+ return ret;
+}
+
static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
{
@@ -69,6 +121,8 @@ static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
err = __ipoib_vlan_add(ppriv, netdev_priv(dev), child_pkey, IPOIB_RTNL_CHILD);
+ if (!err && data)
+ err = ipoib_changelink(dev, tb, data);
return err;
}
@@ -87,7 +141,9 @@ static void ipoib_unregister_child_dev(struct net_device *dev, struct list_head
static size_t ipoib_get_size(const struct net_device *dev)
{
- return nla_total_size(2); /* IFLA_IPOIB_PKEY */
+ return nla_total_size(2) + /* IFLA_IPOIB_PKEY */
+ nla_total_size(2) + /* IFLA_IPOIB_MODE */
+ nla_total_size(2); /* IFLA_IPOIB_UMCAST */
}
static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
@@ -97,8 +153,10 @@ static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
.priv_size = sizeof(struct ipoib_dev_priv),
.setup = ipoib_setup,
.newlink = ipoib_new_child_link,
+ .changelink = ipoib_changelink,
.dellink = ipoib_unregister_child_dev,
.get_size = ipoib_get_size,
+ .fill_info = ipoib_fill_info,
};
int __init ipoib_netlink_init(void)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
index 238bbf9..8292554 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -88,17 +88,21 @@ int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
ipoib_create_debug_files(priv->dev);
- if (ipoib_cm_add_mode_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_pkey_attr(priv->dev))
- goto sysfs_failed;
- if (ipoib_add_umcast_attr(priv->dev))
- goto sysfs_failed;
-
- if (device_create_file(&priv->dev->dev, &dev_attr_parent))
- goto sysfs_failed;
+ /* RTNL childs don't need proprietary sysfs entries */
+ if (type == IPOIB_LEGACY_CHILD) {
+ if (ipoib_cm_add_mode_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_pkey_attr(priv->dev))
+ goto sysfs_failed;
+ if (ipoib_add_umcast_attr(priv->dev))
+ goto sysfs_failed;
+
+ if (device_create_file(&priv->dev->dev, &dev_attr_parent))
+ goto sysfs_failed;
+ }
- priv->child_type = type;
+ priv->child_type = type;
+ priv->dev->iflink = ppriv->dev->ifindex;
list_add_tail(&priv->list, &ppriv->child_intfs);
return 0;
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 24c0dd0..4491177 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -404,9 +404,16 @@ struct ifla_port_vsi {
enum {
IFLA_IPOIB_UNSPEC,
IFLA_IPOIB_PKEY,
+ IFLA_IPOIB_MODE,
+ IFLA_IPOIB_UMCAST,
__IFLA_IPOIB_MAX
};
+enum {
+ IPOIB_MODE_DATAGRAM = 0, /* using unreliable datagram QPs */
+ IPOIB_MODE_CONNECTED = 1, /* using connected QPs */
+};
+
#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1)
#endif /* _LINUX_IF_LINK_H */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/2] Fix a typo in PTP_1588_CLOCK_PCH Kconfig help info.
From: David Miller @ 2012-09-27 22:06 UTC (permalink / raw)
To: haicheng.li; +Cc: netdev, tshimizu818, linux-kernel, haicheng.lee
In-Reply-To: <5060F9C4.4050303@linux.intel.com>
From: Haicheng Li <haicheng.li@linux.intel.com>
Date: Tue, 25 Sep 2012 08:24:36 +0800
> From 5911413366d37aafcc19ddfc9c0f2db31855431e Mon Sep 17 00:00:00 2001
> From: Haicheng Li <haicheng.li@linux.intel.com>
> Date: Mon, 24 Sep 2012 15:55:27 +0800
> Subject: [PATCH 2/2] Fix a typo in PTP_1588_CLOCK_PCH Kconfig help
> info.
>
> Signed-off-by: Haicheng Li <haicheng.lee@gmail.com>
> ---
> drivers/ptp/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
> index ffdf712..82c4a26 100644
> --- a/drivers/ptp/Kconfig
> +++ b/drivers/ptp/Kconfig
> @@ -87,6 +87,6 @@ config PTP_1588_CLOCK_PCH
> SO_TIMESTAMPING API.
>
> To compile this driver as a module, choose M here: the module
> - will be called ptp_pch.
> + will be called by pch_ptp.
The original sentence is correct, it is stating the name of the module
that will be built not the module that will call it.
Rather, the "pch_ptp" is what might need to be adjusted.
^ permalink raw reply
* Re: [PATCH 1/2] Fix build error caused by broken PCH_PTP module dependency.
From: David Miller @ 2012-09-27 22:09 UTC (permalink / raw)
To: haicheng.li; +Cc: netdev, tshimizu818, linux-kernel, haicheng.lee
In-Reply-To: <5060F97F.3040809@linux.intel.com>
From: Haicheng Li <haicheng.li@linux.intel.com>
Date: Tue, 25 Sep 2012 08:23:27 +0800
> From 898e3214b3406c620571cedf704719784b0df049 Mon Sep 17 00:00:00 2001
> From: Haicheng Li <haicheng.li@linux.intel.com>
> Date: Mon, 24 Sep 2012 15:52:30 +0800
> Subject: [PATCH 1/2] Fix build error caused by broken PCH_PTP module
> dependency.
>
> The .config is:
> CONFIG_PCH_GBE=y
> CONFIG_PCH_PTP=y
> CONFIG_PTP_1588_CLOCK=m
>
> The build error:
Your patch submissions are of a very low quality.
And the main reason is that you microscopically look at problems and
do not investigate how the same thing might be handled elsewhere.
Therefore you will never become accustomed to the proper way problems
are fixed, and the proper way to submit patches.
Look at how other people submit patches, do any other patch submissions
look like your's having all of this metadata in the message body:
> From 898e3214b3406c620571cedf704719784b0df049 Mon Sep 17 00:00:00 2001
> From: Haicheng Li <haicheng.li@linux.intel.com>
> Date: Mon, 24 Sep 2012 15:52:30 +0800
> Subject: [PATCH 1/2] Fix build error caused by broken PCH_PTP module
> dependency.
No, nobody else does this.
As for this specific patch:
> - depends on PTP_1588_CLOCK_PCH
> + depends on PTP_1588_CLOCK_PCH = PCH_GBE
This is not the correct way to ensure that the module'ness of one
config option meets the module'ness requirements of another.
The correct way is to say something like "&& (PCH_GBE || PCH_GBE=n)"
^ permalink raw reply
* Re: [PATCH net-next 0/4] Tunnel related patches
From: David Miller @ 2012-09-27 22:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20120925041222.056704869@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 24 Sep 2012 21:12:22 -0700
> These are a set of small tunnel related patches.
Series applied, with the updated version of patch #4.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] be2net: fix vfs enumeration
From: David Miller @ 2012-09-27 22:14 UTC (permalink / raw)
To: ivecera; +Cc: netdev, sathya.perla, ajit.khaparde
In-Reply-To: <1348577442-7720-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Tue, 25 Sep 2012 14:50:42 +0200
> Current VFs enumeration algorithm used in be_find_vfs does not take domain
> number into the match. The match found in igb/ixgbe is more elegant and
> safe.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Applied, thanks Ivan.
^ permalink raw reply
* Re: [PATCH linux-next] nf_defrag_ipv6: fix oops on module unloading
From: David Miller @ 2012-09-27 22:18 UTC (permalink / raw)
To: khlebnikov; +Cc: netdev, amwang
In-Reply-To: <20120925160750.30475.77562.stgit@zurg>
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Tue, 25 Sep 2012 20:07:50 +0400
> fix copy-paste error introduced in linux-next commit
> "ipv6: add a new namespace for nf_conntrack_reasm"
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] qlcnic - Fix scheduling while atomic bug
From: David Miller @ 2012-09-27 22:21 UTC (permalink / raw)
To: Narendra_K; +Cc: netdev, sony.chacko, jitendra.kalsaria, john.r.fastabend
In-Reply-To: <20120925175212.GA1324@fedora-17-guest.blr.amer.dell.com>
Is it really the case that not one Qlogic person feels like ACK'ing
this patch that fixes an obvious bug in their driver for 2 full days?
For real?
^ permalink raw reply
* Re: Netfilter lacks ability to filter packets via Application-origin
From: richard -rw- weinberger @ 2012-09-27 22:25 UTC (permalink / raw)
To: Chad Gray; +Cc: netdev@vger.kernel.org
In-Reply-To: <COL002-W881A56C786C9972B7654E3F3830@phx.gbl>
On Thu, Sep 27, 2012 at 11:04 PM, Chad Gray <chad938@hotmail.com> wrote:
> Users need the ability for Linux firewall to filter packets based on what
> Application they are originating from. This ability is present in Mac and
> Windows firewalls, but not Linux.
>
> For example, users would like ability to open Port 80 for Firefox, but keep
> Port 80 closed for other applications.
You can implement such filters using LSM like SELinux.
> This ability enhances Privacy & Security of the user but also helps to better
> inform the user about the comings and goings of internet traffic and what
> application/s are causing the traffic.
I seriously doubt that.
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH] rtlwifi: use %*ph[C] to dump small buffers
From: Larry Finger @ 2012-09-27 22:28 UTC (permalink / raw)
To: Joe Perches
Cc: Andy Shevchenko, Chaoming Li, David S. Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1348677946.15175.8.camel@joe-AO722>
On 09/26/2012 11:45 AM, Joe Perches wrote:
> On Wed, 2012-09-26 at 16:57 +0300, Andy Shevchenko wrote:
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> Hi Andy.
>
> (adding Larry and Chaoming to cc's)
>
> Please use scripts/get_maintainer.pl on your patches to
> see who maintains these files so you can cc them.
>
> One comment below, it looks like a possible endian bug.
> (not in your patch)
>
>> ---
>> drivers/net/wireless/rtlwifi/cam.c | 7 ++-----
>> drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 6 ++----
>> drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 6 ++----
>> 3 files changed, 6 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/cam.c b/drivers/net/wireless/rtlwifi/cam.c
>> index 5b4b4d4..6ba9f80 100644
>> --- a/drivers/net/wireless/rtlwifi/cam.c
>> +++ b/drivers/net/wireless/rtlwifi/cam.c
>> @@ -52,11 +52,8 @@ static void rtl_cam_program_entry(struct ieee80211_hw *hw, u32 entry_no,
>> u32 target_content = 0;
>> u8 entry_i;
>>
>> - RT_TRACE(rtlpriv, COMP_SEC, DBG_LOUD,
>> - "key_cont_128:\n %x:%x:%x:%x:%x:%x\n",
>> - key_cont_128[0], key_cont_128[1],
>> - key_cont_128[2], key_cont_128[3],
>> - key_cont_128[4], key_cont_128[5]);
>> + RT_TRACE(rtlpriv, COMP_SEC, DBG_LOUD, "key_cont_128: %*ph\n",
>> + 6, key_cont_128);
>>
>> for (entry_i = 0; entry_i < CAM_CONTENT_COUNT; entry_i++) {
>> target_command = entry_i + CAM_CONTENT_COUNT * entry_no;
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>> index 86d73b3..932780d 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
>> @@ -1918,10 +1918,8 @@ static void rtl92ce_update_hal_rate_mask(struct ieee80211_hw *hw,
>> (ratr_index << 28);
>> rate_mask[4] = macid | (shortgi ? 0x20 : 0x00) | 0x80;
>> RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
>> - "Rate_index:%x, ratr_val:%x, %x:%x:%x:%x:%x\n",
>> - ratr_index, ratr_bitmap,
>> - rate_mask[0], rate_mask[1], rate_mask[2], rate_mask[3],
>> - rate_mask[4]);
>> + "Rate_index:%x, ratr_val:%x, %*phC\n",
>> + ratr_index, ratr_bitmap, 5, rate_mask);
>> rtl92c_fill_h2c_cmd(hw, H2C_RA_MASK, 5, rate_mask);
>>
>> if (macid != 0)
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
>> index 4bbb711..7554501 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
>> @@ -2169,10 +2169,8 @@ void rtl92cu_update_hal_rate_mask(struct ieee80211_hw *hw, u8 rssi_level)
>> ratr_index << 28);
>> rate_mask[4] = macid | (shortgi ? 0x20 : 0x00) | 0x80;
>> RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
>> - "Rate_index:%x, ratr_val:%x, %x:%x:%x:%x:%x\n",
>> - ratr_index, ratr_bitmap,
>> - rate_mask[0], rate_mask[1], rate_mask[2], rate_mask[3],
>> - rate_mask[4]);
>> + "Rate_index:%x, ratr_val:%x, %*phC\n",
>> + ratr_index, ratr_bitmap, 5, rate_mask);
>> rtl92c_fill_h2c_cmd(hw, H2C_RA_MASK, 5, rate_mask);
>> }
>>
>
> rate_mask uses:
>
> u32 ratr_bitmap = (u32) mac->basic_rates;
> ...
> u8 rate_mask[5];
> ...
> [sets ratr_bitmap as u32]
> ...
> *(u32 *)&rate_mask = ((ratr_bitmap & 0x0fffffff) |
> ratr_index << 28);
> ...
> rtl92c_fill_h2c_cmd(hw, H2C_RA_MASK, 5, rate_mask);
>
> Looks like a possible endian misuse to me.
After a second look at the code, I don't think this is an endian issue; however,
I am proposing the following changes to remove any doubt:
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -1964,8 +1965,9 @@ static void rtl92ce_update_hal_rate_mask
RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
"ratr_bitmap :%x\n", ratr_bitmap);
- *(u32 *)&rate_mask = (ratr_bitmap & 0x0fffffff) |
- (ratr_index << 28);
+ for (i = 0; i < 3; i++)
+ rate_mask[i] = ratr_bitmap & (0xff << (i * 4));
+ rate_mask[3] = (ratr_bitmap & 0x0f000000) | (ratr_index << 28);
rate_mask[4] = macid | (shortgi ? 0x20 : 0x00) | 0x80;
RT_TRACE(rtlpriv, COMP_RATR, DBG_DMESG,
"Rate_index:%x, ratr_val:%x, %*phC\n",
The downstream routine uses this info as an array of u8, thus it is OK. A proper
patch will be sent later. At least we avoid that ugly cast.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: phy: smsc: Implement PHY config_init for LAN87xx
From: David Miller @ 2012-09-27 22:28 UTC (permalink / raw)
To: otavio; +Cc: marex, netdev, chohnstaedt, fabio.estevam, peppe.cavallaro
In-Reply-To: <CAP9ODKqC5PhkWxuMsFgA019-wZuygr_hhEme_xyP9dy4C6bLmw@mail.gmail.com>
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Thu, 27 Sep 2012 15:21:37 -0300
> On Tue, Sep 25, 2012 at 5:17 PM, Marek Vasut <marex@denx.de> wrote:
>> The LAN8710/LAN8720 chips do have broken the "FlexPWR" smart power-saving
>> capability. Enabling it leads to the PHY not being able to detect Link when
>> cold-started without cable connected. Thus, make sure this is disabled.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>
> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Applied, 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