* Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
From: Stephan Gatzka @ 2013-01-21 19:25 UTC (permalink / raw)
To: Stefan Richter; +Cc: YOSHIFUJI Hideaki, netdev, linux1394-devel, David Miller
In-Reply-To: <20130121083957.6e2c5a68@stein>
> Two net_device instances on one 1394 card would be awkward: They would
> have to share one instance of isochronous reception context (for reception
> of asynchronous 1394 streams; those are used for broadcasts and
> multicasts). Such a sharing is surely possible, but if double net_device
> instantiation can be avoided, then avoid it.
>
> Not to mention the user interface problem of having two netifs, one which
> only supports IPv4 and another one which only supports IPv6. So far I
> never had IPv6 configured into a Linux kernel, but I suppose that folks
> are used to be able to use eth0 etc. for both protocols.
Full ack. And that's the reason why I feel very uncomfortable with a
Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
This seems possible with a single netdevice for IPv4/6 only if we
_always_ use the same fifo address for both IPv4 and IPv6. Do we all
agree on that?
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] cdc_ncm: add support FLAG_NOARP for Infineon modem platform
From: David Miller @ 2013-01-21 19:25 UTC (permalink / raw)
To: cpuwolf-Re5JQEeQqe8AvxtiuMwx3w
Cc: sshtylyov-Igf4POYTYCDQT0dZR+AlfA, dcbw-H+wXaHxf7aLQT0dZR+AlfA,
peter-Y+HMSxxDrH8, oneukum-l3A5Bk7waGM,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw, bjorn-yOkvZcmFvRU,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1358784032-3897-2-git-send-email-cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Wei Shuai <cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 22 Jan 2013 00:00:32 +0800
> Infineon(now Intel) HSPA Modem platform NCM cannot support ARP.
> we can define a new common structure wwan_noarp_info.
> Then more similiar NO ARP devices can be handled easily
>
> Signed-off-by: Wei Shuai <cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] usbnet: add new flag FLAG_NOARP for usb net devices
From: David Miller @ 2013-01-21 19:25 UTC (permalink / raw)
To: cpuwolf-Re5JQEeQqe8AvxtiuMwx3w
Cc: sshtylyov-Igf4POYTYCDQT0dZR+AlfA, dcbw-H+wXaHxf7aLQT0dZR+AlfA,
peter-Y+HMSxxDrH8, oneukum-l3A5Bk7waGM,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw, bjorn-yOkvZcmFvRU,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1358784032-3897-1-git-send-email-cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Wei Shuai <cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 22 Jan 2013 00:00:31 +0800
> We do have some USB net devices, which cannot do ARP.
> so we can introduce a new flag FLAG_NOARP, then client drivers
> can easily handle this kind of devices
>
> Signed-off-by: Wei Shuai <cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 0/3] cdc_ncm and cdc_mbim fixes for 3.8
From: David Miller @ 2013-01-21 19:22 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, gsuarez, alexey.orishko, oneukum
In-Reply-To: <1358783440-11459-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Mon, 21 Jan 2013 16:50:37 +0100
> The 2 first patches in this series are required to make the Sierra
> Wireless MC7710 card work in MBIM mode. They may also be
> required for other Qualcomm firmware based MBIM devices.
>
> Patch #1 was previously posted as a standalone patch. This version
> is a replacement, removing a theoretical NULL pointer exception.
>
> Patch #3 fixes a bug I introduced in v3.7
All applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: Add a socket release callback for datagram sockets
From: David Miller @ 2013-01-21 19:18 UTC (permalink / raw)
To: steffen.klassert; +Cc: Yurij.Plotnikov, ja, netdev
In-Reply-To: <20130121120003.GF30530@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 21 Jan 2013 13:00:03 +0100
> This implements a socket release callback function to check
> if the socket cached route got invalid during the time
> we owned the socket. The function is used from udp, raw
> and ping sockets.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ipv4: Invalidate the socket cached route on pmtu events if possible
From: David Miller @ 2013-01-21 19:18 UTC (permalink / raw)
To: steffen.klassert; +Cc: Yurij.Plotnikov, ja, netdev
In-Reply-To: <20130121115911.GE30530@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 21 Jan 2013 12:59:11 +0100
> The route lookup in ipv4_sk_update_pmtu() might return a route
> different from the route we cached at the socket. This is because
> standart routes are per cpu, so each cpu has it's own struct rtable.
> This means that we do not invalidate the socket cached route if the
> NET_RX_SOFTIRQ is not served by the same cpu that the sending socket
> uses. As a result, the cached route reused until we disconnect.
>
> With this patch we invalidate the socket cached route if possible.
> If the socket is owened by the user, we can't update the cached
> route directly. A followup patch will implement socket release
> callback functions for datagram sockets to handle this case.
>
> Reported-by: Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: net_cls: fd passed in SCM_RIGHTS datagram not set correctly
From: David Miller @ 2013-01-21 19:17 UTC (permalink / raw)
To: wagi-kQCPcA+X3s7YtjvyW6yDsg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
lizefan-hv44wF8Li93QT0dZR+AlfA,
daniel.wagner-98C5kh4wR6ohFhg+JK9F0w,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
nhorman-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <1358761102-7765-1-git-send-email-wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
From: Daniel Wagner <wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
Date: Mon, 21 Jan 2013 10:38:22 +0100
> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>
> Commit 6a328d8c6f03501657ad580f6f98bf9a42583ff7 changed the update
> logic for the socket but it does not update the SCM_RIGHTS update
> as well. This patch is based on the net_prio fix commit
>
> 48a87cc26c13b68f6cce4e9d769fcb17a6b3e4b8
>
> net: netprio: fd passed in SCM_RIGHTS datagram not set correctly
>
> A socket fd passed in a SCM_RIGHTS datagram was not getting
> updated with the new tasks cgrp prioidx. This leaves IO on
> the socket tagged with the old tasks priority.
>
> To fix this add a check in the scm recvmsg path to update the
> sock cgrp prioidx with the new tasks value.
>
> Let's apply the same fix for net_cls.
>
> Reported-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
You need to resubmit this, and proprly add a "Signed-off-by: " tag
for yourself.
^ permalink raw reply
* Re: [PATCH v5 0/3] make mac programming for virtio net more robust
From: David Miller @ 2013-01-21 19:09 UTC (permalink / raw)
To: akong; +Cc: netdev, mst, rusty, qemu-devel, kvm, virtualization
In-Reply-To: <1358767043-24548-1-git-send-email-akong@redhat.com>
From: Amos Kong <akong@redhat.com>
Date: Mon, 21 Jan 2013 19:17:20 +0800
> Currenly mac is programmed byte by byte. This means that we
> have an intermediate step where mac is wrong.
>
> Third patch introduced a new vq control command to set mac
> address, it's atomic.
>
> V2: check return of sending command, delay eth_mac_addr()
> V3: restore software address when fail to set hardware address
> V4: split eth_mac_addr, fix error handle
> V5: rebase patches to net-next tree
I'll apply this series, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2 v2] Add support of multicast static tree
From: David Miller @ 2013-01-21 18:56 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: dlstevens, netdev, netdev-owner
In-Reply-To: <1358784026-4071-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 21 Jan 2013 17:00:24 +0100
> The goal of this serie is to add the support of proxy multicast, ie being able
> to build a static multicast tree. In other words, it adds the support of (*,G)
> mf[6]c entries.
>
> v2: use INADDR_ANY instead of 0 for IPv4 addresses
I'll apply this, thanks Nicolas.
^ permalink raw reply
* Re: [PATCH net-next] Documentation: remove obsolete networking/multicast.txt file
From: David Miller @ 2013-01-21 18:54 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev
In-Reply-To: <1358785061-17985-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon, 21 Jan 2013 11:17:41 -0500
> The original intent of this file was to list limitations in
> drivers/hardware relating to multicast use, back when some
> modest hardware from the early 1990s did not support things
> we might take for granted today.
>
> I was intending to delete some now-gone MCA/token ring entries
> in this file, but once I opened it, I found it only contained
> information on the earliest (pre-2000) linux networking drivers.
>
> Checking the git history shows that the file hasn't been touched
> since 2005. Clearly nobody is actively consulting this file
> as a meaningful reference.
>
> Rather than add a "YES YES YES" line for all of the drivers we
> currently have, lets just take advantage of the fact that nobody
> is using the file to delete it.
>
> This has the side benefit of not having to do a line-by-line
> deletion of the file content as each older driver is expired.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks Paul.
^ permalink raw reply
* Re: [patch 0/6] s390: network patches for net-next
From: David Miller @ 2013-01-21 18:52 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20130121123017.240686588@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Mon, 21 Jan 2013 13:30:17 +0100
> here are some s390 related patches for net-next
All applied, thanks.
^ permalink raw reply
* Re: ipv6: Do not depend on rt->n in rt6_probe().
From: YOSHIFUJI Hideaki @ 2013-01-21 18:41 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev, kbuild, YOSHIFUJI Hideaki
In-Reply-To: <20130121182858.GA8808@elgon.mountain>
(2013年01月22日 03:28), Dan Carpenter wrote:
> Hello YOSHIFUJI Hideaki / 吉藤英明,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 2152caea7196: "ipv6: Do not depend on rt->n in
> rt6_probe()." from Jan 17, 2013, leads to the following Smatch
> complaint:
>
> net/ipv6/route.c:495 rt6_probe()
> error: we previously assumed 'neigh' could be null (see line 490)
>
> net/ipv6/route.c
> 489
> 490 if (!neigh ||
> ^^^^^
> New test.
>
> 491 time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
> 492 struct in6_addr mcaddr;
> 493 struct in6_addr *target;
> 494
> 495 neigh->updated = jiffies;
> ^^^^^^^^^^^^^^
> Old dereference.
>
> 496
> 497 if (neigh)
> ^^^^^
> Another new test.
Oh, right, I'll fix. Thanks!
--yoshfuji
^ permalink raw reply
* Re: [PATCH] net: ethernet: davinci: Fix build breakage
From: Thierry Reding @ 2013-01-21 18:36 UTC (permalink / raw)
To: David Miller; +Cc: mugunthanvnm, netdev, linux-kernel
In-Reply-To: <20130121.131314.1276887267486833907.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Mon, Jan 21, 2013 at 01:13:14PM -0500, David Miller wrote:
> From: Thierry Reding <thierry.reding@avionic-design.de>
> Date: Mon, 21 Jan 2013 10:38:39 +0100
>
> > The correct name of the transmit DMA channel field in struct emac_priv
> > is txchan, not txch.
> >
> > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
>
> Nothing is more irritating than someone not saying what tree their
> patch is targetted for. My time is not well used by playing a
> guessing game about where a patch is supposed to go.
>
> After some futzing around I was able to determine that this patch
> is needed for net-next only, but please make a specific mention of
> this next time.
I'm sorry about that. I'll make a mental note to think of it next time.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 00/19] IPv6 NDISC Updates
From: David Miller @ 2013-01-21 18:35 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <50FD712C.1050703@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 22 Jan 2013 01:47:40 +0900
> This series of changes basically clean up NDISC logic,
> especially on sender side.
This series looks great, applied.
In patch #4 you add a check on rd_len such that the option is only
constructed if rd_len is non-zero, I'd like you to enhance this so
that it's easier to understand.
I can't convince myself either that rd_len can never be zero, or that
when it is zero we do not still put the uninitialized 'opt' into the
packet and out on the wire.
Using either assertions of descriptive comments, explain why all of
these problems will not arise.
Thanks.
^ permalink raw reply
* re: ipv6: Do not depend on rt->n in rt6_probe().
From: Dan Carpenter @ 2013-01-21 18:28 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, kbuild
Hello YOSHIFUJI Hideaki / 吉藤英明,
This is a semi-automatic email about new static checker warnings.
The patch 2152caea7196: "ipv6: Do not depend on rt->n in
rt6_probe()." from Jan 17, 2013, leads to the following Smatch
complaint:
net/ipv6/route.c:495 rt6_probe()
error: we previously assumed 'neigh' could be null (see line 490)
net/ipv6/route.c
489
490 if (!neigh ||
^^^^^
New test.
491 time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
492 struct in6_addr mcaddr;
493 struct in6_addr *target;
494
495 neigh->updated = jiffies;
^^^^^^^^^^^^^^
Old dereference.
496
497 if (neigh)
^^^^^
Another new test.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/2] net: fec: refactor dt probing
From: Sascha Hauer @ 2013-01-21 18:27 UTC (permalink / raw)
To: Baruch Siach; +Cc: netdev, shawn.guo, davem, linux-arm-kernel
In-Reply-To: <20130121174824.GA27956@sapphire.tkos.co.il>
On Mon, Jan 21, 2013 at 07:48:26PM +0200, Baruch Siach wrote:
> Hi Sascha,
>
> On Mon, Jan 21, 2013 at 09:37:54AM +0100, Sascha Hauer wrote:
> > For devicetree parsing only the fec_get_phy_mode_dt() is
> > available. Rename it to fec_probe_dt() to be able to add more devicetree
> > parsing to it.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
>
> [...]
>
> > -static int fec_get_phy_mode_dt(struct platform_device *pdev)
> > +static int fec_probe_dt(struct fec_enet_private *fep)
> > {
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = fep->pdev->dev.of_node;
> >
> > - if (np)
> > - return of_get_phy_mode(np);
> > + if (!np)
> > + return -ENODEV;
> > +
> > + fep->phy_interface = of_get_phy_mode(np);
> >
> > return -ENODEV;
>
> Maybe return fep->phy_interface?
No, but indeed this should return successfully. I will rework this after
it's clear how we want to proceed with this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 15/21] NTB: Update Version
From: Greg KH @ 2013-01-21 18:26 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, Dave Jiang, Nicholas Bellinger
In-Reply-To: <20130121175740.GF22208@jonmason-lab>
On Mon, Jan 21, 2013 at 10:57:41AM -0700, Jon Mason wrote:
> On Sun, Jan 20, 2013 at 03:47:14PM -0800, Greg KH wrote:
> > On Sat, Jan 19, 2013 at 02:02:29AM -0700, Jon Mason wrote:
> > > Update NTB version to 0.25
> > >
> > > Signed-off-by: Jon Mason <jon.mason@intel.com>
> > > ---
> > > drivers/ntb/ntb_hw.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > > index b792ccd..df86882 100644
> > > --- a/drivers/ntb/ntb_hw.c
> > > +++ b/drivers/ntb/ntb_hw.c
> > > @@ -56,7 +56,7 @@
> > > #include "ntb_regs.h"
> > >
> > > #define NTB_NAME "Intel(R) PCI-E Non-Transparent Bridge Driver"
> > > -#define NTB_VER "0.24"
> > > +#define NTB_VER "0.25"
> >
> > I'm not objecting to this, but in the end, does it really matter? Why
> > not just stick with whatever kernel version you are using? Keeping this
> > up to date is going to be hard over the long haul, right?
>
> Currently, it is a convenient way to verify the people testing the
> code are running the latest version, since they are usually running
> their tests on a stable kernel. As the code becomes more stable, I
> can see this becoming unnecessary and I will remove it then.
Ok, that sounds good, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 08/21] NTB: declare unused variables
From: Greg KH @ 2013-01-21 18:25 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, Dave Jiang, Nicholas Bellinger
In-Reply-To: <20130121175054.GE22208@jonmason-lab>
On Mon, Jan 21, 2013 at 10:50:55AM -0700, Jon Mason wrote:
> On Sun, Jan 20, 2013 at 03:42:28PM -0800, Greg KH wrote:
> > On Sat, Jan 19, 2013 at 02:02:22AM -0700, Jon Mason wrote:
> > > Tag pci_device_id in ntb_pci_probe as unused function parameters. This
> > > corrects issues found by 'EXTRA_CFLAGS=-W'.
> >
> > Why would you build the kernel with that option? This isn't needed, so
>
> Per Documentation/SubmitChecklist:
>
> 22: Newly-added code has been compiled with `gcc -W' (use "make
> EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
> finding bugs like "warning: comparison between signed and unsigned".
>
>
> I was attempting to comply with that suggestion. If this is
> unnecessary, then I can toss these, but I don't really see them
> hurting anything.
It's messy and unneeded, so I'd not recommend using it. As the
checklist says, it generates a lot of noise, and is good for finding
real bugs, this isn't a "real" bug at all.
> Same goes for the other 2 patches found via 'EXTRA_CFLAGS=-W'.
Understood, I've not applied them either :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 01/21] NTB: correct missing readq/writeq errors
From: Greg KH @ 2013-01-21 18:23 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, Dave Jiang, Nicholas Bellinger
In-Reply-To: <20130121173818.GD22208@jonmason-lab>
On Mon, Jan 21, 2013 at 10:38:18AM -0700, Jon Mason wrote:
> On Sun, Jan 20, 2013 at 03:40:05PM -0800, Greg KH wrote:
> > On Sat, Jan 19, 2013 at 02:02:15AM -0700, Jon Mason wrote:
> > > Atomic readq and writeq do not exist by default on some 32bit
> > > architectures, thus causing compile errors due to non-existent symbols.
> > > In those cases, use the definitions of those symbols from
> > > include/asm-generic/io-64-nonatomic-hi-lo.h
> > >
> > > Signed-off-by: Jon Mason <jon.mason@intel.com>
> > > ---
> > > drivers/ntb/ntb_hw.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > > index 4c71b17..0b46fef 100644
> > > --- a/drivers/ntb/ntb_hw.c
> > > +++ b/drivers/ntb/ntb_hw.c
> > > @@ -45,6 +45,7 @@
> > > * Contact Information:
> > > * Jon Mason <jon.mason@intel.com>
> > > */
> > > +#include <asm-generic/io-64-nonatomic-hi-lo.h>
> >
> > Really? This seems really odd. Usually we just don't build the code
> > for any platform that doesn't have readq/writeq. Otherwise, shouldn't
> > those arches just include this file themselves to keep everything
> > working? Individual drivers shouldn't have to do this.
>
> There is no readq/writeq for 32bit x86. I was using this header file
> to get around that. I freely admit that I have done 0 testing on
> 32bit, but it should work. If you prefer I modify the Kconfig to only
> enable this for x86_64 until such time as I test on x86_32, I will
> happily submit that patch.
No, other drivers on 32bit x86 also use readq, and do not include this
asm header file. So there is a proper way to do this, just dig through
the header file include mess to determine the proper one to include.
You should never have to include asm-generic file directly, that's the
issue here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] net: ethernet: davinci: Fix build breakage
From: David Miller @ 2013-01-21 18:13 UTC (permalink / raw)
To: thierry.reding; +Cc: mugunthanvnm, netdev, linux-kernel
In-Reply-To: <1358761119-25846-1-git-send-email-thierry.reding@avionic-design.de>
From: Thierry Reding <thierry.reding@avionic-design.de>
Date: Mon, 21 Jan 2013 10:38:39 +0100
> The correct name of the transmit DMA channel field in struct emac_priv
> is txchan, not txch.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Nothing is more irritating than someone not saying what tree their
patch is targetted for. My time is not well used by playing a
guessing game about where a patch is supposed to go.
After some futzing around I was able to determine that this patch
is needed for net-next only, but please make a specific mention of
this next time.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Add support for netconsole driver used on bridge device with VIF attached
From: yuval.shaia @ 2013-01-21 18:00 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org
In-Reply-To: <1358789308.3279.271.camel@zakaz.uk.xensource.com>
On 01/21/2013 07:28 PM, Ian Campbell wrote:
> On Mon, 2013-01-21 at 17:17 +0000, Yuval Shaia wrote:
>
>> When starting a VM which has virtual interface attached to the same
>> bridge (i.e vif = [type=netfront,bridge=xenbr0'] in vm.cfg) which is
>> used for netconsole the
>> following message appears (after about 60 seconds) and VM creation
>> operation fails.
>> Error: Device 0 (vif) could not be connected. Hotplug scripts not
>> working.
> I'm not sure how this can relate netconsole since this happens before
> the guest even runs, doesn't it?
Running the same scenario without netconsole runs smoothly.
>
>> As i see it, netconsole driver requires ndo_poll_controller from the
>> device's controlling driver (function __netpoll_setup in
>> net/core/netpoll.c), a thing that is not supported currently in
>> xen_netback driver which is the driver that runs on dom0 and serve
>> VM's virtual interface.
> Which domain is using netconsole? Is it dom0 or domU? What parameters do
> you give it?
dom0.
parameters: netconsole=1111@src-ip/xenbr0,2002@dst-ip/dst-mac
>
> I assume it is the domU but if that's the case I don't see why a netback
> rather than netfront patch would be required.
>
> Or is dom0 doing netconsole where the log receiver is a domU?
Log received at dom0 as output of xm cr vm.cfg command.
netconsole is used on dom0 to monitor its log
>
> Ian.
>
^ permalink raw reply
* RE: [PATCH net] net: cdc_ncm: workaround for missing CDC Union
From: Alexey ORISHKO @ 2013-01-21 17:59 UTC (permalink / raw)
To: Oliver Neukum, Bjørn Mork
Cc: Alexey Orishko, netdev@vger.kernel.org, linux-usb@vger.kernel.org,
Greg Suarez
In-Reply-To: <2214944.HMNV73jJm5@linux-5eaq.site>
> -----Original Message-----
> From: Oliver Neukum [mailto:oneukum@suse.de]
> On Monday 21 January 2013 15:47:13 Bjørn Mork wrote:
> > But I wonder if this isn't really a generic problem in usbnet. The
> > FLAG_MULTI_PACKET test here seems completely bogus:
> >
> > if (length % dev->maxpacket == 0) {
> > if (!(info->flags & FLAG_SEND_ZLP)) {
> > if (!(info->flags & FLAG_MULTI_PACKET)) {
> > urb->transfer_buffer_length++;
> > if (skb_tailroom(skb)) {
> > skb->data[skb->len] = 0;
> > __skb_put(skb, 1);
> > }
> > }
> > } else
> > urb->transfer_flags |= URB_ZERO_PACKET;
> > }
> >
> > Either the FLAG_MULTI_PACKET minidriver will have already padded the
> > buffer so that we do not hit (length % dev->maxpacket == 0), or we
> > should choose one of the alternatives: ZLP or padding.
>
> But we cannot simply call __skb_put for a complicated data frame.
> Besides you may want the current behavior.
>
Specification says:
NCM/MBIM shall not send ZLP if buffer size is dwNtbOutMaxSize.
The problem is:
dwNtbOutMaxSize value is negotiated between host and device NCM/MBIM
entities and usbnet has no knowledge about it.
Adding one byte to make buffer looking like a short packet was most
simple approach instead of inventing a way to communicate
dwNtbOutMaxSize to usbnet.
You could drop short packet approach if dwNtbOutMaxSize is provided
to usbnet and decision is made accordingly to NCM/MBIM spec (with
exception to faulty devices).
Regards,
Alexey
^ permalink raw reply
* Re: [PATCH 15/21] NTB: Update Version
From: Jon Mason @ 2013-01-21 17:57 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, netdev, Dave Jiang, Nicholas Bellinger
In-Reply-To: <20130120234714.GA21708@kroah.com>
On Sun, Jan 20, 2013 at 03:47:14PM -0800, Greg KH wrote:
> On Sat, Jan 19, 2013 at 02:02:29AM -0700, Jon Mason wrote:
> > Update NTB version to 0.25
> >
> > Signed-off-by: Jon Mason <jon.mason@intel.com>
> > ---
> > drivers/ntb/ntb_hw.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> > index b792ccd..df86882 100644
> > --- a/drivers/ntb/ntb_hw.c
> > +++ b/drivers/ntb/ntb_hw.c
> > @@ -56,7 +56,7 @@
> > #include "ntb_regs.h"
> >
> > #define NTB_NAME "Intel(R) PCI-E Non-Transparent Bridge Driver"
> > -#define NTB_VER "0.24"
> > +#define NTB_VER "0.25"
>
> I'm not objecting to this, but in the end, does it really matter? Why
> not just stick with whatever kernel version you are using? Keeping this
> up to date is going to be hard over the long haul, right?
Currently, it is a convenient way to verify the people testing the
code are running the latest version, since they are usually running
their tests on a stable kernel. As the code becomes more stable, I
can see this becoming unnecessary and I will remove it then.
Thanks,
Jon
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 08/21] NTB: declare unused variables
From: Jon Mason @ 2013-01-21 17:50 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, netdev, Dave Jiang, Nicholas Bellinger
In-Reply-To: <20130120234228.GC14196@kroah.com>
On Sun, Jan 20, 2013 at 03:42:28PM -0800, Greg KH wrote:
> On Sat, Jan 19, 2013 at 02:02:22AM -0700, Jon Mason wrote:
> > Tag pci_device_id in ntb_pci_probe as unused function parameters. This
> > corrects issues found by 'EXTRA_CFLAGS=-W'.
>
> Why would you build the kernel with that option? This isn't needed, so
Per Documentation/SubmitChecklist:
22: Newly-added code has been compiled with `gcc -W' (use "make
EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
finding bugs like "warning: comparison between signed and unsigned".
I was attempting to comply with that suggestion. If this is
unnecessary, then I can toss these, but I don't really see them
hurting anything.
Same goes for the other 2 patches found via 'EXTRA_CFLAGS=-W'.
Thanks,
Jon
> I'm not going to apply it.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] net: fec: refactor dt probing
From: Baruch Siach @ 2013-01-21 17:48 UTC (permalink / raw)
To: Sascha Hauer; +Cc: netdev, shawn.guo, davem, linux-arm-kernel
In-Reply-To: <1358757475-21035-2-git-send-email-s.hauer@pengutronix.de>
Hi Sascha,
On Mon, Jan 21, 2013 at 09:37:54AM +0100, Sascha Hauer wrote:
> For devicetree parsing only the fec_get_phy_mode_dt() is
> available. Rename it to fec_probe_dt() to be able to add more devicetree
> parsing to it.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
[...]
> -static int fec_get_phy_mode_dt(struct platform_device *pdev)
> +static int fec_probe_dt(struct fec_enet_private *fep)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = fep->pdev->dev.of_node;
>
> - if (np)
> - return of_get_phy_mode(np);
> + if (!np)
> + return -ENODEV;
> +
> + fep->phy_interface = of_get_phy_mode(np);
>
> return -ENODEV;
Maybe return fep->phy_interface?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ 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