* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 19:33 UTC (permalink / raw)
To: gregory.v.rose
Cc: leedom, shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, alexander.h.duyck
In-Reply-To: <43F901BD926A4E43B106BF17856F0755F1846247@orsmsx508.amr.corp.intel.com>
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
Date: Wed, 21 Jul 2010 12:02:17 -0700
>>From: David Miller <davem@davemloft.net>
>>Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
>>
>>> You could do things like have the PF controller use the root
>>filesystem
>>> ID label to construct the VF's MAC address, or something like that.
>>
>>And here I of course mean the root filesystem of the guest the VF will
>>be given to.
>
> I suppose you could do that but then the VM is going to have to be
> allowed to set its own MAC address. There is a lot of opposition
> and concern about allowing VMs to set their own MAC address.
Why would that be necessary? The host with the PF creating the guest
has access to the "device" and thus the root filesystem of the guest,
and thus could pull in the root filesystem "key" and instantiate the
VF's MAC before booting the guest.
That was the idea, the control node sets up the VF MAC before the guest
boots or can have access to the VF device.
This is completely agnostic of migration or anything like that. The
procedure for setting the VF MAC is always the same.
^ permalink raw reply
* Re: [PATCH 0/2] Support untagged symlinks to tagged directories.
From: Greg KH @ 2010-07-21 19:02 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, Andrew Morton, Rafael J. Wysocki, Maciej W. Rozycki,
Kay Sievers, Johannes Berg, netdev
In-Reply-To: <m139vd5sms.fsf_-_@fess.ebiederm.org>
On Tue, Jul 20, 2010 at 10:08:27PM -0700, Eric W. Biederman wrote:
>
> Greg KH <gregkh@suse.de> writes:
>
> > On Mon, Jul 19, 2010 at 01:34:51PM -0700, Andrew Morton wrote:
> >> On Thu, 8 Jul 2010 16:06:01 -0700
> >> Greg KH <greg@kroah.com> wrote:
> >>
> >> > On Thu, Jul 08, 2010 at 03:28:53PM -0700, Eric W. Biederman wrote:
> >> > > Greg KH <greg@kroah.com> writes:
> >> > >
> >> > > > With this patch, how does the existing code fail as the drivers aren't
> >> > > > fixed up?
> >> > > >
> >> > > > I like this change, just worried it will cause problems if it gets into
> >> > > > .35, without your RFC patch. Will it?
> >> > >
> >>
> >> geethanks!
> >>
> >> On the FC6 test box I have no networking.
> >
> > Ick.
> >
> > Eric, any ideas?
>
> Yes. I just found some time to test my fixes and things are looking
> good. It really is just two one line fixes.
>
> On the other part of this debug with SYSFS_DEPRECATED enabled it
> with mac80211_hwsim drivers works fine no problems. I expect the
> bnep driver will also be fine.
>
> What is affecting those two is arguably a bug in the non-deprecated
> sysfs mode.
>
> Regardless here are my fixes. I have split this into a patch for
> the warning and a patch for sysfs_delete_link. Because at least
> the sysfs_delete_link code needs to make into 2.6.35 if we can.
Do these patches obsolete the existing one I have in my tree entitled:
Subject: sysfs: Don't allow the creation of symlinks we can't remove
or are they on top of that one?
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Rose, Gregory V @ 2010-07-21 19:02 UTC (permalink / raw)
To: David Miller
Cc: leedom@chelsio.com, shemminger@vyatta.com, andy@greyhouse.net,
harald@redhat.com, bhutchings@solarflare.com, sassmann@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
gospo@redhat.com, Duyck, Alexander H
In-Reply-To: <20100721.115023.69942880.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, July 21, 2010 11:50 AM
>To: Rose, Gregory V
>Cc: leedom@chelsio.com; shemminger@vyatta.com; andy@greyhouse.net;
>harald@redhat.com; bhutchings@solarflare.com; sassmann@redhat.com;
>netdev@vger.kernel.org; linux-kernel@vger.kernel.org; gospo@redhat.com;
>Duyck, Alexander H
>Subject: Re: [PATCH net-next] sysfs: add entry to indicate network
>interfaces with random MAC address
>
>From: David Miller <davem@davemloft.net>
>Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
>
>> You could do things like have the PF controller use the root
>filesystem
>> ID label to construct the VF's MAC address, or something like that.
>
>And here I of course mean the root filesystem of the guest the VF will
>be given to.
I suppose you could do that but then the VM is going to have to be allowed to set its own MAC address. There is a lot of opposition and concern about allowing VMs to set their own MAC address.
Then there's also support in the kernel now for assigning VF MAC and VLAN via the iproute2 package "ip link" commands. The administrative SW that controls VMs should be assigning MAC addresses to VFs as needed. When the VF is de-assigned from the guest because the VM is migrating then the administrative SW can assign another VF to the VM at the migration target machine and assign the same MAC address then. This way it is all done administratively from the (supposedly) secure host VMM domain and we're not allowing VMs to set their own MAC address.
Ultimately I think I agree that some sort of approach such as you and others have been suggesting should be taken. I'm agnostic about which one because my view of how things should work is a bit different. But if the community thinks that finding some way to set a persistent MAC address for a VF is useful then I'd more than happy to make sure our drivers support that also.
As soon as it is decided what that is of course.
;-)
- Greg
^ permalink raw reply
* [patch] usbnet: fix 100% CPU use on suspended device
From: Elly Jones @ 2010-07-21 18:51 UTC (permalink / raw)
To: netdev
Subject: [patch] usbnet: fix 100% CPU use on suspended device
From: Elly Jones <ellyjones@google.com>
This patch causes the usbnet module not to attempt to submit URBs to the device
if the device is not ready to accept them. This fixes a misbehavior trigged by
the Qualcomm Gobi driver (released under GPL through their Code Aurora
initiative) which causes the usbnet core to consume 100% of CPU attempting and
failing to submit URBs. This patch is against Linus's 2.6 repo commit
a9f7f2e74ae0e6a801a2433dc8e9124d73da0cb4.
Signed-off-by: Elizabeth Jones <ellyjones@google.com>
---
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 81c76ad..df7e72e 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1172,6 +1172,7 @@ static void usbnet_bh (unsigned long param)
// or are we maybe short a few urbs?
} else if (netif_running (dev->net) &&
netif_device_present (dev->net) &&
+ dev->udev->can_submit &&
!timer_pending (&dev->delay) &&
!test_bit (EVENT_RX_HALT, &dev->flags)) {
int temp = dev->rxq.qlen;
^ permalink raw reply related
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 18:50 UTC (permalink / raw)
To: gregory.v.rose
Cc: leedom, shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, alexander.h.duyck
In-Reply-To: <20100721.114851.200597269.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
> You could do things like have the PF controller use the root filesystem
> ID label to construct the VF's MAC address, or something like that.
And here I of course mean the root filesystem of the guest the VF will
be given to.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 18:48 UTC (permalink / raw)
To: gregory.v.rose
Cc: leedom, shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, alexander.h.duyck
In-Reply-To: <43F901BD926A4E43B106BF17856F0755F184620A@orsmsx508.amr.corp.intel.com>
From: "Rose, Gregory V" <gregory.v.rose@intel.com>
Date: Wed, 21 Jul 2010 11:43:19 -0700
> Intel's view of things is that we don't use persistent MAC addresses
> in our VFs because the MAC address belongs to the VM and when it
> migrates it's going to want to use another VF with the same MAC
> address. If they're persistent I'm wondering how that can be done.
>
> This discussion has come about because some folks want to use the VF
> in the Host VMM. The original design goal for Intel was that VFs
> would be assigned to VMs and that VMM vendors would want to assign
> MAC addresses with their own assigned OUI's.
If the VM itself is the "physical entity" of the system, the logical
conclusion I come to is that some kind of key should be obtained
through the VM to uniquely give the device a persistent MAC.
You could do things like have the PF controller use the root filesystem
ID label to construct the VF's MAC address, or something like that.
^ permalink raw reply
* Re: [PATCH] LSM: Add post recvmsg() hook.
From: David Miller @ 2010-07-21 18:45 UTC (permalink / raw)
To: penguin-kernel
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, paul.moore, netdev,
linux-security-module
In-Reply-To: <201007171017.DFC73498.SFFFOMLVJOHOtQ@I-love.SAKURA.ne.jp>
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Sat, 17 Jul 2010 10:17:10 +0900
> NETWORKING [IPv4/IPv6] maintainers and Paul, is below patch fine for you?
Unfortunately, after further consideration, I must reject this patch
and also the post accept() LSM hook one.
Sorry.
I looked into history of the discussions on this issue, and I have found
that the core issue with these hooks has not been addressed.
We must ensure that if:
1) Application makes poll() on UDP socket in blocking mode, and UDP
reports that receive data is available
and
2) Application, after such a poll() call, makes a blocking recvmsg() call
and no other activity has occurred on the socket meanwhile
Then we MUST return immediately with that available data.
This LSM hook, when it triggers, can violate this rule, even if you do
this looping thing.
The post accept() hook has the same problems.
Here is where we originally discussed this, in detail:
http://www.spinics.net/lists/netdev/msg95660.html
Therefore, I think this shows that what Tomoyo is trying to do is
fatally flawed. We brought this fundamental issue up to you about a
year ago, and the issue is still not addressed.
So consider very seriously, that what you are trying to do cannot be
performed without breaking applications and API behavioral
expectations.
^ permalink raw reply
* RE: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Rose, Gregory V @ 2010-07-21 18:43 UTC (permalink / raw)
To: Casey Leedom, David Miller
Cc: shemminger@vyatta.com, andy@greyhouse.net, harald@redhat.com,
bhutchings@solarflare.com, sassmann@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
gospo@redhat.com, Duyck, Alexander H
In-Reply-To: <201007211129.48288.leedom@chelsio.com>
>-----Original Message-----
>From: Casey Leedom [mailto:leedom@chelsio.com]
>Sent: Wednesday, July 21, 2010 11:30 AM
>To: David Miller
>Cc: shemminger@vyatta.com; andy@greyhouse.net; harald@redhat.com;
>bhutchings@solarflare.com; sassmann@redhat.com; netdev@vger.kernel.org;
>linux-kernel@vger.kernel.org; gospo@redhat.com; Rose, Gregory V; Duyck,
>Alexander H
>Subject: Re: [PATCH net-next] sysfs: add entry to indicate network
>interfaces with random MAC address
>
>| From: David Miller <davem@davemloft.net>
>| Date: Wednesday, July 21, 2010 10:32 am
>|
>| From: Stephen Hemminger <shemminger@vyatta.com>
>| Date: Wed, 21 Jul 2010 10:28:16 -0700
>|
>| > IMHO no local assigned address should be used by udev. The cxgb4
>driver
>| > should be using random value.
>| >
>| > Does anyone have an example of locally assigned address that has
>| > persistence so that udev could use it.
>|
>| The cxgb4 vf addresses are not random because they are fetched from
>the
>| card's NVRAM/EEPROM/firmware/whatever and thus are persistent.
>|
>| We definitely want udev to use persistent rules for them.
>|
>| This whole issue only exists because of the Intel VF case, where it
>| lacks persistent addresses but somehow we want to assign persistent
>| names to it's VF interfaces.
>
> Yes, we _explicitly_ wanted to have persistent MAC Addresses for our
>PCI-E SR-
>IOV Virtual Functions for a whole raft of reasons. The two most
>important were:
>
> 1. Linux' model for persistent device naming today seems to be
> oriented around persistent network device addresses.
>
> 2. Lots of data centers use MAC addresses for things like DHCP/BOOTP,
> security/filtering, etc.
>
>Our design goal was to look as much like a normal Ethernet MAC as
>possible in
>order to reduce the need for software/behavior changes.
I'm curious, what happens when the VM using the VF migrates to a new machine and has another VF assigned to with a different MAC address?
Intel's view of things is that we don't use persistent MAC addresses in our VFs because the MAC address belongs to the VM and when it migrates it's going to want to use another VF with the same MAC address. If they're persistent I'm wondering how that can be done.
This discussion has come about because some folks want to use the VF in the Host VMM. The original design goal for Intel was that VFs would be assigned to VMs and that VMM vendors would want to assign MAC addresses with their own assigned OUI's.
- Greg
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 18:39 UTC (permalink / raw)
To: leedom
Cc: shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <201007211129.48288.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Wed, 21 Jul 2010 11:29:47 -0700
> Another option might be to have a new Net Device Operations call to ask the
> adapter for a Unique Key. This could be formed for most devices via a tuple of
> the {PCI Vendor ID, PCI Device ID, Adapter Serial Number, Port Number, [and if
> applicable] Adapter Function ID}. Of course this could be a fairly long string
> ... :-)
If a unique key were available, it could be used to generate a persistent
MAC address.
And this sort of means that these drivers could use bits of the
device's geographic ID the construct persistent MAC addresses, but
only if done in a MAC namespace that could be guarenteed unique on the
local system.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Casey Leedom @ 2010-07-21 18:29 UTC (permalink / raw)
To: David Miller
Cc: shemminger, andy, harald, bhutchings, sassmann, netdev,
linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721.103249.107094774.davem@davemloft.net>
| From: David Miller <davem@davemloft.net>
| Date: Wednesday, July 21, 2010 10:32 am
|
| From: Stephen Hemminger <shemminger@vyatta.com>
| Date: Wed, 21 Jul 2010 10:28:16 -0700
|
| > IMHO no local assigned address should be used by udev. The cxgb4 driver
| > should be using random value.
| >
| > Does anyone have an example of locally assigned address that has
| > persistence so that udev could use it.
|
| The cxgb4 vf addresses are not random because they are fetched from the
| card's NVRAM/EEPROM/firmware/whatever and thus are persistent.
|
| We definitely want udev to use persistent rules for them.
|
| This whole issue only exists because of the Intel VF case, where it
| lacks persistent addresses but somehow we want to assign persistent
| names to it's VF interfaces.
Yes, we _explicitly_ wanted to have persistent MAC Addresses for our PCI-E SR-
IOV Virtual Functions for a whole raft of reasons. The two most important were:
1. Linux' model for persistent device naming today seems to be
oriented around persistent network device addresses.
2. Lots of data centers use MAC addresses for things like DHCP/BOOTP,
security/filtering, etc.
Our design goal was to look as much like a normal Ethernet MAC as possible in
order to reduce the need for software/behavior changes.
| One idea I've proposed in other discussions about this is that if the
| address is not persistent (either via the MAC address bit or the sysfs
| value we're thinking of providing here) we use the device's geographic
| location ("device path") as the key for udev stuff.
Another option might be to have a new Net Device Operations call to ask the
adapter for a Unique Key. This could be formed for most devices via a tuple of
the {PCI Vendor ID, PCI Device ID, Adapter Serial Number, Port Number, [and if
applicable] Adapter Function ID}. Of course this could be a fairly long string
... :-)
Casey
^ permalink raw reply
* Re: [patch 3/3] drivers/net/82596.c: fix warning
From: David Miller @ 2010-07-21 18:18 UTC (permalink / raw)
To: akpm; +Cc: netdev, segooon
In-Reply-To: <201007202225.o6KMPIQd021449@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 20 Jul 2010 15:25:18 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
>
> drivers/net/82596.c: In function 'i596_open':
> drivers/net/82596.c:1044: warning: label 'err_irq_dev' defined but not used
>
> Caused by "82596: free resources on error"
>
> Cc: Kulikov Vasiliy <segooon@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When this hit the -mm tree, I replied to the -mm postinging that I applied
it to net-next-2.6
So it's integrated already :-)
^ permalink raw reply
* Re: [patch 2/3] arch/um/drivers: remove duplicate structure field initialization
From: David Miller @ 2010-07-21 18:17 UTC (permalink / raw)
To: akpm; +Cc: netdev, julia, shemminger
In-Reply-To: <201007202225.o6KMPHA3021446@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 20 Jul 2010 15:25:17 -0700
> From: Julia Lawall <julia@diku.dk>
>
> There are two initializations of ndo_set_mac_address, one to a local
> function that is not used otherwise and one to a function that is defined
> elsewhere.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
>
> akpm:
>
> - Use the standard eth_mac_addr() in uml_net_set_mac()
>
> - Remove unneeded and racy local set_ether_mac()
>
> - Remove duplicated (and incorrect)
> uml_netdev_ops.ndo_set_mac_address initializer.
>
> Fixes 8bb95b39a16ed55226810596f92216c53329d2fe ("uml: convert network
> device to netdevice ops").
>
> [akpm@linux-foundation.org: rework as above]
> Signed-off-by: Julia Lawall <julia@diku.dk>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [patch 1/3] drivers/net/cxgb3/t3_hw.c: use new hex_to_bin() method
From: David Miller @ 2010-07-21 18:17 UTC (permalink / raw)
To: akpm; +Cc: netdev, ext-andriy.shevchenko, divy
In-Reply-To: <201007202225.o6KMPGnA021443@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 20 Jul 2010 15:25:16 -0700
> From: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
>
> Get rid of own implementation of hex_to_bin().
>
> Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
> Acked-by: Divy Le Ray <divy@chelsio.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH 0/3 net-2.6] bnx2x: Bug fixes in statistics handling
From: David Miller @ 2010-07-21 18:12 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong, dmitry
In-Reply-To: <1279727936.14094.41.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 21 Jul 2010 18:58:55 +0300
> Dave, pls., consider applying the following patches to the net-2.6 tree.
> They include 2 bugs fixes in the statistics handling flow:
All applied.
There is a space character at the beginning of every "Signed-off-by:"
line in your patch postings, please get rid of them for future
submissions.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller @ 2010-07-21 17:32 UTC (permalink / raw)
To: shemminger
Cc: leedom, andy, harald, bhutchings, sassmann, netdev, linux-kernel,
gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721102816.4bef5ada@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 21 Jul 2010 10:28:16 -0700
> IMHO no local assigned address should be used by udev. The cxgb4 driver
> should be using random value.
>
> Does anyone have an example of locally assigned address that has persistence
> so that udev could use it.
The cxgb4 vf addresses are not random because they are fetched from the
card's NVRAM/EEPROM/firmware/whatever and thus are persistent.
We definitely want udev to use persistent rules for them.
This whole issue only exists because of the Intel VF case, where it
lacks persistent addresses but somehow we want to assign persistent
names to it's VF interfaces.
One idea I've proposed in other discussions about this is that if the
address is not persistent (either via the MAC address bit or the sysfs
value we're thinking of providing here) we use the device's geographic
location ("device path") as the key for udev stuff.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Stephen Hemminger @ 2010-07-21 17:28 UTC (permalink / raw)
To: Casey Leedom
Cc: Andy Gospodarek, Harald Hoyer, David Miller, bhutchings, sassmann,
netdev, linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <201007210934.27986.leedom@chelsio.com>
On Wed, 21 Jul 2010 09:34:27 -0700
Casey Leedom <leedom@chelsio.com> wrote:
> | From: Andy Gospodarek <andy@greyhouse.net>
> | Date: Wednesday, July 21, 2010 08:07 am
> |
> | Agreed. The subtle difference between a locally assigned address that
> | is persistent and one that is random would be helpful.
>
> And just to point out that this case _does_ exist: the igb/igbvf drivers use
> random_ether_addr() to generate a random, locally assigned MAC address for the
> PCI-E SR-IOV Virtual Function MAC Addresses while the cxgb4/cxgb4vf drivers use
> a persistent, non-random locally assigned MAC Addresses.
>
> Note that I am neither arguing for nor against the proposal. I'm just
> pointing out an existence case for the distinction. And yes, bit 1 being set in
> the first octet of a MAC address for locally assigned MAC Addresses is part of
> the IEEE 802 specification just as bit 0 being set in the same octet indicates
> that it's a multi-station address.
IMHO no local assigned address should be used by udev. The cxgb4 driver
should be using random value.
Does anyone have an example of locally assigned address that has persistence
so that udev could use it.
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: David Miller @ 2010-07-21 17:23 UTC (permalink / raw)
To: buytenh-OLH4Qvv75CYX/NnBR394Jw
Cc: karl.beldan-Re5JQEeQqe8AvxtiuMwx3w, vapier-aBrp7R+bbdUdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, graf.yang-OyLXuOCK7orQT0dZR+AlfA,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <20100721151608.GM21121-SHk0+jKqY/D5VnbZ9m/NDkB+6BGkLq7r@public.gmane.org>
From: Lennert Buytenhek <buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>
Date: Wed, 21 Jul 2010 17:16:08 +0200
> On Wed, Jul 21, 2010 at 09:37:22AM -0400, Mike Frysinger wrote:
>
>> +#define pr_fmt(fmt) "ksz8893m: " fmt
>
> This has no users.
egrep pr_fmt include/linux/kernel.h
It feeds into all of the various kernel logging interfaces.
^ permalink raw reply
* Re: net/dsa
From: Karl Beldan @ 2010-07-21 17:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100720215417.GF21121@mail.wantstofly.org>
http://www.mail-archive.com/uclinux-dist-devel@blackfin.uclinux.org/msg04218.html
^ permalink raw reply
* Re: [PATCH net-2.6] ixgbe/igb: catch invalid VF settings
From: Chris Wright @ 2010-07-21 16:50 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, chrisw
In-Reply-To: <1279730431-17156-1-git-send-email-andy@greyhouse.net>
* Andy Gospodarek (andy@greyhouse.net) wrote:
> Some ixgbe cards put an invalid VF device ID in the PCIe SR-IOV
> capability. The ixgbe driver is only valid for PFs or non SR-IOV
> hardware. It seems that the same problem could occur on igb hardware as
> well, so if we discover we are trying to initialize a VF in ixbge_probe
> or igb_probe, print an error and exit.
>
> Based on a patch for ixgbe from Chris Wright <chrisw@sous-sol.org>.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Cc: Chris Wright <chrisw@sous-sol.org>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Only seen this on ixgbe, but since the result there is a kernel panic
makes sense to be defensive.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Joe Perches @ 2010-07-21 16:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Lennert Buytenhek, Mike Frysinger, netdev, David S. Miller,
uclinux-dist-devel, Karl Beldan, Graf Yang, Bryan Wu
In-Reply-To: <1279726393.2452.60.camel@edumazet-laptop>
On Wed, 2010-07-21 at 17:33 +0200, Eric Dumazet wrote:
> It is used by all pr_err() friends
Shouldn't these drivers be moved into
something like drivers/net/dsa/ rather
than be kept in net?
The #define pr_fmt would be more standard as
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
The printks could be netdev_<level>
Suggested patches:
diff --git a/net/dsa/ksz8893m.c b/net/dsa/ksz8893m.c
index 98cce04..80fb0ac 100644
--- a/net/dsa/ksz8893m.c
+++ b/net/dsa/ksz8893m.c
@@ -8,7 +8,7 @@
* Licensed under the GPL-2 or later.
*/
-#define pr_fmt(fmt) "ksz8893m: " fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/list.h>
#include <linux/netdevice.h>
@@ -42,11 +42,14 @@ static int ksz8893m_read(unsigned char *din, unsigned char reg, int len)
spi_message_init(&message);
spi_message_add_tail(t, &message);
ret = spi_sync(sw.dev, &message);
- if (!ret)
- return message.status;
+ if (ret) {
+ pr_err("read reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+ }
+ if (message.status)
+ pr_err("read reg%d failed, status=%d\n", reg, message.status);
- pr_err("read reg%d failed, ret=%d\n", reg, ret);
- return ret;
+ return message.status;
}
static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
@@ -65,11 +68,14 @@ static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
spi_message_init(&message);
spi_message_add_tail(t, &message);
ret = spi_sync(sw.dev, &message);
- if (!ret)
- return message.status;
+ if (ret) {
+ pr_err("write reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+ }
+ if (message.status)
+ pr_err("write reg%d failed, status=%d\n", reg, message.status);
- pr_err("write reg%d failed, ret=%d\n", reg, ret);
- return ret;
+ return message.status;
}
static char *ksz8893m_probe(struct mii_bus *bus, int sw_addr)
@@ -168,8 +174,8 @@ static int ksz8893m_setup_port(struct dsa_switch *ds, int p)
if (val < 0)
return val;
val |= AN_ENABLE | FORCE_100 | FORCE_FULL_DUPLEX;
- val &= ~(POWER_DOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |\
- DISABLE_TRANSMIT | DISABLE_LED);
+ val &= ~(POWER_DOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |
+ DISABLE_TRANSMIT | DISABLE_LED);
ret = mdiobus_write(ds->master_mii_bus, p, MII_BMCR, val);
if (ret < 0)
return ret;
@@ -228,8 +234,7 @@ ksz8893m_phy_read(struct dsa_switch *ds, int port, int regnum)
}
static int
-ksz8893m_phy_write(struct dsa_switch *ds,
- int port, int regnum, u16 val)
+ksz8893m_phy_write(struct dsa_switch *ds, int port, int regnum, u16 val)
{
int phy_addr = ksz8893m_port_to_phy_addr(port);
return mdiobus_write(ds->master_mii_bus, phy_addr, regnum, val);
@@ -263,7 +268,7 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
if (!link) {
if (netif_carrier_ok(dev)) {
- printk(KERN_INFO "%s: link down\n", dev->name);
+ netdev_info(dev, "link down\n");
netif_carrier_off(dev);
}
continue;
@@ -274,8 +279,8 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
val = mdiobus_read(ds->master_mii_bus, i, MII_BMSR);
if (val < 0)
continue;
- val &= HALF_10_CAPABLE | FULL_10_CAPABLE |\
- HALF_100_CAPABLE | FULL_100_CAPABLE;
+ val &= (HALF_10_CAPABLE | FULL_10_CAPABLE |
+ HALF_100_CAPABLE | FULL_100_CAPABLE);
if (val & FULL_100_CAPABLE) {
speed = 100;
duplex = 1;
@@ -288,8 +293,8 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
}
if (!netif_carrier_ok(dev)) {
- printk(KERN_INFO "%s: link up, %d Mb/s, %s duplex\n",
- dev->name, speed, duplex ? "full" : "half");
+ netdev_info(dev, "link up, %d Mb/s, %s duplex\n",
+ speed, duplex ? "full" : "half");
netif_carrier_on(dev);
}
}
^ permalink raw reply related
* [PATCH net-2.6] ixgbe/igb: catch invalid VF settings
From: Andy Gospodarek @ 2010-07-21 16:40 UTC (permalink / raw)
To: netdev; +Cc: chrisw
Some ixgbe cards put an invalid VF device ID in the PCIe SR-IOV
capability. The ixgbe driver is only valid for PFs or non SR-IOV
hardware. It seems that the same problem could occur on igb hardware as
well, so if we discover we are trying to initialize a VF in ixbge_probe
or igb_probe, print an error and exit.
Based on a patch for ixgbe from Chris Wright <chrisw@sous-sol.org>.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Cc: Chris Wright <chrisw@sous-sol.org>
---
drivers/net/igb/igb_main.c | 9 +++++++++
drivers/net/ixgbe/ixgbe_main.c | 9 +++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 3881918..cea37e0 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1722,6 +1722,15 @@ static int __devinit igb_probe(struct pci_dev *pdev,
u16 eeprom_apme_mask = IGB_EEPROM_APME;
u32 part_num;
+ /* Catch broken hardware that put the wrong VF device ID in
+ * the PCIe SR-IOV capability.
+ */
+ if (pdev->is_virtfn) {
+ WARN(1, KERN_ERR "%s (%hx:%hx) should not be a VF!\n",
+ pci_name(pdev), pdev->vendor, pdev->device);
+ return -EINVAL;
+ }
+
err = pci_enable_device_mem(pdev);
if (err)
return err;
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 7b5d976..74d9b6d 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6492,6 +6492,15 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
#endif
u32 part_num, eec;
+ /* Catch broken hardware that put the wrong VF device ID in
+ * the PCIe SR-IOV capability.
+ */
+ if (pdev->is_virtfn) {
+ WARN(1, KERN_ERR "%s (%hx:%hx) should not be a VF!\n",
+ pci_name(pdev), pdev->vendor, pdev->device);
+ return -EINVAL;
+ }
+
err = pci_enable_device_mem(pdev);
if (err)
return err;
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Casey Leedom @ 2010-07-21 16:34 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Harald Hoyer, David Miller, shemminger, bhutchings, sassmann,
netdev, linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721150732.GR7497@gospo.rdu.redhat.com>
| From: Andy Gospodarek <andy@greyhouse.net>
| Date: Wednesday, July 21, 2010 08:07 am
|
| Agreed. The subtle difference between a locally assigned address that
| is persistent and one that is random would be helpful.
And just to point out that this case _does_ exist: the igb/igbvf drivers use
random_ether_addr() to generate a random, locally assigned MAC address for the
PCI-E SR-IOV Virtual Function MAC Addresses while the cxgb4/cxgb4vf drivers use
a persistent, non-random locally assigned MAC Addresses.
Note that I am neither arguing for nor against the proposal. I'm just
pointing out an existence case for the distinction. And yes, bit 1 being set in
the first octet of a MAC address for locally assigned MAC Addresses is part of
the IEEE 802 specification just as bit 0 being set in the same octet indicates
that it's a multi-station address.
Casey
^ permalink raw reply
* [PATCH 2/2 v2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Mike Frysinger @ 2010-07-21 16:29 UTC (permalink / raw)
To: netdev, David S. Miller
Cc: uclinux-dist-devel, Karl Beldan, Lennert Buytenhek, Graf Yang,
Bryan Wu
In-Reply-To: <1279719442-10174-2-git-send-email-vapier@gentoo.org>
From: Graf Yang <graf.yang@analog.com>
Signed-off-by: Graf Yang <graf.yang@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
v2
- clean up header duplication
net/dsa/Kconfig | 7 +
net/dsa/Makefile | 1 +
net/dsa/ksz8893m.c | 341 ++++++++++++++++++++++++++++++++++++++++++++++++++++
net/dsa/ksz8893m.h | 163 +++++++++++++++++++++++++
4 files changed, 512 insertions(+), 0 deletions(-)
create mode 100644 net/dsa/ksz8893m.c
create mode 100644 net/dsa/ksz8893m.h
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index ee8d705..4a87436 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -60,4 +60,11 @@ config NET_DSA_MV88E6123_61_65
This enables support for the Marvell 88E6123/6161/6165
ethernet switch chips.
+config NET_DSA_KSZ8893M
+ bool "MICREL KSZ8893MQL/BL ethernet switch chip support"
+ select NET_DSA_TAG_STPID
+ ---help---
+ This enables support for the Micrel KSZ8893MQL/BL
+ ethernet switch chips.
+
endif
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index 4881577..c4295e3 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_NET_DSA_MV88E6XXX) += mv88e6xxx.o
obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_MV88E6123_61_65) += mv88e6123_61_65.o
obj-$(CONFIG_NET_DSA_MV88E6131) += mv88e6131.o
+obj-$(CONFIG_NET_DSA_KSZ8893M) += ksz8893m.o
# the core
obj-$(CONFIG_NET_DSA) += dsa.o slave.o
diff --git a/net/dsa/ksz8893m.c b/net/dsa/ksz8893m.c
new file mode 100644
index 0000000..0bfa193
--- /dev/null
+++ b/net/dsa/ksz8893m.c
@@ -0,0 +1,341 @@
+/*
+ * Integrated 3-Port 10/100 Managed Switch with PHYs
+ *
+ * - KSZ8893M support
+ *
+ * Copyright 2008-2010 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#define pr_fmt(fmt) "ksz8893m: " fmt
+
+#include <linux/list.h>
+#include <linux/netdevice.h>
+#include <linux/phy.h>
+#include <linux/spi/spi.h>
+#include "dsa_priv.h"
+#include "ksz8893m.h"
+
+#define BUF_LEN 6
+
+static struct _spi_switch {
+ struct spi_transfer xfer;
+ struct spi_device *dev;
+} sw;
+
+static int ksz8893m_read(unsigned char *din, unsigned char reg, int len)
+{
+ int i, ret;
+ struct spi_message message;
+ unsigned char dout[BUF_LEN];
+ struct spi_transfer *t = &sw.xfer;
+
+ t->len = len;
+ t->tx_buf = dout;
+ t->rx_buf = din;
+ dout[0] = SPI_READ;
+ dout[1] = reg;
+ for (i = 2; i < len; i++)
+ dout[i] = 0;
+
+ spi_message_init(&message);
+ spi_message_add_tail(t, &message);
+ ret = spi_sync(sw.dev, &message);
+ if (!ret)
+ return message.status;
+
+ pr_err("read reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+}
+
+static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
+{
+ int ret;
+ struct spi_message message;
+ unsigned char din[BUF_LEN];
+ struct spi_transfer *t = &sw.xfer;
+
+ t->len = len;
+ t->tx_buf = dout;
+ t->rx_buf = din;
+ dout[0] = SPI_WRITE;
+ dout[1] = reg;
+
+ spi_message_init(&message);
+ spi_message_add_tail(t, &message);
+ ret = spi_sync(sw.dev, &message);
+ if (!ret)
+ return message.status;
+
+ pr_err("write reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+}
+
+static char *ksz8893m_probe(struct mii_bus *bus, int sw_addr)
+{
+ int ret, phyid_low, phyid_high;
+ unsigned char din[BUF_LEN];
+
+ phyid_high = mdiobus_read(bus, KSZ8893M_CPU_PORT, MII_PHYSID1);
+ phyid_low = mdiobus_read(bus, KSZ8893M_CPU_PORT, MII_PHYSID2);
+ if (phyid_high != PHYID_HIGH || phyid_low != PHYID_LOW)
+ return NULL;
+
+ ret = ksz8893m_read(din, ChipID0, 3);
+
+ if (!ret && FAMILY_ID == din[2])
+ return "KSZ8893M";
+
+ return NULL;
+}
+
+static int ksz8893m_switch_reset(struct dsa_switch *ds)
+{
+ return 0;
+}
+
+static int ksz8893m_setup_global(struct dsa_switch *ds)
+{
+ int ret;
+ unsigned char dout[BUF_LEN];
+ unsigned char din[BUF_LEN];
+
+ /* Set VLAN VID of port1 */
+ ret = ksz8893m_read(din, Port1Control3, 3);
+ if (ret)
+ return ret;
+ din[2] &= 0xf0;
+ dout[2] = (DEFAULT_PORT_VID & 0xfff) >> 8 | din[2];
+ dout[3] = DEFAULT_PORT_VID & 0xff;
+ ret = ksz8893m_write(dout, Port1Control3, 4);
+ if (ret)
+ return ret;
+
+ /* Set VLAN VID of port2 */
+ ret = ksz8893m_read(din, Port2Control3, 3);
+ if (ret)
+ return ret;
+ din[2] &= 0xf0;
+ dout[2] = (DEFAULT_PORT_VID & 0xfff) >> 8 | din[2];
+ dout[3] = DEFAULT_PORT_VID & 0xff;
+ ret = ksz8893m_write(dout, Port2Control3, 4);
+ if (ret)
+ return ret;
+
+ /* Set VLAN VID of port3 */
+ ret = ksz8893m_read(din, Port3Control3, 3);
+ if (ret)
+ return ret;
+ din[2] &= 0xf0;
+ dout[2] = (DEFAULT_PORT_VID & 0xfff) >> 8 | din[2];
+ dout[3] = DEFAULT_PORT_VID & 0xff;
+ ret = ksz8893m_write(dout, Port3Control3, 4);
+ if (ret)
+ return ret;
+
+ /* Insert VLAN tag that egress Port3 */
+ ret = ksz8893m_read(din, Port3Control0, 3);
+ if (ret)
+ return ret;
+ dout[2] = TAG_INSERTION | din[2];
+ ret = ksz8893m_write(dout, Port3Control0, 3);
+ if (ret)
+ return ret;
+
+ /* Enable STPID Mode */
+ ret = ksz8893m_read(din, GlobalControl9, 3);
+ if (ret)
+ return ret;
+ dout[2] = SPECIAL_TPID_MODE | din[2];
+ ret = ksz8893m_write(dout, GlobalControl9, 3);
+ if (ret)
+ return ret;
+
+ /* Start switch */
+ dout[2] = START_SWITCH;
+ ret = ksz8893m_write(dout, ChipID1_StartSwitch, 3);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int ksz8893m_setup_port(struct dsa_switch *ds, int p)
+{
+ int val, ret;
+ val = mdiobus_read(ds->master_mii_bus, p, MII_BMCR);
+ if (val < 0)
+ return val;
+ val |= BMCR_ANENABLE | BMCR_SPEED100 | BMCR_FULLDPLX;
+ val &= ~(BMCR_PDOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |
+ DISABLE_TRANSMIT | DISABLE_LED);
+ ret = mdiobus_write(ds->master_mii_bus, p, MII_BMCR, val);
+ if (ret < 0)
+ return ret;
+
+ val = mdiobus_read(ds->master_mii_bus, p, MII_ADVERTISE);
+ if (val < 0)
+ return val;
+ val |= ADVERTISE_10HALF | ADVERTISE_10FULL |
+ ADVERTISE_100HALF | ADVERTISE_100FULL;
+ ret = mdiobus_write(ds->master_mii_bus, p, MII_ADVERTISE, val);
+ if (ret < 0)
+ return ret;
+ return 0;
+}
+
+static int ksz8893m_setup(struct dsa_switch *ds)
+{
+ int i;
+ int ret;
+
+ ret = ksz8893m_switch_reset(ds);
+ if (ret < 0)
+ return ret;
+
+ ret = ksz8893m_setup_global(ds);
+ if (ret < 0)
+ return ret;
+
+ for (i = 1; i < KSZ8893M_PORT_NUM; i++) {
+ ret = ksz8893m_setup_port(ds, i);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ksz8893m_set_addr(struct dsa_switch *ds, u8 *addr)
+{
+ return 0;
+}
+
+static int ksz8893m_port_to_phy_addr(int port)
+{
+ if (port >= 1 && port <= KSZ8893M_PORT_NUM)
+ return port;
+ return -1;
+}
+
+static int
+ksz8893m_phy_read(struct dsa_switch *ds, int port, int regnum)
+{
+ int phy_addr = ksz8893m_port_to_phy_addr(port);
+ return mdiobus_read(ds->master_mii_bus, phy_addr, regnum);
+}
+
+static int
+ksz8893m_phy_write(struct dsa_switch *ds,
+ int port, int regnum, u16 val)
+{
+ int phy_addr = ksz8893m_port_to_phy_addr(port);
+ return mdiobus_write(ds->master_mii_bus, phy_addr, regnum, val);
+}
+
+static void ksz8893m_poll_link(struct dsa_switch *ds)
+{
+ int i;
+
+ for (i = 1; i < KSZ8893M_PORT_NUM; i++) {
+ struct net_device *dev;
+ int val, link;
+
+ dev = ds->ports[i];
+ if (dev == NULL)
+ continue;
+
+ link = 0;
+ if (dev->flags & IFF_UP) {
+ val = mdiobus_read(ds->master_mii_bus, i, MII_BMSR);
+ if (val < 0)
+ continue;
+
+ link = val & BMSR_LSTATUS;
+ }
+
+ if (!link) {
+ if (netif_carrier_ok(dev)) {
+ printk(KERN_INFO "%s: link down\n", dev->name);
+ netif_carrier_off(dev);
+ }
+ continue;
+ }
+
+ val = mdiobus_read(ds->master_mii_bus, i, MII_BMSR);
+ if (val < 0)
+ continue;
+
+ if (!netif_carrier_ok(dev)) {
+ printk(KERN_INFO "%s: link up, %d Mb/s, %s duplex\n",
+ dev->name,
+ (val & LPA_100) ? 100 : 10,
+ (val & LPA_DUPLEX) ? "half" : "full");
+ netif_carrier_on(dev);
+ }
+ }
+}
+
+static int __devinit spi_switch_probe(struct spi_device *spi)
+{
+ if (sw.dev) {
+ pr_err("only one instance supported at a time\n");
+ return 1;
+ }
+ memset(&sw.xfer, 0, sizeof(sw.xfer));
+ sw.dev = spi;
+ return 0;
+}
+
+static int __devexit spi_switch_remove(struct spi_device *spi)
+{
+ sw.dev = NULL;
+ return 0;
+}
+
+static struct spi_driver spi_switch_driver = {
+ .driver = {
+ .name = "ksz8893m",
+ .bus = &spi_bus_type,
+ .owner = THIS_MODULE,
+ },
+ .probe = spi_switch_probe,
+ .remove = __devexit_p(spi_switch_remove),
+};
+
+static struct dsa_switch_driver ksz8893m_switch_driver = {
+ .tag_protocol = __constant_htons(ETH_P_STPID),
+ .probe = ksz8893m_probe,
+ .setup = ksz8893m_setup,
+ .set_addr = ksz8893m_set_addr,
+ .phy_read = ksz8893m_phy_read,
+ .phy_write = ksz8893m_phy_write,
+ .poll_link = ksz8893m_poll_link,
+};
+
+static int __init ksz8893m_init(void)
+{
+ int ret;
+
+ ret = spi_register_driver(&spi_switch_driver);
+ if (ret) {
+ pr_err("can't register driver\n");
+ return ret;
+ }
+
+ register_switch_driver(&ksz8893m_switch_driver);
+ return 0;
+}
+module_init(ksz8893m_init);
+
+static void __exit ksz8893m_cleanup(void)
+{
+ spi_unregister_driver(&spi_switch_driver);
+ unregister_switch_driver(&ksz8893m_switch_driver);
+}
+module_exit(ksz8893m_cleanup);
+
+MODULE_AUTHOR("Graf Yang <graf.yang@analog.com>");
+MODULE_DESCRIPTION("KSZ8893M driver for DSA");
+MODULE_LICENSE("GPL");
diff --git a/net/dsa/ksz8893m.h b/net/dsa/ksz8893m.h
new file mode 100644
index 0000000..30e0df0
--- /dev/null
+++ b/net/dsa/ksz8893m.h
@@ -0,0 +1,163 @@
+/*
+ * Integrated 3-Port 10/100 Managed Switch with PHYs
+ *
+ * - KSZ8893M support
+ *
+ * Copyright 2008-2010 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef __KSZ8893M_H__
+#define __KSZ8893M_H__
+
+#define KSZ8893M_PORT_NUM 3
+#define KSZ8893M_CPU_PORT 3
+
+#define DEFAULT_PORT_VID 0
+
+/* Simple SPI command set for poking registers */
+#define SPI_READ 3
+#define SPI_WRITE 2
+
+/* Expected value for MII_PHYSID1 */
+#define PHYID_HIGH 0x22
+/* Expected value for MII_PHYSID2 */
+#define PHYID_LOW 0x1430
+
+/* ChipID0 defines */
+#define FAMILY_ID 0x88
+
+/* ChipID1_StartSwitch defines */
+#define START_SWITCH 0x01
+
+/* Port3Control0 defines */
+#define TAG_INSERTION 0x04
+
+/* GlobalControl9 defines */
+#define SPECIAL_TPID_MODE 0x01
+
+/* BMCR Reserved Bits */
+#define HP_MDIX 0x0020
+#define FORCE_MDI 0x0010
+#define DISABLE_MDIX 0x0008
+#define DIS_FAR_END_FAULT 0x0004
+#define DISABLE_TRANSMIT 0x0002
+#define DISABLE_LED 0x0001
+
+/* BMSCR Reserved Bits */
+#define PREAMBLE_SUPPRESS 0x0040
+
+enum switch_phy_reg {
+ /* Global Registers: 0-15 */
+ ChipID0 = 0,
+ ChipID1_StartSwitch,
+ GlobalControl0,
+ GlobalControl1,
+ GlobalControl2, /* 4 */
+ GlobalControl3,
+ GlobalControl4,
+ GlobalControl5,
+ GlobalControl6, /* 8 */
+ GlobalControl7,
+ GlobalControl8,
+ GlobalControl9,
+ GlobalControl10, /* 12 */
+ GlobalControl11,
+ GlobalControl12,
+ GlobalControl13,
+ /* Port Registers: 16-95 */
+ Port1Control0 = 16,
+ Port1Control1,
+ Port1Control2,
+ Port1Control3,
+ Port1Control4, /* 20 */
+ Port1Control5,
+ Port1Control6,
+ Port1Control7,
+ Port1Control8, /* 24 */
+ Port1Control9,
+ Port1PHYSpecialControl_Status,
+ Port1LinkMDResult,
+ Port1Control12, /* 28 */
+ Port1Control13,
+ Port1Status0,
+ Port1Status1,
+ Port2Control0, /* 32 */
+ Port2Control1,
+ Port2Control2,
+ Port2Control3,
+ Port2Control4, /* 36 */
+ Port2Control5,
+ Port2Control6,
+ Port2Control7,
+ Port2Control8, /* 40 */
+ Port2Control9,
+ Port2PHYSpecialControl_Status,
+ Port2LinkMDResult,
+ Port2Control12, /* 44 */
+ Port2Control13,
+ Port2Status0,
+ Port2Status1,
+ Port3Control0, /* 48 */
+ Port3Control1,
+ Port3Control2,
+ Port3Control3,
+ Port3Control4, /* 52 */
+ Port3Control5,
+ Port3Control6,
+ Port3Control7,
+ Port3Control8, /* 56 */
+ Port3Control9,
+ Reservednotappliedtoport3, /* 58-62 */
+ Port3Status1 = 63,
+ /* Advanced Control Registers: 96-141 */
+ TOSPriorityControlRegister0 = 96,
+ TOSPriorityControlRegister1,
+ TOSPriorityControlRegister2,
+ TOSPriorityControlRegister3,
+ TOSPriorityControlRegister4, /* 100 */
+ TOSPriorityControlRegister5,
+ TOSPriorityControlRegister6,
+ TOSPriorityControlRegister7,
+ TOSPriorityControlRegister8, /* 104 */
+ TOSPriorityControlRegister9,
+ TOSPriorityControlRegister10,
+ TOSPriorityControlRegister11,
+ TOSPriorityControlRegister12, /* 108 */
+ TOSPriorityControlRegister13,
+ TOSPriorityControlRegister14,
+ TOSPriorityControlRegister15,
+ MACAddressRegister0 = 112,
+ MACAddressRegister1,
+ MACAddressRegister2,
+ MACAddressRegister3,
+ MACAddressRegister4,
+ MACAddressRegister5,
+ UserDefinedRegister1 = 118,
+ UserDefinedRegister2,
+ UserDefinedRegister3,
+ IndirectAccessControl0 = 121,
+ IndirectAccessControl1,
+ IndirectDataRegister8 = 123,
+ IndirectDataRegister7,
+ IndirectDataRegister6,
+ IndirectDataRegister5,
+ IndirectDataRegister4,
+ IndirectDataRegister3,
+ IndirectDataRegister2,
+ IndirectDataRegister1,
+ IndirectDataRegister0,
+ DigitalTestingStatus0 = 132,
+ DigitalTestingControl0,
+ AnalogTestingControl0,
+ AnalogTestingControl1,
+ AnalogTestingControl2,
+ AnalogTestingControl3,
+ AnalogTestingStatus,
+ AnalogTestingControl4,
+ QMDebug1,
+ QMDebug2,
+};
+
+#endif
--
1.7.1.1
^ permalink raw reply related
* [PATCH] Add missing read memory barrier to Intel Ethernet device drivers
From: Sonny Rao @ 2010-07-21 16:22 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel
From: Milton Miller <miltonm@bga.com>
The PowerPC architecture does not require loads to independent bytes to be
ordered without adding an explicit barrier.
In ixgbe_clean_rx_irq we load the status bit then load the packet data.
With packet split disabled if these loads go out of order we get a
stale packet, but we will notice the bad sequence numbers and drop it.
The problem occurs with packet split enabled where the TCP/IP header and data
are in different descriptors. If the reads go out of order we may have data
that doesn't match the TCP/IP header. Since we use hardware checksumming this
bad data is never verified and it makes it all the way to the application.
This bug was found during stress testing and adding this barrier has been shown
to fix it. The bug can manifest as a data integrity issue (bad payload data)
or as a BUG in skb_pull().
This was a nasty bug to hunt down, if people agree with the fix I think
it's a candidate for stable.
Previously Submitted to e1000-devel only for ixgbe
http://marc.info/?l=e1000-devel&m=126593062701537&w=3
We've now seen this problem hit with other device drivers (e1000e mostly)
So I'm resubmitting with fixes for other Intel Device Drivers with
similar issues: ixgb, e100, e1000, and e1000e
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Sonny Rao <sonnyrao@us.ibm.com>
cc: stable <stable@kernel.org>
---
Index: linux-2.6.35-rc5/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/e1000/e1000_main.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/e1000/e1000_main.c 2010-07-21 11:19:58.000000000 -0500
@@ -3448,6 +3448,7 @@ static bool e1000_clean_tx_irq(struct e1
while ((eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) &&
(count < tx_ring->count)) {
bool cleaned = false;
+ rmb(); /* read buffer_info after eop_desc */
for ( ; !cleaned; count++) {
tx_desc = E1000_TX_DESC(*tx_ring, i);
buffer_info = &tx_ring->buffer_info[i];
Index: linux-2.6.35-rc5/drivers/net/e1000e/netdev.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/e1000e/netdev.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/e1000e/netdev.c 2010-07-21 11:19:58.000000000 -0500
@@ -984,6 +984,7 @@ static bool e1000_clean_tx_irq(struct e1
while ((eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) &&
(count < tx_ring->count)) {
bool cleaned = false;
+ rmb(); /* read buffer_info after eop_desc */
for (; !cleaned; count++) {
tx_desc = E1000_TX_DESC(*tx_ring, i);
buffer_info = &tx_ring->buffer_info[i];
Index: linux-2.6.35-rc5/drivers/net/ixgb/ixgb_main.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/ixgb/ixgb_main.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/ixgb/ixgb_main.c 2010-07-21 11:19:58.000000000 -0500
@@ -1816,6 +1816,7 @@ ixgb_clean_tx_irq(struct ixgb_adapter *a
while (eop_desc->status & IXGB_TX_DESC_STATUS_DD) {
+ rmb(); /* read buffer_info after eop_desc */
for (cleaned = false; !cleaned; ) {
tx_desc = IXGB_TX_DESC(*tx_ring, i);
buffer_info = &tx_ring->buffer_info[i];
Index: linux-2.6.35-rc5/drivers/net/e100.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/e100.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/e100.c 2010-07-21 11:20:04.000000000 -0500
@@ -1779,6 +1779,7 @@ static int e100_tx_clean(struct nic *nic
for (cb = nic->cb_to_clean;
cb->status & cpu_to_le16(cb_complete);
cb = nic->cb_to_clean = cb->next) {
+ rmb(); /* read skb after status */
netif_printk(nic, tx_done, KERN_DEBUG, nic->netdev,
"cb[%d]->status = 0x%04X\n",
(int)(((void*)cb - (void*)nic->cbs)/sizeof(struct cb)),
Index: linux-2.6.35-rc5/drivers/net/ixgbe/ixgbe_main.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/ixgbe/ixgbe_main.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/ixgbe/ixgbe_main.c 2010-07-21 11:19:58.000000000 -0500
@@ -748,6 +748,7 @@ static bool ixgbe_clean_tx_irq(struct ix
while ((eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD)) &&
(count < tx_ring->work_limit)) {
bool cleaned = false;
+ rmb(); /* read buffer_info after eop_desc */
for ( ; !cleaned; count++) {
struct sk_buff *skb;
tx_desc = IXGBE_TX_DESC_ADV(*tx_ring, i);
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/2] net: dsa: introduce STPID switch tagging handling code
From: Mike Frysinger @ 2010-07-21 16:08 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Karl Beldan, netdev, uclinux-dist-devel, David S. Miller
In-Reply-To: <20100721153531.GN21121@mail.wantstofly.org>
On Wed, Jul 21, 2010 at 11:35, Lennert Buytenhek wrote:
> On Wed, Jul 21, 2010 at 11:29:30AM -0400, Mike Frysinger wrote:
>> >> + source_port = dsa_header[1] & 0x03;
>> >> + if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
>> >> + goto out_drop;
>> >> +
>> >> + if (((dsa_header[0] & ETH_P_8021QH) == ETH_P_8021QH) &&
>> >
>> > This is bogus -- what it does is:
>> >
>> > if ((dsa_header[0] & 0x81) == 0x81)
>> >
>> > It doesn't look like you need to mask here at all.
>>
>> where does it say dsa_header[0] will always have 0x81 set ?
>
> Eh?
>
> This code is checking whether the packet has a STPID tag on it or not.
> A STPID tag exists if the first 12 nibbles are 0x810.
>
> You are checking whether the first 8 nibbles of this are equal to 0x81
> by doing:
>
> if ((byte & 0x81) == 0x81)
>
> What if the first byte is 0x93? Or 0xc5?
that was my point. should it be masking or doing a raw compare ?
i have nfc as i had nothing to do with the creation of this code. i
dont know the first thing about VLAN tags or anything else at that
level.
-mike
^ 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