* [PATCH] myri10ge: fix rmmod crash
From: Stanislaw Gruszka @ 2011-03-23 12:44 UTC (permalink / raw)
To: netdev; +Cc: stable, Brice Goglin, Andrew Gallatin
Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because napi
structures are already deallocated. To fix call netif_napi_del() before
kfree() at myri10ge_free_slices().
Cc: stable@kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/myri10ge/myri10ge.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index ea5cfe2..24386a8 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -3645,6 +3645,7 @@ static void myri10ge_free_slices(struct myri10ge_priv *mgp)
dma_free_coherent(&pdev->dev, bytes,
ss->fw_stats, ss->fw_stats_bus);
ss->fw_stats = NULL;
+ netif_napi_del(&ss->napi);
}
}
kfree(mgp->ss);
--
1.7.1
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply related
* [RFC] myri10ge: small rx_done refactoring
From: Stanislaw Gruszka @ 2011-03-23 12:52 UTC (permalink / raw)
To: netdev; +Cc: Andrew Gallatin, Brice Goglin
myri10ge: small rx_done refactoring
Add lro_enable variable to read NETIF_F_LRO flag only once per napi poll
call. This should fix theoretical race condition with
myri10ge_set_rx_csum() and myri10ge_set_flags() where flag NETIF_F_LRO
can be changed.
On the way reduce myri10ge_rx_done() number of arguments and calls by
moving mgp->small_bytes check into that function. That reduce code size
from:
text data bss dec hex filename
36644 248 100 36992 9080 drivers/net/myri10ge/myri10ge.o
to:
text data bss dec hex filename
36037 247 100 36384 8e20 drivers/net/myri10ge/myri10ge.o
on my i686 system, what should also make myri10ge_clean_rx_done()
being faster.
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 24386a8..2e71240 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1312,17 +1312,26 @@ myri10ge_unmap_rx_page(struct pci_dev *pdev,
* page into an skb */
static inline int
-myri10ge_rx_done(struct myri10ge_slice_state *ss, struct myri10ge_rx_buf *rx,
- int bytes, int len, __wsum csum)
+myri10ge_rx_done(struct myri10ge_slice_state *ss, int len, __wsum csum,
+ bool lro_enabled)
{
struct myri10ge_priv *mgp = ss->mgp;
struct sk_buff *skb;
struct skb_frag_struct rx_frags[MYRI10GE_MAX_FRAGS_PER_FRAME];
- int i, idx, hlen, remainder;
+ struct myri10ge_rx_buf *rx;
+ int i, idx, hlen, remainder, bytes;
struct pci_dev *pdev = mgp->pdev;
struct net_device *dev = mgp->dev;
u8 *va;
+ if (len <= mgp->small_bytes) {
+ rx = &ss->rx_small;
+ bytes = mgp->small_bytes;
+ } else {
+ rx = &ss->rx_big,
+ bytes = mgp->big_bytes;
+ }
+
len += MXGEFW_PAD;
idx = rx->cnt & rx->mask;
va = page_address(rx->info[idx].page) + rx->info[idx].page_offset;
@@ -1341,7 +1350,7 @@ myri10ge_rx_done(struct myri10ge_slice_state *ss, struct myri10ge_rx_buf *rx,
remainder -= MYRI10GE_ALLOC_SIZE;
}
- if (dev->features & NETIF_F_LRO) {
+ if (lro_enabled) {
rx_frags[0].page_offset += MXGEFW_PAD;
rx_frags[0].size -= MXGEFW_PAD;
len -= MXGEFW_PAD;
@@ -1464,6 +1473,7 @@ myri10ge_clean_rx_done(struct myri10ge_slice_state *ss, int budget)
struct myri10ge_rx_done *rx_done = &ss->rx_done;
struct myri10ge_priv *mgp = ss->mgp;
struct net_device *netdev = mgp->dev;
+ bool lro_enabled = (netdev->features & NETIF_F_LRO) ? true : false;
unsigned long rx_bytes = 0;
unsigned long rx_packets = 0;
unsigned long rx_ok;
@@ -1478,14 +1488,7 @@ myri10ge_clean_rx_done(struct myri10ge_slice_state *ss, int budget)
length = ntohs(rx_done->entry[idx].length);
rx_done->entry[idx].length = 0;
checksum = csum_unfold(rx_done->entry[idx].checksum);
- if (length <= mgp->small_bytes)
- rx_ok = myri10ge_rx_done(ss, &ss->rx_small,
- mgp->small_bytes,
- length, checksum);
- else
- rx_ok = myri10ge_rx_done(ss, &ss->rx_big,
- mgp->big_bytes,
- length, checksum);
+ rx_ok = myri10ge_rx_done(ss, length, checksum, lro_enabled);
rx_packets += rx_ok;
rx_bytes += rx_ok * (unsigned long)length;
cnt++;
@@ -1497,7 +1500,7 @@ myri10ge_clean_rx_done(struct myri10ge_slice_state *ss, int budget)
ss->stats.rx_packets += rx_packets;
ss->stats.rx_bytes += rx_bytes;
- if (netdev->features & NETIF_F_LRO)
+ if (lro_enabled)
lro_flush_all(&rx_done->lro_mgr);
/* restock receive rings if needed */
^ permalink raw reply related
* Re: [PATCH] myri10ge: fix rmmod crash
From: Andrew Gallatin @ 2011-03-23 13:09 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev, Brice Goglin, stable
In-Reply-To: <20110323124412.GA7813@redhat.com>
On 03/23/11 08:44, Stanislaw Gruszka wrote:
> Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because napi
> structures are already deallocated. To fix call netif_napi_del() before
> kfree() at myri10ge_free_slices().
I apologize; I made a similar fix myself to our tree last fall simply
forgot to post it to netdev... I'm terribly sorry for the time
you wasted chasing this. At any rate...
Acked by: Andrew Gallatin <gallatin@myri.com>
^ permalink raw reply
* Re: [PATCH 02/36] scsi, rcu: convert call_rcu(fc_rport_free_rcu) to kfree_rcu()
From: Paul E. McKenney @ 2011-03-23 13:30 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jens Axboe, Lai Jiangshan, Neil Horman, Hideaki YOSHIFUJI,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Hemminger, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
James Morris, Patrick McHardy,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
James E.J. Bottomley,
devel-s9riP+hp16TNLxjTenLetw@public.gmane.org, Eric Dumazet,
Tejun Heo, Alexey Kuznetsov, Ingo Molnar, David S. Miller,
Jarek Poplawski, Pekka Savola (ipv6)
In-Reply-To: <20110323112257.GD13806-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
On Wed, Mar 23, 2011 at 05:22:57AM -0600, Matthew Wilcox wrote:
> On Tue, Mar 22, 2011 at 11:50:14PM -0700, Paul E. McKenney wrote:
> > On Tue, Mar 22, 2011 at 10:28:33AM -0700, Robert Love wrote:
> > > On Thu, 2011-03-17 at 20:41 -0700, Lai Jiangshan wrote:
> > > > - call_rcu(&rdata->rcu, fc_rport_free_rcu);
> > > > + kfree_rcu(rdata, rcu);
> > >
> > > I think this last line should be:
> > >
> > > kfree_rcu(rdata, &rdata->rcu);
> >
> > Hello, Robert,
> >
> > I believe that it is correct as is. The kfree_rcu() definition is as
> > follows:
> >
> > #define kfree_rcu(ptr, rcu_head) \
> > __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
> >
> > Then __kfree_rcu() encodes the offset into the rcu_head so that it can
> > be handled properly at the end of the grace period.
>
> To be fair to Robert, I had the same thought, but decided to check the
> definition of kfree_rcu before I made the same comment. Unfortunately,
> the definition of kfree_rcu is still not in Linus' tree (and there's no
> indication in the patch series about where to find the definition). It
> would have been better if kfree_rcu were patch 1/n in the series, then
> we'd've been able to review it more effectively.
Good point! That said, it is a bit ugly no matter how we handle it
because any of the patches that have not received acked-bys will need
to go up through their respective maintainer trees. Last time I had a
situation like this, it ended up stalling my commit stream for several
months, so was trying to separate them in order to avoid the stall.
But perhaps this is one of those situations where there is simply no
good way to handle the full series. :-(
> Any idea when kfree_rcu will be submitted to Linus?
I have it queued, and it passes mild testing. I therefore expect to
push it for the next merge window.
So, do you guys want to carry the patches for your subsystems, or are
you willing to ack this one so that I can push it via -tip?
Thanx, Paul
^ permalink raw reply
* Re: can: c_can: TX echo
From: Jan Altenberg @ 2011-03-23 13:54 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: Jan Altenberg, bhupesh.sharma, wg, b.spranger, netdev
In-Reply-To: <20110323085133.GB346@e-circ.dyndns.org>
Hi,
>> So, we first invalidate the message object and afterwards we read
>> the DLC value from the msg_cntrl (which is 0 after invalidating the
>> message object) to account the TX bytes. So tx_bytes will always be
>> 0. The fix should be easy, I think, we can just move
>> c_can_inval_msg_object to the end of that loop.
>
> IMO, it looks necessary to call c_can_inval_msg_object inside the if
> (), after it has been transmitted. Otherwise, if for some other (TX)
> reason you get in this loop, you may clear a pending transmission?
> Again, I haven't read this one's datasheet. I was familiar with its
> predecessor.
I tried to check, but the datasheet is a bit unclear regarding that
point ;-) My interpretation is, that c_can_inval_msg_object()
shouldn't affect the txrqst bit, but nevertheless calling it inside
the if() statement would make the code more readable.
I can prepare a patch, but I'd like to wait for Wolfgang's / Bupesh's
feedback.
Cheers,
Jan
^ permalink raw reply
* Re: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Ben Hutchings @ 2011-03-23 14:04 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev, eugenia
In-Reply-To: <4D89B16F.4040008@mellanox.co.il>
On Wed, 2011-03-23 at 10:38 +0200, Yevgeny Petrilin wrote:
> HW revision is derived from device ID and rev id.
[...]
> - sprintf(drvinfo->driver, DRV_NAME " (%s)", mdev->dev->board_id);
> + switch (mdev->dev->rev_id) {
> + case 0xa0:
> + if (dev->dev_id >= MLX4_EN_CX3_LOW_ID && dev->dev_id <= MLX4_EN_CX3_HIGH_ID)
> + sprintf(drvinfo->driver, DRV_NAME " (%s_CX-3)", mdev->dev->board_id);
> + else
> + sprintf(drvinfo->driver, DRV_NAME " (%s_CX)", mdev->dev->board_id);
> + break;
> + case 0xb0:
> + sprintf(drvinfo->driver, DRV_NAME " (%s_CX-2)", mdev->dev->board_id);
> + break;
> + default:
> + sprintf(drvinfo->driver, DRV_NAME " (%s)", mdev->dev->board_id);
> + break;
[...]
This is an abuse of the ethtool_drvinfo::driver field.
Your users can use lspci -v, can't they?
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: [PATCH 02/36] scsi,rcu: convert call_rcu(fc_rport_free_rcu) to kfree_rcu()
From: James Bottomley @ 2011-03-23 14:05 UTC (permalink / raw)
To: paulmck
Cc: Robert Love, Lai Jiangshan, Ingo Molnar, Jens Axboe, Neil Horman,
David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
Stephen Hemminger, Tejun Heo, Jarek Poplawski,
linux-kernel@vger.kernel.org, devel@open-fcoe.org,
linux-scsi@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20110323065014.GU2322@linux.vnet.ibm.com>
On Tue, 2011-03-22 at 23:50 -0700, Paul E. McKenney wrote:
> The kfree_rcu() definition is as
> follows:
>
> #define kfree_rcu(ptr, rcu_head) \
> __kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
Isn't this one of those cases where the obvious use of the interface is
definitely wrong?
It's also another nasty pseudo C prototype. I know we do this sort of
thing for container_of et al, but I don't really think we want to extend
it.
Why not make the interface take a pointer to the embedding structure and
one to the rcu_head ... that way all pointer mathematics can be
contained inside the RCU routines.
James
^ permalink raw reply
* Re: can: c_can: TX echo
From: Wolfgang Grandegger @ 2011-03-23 14:25 UTC (permalink / raw)
To: Jan Altenberg; +Cc: Kurt Van Dijck, bhupesh.sharma, b.spranger, netdev
In-Reply-To: <b7a5102e35a2afd04327d7b42da4e988.squirrel@www2.linutronix.de>
Hi Jan,
On 03/23/2011 02:54 PM, Jan Altenberg wrote:
> Hi,
>
>>> So, we first invalidate the message object and afterwards we read
>>> the DLC value from the msg_cntrl (which is 0 after invalidating the
>>> message object) to account the TX bytes. So tx_bytes will always be
>>> 0. The fix should be easy, I think, we can just move
>>> c_can_inval_msg_object to the end of that loop.
This means that "ifconfig" will report *0* TX Bytes!?
>> IMO, it looks necessary to call c_can_inval_msg_object inside the if
>> (), after it has been transmitted. Otherwise, if for some other (TX)
>> reason you get in this loop, you may clear a pending transmission?
>> Again, I haven't read this one's datasheet. I was familiar with its
>> predecessor.
>
> I tried to check, but the datasheet is a bit unclear regarding that
> point ;-) My interpretation is, that c_can_inval_msg_object()
> shouldn't affect the txrqst bit, but nevertheless calling it inside
> the if() statement would make the code more readable.
>
> I can prepare a patch, but I'd like to wait for Wolfgang's / Bupesh's
> feedback.
I'm following the discussion and as I'm not familiar with that chip, I'm
waiting for Bupesh's answer as well... before I start digging. You can
also have a look to the pch_can driver, which is C_CAN based as well.
Wolfgang.
^ permalink raw reply
* Re: can: c_can: TX echo
From: Jan Altenberg @ 2011-03-23 14:52 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Jan Altenberg, Kurt Van Dijck, bhupesh.sharma, b.spranger, netdev
In-Reply-To: <4D8A02F7.7050607@grandegger.com>
Hi Wolfgang,
> This means that "ifconfig" will report *0* TX Bytes!?
Yep, ifconfig reports *0* TX Bytes.
> I'm following the discussion and as I'm not familiar with that chip,
> I'm waiting for Bupesh's answer as well... before I start digging.
> You can also have a look to the pch_can driver, which is C_CAN based
> as well.
I'm also quite new to that chip, so lets wait for Bupesh's feedback.
Cheers,
Jan
^ permalink raw reply
* RE: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Yevgeny Petrilin @ 2011-03-23 15:10 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org, Eugenia Emantayev
In-Reply-To: <1300889054.26693.527.camel@localhost>
>
> This is an abuse of the ethtool_drvinfo::driver field.
>
> Your users can use lspci -v, can't they?
>
I don't think there is a problem here.
We have always reported the HW model via Ethtool, we just expanded the information
we provide.
Our users prefer to see the information in ethtool.
Thanks,
Yevgeny
^ permalink raw reply
* Re: [RFC] myri10ge: small rx_done refactoring
From: Andrew Gallatin @ 2011-03-23 15:21 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev, Brice Goglin
In-Reply-To: <20110323124939.GA7834@redhat.com>
On 03/23/11 08:52, Stanislaw Gruszka wrote:
> on my i686 system, what should also make myri10ge_clean_rx_done()
> being faster.
I tested this on my very old, very weak dual-core athlon64 systems.
These machines can barely achieve 10Gb/s using a 1500b MTU with LRO.
Running 35 60 second netperf tests into the machines with the stock
driver, and again with this patch applied, I see a tiny bandwidth
increase (1.4Mb/s on average) which is statistically significant
( p < 0.001). There is no statistically significant CPU load
reduction.
> + if (len<= mgp->small_bytes) {
> + rx =&ss->rx_small;
> + bytes = mgp->small_bytes;
> + } else {
> + rx =&ss->rx_big,
Small nit: the "," above should be a ";"
Between the small bandwidth increase, and the code size reduction,
I'm very appreciative of this patch.
Thank you,
Drew
^ permalink raw reply
* Re: [BUG] VPN broken in net-next
From: Stephen Hemminger @ 2011-03-23 15:24 UTC (permalink / raw)
To: David Miller; +Cc: ja, netdev
In-Reply-To: <20110322.215655.245381151.davem@davemloft.net>
On Tue, 22 Mar 2011 21:56:55 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Fri, 4 Mar 2011 10:39:55 +0200 (EET)
>
> > On Thu, 3 Mar 2011, David Miller wrote:
> >
> >> I suspect that even if we need to handle prefixes, we can still use
> >> the hash for optimistic lookup, and fallback to a local table FIB
> >> inspection if that fails.
> >
> > Yes, as ip_route_output_slow uses __ip_dev_find for
> > fl4_src there should be some kind of fallback to local table,
> > so that traffic from 127.0.0.2 to 127.0.0.3 or other local
> > subnets on loopback can work. Another option is to use
> > inet_addr_onlink but I suspect people can add many addresses
> > on loopback: inet_addr_onlink(loopback_indev, addr, 0)
>
> I just got back to this, sorry for taking so long :-)
>
> Here is the patch I've come up with and will commit to
> net-2.6, thanks!
>
> --------------------
> ipv4: Fallback to FIB local table in __ip_dev_find().
>
> In commit 9435eb1cf0b76b323019cebf8d16762a50a12a19
> ("ipv4: Implement __ip_dev_find using new interface address hash.")
> we reimplemented __ip_dev_find() so that it doesn't have to
> do a full FIB table lookup.
>
> Instead, it consults a hash table of addresses configured to
> interfaces.
>
> This works identically to the old code in all except one case,
> and that is for loopback subnets.
>
> The old code would match the loopback device for any IP address
> that falls within a subnet configured to the loopback device.
>
> Handle this corner case by doing the FIB lookup.
>
> We could implement this via inet_addr_onlink() but:
>
> 1) Someone could configure many addresses to loopback and
> inet_addr_onlink() is a simple list traversal.
>
> 2) We know the old code works.
>
> Reported-by: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/ipv4/devinet.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index d5a4553..5345b0b 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -64,6 +64,8 @@
> #include <net/rtnetlink.h>
> #include <net/net_namespace.h>
>
> +#include "fib_lookup.h"
> +
> static struct ipv4_devconf ipv4_devconf = {
> .data = {
> [IPV4_DEVCONF_ACCEPT_REDIRECTS - 1] = 1,
> @@ -151,6 +153,20 @@ struct net_device *__ip_dev_find(struct net *net, __be32 addr, bool devref)
> break;
> }
> }
> + if (!result) {
> + struct flowi4 fl4 = { .daddr = addr };
> + struct fib_result res = { 0 };
> + struct fib_table *local;
> +
> + /* Fallback to FIB local table so that communication
> + * over loopback subnets work.
> + */
> + local = fib_get_table(net, RT_TABLE_LOCAL);
> + if (local &&
> + !fib_table_lookup(local, &fl4, &res, FIB_LOOKUP_NOREF) &&
> + res.type == RTN_LOCAL)
> + result = FIB_RES_DEV(res);
> + }
> if (result && devref)
> dev_hold(result);
> rcu_read_unlock();
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* Re: can: c_can: TX delivery
From: Jan Altenberg @ 2011-03-23 15:32 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: Jan Altenberg, bhupesh.sharma, wg, b.spranger, netdev
In-Reply-To: <20110323085340.GC346@e-circ.dyndns.org>
Hi,
> I split your 2 questions in 2 replies.
Thanks :)
> not sure if I made my point. Note that this will eliminate the need
> for explicit wrap-around. It's done implicitely.
Hmmm, I double-checked the datasheet, which gives the following statement:
"The receive/transmit priority for the Message Objects is attached to
the message number. Message Object 1 has the highest priority, while
Message Object 32 has the lowest priority. If more than one
transmission request is pending, they are serviced due to the priority
of the corresponding Message Object."
So, we shouldn't run into the scenario I described in my previous mail
and the existing implementation should be OK, right?! I'm quite sure
I've seen a situation where msg_obj 17 "seemed" to be pending, while
msg_obj 18 and 19 already have been transmitted. But in that case, I
enabled ONESHOT for the can interface, which enables the DA mode
(automatic
retransmission is disabled). The errata sheet for c_can covers that
mode. There's a problem with "Concurrent transmission requests" and I'm
quite sure my test-case hit that problem.
I'm quite new to Bosch's c_can, so maybe Bhupesh can give some feedback
(or beat me for causing some confusion ;-)).
Sorry for the confusion!
Jan
^ permalink raw reply
* Re: [RFC] myri10ge: small rx_done refactoring
From: Stephen Hemminger @ 2011-03-23 15:33 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: netdev, Andrew Gallatin, Brice Goglin
In-Reply-To: <20110323124939.GA7834@redhat.com>
On Wed, 23 Mar 2011 13:52:04 +0100
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Add lro_enable variable to read NETIF_F_LRO flag only once per napi poll
> call. This should fix theoretical race condition with
> myri10ge_set_rx_csum() and myri10ge_set_flags() where flag NETIF_F_LRO
> can be changed.
You may need a barrier or the race may still be there.
The driver seems to use mb() where wmb() is intended, and never use rmb()?
--
^ permalink raw reply
* RE: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Ben Hutchings @ 2011-03-23 15:46 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: davem@davemloft.net, netdev@vger.kernel.org, Eugenia Emantayev
In-Reply-To: <953B660C027164448AE903364AC447D20705BE28@mtldag01.mtl.com>
On Wed, 2011-03-23 at 15:10 +0000, Yevgeny Petrilin wrote:
> >
> > This is an abuse of the ethtool_drvinfo::driver field.
> >
> > Your users can use lspci -v, can't they?
> >
> I don't think there is a problem here.
> We have always reported the HW model via Ethtool, we just expanded the information
> we provide.
> Our users prefer to see the information in ethtool.
Do you mean 'we documented ethtool -i as the way to get hardware
identification'? That would be a bug in your documentation.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: can: c_can: TX delivery
From: Kurt Van Dijck @ 2011-03-23 15:49 UTC (permalink / raw)
To: Jan Altenberg; +Cc: bhupesh.sharma, wg, b.spranger, netdev
In-Reply-To: <ff5ade24e148af2e46832e5a64444d05.squirrel@www2.linutronix.de>
On Wed, Mar 23, 2011 at 04:32:31PM +0100, Jan Altenberg wrote:
> Hi,
>
> > I split your 2 questions in 2 replies.
>
> Thanks :)
>
> > not sure if I made my point. Note that this will eliminate the need
> > for explicit wrap-around. It's done implicitely.
>
> Hmmm, I double-checked the datasheet, which gives the following statement:
> "The receive/transmit priority for the Message Objects is attached to
> the message number. Message Object 1 has the highest priority, while
> Message Object 32 has the lowest priority. If more than one
> transmission request is pending, they are serviced due to the priority
> of the corresponding Message Object."
With its predecessor (I used it as IP inside infineon CPU's), this was also
true. But I _think_ that object 17 could send before object 16 if its identifier
is lower.
So, me too wait for Bhupesh ...
> I'm quite new to Bosch's c_can, so maybe Bhupesh can give some feedback
> (or beat me for causing some confusion ;-)).
>
> Sorry for the confusion!
> Jan
>
>
^ permalink raw reply
* RE: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Yevgeny Petrilin @ 2011-03-23 15:54 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org, Eugenia Emantayev
In-Reply-To: <1300895205.2638.0.camel@bwh-desktop>
> On Wed, 2011-03-23 at 15:10 +0000, Yevgeny Petrilin wrote:
> > >
> > > This is an abuse of the ethtool_drvinfo::driver field.
> > >
> > > Your users can use lspci -v, can't they?
> > >
> > I don't think there is a problem here.
> > We have always reported the HW model via Ethtool, we just expanded
> the information
> > we provide.
> > Our users prefer to see the information in ethtool.
>
> Do you mean 'we documented ethtool -i as the way to get hardware
> identification'? That would be a bug in your documentation.
>
> Ben.
This is not what I mean, All the required information can be found in lspci,
There are some requests to see part of this information also via ethtool
Yevgeny
^ permalink raw reply
* Re: [PATCH] ethtool: remove mask for Auto in advertise section
From: Ben Hutchings @ 2011-03-23 15:56 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Emil Tantilov, netdev
In-Reply-To: <1299310021-29027-1-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, 2011-03-04 at 23:27 -0800, Jeff Kirsher wrote:
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> The mask for Auto in the advertise section is incorrect for any interface
> that supports speeds > 1000Mbps. Since the description already states that
> the mask can be a combination of the supported values it's probably better
> to just remove it. 'Auto' was misleading anyway.
[...]
Applied.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2] net/unix: Add secdata to unix_stream msgs
From: Eric Paris @ 2011-03-23 15:57 UTC (permalink / raw)
To: David Miller
Cc: pekane52, linux-kernel, netdev, cxzhang, sds, jmorris, eparis,
paul.moore
In-Reply-To: <20110322.193206.28821045.davem@davemloft.net>
On Tue, 2011-03-22 at 19:32 -0700, David Miller wrote:
> From: Pat Kane <pekane52@gmail.com>
> Date: Tue, 22 Mar 2011 19:38:37 -0500
>
> > The unix_dgram routines add secdata to socket messages,
> > but the unix_stream routines do not. I have added the
> > two missing lines of code.
> >
> > Signed-off-by: Pat Kane <pekane52@gmail.com>
>
> The security hooks appear to be only intended to operate on datagram
> sockets, and as such I think the omission of UNIX stream sockets was
> very much on purpose.
>
> The SELINUX hook implementations even have "_dgram()" in their names.
>
> Catherine Zhang added to CC: as she last made modifications to these
> hooks.
And I'll add Paul Moore as I think he understands the intersection
of /net and /security better than anyone.
>
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index 1663e1a..8753cdd 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> > @@ -1642,6 +1642,8 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
> > max_level = err + 1;
> > fds_sent = true;
> >
> > + unix_get_secdata(siocb->scm, skb);
> > +
> > err = memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size);
> > if (err) {
> > kfree_skb(skb);
> > @@ -1930,6 +1932,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
> > } else {
> > /* Copy credentials */
> > scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).cred);
> > + unix_set_secdata(siocb->scm, skb);
> > check_creds = 1;
> > }
> >
> > --
> > 1.7.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Stephen Hemminger @ 2011-03-23 15:58 UTC (permalink / raw)
To: Ben Hutchings
Cc: Yevgeny Petrilin, davem@davemloft.net, netdev@vger.kernel.org,
Eugenia Emantayev
In-Reply-To: <1300895205.2638.0.camel@bwh-desktop>
On Wed, 23 Mar 2011 15:46:45 +0000
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Wed, 2011-03-23 at 15:10 +0000, Yevgeny Petrilin wrote:
> > >
> > > This is an abuse of the ethtool_drvinfo::driver field.
> > >
> > > Your users can use lspci -v, can't they?
> > >
> > I don't think there is a problem here.
> > We have always reported the HW model via Ethtool, we just expanded the information
> > we provide.
> > Our users prefer to see the information in ethtool.
>
> Do you mean 'we documented ethtool -i as the way to get hardware
> identification'? That would be a bug in your documentation.
We need consistency among drivers in these fields.
^ permalink raw reply
* RE: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Ben Hutchings @ 2011-03-23 16:08 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: davem@davemloft.net, netdev@vger.kernel.org, Eugenia Emantayev
In-Reply-To: <953B660C027164448AE903364AC447D20705BF27@mtldag01.mtl.com>
On Wed, 2011-03-23 at 15:54 +0000, Yevgeny Petrilin wrote:
> > On Wed, 2011-03-23 at 15:10 +0000, Yevgeny Petrilin wrote:
> > > >
> > > > This is an abuse of the ethtool_drvinfo::driver field.
> > > >
> > > > Your users can use lspci -v, can't they?
> > > >
> > > I don't think there is a problem here.
> > > We have always reported the HW model via Ethtool, we just expanded
> > the information
> > > we provide.
> > > Our users prefer to see the information in ethtool.
> >
> > Do you mean 'we documented ethtool -i as the way to get hardware
> > identification'? That would be a bug in your documentation.
> >
> > Ben.
>
> This is not what I mean, All the required information can be found in lspci,
> There are some requests to see part of this information also via ethtool
As Stephen says, the issue here is consistency between drivers.
Sometimes you just have to say no to customer requests that you abuse a
standard API.
You could perhaps include some sort of hardware type distinction in the
firmware version string, if it doesn't already incorporate that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2] net/unix: Add secdata to unix_stream msgs
From: Casey Schaufler @ 2011-03-23 16:11 UTC (permalink / raw)
To: Eric Paris
Cc: David Miller, pekane52, linux-kernel, netdev, cxzhang, sds,
jmorris, eparis, paul.moore, LSM
In-Reply-To: <1300895847.28871.13.camel@unknown001a4b0c2895>
On 3/23/2011 8:57 AM, Eric Paris wrote:
> On Tue, 2011-03-22 at 19:32 -0700, David Miller wrote:
>> From: Pat Kane <pekane52@gmail.com>
>> Date: Tue, 22 Mar 2011 19:38:37 -0500
>>
>>> The unix_dgram routines add secdata to socket messages,
>>> but the unix_stream routines do not. I have added the
>>> two missing lines of code.
>>>
>>> Signed-off-by: Pat Kane <pekane52@gmail.com>
>> The security hooks appear to be only intended to operate on datagram
>> sockets, and as such I think the omission of UNIX stream sockets was
>> very much on purpose.
>>
>> The SELINUX hook implementations even have "_dgram()" in their names.
>>
>> Catherine Zhang added to CC: as she last made modifications to these
>> hooks.
> And I'll add Paul Moore as I think he understands the intersection
> of /net and /security better than anyone.
Paul is definitely the man on this. I've also added the LSM list,
as while SELinux is the only current user of secdata that may not
always be the case.
>>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>>> index 1663e1a..8753cdd 100644
>>> --- a/net/unix/af_unix.c
>>> +++ b/net/unix/af_unix.c
>>> @@ -1642,6 +1642,8 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
>>> max_level = err + 1;
>>> fds_sent = true;
>>>
>>> + unix_get_secdata(siocb->scm, skb);
>>> +
>>> err = memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size);
>>> if (err) {
>>> kfree_skb(skb);
>>> @@ -1930,6 +1932,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
>>> } else {
>>> /* Copy credentials */
>>> scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).cred);
>>> + unix_set_secdata(siocb->scm, skb);
>>> check_creds = 1;
>>> }
>>>
>>> --
>>> 1.7.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* [RFC] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-03-23 16:56 UTC (permalink / raw)
To: Greg KH
Cc: andy.green, Alan Cox, Benjamin Herrenschmidt, Nicolas Pitre,
Jaswinder Singh, Linux USB list, lkml, broonie, roger.quadros,
grant.likely, netdev, David Brownell
In-Reply-To: <20110323162251.GA9367@kroah.com>
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_PTP setting in the usbnet
driver_info. A driver can set both FLAG_PTP and FLAG_ETHER if
it is not sure (e.g. cdc_ether), or just one of the two.
The usbnet framework only looks at the MAC address for device
naming if both flags are set, otherwise it trusts the flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: Andy Green <andy.green@linaro.org>
---
drivers/net/usb/cdc_eem.c | 2 +-
drivers/net/usb/cdc_ether.c | 2 +-
drivers/net/usb/cdc_ncm.c | 2 +-
drivers/net/usb/cdc_subset.c | 8 ++++++++
drivers/net/usb/gl620a.c | 2 +-
drivers/net/usb/net1080.c | 2 +-
drivers/net/usb/plusb.c | 2 +-
drivers/net/usb/rndis_host.c | 2 +-
drivers/net/usb/smsc75xx.c | 2 +-
drivers/net/usb/smsc95xx.c | 2 +-
drivers/net/usb/usbnet.c | 3 ++-
drivers/net/usb/zaurus.c | 8 ++++----
drivers/usb/serial/usb_wwan.c | 2 +-
include/linux/usb/usbnet.h | 2 ++
Not tested yet, could someone try this out on a panda board
and ideally on a CDC device as well?
diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
index 5f3b976..4d6bcb8 100644
--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -340,7 +340,7 @@ next:
static const struct driver_info eem_info = {
.description = "CDC EEM Device",
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_PTP,
.bind = eem_bind,
.rx_fixup = eem_rx_fixup,
.tx_fixup = eem_tx_fixup,
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 9a60e41..6dc89d0 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -450,7 +450,7 @@ static int cdc_manage_power(struct usbnet *dev, int on)
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
- .flags = FLAG_ETHER,
+ .flags = FLAG_ETHER | FLAG_PTP,
// .check_connect = cdc_check_connect,
.bind = cdc_bind,
.unbind = usbnet_cdc_unbind,
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 7113168..a6a026a 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1237,7 +1237,7 @@ static int cdc_ncm_manage_power(struct usbnet *dev, int status)
static const struct driver_info cdc_ncm_info = {
.description = "CDC NCM",
- .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET,
+ .flags = FLAG_PTP | FLAG_NO_SETINT | FLAG_MULTI_PACKET,
.bind = cdc_ncm_bind,
.unbind = cdc_ncm_unbind,
.check_connect = cdc_ncm_check_connect,
diff --git a/drivers/net/usb/cdc_subset.c b/drivers/net/usb/cdc_subset.c
index ca39ace..fbe2b1b 100644
--- a/drivers/net/usb/cdc_subset.c
+++ b/drivers/net/usb/cdc_subset.c
@@ -89,6 +89,7 @@ static int always_connected (struct usbnet *dev)
static const struct driver_info ali_m5632_info = {
.description = "ALi M5632",
+ .flags = FLAG_PTP,
};
#endif
@@ -110,6 +111,7 @@ static const struct driver_info ali_m5632_info = {
static const struct driver_info an2720_info = {
.description = "AnchorChips/Cypress 2720",
+ .flags = FLAG_PTP,
// no reset available!
// no check_connect available!
@@ -132,6 +134,7 @@ static const struct driver_info an2720_info = {
static const struct driver_info belkin_info = {
.description = "Belkin, eTEK, or compatible",
+ .flags = FLAG_PTP,
};
#endif /* CONFIG_USB_BELKIN */
@@ -157,6 +160,7 @@ static const struct driver_info belkin_info = {
static const struct driver_info epson2888_info = {
.description = "Epson USB Device",
.check_connect = always_connected,
+ .flags = FLAG_PTP,
.in = 4, .out = 3,
};
@@ -173,6 +177,7 @@ static const struct driver_info epson2888_info = {
#define HAVE_HARDWARE
static const struct driver_info kc2190_info = {
.description = "KC Technology KC-190",
+ .flags = FLAG_PTP,
};
#endif /* CONFIG_USB_KC2190 */
@@ -200,16 +205,19 @@ static const struct driver_info kc2190_info = {
static const struct driver_info linuxdev_info = {
.description = "Linux Device",
.check_connect = always_connected,
+ .flags = FLAG_PTP,
};
static const struct driver_info yopy_info = {
.description = "Yopy",
.check_connect = always_connected,
+ .flags = FLAG_PTP,
};
static const struct driver_info blob_info = {
.description = "Boot Loader OBject",
.check_connect = always_connected,
+ .flags = FLAG_PTP,
};
#endif /* CONFIG_USB_ARMLINUX */
diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
index dcd57c3..972ee83 100644
--- a/drivers/net/usb/gl620a.c
+++ b/drivers/net/usb/gl620a.c
@@ -193,7 +193,7 @@ static int genelink_bind(struct usbnet *dev, struct usb_interface *intf)
static const struct driver_info genelink_info = {
.description = "Genesys GeneLink",
- .flags = FLAG_FRAMING_GL | FLAG_NO_SETINT,
+ .flags = FLAG_PTP | FLAG_FRAMING_GL | FLAG_NO_SETINT,
.bind = genelink_bind,
.rx_fixup = genelink_rx_fixup,
.tx_fixup = genelink_tx_fixup,
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index ba72a72..f8a294e 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -560,7 +560,7 @@ static int net1080_bind(struct usbnet *dev, struct usb_interface *intf)
static const struct driver_info net1080_info = {
.description = "NetChip TurboCONNECT",
- .flags = FLAG_FRAMING_NC,
+ .flags = FLAG_PTP | FLAG_FRAMING_NC,
.bind = net1080_bind,
.reset = net1080_reset,
.check_connect = net1080_check_connect,
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 08ad269..0ac7845 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -96,7 +96,7 @@ static int pl_reset(struct usbnet *dev)
static const struct driver_info prolific_info = {
.description = "Prolific PL-2301/PL-2302",
- .flags = FLAG_NO_SETINT,
+ .flags = FLAG_PTP | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset = pl_reset,
};
diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index dd8a4ad..bf2ab6e 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -573,7 +573,7 @@ EXPORT_SYMBOL_GPL(rndis_tx_fixup);
static const struct driver_info rndis_info = {
.description = "RNDIS device",
- .flags = FLAG_ETHER | FLAG_FRAMING_RN | FLAG_NO_SETINT,
+ .flags = FLAG_ETHER | FLAG_PTP | FLAG_FRAMING_RN | FLAG_NO_SETINT,
.bind = rndis_bind,
.unbind = rndis_unbind,
.status = rndis_status,
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 753ee6e..404a475 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -1244,7 +1244,7 @@ static const struct driver_info smsc75xx_info = {
.rx_fixup = smsc75xx_rx_fixup,
.tx_fixup = smsc75xx_tx_fixup,
.status = smsc75xx_status,
- .flags = FLAG_ETHER | FLAG_SEND_ZLP,
+ .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
};
static const struct usb_device_id products[] = {
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index bc86f4b..c98d3a7 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1231,7 +1231,7 @@ static const struct driver_info smsc95xx_info = {
.rx_fixup = smsc95xx_rx_fixup,
.tx_fixup = smsc95xx_tx_fixup,
.status = smsc95xx_status,
- .flags = FLAG_ETHER | FLAG_SEND_ZLP,
+ .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
};
static const struct usb_device_id products[] = {
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 95c41d5..b339d3f 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1376,7 +1376,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
// else "eth%d" when there's reasonable doubt. userspace
// can rename the link if it knows better.
if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
- (net->dev_addr [0] & 0x02) == 0)
+ ((dev->driver_info->flags & FLAG_PTP) == 0 ||
+ (net->dev_addr [0] & 0x02) == 0))
strcpy (net->name, "eth%d");
/* WLAN devices should always be named "wlan%d" */
if ((dev->driver_info->flags & FLAG_WLAN) != 0)
diff --git a/drivers/net/usb/zaurus.c b/drivers/net/usb/zaurus.c
index 3eb0b16..e906700 100644
--- a/drivers/net/usb/zaurus.c
+++ b/drivers/net/usb/zaurus.c
@@ -102,7 +102,7 @@ static int always_connected (struct usbnet *dev)
static const struct driver_info zaurus_sl5x00_info = {
.description = "Sharp Zaurus SL-5x00",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_PTP | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -112,7 +112,7 @@ static const struct driver_info zaurus_sl5x00_info = {
static const struct driver_info zaurus_pxa_info = {
.description = "Sharp Zaurus, PXA-2xx based",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_PTP | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -122,7 +122,7 @@ static const struct driver_info zaurus_pxa_info = {
static const struct driver_info olympus_mxl_info = {
.description = "Olympus R1000",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_PTP | FLAG_FRAMING_Z,
.check_connect = always_connected,
.bind = zaurus_bind,
.unbind = usbnet_cdc_unbind,
@@ -258,7 +258,7 @@ bad_desc:
static const struct driver_info bogus_mdlm_info = {
.description = "pseudo-MDLM (BLAN) device",
- .flags = FLAG_FRAMING_Z,
+ .flags = FLAG_PTP | FLAG_FRAMING_Z,
.check_connect = always_connected,
.tx_fixup = zaurus_tx_fixup,
.bind = blan_mdlm_bind,
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 44842c8..5ecd8e7 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -97,6 +97,8 @@ struct driver_info {
#define FLAG_LINK_INTR 0x0800 /* updates link (carrier) status */
+#define FLAG_PTP 0x1000 /* maybe use "usb%d" names */
+
/*
* Indicates to usbnet, that USB driver accumulates multiple IP packets.
* Affects statistic (counters) and short packet handling.
^ permalink raw reply related
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Andy Green @ 2011-03-23 17:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, Alan Cox, Benjamin Herrenschmidt, Nicolas Pitre,
Jaswinder Singh, Linux USB list, lkml, broonie, roger.quadros,
grant.likely, netdev, David Brownell
In-Reply-To: <201103231756.39849.arnd@arndb.de>
On 03/23/2011 04:56 PM, Somebody in the thread at some point said:
> The approach taken here is to flag whether a device might be a
> point-to-point link with the new FLAG_PTP setting in the usbnet
> driver_info. A driver can set both FLAG_PTP and FLAG_ETHER if
> it is not sure (e.g. cdc_ether), or just one of the two.
> The usbnet framework only looks at the MAC address for device
> naming if both flags are set, otherwise it trusts the flag.
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index bc86f4b..c98d3a7 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -1231,7 +1231,7 @@ static const struct driver_info smsc95xx_info = {
> - .flags = FLAG_ETHER | FLAG_SEND_ZLP,
> + .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
> if ((dev->driver_info->flags& FLAG_ETHER) != 0&&
> + ((dev->driver_info->flags& FLAG_PTP) == 0 ||
> + (net->dev_addr [0]& 0x02) == 0))
> strcpy (net->name, "eth%d");
So it just takes the approach that all smsc95xx are going to be eth%d?
Sounds good to me.
-Andy
^ permalink raw reply
* Re: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Stephen Hemminger @ 2011-03-23 17:06 UTC (permalink / raw)
To: Ben Hutchings
Cc: Yevgeny Petrilin, davem@davemloft.net, netdev@vger.kernel.org,
Eugenia Emantayev
In-Reply-To: <1300896492.2638.13.camel@bwh-desktop>
On Wed, 23 Mar 2011 16:08:12 +0000
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Wed, 2011-03-23 at 15:54 +0000, Yevgeny Petrilin wrote:
> > > On Wed, 2011-03-23 at 15:10 +0000, Yevgeny Petrilin wrote:
> > > > >
> > > > > This is an abuse of the ethtool_drvinfo::driver field.
> > > > >
> > > > > Your users can use lspci -v, can't they?
> > > > >
> > > > I don't think there is a problem here.
> > > > We have always reported the HW model via Ethtool, we just expanded
> > > the information
> > > > we provide.
> > > > Our users prefer to see the information in ethtool.
> > >
> > > Do you mean 'we documented ethtool -i as the way to get hardware
> > > identification'? That would be a bug in your documentation.
> > >
> > > Ben.
> >
> > This is not what I mean, All the required information can be found in lspci,
> > There are some requests to see part of this information also via ethtool
>
> As Stephen says, the issue here is consistency between drivers.
> Sometimes you just have to say no to customer requests that you abuse a
> standard API.
>
> You could perhaps include some sort of hardware type distinction in the
> firmware version string, if it doesn't already incorporate that.
The pci info is already in bus_info and that can be used by tools.
Alternatively, many drivers splat revision/config info out to dmesg.
^ 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