* pull-request: can-next 2012-09-22
From: Marc Kleine-Budde @ 2012-09-21 22:24 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2623 bytes --]
Hello David,
this pull request is intended for net-next (v3.7 cycle), it consist of
5 patches by AnilKumar bringing device tree support, runtime PM, suspend
resume and pinctrl support to the c_can/d_can driver.
Andreas Larsson improves the sja1000 driver (one-shot, listen only).
Randy Dunlap fixes a function name conflict in the peak driver.
Wei Yongjun fixes a return value check in the mscan-mpc5xxx driver.
regards, Marc
--
The following changes since commit abb17e6c0c7b27693201dc85f75dbb184279fd10:
netlink: use <linux/export.h> instead of <linux/module.h> (2012-09-21 15:43:58 -0400)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git for-davem
for you to fetch changes up to cb8db899a6b73334b41fd1a72252533afdf080dc:
can: sja1000: Add support for listen-only mode and one-shot mode (2012-09-21 23:58:49 +0200)
----------------------------------------------------------------
Andreas Larsson (1):
can: sja1000: Add support for listen-only mode and one-shot mode
AnilKumar Ch (5):
can: c_can: Modify c_can device names
can: c_can: Add device tree support to Bosch C_CAN/D_CAN controller
can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
can: c_can: Add d_can suspend resume support
can: c_can: Adopt pinctrl support
Randy Dunlap (1):
can: usb: peak: rename peak_usb dump_mem function
Wei Yongjun (1):
can: mscan-mpc5xxx: fix return value check in mpc512x_can_get_clock()
.../devicetree/bindings/net/can/c_can.txt | 49 ++++++++
drivers/net/can/c_can/c_can.c | 127 +++++++++++++++++++-
drivers/net/can/c_can/c_can.h | 14 ++-
drivers/net/can/c_can/c_can_pci.c | 6 +-
drivers/net/can/c_can/c_can_platform.c | 123 ++++++++++++++++---
drivers/net/can/mscan/mpc5xxx_can.c | 4 +-
drivers/net/can/sja1000/sja1000.c | 31 +++--
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 8 +-
drivers/net/can/usb/peak_usb/pcan_usb_core.h | 2 +-
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 8 +-
10 files changed, 332 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/c_can.txt
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH] net/can: rename peak_usb dump_mem function
From: Marc Kleine-Budde @ 2012-09-21 21:52 UTC (permalink / raw)
To: Randy Dunlap
Cc: netdev, Geert Uytterhoeven, linux-kernel, David Miller,
Stephane Grosjean, Wolfgang Grandegger, linux-can
In-Reply-To: <505CDF3F.6040009@xenotime.net>
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
On 09/21/2012 11:42 PM, Randy Dunlap wrote:
> On 09/02/2012 10:13 AM, Randy Dunlap wrote:
>
>> From: Randy Dunlap <rdunlap@xenotime.net>
>>
>> Rename generic-sounding function dump_mem() to pcan_dump_mem()
>> so that it does not conflict with the dump_mem() function in
>> arch/sh/include/asm/kdebug.h.
>>
>> drivers/net/can/usb/peak_usb/pcan_usb_core.c: error: conflicting types for 'dump_mem': => 56:6
>> drivers/net/can/usb/peak_usb/pcan_usb_core.h: error: conflicting types for 'dump_mem': => 134:6
>>
>> Not tested.
>>
>> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
>> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> Cc: Stephane Grosjean <s.grosjean@peak-system.com>
>> Cc: Wolfgang Grandegger <wg@grandegger.com>
>> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
>
>
> ping.
The patch is already part of can-next and will be included in the next
pull request to David.
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Benjamin Herrenschmidt @ 2012-09-21 21:46 UTC (permalink / raw)
To: David Miller
Cc: sfr, paulus, linuxppc-dev, mika.westerberg, netdev, linux-next,
linux-kernel
In-Reply-To: <20120920.185315.576326460331670020.davem@davemloft.net>
On Thu, 2012-09-20 at 18:53 -0400, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Fri, 21 Sep 2012 08:22:44 +1000
>
> > Hrm, that's ancient gunk, I'll have to dig. We potentially can support
> > ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
> > isa_virt_to_bus is a non-starter.
> >
> > But then, do we really care ? IE. Is there single device that actually
> > requires ISA_DMA_API and that is expected to work on any currently
> > supported powerpc hw ? :-)
> >
> > We don't even support PReP anymore, so that leaves us with what ?
>
> ISA_DMA_API implies a fixed window of addresses which are <= 32-bits
> on the bus, which is a hardware requirement of these devices.
>
> isa_virt_to_bus() goes to that physical address, and the expection is
> that you use GFP_DMA and thus the physical addresses fit inside of
> an unsigned int.
Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all
of memory is ZONE_DMA). It's always been like that afaik.
We could support ISA device limited addressability using the iommu but
that would involve a map/unmap type API (which I remember we did support
in the old days by passing NULL to pci_map_*, but we dropped that along
the way).
> isa_virt_to_bus() basically amounts to a virt-->phys plus a cast.
>
> > Anybody has an objection to turning ISA_DMA_API off ?
>
> Then you can remove all of the DMA api stuff in powerpc's asm/dma.h
> but some of it looks like it might be in use.
I will dig a bit. I think there might be some users of the ISA DMA
engine for legacy floppies and parport on some early pSeries and CHRP
machines (including Pegasos).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] net/can: rename peak_usb dump_mem function
From: Randy Dunlap @ 2012-09-21 21:42 UTC (permalink / raw)
To: Randy Dunlap
Cc: netdev, Geert Uytterhoeven, linux-kernel, David Miller,
Stephane Grosjean, Wolfgang Grandegger, Marc Kleine-Budde,
linux-can
In-Reply-To: <504393A7.8040007@xenotime.net>
On 09/02/2012 10:13 AM, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Rename generic-sounding function dump_mem() to pcan_dump_mem()
> so that it does not conflict with the dump_mem() function in
> arch/sh/include/asm/kdebug.h.
>
> drivers/net/can/usb/peak_usb/pcan_usb_core.c: error: conflicting types for 'dump_mem': => 56:6
> drivers/net/can/usb/peak_usb/pcan_usb_core.h: error: conflicting types for 'dump_mem': => 134:6
>
> Not tested.
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Stephane Grosjean <s.grosjean@peak-system.com>
> Cc: Wolfgang Grandegger <wg@grandegger.com>
> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
ping.
> ---
> drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
> drivers/net/can/usb/peak_usb/pcan_usb_core.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- lnx-36-rc4.orig/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ lnx-36-rc4/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -53,7 +53,7 @@ static struct peak_usb_adapter *peak_usb
> * dump memory
> */
> #define DUMP_WIDTH 16
> -void dump_mem(char *prompt, void *p, int l)
> +void pcan_dump_mem(char *prompt, void *p, int l)
> {
> pr_info("%s dumping %s (%d bytes):\n",
> PCAN_USB_DRIVER_NAME, prompt ? prompt : "memory", l);
> --- lnx-36-rc4.orig/drivers/net/can/usb/peak_usb/pcan_usb_core.h
> +++ lnx-36-rc4/drivers/net/can/usb/peak_usb/pcan_usb_core.h
> @@ -131,7 +131,7 @@ struct peak_usb_device {
> struct peak_usb_device *next_siblings;
> };
>
> -void dump_mem(char *prompt, void *p, int l);
> +void pcan_dump_mem(char *prompt, void *p, int l);
>
> /* common timestamp management */
> void peak_usb_init_time_ref(struct peak_time_ref *time_ref,
>
--
~Randy
^ permalink raw reply
* Re: [PATCH] rds: Error on offset mismatch if not loopback
From: Venkat Venkatsubra @ 2012-09-21 21:38 UTC (permalink / raw)
To: John Jolly; +Cc: linux-kernel, netdev
In-Reply-To: <20120921213239.GJ14393@linux-tkdk.sfcn.org>
On 9/21/2012 4:32 PM, John Jolly wrote:
> Attempting an rds connection from the IP address of an IPoIB interface
> to itself causes a kernel panic due to a BUG_ON() being triggered.
> Making the test less strict allows rds-ping to work without crashing
> the machine.
>
> A local unprivileged user could use this flaw to crash the system.
>
> Signed-off-by: John Jolly<jjolly@suse.com>
> ---
> net/rds/ib_send.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
> index e590949..7920c85 100644
> --- a/net/rds/ib_send.c
> +++ b/net/rds/ib_send.c
> @@ -544,7 +544,7 @@ int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
> int flow_controlled = 0;
> int nr_sig = 0;
>
> - BUG_ON(off % RDS_FRAG_SIZE);
> + BUG_ON(!conn->c_loopback&& off % RDS_FRAG_SIZE);
> BUG_ON(hdr_off != 0&& hdr_off != sizeof(struct rds_header));
>
> /* Do not send cong updates to IB loopback */
Hi John,
How do you trigger this BUG_ON ?
With rds-ping I could not hit this condition of non-zero "off %
RDS_FRAG_SIZE".
rds-ping uses zero byte messages to ping or pong back. How does the
"off" become non-zero ?
Thanks.
Venkat
^ permalink raw reply
* [PATCH] rds: Error on offset mismatch if not loopback
From: John Jolly @ 2012-09-21 21:32 UTC (permalink / raw)
To: linux-kernel; +Cc: venkat.x.venkatsubra, netdev
Attempting an rds connection from the IP address of an IPoIB interface
to itself causes a kernel panic due to a BUG_ON() being triggered.
Making the test less strict allows rds-ping to work without crashing
the machine.
A local unprivileged user could use this flaw to crash the system.
Signed-off-by: John Jolly <jjolly@suse.com>
---
net/rds/ib_send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index e590949..7920c85 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -544,7 +544,7 @@ int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
int flow_controlled = 0;
int nr_sig = 0;
- BUG_ON(off % RDS_FRAG_SIZE);
+ BUG_ON(!conn->c_loopback && off % RDS_FRAG_SIZE);
BUG_ON(hdr_off != 0 && hdr_off != sizeof(struct rds_header));
/* Do not send cong updates to IB loopback */
--
1.7.7
^ permalink raw reply related
* Re: [PATCH] rds: Error on offset mismatch if not loopback
From: John Jolly @ 2012-09-21 21:28 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, venkat.x.venkatsubra, netdev
In-Reply-To: <20120921.132045.951559071646755065.davem@davemloft.net>
On Fri, Sep 21, 2012 at 01:20:45PM -0400, David Miller wrote:
> From: John Jolly <jjolly@suse.com>
> Date: Thu, 20 Sep 2012 01:11:34 -0600
>
> > Attempting an rds connection from the IP address of an IPoIB interface
> > to itself causes a kernel panic due to a BUG_ON() being triggered. Making
> > the test less strict allows rds-ping to work without crashing the machine.
> >
> > A local unprivileged user could use this flaw to crash the sytem.
>
> Please read Documentation/SubmittingPatches to learn how to properly
> submit a change, in particular your patch submission was missing a
> proper signoff.
Thanks for catching that. Resubmitting with proper signoff.
>
> Thanks.
> --
> 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] Xen backend support for paged out grant targets V4.
From: Konrad Rzeszutek Wilk @ 2012-09-21 20:45 UTC (permalink / raw)
To: Andres Lagar-Cavilla
Cc: Andres Lagar-Cavilla, Ian Campbell, Andres Lagar-Cavilla,
xen-devel, David Vrabel, David Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
> > So with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> > in the initial domain and the guest is crashed:
> >
> > [ 261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
>
> With this patch? Or with the mmapbatch v2? This is a page fault in a foreign-mapped VMA. Not touched by this grant backend patch we are talking about.
>
> Does the hypervisor dump anything to its console?
>
> At which point during xc_hvm_build do you see this? (or elsewhere in the toolstack?)
My apologies. It was Oliver's persistent grant patch that does not like your patch.
^ permalink raw reply
* Re: [PATCH net-next v1] net: use a per task frag allocator
From: Vijay Subramanian @ 2012-09-21 20:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, linux-kernel, netdev, Ben Hutchings,
Alexander Duyck
In-Reply-To: <1348239433.2669.522.camel@edumazet-glaptop>
I get the following compile error with the newer version of the patch
net/sched/em_meta.c: In function ‘meta_int_sk_sendmsg_off’:
net/sched/em_meta.c:464: error: ‘struct sock’ has no member named
‘sk_sndmsg_off’
make[1]: *** [net/sched/em_meta.o] Error 1
make: *** [net/sched/em_meta.o] Error 2
Vijay
^ permalink raw reply
* Re: New commands to configure IOV features
From: Don Dutile @ 2012-09-21 20:08 UTC (permalink / raw)
To: Yinghai Lu
Cc: Rose, Gregory V, Ben Hutchings, Bjorn Helgaas, Yuval Mintz,
davem@davemloft.net, netdev@vger.kernel.org, Ariel Elior,
Eilon Greenstein, linux-pci
In-Reply-To: <CAE9FiQW4vY3SwAt1TGhSa=bcmKnzxS96b9HGoU5_CDb3FRvGVA@mail.gmail.com>
On 09/21/2012 03:49 PM, Yinghai Lu wrote:
> On Fri, Sep 21, 2012 at 11:06 AM, Don Dutile<ddutile@redhat.com> wrote:
>>>
>>> ok, something like attached patches?
>>>
>>> ixgbe change need more cleanup from ixgbe guys.
>>>
>> yuk, no.
>> I have a set of patches almost done.
>
> good. includes update to those network drivers?
>
>> It provides 3 sysfs files (enable, disable, num_max_vfs);
>> callbacks for enable& disable.
>
> why using three? only pass max_vfs should be enough...
>
> aka pass 0 mean disabling, pass other value mean enabling.
>
could do that. but I wouldn't use 'max_vfs'; I would recommend
'num_vfs', as max implies, er, um, the maximum, and what one
wants is to be able to enable a number from 1->max_vfs.
'max_vfs' will be provided by another file.
>>
>> i'm tied up until Monday on RHEL6, then I'll switch gears& post a set of
>> patches.
>
> so that is your employer 'sinternal policy? for RHEL 6 kernel first,
> then upstream kernel?
No, I have deadlines for RHEL6 for *other work* until Monday. After that,
I can re-focus on upstream work. Some of us actually have other work than
just upstream.... crazy talk, I know! ;-)
> thought RH only accept backporting only patches get into upstream already.
>
yup. 'upstream first' is the rule at RH before it gets into a RHEL release...
and sometimes that isn't sufficient!
Have a beer, enjoy the weekend, posting forthcoming next week!
> -Yinghai
^ permalink raw reply
* Re: [PATCH] Xen backend support for paged out grant targets V4.
From: Konrad Rzeszutek Wilk @ 2012-09-21 20:05 UTC (permalink / raw)
To: Andres Lagar-Cavilla
Cc: Andres Lagar-Cavilla, Ian Campbell, Andres Lagar-Cavilla,
xen-devel, David Vrabel, David Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
On Fri, Sep 21, 2012 at 03:30:01PM -0400, Andres Lagar-Cavilla wrote:
> On Sep 21, 2012, at 2:52 PM, Konrad Rzeszutek Wilk wrote:
>
> > On Mon, Sep 17, 2012 at 05:29:24AM -0400, Andres Lagar-Cavilla wrote:
> >> On Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:
> >>
> >>> (I think I forgot to hit send on this on Friday, sorry. Also
> >>> s/xen.lists.org/lists.xen.org in the CC line…)
> >> I'm on a roll here…
> >>
> >>>
> >>> On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
> >>>> Since Xen-4.2, hvm domains may have portions of their memory paged out. When a
> >>>> foreign domain (such as dom0) attempts to map these frames, the map will
> >>>> initially fail. The hypervisor returns a suitable errno, and kicks an
> >>>> asynchronous page-in operation carried out by a helper. The foreign domain is
> >>>> expected to retry the mapping operation until it eventually succeeds. The
> >>>> foreign domain is not put to sleep because itself could be the one running the
> >>>> pager assist (typical scenario for dom0).
> >>>>
> >>>> This patch adds support for this mechanism for backend drivers using grant
> >>>> mapping and copying operations. Specifically, this covers the blkback and
> >>>> gntdev drivers (which map foregin grants), and the netback driver (which copies
> >>>
> >>> foreign
> >>>
> >>>> foreign grants).
> >>>>
> >>>> * Add a retry method for grants that fail with GNTST_eagain (i.e. because the
> >>>> target foregin frame is paged out).
> >>>
> >>> foreign
> >>>
> >>>> * Insert hooks with appropriate wrappers in the aforementioned drivers.
> >>>>
> >>>> The retry loop is only invoked if the grant operation status is GNTST_eagain.
> >>>> It guarantees to leave a new status code different from GNTST_eagain. Any other
> >>>> status code results in identical code execution as before.
> >>>>
> >>>> The retry loop performs 256 attempts with increasing time intervals through a
> >>>> 32 second period. It uses msleep to yield while waiting for the next retry.
> >>> [...]
> >>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>>
> >>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >>>
> >>> Since this is more about grant tables than netback this should probably
> >>> go via Konrad rather than Dave, is that OK with you Dave?
> >>
> >> If that is the case hopefully Konrad can deal with the two typos? Otherwise happy to re-spin the patch.
> >
> > So with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> > in the initial domain and the guest is crashed:
> >
> > [ 261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
>
> With this patch? Or with the mmapbatch v2? This is a page fault in a foreign-mapped VMA. Not touched by this grant backend patch we are talking about.
This patch. But I also had a modified blkback. So let me double check
that it is not the persistent grants and this patch doing something naughty.
>
> Does the hypervisor dump anything to its console?
>
> At which point during xc_hvm_build do you see this? (or elsewhere in the toolstack?)
No idea. Didn't examine that much.
^ permalink raw reply
* Re: New commands to configure IOV features
From: Yinghai Lu @ 2012-09-21 19:49 UTC (permalink / raw)
To: Don Dutile
Cc: Rose, Gregory V, Ben Hutchings, Bjorn Helgaas, Yuval Mintz,
davem@davemloft.net, netdev@vger.kernel.org, Ariel Elior,
Eilon Greenstein, linux-pci
In-Reply-To: <505CAC93.8020304@redhat.com>
On Fri, Sep 21, 2012 at 11:06 AM, Don Dutile <ddutile@redhat.com> wrote:
>>
>> ok, something like attached patches?
>>
>> ixgbe change need more cleanup from ixgbe guys.
>>
> yuk, no.
> I have a set of patches almost done.
good. includes update to those network drivers?
> It provides 3 sysfs files (enable, disable, num_max_vfs);
> callbacks for enable & disable.
why using three? only pass max_vfs should be enough...
aka pass 0 mean disabling, pass other value mean enabling.
>
> i'm tied up until Monday on RHEL6, then I'll switch gears & post a set of
> patches.
so that is your employer 'sinternal policy? for RHEL 6 kernel first,
then upstream kernel?
thought RH only accept backporting only patches get into upstream already.
-Yinghai
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-09-21 19:48 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
More bug fixes, nothing gets past these guys:
1) More kernel info leaks found by Mathias Krause, this time in the
IPSEC configuration layers.
2) When IPSEC policies change, we do not properly make sure that
cached routes (which could now be stale) throughout the system will
be revalidated. Fix this by generalizing the generation count
invalidation scheme used by ipv4. From Nicolas Dichtel.
3) When repairing TCP sockets, we need to allow to restore not just
the send window scale, but the receive one too. Extend the
existing interface to achieve this in a backwards compatible way.
From Andrey Vagin.
4) A fix for FCOE scatter gather feature validation erroneously
caused scatter gather to be disabled for things like AOE too.
From Ed L. Cashin.
5) Several cases of mishandling of error pointers, from Mathias Krause,
Wei Yongjun, and Devendra Naga.
6) Fix gianfar build, from Richard Cochran.
7) CAP_NET_* failures should return -EPERM not -EACCES, from Zhao
Hongjiang.
8) Hardware reset fix in janz-ican3 CAN driver, from Ira W. Snyder.
9) Fix oops during rmmod in ti_hecc CAN driver, from Marc Kleine-Budde.
10) The removal of the conditional compilation of the clk support code
in the stmmac driver broke things. This is because the interfaces
used are the ones that don't also perform the enable/disable of
the clk. Fix from Stefan Roese.
11) The QFQ packet scheduler can record out of range virtual start
times, resulting later in misbehavior and even crashes. Fix
from Paolo Valente.
12) If MSG_WAITALL is used with IOAT DMA under TCP, we can wedge the
receiver when the advertised receive window goes to zero. Detect
this case and force the processing of the IOAT DMA queue when it
happens to avoid getting stuck. Fix from Michal Kubecek.
13) batman-adv assumes that test_bit() returns only 0 or 1, but this
is not true for x86 (which returns -1 or 0, via the 'sbb'
instruction). Fix from Linus Lussing.
14) Fix small packet corruption in e1000, from Tushar Dave.
15) make_blackhole() in the IPSEC policy code can do one read unlock
too many, fix from Li RongQing.
16) The new tcp_try_coalesce() code introduced a bug in TCP URG handling,
fix from Eric Dumazet.
17) Fix memory leak in __netif_receive_skb() when doing zerocopy and
when hit an OOM condition. From Michael S. Tsirkin.
18) netxen blindly deferences pdev->bus->self, which is not guarenteed
to be non-NULL. Fix from Nikolay Aleksandrov.
19) Fix a performance regression caused by mistakes in ipv6 checksum
validation in the bnx2x driver, fix from Michal Schmidt.
Please pull, thanks a lot!
The following changes since commit 3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes (2012-09-14 18:05:14 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to a630844d898ae8a0b4a3db84af061150682e0d3c:
net/stmmac: Use clk_prepare_enable and clk_disable_unprepare (2012-09-21 14:59:52 -0400)
----------------------------------------------------------------
Andrey Vagin (1):
tcp: restore rcv_wscale in a repair mode (v2)
Arend van Spriel (1):
brcmsmac: fix mismatch in number of custom regulatory rules
Ariel Elior (1):
bnx2x: remove false warning regarding interrupt number
Bjørn Mork (1):
net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200
Colin Ian King (1):
brcm80211: fix missing allocation failure check
David S. Miller (2):
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Merge branch 'fixes-for-3.6' of git://gitorious.org/linux-can/linux-can
Devendra Naga (1):
at91ether: return PTR_ERR if call to clk_get fails
Ed L. Cashin (2):
aoe: assert AoE packets marked as requiring no checksum
net: do not disable sg for packets requiring no checksum
Eric Dumazet (2):
net: rt_cache_flush() cleanup
tcp: fix regression in urgent data handling
Felix Fietkau (1):
ath9k: make PA linearization optional, disabled by default and fix checks
Hante Meuleman (2):
brcmfmac: fix big endian bug in i-scan.
brcmfmac: Fix big endian host configuration data.
Ira W. Snyder (1):
can: janz-ican3: fix support for older hardware revisions
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Larry Finger (1):
rtlwifi: rtl8192ce: Log message that B_CUT device may not work
Li RongQing (2):
xfrm: fix a read lock imbalance in make_blackhole
net/core: fix comment in skb_try_coalesce
Linus Lüssing (1):
batman-adv: make batadv_test_bit() return 0 or 1 only
Marc Kleine-Budde (1):
can: ti_hecc: fix oops during rmmod
Mathias Krause (8):
xfrm_user: return error pointer instead of NULL
xfrm_user: return error pointer instead of NULL #2
xfrm_user: fix info leak in copy_to_user_auth()
xfrm_user: fix info leak in copy_to_user_state()
xfrm_user: fix info leak in copy_to_user_policy()
xfrm_user: fix info leak in copy_to_user_tmpl()
xfrm_user: ensure user supplied esn replay window is valid
xfrm_user: don't copy esn replay window twice for new states
Michael S. Tsirkin (1):
net: fix memory leak on oom with zerocopy
Michal Kubeček (1):
tcp: flush DMA queue before sk_wait_data if rcv_wnd is zero
Michal Schmidt (1):
bnx2x: fix rx checksum validation for IPv6
Nicolas Dichtel (5):
ipv4/route: arg delay is useless in rt_cache_flush()
netns: move net->ipv4.rt_genid to net->rt_genid
xfrm: invalidate dst on policy insertion/deletion
ipv6: use net->rt_genid to check dst validity
ipv6: use DST_* macro to set obselete field
Nikolay Aleksandrov (1):
netxen: check for root bus in netxen_mask_aer_correctable
Paolo Valente (1):
pkt_sched: fix virtual-start-time update in QFQ
Richard Cochran (1):
gianfar: fix phc index build failure
Stefan Roese (1):
net/stmmac: Use clk_prepare_enable and clk_disable_unprepare
Søren holm (1):
asix: Support DLink DUB-E100 H/W Ver C1
Tushar Dave (1):
e1000: Small packets may get corrupted during padding by HW
Wei Yongjun (3):
ipv6: fix return value check in fib6_add()
stmmac: fix return value check in stmmac_open_ext_timer()
net/irda: sh_sir: fix return value check in sh_sir_set_baudrate()
Zhao Hongjiang (1):
net: change return values from -EACCES to -EPERM
drivers/block/aoe/aoecmd.c | 1 +
drivers/net/can/janz-ican3.c | 4 +---
drivers/net/can/ti_hecc.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 12 +++++++-----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 11 ++++++-----
drivers/net/ethernet/cadence/at91_ether.c | 2 +-
drivers/net/ethernet/freescale/gianfar_ethtool.c | 1 +
drivers/net/ethernet/freescale/gianfar_ptp.c | 4 ++--
drivers/net/ethernet/intel/e1000/e1000_main.c | 11 +++++++++++
drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 4 ++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 +++++-----
drivers/net/ethernet/stmicro/stmmac/stmmac_timer.c | 8 ++++----
drivers/net/irda/sh_sir.c | 2 +-
drivers/net/usb/asix_devices.c | 4 ++++
drivers/net/usb/qmi_wwan.c | 11 ++++++++---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 4 ++++
drivers/net/wireless/ath/ath9k/debug.c | 2 ++
drivers/net/wireless/ath/ath9k/hw.c | 4 ----
drivers/net/wireless/ath/ath9k/hw.h | 3 +--
drivers/net/wireless/ath/ath9k/link.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 2 ++
drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c | 26 ++++++++++++++++----------
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 6 ++++--
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 1 +
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 12 ++++++++++--
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 6 ++++--
include/linux/xfrm.h | 2 ++
include/net/ip6_fib.h | 5 ++---
include/net/net_namespace.h | 10 ++++++++++
include/net/netns/ipv4.h | 1 -
include/net/route.h | 2 +-
net/batman-adv/bitarray.h | 6 +++---
net/bluetooth/bnep/sock.c | 4 ++--
net/bluetooth/cmtp/sock.c | 4 ++--
net/bluetooth/hci_sock.c | 16 ++++++++--------
net/bluetooth/hidp/sock.c | 4 ++--
net/core/dev.c | 5 +++--
net/core/skbuff.c | 4 +++-
net/ipv4/arp.c | 2 +-
net/ipv4/devinet.c | 10 +++++-----
net/ipv4/fib_frontend.c | 20 ++++++++++----------
net/ipv4/fib_rules.c | 2 +-
net/ipv4/fib_trie.c | 6 +++---
net/ipv4/route.c | 43 +++++--------------------------------------
net/ipv4/tcp.c | 23 ++++++++++++++++++-----
net/ipv4/tcp_input.c | 5 ++---
net/ipv6/inet6_connection_sock.c | 23 +----------------------
net/ipv6/ip6_fib.c | 4 ++++
net/ipv6/route.c | 19 ++++++++++++-------
net/netrom/af_netrom.c | 2 +-
net/sched/sch_qfq.c | 5 ++++-
net/xfrm/xfrm_policy.c | 3 ++-
net/xfrm/xfrm_user.c | 57 ++++++++++++++++++++++++++++++++++++++++++---------------
security/selinux/include/xfrm.h | 1 +
55 files changed, 253 insertions(+), 192 deletions(-)
^ permalink raw reply
* Re: [PATCH] netlink: use <linux/export.h> instead of <linux/module.h>
From: David Miller @ 2012-09-21 19:44 UTC (permalink / raw)
To: pablo; +Cc: netdev
In-Reply-To: <1348256138-15500-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Fri, 21 Sep 2012 21:35:38 +0200
> From: Pablo Neira Ayuso <pablo@netfilter.org>
>
> Since (9f00d97 netlink: hide struct module parameter in netlink_kernel_create),
> linux/netlink.h includes linux/module.h because of the use of THIS_MODULE.
>
> Use linux/export.h instead, as suggested by Stephen Rothwell, which is
> significantly smaller and defines THIS_MODULES.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Applied, but please make explicit what tree you are targetting when you
submit changes like this in the future.
Thanks.
^ permalink raw reply
* [PATCH] netlink: use <linux/export.h> instead of <linux/module.h>
From: pablo @ 2012-09-21 19:35 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Pablo Neira Ayuso <pablo@netfilter.org>
Since (9f00d97 netlink: hide struct module parameter in netlink_kernel_create),
linux/netlink.h includes linux/module.h because of the use of THIS_MODULE.
Use linux/export.h instead, as suggested by Stephen Rothwell, which is
significantly smaller and defines THIS_MODULES.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netlink.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 73ade5f..b3dc992 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -153,7 +153,7 @@ struct nlattr {
#include <linux/capability.h>
#include <linux/skbuff.h>
-#include <linux/module.h>
+#include <linux/export.h>
#include <net/scm.h>
struct net;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] Xen backend support for paged out grant targets V4.
From: Andres Lagar-Cavilla @ 2012-09-21 19:30 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Andres Lagar-Cavilla, Ian Campbell, Andres Lagar-Cavilla,
xen-devel, David Vrabel, David Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20120921185258.GA4931@phenom.dumpdata.com>
On Sep 21, 2012, at 2:52 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 05:29:24AM -0400, Andres Lagar-Cavilla wrote:
>> On Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:
>>
>>> (I think I forgot to hit send on this on Friday, sorry. Also
>>> s/xen.lists.org/lists.xen.org in the CC line…)
>> I'm on a roll here…
>>
>>>
>>> On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
>>>> Since Xen-4.2, hvm domains may have portions of their memory paged out. When a
>>>> foreign domain (such as dom0) attempts to map these frames, the map will
>>>> initially fail. The hypervisor returns a suitable errno, and kicks an
>>>> asynchronous page-in operation carried out by a helper. The foreign domain is
>>>> expected to retry the mapping operation until it eventually succeeds. The
>>>> foreign domain is not put to sleep because itself could be the one running the
>>>> pager assist (typical scenario for dom0).
>>>>
>>>> This patch adds support for this mechanism for backend drivers using grant
>>>> mapping and copying operations. Specifically, this covers the blkback and
>>>> gntdev drivers (which map foregin grants), and the netback driver (which copies
>>>
>>> foreign
>>>
>>>> foreign grants).
>>>>
>>>> * Add a retry method for grants that fail with GNTST_eagain (i.e. because the
>>>> target foregin frame is paged out).
>>>
>>> foreign
>>>
>>>> * Insert hooks with appropriate wrappers in the aforementioned drivers.
>>>>
>>>> The retry loop is only invoked if the grant operation status is GNTST_eagain.
>>>> It guarantees to leave a new status code different from GNTST_eagain. Any other
>>>> status code results in identical code execution as before.
>>>>
>>>> The retry loop performs 256 attempts with increasing time intervals through a
>>>> 32 second period. It uses msleep to yield while waiting for the next retry.
>>> [...]
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>> Since this is more about grant tables than netback this should probably
>>> go via Konrad rather than Dave, is that OK with you Dave?
>>
>> If that is the case hopefully Konrad can deal with the two typos? Otherwise happy to re-spin the patch.
>
> So with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> in the initial domain and the guest is crashed:
>
> [ 261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
With this patch? Or with the mmapbatch v2? This is a page fault in a foreign-mapped VMA. Not touched by this grant backend patch we are talking about.
Does the hypervisor dump anything to its console?
At which point during xc_hvm_build do you see this? (or elsewhere in the toolstack?)
Thanks
Andres
>
> guest config:
>> more /mnt/lab/latest/hvm.xm
> kernel = "/usr/lib/xen/boot/hvmloader"
> builder='hvm'
> memory=1024
> #maxmem=1024
> maxvcpus = 2
> serial='pty'
> vcpus = 2
> disk = [ 'file:/mnt/lab/latest/root_image.iso,hdc:cdrom,r']
> boot="dn"
> #vif = [ 'type=ioemu,model=e1000,mac=00:0F:4B:00:00:71, bridge=switch' ]
> vif = [ 'type=netfront, bridge=switch' ]
> #vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1']
> vnc=1
> vnclisten="0.0.0.0"
> usb=1
> xen_platform_pci=1
>
>
^ permalink raw reply
* Re: [PATCH v3] ipconfig: add nameserver IPs to kernel-parameter ip=
From: Christoph Fritz @ 2012-09-21 19:28 UTC (permalink / raw)
To: David Miller
Cc: rob, kuznet, j.weitzel, jmorris, yoshfuji, kaber, linux-doc,
linux-kernel, netdev, hjk, daniel
In-Reply-To: <20120921.145144.14955032475453606.davem@davemloft.net>
On Fri, 2012-09-21 at 14:51 -0400, David Miller wrote:
> From: Christoph Fritz <chf.fritz@googlemail.com>
> Date: Fri, 21 Sep 2012 20:31:19 +0200
>
> > On small systems (e.g. embedded ones) IP addresses are often configured
> > by bootloaders and get assigned to kernel via parameter "ip=". If set to
> > "ip=dhcp", even nameserver entries from DHCP daemons are handled. These
> > entries exported in /proc/net/pnp are commonly linked by /etc/resolv.conf.
> >
> > To configure nameservers for networks without DHCP, this patch adds option
> > <dns0-ip> and <dns1-ip> to kernel-parameter 'ip='.
> >
> > Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
> > Tested-by: Jan Weitzel <j.weitzel@phytec.de>
>
> Applied to net-next, thanks.
Thanks a lot for your reviews.
-- Christoph
^ permalink raw reply
* Re: New commands to configure IOV features
From: Yinghai Lu @ 2012-09-21 19:23 UTC (permalink / raw)
To: Ben Hutchings
Cc: Rose, Gregory V, Bjorn Helgaas, Yuval Mintz, davem@davemloft.net,
netdev@vger.kernel.org, Ariel Elior, Eilon Greenstein, linux-pci
In-Reply-To: <1348248958.2521.23.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, Sep 21, 2012 at 10:35 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Thu, 2012-09-20 at 22:50 -0700, Yinghai Lu wrote:
> [...]
>> Index: linux-2.6/include/linux/pci.h
>> ===================================================================
>> --- linux-2.6.orig/include/linux/pci.h
>> +++ linux-2.6/include/linux/pci.h
>> @@ -663,6 +663,7 @@ struct pci_driver {
>> const struct pci_device_id *id_table; /* must be non-NULL for probe to be called */
>> int (*probe) (struct pci_dev *dev, const struct pci_device_id *id); /* New device inserted */
>> void (*remove) (struct pci_dev *dev); /* Device removed (NULL if not a hot-plug capable driver) */
>> + void (*set_max_vfs) (struct pci_dev *dev); /* enable sriov */
>> int (*suspend) (struct pci_dev *dev, pm_message_t state); /* Device suspended */
>> int (*suspend_late) (struct pci_dev *dev, pm_message_t state);
>> int (*resume_early) (struct pci_dev *dev);
>
> Not sure about this; the driver may fail to enable those VFs and it
> would be nice to be able to report that failure directly.
>
> That said, this is 'max_vfs' (a limit) and if the driver fails to set up
> all the VFs then the *limit* may still be changed.
>
>> Subject: [PATCH] PCI: Add max_vfs in sysfs per pci device where supports
>>
>> driver later need to check dev->max_vfs in /sys
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> [...]
>> +static ssize_t
>> +max_vfs_store(struct device *dev, struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + unsigned long val;
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> +
>> + if (strict_strtoul(buf, 0, &val) < 0)
>> + return -EINVAL;
>> +
>> + pdev->max_vfs = val;
>> +
>> + if (pdev->is_added) {
>
> No locking required here?
should be removed.
>
>> + int err;
>> + err = device_schedule_callback(dev, max_vfs_callback);
>
> Any particular reason this should be a callback?
no, just copied that from bus rescan.
>
> [...]
>> Index: linux-2.6/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> +++ linux-2.6/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>> @@ -129,13 +129,6 @@ static struct notifier_block dca_notifie
>> };
>> #endif
>>
>> -#ifdef CONFIG_PCI_IOV
>> -static unsigned int max_vfs;
>> -module_param(max_vfs, uint, 0);
>> -MODULE_PARM_DESC(max_vfs,
>> - "Maximum number of virtual functions to allocate per
>> physical function - default is zero and maximum value is 63");
>> -#endif /* CONFIG_PCI_IOV */
>> -
>> static unsigned int allow_unsupported_sfp;
>> module_param(allow_unsupported_sfp, uint, 0);
>> MODULE_PARM_DESC(allow_unsupported_sfp,
>> @@ -4528,7 +4521,7 @@ static int __devinit ixgbe_sw_init(struc
>> #ifdef CONFIG_PCI_IOV
>> /* assign number of SR-IOV VFs */
>> if (hw->mac.type != ixgbe_mac_82598EB)
>> - adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
>> + adapter->num_vfs = (pdev->max_vfs > 63) ? 0 : pdev->max_vfs;
>
> We are trying to make all SR-IOV capable drivers work the same, so this
> weird limiting behaviour should not be retained.
>
> So I think the correct assignment is:
> adapter->num_vfs = min(pdev->max_vfs, 63);
this will treat >63 as 63. old one treat > 63 as 0 aka disabled.
looks your version is more reasonable...
>
>> #endif
>> /* enable itr by default in dynamic mode */
>> @@ -7249,8 +7242,9 @@ static int __devinit ixgbe_probe(struct
>>
>> #ifdef CONFIG_PCI_IOV
>> ixgbe_enable_sriov(adapter, ii);
>> -
>> #endif
>> + adapter->ixgbe_info = ii;
>> +
>> netdev->features = NETIF_F_SG |
>> NETIF_F_IP_CSUM |
>> NETIF_F_IPV6_CSUM |
>> @@ -7720,11 +7714,42 @@ static const struct pci_error_handlers i
>> .resume = ixgbe_io_resume,
>> };
>>
>> +static void ixgbe_set_max_vfs(struct pci_dev *pdev)
>> +{
>> +#ifdef CONFIG_PCI_IOV
>> + struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
>> + struct net_device *netdev = adapter->netdev;
>> + struct ixgbe_hw *hw = &adapter->hw;
>> + int num_vfs = 0;
>> +
>> + /* assign number of SR-IOV VFs */
>> + if (hw->mac.type != ixgbe_mac_82598EB)
>> + num_vfs = (pdev->max_vfs > 63) ? 0 : pdev->max_vfs;
>> +
>> + /* no change */
>> + if (adapter->num_vfs == num_vfs)
>> + return;
>> +
>> + if (!num_vfs) {
>> + /* disable sriov */
>> + ixgbe_disable_sriov(adapter);
>> + adapter->num_vfs = 0;
>> + } else if (!adapter->num_vfs && num_vfs) {
>> + /* enable sriov */
>> + adapter->num_vfs = num_vfs;
>> + ixgbe_enable_sriov(adapter, adapter->ixgbe_info);
>> + } else {
>> + /* increase or decrease */
>
> Indeed, increase or decrease is not supported either in our PCI API or
> in the SR-IOV spec. I think I would prefer the PCI core to filter out
> unsupported changes (i.e. not call set_max_vfs and maybe report an
> error), but I'm not sure about that.
should still call set_max_vfs, and let it set finally valid max_vfs.
pci driver should know better which max_vfs is better for exact ...
-Yinghai
^ permalink raw reply
* [PATCH] sunbmac: Remove unused local variable.
From: David Miller @ 2012-09-21 19:23 UTC (permalink / raw)
To: netdev
Commit eb716c54b1c71ad28ab20461bff831bd481066c4 ("sunbmac: remove
unnecessary setting of skb->dev") caused the local varible 'dev'
in bigmac_init_rings to become unused. And now the compiler
warns about it.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Noticed while doing some sparc test builds, committed to net-next
drivers/net/ethernet/sun/sunbmac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/sunbmac.c b/drivers/net/ethernet/sun/sunbmac.c
index 967fe8c..c9c977b 100644
--- a/drivers/net/ethernet/sun/sunbmac.c
+++ b/drivers/net/ethernet/sun/sunbmac.c
@@ -212,7 +212,6 @@ static void bigmac_clean_rings(struct bigmac *bp)
static void bigmac_init_rings(struct bigmac *bp, int from_irq)
{
struct bmac_init_block *bb = bp->bmac_block;
- struct net_device *dev = bp->dev;
int i;
gfp_t gfp_flags = GFP_KERNEL;
--
1.7.11.4
^ permalink raw reply related
* RE: bnx2x: link detected up at startup even when it should be down
From: Dmitry Kravkov @ 2012-09-21 19:23 UTC (permalink / raw)
To: Jean-Michel Hautbois
Cc: netdev, Barak Witkowski, Eilon Greenstein, davem@davemloft.net
In-Reply-To: <CAL8zT=i_eV3SjuBgdWrBPaE-CoBBVh5QJD8jg-YMoQHDuA4AOQ@mail.gmail.com>
Hi Jean,
Thank you for the info
> -----Original Message-----
> From: Jean-Michel Hautbois [mailto:jhautbois@gmail.com]
> Sent: Friday, September 21, 2012 9:04 AM
> To: Dmitry Kravkov
> Cc: netdev; Barak Witkowski; Eilon Greenstein; davem@davemloft.net
> Subject: Re: bnx2x: link detected up at startup even when it should be down
>
> I already did it twice. I think this is FW related and not only the
> commit adding afex support. It may have solved a link issue (I am just
> guessing, based on experiments) ?
FW replaced in this commit does not deal with link at all,
One is involved in link management is displayed using 'ethtool -i' - it comes with a card and driver independent.
Is device configured for MF by the switch?
Can you please share lspci output?
Other thing that can help in analysis is msglvl 0x4 for both situations
Thanks a lot
^ permalink raw reply
* Re: [PATCH 1/3 V2] phy/micrel: Implement support for KSZ8021
From: Marek Vasut @ 2012-09-21 19:19 UTC (permalink / raw)
To: David Miller
Cc: netdev, david.choi, nobuhiro.iwamatsu.yj, fabio.estevam,
shawn.guo
In-Reply-To: <20120921.151104.718226045755546422.davem@davemloft.net>
Dear David Miller,
> From: Marek Vasut <marex@denx.de>
> Date: Fri, 21 Sep 2012 21:06:52 +0200
>
> > You know, youth and all ... I was under the impression the patches shall
> > be checkpatch clean. But you got me there quite well, something must be
> > wrong with my precommit hook.
>
> checkpatch is not a panacea, and it is in particular not an automaton
> that one uses without using any human judgement at all.
>
> In particular, checkpatch does not enforce the comment style we use in
> the networking code nor several other conventions that we use which
> are slightly different from the rest of the tree.
>
> Therefore strick checkpatch conformance is never appropriate.
Understood.
> > Anyway, about the checkpatch cleanup of the file, will that be
> > welcome (afterwards I fix the patchset and repost)?
>
> See above, strict checkpatch cleanups, especially those done in
> a completely automaton style with zero human judgment involved,
> are not welcome.
I meant the .features field ... it seems that the | at the following line
appears in other PHY drivers as well though. Lets leave it at that anyway.
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 1/3 V2] phy/micrel: Implement support for KSZ8021
From: David Miller @ 2012-09-21 19:11 UTC (permalink / raw)
To: marex; +Cc: netdev, david.choi, nobuhiro.iwamatsu.yj, fabio.estevam,
shawn.guo
In-Reply-To: <201209212106.53069.marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Fri, 21 Sep 2012 21:06:52 +0200
> You know, youth and all ... I was under the impression the patches shall be
> checkpatch clean. But you got me there quite well, something must be wrong with
> my precommit hook.
checkpatch is not a panacea, and it is in particular not an automaton
that one uses without using any human judgement at all.
In particular, checkpatch does not enforce the comment style we use in
the networking code nor several other conventions that we use which
are slightly different from the rest of the tree.
Therefore strick checkpatch conformance is never appropriate.
> Anyway, about the checkpatch cleanup of the file, will that be
> welcome (afterwards I fix the patchset and repost)?
See above, strict checkpatch cleanups, especially those done in
a completely automaton style with zero human judgment involved,
are not welcome.
^ permalink raw reply
* Re: [PATCH 1/3 V2] phy/micrel: Implement support for KSZ8021
From: Marek Vasut @ 2012-09-21 19:06 UTC (permalink / raw)
To: David Miller
Cc: netdev, david.choi, nobuhiro.iwamatsu.yj, fabio.estevam,
shawn.guo
In-Reply-To: <20120921.145405.646315503417542108.davem@davemloft.net>
Dear David Miller,
> From: Marek Vasut <marex@denx.de>
> Date: Fri, 21 Sep 2012 20:50:46 +0200
>
> > Dear David Miller,
> >
> >> From: Marek Vasut <marex@denx.de>
> >> Date: Fri, 21 Sep 2012 20:33:12 +0200
> >>
> >> > I don't like it.
> >>
> >> Then I'm not applying your patches.
> >
> > What about the other part of my offer ?
>
> I read it, and if it were relevant to this discussion I would
> have quoted it.
>
> Can you please just fix up your patches exactly how I have asked you
> to so that I can get these bug fixes into the 'net' tree?
Sure, as you wish.
> This is completely rediculous, nobody else pushes back when I make
> simple coding style correction requests for their changes like you
> are.
You know, youth and all ... I was under the impression the patches shall be
checkpatch clean. But you got me there quite well, something must be wrong with
my precommit hook.
> You're behavior is self defeating, it's causing your work to not be
> useful and to not propagate to the very place where people can benefit
> from it the most.
Hey, this hurt. Anyway, about the checkpatch cleanup of the file, will that be
welcome (afterwards I fix the patchset and repost)? Now that you pointed out
there's more trouble in the file that is.
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH net-next] be2net: Ignore spurious UE indication from NIC
From: David Miller @ 2012-09-21 19:04 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20120921163620.GA6147@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Fri, 21 Sep 2012 11:36:20 -0500
> Ignore spurious UE indication seen on some platforms.
> Consider the error as un-recoverable only when the bits
> stay high during second sampling.
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Treating uncorrectable errors as spurious seems like an invitation
for hard to track down data corruption to me.
You'll need to come up with a more sophisticated test for
spurious other than "happens more than once" before I'm willing
to subject the entire world to this kind of potential problem.
^ permalink raw reply
* Re: [PATCH net-next 3/3] ptp: derive the device name from the parent device
From: Ben Hutchings @ 2012-09-21 19:01 UTC (permalink / raw)
To: Richard Cochran
Cc: Keller, Jacob E, netdev@vger.kernel.org, David Miller,
Kirsher, Jeffrey T, John Stultz, Vick, Matthew
In-Reply-To: <20120921184035.GF6129@netboy.at.omicron.at>
On Fri, 2012-09-21 at 20:40 +0200, Richard Cochran wrote:
> On Fri, Sep 21, 2012 at 07:23:03PM +0100, Ben Hutchings wrote:
> >
> > I think what I'm still missing from you is some explanation of what the
> > 'clock name' is meant to be used as - a type name, a unique identifier,
> > a 'friendly name' for listing clocks in a user interface?
>
> The original idea was a type/friendly kind of thing.
>
> Imagine you are the admin of some random box that should run PTP. You
> do 'cat /sys/class/ptp/ptp0/clock_name' and see "gianfar clock". Then
> you think to yourself, "Excellent, I know that one, it works great,
> and I can even get a PPS output."
>
> But if you saw "IXP46X timer" then you would think, "Forget it, this
> will never work."
>
> That was the idea.
>
> But before the ethtool thing came along, people started putting MAC
> addresses in that string, and it continued even after the ethtool
> method appeared. I wanted to correct the MAC abuses, but then I
> thought you were concurring with putting some kind of semi-unique
> device ID there.
I was confused about whether it was actually meant to be unique.
The ethtool command is useful but setting the parent device may be even
more useful, e.g. you will be able to write udev rules for PHC devices
based on the parent device's identity.
> I really don't care too much about the clock_name anyhow, because I
> always know my own hardware. I don't mind changing it from type-string
> or friendly-name to device ID, if people think that is more useful.
I don't mind either, just so long as the rule is either (1) implemented
in the PTP core code or (2) made very clear to driver writers.
The lack of a parent for the IXP device makes (1) hard to do well.
Ben.
--
Ben Hutchings, Staff 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
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