* Re: qmi_wwan on Huawei E398
From: Bjørn Mork @ 2013-01-11 19:27 UTC (permalink / raw)
To: Cedric Jehasse, netdev
In-Reply-To: <CABvLYuAX=r_Y0AdDtNp5g0kRYeP6suhLe_b68a7sQYJ-i7wrvg@mail.gmail.com>
Cedric Jehasse <cedric.jehasse@gmail.com> wrote:
>Hi,
>
>I'm trying to use qmi on an Huawei E398 dongle with ofono on a 3.7.1
>kernel. (this works with a 3.5.0 kernel)
>ofono looks for the class/subclass/protocol of the parent
>usb_interface device for the qmi_wwan and cdc_wdm devices. This must
>match with ff/01/08 and ff/01/09 Cls/Sub/Prot.
>
>Below is a trace of the udev events and usb-device output for a 3.5.0
>and 3.7.1 kernel. The difference is in the parent devices for wwan0
>and cdc-wdm0.
>The parent device for wwan0 is on a 3.7.1 kernel is If3. Is this
>normal?
>
>* 3.5.0:
>KERNEL[201.262240] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usb/cdc-wdm0 (usb)
>KERNEL[201.347292] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.4/net/wwan0 (net)
>
>T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
>D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>P: Vendor=12d1 ProdID=150a Rev=00.00
>S: Manufacturer=Huawei Technologies
>S: Product=HUAWEI Mobile
>S: SerialNumber=1234567890ABCDEF
>C: #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=cdc_wdm
>I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>* 3.7.1:
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>
>T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
>D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>P: Vendor=12d1 ProdID=150a Rev=00.00
>S: Manufacturer=Huawei Technologies
>S: Product=HUAWEI Mobile
>S: SerialNumber=1234567890ABCDEF
>C: #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=qmi_wwan
>I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>Thanks,
>Cedric
This looks right to me. There is a single function using two USB interfaces. We started out letting the cdc-wdm driver handle the control interface and the qmi_wwan driver the data interface. This is what you see in 3.5. But splitting a function like this was very awkward and made devices like the E398 behave differently from most other QMI devices, which only use a single USB interface.
So we changed this to let the qmi_wwan driver handle both interfaces. This is what you see in 3.7. The control interface is now the parent of both the cdc_wdm character device and the wwan network device and the data interface is just a data interface.
I realize that this is balancing on the edge of acceptable userspace visible changes, but all this did was making devices like the E398 look similar to single interface devices. Which already had to be supported by the userspace applications.
Now I understand that ofono does a lot stricter matching than I have anticipated, looking at the vendor specific subclass and protocol fields of the wwan parent interface. I don't think we can fix that without updating ofono. Sorry. If it is going to do that then it needs to accept both ff/01/08 and ff/01/09.
Bjørn
^ permalink raw reply
* Re: [PATCH 0/3] ixgbe: request_firmware for configuration parameters
From: Shannon Nelson @ 2013-01-11 19:30 UTC (permalink / raw)
To: Greg KH; +Cc: netdev, davem, dwmw2, jeffrey.t.kirsher, linux-kernel
In-Reply-To: <20130111182547.GA22231@kroah.com>
On Fri, Jan 11, 2013 at 10:25 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
>> Most networking dials and knobs can be set using ethtool, ifconfig, ip link
>> commands, or sysfs entries, all of which can be driven by startup scripts
>> and other configuration tools. However, they all depend on having a netdev
>> already set up, and we have some low-level device functionality that needs
>> to be sorted out before we start setting up MSI-x and memory allocations.
> Ick, please don't abuse request_firmware() for this type of thing.
Yeah, it seemed ugly to me at first as well, but it grew on me as I
realized that it does solve a problem in a rather elegant way. While
working this up I discussed this with Mr. Woodhouse thinking that as a
firmware tree maintainer he'd have a similar reaction, but he actually
wasn't opposed to it (David, please speak up if I'm misrepresenting
your comments).
> What's wrong with configfs? It sounds like it will fit your need, and
> that is what is created for.
configfs has similar problems as sysfs - the driver needs to create
the hooks before it has all the info it might need for some hooks,
there is no persistence across reboots, and I don't think it will help
for initrd images. Additionally, there would need to be some userland
mechanism to notice that the hooks were there and to feed it the
startup info. Using a file in the firmware path gives us persistence
and a way for the driver to get info before having to set up
filesystem hooks. It also gives us a way to get special config info
into the boot image. And the whole mechanism already exists,
including UDEV hooks that can do more fancy stuff if needed.
sln
--
==============================================
Mr. Shannon Nelson Parents can't afford to be squeamish.
^ permalink raw reply
* Re: [PATCH 0/3] ixgbe: request_firmware for configuration parameters
From: Greg KH @ 2013-01-11 19:41 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev, davem, dwmw2, jeffrey.t.kirsher, linux-kernel
In-Reply-To: <CAP-MU4MzG_P9fz3_eix=zgzyjijZ5qo1mpKE=r_K7y3xcJqc5Q@mail.gmail.com>
On Fri, Jan 11, 2013 at 11:30:54AM -0800, Shannon Nelson wrote:
> On Fri, Jan 11, 2013 at 10:25 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
> >> Most networking dials and knobs can be set using ethtool, ifconfig, ip link
> >> commands, or sysfs entries, all of which can be driven by startup scripts
> >> and other configuration tools. However, they all depend on having a netdev
> >> already set up, and we have some low-level device functionality that needs
> >> to be sorted out before we start setting up MSI-x and memory allocations.
>
> > Ick, please don't abuse request_firmware() for this type of thing.
>
> Yeah, it seemed ugly to me at first as well, but it grew on me as I
> realized that it does solve a problem in a rather elegant way. While
> working this up I discussed this with Mr. Woodhouse thinking that as a
> firmware tree maintainer he'd have a similar reaction, but he actually
> wasn't opposed to it (David, please speak up if I'm misrepresenting
> your comments).
David maintains the external firmware tree repo, not the in-kernel
firmware core code (which I used to maintain.)
> > What's wrong with configfs? It sounds like it will fit your need, and
> > that is what is created for.
>
> configfs has similar problems as sysfs - the driver needs to create
> the hooks before it has all the info it might need for some hooks,
> there is no persistence across reboots, and I don't think it will help
> for initrd images. Additionally, there would need to be some userland
> mechanism to notice that the hooks were there and to feed it the
> startup info. Using a file in the firmware path gives us persistence
> and a way for the driver to get info before having to set up
> filesystem hooks. It also gives us a way to get special config info
> into the boot image. And the whole mechanism already exists,
> including UDEV hooks that can do more fancy stuff if needed.
Yes, but you are now starting to use "configuration files" for kernel
drivers, which we have resisted for 20+ years for a variety of good
reasons. You can't just ignore all of the arguments to not do this all
of a sudden because you feel your driver is somehow "special" here.
All of the above issues you seem to have with sysfs and configfs can be
resolved with userspace code, and having your driver not do anything to
the hardware until it is told to by userspace.
The boot image problem is harder, but I would argue that your driver
better fall-back to some "known good" configuration for that type of
instance, as you will need to do that anyway if your "firmware" file
isn't present in the first place.
So please try configfs again, the idea of loading configuration files
from the filesystem, no matter what the mechanism, into your driver,
isn't ok to do, sorry.
greg k-h
^ permalink raw reply
* Re: [PATCH v3] net, wireless: overwrite default_ethtool_ops
From: Ben Hutchings @ 2013-01-11 20:00 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: netdev, David S. Miller, Eric Dumazet, Ben Greear,
Bjørn Mork, linux-wireless, Michał Mirosław,
Johannes Berg
In-Reply-To: <20130111091909.GA2347@redhat.com>
On Fri, 2013-01-11 at 10:19 +0100, Stanislaw Gruszka wrote:
> Since:
>
> commit 2c60db037034d27f8c636403355d52872da92f81
> Author: Eric Dumazet <edumazet@google.com>
> Date: Sun Sep 16 09:17:26 2012 +0000
>
> net: provide a default dev->ethtool_ops
>
> wireless core does not correctly assign ethtool_ops.
>
> After alloc_netdev*() call, some cfg80211 drivers provide they own
> ethtool_ops, but some do not. For them, wireless core provide generic
> cfg80211_ethtool_ops, which is assigned in NETDEV_REGISTER notify call:
>
> if (!dev->ethtool_ops)
> dev->ethtool_ops = &cfg80211_ethtool_ops;
>
> But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
> drivers without custom ethtool_ops), but points to &default_ethtool_ops.
>
> In order to fix the problem, provide function which will overwrite
> default_ethtool_ops and use it by wireless core.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
[...]
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
--
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
* [PATCH net-next] ipv4: fib: fix a comment.
From: Rami Rosen @ 2013-01-11 19:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Rami Rosen
In fib_frontend.c, there is a confusing comment; NETLINK_CB(skb).portid does not
refer to a pid of sending process, but rather to a netlink portid.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
net/ipv4/fib_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 5cd75e2..99f00d3 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -974,7 +974,7 @@ static void nl_fib_input(struct sk_buff *skb)
nl_fib_lookup(frn, tb);
- portid = NETLINK_CB(skb).portid; /* pid of sending process */
+ portid = NETLINK_CB(skb).portid; /* netlink portid */
NETLINK_CB(skb).portid = 0; /* from kernel */
NETLINK_CB(skb).dst_group = 0; /* unicast */
netlink_unicast(net->ipv4.fibnl, skb, portid, MSG_DONTWAIT);
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH/RFC] ipv6: fib: Drop cached routes with dead neighbours on fib GC
From: Roland Dreier @ 2013-01-11 21:10 UTC (permalink / raw)
To: David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20130111140119.GC8436@order.stressinduktion.org>
On Fri, Jan 11, 2013 at 6:01 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> The report I meant was actually not referred in this bug report:
> http://article.gmane.org/gmane.linux.network/224832
>
> ENETDOWN was also observed via bridges.
Yes, I would have to think any report of ENETDOWN with ipv6 and
bridging is quite likely to be the same issue I hit.
- R.
^ permalink raw reply
* Re: [PATCH/RFC] ipv6: fib: Drop cached routes with dead neighbours on fib GC
From: Roland Dreier @ 2013-01-11 21:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20130110.141847.265135906896223944.davem@davemloft.net>
On Thu, Jan 10, 2013 at 2:18 PM, David Miller <davem@davemloft.net> wrote:
> Another reason we must make ipv6 like ipv4, which looks up neighbours
> on demand at packet output time rather than caching them in the route
> entries.
Not sure I'm qualified to perform that level of surgery, but I'll take
a look at ipv4 and try to understand how that works.
In the meantime does it make sense to put a smaller bandaid in 3.8?
I'm pretty sure this is a regression (we never saw it with older
kernels), probably due to some part of the route cache improvements
you've been doing.
- R.
^ permalink raw reply
* RE: [PATCH net] qlge: remove NETIF_F_TSO6 flag
From: Jitendra Kalsaria @ 2013-01-11 21:48 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: Ron Mercer, Dept-Eng Linux Driver, David Miller
In-Reply-To: <1357894374-10767-1-git-send-email-amwang@redhat.com>
>From: Cong Wang [mailto:amwang@redhat.com]
>Sent: Friday, January 11, 2013 12:53 AM
>To: netdev
>Cc: Jitendra Kalsaria; Ron Mercer; Dept-Eng Linux Driver; David Miller; Cong Wang
>Subject: [PATCH net] qlge: remove NETIF_F_TSO6 flag
>
>It is werid that qlge driver supports NETIF_F_TSO6 but
>not NETIF_F_IPV6_CSUM. This also causes some kernel warning [1]
>when VLAN device setups on a qlge interface.
>
>I think the qlge hardware doesn't support NETIF_F_IPV6_CSUM,
>so we have to just remove the NETIF_F_TSO6 flag.
>
>After this patch, the TCP/IPv6 traffic becomes normal again,
>no kernel warnings any more.
>
>NOTE: I only tested it on 2.6.32 kernel, even if the upstream
>kernel could fix this automatically (it is hard to track NETIF*
>flags), removing it is also safe.
>
>1. https://bugzilla.redhat.com/show_bug.cgi?id=891839
>
>Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>Cc: Ron Mercer <ron.mercer@qlogic.com>
>Cc: linux-driver@qlogic.com
>Cc: David S. Miller <davem@davemloft.net>
>Signed-off-by: Cong Wang <amwang@redhat.com>
Thanks!
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
^ permalink raw reply
* Re: [PATCH] net: Export __netdev_pick_tx so that it can be used in modules
From: Alexander Duyck @ 2013-01-11 22:20 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, davem
In-Reply-To: <50F061B9.4060703@intel.com>
On 01/11/2013 11:02 AM, John Fastabend wrote:
> On 1/11/2013 10:38 AM, Alexander Duyck wrote:
>> When testing with FCoE enabled we discovered that I had not exported
>> __netdev_pick_tx. As a result ixgbe doesn't build with the RFC patches
>> applied because ixgbe_select_queue was calling the function. This change
>> corrects that build issue by correctly exporting __netdev_pick_tx so it
>> can be used by modules.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> ---
>
> Hi Alex,
>
> If we get XPS to play nicely with the traffic class schemes we
> can just remove select_queue completely.
>
> I'll take a look tomorrow.
>
> Thanks,
> John
Hi John,
It would be great if we could drop it entirely.
I just to make sure we are on the same page. What you are saying is
that we could do that in addition to this patch correct? I'm pretty
sure we will still need this patch in order to make this interface
available for any other drivers that would want to make use of transmit
packet steering instead of just the Tx hash.
Thanks,
Alex
^ permalink raw reply
* [net-next] gianfar: use more portable i/o accessors
From: Kim Phillips @ 2013-01-11 22:18 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
in/out_be32 accessors are Power arch centric whereas
ioread/writebe32 are available in other arches. Also, unlike
in/out_be32, ioread/writebe32 expect non-volatile address arguments.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
index 1b6a67c..91bb2de 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -1136,16 +1136,16 @@ static inline int gfar_has_errata(struct gfar_private *priv,
return priv->errata & err;
}
-static inline u32 gfar_read(volatile unsigned __iomem *addr)
+static inline u32 gfar_read(unsigned __iomem *addr)
{
u32 val;
- val = in_be32(addr);
+ val = ioread32be(addr);
return val;
}
-static inline void gfar_write(volatile unsigned __iomem *addr, u32 val)
+static inline void gfar_write(unsigned __iomem *addr, u32 val)
{
- out_be32(addr, val);
+ iowrite32be(val, addr);
}
static inline void gfar_write_filer(struct gfar_private *priv,
--
1.8.1
^ permalink raw reply related
* Can't build alx driver for hardened 3.7 kernel
From: Norman Shulman @ 2013-01-11 22:37 UTC (permalink / raw)
To: backports, netdev
nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
$ uname -a
Linux nvshp 3.7.0-hardened #4 SMP Wed Jan 9 12:01:45 EST 2013 x86_64
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux
nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
$ ./scripts/driver-select alx
Processing new driver-select request...
Backing up makefile: Makefile.bk
Backup exists: Makefile.bk
Backing up makefile: drivers/net/ethernet/broadcom/Makefile.bk
Backing up makefile: drivers/net/ethernet/atheros/Makefile.bk
Backup exists: Makefile.bk
Backup exists: Makefile.bk
Backup exists: drivers/net/ethernet/broadcom/Makefile.bk
nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
$ make
./scripts/gen-compat-autoconf.sh
/home/nshulman/src/compat-drivers-2013-01-10-2/.config
/home/nshulman/src/compat-drivers-2013-01-10-2/config.mk >
include/linux/compat_autoconf.h
make -C /lib/modules/3.7.0-hardened/build
M=/home/nshulman/src/compat-drivers-2013-01-10-2 modules
make[1]: Entering directory `/usr/src/linux-3.7.0-hardened'
/home/nshulman/src/compat-drivers-2013-01-10-2/config.mk:73: "WARNING:
You are running a kernel >= 2.6.23, you should enable in it
CONFIG_NET_SCHED for 802.11[ne] support"
/home/nshulman/src/compat-drivers-2013-01-10-2/config.mk:252:
"WARNING: CONFIG_CFG80211_WEXT will be deactivated or not working
because kernel was compiled with CONFIG_WIRELESS_EXT=n. Tools using
wext interface like iwconfig will not work. To activate it build your
kernel e.g. with CONFIG_LIBIPW=m."
CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/main.o
CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/compat-3.8.o
CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/cordic.o
CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/crc8.o
LD [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/compat.o
scripts/Makefile.build:44:
/home/nshulman/src/compat-drivers-2013-01-10-2/drivers/net/ethernet/atheros/alx/Makefile:
No such file or directory
make[4]: *** No rule to make target
`/home/nshulman/src/compat-drivers-2013-01-10-2/drivers/net/ethernet/atheros/alx/Makefile'.
Stop.
--
Norman Shulman
Sr. Developer/Architect
N-Dimension Solutions Inc.
9030 Leslie St, Unit 300
Richmond Hill, ON L4B 1G2
Canada
Tel: 905 707-8884 x 226
Fax: 905 707-0886
This email and any files transmitted with it are solely intended for
the use of the named recipient(s) and may contain information that is
privileged and confidential. If you receive this email in error,
please immediately notify the sender and delete this message in all
its forms.
^ permalink raw reply
* Re: Can't build alx driver for hardened 3.7 kernel
From: Richard Farina @ 2013-01-11 22:50 UTC (permalink / raw)
To: Norman Shulman; +Cc: backports, netdev
In-Reply-To: <CANQAqMVMY8Q2B0_2GatohnpBV5cYOY_vNb0owqMfi07ExrtvbA@mail.gmail.com>
On 01/11/2013 05:37 PM, Norman Shulman wrote:
> nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
> $ uname -a
> Linux nvshp 3.7.0-hardened #4 SMP Wed Jan 9 12:01:45 EST 2013 x86_64
> Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux
Looking at that uname I'm guessing gentoo? My team maintains a
compat-drivers ebuild that supports building on hardened. We only do the
stable releases but if it helps, you can find it in the pentoo overlay.
-Zero_Chaos
>
> nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
> $ ./scripts/driver-select alx
> Processing new driver-select request...
> Backing up makefile: Makefile.bk
> Backup exists: Makefile.bk
> Backing up makefile: drivers/net/ethernet/broadcom/Makefile.bk
> Backing up makefile: drivers/net/ethernet/atheros/Makefile.bk
> Backup exists: Makefile.bk
> Backup exists: Makefile.bk
> Backup exists: drivers/net/ethernet/broadcom/Makefile.bk
>
> nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
> $ make
> ./scripts/gen-compat-autoconf.sh
> /home/nshulman/src/compat-drivers-2013-01-10-2/.config
> /home/nshulman/src/compat-drivers-2013-01-10-2/config.mk >
> include/linux/compat_autoconf.h
> make -C /lib/modules/3.7.0-hardened/build
> M=/home/nshulman/src/compat-drivers-2013-01-10-2 modules
> make[1]: Entering directory `/usr/src/linux-3.7.0-hardened'
> /home/nshulman/src/compat-drivers-2013-01-10-2/config.mk:73: "WARNING:
> You are running a kernel >= 2.6.23, you should enable in it
> CONFIG_NET_SCHED for 802.11[ne] support"
> /home/nshulman/src/compat-drivers-2013-01-10-2/config.mk:252:
> "WARNING: CONFIG_CFG80211_WEXT will be deactivated or not working
> because kernel was compiled with CONFIG_WIRELESS_EXT=n. Tools using
> wext interface like iwconfig will not work. To activate it build your
> kernel e.g. with CONFIG_LIBIPW=m."
> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/main.o
> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/compat-3.8.o
> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/cordic.o
> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/crc8.o
> LD [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/compat.o
> scripts/Makefile.build:44:
> /home/nshulman/src/compat-drivers-2013-01-10-2/drivers/net/ethernet/atheros/alx/Makefile:
> No such file or directory
> make[4]: *** No rule to make target
> `/home/nshulman/src/compat-drivers-2013-01-10-2/drivers/net/ethernet/atheros/alx/Makefile'.
> Stop.
>
>
> --
> Norman Shulman
> Sr. Developer/Architect
> N-Dimension Solutions Inc.
> 9030 Leslie St, Unit 300
> Richmond Hill, ON L4B 1G2
> Canada
>
> Tel: 905 707-8884 x 226
> Fax: 905 707-0886
>
> This email and any files transmitted with it are solely intended for
> the use of the named recipient(s) and may contain information that is
> privileged and confidential. If you receive this email in error,
> please immediately notify the sender and delete this message in all
> its forms.
> --
> To unsubscribe from this list: send the line "unsubscribe backports" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Can't build alx driver for hardened 3.7 kernel
From: Norman Shulman @ 2013-01-11 23:21 UTC (permalink / raw)
To: Richard Farina, backports, netdev
In-Reply-To: <50F0973E.9040506@gmail.com>
Gentoo alright. Seems the problem is unrelated to hardened; looks like
they're in the process of renaming alx to atlx and are in an
inconsistent state. If this isn't fixed over the weekend, I'll try the
overlay.
Thanks.
Norm
On Fri, Jan 11, 2013 at 5:50 PM, Richard Farina <sidhayn@gmail.com> wrote:
> On 01/11/2013 05:37 PM, Norman Shulman wrote:
>> nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
>> $ uname -a
>> Linux nvshp 3.7.0-hardened #4 SMP Wed Jan 9 12:01:45 EST 2013 x86_64
>> Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux
>
> Looking at that uname I'm guessing gentoo? My team maintains a
> compat-drivers ebuild that supports building on hardened. We only do the
> stable releases but if it helps, you can find it in the pentoo overlay.
>
> -Zero_Chaos
>>
>> nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
>> $ ./scripts/driver-select alx
>> Processing new driver-select request...
>> Backing up makefile: Makefile.bk
>> Backup exists: Makefile.bk
>> Backing up makefile: drivers/net/ethernet/broadcom/Makefile.bk
>> Backing up makefile: drivers/net/ethernet/atheros/Makefile.bk
>> Backup exists: Makefile.bk
>> Backup exists: Makefile.bk
>> Backup exists: drivers/net/ethernet/broadcom/Makefile.bk
>>
>> nshulman@nvshp:~/src/compat-drivers-2013-01-10-2
>> $ make
>> ./scripts/gen-compat-autoconf.sh
>> /home/nshulman/src/compat-drivers-2013-01-10-2/.config
>> /home/nshulman/src/compat-drivers-2013-01-10-2/config.mk >
>> include/linux/compat_autoconf.h
>> make -C /lib/modules/3.7.0-hardened/build
>> M=/home/nshulman/src/compat-drivers-2013-01-10-2 modules
>> make[1]: Entering directory `/usr/src/linux-3.7.0-hardened'
>> /home/nshulman/src/compat-drivers-2013-01-10-2/config.mk:73: "WARNING:
>> You are running a kernel >= 2.6.23, you should enable in it
>> CONFIG_NET_SCHED for 802.11[ne] support"
>> /home/nshulman/src/compat-drivers-2013-01-10-2/config.mk:252:
>> "WARNING: CONFIG_CFG80211_WEXT will be deactivated or not working
>> because kernel was compiled with CONFIG_WIRELESS_EXT=n. Tools using
>> wext interface like iwconfig will not work. To activate it build your
>> kernel e.g. with CONFIG_LIBIPW=m."
>> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/main.o
>> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/compat-3.8.o
>> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/cordic.o
>> CC [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/crc8.o
>> LD [M] /home/nshulman/src/compat-drivers-2013-01-10-2/compat/compat.o
>> scripts/Makefile.build:44:
>> /home/nshulman/src/compat-drivers-2013-01-10-2/drivers/net/ethernet/atheros/alx/Makefile:
>> No such file or directory
>> make[4]: *** No rule to make target
>> `/home/nshulman/src/compat-drivers-2013-01-10-2/drivers/net/ethernet/atheros/alx/Makefile'.
>> Stop.
>>
>>
>> --
>> Norman Shulman
>> Sr. Developer/Architect
>> N-Dimension Solutions Inc.
>> 9030 Leslie St, Unit 300
>> Richmond Hill, ON L4B 1G2
>> Canada
>>
>> Tel: 905 707-8884 x 226
>> Fax: 905 707-0886
>>
>> This email and any files transmitted with it are solely intended for
>> the use of the named recipient(s) and may contain information that is
>> privileged and confidential. If you receive this email in error,
>> please immediately notify the sender and delete this message in all
>> its forms.
>> --
>> To unsubscribe from this list: send the line "unsubscribe backports" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
Norman Shulman
Sr. Developer/Architect
N-Dimension Solutions Inc.
9030 Leslie St, Unit 300
Richmond Hill, ON L4B 1G2
Canada
Tel: 905 707-8884 x 226
Fax: 905 707-0886
This email and any files transmitted with it are solely intended for
the use of the named recipient(s) and may contain information that is
privileged and confidential. If you receive this email in error,
please immediately notify the sender and delete this message in all
its forms.
^ permalink raw reply
* Re: [PATCH] net: Export __netdev_pick_tx so that it can be used in modules
From: David Miller @ 2013-01-11 23:47 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20130111183842.6152.34578.stgit@ahduyck-cp1.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 11 Jan 2013 10:38:42 -0800
> When testing with FCoE enabled we discovered that I had not exported
> __netdev_pick_tx. As a result ixgbe doesn't build with the RFC patches
> applied because ixgbe_select_queue was calling the function. This change
> corrects that build issue by correctly exporting __netdev_pick_tx so it
> can be used by modules.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH/RFC] ipv6: fib: Drop cached routes with dead neighbours on fib GC
From: David Miller @ 2013-01-11 23:50 UTC (permalink / raw)
To: roland; +Cc: netdev
In-Reply-To: <CAL1RGDVjwddbyVdkzMeXEiqFXQNECjCWAyEFK5V5oAPddfbwZA@mail.gmail.com>
From: Roland Dreier <roland@kernel.org>
Date: Fri, 11 Jan 2013 13:13:42 -0800
> In the meantime does it make sense to put a smaller bandaid in 3.8?
I want it fixed properly from the start, sorry.
> I'm pretty sure this is a regression (we never saw it with older
> kernels), probably due to some part of the route cache improvements
> you've been doing.
I do not believe this is the situation at all.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: fib: fix a comment.
From: David Miller @ 2013-01-11 23:59 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <1357934360-17986-1-git-send-email-ramirose@gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Fri, 11 Jan 2013 21:59:20 +0200
> In fib_frontend.c, there is a confusing comment; NETLINK_CB(skb).portid does not
> refer to a pid of sending process, but rather to a netlink portid.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] qlge: remove NETIF_F_TSO6 flag
From: David Miller @ 2013-01-11 23:59 UTC (permalink / raw)
To: jitendra.kalsaria; +Cc: amwang, netdev, ron.mercer, Linux-Driver
In-Reply-To: <BECD8E8A1B550B48A1BF97C13991F60E03F661@avmb2.qlogic.org>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Date: Fri, 11 Jan 2013 21:48:52 +0000
>
>>From: Cong Wang [mailto:amwang@redhat.com]
>>Sent: Friday, January 11, 2013 12:53 AM
>>To: netdev
>>Cc: Jitendra Kalsaria; Ron Mercer; Dept-Eng Linux Driver; David Miller; Cong Wang
>>Subject: [PATCH net] qlge: remove NETIF_F_TSO6 flag
>>
>>It is werid that qlge driver supports NETIF_F_TSO6 but
>>not NETIF_F_IPV6_CSUM. This also causes some kernel warning [1]
>>when VLAN device setups on a qlge interface.
>>
>>I think the qlge hardware doesn't support NETIF_F_IPV6_CSUM,
>>so we have to just remove the NETIF_F_TSO6 flag.
>>
>>After this patch, the TCP/IPv6 traffic becomes normal again,
>>no kernel warnings any more.
>>
>>NOTE: I only tested it on 2.6.32 kernel, even if the upstream
>>kernel could fix this automatically (it is hard to track NETIF*
>>flags), removing it is also safe.
>>
>>1. https://bugzilla.redhat.com/show_bug.cgi?id=891839
>>
>>Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>>Cc: Ron Mercer <ron.mercer@qlogic.com>
>>Cc: linux-driver@qlogic.com
>>Cc: David S. Miller <davem@davemloft.net>
>>Signed-off-by: Cong Wang <amwang@redhat.com>
>
> Thanks!
> Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Applied.
^ permalink raw reply
* Re: [net-next] gianfar: use more portable i/o accessors
From: David Miller @ 2013-01-11 23:59 UTC (permalink / raw)
To: kim.phillips; +Cc: netdev
In-Reply-To: <20130111161821.d62a0a60ee8d1005fb14b4d5@freescale.com>
From: Kim Phillips <kim.phillips@freescale.com>
Date: Fri, 11 Jan 2013 16:18:21 -0600
> in/out_be32 accessors are Power arch centric whereas
> ioread/writebe32 are available in other arches. Also, unlike
> in/out_be32, ioread/writebe32 expect non-volatile address arguments.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3] net, wireless: overwrite default_ethtool_ops
From: David Miller @ 2013-01-11 23:59 UTC (permalink / raw)
To: bhutchings-s/n/eUQHGBpZroRs9YW3xA
Cc: sgruszka-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, greearb-my8/4N5VtI7c+919tysfdA,
bjorn-yOkvZcmFvRU, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
mirqus-Re5JQEeQqe8AvxtiuMwx3w, johannes-cdvu00un1VgdHxzADdlk8Q
In-Reply-To: <1357934432.2643.4.camel-/LGg1Z1CJKReKY3V0RtoKmatzQS1i7+A3tAM5lWOD0I@public.gmane.org>
From: Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
Date: Fri, 11 Jan 2013 20:00:32 +0000
> On Fri, 2013-01-11 at 10:19 +0100, Stanislaw Gruszka wrote:
>> Since:
>>
>> commit 2c60db037034d27f8c636403355d52872da92f81
>> Author: Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> Date: Sun Sep 16 09:17:26 2012 +0000
>>
>> net: provide a default dev->ethtool_ops
>>
>> wireless core does not correctly assign ethtool_ops.
>>
>> After alloc_netdev*() call, some cfg80211 drivers provide they own
>> ethtool_ops, but some do not. For them, wireless core provide generic
>> cfg80211_ethtool_ops, which is assigned in NETDEV_REGISTER notify call:
>>
>> if (!dev->ethtool_ops)
>> dev->ethtool_ops = &cfg80211_ethtool_ops;
>>
>> But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
>> drivers without custom ethtool_ops), but points to &default_ethtool_ops.
>>
>> In order to fix the problem, provide function which will overwrite
>> default_ethtool_ops and use it by wireless core.
>>
>> Signed-off-by: Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> [...]
>
> Acked-by: Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH net-next] networking/cs89x0.txt: delete stale information about hand patching
From: Paul Gortmaker @ 2013-01-12 0:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Paul Gortmaker
Output of a git grep happened to make me look into this file, and
I found instructions about how to hand patch (without using patch)
the driver into the kernel tree.
Since the driver has been a part of the mainline kernel for years,
we can dump this whole section. Fortunately it doesn't even cause
a renumbering of the sections to do so.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Documentation/networking/cs89x0.txt | 78 -------------------------------------
1 file changed, 78 deletions(-)
diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt
index c725d33..2ede91f 100644
--- a/Documentation/networking/cs89x0.txt
+++ b/Documentation/networking/cs89x0.txt
@@ -364,84 +364,6 @@ The compile-time optionality for DMA was removed in the 2.3 kernel
series. DMA support is now unconditionally part of the driver. It is
enabled by the 'use_dma=1' module option.
-4.4 COMPILING THE DRIVER INTO THE KERNEL
-
-If your Linux distribution already has support for the cs89x0 driver
-then simply copy the source file to the /usr/src/linux/drivers/net
-directory to replace the original ones and run the make utility to
-rebuild the kernel. See Step 3 for rebuilding the kernel.
-
-If your Linux does not include the cs89x0 driver, you need to edit three
-configuration files, copy the source file to the /usr/src/linux/drivers/net
-directory, and then run the make utility to rebuild the kernel.
-
-1. Edit the following configuration files by adding the statements as
-indicated. (When possible, try to locate the added text to the section of the
-file containing similar statements).
-
-
-a.) In /usr/src/linux/drivers/net/Config.in, add:
-
-tristate 'CS89x0 support' CONFIG_CS89x0
-
-Example:
-
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
- tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
- fi
-
- tristate 'CS89x0 support' CONFIG_CS89x0
-
- tristate 'NE2000/NE1000 support' CONFIG_NE2000
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
- tristate 'NI5210 support' CONFIG_NI52
-
-
-b.) In /usr/src/linux/drivers/net/Makefile, add the following lines:
-
-ifeq ($(CONFIG_CS89x0),y)
-L_OBJS += cs89x0.o
-else
- ifeq ($(CONFIG_CS89x0),m)
- M_OBJS += cs89x0.o
- endif
-endif
-
-
-c.) In /linux/drivers/net/Space.c file, add the line:
-
-extern int cs89x0_probe(struct device *dev);
-
-
-Example:
-
- extern int ultra_probe(struct device *dev);
- extern int wd_probe(struct device *dev);
- extern int el2_probe(struct device *dev);
-
- extern int cs89x0_probe(struct device *dev);
-
- extern int ne_probe(struct device *dev);
- extern int hp_probe(struct device *dev);
- extern int hp_plus_probe(struct device *dev);
-
-
-Also add:
-
- #ifdef CONFIG_CS89x0
- { cs89x0_probe,0 },
- #endif
-
-
-2.) Copy the driver source files (cs89x0.c and cs89x0.h)
-into the /usr/src/linux/drivers/net directory.
-
-
-3.) Go to /usr/src/linux directory and run 'make config' followed by 'make'
-(or make bzImage) to rebuild the kernel.
-
-4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
-
5.0 TESTING AND TROUBLESHOOTING
===============================================================================
--
1.8.1
^ permalink raw reply related
* Re: [RFCv2 00/12] Introduce host-side virtio queue and CAIF Virtio.
From: Rusty Russell @ 2013-01-12 0:20 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, Linus Walleij, virtualization
In-Reply-To: <20130111073155.GA13315@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Fri, Jan 11, 2013 at 09:18:33AM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> > On Thu, Jan 10, 2013 at 09:00:55PM +1030, Rusty Russell wrote:
>> >> Not sure why vhost/net doesn't built a packet and feed it in
>> >> netif_rx_ni(). This is what tun seems to do, and with this code it
>> >> should be fairly optimal.
>> >
>> > Because we want to use NAPI.
>>
>> Not quite what I was asking; it was more a question of why we're using a
>> raw socket, when we trivially have a complete skb already which we
>> should be able to feed to Linux like any network packet.
>
> Oh for some reason I thought you were talking about virtio.
> I don't really understand what you are saying here - vhost
> actually calls out to tun to build and submit the skb.
Ah, the fd is tun? Seems a bit indirect; I wonder if there's room for
more optimization here...
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH net-next] networking/cs89x0.txt: delete stale information about hand patching
From: David Miller @ 2013-01-12 0:31 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev
In-Reply-To: <1357949976-11463-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 11 Jan 2013 19:19:36 -0500
> Output of a git grep happened to make me look into this file, and
> I found instructions about how to hand patch (without using patch)
> the driver into the kernel tree.
>
> Since the driver has been a part of the mainline kernel for years,
> we can dump this whole section. Fortunately it doesn't even cause
> a renumbering of the sections to do so.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
When removing a section you should fix up the numbers of the
remaining sections and any cross references within.
^ permalink raw reply
* Re: [PATCH net-next] networking/cs89x0.txt: delete stale information about hand patching
From: Paul Gortmaker @ 2013-01-12 0:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130111.163112.1015838278440673633.davem@davemloft.net>
[Re: [PATCH net-next] networking/cs89x0.txt: delete stale information about hand patching] On 11/01/2013 (Fri 16:31) David Miller wrote:
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Fri, 11 Jan 2013 19:19:36 -0500
>
> > Output of a git grep happened to make me look into this file, and
> > I found instructions about how to hand patch (without using patch)
> > the driver into the kernel tree.
> >
> > Since the driver has been a part of the mainline kernel for years,
> > we can dump this whole section. Fortunately it doesn't even cause
> > a renumbering of the sections to do so.
> >
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> When removing a section you should fix up the numbers of the
> remaining sections and any cross references within.
Ah crap, I was so glad that I didn't have to renumber anything, that
I did forget to delete the dangling TOC entry; thanks for spotting
that, and sorry for the v2 on something so trivial.
P.
--
>From d21b48a100d9c0e8f102b38a6e6dbeeb39f98b94 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 11 Jan 2013 19:00:36 -0500
Subject: [PATCH net-next v2] networking/cs89x0.txt: delete stale information
about hand patching
Output of a git grep happened to make me look into this file, and
I found instructions about how to hand patch (without using patch)
the driver into the kernel tree.
Since the driver has been a part of the mainline kernel for years,
we can dump this whole section. Fortunately it doesn't even cause
a renumbering of the sections to do so.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[v2: also delete the TOC entry for section 4.4]
Documentation/networking/cs89x0.txt | 79 -------------------------------------
1 file changed, 79 deletions(-)
diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt
index c725d33..0e19018 100644
--- a/Documentation/networking/cs89x0.txt
+++ b/Documentation/networking/cs89x0.txt
@@ -36,7 +36,6 @@ TABLE OF CONTENTS
4.1 Compiling the Driver as a Loadable Module
4.2 Compiling the driver to support memory mode
4.3 Compiling the driver to support Rx DMA
- 4.4 Compiling the Driver into the Kernel
5.0 TESTING AND TROUBLESHOOTING
5.1 Known Defects and Limitations
@@ -364,84 +363,6 @@ The compile-time optionality for DMA was removed in the 2.3 kernel
series. DMA support is now unconditionally part of the driver. It is
enabled by the 'use_dma=1' module option.
-4.4 COMPILING THE DRIVER INTO THE KERNEL
-
-If your Linux distribution already has support for the cs89x0 driver
-then simply copy the source file to the /usr/src/linux/drivers/net
-directory to replace the original ones and run the make utility to
-rebuild the kernel. See Step 3 for rebuilding the kernel.
-
-If your Linux does not include the cs89x0 driver, you need to edit three
-configuration files, copy the source file to the /usr/src/linux/drivers/net
-directory, and then run the make utility to rebuild the kernel.
-
-1. Edit the following configuration files by adding the statements as
-indicated. (When possible, try to locate the added text to the section of the
-file containing similar statements).
-
-
-a.) In /usr/src/linux/drivers/net/Config.in, add:
-
-tristate 'CS89x0 support' CONFIG_CS89x0
-
-Example:
-
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
- tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
- fi
-
- tristate 'CS89x0 support' CONFIG_CS89x0
-
- tristate 'NE2000/NE1000 support' CONFIG_NE2000
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
- tristate 'NI5210 support' CONFIG_NI52
-
-
-b.) In /usr/src/linux/drivers/net/Makefile, add the following lines:
-
-ifeq ($(CONFIG_CS89x0),y)
-L_OBJS += cs89x0.o
-else
- ifeq ($(CONFIG_CS89x0),m)
- M_OBJS += cs89x0.o
- endif
-endif
-
-
-c.) In /linux/drivers/net/Space.c file, add the line:
-
-extern int cs89x0_probe(struct device *dev);
-
-
-Example:
-
- extern int ultra_probe(struct device *dev);
- extern int wd_probe(struct device *dev);
- extern int el2_probe(struct device *dev);
-
- extern int cs89x0_probe(struct device *dev);
-
- extern int ne_probe(struct device *dev);
- extern int hp_probe(struct device *dev);
- extern int hp_plus_probe(struct device *dev);
-
-
-Also add:
-
- #ifdef CONFIG_CS89x0
- { cs89x0_probe,0 },
- #endif
-
-
-2.) Copy the driver source files (cs89x0.c and cs89x0.h)
-into the /usr/src/linux/drivers/net directory.
-
-
-3.) Go to /usr/src/linux directory and run 'make config' followed by 'make'
-(or make bzImage) to rebuild the kernel.
-
-4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
-
5.0 TESTING AND TROUBLESHOOTING
===============================================================================
--
1.8.1
^ permalink raw reply related
* [PATCH net-next] net: splice: fix __splice_segment()
From: Eric Dumazet @ 2013-01-12 0:46 UTC (permalink / raw)
To: Willy Tarreau, David Miller; +Cc: netdev
In-Reply-To: <1357831787.27446.2168.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
commit 9ca1b22d6d2 (net: splice: avoid high order page splitting)
forgot that skb->head could need a copy into several page frags.
This could be the case for loopback traffic mostly.
Also remove now useless skb argument from linear_to_page()
and __splice_segment() prototypes.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willy Tarreau <w@1wt.eu>
---
net/core/skbuff.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 1e1b9ea..2568c44 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1652,7 +1652,7 @@ static void sock_spd_release(struct splice_pipe_desc *spd, unsigned int i)
static struct page *linear_to_page(struct page *page, unsigned int *len,
unsigned int *offset,
- struct sk_buff *skb, struct sock *sk)
+ struct sock *sk)
{
struct page_frag *pfrag = sk_page_frag(sk);
@@ -1685,14 +1685,14 @@ static bool spd_can_coalesce(const struct splice_pipe_desc *spd,
static bool spd_fill_page(struct splice_pipe_desc *spd,
struct pipe_inode_info *pipe, struct page *page,
unsigned int *len, unsigned int offset,
- struct sk_buff *skb, bool linear,
+ bool linear,
struct sock *sk)
{
if (unlikely(spd->nr_pages == MAX_SKB_FRAGS))
return true;
if (linear) {
- page = linear_to_page(page, len, &offset, skb, sk);
+ page = linear_to_page(page, len, &offset, sk);
if (!page)
return true;
}
@@ -1711,13 +1711,11 @@ static bool spd_fill_page(struct splice_pipe_desc *spd,
static bool __splice_segment(struct page *page, unsigned int poff,
unsigned int plen, unsigned int *off,
- unsigned int *len, struct sk_buff *skb,
+ unsigned int *len,
struct splice_pipe_desc *spd, bool linear,
struct sock *sk,
struct pipe_inode_info *pipe)
{
- unsigned int flen;
-
if (!*len)
return true;
@@ -1732,12 +1730,16 @@ static bool __splice_segment(struct page *page, unsigned int poff,
plen -= *off;
*off = 0;
- flen = min(*len, plen);
-
- if (spd_fill_page(spd, pipe, page, &flen, poff, skb, linear, sk))
- return true;
+ do {
+ unsigned int flen = min(*len, plen);
- *len -= flen;
+ if (spd_fill_page(spd, pipe, page, &flen, poff,
+ linear, sk))
+ return true;
+ poff += flen;
+ plen -= flen;
+ *len -= flen;
+ } while (*len && plen);
return false;
}
@@ -1760,7 +1762,7 @@ static bool __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info *pipe,
if (__splice_segment(virt_to_page(skb->data),
(unsigned long) skb->data & (PAGE_SIZE - 1),
skb_headlen(skb),
- offset, len, skb, spd,
+ offset, len, spd,
skb_head_is_locked(skb),
sk, pipe))
return true;
@@ -1773,7 +1775,7 @@ static bool __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info *pipe,
if (__splice_segment(skb_frag_page(f),
f->page_offset, skb_frag_size(f),
- offset, len, skb, spd, false, sk, pipe))
+ offset, len, spd, false, sk, pipe))
return true;
}
^ permalink raw reply related
* Re: [PATCH net-next] networking/cs89x0.txt: delete stale information about hand patching
From: David Miller @ 2013-01-12 0:47 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev
In-Reply-To: <20130112004558.GB4625@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 11 Jan 2013 19:45:58 -0500
> [Re: [PATCH net-next] networking/cs89x0.txt: delete stale information about hand patching] On 11/01/2013 (Fri 16:31) David Miller wrote:
>
>> From: Paul Gortmaker <paul.gortmaker@windriver.com>
>> Date: Fri, 11 Jan 2013 19:19:36 -0500
>>
>> > Output of a git grep happened to make me look into this file, and
>> > I found instructions about how to hand patch (without using patch)
>> > the driver into the kernel tree.
>> >
>> > Since the driver has been a part of the mainline kernel for years,
>> > we can dump this whole section. Fortunately it doesn't even cause
>> > a renumbering of the sections to do so.
>> >
>> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>
>> When removing a section you should fix up the numbers of the
>> remaining sections and any cross references within.
>
> Ah crap, I was so glad that I didn't have to renumber anything, that
> I did forget to delete the dangling TOC entry; thanks for spotting
> that, and sorry for the v2 on something so trivial.
Section 5 is still numbered 5, you didn't renumber the sections after
the one you are removing, as I asked you to.
^ 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