* Re: [PATCH v2 linux-2.6.35-rc3] ks8842 driver
From: Simon Horman @ 2010-07-10 0:25 UTC (permalink / raw)
To: Choi, David; +Cc: David Miller, netdev, Li, Charles
In-Reply-To: <C43529A246480145B0A6D0234BDB0F0D0212A5@MELANITE.micrel.com>
On Fri, Jul 09, 2010 at 02:22:35PM -0700, Choi, David wrote:
> Hi all,
>
> I change the ks8842 driver so that the platform private data is used to pass
> different parameters like selection of 16/32bit, as suggested.
Thanks David, that seems a lot nicer to me.
^ permalink raw reply
* 2.6.35-rc4-git4: Reported regressions 2.6.33 -> 2.6.34
From: Rafael J. Wysocki @ 2010-07-10 0:24 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTES:
* This list seems to be shrinking at last.
* The bug entries with the NEEDINFO status will be closed next round if the
reporters don't follow up.]
This message contains a list of some post-2.6.33 regressions introduced before
2.6.34, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.33 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-07-10 122 25 24
2010-06-21 114 36 28
2010-06-13 111 40 34
2010-05-09 80 27 24
2010-05-04 76 26 22
2010-04-20 64 35 34
2010-04-07 48 35 33
2010-03-21 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16357
Subject : acpi-cpufreq fails to load (No such device)
Submitter : Ambroz Bizjak <ambrop7@gmail.com>
Date : 2010-07-09 09:40 (1 days old)
Handled-By : Thomas Renninger <trenn@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16348
Subject : kswapd continuously active when doing IO
Submitter : Marius Tolzmann <tolzmann@molgen.mpg.de>
Date : 2010-07-07 10:58 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16320
Subject : iwl3945 crashes, seems to be disconnecting from the PCI bus
Submitter : Satish <eerpini@gmail.com>
Date : 2010-07-01 08:24 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16318
Subject : macbook pro 5,1 does not boot with acpi
Submitter : <syamajala@gmail.com>
Date : 2010-06-30 13:38 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16300
Subject : [2.6.34 regression] mplayer gets out of sync due to problems with ALSA
Submitter : Artem S. Tashkinov <t.artem@mailcity.com>
Date : 2010-06-26 20:39 (14 days old)
Handled-By : Takashi Iwai <tiwai@suse.de>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16270
Subject : Image is a hit-or-a-miss. Often displayed green+purple
Submitter : Vish <drkvi-a@yahoo.com>
Date : 2010-06-22 10:47 (18 days old)
First-Bad-Commit: http://git.kernel.org/linus/acef4a407ed6e0a9ed87a2747be592fe49e64bdd
Handled-By : Jean-Francois Moine <moinejf@free.fr>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16233
Subject : Fwd: [2.6.34] INFO: task rsync:20019 blocked for more than 120 seconds.
Submitter : Jan De Luyck <mailinglists+linuxkernel_20080830@kcore.org>
Date : 2010-06-14 19:49 (26 days old)
Message-ID : <AANLkTimutyh3WIALv3NIxA8Xt5JtU6tp4EWOnuSqhdyD@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127654498016377&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16207
Subject : Suspend and VT switch hangs since 2.6.34
Submitter : Tino Keitel <tino.keitel+xorg@tikei.de>
Date : 2010-06-09 17:53 (31 days old)
Message-ID : <20100609175356.GA17332@x61.home>
References : http://marc.info/?l=linux-kernel&m=127610606214060&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16206
Subject : PROBLEM: PPP and other serial port related application hangs in kernel space
Submitter : Ales Teska <ales.teska@gmail.com>
Date : 2010-06-09 20:46 (31 days old)
Message-ID : <900E3B14-5B92-4A37-9581-049DB40F4D1C@gmail.com>
References : http://marc.info/?l=linux-kernel&m=127611640301071&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16170
Subject : Leadtek Winfast DTV Dongle (STK7700P based) is not working in 2.6.34
Submitter : <macjariel@gmail.com>
Date : 2010-06-09 11:11 (31 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16158
Subject : winxp guest hangs after idle for ~30 minutes
Submitter : <brimhall@pobox.com>
Date : 2010-06-08 17:52 (32 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16139
Subject : wait_even_interruptible_timeout(), signal, spin_lock() = system hang
Submitter : Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Date : 2010-05-28 16:44 (43 days old)
Message-ID : <AANLkTiliRFydAhxH2-Dp1RKuz6sq7vgWIcMvLMi68ftg@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127506510328758&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16137
Subject : Ooops in BTRFS in 2.6.34 / x86_64 when mounting subvolume by name
Submitter : armin walland <a.walland@focusmr.com>
Date : 2010-05-27 12:27 (44 days old)
Message-ID : <201005271428.01239.a.walland@focusmr.com>
References : http://marc.info/?l=linux-kernel&m=127496434110736&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16097
Subject : 2.6.34 on Samsung P460: reset after "Waiting for /dev to be fully populated"
Submitter : Harald Dunkel <harald.dunkel@aixigo.de>
Date : 2010-05-25 9:12 (46 days old)
Message-ID : <4BFB947E.9080509@aixigo.de>
References : http://marc.info/?l=linux-kernel&m=127477877432254&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16082
Subject : host panic on kernel 2.6.34
Submitter : Hao, Xudong <xudong.hao@intel.com>
Date : 2010-05-24 8:23 (47 days old)
Message-ID : <BC00F5384FCFC9499AF06F92E8B78A9E04DCCCE242@shsmsx502.ccr.corp.intel.com>
References : http://marc.info/?l=linux-kernel&m=127468951208864&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16050
Subject : The ibmcam driver is not working
Submitter : Bill Davidsen <davidsen@tmr.com>
Date : 2010-05-25 23:02 (46 days old)
Handled-By : Hans de Goede <hdegoede@redhat.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16035
Subject : Incorrect initial resolution of (external) vga monitor with KMS
Submitter : <andreas.eckstein@gmx.net>
Date : 2010-05-23 12:28 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15977
Subject : WARNING: at lib/dma-debug.c:866 check_for_stack
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2010-05-14 8:56 (57 days old)
Message-ID : <AANLkTikyx2eaxaiUCFDSfpmn1UG0t2GOxArz6F4wp1LJ@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127382742729825&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15912
Subject : Audio/video sync and crackling issues with snd-hda-intel (AD1981 codec)
Submitter : Øyvind Stegard <oyvinst@ifi.uio.no>
Date : 2010-05-05 16:20 (66 days old)
Handled-By : Jaroslav Kysela <perex@perex.cz>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15862
Subject : 2.6.34-rc4/5: iwlagn unusable until reload
Submitter : Nico Schottelius <nico-linux-20100427@schottelius.org>
Date : 2010-04-27 7:49 (74 days old)
Message-ID : <20100427074934.GB3261@ikn.schottelius.org>
References : http://marc.info/?l=linux-kernel&m=127235784004839&w=2
Handled-By : Johannes Berg <johannes@sipsolutions.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15805
Subject : reiserfs locking
Submitter : Alexander Beregalov <a.beregalov@gmail.com>
Date : 2010-04-15 21:02 (86 days old)
Message-ID : <t2ka4423d671004151402n7b2dc425mdc9c6bb9640d63fb@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127136535323933&w=2
Handled-By : Frederic Weisbecker <fweisbec@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15704
Subject : [r8169] WARNING: at net/sched/sch_generic.c
Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date : 2010-03-31 10:21 (101 days old)
Message-ID : <20100331102142.GA3294@swordfish.minsk.epam.com>
References : http://marc.info/?l=linux-kernel&m=127003090406108&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15673
Subject : 2.6.34-rc2: "ima_dec_counts: open/free imbalance"?
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2010-03-28 11:31 (104 days old)
Message-ID : <1269775909.5301.4.camel@localhost.localdomain>
References : http://marc.info/?l=linux-kernel&m=126977593326800&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15664
Subject : Graphics hang and kernel backtrace when starting Azureus with Compiz enabled
Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date : 2010-04-01 01:09 (100 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16007
Subject : x86/pci Oops with CONFIG_SND_HDA_INTEL
Submitter : Graham Ramsey <ramsey.graham@ntlworld.com>
Date : 2010-05-19 17:09 (52 days old)
Handled-By : Yinghai Lu <yinghai@kernel.org>
Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch : https://patchwork.kernel.org/patch/105662/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.33 and 2.6.34, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=15310
Please let the tracking teak know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: why doesn't close() wake a blocked read() --- and what should i do about it?
From: Ben Hutchings @ 2010-07-10 0:18 UTC (permalink / raw)
To: enh; +Cc: netdev
In-Reply-To: <AANLkTin4ugMqekRX389XxPx_R8Nu2cWYCLYtpU5rSrsU@mail.gmail.com>
On Fri, 2010-07-09 at 16:38 -0700, enh wrote:
> on Android (Linux 2.6.32), if one thread is in accept(2) and another
> thread calls close(2) on that socket, the first thread returns with an
> error.
This suffers from the same race condition you describe below: you don't
know whether the first thread is actually in accept() or is just about
to call it using the file descriptor you're invalidating.
> likewise if the first thread is in recv(2) waiting for a
> datagram packet. but if the first thread is just doing a regular
> read(2), it's not woken. (similarly for write(2).) this is unfortunate
> for me, because that's not how Java is supposed to work
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4344135); calling
> Socket.close from another thread is the way you're supposed to unblock
> such things. apps need this so they can free up threads. (and i'm
> trying to fix the VM so apps can do this.)
>
> it's well documented on the web that this is how linux behaves, though
> i didn't find any explanation of why, or why there's the discrepancy
> between read(2) and other similar operations. or is this just a bug?
I don't see any good reason for this behaviour, but even if the
behaviour was as you want it would not make it safe to call close() on a
socket used by another thread.
> on the assumption that this is something i need to work around in
> userspace, what's my best choice? i can pthread_kill the stuck
> threads, but that means they need to be somewhat aware of this hack.
>
> if they just TEMP_FAILURE_RETRY, there's a race condition if the fd
> has been reopened as something else between the close(2) and their
> retry. it also means i'm out of luck for code i don't control, such as
> openssl: that code is always going to be open to the race.
I don't see why you as the platform provider cannot modify your version
of OpenSSL.
> alternatively, i could have a pipe per thread, select(2) on both the
> pipe and the socket rather than read(2) directly, and then examine my
> fd_sets to see whether it's time to read or time to give up, but that
> seems unnecessarily resource-intensive, and also doesn't address the
> openssl case.
>
> alternatively, there's shutdown(2), but i'm not sure that really does
> what i want either.
I think this may be the way to go.
> for one thing, it's not clear what the interaction
> between shutdown(2) and SO_LINGER is (i'm thinking of write(2) here).
> i also find my unblocked read(2) returns 0 rather than -1 and some
> recognizable value of errno -- which isn't unreasonable in general,
> just for this particular use -- so i'd need to do some bookkeeping to
> check what that 0 really means.
You already need to mark the file descriptor in the Socket object as
invalid at the start of the close() method, to prevent any further calls
using it. Other methods can then check whether the file descriptor is
still valid after the system call if they need to distinguish error
cases.
> any comments on these ideas, or other ideas i haven't thought of?
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: net/sched/act_nat.c BUG
From: David Miller @ 2010-07-10 0:00 UTC (permalink / raw)
To: herbert; +Cc: eric.dumazet, rpartearroyo, linux-kernel, ipichel, nmoron, netdev
In-Reply-To: <20100709232359.GA2501@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 10 Jul 2010 07:23:59 +0800
> On Fri, Jul 09, 2010 at 05:13:40PM +0200, Eric Dumazet wrote:
>> Le vendredi 09 juillet 2010 à 16:37 +0200, Rodrigo Partearroyo González
>> a écrit :
>> > Hi all,
>> >
>> > I have been testing Stateless NAT and found that ICMP packets with length less
>> > than 20 bytes were not correctly NAT'ed. I have found a BUG that makes taking
>> > into account IP header length twice, so ICMP packets smaller than 20 bytes
>> > were being dropped.
>> >
>>
>> CC netdev
>>
>> > The proposed fix is:
>> >
>> > Index: net/sched/act_nat.c
>> > ===================================================================
>> > --- net/sched/act_nat.c
>> > +++ net/sched/act_nat.c
>> > @@ -202,7 +202,7 @@
>> > {
>> > struct icmphdr *icmph;
>> >
>> > - if (!pskb_may_pull(skb, ihl + sizeof(*icmph) + sizeof(*iph)))
>> > + if (!pskb_may_pull(skb, ihl + sizeof(*icmph)))
>> > goto drop;
>> >
>> > icmph = (void *)(skb_network_header(skb) + ihl);
>> >
>> > Please, consider applying it.
>>
>> Nice catch, but take a look at next lines too,
>> when call to skb_clone_writable() is done, since same error is present.
>>
>> skb_clone_writable(skb,
>> ihl + sizeof(*icmph) + sizeof(*iph))
>>
>> Please submit a formal patch, with your "Signed-off-by: ...", as
>> documented in Documentation/SubmittingPatches
>
> No we do need the second IP header, think about it...
>
> However, we should only drop it only if it's long enough and
> pskb_may_pull fails.
Ok, I've reverted until we come up with the proper fix, thanks.
^ permalink raw reply
* why doesn't close() wake a blocked read() --- and what should i do about it?
From: enh @ 2010-07-09 23:38 UTC (permalink / raw)
To: netdev
on Android (Linux 2.6.32), if one thread is in accept(2) and another
thread calls close(2) on that socket, the first thread returns with an
error. likewise if the first thread is in recv(2) waiting for a
datagram packet. but if the first thread is just doing a regular
read(2), it's not woken. (similarly for write(2).) this is unfortunate
for me, because that's not how Java is supposed to work
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4344135); calling
Socket.close from another thread is the way you're supposed to unblock
such things. apps need this so they can free up threads. (and i'm
trying to fix the VM so apps can do this.)
it's well documented on the web that this is how linux behaves, though
i didn't find any explanation of why, or why there's the discrepancy
between read(2) and other similar operations. or is this just a bug?
on the assumption that this is something i need to work around in
userspace, what's my best choice? i can pthread_kill the stuck
threads, but that means they need to be somewhat aware of this hack.
if they just TEMP_FAILURE_RETRY, there's a race condition if the fd
has been reopened as something else between the close(2) and their
retry. it also means i'm out of luck for code i don't control, such as
openssl: that code is always going to be open to the race.
alternatively, i could have a pipe per thread, select(2) on both the
pipe and the socket rather than read(2) directly, and then examine my
fd_sets to see whether it's time to read or time to give up, but that
seems unnecessarily resource-intensive, and also doesn't address the
openssl case.
alternatively, there's shutdown(2), but i'm not sure that really does
what i want either. for one thing, it's not clear what the interaction
between shutdown(2) and SO_LINGER is (i'm thinking of write(2) here).
i also find my unblocked read(2) returns 0 rather than -1 and some
recognizable value of errno -- which isn't unreasonable in general,
just for this particular use -- so i'd need to do some bookkeeping to
check what that 0 really means.
any comments on these ideas, or other ideas i haven't thought of?
thanks,
--elliott
^ permalink raw reply
* Re: net/sched/act_nat.c BUG
From: Herbert Xu @ 2010-07-09 23:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Rodrigo Partearroyo González, Linux Kernel Mailing List,
Iratxo Pichel Ortiz, Noelia Morón, netdev
In-Reply-To: <1278688420.2696.7.camel@edumazet-laptop>
On Fri, Jul 09, 2010 at 05:13:40PM +0200, Eric Dumazet wrote:
> Le vendredi 09 juillet 2010 à 16:37 +0200, Rodrigo Partearroyo González
> a écrit :
> > Hi all,
> >
> > I have been testing Stateless NAT and found that ICMP packets with length less
> > than 20 bytes were not correctly NAT'ed. I have found a BUG that makes taking
> > into account IP header length twice, so ICMP packets smaller than 20 bytes
> > were being dropped.
> >
>
> CC netdev
>
> > The proposed fix is:
> >
> > Index: net/sched/act_nat.c
> > ===================================================================
> > --- net/sched/act_nat.c
> > +++ net/sched/act_nat.c
> > @@ -202,7 +202,7 @@
> > {
> > struct icmphdr *icmph;
> >
> > - if (!pskb_may_pull(skb, ihl + sizeof(*icmph) + sizeof(*iph)))
> > + if (!pskb_may_pull(skb, ihl + sizeof(*icmph)))
> > goto drop;
> >
> > icmph = (void *)(skb_network_header(skb) + ihl);
> >
> > Please, consider applying it.
>
> Nice catch, but take a look at next lines too,
> when call to skb_clone_writable() is done, since same error is present.
>
> skb_clone_writable(skb,
> ihl + sizeof(*icmph) + sizeof(*iph))
>
> Please submit a formal patch, with your "Signed-off-by: ...", as
> documented in Documentation/SubmittingPatches
No we do need the second IP header, think about it...
However, we should only drop it only if it's long enough and
pskb_may_pull fails.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH net-next-2.6 2/2] qlcnic: Disable admin tools interface for VF driver mode
From: Anirban Chakraborty @ 2010-07-09 23:15 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org; +Cc: Dept_NX_Linux_NIC_Driver
Non privileged (VF) driver will not be able to carry out any of the FW update,
etc. operations. Disable the tools interface by not creating the sysfs nodes.
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index c334f1a..4d18313 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -3272,6 +3272,8 @@ qlcnic_create_diag_entries(struct qlcnic_adapter *adapter)
{
struct device *dev = &adapter->pdev->dev;
+ if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC)
+ return;
if (device_create_file(dev, &dev_attr_diag_mode))
dev_info(dev, "failed to create diag_mode sysfs entry\n");
if (device_create_bin_file(dev, &bin_attr_crb))
@@ -3292,12 +3294,13 @@ qlcnic_create_diag_entries(struct qlcnic_adapter *adapter)
}
-
static void
qlcnic_remove_diag_entries(struct qlcnic_adapter *adapter)
{
struct device *dev = &adapter->pdev->dev;
+ if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC)
+ return;
device_remove_file(dev, &dev_attr_diag_mode);
device_remove_bin_file(dev, &bin_attr_crb);
device_remove_bin_file(dev, &bin_attr_mem);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next-2.6 1/2] qlcnic: Check FW capability for TSO
From: Anirban Chakraborty @ 2010-07-09 23:14 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org; +Cc: Dept_NX_Linux_NIC_Driver
Driver checks TSO capability from FW before enabling it.
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 7 ++++---
drivers/net/qlcnic/qlcnic_ethtool.c | 3 +++
drivers/net/qlcnic/qlcnic_main.c | 10 +++++++---
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 60ea7cb..02a50e6 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -821,9 +821,10 @@ struct qlcnic_nic_intr_coalesce {
#define QLCNIC_LRO_REQUEST_CLEANUP 4
/* Capabilites received */
-#define QLCNIC_FW_CAPABILITY_BDG (1 << 8)
-#define QLCNIC_FW_CAPABILITY_FVLANTX (1 << 9)
-#define QLCNIC_FW_CAPABILITY_HW_LRO (1 << 10)
+#define QLCNIC_FW_CAPABILITY_TSO BIT_1
+#define QLCNIC_FW_CAPABILITY_BDG BIT_8
+#define QLCNIC_FW_CAPABILITY_FVLANTX BIT_9
+#define QLCNIC_FW_CAPABILITY_HW_LRO BIT_10
/* module types */
#define LINKEVENT_MODULE_NOT_PRESENT 1
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index f8e39e4..baf5a52 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -820,6 +820,9 @@ static u32 qlcnic_get_tso(struct net_device *dev)
static int qlcnic_set_tso(struct net_device *dev, u32 data)
{
+ struct qlcnic_adapter *adapter = netdev_priv(dev);
+ if (!(adapter->capabilities & QLCNIC_FW_CAPABILITY_TSO))
+ return -EOPNOTSUPP;
if (data)
dev->features |= (NETIF_F_TSO | NETIF_F_TSO6);
else
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 18e2b2e..c334f1a 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1226,10 +1226,14 @@ qlcnic_setup_netdev(struct qlcnic_adapter *adapter,
SET_ETHTOOL_OPS(netdev, &qlcnic_ethtool_ops);
netdev->features |= (NETIF_F_SG | NETIF_F_IP_CSUM |
- NETIF_F_IPV6_CSUM | NETIF_F_GRO | NETIF_F_TSO | NETIF_F_TSO6);
-
+ NETIF_F_IPV6_CSUM | NETIF_F_GRO);
netdev->vlan_features |= (NETIF_F_SG | NETIF_F_IP_CSUM |
- NETIF_F_IPV6_CSUM | NETIF_F_TSO | NETIF_F_TSO6);
+ NETIF_F_IPV6_CSUM);
+
+ if (adapter->capabilities & QLCNIC_FW_CAPABILITY_TSO) {
+ netdev->features |= (NETIF_F_TSO | NETIF_F_TSO6);
+ netdev->vlan_features |= (NETIF_F_TSO | NETIF_F_TSO6);
+ }
if (pci_using_dac) {
netdev->features |= NETIF_F_HIGHDMA;
--
1.7.1
^ permalink raw reply related
* Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-07-09 21:35 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Linus Torvalds, Linux Kernel Mailing List, Maciej Rutecki,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, Al Viro, Shawn Starr, Jesse Barnes, Dave Airlie,
David S. Miller, Patrick McHardy, Jens Axboe
In-Reply-To: <20100709020440.GJ6405@nowhere>
On Friday, July 09, 2010, Frederic Weisbecker wrote:
> On Thu, Jul 08, 2010 at 06:34:25PM -0700, Linus Torvalds wrote:
> > On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16284
> > > Subject : Hitting WARN_ON in hw_breakpoint code
> > > Submitter : Paul Mackerras <paulus@samba.org>
> > > Date : 2010-06-23 12:57 (16 days old)
> > > Message-ID : <20100623125740.GA3368@brick.ozlabs.ibm.com>
> > > References : http://marc.info/?l=linux-kernel&m=127729789113432&w=2
> >
> > This has "I have a fix, will post it very soon." in the thread from
> > Frederic, but I'm not seeing anything else. Frederic?
>
>
>
> Right. In fact it wasn't a regression. The per task breakpoint reservation
> design was broken from the beginning and this warning has revealed the
> problem. This only touched perf, and it did since perf support breakpoints.
> Fortunately ptrace wasn't concerned by this problem, even not by side effects
> of this.
>
> The fix is invasive as it's a rewrite of a (little) part of the breakpoint
> reservation. And since the symptom is only a warning and also breakpoints
> never released from the constraint table (just a counter, no memory leak),
> the fix is headed for 2.6.36.
>
> It is ready in tip:/perf/core:
>
> http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commitdiff;h=45a73372efe4a63f44aa2e1125d4a777c2fdc8d8
>
> I think this ticket can be safely closed.
OK, closing.
Rafael
^ permalink raw reply
* Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-07-09 21:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI,
Frederic Weisbecker, Al Viro, Shawn Starr, Jesse Barnes,
Dave Airlie, David S. Miller, Patrick McHardy, Jens Axboe
In-Reply-To: <AANLkTiknnzWyVpqnPCpyiEVHLgkewd0zaGzLInABRe2G-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Friday, July 09, 2010, Linus Torvalds wrote:
> On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >
> > Unresolved regressions
> > ----------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16353
> > Subject : 2.6.35 regression
> > Submitter : Zeev Tarantov <zeev.tarantov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-07-05 13:04 (4 days old)
> > Message-ID : <loom.20100705T144459-919-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=127836002702522&w=2
>
> This is a gcc-4.5 issue. Whether it's also something that we should
> change in the kernel is unclear, but at least as of now, the rule is
> that you cannot compile the kernel with gcc-4.5. No idea whether the
> compiler is just entirely broken, or whether it's just that it
> triggers something iffy by being overly clever.
This claims to fix it, though: https://patchwork.kernel.org/patch/110988/
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16346
> > Subject : 2.6.35-rc3-git8 - include/linux/fdtable.h:88 invoked rcu_dereference_check() without protection!
> > Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-07-04 22:04 (5 days old)
> > Message-ID : <AANLkTinof0k28rk4rMr66aubxcRL2rFa5ZEArj1lqD3o@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127828107815930&w=2
>
> I'm not entirely sure if these RCU proving things should count as regressions.
>
> Sure, the option to enable RCU proving is new, but the things it
> reports about generally are not new - and they are usually not even
> bugs in the sense that they necessarily cause any real problems.
>
> That particular one is in the single-thread optimizated case for fget_light, ie
>
> if (likely((atomic_read(&files->count) == 1))) {
> file = fcheck_files(files, fd);
>
> where I think it should be entirely safe in all ways without any
> locking. So I think it's a false positive too.
OK, so I'm going to close these bugs.
...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16333
> > Subject : iwl3945: HARDWARE GONE??
> > Submitter : Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
> > Date : 2010-07-02 16:02 (7 days old)
> > Message-ID : <1278086575.2889.8.camel@chi>
> > References : http://marc.info/?l=linux-kernel&m=127808659705983&w=2
>
> This either got fixed, or will be practically impossible to debug. The
> reporter ends up being unable to reproduce the issue.
Closed as unreproducible.
...
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16330
> > Subject : Dynamic Debug broken on 2.6.35-rc3?
> > Submitter : Thomas Renninger <trenn-l3A5Bk7waGM@public.gmane.org>
> > Date : 2010-07-01 15:44 (8 days old)
> > Message-ID : <201007011744.19564.trenn-l3A5Bk7waGM@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=127799907218877&w=2
>
> There's a suggested patch in
>
> http://marc.info/?l=linux-kernel&m=127862524404291&w=2
>
> but no reply to it yet.
Patch information added to the bug entry (it's been confirmed to work).
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16329
> > Subject : 2.6.35-rc3: Load average climbing to 3+ with no apparent reason: CPU 98% idle, with hardly no I/O
> > Submitter : Török Edwin <edwintorok-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-07-01 7:40 (8 days old)
> > Message-ID : <20100701104022.404410d6@debian>
> > References : http://marc.info/?l=linux-kernel&m=127797005030536&w=2
>
> This seems to be partly a confusion about what "load average" is. It's
> not a CPU load, it's a system load average, and disk-wait processes
> count towards it. He has some problem with his CD-ROM, and it sounds
> like it might be hardware on the verge of going bad.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16324
> > Subject : Oops while running fs_racer test on a POWER6 box against latest git
> > Submitter : divya <dipraksh-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> > Date : 2010-06-30 11:34 (9 days old)
> > Message-ID : <4C2B28F3.7000006-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=127789697303061&w=2
>
> I wonder if this is the writeback problem. That POWER crash dump is
> unreadable, so it's hard to tell, but the load in question makes that
> at least likely.
>
> If so, it should hopefully be fixed in today's git (commit
> 83ba7b071f30f7c01f72518ad72d5cd203c27502 and friends).
OK, closed.
> > Bug-entry : http://bugzilla.kernel.org/show_bug.cgi?id=16323
> > Subject : 2.6.35-rc3-git4 - kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> > Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-07-01 12:21 (8 days old)
> > Message-ID : <AANLkTini6hz2LFeZi8CMUmY3xw1MU7NxmyesuxZ4oCdo@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127798693125541&w=2
>
> See earlier about these being marked as regressions, but it should be
> fixed by commit dc61b1d6 ("sched: Fix PROVE_RCU vs cpu_cgroup").
Closed.
...
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16309
> > Subject : 2.6.35-rc3 oops trying to suspend.
> > Submitter : Andrew Hendry <andrew.hendry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-06-27 12:40 (12 days old)
> > Message-ID : <AANLkTinUH2p33-AWxOVDrLsNkn9rgEVrlwn5mfK7P8NH@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127764249926781&w=2
>
> I'm pretty sure this was fixed by Nick in commit 57439f878afa ("fs:
> fix superblock iteration race").
Closed.
...
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16304
> > Subject : i915 - high number of wakeups
> > Submitter : Enrico Bandiello <enban-c0jvKHQHzSzx4jp4WZvp5g@public.gmane.org>
> > Date : 2010-06-27 09:52 (12 days old)
>
> Duplicate of that 16307 one.
Closed.
...
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16230
> > Subject : inconsistent IN-HARDIRQ-W -> HARDIRQ-ON-W usage: fasync, 2.6.35-rc3
> > Submitter : Dominik Brodowski <linux-X3ehHDuj6sIIGcDfoQAp7OTW4wlIGRCZ@public.gmane.org>
> > Date : 2010-06-13 9:53 (26 days old)
> > Message-ID : <20100613095305.GA13231-S7uyTPAaJ/sb6pqDj42GsMgv3T4z79SOs0AfqQuZ5sE@public.gmane.orgt>
> > References : http://marc.info/?l=linux-kernel&m=127642282208277&w=2
>
> Fixed by commit f4985dc714d7.
Closed.
...
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16205
> > Subject : acpi: freeing invalid memtype bf799000-bf79a000
> > Submitter : Marcin Slusarz <marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-06-09 20:09 (30 days old)
> > Message-ID : <20100609200910.GA2876-OI9uyE9O0yo@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=127611427029914&w=2
> > http://marc.info/?l=linux-kernel&m=127688398513862&w=2
>
> This should be fixed by commit b945d6b2554d ("rbtree: Undo augmented
> trees performance damage and regression").
Yup, closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16199
> > Subject : 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
> > Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-06-07 18:14 (32 days old)
> > Message-ID : <AANLkTin2pPqOUx--9fIX3BH3e-cU6oCRufijcx_4ozx5@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127593447812015&w=2
>
> Another RCU proving thing. And this one looks the same as the 16323
> one above, and fixed by the same commit as that one.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16197
> > Subject : [BUG on 2.6.35-rc2] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:11.0/0000:02:03.0/slot'
> > Submitter : Ryan Wang <openspace.wang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-06-07 0:23 (32 days old)
> > Message-ID : <AANLkTincwMZPnYW3S4uz4k2GOn52RpgBIBRfzyD010Yo@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127587022219378&w=2
>
> These should all be gone. See commit 3be434f0244ee by Jesse ('Revert
> "PCI: create function symlinks in /sys/bus/pci/slots/N/"').
Yes, I've already closed it.
...
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16175
> > Subject : 2.6.35-rc1 system oom, many processes killed but memory not free
> > Submitter : andrew hendry <andrew.hendry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-06-05 0:46 (34 days old)
> > Message-ID : <AANLkTim7CiW-yfugZUAHZCqLvXKgt9CwolCvbLGdCLAk@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127569877714937&w=2
>
> Not a regression or a kernel bug at all. See the thread. Big ramdisk
> filled up all of memory when it was filled by the builds.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16145
> > Subject : Unable to boot unless "notsc" or "clocksource=hpet", or acpi_pad disabling the TSC
> > Submitter : Tom Gundersen <teg-B22kvLQNl6c@public.gmane.org>
> > Date : 2010-06-07 13:11 (32 days old)
> > Handled-By : Venkatesh Pallipadi <venki-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> This is not a regression. See the full bugzilla details. The same
> problem persists at least back to 2.6.30 with his config. So it's
> somehow specific to his particular config use that requires "notsc" to
> boot.
Dropped from the list.
Thanks,
Rafael
^ permalink raw reply
* RE: [PATCH v2 linux-2.6.35-rc3] ks8842 driver
From: Choi, David @ 2010-07-09 21:22 UTC (permalink / raw)
To: Simon Horman, David Miller; +Cc: netdev, Li, Charles
In-Reply-To: <20100709060808.GA20370@verge.net.au>
Hi all,
I change the ks8842 driver so that the platform private data is used to pass
different parameters like selection of 16/32bit, as suggested.
---
--- linux-2.6.35-rc3/drivers/net/ks8842.c.orig 2010-07-01 16:26:50.000000000 -0700
+++ linux-2.6.35-rc3/drivers/net/ks8842.c 2010-07-09 13:27:37.000000000 -0700
@@ -18,6 +18,7 @@
/* Supports:
* The Micrel KS8842 behind the timberdale FPGA
+ * The genuine Micrel KS8841/42 device with ISA 16/32bit bus interface
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -114,9 +115,14 @@
#define REG_P1CR4 0x02
#define REG_P1SR 0x04
+/* flags passed by platform_device for configuration */
+#define MICREL_KS884X 0x01 /* 0=Timeberdale(FPGA), 1=Micrel */
+#define KS884X_16BIT 0x02 /* 1=16bit, 0=32bit */
+
struct ks8842_adapter {
void __iomem *hw_addr;
int irq;
+ unsigned long conf_flags; /* copy of platform_device config */
struct tasklet_struct tasklet;
spinlock_t lock; /* spinlock to be interrupt safe */
struct platform_device *pdev;
@@ -191,16 +197,22 @@ static inline u32 ks8842_read32(struct k
static void ks8842_reset(struct ks8842_adapter *adapter)
{
- /* The KS8842 goes haywire when doing softare reset
- * a work around in the timberdale IP is implemented to
- * do a hardware reset instead
- ks8842_write16(adapter, 3, 1, REG_GRR);
- msleep(10);
- iowrite16(0, adapter->hw_addr + REG_GRR);
- */
- iowrite16(32, adapter->hw_addr + REG_SELECT_BANK);
- iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
- msleep(20);
+ if (adapter->conf_flags & MICREL_KS884X) {
+ ks8842_write16(adapter, 3, 1, REG_GRR);
+ msleep(10);
+ iowrite16(0, adapter->hw_addr + REG_GRR);
+ } else {
+ /* The KS8842 goes haywire when doing softare reset
+ * a work around in the timberdale IP is implemented to
+ * do a hardware reset instead
+ ks8842_write16(adapter, 3, 1, REG_GRR);
+ msleep(10);
+ iowrite16(0, adapter->hw_addr + REG_GRR);
+ */
+ iowrite16(32, adapter->hw_addr + REG_SELECT_BANK);
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
+ msleep(20);
+ }
}
static void ks8842_update_link_status(struct net_device *netdev,
@@ -269,8 +281,10 @@ static void ks8842_reset_hw(struct ks884
/* restart port auto-negotiation */
ks8842_enable_bits(adapter, 49, 1 << 13, REG_P1CR4);
- /* only advertise 10Mbps */
- ks8842_clear_bits(adapter, 49, 3 << 2, REG_P1CR4);
+
+ if (!(adapter->conf_flags & MICREL_KS884X))
+ /* only advertise 10Mbps */
+ ks8842_clear_bits(adapter, 49, 3 << 2, REG_P1CR4);
/* Enable the transmitter */
ks8842_enable_tx(adapter);
@@ -296,13 +310,28 @@ static void ks8842_read_mac_addr(struct
for (i = 0; i < ETH_ALEN; i++)
dest[ETH_ALEN - i - 1] = ks8842_read8(adapter, 2, REG_MARL + i);
- /* make sure the switch port uses the same MAC as the QMU */
- mac = ks8842_read16(adapter, 2, REG_MARL);
- ks8842_write16(adapter, 39, mac, REG_MACAR1);
- mac = ks8842_read16(adapter, 2, REG_MARM);
- ks8842_write16(adapter, 39, mac, REG_MACAR2);
- mac = ks8842_read16(adapter, 2, REG_MARH);
- ks8842_write16(adapter, 39, mac, REG_MACAR3);
+ if (adapter->conf_flags & MICREL_KS884X) {
+ /*
+ the sequence of saving mac addr between MAC and Switch is
+ different.
+ */
+
+ mac = ks8842_read16(adapter, 2, REG_MARL);
+ ks8842_write16(adapter, 39, mac, REG_MACAR3);
+ mac = ks8842_read16(adapter, 2, REG_MARM);
+ ks8842_write16(adapter, 39, mac, REG_MACAR2);
+ mac = ks8842_read16(adapter, 2, REG_MARH);
+ ks8842_write16(adapter, 39, mac, REG_MACAR1);
+ } else {
+
+ /* make sure the switch port uses the same MAC as the QMU */
+ mac = ks8842_read16(adapter, 2, REG_MARL);
+ ks8842_write16(adapter, 39, mac, REG_MACAR1);
+ mac = ks8842_read16(adapter, 2, REG_MARM);
+ ks8842_write16(adapter, 39, mac, REG_MACAR2);
+ mac = ks8842_read16(adapter, 2, REG_MARH);
+ ks8842_write16(adapter, 39, mac, REG_MACAR3);
+ }
}
static void ks8842_write_mac_addr(struct ks8842_adapter *adapter, u8 *mac)
@@ -313,8 +342,25 @@ static void ks8842_write_mac_addr(struct
spin_lock_irqsave(&adapter->lock, flags);
for (i = 0; i < ETH_ALEN; i++) {
ks8842_write8(adapter, 2, mac[ETH_ALEN - i - 1], REG_MARL + i);
- ks8842_write8(adapter, 39, mac[ETH_ALEN - i - 1],
- REG_MACAR1 + i);
+ if (!(adapter->conf_flags & MICREL_KS884X))
+ ks8842_write8(adapter, 39, mac[ETH_ALEN - i - 1],
+ REG_MACAR1 + i);
+ }
+
+ if (adapter->conf_flags & MICREL_KS884X) {
+ /*
+ the sequence of saving mac addr between MAC and Switch is
+ different.
+ */
+
+ u16 mac;
+
+ mac = ks8842_read16(adapter, 2, REG_MARL);
+ ks8842_write16(adapter, 39, mac, REG_MACAR3);
+ mac = ks8842_read16(adapter, 2, REG_MARM);
+ ks8842_write16(adapter, 39, mac, REG_MACAR2);
+ mac = ks8842_read16(adapter, 2, REG_MARH);
+ ks8842_write16(adapter, 39, mac, REG_MACAR1);
}
spin_unlock_irqrestore(&adapter->lock, flags);
}
@@ -328,8 +374,6 @@ static int ks8842_tx_frame(struct sk_buf
{
struct ks8842_adapter *adapter = netdev_priv(netdev);
int len = skb->len;
- u32 *ptr = (u32 *)skb->data;
- u32 ctrl;
dev_dbg(&adapter->pdev->dev,
"%s: len %u head %p data %p tail %p end %p\n",
@@ -340,17 +384,34 @@ static int ks8842_tx_frame(struct sk_buf
if (ks8842_tx_fifo_space(adapter) < len + 8)
return NETDEV_TX_BUSY;
- /* the control word, enable IRQ, port 1 and the length */
- ctrl = 0x8000 | 0x100 | (len << 16);
- ks8842_write32(adapter, 17, ctrl, REG_QMU_DATA_LO);
-
- netdev->stats.tx_bytes += len;
-
- /* copy buffer */
- while (len > 0) {
- iowrite32(*ptr, adapter->hw_addr + REG_QMU_DATA_LO);
- len -= sizeof(u32);
- ptr++;
+ if (adapter->conf_flags & KS884X_16BIT) {
+ u16 *ptr16 = (u16 *)skb->data;
+ ks8842_write16(adapter, 17, 0x8000 | 0x100, REG_QMU_DATA_LO);
+ ks8842_write16(adapter, 17, (u16)len, REG_QMU_DATA_HI);
+ netdev->stats.tx_bytes += len;
+
+ /* copy buffer */
+ while (len > 0) {
+ iowrite16(*ptr16++, adapter->hw_addr + REG_QMU_DATA_LO);
+ iowrite16(*ptr16++, adapter->hw_addr + REG_QMU_DATA_HI);
+ len -= sizeof(u32);
+ }
+ } else {
+
+ u32 *ptr = (u32 *)skb->data;
+ u32 ctrl;
+ /* the control word, enable IRQ, port 1 and the length */
+ ctrl = 0x8000 | 0x100 | (len << 16);
+ ks8842_write32(adapter, 17, ctrl, REG_QMU_DATA_LO);
+
+ netdev->stats.tx_bytes += len;
+
+ /* copy buffer */
+ while (len > 0) {
+ iowrite32(*ptr, adapter->hw_addr + REG_QMU_DATA_LO);
+ len -= sizeof(u32);
+ ptr++;
+ }
}
/* enqueue packet */
@@ -364,13 +425,23 @@ static int ks8842_tx_frame(struct sk_buf
static void ks8842_rx_frame(struct net_device *netdev,
struct ks8842_adapter *adapter)
{
- u32 status = ks8842_read32(adapter, 17, REG_QMU_DATA_LO);
- int len = (status >> 16) & 0x7ff;
-
- status &= 0xffff;
-
- dev_dbg(&adapter->pdev->dev, "%s - rx_data: status: %x\n",
- __func__, status);
+ u16 status16;
+ u32 status;
+ int len;
+
+ if (adapter->conf_flags & KS884X_16BIT) {
+ status16 = ks8842_read16(adapter, 17, REG_QMU_DATA_LO);
+ len = (int)ks8842_read16(adapter, 17, REG_QMU_DATA_HI);
+ len &= 0xffff;
+ dev_dbg(&adapter->pdev->dev, "%s - rx_data: status: %x\n",
+ __func__, status16);
+ } else {
+ status = ks8842_read32(adapter, 17, REG_QMU_DATA_LO);
+ len = (status >> 16) & 0x7ff;
+ status &= 0xffff;
+ dev_dbg(&adapter->pdev->dev, "%s - rx_data: status: %x\n",
+ __func__, status);
+ }
/* check the status */
if ((status & RXSR_VALID) && !(status & RXSR_ERROR)) {
@@ -379,22 +450,32 @@ static void ks8842_rx_frame(struct net_d
dev_dbg(&adapter->pdev->dev, "%s, got package, len: %d\n",
__func__, len);
if (skb) {
- u32 *data;
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += len;
if (status & RXSR_MULTICAST)
netdev->stats.multicast++;
- data = (u32 *)skb_put(skb, len);
-
- ks8842_select_bank(adapter, 17);
- while (len > 0) {
- *data++ = ioread32(adapter->hw_addr +
- REG_QMU_DATA_LO);
- len -= sizeof(u32);
+ if (adapter->conf_flags & KS884X_16BIT) {
+ u16 *data16 = (u16 *)skb_put(skb, len);
+ ks8842_select_bank(adapter, 17);
+ while (len > 0) {
+ *data16++ = ioread16(adapter->hw_addr +
+ REG_QMU_DATA_LO);
+ *data16++ = ioread16(adapter->hw_addr +
+ REG_QMU_DATA_HI);
+ len -= sizeof(u32);
+ }
+ } else {
+ u32 *data = (u32 *)skb_put(skb, len);
+
+ ks8842_select_bank(adapter, 17);
+ while (len > 0) {
+ *data++ = ioread32(adapter->hw_addr +
+ REG_QMU_DATA_LO);
+ len -= sizeof(u32);
+ }
}
-
skb->protocol = eth_type_trans(skb, netdev);
netif_rx(skb);
} else
@@ -654,6 +735,8 @@ static int __devinit ks8842_probe(struct
adapter = netdev_priv(netdev);
adapter->hw_addr = ioremap(iomem->start, resource_size(iomem));
+ adapter->conf_flags = iomem->flags;
+
if (!adapter->hw_addr)
goto err_ioremap;
--- linux-2.6.35-rc3/drivers/net/Kconfig.orig 2010-07-02 15:52:41.000000000 -0700
+++ linux-2.6.35-rc3/drivers/net/Kconfig 2010-07-09 13:33:56.000000000 -0700
@@ -1748,11 +1748,12 @@ config TLAN
Please email feedback to <torben.mathiasen@compaq.com>.
config KS8842
- tristate "Micrel KSZ8842"
+ tristate "Micrel KSZ8841/42 with generic bus interface"
depends on HAS_IOMEM
help
- This platform driver is for Micrel KSZ8842 / KS8842
- 2-port ethernet switch chip (managed, VLAN, QoS).
+ This platform driver is for KSZ8841(1-port) / KS8842(2-port)
+ ethernet switch chip (managed, VLAN, QoS) from Micrel or
+ Timberdale(FPGA).
config KS8851
tristate "Micrel KS8851 SPI"
---
-----Original Message-----
From: Simon Horman [mailto:horms@verge.net.au]
Sent: Thu 7/8/2010 11:08 PM
To: David Miller
Cc: Choi, David; netdev@vger.kernel.org; Li, Charles
Subject: Re: [PATCH linux-2.6.35-rc3] ks8842 driver
On Thu, Jul 08, 2010 at 09:41:01PM -0700, David Miller wrote:
> From: "Choi, David" <David.Choi@Micrel.Com>
> Date: Thu, 8 Jul 2010 12:01:51 -0700
>
> > The original ks8842 driver is designed to work on the customized bus
> > interface based on an FPGA. This patch is intended to address the more
> > commonly used generic bus interface available on the majority of SoC in
> > the market.
> >
> > It is unlikely that for a system to use both FPGA based and generic bus
> > interface for ks8842, I am quite certain that those 2 devices are used
> > mutual exclusively.
>
> Like Simon, I'm not to thrilled with this approach.
>
> Any flag bit test you'd need to add to the driver to handle both cases
> will have zero performance impact since the cost of the MMIO accesses
> will dominate such tests entirely.
>
> Add a boolean flag bit to the driver software state, set it based upon
> some platform_device private setting, and test it in these paths to
> device what to do.
>
> As a bonus, anyone who enables this driver at all in their build will
> test the compilation of both code paths. And to me, that extra
> compilation testing trumps whatever arguments you may make for not
> making this support dynamic.
I was thinking more in terms of needing fewer kernels,
but yes build coverage is a big win.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] net: Get rid of rtnl_link_stats64 / net_device_stats union
From: Eric Dumazet @ 2010-07-09 21:08 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1278702713.2078.13.camel@achroite.uk.solarflarecom.com>
Le vendredi 09 juillet 2010 à 20:11 +0100, Ben Hutchings a écrit :
> In commit be1f3c2c027cc5ad735df6a45a542ed1db7ec48b "net: Enable 64-bit
> net device statistics on 32-bit architectures" I redefined struct
> net_device_stats so that it could be used in a union with struct
> rtnl_link_stats64, avoiding the need for explicit copying or
> conversion between the two. However, this is unsafe because there is
> no locking required and no lock consistently held around calls to
> dev_get_stats() and use of the statistics structure it returns.
>
> In commit 28172739f0a276eb8d6ca917b3974c2edb036da3 "net: fix 64 bit
> counters on 32 bit arches" Eric Dumazet dealt with that problem by
> requiring callers of dev_get_stats() to provide storage for the
> result. This means that the net_device::stats64 field and the padding
> in struct net_device_stats are now redundant, so remove them.
>
> Update the comment on net_device_ops::ndo_get_stats64 to reflect its
> new usage.
>
> Change dev_txq_stats_fold() to use struct rtnl_link_stats64, since
> that is what all its callers are really using and it is no longer
> going to be compatible with struct net_device_stats.
>
> Eric Dumazet suggested the separate function for the structure
> conversion.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks !
^ permalink raw reply
* Re: [PATCH v2 -net-2.6] ll_temac: fix DMA resources leak
From: Denis Kirjanov @ 2010-07-09 20:09 UTC (permalink / raw)
To: Kulikov Vasiliy
Cc: Denis Kirjanov, davem, john.linn, brian.hill, grant.likely,
jpirko, netdev
In-Reply-To: <20100709175952.GA5450@albatros>
On 07/09/2010 09:59 PM, Kulikov Vasiliy wrote:
> On Fri, Jul 09, 2010 at 15:43 +0400, Kulikov Vasiliy wrote:
>> On Thu, Jul 08, 2010 at 20:24 +0000, Denis Kirjanov wrote:
>>> V2: Check pointers before releasing resources.
>>>
>>> Fix DMA resources leak.
>>> Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
>>> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
>>> ---
>>> 1 files changed, 32 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
>>> index fa303c8..b57d0ff 100644
>>> --- a/drivers/net/ll_temac_main.c
>>> +++ b/drivers/net/ll_temac_main.c
>>> @@ -193,6 +193,35 @@ static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
>>> #endif
>>>
>>> /**
>>> + * * temac_dma_bd_release - Release buffer descriptor rings
>>> + */
>>> +static void temac_dma_bd_release(struct net_device *ndev)
>>> +{
>>> + struct temac_local *lp = netdev_priv(ndev);
>>> + int i;
>>> +
>>> + for (i = 0; i < RX_BD_NUM; i++) {
>>> + if (!lp->rx_skb[i])
>>> + break;
>>> + else {
>>> + dma_unmap_single(ndev->dev.parent, lp->rx_bd_v[i].phys,
>>> + XTE_MAX_JUMBO_FRAME_SIZE, DMA_FROM_DEVICE);
>>> + dev_kfree_skb(lp->rx_skb[i]);
>>> + }
>>> + }
>> This cycle is needed only if (lp->rx_skb != NULL).
>>
>>> + if (lp->rx_bd_v)
>>> + dma_free_coherent(ndev->dev.parent,
>>> + sizeof(*lp->rx_bd_v) * RX_BD_NUM,
>>> + lp->rx_bd_v, lp->rx_bd_p);
>>> + if (lp->tx_bd_v)
>>> + dma_free_coherent(ndev->dev.parent,
>>> + sizeof(*lp->tx_bd_v) * TX_BD_NUM,
>>> + lp->tx_bd_v, lp->tx_bd_p);
>> After temac_dma_bd_release() lp->rx_bd_v and lp->rx_bd_p are freed but
>> are nonzero. If lp->rx_skb allocation fails second time then these DMA's
>> would be freed second time.
>> lp->tx_bd_v = lp->rx_bd_v = NULL here fixes this.
>>
>>> + if (lp->rx_skb)
>>> + kfree(lp->rx_skb);
>>> +}
>>> +
>>> +/**
>>> * temac_dma_bd_init - Setup buffer descriptor rings
>>> */
>>> static int temac_dma_bd_init(struct net_device *ndev)
>>> @@ -275,6 +304,7 @@ static int temac_dma_bd_init(struct net_device *ndev)
>>> return 0;
>>>
>>> out:
>>> + temac_dma_bd_release(ndev);
>>> return -ENOMEM;
>>> }
>>>
>>> @@ -858,6 +888,8 @@ static int temac_stop(struct net_device *ndev)
>>> phy_disconnect(lp->phy_dev);
>>> lp->phy_dev = NULL;
>>>
>>> + temac_dma_bd_release(ndev);
>>> +
>>> return 0;
>>> }
>>>
> I've fixed it in PATCH v3.
Could you please fix this on the top on the previous one.
Thanks.
>
> http://marc.info/?l=kernel-janitors&m=127869815002994&w=2
>
^ permalink raw reply
* [PATCH net-next-2.6 2/2] net: Document that dev_get_stats() returns the given pointer
From: Ben Hutchings @ 2010-07-09 19:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Eric Dumazet
In-Reply-To: <1278702713.2078.13.camel@achroite.uk.solarflarecom.com>
Document that dev_get_stats() returns the same stats pointer it was
given. Remove const qualification from the returned pointer since the
caller may do what it likes with that structure.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/netdevice.h | 4 ++--
net/core/dev.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 17e95e3..c4fedf0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2130,8 +2130,8 @@ extern void netdev_features_change(struct net_device *dev);
/* Load a device via the kmod */
extern void dev_load(struct net *net, const char *name);
extern void dev_mcast_init(void);
-extern const struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
- struct rtnl_link_stats64 *storage);
+extern struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
+ struct rtnl_link_stats64 *storage);
extern void dev_txq_stats_fold(const struct net_device *dev,
struct rtnl_link_stats64 *stats);
diff --git a/net/core/dev.c b/net/core/dev.c
index 79ee26e..e2b9fa2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5323,13 +5323,13 @@ static void netdev_stats_to_stats64(struct rtnl_link_stats64 *stats64,
* @dev: device to get statistics from
* @storage: place to store stats
*
- * Get network statistics from device. The device driver may provide
- * its own method by setting dev->netdev_ops->get_stats64 or
- * dev->netdev_ops->get_stats; otherwise the internal statistics
- * structure is used.
+ * Get network statistics from device. Return @storage.
+ * The device driver may provide its own method by setting
+ * dev->netdev_ops->get_stats64 or dev->netdev_ops->get_stats;
+ * otherwise the internal statistics structure is used.
*/
-const struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
- struct rtnl_link_stats64 *storage)
+struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
+ struct rtnl_link_stats64 *storage)
{
const struct net_device_ops *ops = dev->netdev_ops;
--
1.6.2.5
--
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 related
* [PATCH net-next-2.6 1/2] net: Get rid of rtnl_link_stats64 / net_device_stats union
From: Ben Hutchings @ 2010-07-09 19:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Eric Dumazet
In commit be1f3c2c027cc5ad735df6a45a542ed1db7ec48b "net: Enable 64-bit
net device statistics on 32-bit architectures" I redefined struct
net_device_stats so that it could be used in a union with struct
rtnl_link_stats64, avoiding the need for explicit copying or
conversion between the two. However, this is unsafe because there is
no locking required and no lock consistently held around calls to
dev_get_stats() and use of the statistics structure it returns.
In commit 28172739f0a276eb8d6ca917b3974c2edb036da3 "net: fix 64 bit
counters on 32 bit arches" Eric Dumazet dealt with that problem by
requiring callers of dev_get_stats() to provide storage for the
result. This means that the net_device::stats64 field and the padding
in struct net_device_stats are now redundant, so remove them.
Update the comment on net_device_ops::ndo_get_stats64 to reflect its
new usage.
Change dev_txq_stats_fold() to use struct rtnl_link_stats64, since
that is what all its callers are really using and it is no longer
going to be compatible with struct net_device_stats.
Eric Dumazet suggested the separate function for the structure
conversion.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/macvlan.c | 2 +-
include/linux/netdevice.h | 70 ++++++++++++++++++---------------------------
net/8021q/vlan_dev.c | 2 +-
net/core/dev.c | 31 ++++++++++++++++---
4 files changed, 56 insertions(+), 49 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 6112f14..1b28aae 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -436,7 +436,7 @@ static struct rtnl_link_stats64 *macvlan_dev_get_stats64(struct net_device *dev,
{
struct macvlan_dev *vlan = netdev_priv(dev);
- dev_txq_stats_fold(dev, (struct net_device_stats *)stats);
+ dev_txq_stats_fold(dev, stats);
if (vlan->rx_stats) {
struct macvlan_rx_stats *p, accum = {0};
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8018f6b..17e95e3 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -162,42 +162,32 @@ static inline bool dev_xmit_complete(int rc)
/*
* Old network device statistics. Fields are native words
* (unsigned long) so they can be read and written atomically.
- * Each field is padded to 64 bits for compatibility with
- * rtnl_link_stats64.
*/
-#if BITS_PER_LONG == 64
-#define NET_DEVICE_STATS_DEFINE(name) unsigned long name
-#elif defined(__LITTLE_ENDIAN)
-#define NET_DEVICE_STATS_DEFINE(name) unsigned long name, pad_ ## name
-#else
-#define NET_DEVICE_STATS_DEFINE(name) unsigned long pad_ ## name, name
-#endif
-
struct net_device_stats {
- NET_DEVICE_STATS_DEFINE(rx_packets);
- NET_DEVICE_STATS_DEFINE(tx_packets);
- NET_DEVICE_STATS_DEFINE(rx_bytes);
- NET_DEVICE_STATS_DEFINE(tx_bytes);
- NET_DEVICE_STATS_DEFINE(rx_errors);
- NET_DEVICE_STATS_DEFINE(tx_errors);
- NET_DEVICE_STATS_DEFINE(rx_dropped);
- NET_DEVICE_STATS_DEFINE(tx_dropped);
- NET_DEVICE_STATS_DEFINE(multicast);
- NET_DEVICE_STATS_DEFINE(collisions);
- NET_DEVICE_STATS_DEFINE(rx_length_errors);
- NET_DEVICE_STATS_DEFINE(rx_over_errors);
- NET_DEVICE_STATS_DEFINE(rx_crc_errors);
- NET_DEVICE_STATS_DEFINE(rx_frame_errors);
- NET_DEVICE_STATS_DEFINE(rx_fifo_errors);
- NET_DEVICE_STATS_DEFINE(rx_missed_errors);
- NET_DEVICE_STATS_DEFINE(tx_aborted_errors);
- NET_DEVICE_STATS_DEFINE(tx_carrier_errors);
- NET_DEVICE_STATS_DEFINE(tx_fifo_errors);
- NET_DEVICE_STATS_DEFINE(tx_heartbeat_errors);
- NET_DEVICE_STATS_DEFINE(tx_window_errors);
- NET_DEVICE_STATS_DEFINE(rx_compressed);
- NET_DEVICE_STATS_DEFINE(tx_compressed);
+ unsigned long rx_packets;
+ unsigned long tx_packets;
+ unsigned long rx_bytes;
+ unsigned long tx_bytes;
+ unsigned long rx_errors;
+ unsigned long tx_errors;
+ unsigned long rx_dropped;
+ unsigned long tx_dropped;
+ unsigned long multicast;
+ unsigned long collisions;
+ unsigned long rx_length_errors;
+ unsigned long rx_over_errors;
+ unsigned long rx_crc_errors;
+ unsigned long rx_frame_errors;
+ unsigned long rx_fifo_errors;
+ unsigned long rx_missed_errors;
+ unsigned long tx_aborted_errors;
+ unsigned long tx_carrier_errors;
+ unsigned long tx_fifo_errors;
+ unsigned long tx_heartbeat_errors;
+ unsigned long tx_window_errors;
+ unsigned long rx_compressed;
+ unsigned long tx_compressed;
};
#endif /* __KERNEL__ */
@@ -666,14 +656,13 @@ struct netdev_rx_queue {
* Callback uses when the transmitter has not made any progress
* for dev->watchdog ticks.
*
- * struct rtnl_link_stats64* (*ndo_get_stats64)(struct net_device *dev
+ * struct rtnl_link_stats64* (*ndo_get_stats64)(struct net_device *dev,
* struct rtnl_link_stats64 *storage);
* struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
* Called when a user wants to get the network device usage
* statistics. Drivers must do one of the following:
- * 1. Define @ndo_get_stats64 to update a rtnl_link_stats64 structure
- * (which should normally be dev->stats64) and return a ponter to
- * it. The structure must not be changed asynchronously.
+ * 1. Define @ndo_get_stats64 to fill in a zero-initialised
+ * rtnl_link_stats64 structure passed by the caller.
* 2. Define @ndo_get_stats to update a net_device_stats structure
* (which should normally be dev->stats) and return a pointer to
* it. The structure may be changed asynchronously only if each
@@ -888,10 +877,7 @@ struct net_device {
int ifindex;
int iflink;
- union {
- struct rtnl_link_stats64 stats64;
- struct net_device_stats stats;
- };
+ struct net_device_stats stats;
#ifdef CONFIG_WIRELESS_EXT
/* List of functions to handle Wireless Extensions (instead of ioctl).
@@ -2147,7 +2133,7 @@ extern void dev_mcast_init(void);
extern const struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
struct rtnl_link_stats64 *storage);
extern void dev_txq_stats_fold(const struct net_device *dev,
- struct net_device_stats *stats);
+ struct rtnl_link_stats64 *stats);
extern int netdev_max_backlog;
extern int netdev_tstamp_prequeue;
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index a1b8171..7cb285f 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -805,7 +805,7 @@ static u32 vlan_ethtool_get_flags(struct net_device *dev)
static struct rtnl_link_stats64 *vlan_dev_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)
{
- dev_txq_stats_fold(dev, (struct net_device_stats *)stats);
+ dev_txq_stats_fold(dev, stats);
if (vlan_dev_info(dev)->vlan_rx_stats) {
struct vlan_rx_stats *p, accum = {0};
diff --git a/net/core/dev.c b/net/core/dev.c
index eb4201c..79ee26e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5274,10 +5274,10 @@ void netdev_run_todo(void)
/**
* dev_txq_stats_fold - fold tx_queues stats
* @dev: device to get statistics from
- * @stats: struct net_device_stats to hold results
+ * @stats: struct rtnl_link_stats64 to hold results
*/
void dev_txq_stats_fold(const struct net_device *dev,
- struct net_device_stats *stats)
+ struct rtnl_link_stats64 *stats)
{
unsigned long tx_bytes = 0, tx_packets = 0, tx_dropped = 0;
unsigned int i;
@@ -5297,6 +5297,27 @@ void dev_txq_stats_fold(const struct net_device *dev,
}
EXPORT_SYMBOL(dev_txq_stats_fold);
+/* Convert net_device_stats to rtnl_link_stats64. They have the same
+ * fields in the same order, with only the type differing.
+ */
+static void netdev_stats_to_stats64(struct rtnl_link_stats64 *stats64,
+ const struct net_device_stats *netdev_stats)
+{
+#if BITS_PER_LONG == 64
+ BUILD_BUG_ON(sizeof(*stats64) != sizeof(*netdev_stats));
+ memcpy(stats64, netdev_stats, sizeof(*stats64));
+#else
+ size_t i, n = sizeof(*stats64) / sizeof(u64);
+ const unsigned long *src = (const unsigned long *)netdev_stats;
+ u64 *dst = (u64 *)stats64;
+
+ BUILD_BUG_ON(sizeof(*netdev_stats) / sizeof(unsigned long) !=
+ sizeof(*stats64) / sizeof(u64));
+ for (i = 0; i < n; i++)
+ dst[i] = src[i];
+#endif
+}
+
/**
* dev_get_stats - get network device statistics
* @dev: device to get statistics from
@@ -5317,11 +5338,11 @@ const struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
return ops->ndo_get_stats64(dev, storage);
}
if (ops->ndo_get_stats) {
- memcpy(storage, ops->ndo_get_stats(dev), sizeof(*storage));
+ netdev_stats_to_stats64(storage, ops->ndo_get_stats(dev));
return storage;
}
- memcpy(storage, &dev->stats, sizeof(*storage));
- dev_txq_stats_fold(dev, (struct net_device_stats *)storage);
+ netdev_stats_to_stats64(storage, &dev->stats);
+ dev_txq_stats_fold(dev, storage);
return storage;
}
EXPORT_SYMBOL(dev_get_stats);
--
1.6.2.5
--
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 related
* Re: [PATCH] at1700: fix double free_irq
From: Dan Carpenter @ 2010-07-09 18:56 UTC (permalink / raw)
To: Kulikov Vasiliy
Cc: kernel-janitors, David S. Miller, Jiri Pirko, Joe Perches,
Stephen Hemminger, Eric Dumazet, netdev
In-Reply-To: <20100709174809.GA5228@albatros>
On Fri, Jul 09, 2010 at 09:48:09PM +0400, Kulikov Vasiliy wrote:
> > > /* Disable the IRQ on boards of fmv18x where it is feasible. */
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > It seems like this comment should be updated?
>
> Maybe yes, but I don't know what these damn IO requests mean.
> Sure, it's better to request IRQ in xxx_open(), but as it is already
> done in probe() I leave it here.
>
> If it is a bug then I do nothing with it, but if it is not then I'll
> create a bug.
>
Yeah. I see what you mean. You are probably right. It should be easy
to test if anyone had the hardware. But this driver is 17 years old so
I doubt anyone does. :P
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Alan Ott @ 2010-07-09 18:24 UTC (permalink / raw)
To: Marcel Holtmann
Cc: David S Miller, Jiri Kosina, Michael Poole, Bastien Nocera,
Eric Dumazet, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1278696815.10421.137.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 07/09/2010 01:33 PM, Marcel Holtmann wrote:
>>>>>>> I looked at this and I am bit worried that this should not be done in
>>>>>>> this detail in the HIDP driver. Essentially HIDP is a pure transport
>>>>>>> driver. It should not handle all these details. Can we make this a bit
>>>>>>> easier for the transport drivers to support such features?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I put these changes (most notably the addition of hidp_get_raw_report())
>>>>>> in hidp because that's where the parallel function
>>>>>> hidp_output_raw_report() was already located. I figured the input should
>>>>>> go with the output. That said, if there's a better place for both of
>>>>>> them (input and output) to go, let me know where you think it should be,
>>>>>> and I'll get them moved into the proper spot.
>>>>>>
>>>>>> I'm not sure what you mean about HIDP being a pure transport driver.
>>>>>>
>>>>>>
>>>>>>
>>>>> what is usb-hid.ko doing here? I would expect a bunch of code
>>>>> duplication with minor difference between USB and Bluetooth.
>>>>>
>>>>>
>>>> usbhid doesn't have a lot of code for hidraw. Two functions are involved:
>>>> usbhid_output_raw_report()
>>>> - calls usb_control_msg() with Get_Report
>>>> usbhid_get_raw_report()
>>>> - calls usb_control_msg() with Set_Report
>>>> OR
>>>> - calls usb_interrupt_msg() on the Ouput pipe.
>>>>
>>>> This is of course easier than bluetooth because usb_control_msg() is
>>>> synchronous, even when requesting reports, mostly because of the nature
>>>> of USB, where the request and response are part of the same transfer.
>>>>
>>>> For Bluetooth, it's a bit more complicated since the kernel treats it
>>>> more like a networking interface (and indeed it is). My understanding is
>>>> that to make a synchronous transfer in bluetooth, one must:
>>>> - send the request packet
>>>> - block (wait_event_*())
>>>> - when the response is received in the input handler, wake_up_*().
>>>>
>>>> There's not really any code duplication, mostly because initiating
>>>> synchronous USB transfers (input and output) is easy (because of the
>>>> usb_*_msg() functions), while making synchronous Bluetooth transfers
>>>> must be done manually. If there's a nice, convenient, synchronous
>>>> function in Bluetooth similar to usb_control_msg() that I've missed,
>>>> then let me know, as it would simplify this whole thing.
>>>>
>>>>
>>> there is not and I don't think we ever get one. My question here was
>>> more in the direction why HID core is doing these synchronously in the
>>> first place. Especially since USB can do everything async as well.
>>>
>> I'm open to suggestions. The way I see it is from a user space
>> perspective. With Get_Feature being on an ioctl(), I don't see any clean
>> way to do it other than synchronously. Other operating systems (I can
>> say for sure Windows, Mac OS X, and FreeBSD) handle Get/Set Feature the
>> same way (synchronously) from user space.
>>
>> You seem to be proposing an asynchronous interface. What would that look
>> like from user space?
>>
> not necessarily from user space, but at least from HID core to HIDP and
> usb-hid transports. At least that is what I would expect, Jiri?
>
> Regards
>
> Marcel
>
Hi Marcel,
So it sounds like you're mostly concerned about the sleeping (blocking),
and where is the _right_ place for it to occur. It seems like it could
either occur in hid/hidraw.c or in hidp/core.c. If it were to occur in
hid/hidraw.c, what then would get passed back and forth between the
bluetooth/hidp and hidraw?
Maybe something like the following:
hidraw:
- get_report() (hypothetical)
- calls a hypothetical hidp_initiate_get_report(), which:
- sends the report request and returns immediately.
- wait for response
hidp:
- whenever a report is returned, it calls back to hidraw,
which wakes up the get_report() thread if
the data matches the report being waited on.
For this to work, we'd need 2 more function pointers in struct hid_device:
1. a way for hidp to call back into hidraw.
2. a pointer for hidp_initiate_get_report().
These of course would be in addition to the ones that USB already uses
(like hid_get_raw_report()), and would cause USB and Bluetooth to use
different APIs to each transport.
Of course, there could be commonality if we used the asynchronous USB
APIs like you suggested, although, I'm not sure I see the benefit of
making the USB part more complicated. The USB part (hid/usb/hid-core.c)
is currently _very_ simple.
It seems like we have two options:
1. Move to asynchronous APIs in USB and Bluetooth. This involves:
a. Move to asynchronous APIs in hid/usbhid/hid-core.c
b. Adding support into hid/hidraw.c to do the waiting.
c. Changing bluetooth/hidp to be asynchronous in nature.
2. Keep using synchronous USB APIs.
a. hid/usbhid/hid-core remains really simple
b. hid/hidraw.c remains really simple
c. bluetooth/hidp has some complexity
I'd argue that the complexity of bluetooth/hidp isn't really that
complex, and further, it's mostly isolated to one (new) function (that's
where the wait_event_*() is).
Further, if we did option #2, some piece of code has to determine
whether to wake up the blocking thread (which would then be in
hid/hidraw.c). This piece of code would be notified for every packet
received from Bluetooth to decide whether it should wake up the sleeping
thread, and would have to have bluetooth-specific code in it (something
like the block which calls wake_up_interruptible() in my patch). It
seems like this code would _have_ to be in hidp.
From a design standpoint, I can't see how it makes sense to push this
code into hid/hidraw.c when it is bluetooth-specific. Further, I can't
see how it makes sense to do the USB portion the hard way, when the
current implementation is so compact and non-error-prone.
Clients to hidraw provide two functions with very simple interfaces, one
for outputting reports, and one for getting (requesting and receiving)
reports. I think having clean interfaces between modules has a lot of value.
All that said, I'm always open to better ideas. Maybe you have a better
design idea that you can enlighten me with.
Alan.
^ permalink raw reply
* Re: [PATCH] tproxy: nf_tproxy_assign_sock() can handle tw sockets
From: Felipe W Damasio @ 2010-07-09 18:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, linux-kernel, netdev
In-Reply-To: <1278695580.2696.55.camel@edumazet-laptop>
Hi,
2010/7/9 Eric Dumazet <eric.dumazet@gmail.com>:
> Reviewing tproxy stuff I spotted a problem in nf_tproxy_assign_sock()
> but I could not see how it could explain your crash.
>
> We can read uninitialized memory and trigger a fault in
> nf_tproxy_assign_sock(), not later in tcp_recvmsg()...
Well, since I can't reproduce the bug, if you think this patch solves
my problem, I'll tell my bosses that we can put back the production
machine online.
But anyway, if there's test you think I can run, I have same the same
hardware on a lab using the same setup as the production
environment...
Thanks,
Felipe Damasio
^ permalink raw reply
* Re: [PATCH v2 -net-2.6] ll_temac: fix DMA resources leak
From: Kulikov Vasiliy @ 2010-07-09 17:59 UTC (permalink / raw)
To: Denis Kirjanov; +Cc: davem, john.linn, brian.hill, grant.likely, jpirko, netdev
In-Reply-To: <20100709114347.GA3553@albatros>
On Fri, Jul 09, 2010 at 15:43 +0400, Kulikov Vasiliy wrote:
> On Thu, Jul 08, 2010 at 20:24 +0000, Denis Kirjanov wrote:
> > V2: Check pointers before releasing resources.
> >
> > Fix DMA resources leak.
> > Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
> > Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
> > ---
> > 1 files changed, 32 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
> > index fa303c8..b57d0ff 100644
> > --- a/drivers/net/ll_temac_main.c
> > +++ b/drivers/net/ll_temac_main.c
> > @@ -193,6 +193,35 @@ static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
> > #endif
> >
> > /**
> > + * * temac_dma_bd_release - Release buffer descriptor rings
> > + */
> > +static void temac_dma_bd_release(struct net_device *ndev)
> > +{
> > + struct temac_local *lp = netdev_priv(ndev);
> > + int i;
> > +
> > + for (i = 0; i < RX_BD_NUM; i++) {
> > + if (!lp->rx_skb[i])
> > + break;
> > + else {
> > + dma_unmap_single(ndev->dev.parent, lp->rx_bd_v[i].phys,
> > + XTE_MAX_JUMBO_FRAME_SIZE, DMA_FROM_DEVICE);
> > + dev_kfree_skb(lp->rx_skb[i]);
> > + }
> > + }
> This cycle is needed only if (lp->rx_skb != NULL).
>
> > + if (lp->rx_bd_v)
> > + dma_free_coherent(ndev->dev.parent,
> > + sizeof(*lp->rx_bd_v) * RX_BD_NUM,
> > + lp->rx_bd_v, lp->rx_bd_p);
> > + if (lp->tx_bd_v)
> > + dma_free_coherent(ndev->dev.parent,
> > + sizeof(*lp->tx_bd_v) * TX_BD_NUM,
> > + lp->tx_bd_v, lp->tx_bd_p);
> After temac_dma_bd_release() lp->rx_bd_v and lp->rx_bd_p are freed but
> are nonzero. If lp->rx_skb allocation fails second time then these DMA's
> would be freed second time.
> lp->tx_bd_v = lp->rx_bd_v = NULL here fixes this.
>
> > + if (lp->rx_skb)
> > + kfree(lp->rx_skb);
> > +}
> > +
> > +/**
> > * temac_dma_bd_init - Setup buffer descriptor rings
> > */
> > static int temac_dma_bd_init(struct net_device *ndev)
> > @@ -275,6 +304,7 @@ static int temac_dma_bd_init(struct net_device *ndev)
> > return 0;
> >
> > out:
> > + temac_dma_bd_release(ndev);
> > return -ENOMEM;
> > }
> >
> > @@ -858,6 +888,8 @@ static int temac_stop(struct net_device *ndev)
> > phy_disconnect(lp->phy_dev);
> > lp->phy_dev = NULL;
> >
> > + temac_dma_bd_release(ndev);
> > +
> > return 0;
> > }
> >
I've fixed it in PATCH v3.
http://marc.info/?l=kernel-janitors&m=127869815002994&w=2
^ permalink raw reply
* Urgent Response Required.(OSA AWARD)
From: Mrs. Maria Ortega @ 2010-07-09 17:47 UTC (permalink / raw)
Euro Millones s.l
Oversea Subscriber Agent
Madrid, Spain.
Ref : EML/2010/799
Bat : 4/001/2301ESP
You have won the Oversea Subscriber Agency(OSA) Bonanza Award of 2nd July 2010 of the Euro Millones Int. Your winning email attached to ticket 12-13-36-41-46, 5-8. won in the 2nd category. You are therefore approved to receive the sum of 1.417.999,54 Euro.
Check result here: http://www.onlae.es/euroMillones/comprobar.aspx
Contact your claims officer:
Mr. Frank Dumbell
Tel: 0034-672-528-600
Email: osaclearance@aol.co.uk
Congratulations on your success.
Regards,
Mrs. Maria Ortega
Coordinator
^ permalink raw reply
* [PATCH v3] ll_temac: fix DMA and memory leaks
From: Kulikov Vasiliy @ 2010-07-09 17:55 UTC (permalink / raw)
To: kernel-janitors
Cc: Denis Kirjanov, David S. Miller, John Linn, Grant Likely,
Jiri Pirko, netdev, devicetree-discuss
temac_dma_bd_init() doesn't free DMA and memory on error. Also
temac_stop() must free them.
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/ll_temac_main.c | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 5bca20b..9090e79 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -193,6 +193,41 @@ static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
#endif
/**
+ * * temac_dma_bd_release - Release buffer descriptor rings
+ */
+static void temac_dma_bd_release(struct net_device *ndev)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ int i;
+
+ if (lp->rx_skb) {
+ for (i = 0; i < RX_BD_NUM; i++) {
+ if (!lp->rx_skb[i])
+ break;
+ dma_unmap_single(ndev->dev.parent, lp->rx_bd_v[i].phys,
+ XTE_MAX_JUMBO_FRAME_SIZE, DMA_FROM_DEVICE);
+ dev_kfree_skb(lp->rx_skb[i]);
+ }
+ kfree(lp->rx_skb);
+ lp->rx_skb = NULL;
+ }
+
+ if (lp->rx_bd_v) {
+ dma_free_coherent(ndev->dev.parent,
+ sizeof(*lp->rx_bd_v) * RX_BD_NUM,
+ lp->rx_bd_v, lp->rx_bd_p);
+ lp->rx_bd_v = NULL;
+ }
+
+ if (lp->tx_bd_v) {
+ dma_free_coherent(ndev->dev.parent,
+ sizeof(*lp->tx_bd_v) * TX_BD_NUM,
+ lp->tx_bd_v, lp->tx_bd_p);
+ lp->tx_bd_v = NULL;
+ }
+}
+
+/**
* temac_dma_bd_init - Setup buffer descriptor rings
*/
static int temac_dma_bd_init(struct net_device *ndev)
@@ -275,6 +310,7 @@ static int temac_dma_bd_init(struct net_device *ndev)
return 0;
out:
+ temac_dma_bd_release(ndev);
return -ENOMEM;
}
@@ -858,6 +894,8 @@ static int temac_stop(struct net_device *ndev)
phy_disconnect(lp->phy_dev);
lp->phy_dev = NULL;
+ temac_dma_bd_release(ndev);
+
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 001/001] QoS and/or fair queueing: Stateless NAT BUG
From: Eric Dumazet @ 2010-07-09 17:54 UTC (permalink / raw)
To: Rodrigo Partearroyo González
Cc: Herbert Xu, Linux Kernel Mailing List, Iratxo Pichel Ortiz,
Noelia Morón, netdev
In-Reply-To: <201007091937.17349.rpartearroyo@albentia.com>
Le vendredi 09 juillet 2010 à 19:37 +0200, Rodrigo Partearroyo González
a écrit :
> Hi all,
> I have been testing Stateless NAT and found that ICMP packets with length
> less than 20 bytes were not correctly NAT'ed. I have found a BUG that
> makes taking into account IP header length twice, so ICMP packets smaller
> than 20 bytes were being dropped.
>
> Proposed formal patch is below, as suggested by Eric Dumazet, thanks.
> It is taken from 2.6.34.1 stable version.
>
> Signed-off-by: Rodrigo Partearroyo González <rpartearroyo@albentia.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> diff -uprN a/net/sched/act_nat.c b/net/sched/act_nat.c
> --- a/net/sched/act_nat.c 2010-07-09 18:25:18.000000000 +0200
> +++ b/net/sched/act_nat.c 2010-07-09 18:26:16.000000000 +0200
> @@ -202,7 +202,7 @@ static int tcf_nat(struct sk_buff *skb,
> {
> struct icmphdr *icmph;
>
> - if (!pskb_may_pull(skb, ihl + sizeof(*icmph) + sizeof(*iph)))
> + if (!pskb_may_pull(skb, ihl + sizeof(*icmph)))
> goto drop;
>
> icmph = (void *)(skb_network_header(skb) + ihl);
> @@ -223,7 +223,7 @@ static int tcf_nat(struct sk_buff *skb,
>
> if (skb_cloned(skb) &&
> !skb_clone_writable(skb,
> - ihl + sizeof(*icmph) + sizeof(*iph)) &&
> + ihl + sizeof(*icmph)) &&
> pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
> goto drop;
>
^ permalink raw reply
* Re: [PATCH] tproxy: nf_tproxy_assign_sock() can handle tw sockets
From: David Miller @ 2010-07-09 17:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: felipewd, kaber, linux-kernel, netdev
In-Reply-To: <1278695580.2696.55.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 09 Jul 2010 19:13:00 +0200
> Reviewing tproxy stuff I spotted a problem in nf_tproxy_assign_sock()
> but I could not see how it could explain your crash.
>
> We can read uninitialized memory and trigger a fault in
> nf_tproxy_assign_sock(), not later in tcp_recvmsg()...
>
> David, Patrick, what do you think ?
>
> Thanks
>
> [PATCH] tproxy: nf_tproxy_assign_sock() can handle tw sockets
>
> transparent field of a socket is either inet_twsk(sk)->tw_transparent
> for timewait sockets, or inet_sk(sk)->transparent for other sockets
> (TCP/UDP).
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks fine to me:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 001/001] QoS and/or fair queueing: Stateless NAT BUG
From: David Miller @ 2010-07-09 17:52 UTC (permalink / raw)
To: rpartearroyo; +Cc: eric.dumazet, herbert, linux-kernel, ipichel, nmoron, netdev
In-Reply-To: <201007091937.17349.rpartearroyo@albentia.com>
From: Rodrigo Partearroyo González <rpartearroyo@albentia.com>
Date: Fri, 9 Jul 2010 19:37:16 +0200
> Hi all,
> I have been testing Stateless NAT and found that ICMP packets with length
> less than 20 bytes were not correctly NAT'ed. I have found a BUG that
> makes taking into account IP header length twice, so ICMP packets smaller
> than 20 bytes were being dropped.
>
> Proposed formal patch is below, as suggested by Eric Dumazet, thanks.
> It is taken from 2.6.34.1 stable version.
>
> Signed-off-by: Rodrigo Partearroyo González <rpartearroyo@albentia.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH]: rfs: record flow in TCP receiving and sending pathes
From: David Miller @ 2010-07-09 17:51 UTC (permalink / raw)
To: xiaosuo; +Cc: therbert, netdev
In-Reply-To: <1278660498-26587-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Fri, 9 Jul 2010 15:28:18 +0800
> rfs: record flow in TCP receiving and sending pathes
>
> call sock_rps_record_flow() in function tcp_splice_read(), tcp_sendpage() and
> tcp_sendmsg().
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
I don't think it's wise to pepper these calls all over the place if it
is not necessary.
The only reason we vector straight to the TCP implementations of these
I/O routines is to avoid the port autobinding made by the inet_*()
functions.
But now that avoids also the RPS calls.
So it makes sense to just add a boolean state bit flag of some sort
to "struct proto" which says to avoid the autobind calls, then
make TCP vector through the inet_*() functions just like the other
inet protocols do.
Then these extra send_rps_record_flow() annotations will not be
necessary.
^ 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