* Devices with colon in name (iproute2 bug)
From: Štefan Sakalík @ 2010-11-18 12:14 UTC (permalink / raw)
To: netdev
Hi,
When I add a device with colon via ip (from git 3f5c1a01):
ip link add dev 'a:b' type dummy
then ip link show dev 'a:b' returns
12: a:b: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
ioctl(SIOCGIFXQLEN) failed: No such device
link/ether 9e:44:b4:ec:77:f1 brd ff:ff:ff:ff:ff:ff
Also ifconfig from net-tools returns
a: error fetching interface information: Device not found
but I guess it's obsolete.
Regards,
-Stefan
^ permalink raw reply
* [PATCH net-next-2.6] bonding: IGMP handling cleanup
From: Eric Dumazet @ 2010-11-18 10:49 UTC (permalink / raw)
To: Sachin Sant, David Miller
Cc: netdev, linux-s390, linux-next, ursula.braun, Jay Vosburgh
In-Reply-To: <1290075978.2781.36.camel@edumazet-laptop>
Le jeudi 18 novembre 2010 à 11:26 +0100, Eric Dumazet a écrit :
> Actually this raises an interesting case for bonding as well.
>
> Before my RCU conversion __bond_resend_igmp_join_requests() was unsafe.
>
> For net-next-2.6, it is now safe (RCU is held), but needs a cleanup
> patch to avoid sparse errors.
[PATCH net-next-2.6] bonding: IGMP handling cleanup
Instead of iterating in_dev->mc_list from bonding driver, its better
to call a helper function provided by igmp.c
Details of implementation (locking) are private to igmp code.
ip_mc_rejoin_group(struct ip_mc_list *im) becomes
ip_mc_rejoin_groups(struct in_device *in_dev);
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Sachin Sant <sachinp@in.ibm.com>
---
drivers/net/bonding/bond_main.c | 8 +------
include/linux/igmp.h | 2 -
net/ipv4/igmp.c | 34 +++++++++++++++++-------------
3 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5188448..e588b2e 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -873,15 +873,11 @@ static void bond_mc_del(struct bonding *bond, void *addr)
static void __bond_resend_igmp_join_requests(struct net_device *dev)
{
struct in_device *in_dev;
- struct ip_mc_list *im;
rcu_read_lock();
in_dev = __in_dev_get_rcu(dev);
- if (in_dev) {
- for (im = in_dev->mc_list; im; im = im->next)
- ip_mc_rejoin_group(im);
- }
-
+ if (in_dev)
+ ip_mc_rejoin_groups(in_dev);
rcu_read_unlock();
}
diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index 7d16467..c4987f2 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -238,7 +238,7 @@ extern void ip_mc_unmap(struct in_device *);
extern void ip_mc_remap(struct in_device *);
extern void ip_mc_dec_group(struct in_device *in_dev, __be32 addr);
extern void ip_mc_inc_group(struct in_device *in_dev, __be32 addr);
-extern void ip_mc_rejoin_group(struct ip_mc_list *im);
+extern void ip_mc_rejoin_groups(struct in_device *in_dev);
#endif
#endif
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index afb1e82..35f0231 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1267,26 +1267,32 @@ EXPORT_SYMBOL(ip_mc_inc_group);
/*
* Resend IGMP JOIN report; used for bonding.
+ * Called with rcu_read_lock()
*/
-void ip_mc_rejoin_group(struct ip_mc_list *im)
+void ip_mc_rejoin_groups(struct in_device *in_dev)
{
#ifdef CONFIG_IP_MULTICAST
- struct in_device *in_dev = im->interface;
-
- if (im->multiaddr == IGMP_ALL_HOSTS)
- return;
+ struct ip_mc_list *im;
+ int type;
+
+ for_each_pmc_rcu(in_dev, im) {
+ if (im->multiaddr == IGMP_ALL_HOSTS)
+ continue;
- /* a failover is happening and switches
- * must be notified immediately */
- if (IGMP_V1_SEEN(in_dev))
- igmp_send_report(in_dev, im, IGMP_HOST_MEMBERSHIP_REPORT);
- else if (IGMP_V2_SEEN(in_dev))
- igmp_send_report(in_dev, im, IGMPV2_HOST_MEMBERSHIP_REPORT);
- else
- igmp_send_report(in_dev, im, IGMPV3_HOST_MEMBERSHIP_REPORT);
+ /* a failover is happening and switches
+ * must be notified immediately
+ */
+ if (IGMP_V1_SEEN(in_dev))
+ type = IGMP_HOST_MEMBERSHIP_REPORT;
+ else if (IGMP_V2_SEEN(in_dev))
+ type = IGMPV2_HOST_MEMBERSHIP_REPORT;
+ else
+ type = IGMPV3_HOST_MEMBERSHIP_REPORT;
+ igmp_send_report(in_dev, im, type);
+ }
#endif
}
-EXPORT_SYMBOL(ip_mc_rejoin_group);
+EXPORT_SYMBOL(ip_mc_rejoin_groups);
/*
* A socket has left a multicast group on device dev
^ permalink raw reply related
* [PATCH net-2.6] CAIF: Fix U5500 compile error for shared memory driver
From: Sjur Braendeland @ 2010-11-18 10:42 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Kim Lilliestierna XX
From: Kim Lilliestierna XX <kim.xx.lilliestierna@stericsson.com>
Rearrange pr_fmt as __func__ is a variable and not a constant
---
drivers/net/caif/caif_shm_u5500.c | 2 +-
drivers/net/caif/caif_shmcore.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/caif/caif_shm_u5500.c b/drivers/net/caif/caif_shm_u5500.c
index 1cd90da..7c1f7b9 100644
--- a/drivers/net/caif/caif_shm_u5500.c
+++ b/drivers/net/caif/caif_shm_u5500.c
@@ -5,7 +5,7 @@
* License terms: GNU General Public License (GPL) version 2
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ":" __func__ "():" fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ":%s(): " fmt, __func__
#include <linux/version.h>
#include <linux/init.h>
diff --git a/drivers/net/caif/caif_shmcore.c b/drivers/net/caif/caif_shmcore.c
index 19f9c06..e4ee8c2 100644
--- a/drivers/net/caif/caif_shmcore.c
+++ b/drivers/net/caif/caif_shmcore.c
@@ -6,7 +6,7 @@
* License terms: GNU General Public License (GPL) version 2
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ":" __func__ "():" fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ":%s(): " fmt, __func__
#include <linux/spinlock.h>
#include <linux/sched.h>
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-2.6] bonding: fix a race in IGMP handling
From: Eric Dumazet @ 2010-11-18 10:26 UTC (permalink / raw)
To: Sachin Sant, David Miller
Cc: netdev, davem, linux-s390, linux-next, ursula.braun, Jay Vosburgh
In-Reply-To: <1290073388.2781.12.camel@edumazet-laptop>
Le jeudi 18 novembre 2010 à 10:43 +0100, Eric Dumazet a écrit :
> Le jeudi 18 novembre 2010 à 10:33 +0100, Eric Dumazet a écrit :
> >
> >
> >
> > Hmm, sorry but this wont work.
> >
> > > diff -Narup linux-2.6-next/drivers/s390/net/lcs.c linux-2.6-next-new/drivers/s390/net/lcs.c
> > > --- linux-2.6-next/drivers/s390/net/lcs.c 2010-11-17 11:38:25.000000000 +0530
> > > +++ linux-2.6-next-new/drivers/s390/net/lcs.c 2010-11-18 11:59:46.000000000 +0530
> > > @@ -1269,10 +1269,10 @@ lcs_register_mc_addresses(void *data)
> > > in4_dev = in_dev_get(card->dev);
> > > if (in4_dev == NULL)
> > > goto out;
> > > - read_lock(&in4_dev->mc_list_lock);
> > > + rcu_read_lock();
> >
> > If you use rcu_read_lock(), then you also need to
> > use the rcu list iterators in lcs_remove_mc_addresses() and
> > lcs_set_mc_addresses()
> >
> > Then, its strange this driver is not protected by RTNL at this stage.
> >
> > Ah yes, it uses a kthread from its ndo_set_multicast_list() handler.
> >
> > This seems not safe at all.
Actually this raises an interesting case for bonding as well.
Before my RCU conversion __bond_resend_igmp_join_requests() was unsafe.
For net-next-2.6, it is now safe (RCU is held), but needs a cleanup
patch to avoid sparse errors.
Thanks
[PATCH net-2.6] bonding: fix a race in IGMP handling
RCU conversion in IGMP code done in net-next-2.6 raised a race in
__bond_resend_igmp_join_requests().
It iterates in_dev->mc_list without appropriate protection (RTNL, or
read_lock on in_dev->mc_list_lock).
Another cpu might delete an entry while we use it and trigger a fault.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/bonding/bond_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index bdb68a6..71a1697 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -878,8 +878,10 @@ static void __bond_resend_igmp_join_requests(struct net_device *dev)
rcu_read_lock();
in_dev = __in_dev_get_rcu(dev);
if (in_dev) {
+ read_lock(&in_dev->mc_list_lock);
for (im = in_dev->mc_list; im; im = im->next)
ip_mc_rejoin_group(im);
+ read_unlock(&in_dev->mc_list_lock);
}
rcu_read_unlock();
^ permalink raw reply related
* Re: [net-next pull-request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2010-11-18 9:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101117.100119.71117424.davem@davemloft.net>
On Wed, Nov 17, 2010 at 10:01, David Miller <davem@davemloft.net> wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 16 Nov 2010 20:59:49 -0800
>
>> Here is a batch of fixes/cleanups intended for 2.6.38. In the mix is added
>> support for x540 10GbE MAC. A large part of the changes are ixgbe cleanup
>> patches by Alex.
>>
>> Please let me know if there are problems.
>
> Pulled, thanks Jeff.
>
> But in the future you'll need to still post the patches you're asking
> me to merge to the list. Usually folks do this by posting something
> like a "Subject: [PATCH 0/N] Intel Wired Lan Driver Updates"
> thread-leading posting which contains an overall description of the
> changes, as well as the pull request. This is followed-up with the
> actual patches.
>
> This way people can review the changes and reply to any issues they
> have on-list with a simple reply to the patch in question.
>
> Thanks.
> --
Ok, will do. Thanks.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [Patch -next] Adapt s390 qeth & lcs driver code to use RCU
From: Eric Dumazet @ 2010-11-18 9:43 UTC (permalink / raw)
To: Sachin Sant; +Cc: netdev, davem, linux-s390, linux-next, ursula.braun
In-Reply-To: <1290072794.2781.10.camel@edumazet-laptop>
Le jeudi 18 novembre 2010 à 10:33 +0100, Eric Dumazet a écrit :
> Le jeudi 18 novembre 2010 à 14:48 +0530, Sachin Sant a écrit :
> > Commit 1d7138de878d1d4210727c1200193e69596f93b3
> > igmp: RCU conversion of in_dev->mc_list
> >
> > converted rwlock to RCU.
> >
> > Update the s390 network drivers(qeth & lcs) code to adapt to this change.
> >
> > Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> > ---
> >
> > Only compile tested.
> >
>
> Hmm, sorry but this wont work.
>
> > diff -Narup linux-2.6-next/drivers/s390/net/lcs.c linux-2.6-next-new/drivers/s390/net/lcs.c
> > --- linux-2.6-next/drivers/s390/net/lcs.c 2010-11-17 11:38:25.000000000 +0530
> > +++ linux-2.6-next-new/drivers/s390/net/lcs.c 2010-11-18 11:59:46.000000000 +0530
> > @@ -1269,10 +1269,10 @@ lcs_register_mc_addresses(void *data)
> > in4_dev = in_dev_get(card->dev);
> > if (in4_dev == NULL)
> > goto out;
> > - read_lock(&in4_dev->mc_list_lock);
> > + rcu_read_lock();
>
> If you use rcu_read_lock(), then you also need to
> use the rcu list iterators in lcs_remove_mc_addresses() and
> lcs_set_mc_addresses()
>
> Then, its strange this driver is not protected by RTNL at this stage.
>
> Ah yes, it uses a kthread from its ndo_set_multicast_list() handler.
>
> This seems not safe at all.
Please check following patch to give you the idea of what is needed :
diff --git a/drivers/s390/net/lcs.c b/drivers/s390/net/lcs.c
index 0f19d54..05755b7 100644
--- a/drivers/s390/net/lcs.c
+++ b/drivers/s390/net/lcs.c
@@ -1188,7 +1188,9 @@ lcs_remove_mc_addresses(struct lcs_card *card, struct in_device *in4_dev)
spin_lock_irqsave(&card->ipm_lock, flags);
list_for_each(l, &card->ipm_list) {
ipm = list_entry(l, struct lcs_ipm_list, list);
- for (im4 = in4_dev->mc_list; im4 != NULL; im4 = im4->next) {
+ for (im4 = rcu_dereference(in4_dev->mc_list);
+ im4 != NULL;
+ im4 = rcu_dereference(im4->next_rcu)) {
lcs_get_mac_for_ipm(im4->multiaddr, buf, card->dev);
if ( (ipm->ipm.ip_addr == im4->multiaddr) &&
(memcmp(buf, &ipm->ipm.mac_addr,
@@ -1233,7 +1235,9 @@ lcs_set_mc_addresses(struct lcs_card *card, struct in_device *in4_dev)
unsigned long flags;
LCS_DBF_TEXT(4, trace, "setmclst");
- for (im4 = in4_dev->mc_list; im4; im4 = im4->next) {
+ for (im4 = rcu_dereference(in4_dev->mc_list);
+ im4 != NULL;
+ im4 = rcu_dereference(im4->next_rcu)) {
lcs_get_mac_for_ipm(im4->multiaddr, buf, card->dev);
ipm = lcs_check_addr_entry(card, im4, buf);
if (ipm != NULL)
@@ -1269,10 +1273,10 @@ lcs_register_mc_addresses(void *data)
in4_dev = in_dev_get(card->dev);
if (in4_dev == NULL)
goto out;
- read_lock(&in4_dev->mc_list_lock);
+ rcu_read_lock();
lcs_remove_mc_addresses(card,in4_dev);
lcs_set_mc_addresses(card, in4_dev);
- read_unlock(&in4_dev->mc_list_lock);
+ rcu_read_unlock();
in_dev_put(in4_dev);
netif_carrier_off(card->dev);
^ permalink raw reply related
* Re: [Patch -next] Adapt s390 qeth & lcs driver code to use RCU
From: Eric Dumazet @ 2010-11-18 9:33 UTC (permalink / raw)
To: Sachin Sant; +Cc: netdev, davem, linux-s390, linux-next, ursula.braun
In-Reply-To: <20101118091846.26534.38865.sendpatchset@localhost.localdomain>
Le jeudi 18 novembre 2010 à 14:48 +0530, Sachin Sant a écrit :
> Commit 1d7138de878d1d4210727c1200193e69596f93b3
> igmp: RCU conversion of in_dev->mc_list
>
> converted rwlock to RCU.
>
> Update the s390 network drivers(qeth & lcs) code to adapt to this change.
>
> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> ---
>
> Only compile tested.
>
Hmm, sorry but this wont work.
> diff -Narup linux-2.6-next/drivers/s390/net/lcs.c linux-2.6-next-new/drivers/s390/net/lcs.c
> --- linux-2.6-next/drivers/s390/net/lcs.c 2010-11-17 11:38:25.000000000 +0530
> +++ linux-2.6-next-new/drivers/s390/net/lcs.c 2010-11-18 11:59:46.000000000 +0530
> @@ -1269,10 +1269,10 @@ lcs_register_mc_addresses(void *data)
> in4_dev = in_dev_get(card->dev);
> if (in4_dev == NULL)
> goto out;
> - read_lock(&in4_dev->mc_list_lock);
> + rcu_read_lock();
If you use rcu_read_lock(), then you also need to
use the rcu list iterators in lcs_remove_mc_addresses() and
lcs_set_mc_addresses()
Then, its strange this driver is not protected by RTNL at this stage.
Ah yes, it uses a kthread from its ndo_set_multicast_list() handler.
This seems not safe at all.
> lcs_remove_mc_addresses(card,in4_dev);
> lcs_set_mc_addresses(card, in4_dev);
> - read_unlock(&in4_dev->mc_list_lock);
> + rcu_read_unlock();
> in_dev_put(in4_dev);
>
> netif_carrier_off(card->dev);
> diff -Narup linux-2.6-next/drivers/s390/net/qeth_l3_main.c linux-2.6-next-new/drivers/s390/net/qeth_l3_main.c
> --- linux-2.6-next/drivers/s390/net/qeth_l3_main.c 2010-10-30 12:54:22.000000000 +0530
> +++ linux-2.6-next-new/drivers/s390/net/qeth_l3_main.c 2010-11-18 11:59:13.000000000 +0530
> @@ -1828,9 +1828,9 @@ static void qeth_l3_add_vlan_mc(struct q
> in_dev = in_dev_get(netdev);
> if (!in_dev)
> continue;
> - read_lock(&in_dev->mc_list_lock);
> + rcu_read_lock();
> qeth_l3_add_mc(card, in_dev);
> - read_unlock(&in_dev->mc_list_lock);
> + rcu_read_unlock();
> in_dev_put(in_dev);
> }
> }
> @@ -1843,10 +1843,10 @@ static void qeth_l3_add_multicast_ipv4(s
> in4_dev = in_dev_get(card->dev);
> if (in4_dev == NULL)
> return;
> - read_lock(&in4_dev->mc_list_lock);
> + rcu_read_lock();
> qeth_l3_add_mc(card, in4_dev);
> qeth_l3_add_vlan_mc(card);
> - read_unlock(&in4_dev->mc_list_lock);
> + rcu_read_unlock();
> in_dev_put(in4_dev);
> }
>
^ permalink raw reply
* [net-next] MAINTAINERS: Add stmmac maintainer
From: Giuseppe CAVALLARO @ 2010-11-18 9:19 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
Add STMMAC to the list of supported Ethernet drivers
and myself as maintainer.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
MAINTAINERS | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 88b74a7..8b6ca96 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1829,6 +1829,13 @@ W: http://www.chelsio.com
S: Supported
F: drivers/net/cxgb4vf/
+STMMAC ETHERNET DRIVER
+M: Giuseppe Cavallaro <peppe.cavallaro@st.com>
+L: netdev@vger.kernel.org
+W: http://www.stlinux.com
+S: Supported
+F: drivers/net/stmmac/
+
CYBERPRO FB DRIVER
M: Russell King <linux@arm.linux.org.uk>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
1.5.5.6
^ permalink raw reply related
* [Patch -next] Adapt s390 qeth & lcs driver code to use RCU
From: Sachin Sant @ 2010-11-18 9:18 UTC (permalink / raw)
To: netdev, davem
Cc: Sachin Sant, linux-s390, linux-next, ursula.braun, eric.dumazet
Commit 1d7138de878d1d4210727c1200193e69596f93b3
igmp: RCU conversion of in_dev->mc_list
converted rwlock to RCU.
Update the s390 network drivers(qeth & lcs) code to adapt to this change.
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
---
Only compile tested.
diff -Narup linux-2.6-next/drivers/s390/net/lcs.c linux-2.6-next-new/drivers/s390/net/lcs.c
--- linux-2.6-next/drivers/s390/net/lcs.c 2010-11-17 11:38:25.000000000 +0530
+++ linux-2.6-next-new/drivers/s390/net/lcs.c 2010-11-18 11:59:46.000000000 +0530
@@ -1269,10 +1269,10 @@ lcs_register_mc_addresses(void *data)
in4_dev = in_dev_get(card->dev);
if (in4_dev == NULL)
goto out;
- read_lock(&in4_dev->mc_list_lock);
+ rcu_read_lock();
lcs_remove_mc_addresses(card,in4_dev);
lcs_set_mc_addresses(card, in4_dev);
- read_unlock(&in4_dev->mc_list_lock);
+ rcu_read_unlock();
in_dev_put(in4_dev);
netif_carrier_off(card->dev);
diff -Narup linux-2.6-next/drivers/s390/net/qeth_l3_main.c linux-2.6-next-new/drivers/s390/net/qeth_l3_main.c
--- linux-2.6-next/drivers/s390/net/qeth_l3_main.c 2010-10-30 12:54:22.000000000 +0530
+++ linux-2.6-next-new/drivers/s390/net/qeth_l3_main.c 2010-11-18 11:59:13.000000000 +0530
@@ -1828,9 +1828,9 @@ static void qeth_l3_add_vlan_mc(struct q
in_dev = in_dev_get(netdev);
if (!in_dev)
continue;
- read_lock(&in_dev->mc_list_lock);
+ rcu_read_lock();
qeth_l3_add_mc(card, in_dev);
- read_unlock(&in_dev->mc_list_lock);
+ rcu_read_unlock();
in_dev_put(in_dev);
}
}
@@ -1843,10 +1843,10 @@ static void qeth_l3_add_multicast_ipv4(s
in4_dev = in_dev_get(card->dev);
if (in4_dev == NULL)
return;
- read_lock(&in4_dev->mc_list_lock);
+ rcu_read_lock();
qeth_l3_add_mc(card, in4_dev);
qeth_l3_add_vlan_mc(card);
- read_unlock(&in4_dev->mc_list_lock);
+ rcu_read_unlock();
in_dev_put(in4_dev);
}
^ permalink raw reply
* Re: 2.6.37-rc2 after KVM shutdown - unregister_netdevice: waiting for vmtst01eth0 to become free. Usage count = 1
From: Eric Dumazet @ 2010-11-18 9:16 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, netdev list, nikola.ciprich, Linux kernel list
In-Reply-To: <20101118062822.GB3781@pcnci.linuxbox.cz>
Le jeudi 18 novembre 2010 à 07:28 +0100, Nikola Ciprich a écrit :
> > Yep, this is a known problem, thanks !
> >
> > fix is there :
> >
> > http://patchwork.ozlabs.org/patch/71354/
> Thanks Eric, this indeed fixes the problem..
> I noticed the fix didn't make it to 2.6.37-rc2-git3 though,
> maybe it just got omited?
> anyways, thanks for help!
> n.
Its in David Miller net-2.6 tree (all pending network patches for
current linux-2.6 version), so it'll be included next time David push
its tree to Linus, dont worry ;)
^ permalink raw reply
* Re: [alsa-devel] sound playback became chopping on nfs rootfs
From: Clemens Ladisch @ 2010-11-18 9:03 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Chuck Lever, Linux-Net, Linux-ALSA
In-Reply-To: <w3ptyjfrqde.wl%kuninori.morimoto.gx@renesas.com>
Kuninori Morimoto wrote:
> I noticed that sound playback became chopping on latest Linux kernel.
> ...
> This chopping seems happen from below patch.
>
> commit 56463e50d1fc3f070492434cea6303b35ea000de
> Author: Chuck Lever <chuck.lever@oracle.com>
>
> NFS: Use super.c for NFSROOT mount option parsing
> ...
> Note that this means NFSROOT mounts now use the same default settings
> as v2/v3 mounts done via mount(2) from user space.
Apparently, the latest kernel uses different mount options.
Try to find out what mount options your root FS had in the old kernel,
and manually set them in some startup script.
Regards,
Clemens
^ permalink raw reply
* MDaemon Notification -- Attachment Removed
From: Postmaster @ 2010-11-18 8:26 UTC (permalink / raw)
To: netdev
-------------------------------------------------------------------
MDaemon has detected restricted attachments within an email message
-------------------------------------------------------------------
>From : netdev@vger.kernel.org
To : ngocht.ktkd.cv@hpport.com.vn
Subject : Message could not be delivered
Message-ID:
---------------------
Attachment(s) removed
---------------------
ngocht.ktkd.cv@hpport.com.vn.zip (ngocht.ktkd.cv@hpport.com.vn.doc .com)
^ permalink raw reply
* sound playback became chopping on nfs rootfs
From: Kuninori Morimoto @ 2010-11-18 8:24 UTC (permalink / raw)
To: Linux-Net, Linux-ALSA
Dear all
I noticed that sound playback became chopping on latest Linux kernel.
I checked it by "git bisect".
This chopping seems happen from below patch.
How to modify this chopping ?
I'm using SuperH ap4evb board.
CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs ip=dhcp"
----------------------------------------------
commit 56463e50d1fc3f070492434cea6303b35ea000de
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Fri Sep 17 10:54:37 2010 -0400
NFS: Use super.c for NFSROOT mount option parsing
Replace duplicate code in NFSROOT for mounting an NFS server on '/'
with logic that uses the existing mainline text-based logic in the NFS
client.
Add documenting comments where appropriate.
Note that this means NFSROOT mounts now use the same default settings
as v2/v3 mounts done via mount(2) from user space.
vers=3,tcp,rsize=<negotiated default>,wsize=<negotiated default>
As before, however, no version/protocol negotiation with the server is
done.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
----------------------------------------------
Best regards
--
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH 06/10] drivers/net/usb: Remove unnecessary casts of netdev_priv
From: Petko Manolov @ 2010-11-18 7:24 UTC (permalink / raw)
To: David Miller
Cc: joe, trivial, petkan, gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <20101117.104555.246530412.davem@davemloft.net>
On Wed, 17 Nov 2010, David Miller wrote:
> From: Petko Manolov <petkan@nucleusys.com>
> Date: Tue, 16 Nov 2010 19:59:29 +0200 (EET)
>
>> ACK! :-)
>
> Please do not top post.
Sorry about that.
> Also, please use a properly formed "Acked-by: " tag if you want
> your ACK to actually show up in the commit log message.
My "ack" was only a notification that i've checked the patch. It was not
meant to go into the logs.
cheers,
Petko
^ permalink raw reply
* Re: net-next-2.6 [PATCH 0/6]: dccp ccid-2: Ack Vector patch set second/concluding part II
From: Gerrit Renker @ 2010-11-18 6:42 UTC (permalink / raw)
To: David Miller; +Cc: dccp, netdev
In-Reply-To: <20101115.110459.68121782.davem@davemloft.net>
> Some of the new functions you added had some coding style quirks,
> for example the openning brace for dccp_ackvec_clear_state()
> has an unnecessary space before it on that line.
>
> Please fix those sorts of things up, thanks.
I am sorry, this glitch must have occurred since I last ran checkpatch.pl.
Please find a fix attached. I have checked all patches again, line-by-line
and using checkpatch.pl. I found only this one occurrence, checking twice.
It is also on top today's copy of net-next-2.6, on
git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
(I tried to put up the patches on top of this, but this did not work cleanly,
due to inter-dependencies. I apologize for this.)
>>>>>>>>>>>>>>>>>>>>>>>>>> Patch <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp ccid-2: whitespace fix-up
This fixes whitespace noise introduced in commit "dccp ccid-2: Algorithm to
update buffer state", 5753fdfe8bd8e9a2ff9e5af19b0ffc78bfcd502a, 14 Nov 2010.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
ackvec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/dccp/ackvec.c
+++ b/net/dccp/ackvec.c
@@ -282,7 +282,7 @@ void dccp_ackvec_input(struct dccp_ackvec *av, struct sk_buff *skb)
* packet of group (2) in 11.4.2.
*/
void dccp_ackvec_clear_state(struct dccp_ackvec *av, const u64 ackno)
- {
+{
struct dccp_ackvec_record *avr, *next;
u8 runlen_now, eff_runlen;
s64 delta;
^ permalink raw reply
* Re: 2.6.37-rc2 after KVM shutdown - unregister_netdevice: waiting for vmtst01eth0 to become free. Usage count = 1
From: Nikola Ciprich @ 2010-11-18 6:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: KVM list, netdev list, nikola.ciprich, Linux kernel list
In-Reply-To: <1289900812.5372.1.camel@edumazet-laptop>
> Yep, this is a known problem, thanks !
>
> fix is there :
>
> http://patchwork.ozlabs.org/patch/71354/
Thanks Eric, this indeed fixes the problem..
I noticed the fix didn't make it to 2.6.37-rc2-git3 though,
maybe it just got omited?
anyways, thanks for help!
n.
>
>
>
> --
> 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
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply
* Re: [1/2] of/phylib: Use device tree properties to initialize Marvell PHYs.
From: Milton Miller @ 2010-11-18 5:38 UTC (permalink / raw)
To: David Daney
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cyril Chemparathy,
Arnaud Patard
In-Reply-To: <1290038071-13296-2-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Wed, 17 Nov 2010 15:54:30 -0800, David Daney wrote:
> Some aspects of PHY initialization are board dependent, things like
> indicator LED connections and some clocking modes cannot be determined
> by probing. The dev_flags element of struct phy_device can be used to
> control these things if an appropriate value can be passed from the
> Ethernet driver. We run into problems however if the PHY connections
> are specified by the device tree. There is no way for the Ethernet
> driver to know what flags it should pass.
>
> If we are using the device tree, the struct phy_device will be
> populated with the device tree node corresponding to the PHY, and we
> can extract extra configuration information from there.
..
>
> ---
> drivers/net/phy/marvell.c | 91 +++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 91 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index f0bd1a1..33ad654 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -30,6 +30,7 @@
> #include <linux/ethtool.h>
> #include <linux/phy.h>
> #include <linux/marvell_phy.h>
> +#include <linux/of.h>
>
> #include <asm/io.h>
> #include <asm/irq.h>
> @@ -186,6 +187,85 @@ static int marvell_config_aneg(struct phy_device *phydev)
> return 0;
> }
>
> +#ifndef CONFIG_OF
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +#else
> +/*
> + * Set and/or override some configuration registers based on the
> + * marvell,reg-init property stored in the of_node for the phydev.
> + *
> + * marvell,reg-init = <reg-spec val-spec>,...;
> + *
> + * There may be one or more pairs of <reg-spec val-spec>:
> + * reg-spec [16..31]: Page address.
> + * reg-spec [0..15]: Register address.
> + *
> + * val-spec [16..31]: Mask bits.
> + * val-spec [0..15]: Register bits.
> + */
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + const __be32 *paddr;
> + int len, i, saved_page, current_page, page_changed, ret;
> +
> + if (!phydev->dev.of_node)
> + return 0;
> +
> + paddr = of_get_property(phydev->dev.of_node, "marvell,reg-init", &len);
> + if (!paddr || len < (2 * sizeof(u32)))
> + return 0;
> +
> + saved_page = phy_read(phydev, 22);
> + if (saved_page < 0)
> + return saved_page;
> + page_changed = 0;
> + current_page = saved_page;
> +
> + ret = 0;
> + len /= sizeof(u32);
> + for (i = 0; i < len / 2; i += 2) {
i < len - 1 would execute all the register inits specified in the property.
> + u32 reg_spec = be32_to_cpup(&paddr[i]);
> + u32 val_spec = be32_to_cpup(&paddr[i + 1]);
> + u16 reg = reg_spec & 0xffff;
> + u16 reg_page = reg_spec >> 16;
> + u16 val_bits = val_spec & 0xffff;
> + u16 mask = val_spec >> 16;
> + int val;
> +
While the outcome is the same, this code also mixes sizeof(u32)
with __be32 pointer math.
milton
^ permalink raw reply
* [PATCH 2.6.37-rc2] Fix duplicate volatile warning.
From: Tetsuo Handa @ 2010-11-18 4:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
Commit 0ed8ddf4 "neigh: Protect neigh->ha[] with a seqlock" made gcc 3.x
to warn
include/net/neighbour.h: In function `neigh_event_send':
include/net/neighbour.h:306: warning: duplicate `volatile'
.
----------------------------------------
>From a391f571f21bfa81369599f03e86fa75589291a3 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Thu, 18 Nov 2010 12:44:26 +0900
Subject: [PATCH 2.6.37-rc2] Fix duplicate volatile warning.
jiffies is defined as "volatile".
extern unsigned long volatile __jiffy_data jiffies;
ACCESS_ONCE() uses "volatile".
As a result, some compilers warn duplicate `volatile' for ACCESS_ONCE(jiffies).
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
include/net/neighbour.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 55590ab..6beb1ff 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -303,7 +303,7 @@ static inline void neigh_confirm(struct neighbour *neigh)
static inline int neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
- unsigned long now = ACCESS_ONCE(jiffies);
+ unsigned long now = jiffies;
if (neigh->used != now)
neigh->used = now;
--
1.7.1
^ permalink raw reply related
* Re: extended netdevice naming proposal
From: Ben Hutchings @ 2010-11-18 2:29 UTC (permalink / raw)
To: Bill Nottingham; +Cc: Matt Domsch, linux-hotplug, netdev, narendra_k, jcm
In-Reply-To: <20101118021039.GA18707@nostromo.devel.redhat.com>
On Wed, 2010-11-17 at 21:10 -0500, Bill Nottingham wrote:
> Matt Domsch (Matt_Domsch@dell.com) said:
> > (location)(slot)#(port)/(instance).(vlan)
>
> AIUI, the kernel explicitly rejects '/' in the name (for fairly obvious
> sysfs reasons.) So you'd at least need a different delimiter. There may
> also be potential confusion with pci01#03:02.0001 with someone thinking
> that's bus/dev/fn, if we're being really petty.
':' is also reserved for alias interfaces, the old way of assigning
multiple IP addresses.
I would say '-' is a good separator, but that might result in ambiguity
in IRQ names.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: extended netdevice naming proposal
From: Bill Nottingham @ 2010-11-18 2:10 UTC (permalink / raw)
To: Matt Domsch; +Cc: linux-hotplug, netdev, narendra_k, jcm
In-Reply-To: <20101117220659.GA12177@auslistsprd01.us.dell.com>
Matt Domsch (Matt_Domsch@dell.com) said:
> (location)(slot)#(port)/(instance).(vlan)
AIUI, the kernel explicitly rejects '/' in the name (for fairly obvious
sysfs reasons.) So you'd at least need a different delimiter. There may
also be potential confusion with pci01#03:02.0001 with someone thinking
that's bus/dev/fn, if we're being really petty.
Bill
^ permalink raw reply
* ixgbe dump
From: Yinghai Lu @ 2010-11-18 1:21 UTC (permalink / raw)
To: Brandeburg, Jesse, David Miller; +Cc: NetDev
[ 1546.287521] md: stopping all md devices.
[ 1547.283729] kvm: exiting hardware virtualization
[ 1547.292876] sd 2:2:1:0: [sdb] Synchronizing SCSI cache
[ 1547.293831] sd 2:2:0:0: [sda] Synchronizing SCSI cache
[ 1547.299627] BUG: unable to handle kernel NULL pointer dereference at 0000000000000033
[ 1547.315819] IP: [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
[ 1547.316448] PGD 3ff4487067 PUD 3ff216b067 PMD 0
[ 1547.335626] Oops: 0000 [#1] SMP
[ 1547.335941] last sysfs file: /sys/kernel/kexec_loaded
[ 1547.336381] CPU 0
[ 1547.336548] Modules linked in:
[ 1547.355798]
[ 1547.355968] Pid: 25630, comm: kexec Not tainted 2.6.37-rc2-tip-yh-01961-g6034289-dirty #281 /Sun Fire X4800
[ 1547.375849] RIP: 0010:[<ffffffff81746273>] [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
[ 1547.395543] RSP: 0018:ffff881fb9d49ce8 EFLAGS: 00010287
[ 1547.396080] RAX: 0000000000000000 RBX: ffff88dffe5a0940 RCX: ffff88dffe5a0940
[ 1547.415635] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffc90077780000
[ 1547.416299] RBP: ffff881fb9d49d48 R08: 0000000000000000 R09: 0000000000000000
[ 1547.435860] R10: 000000000000a608 R11: 0000000000000000 R12: 0000000000000000
[ 1547.455516] R13: ffff88dffe5a0000 R14: 0000000000003400 R15: ffff881fb9d49db7
[ 1547.456257] FS: 00000000006e0850(0063) GS:ffff88207d600000(0000) knlGS:0000000000000000
[ 1547.475937] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1547.495330] CR2: 0000000000000033 CR3: 0000003ffa77e000 CR4: 00000000000006f0
[ 1547.496009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1547.515594] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1547.516229] Process kexec (pid: 25630, threadinfo ffff881fb9d48000, task ffff881f8a57a2d0)
[ 1547.536039] Stack:
[ 1547.536244] 0000000000000040 0000002b00000000 ffff881ffedc1000 0000000000000006
[ 1547.555894] ffff88dffe5a1b40 0b00000081454ec8 ffff881fb9d49d48 ffff88dffe5a0940
[ 1547.575411] ffff881ffedc1000 000000000000001e 0000000000000000 ffff881fb9d49db7
[ 1547.576131] Call Trace:
[ 1547.595251] [<ffffffff8174a8f4>] __ixgbe_shutdown+0x9d/0x153
[ 1547.595770] [<ffffffff8174a9c4>] ixgbe_shutdown+0x1a/0x43
[ 1547.615250] [<ffffffff814574bb>] pci_device_shutdown+0x2c/0x40
[ 1547.615887] [<ffffffff8151c5e9>] device_shutdown+0x75/0xb0
[ 1547.635268] [<ffffffff8108f461>] kernel_restart_prepare+0x2c/0x33
[ 1547.635927] [<ffffffff810bc821>] kernel_kexec+0x38/0x6b
[ 1547.655252] [<ffffffff8108f618>] sys_reboot+0x156/0x194
[ 1547.655765] [<ffffffff8114422a>] ? __d_free+0x59/0x5e
[ 1547.675145] [<ffffffff81144283>] ? d_free+0x54/0x66
[ 1547.675612] [<ffffffff8114439d>] ? d_kill+0x3b/0x43
[ 1547.695025] [<ffffffff81144a1c>] ? dput+0x40/0x140
[ 1547.695539] [<ffffffff811351a9>] ? fput+0x1d7/0x1e6
[ 1547.696045] [<ffffffff81036c0c>] ? sysret_check+0x27/0x62
[ 1547.715426] [<ffffffff81cd9772>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1547.734897] [<ffffffff81036bdb>] system_call_fastpath+0x16/0x1b
[ 1547.735428] Code: d2 e9 81 00 00 00 48 8b 83 00 12 00 00 8b 80 88 50 00 00 0d 00 00 00 80 e9 a7 00 00 00 48 8b 81 00 0a 00 00 48 8b bb 00 12 00 00 <0f> b6 40 33 83 f8 3f 7f 0d 89 c6 c1 e6 06 81 c6 28 10 00 00 eb
[ 1547.775262] RIP [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
[ 1547.775909] RSP <ffff881fb9d49ce8>
[ 1547.794997] CR2: 0000000000000033
[ 1547.795987] ---[ end trace 4ed9616adc45007c ]---
^ permalink raw reply
* ethtool 2.6.36 released
From: Ben Hutchings @ 2010-11-18 0:58 UTC (permalink / raw)
To: netdev; +Cc: Jeff Garzik
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
ethtool version 2.6.36 has been released.
Home page: https://sourceforge.net/projects/gkernel/
Download link:
https://sourceforge.net/projects/gkernel/files/ethtool/2.6.36/ethtool-2.6.36.tar.gz/download
This will be the last release via Sourceforge. A new home page will
shortly be created on kernel.org resources, probably at
<https://ftp.kernel.org/pub/software/network/ethtool/>.
Release notes:
* Fix: RX n-tuple masks and documentation
* Feature: Ethernet-level RX n-tuple filtering and 'clear' action
* Feature: stmmac register dump support
* Feature: get permanent address (-P) option
* Feature: VLAN acceleration control
Jeff Garzik has handed over ongoing maintenance to me. Jeff, thanks for
all your work on ethtool over the past 10 years and for your help with
making this release.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply
* Re: extended netdevice naming proposal
From: Ben Hutchings @ 2010-11-18 0:39 UTC (permalink / raw)
To: Matt Domsch; +Cc: linux-hotplug, netdev, narendra_k, jcm, notting
In-Reply-To: <20101117220659.GA12177@auslistsprd01.us.dell.com>
On Wed, 2010-11-17 at 16:06 -0600, Matt Domsch wrote:
> While this _is_ the original bikeshedding problem, as long as I'm
> going to use biosdevname to change names for embedded NICs, perhaps I
> can be so bold as to change them for USB add-in cards too?
>
> There are quite a few dimensions to the problem:
> * device location (onboard, PCI, other bus)
> * multiple ports on a single add-in card
> * with Network Partitioning (NPAR) and SR-IOV, the OS sees multiple
> network interfaces (physical or virtual interfaces) but a single external port
> * the suffix .1234 currently used for vlans (ala vconfig)
> * A single PCI device may drive multiple external ports
>
> As such, here is a naming proposal, aimed to keep within 15
> characters for most configurations.
>
> (location)(slot)#(port)/(instance).(vlan)
>
> location := NIC on Motherboard = net1, net2, net3, net4
"net", really?! I can't say I care that much, but this just doesn't
seem like a helpful prefix.
> (note: people hated the TLA collision with 'lom', so avoiding that here).
> := PCI slot = pci1, pci2, pci3, pci4
> these correspond to chassis labels, information is available in
> $PIRQ, SMBIOS or ACPI, which biosdevname retrieves and uses.
>
> For single- or multi-port cards in PCI slots, append #(port):
> pci1#1, pci1#2, pci1#3, pci1#4 for 4 ports on a card in PCI slot 1
'#' might be problematic but I don't have any concrete evidence of that.
> There is currently no way to get this port info from BIOS. Several people
> have suggested using adding a PCI capabilities field to expose this
> info in a standard way, but that's a ways off. Until then, biosdevname
> can guess (assume ascending MAC order on the single card).
You could try using the dev_id attribute first; it's supposed to be a
0-based index of a net device on a board. It won't be unique in all
cases, e.g. if a NIC vendor has used a bridge chip to connect multiple
controllers on a single board or if the driver just doesn't set it. So
you would need to fall back to MAC order in tha tcase.
> For NPAR/SR-IOV where the physical port is shared by several
> instances, append /(instance):
> net1/1, net1/2 pci1#1/1, pci1#1/2,
> pci1#1/2, pci1#1/3, ...
[...]
Surely VFs are normally passed through to a guest, in which case:
1. The host/console/dom0 won't create a net device for them.
2. The guest won't (and shouldn't) have such information about the
physical location of the PCI function.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [RFC PATCH 0/3] e1000/e1000e/igb MDI-X control implementation
From: Ben Hutchings @ 2010-11-18 0:14 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>
On Wed, 2010-11-17 at 15:29 -0800, Jesse Brandeburg wrote:
> this patch series is RFC for implemenation, I've briefly tested
> it to make sure I still get link after setting MDI-X and I see
> the status change in ethtool.
>
> The basic idea is to fill out the MDI-X read functionality with
> some write functionality.
>
> the e1000e patch is actually what drove this change as some users
> have found wonky switches that must have MDI/MDI-X forced.
[...]
I object to all these for the reasons explained in my comments on the
changes to the ethtool utility.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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
* [PATCH net-next-2.6] can: EG20T PCH: use BIT(X)
From: Tomoya MORINAGA @ 2010-11-18 0:06 UTC (permalink / raw)
To: Wolfgang Grandegger, Wolfram Sang, Christian Pellegrin,
Barry Song, Samuel Ortiz
Cc: qi.wang, yong.y.wang, andrew.chih.howe.khor, joel.clark,
kok.howg.ewe, margie.foster
Replace bit assignment value to BIT(X).
For easy to readable/identifiable, replace all bit assigned macros to BIT(X)
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/pch_can.c | 73 +++++++++++++++++++++++----------------------
1 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index c523e3d..238622a 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -38,50 +38,51 @@
#define PCH_ENABLE 1 /* The enable flag */
#define PCH_DISABLE 0 /* The disable flag */
-#define PCH_CTRL_INIT 0x0001 /* The INIT bit of CANCONT register. */
-#define PCH_CTRL_IE 0x0002 /* The IE bit of CAN control register */
-#define PCH_CTRL_IE_SIE_EIE 0x000e
-#define PCH_CTRL_CCE 0x0040
-#define PCH_CTRL_OPT 0x0080 /* The OPT bit of CANCONT register. */
-#define PCH_OPT_SILENT 0x0008 /* The Silent bit of CANOPT reg. */
-#define PCH_OPT_LBACK 0x0010 /* The LoopBack bit of CANOPT reg. */
+#define PCH_CTRL_INIT BIT(0) /* The INIT bit of CANCONT register. */
+#define PCH_CTRL_IE BIT(1) /* The IE bit of CAN control register */
+#define PCH_CTRL_IE_SIE_EIE (BIT(3) | BIT(2) | BIT(1))
+#define PCH_CTRL_CCE BIT(6)
+#define PCH_CTRL_OPT BIT(7) /* The OPT bit of CANCONT register. */
+#define PCH_OPT_SILENT BIT(3) /* The Silent bit of CANOPT reg. */
+#define PCH_OPT_LBACK BIT(4) /* The LoopBack bit of CANOPT reg. */
+
#define PCH_CMASK_RX_TX_SET 0x00f3
#define PCH_CMASK_RX_TX_GET 0x0073
#define PCH_CMASK_ALL 0xff
-#define PCH_CMASK_RDWR 0x80
-#define PCH_CMASK_ARB 0x20
-#define PCH_CMASK_CTRL 0x10
-#define PCH_CMASK_MASK 0x40
-#define PCH_CMASK_NEWDAT 0x04
-#define PCH_CMASK_CLRINTPND 0x08
-#define PCH_IF_MCONT_NEWDAT 0x8000
-#define PCH_IF_MCONT_INTPND 0x2000
-#define PCH_IF_MCONT_UMASK 0x1000
-#define PCH_IF_MCONT_TXIE 0x0800
-#define PCH_IF_MCONT_RXIE 0x0400
-#define PCH_IF_MCONT_RMTEN 0x0200
-#define PCH_IF_MCONT_TXRQXT 0x0100
-#define PCH_IF_MCONT_EOB 0x0080
-#define PCH_IF_MCONT_DLC 0x000f
-#define PCH_IF_MCONT_MSGLOST 0x4000
-#define PCH_MASK2_MDIR_MXTD 0xc000
-#define PCH_ID2_DIR 0x2000
-#define PCH_ID2_XTD 0x4000
-#define PCH_ID_MSGVAL 0x8000
-#define PCH_IF_CREQ_BUSY 0x8000
+#define PCH_CMASK_NEWDAT BIT(2)
+#define PCH_CMASK_CLRINTPND BIT(3)
+#define PCH_CMASK_CTRL BIT(4)
+#define PCH_CMASK_ARB BIT(5)
+#define PCH_CMASK_MASK BIT(6)
+#define PCH_CMASK_RDWR BIT(7)
+#define PCH_IF_MCONT_NEWDAT BIT(15)
+#define PCH_IF_MCONT_MSGLOST BIT(14)
+#define PCH_IF_MCONT_INTPND BIT(13)
+#define PCH_IF_MCONT_UMASK BIT(12)
+#define PCH_IF_MCONT_TXIE BIT(11)
+#define PCH_IF_MCONT_RXIE BIT(10)
+#define PCH_IF_MCONT_RMTEN BIT(9)
+#define PCH_IF_MCONT_TXRQXT BIT(8)
+#define PCH_IF_MCONT_EOB BIT(7)
+#define PCH_IF_MCONT_DLC (BIT(0) | BIT(1) | BIT(2) | BIT(3))
+#define PCH_MASK2_MDIR_MXTD (BIT(14) | BIT(15))
+#define PCH_ID2_DIR BIT(13)
+#define PCH_ID2_XTD BIT(14)
+#define PCH_ID_MSGVAL BIT(15)
+#define PCH_IF_CREQ_BUSY BIT(15)
#define PCH_STATUS_INT 0x8000
#define PCH_REC 0x00007f00
#define PCH_TEC 0x000000ff
-#define PCH_RX_OK 0x00000010
-#define PCH_TX_OK 0x00000008
-#define PCH_BUS_OFF 0x00000080
-#define PCH_EWARN 0x00000040
-#define PCH_EPASSIV 0x00000020
-#define PCH_LEC0 0x00000001
-#define PCH_LEC1 0x00000002
-#define PCH_LEC2 0x00000004
+#define PCH_TX_OK BIT(3)
+#define PCH_RX_OK BIT(4)
+#define PCH_EPASSIV BIT(5)
+#define PCH_EWARN BIT(6)
+#define PCH_BUS_OFF BIT(7)
+#define PCH_LEC0 BIT(0)
+#define PCH_LEC1 BIT(1)
+#define PCH_LEC2 BIT(2)
#define PCH_LEC_ALL (PCH_LEC0 | PCH_LEC1 | PCH_LEC2)
#define PCH_STUF_ERR PCH_LEC0
#define PCH_FORM_ERR PCH_LEC1
--
1.6.0.6
^ permalink raw reply related
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