* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: David Miller @ 2011-06-11 23:29 UTC (permalink / raw)
To: marius.kotsbak; +Cc: netdev, linux-usb, marius
In-Reply-To: <20110611.162711.907394751613071878.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 11 Jun 2011 16:27:11 -0700 (PDT)
> From: "Marius B. Kotsbak" <marius.kotsbak@gmail.com>
> Date: Sat, 11 Jun 2011 23:55:18 +0200
>
>> Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
>> It has also an ACM interface that previous patches associates with the "option"
>> module. To access those interfaces, the modem must first be switched from modem
>> mode using a tool like usb_modeswitch.
>>
>> As the proprietary protocol has been discovered by watching the MS Windows driver
>> behavior, there might be errors in the protocol handling, but stable and fast
>> connection has been established for hours with Norwegian operator NetCom that
>> distributes this modem with their LTE/4G subscription.
>>
>> More and updated information about how to use this driver is available here:
>>
>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
>> https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
>>
>> Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
>
> Applied, thanks.
Actually, reverted.
There's a typo in your Makefile patch, and because of this it
won't even build the new driver.
People are so damn anxious to get this backported into stable
and various distributions, yet this patch wasn't even tested
properly.
That really drives me crazy.
^ permalink raw reply
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: David Miller @ 2011-06-11 23:27 UTC (permalink / raw)
To: marius.kotsbak; +Cc: netdev, linux-usb, marius
In-Reply-To: <1307829318-18246-1-git-send-email-marius@kotsbak.com>
From: "Marius B. Kotsbak" <marius.kotsbak@gmail.com>
Date: Sat, 11 Jun 2011 23:55:18 +0200
> Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
> It has also an ACM interface that previous patches associates with the "option"
> module. To access those interfaces, the modem must first be switched from modem
> mode using a tool like usb_modeswitch.
>
> As the proprietary protocol has been discovered by watching the MS Windows driver
> behavior, there might be errors in the protocol handling, but stable and fast
> connection has been established for hours with Norwegian operator NetCom that
> distributes this modem with their LTE/4G subscription.
>
> More and updated information about how to use this driver is available here:
>
> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
> https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
>
> Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 5/5] net: ep93xx_eth: fix DMA API violations
From: David Miller @ 2011-06-11 23:26 UTC (permalink / raw)
To: mika.westerberg; +Cc: netdev, linux-arm-kernel, hsweeten, rmallon, ynezz
In-Reply-To: <d1ab2a21856804a430be57469595d5c1f7cb936c.1307816881.git.mika.westerberg@iki.fi>
From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sat, 11 Jun 2011 21:39:58 +0300
> Russell King said:
>>
>> So, to summarize what its doing:
>>
>> 1. It allocates buffers for rx and tx.
>> 2. It maps them with dma_map_single().
>> This transfers ownership of the buffer to the DMA device.
>> 3. In ep93xx_xmit,
>> 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
>> This violates the DMA buffer ownership rules - the CPU should
>> not be writing to this buffer while it is (in principle) owned
>> by the DMA device.
>> 3b. It then calls dma_sync_single_for_cpu() for the buffer.
>> This transfers ownership of the buffer to the CPU, which surely
>> is the wrong direction.
>> 4. In ep93xx_rx,
>> 4a. It calls dma_sync_single_for_cpu() for the buffer.
>> This at least transfers the DMA buffer ownership to the CPU
>> before the CPU reads the buffer
>> 4b. It then uses skb_copy_to_linear_data() to copy the data out.
>> At no point does it transfer ownership back to the DMA device.
>> 5. When the driver is removed, it dma_unmap_single()'s the buffer.
>> This transfers ownership of the buffer to the CPU.
>> 6. It frees the buffer.
>>
>> While it may work on ep93xx, it's not respecting the DMA API rules,
>> and with DMA debugging enabled it will probably encounter quite a few
>> warnings.
>
> This patch fixes these violations.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Tested-by: Petr Stetiar <ynezz@true.cz>
Applied.
^ permalink raw reply
* Re: [PATCH v3 4/5] net: ep93xx_eth: drop GFP_DMA from call to dma_alloc_coherent()
From: David Miller @ 2011-06-11 23:25 UTC (permalink / raw)
To: mika.westerberg; +Cc: netdev, linux-arm-kernel, hsweeten, rmallon, ynezz
In-Reply-To: <6f1c0ce5bbc0c36ce509d6503363c5e9ee3f626b.1307816881.git.mika.westerberg@iki.fi>
From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sat, 11 Jun 2011 21:39:57 +0300
> Commit a197b59ae6e8 (mm: fail GFP_DMA allocations when ZONE_DMA is not
> configured) made page allocator to return NULL if GFP_DMA is set but
> CONFIG_ZONE_DMA is disabled.
>
> This causes ep93xx_eth to fail:
>
> WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
> Modules linked in:
> [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
> [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
> [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
> [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
> [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
> [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
> [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
> [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
> [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
> [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
> [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
> [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
> [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)
>
> Since there is no restrictions for DMA on ep93xx, we can fix this by just
> removing the GFP_DMA flag from the call.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Tested-by: Petr Stetiar <ynezz@true.cz>
Applied.
^ permalink raw reply
* Re: [PATCH v3 3/5] net: ep93xx_eth: allocate buffers using kmalloc()
From: David Miller @ 2011-06-11 23:25 UTC (permalink / raw)
To: mika.westerberg; +Cc: netdev, linux-arm-kernel, hsweeten, rmallon, ynezz
In-Reply-To: <511e0ae99e245fccb4692e7bb51944575f1b3287.1307816881.git.mika.westerberg@iki.fi>
From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sat, 11 Jun 2011 21:39:56 +0300
> We can use simply kmalloc() to allocate the buffers. This also simplifies the
> code and allows us to perform DMA sync operations more easily.
>
> Memory is allocated with only GFP_KERNEL since there are no DMA allocation
> restrictions on this platform.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Tested-by: Petr Stetiar <ynezz@true.cz>
Applied.
^ permalink raw reply
* Re: [PATCH v3 2/5] net: ep93xx_eth: pass struct device to DMA API functions
From: David Miller @ 2011-06-11 23:25 UTC (permalink / raw)
To: mika.westerberg; +Cc: netdev, linux-arm-kernel, hsweeten, rmallon, ynezz
In-Reply-To: <b69ec17080017f62baaa94bc1d21960022dc7381.1307816881.git.mika.westerberg@iki.fi>
From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sat, 11 Jun 2011 21:39:55 +0300
> We shouldn't use NULL for any DMA API functions, unless we are dealing with
> ISA or EISA device. So pass correct struct dev pointer to these functions.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Applied.
^ permalink raw reply
* Re: [PATCH v3 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: David Miller @ 2011-06-11 23:25 UTC (permalink / raw)
To: mika.westerberg; +Cc: netdev, linux-arm-kernel, hsweeten, rmallon, ynezz
In-Reply-To: <a908e30a30247a07b2352002742f291d1df0eb18.1307816881.git.mika.westerberg@iki.fi>
From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sat, 11 Jun 2011 21:39:54 +0300
> Since the driver uses the DMA API, we should pass it valid DMA masks.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Tested-by: Petr Stetiar <ynezz@true.cz>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] snmp: reduce percpu needs by 50%
From: David Miller @ 2011-06-11 23:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, andi, linux-kernel, benh, mingo, tj, cl, linux-arch
In-Reply-To: <1307771151.2872.72.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 11 Jun 2011 07:45:51 +0200
> SNMP mibs use two percpu arrays, one used in BH context, another in USER
> context. With increasing number of cpus in machines, and fact that ipv6
> uses per network device ipstats_mib, this is consuming a lot of memory
> if many network devices are registered.
>
> commit be281e554e2a (ipv6: reduce per device ICMP mib sizes) shrinked
> percpu needs for ipv6, but we can reduce memory use a bit more.
>
> With recent percpu infrastructure (irqsafe_cpu_inc() ...), we no longer
> need this BH/USER separation since we can update counters in a single
> x86 instruction, regardless of the BH/USER context.
>
> Other arches than x86 might need to disable irq in their
> irqsafe_cpu_inc() implementation : If this happens to be a problem, we
> can make SNMP_ARRAY_SZ arch dependent, but a previous poll
> ( https://lkml.org/lkml/2011/3/17/174 ) to arch maintainers did not
> raise strong opposition.
>
> Only on 32bit arches, we need to disable BH for 64bit counters updates
> done from USER context (currently used for IP MIB)
>
> This also reduces vmlinux size :
>
> 1) x86_64 build
> $ size vmlinux.before vmlinux.after
> text data bss dec hex filename
> 7853650 1293772 1896448 11043870 a8841e vmlinux.before
> 7850578 1293772 1896448 11040798 a8781e vmlinux.after
>
> 2) i386 build
> $ size vmlinux.before vmlinux.afterpatch
> text data bss dec hex filename
> 6039335 635076 3670016 10344427 9dd7eb vmlinux.before
> 6037342 635076 3670016 10342434 9dd022 vmlinux.afterpatch
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks good to me, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 2/2] bonding: restore NETIF_F_VLAN_CHALLENGED properly in bond_del_vlan()
From: David Miller @ 2011-06-11 23:13 UTC (permalink / raw)
To: jbohac; +Cc: fubar, andy, netdev, pedro.netdev, kaber, mirq-linux
In-Reply-To: <20110610202720.GA4256@midget.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Fri, 10 Jun 2011 22:27:20 +0200
> bonding: clean up bond_del_vlan()
>
> 1) the setting of NETIF_F_VLAN_CHALLENGED in bond_del_vlan() is
> useless since commit b2a103e6 because bond_fix_features() now
> sets NETIF_F_VLAN_CHALLENGED whenever the last slave is being
> removed.
>
> 2) the code never triggers anyway as vlan_list is never empty
> since ad1afb00.
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check
From: David Miller @ 2011-06-11 23:16 UTC (permalink / raw)
To: xiaosuo
Cc: jpirko, pratnakarlx, ebiederm, shemminger, greearb,
nicolas.2p.debian, netdev, kaber, fubar, eric.dumazet, andy,
jesse
In-Reply-To: <BANLkTi=LeDecHK4x+6qa-q2h5Duub4zoTg@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Sat, 11 Jun 2011 08:05:37 +0800
> On Sat, Jun 11, 2011 at 12:56 AM, Jiri Pirko <jpirko@redhat.com> wrote:
>> This time heavily based on Eric's V2. mac_len is reset at appropriate
>> places. Also skb->data is adjusted to point to beginning of mac header
>> before calling vlan_insert_tag.
>>
>> Please review (fingers crossed).
>>
>> Subject: [patch net-2.6 v2.1] vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check
>>
>> Testing of VLAN_FLAG_REORDER_HDR does not belong in vlan_untag
>> but rather in vlan_do_receive. Otherwise the vlan header
>> will not be properly put on the packet in the case of
>> vlan header accelleration.
>>
>> As we remove the check from vlan_check_reorder_header
>> rename it vlan_reorder_header to keep the naming clean.
>>
>> Fix up the skb->pkt_type early so we don't look at the packet
>> after adding the vlan tag, which guarantees we don't goof
>> and look at the wrong field.
>>
>> Use a simple if statement instead of a complicated switch
>> statement to decided that we need to increment rx_stats
>> for a multicast packet.
>>
>> Hopefully at somepoint we will just declare the case where
>> VLAN_FLAG_REORDER_HDR is cleared as unsupported and remove
>> the code. Until then this keeps it working correctly.
>>
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> Acked-by: Changli Gao <xiaosuo@gmail.com>
Applied, great work everyone.
^ permalink raw reply
* Re: [PATCH 01/10] net: introduce time stamping wrapper for netif_rx.
From: David Miller @ 2011-06-11 23:10 UTC (permalink / raw)
To: shemminger; +Cc: richardcochran, netdev
In-Reply-To: <20110610111924.54fede19@nehalam.ftrdhcpuser.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 10 Jun 2011 11:19:24 -0700
> On Fri, 10 Jun 2011 19:27:47 +0200
> Richard Cochran <richardcochran@gmail.com> wrote:
>
>> On Fri, Jun 10, 2011 at 08:20:56AM -0700, Stephen Hemminger wrote:
>> > On Fri, 10 Jun 2011 17:06:59 +0200
>> > Richard Cochran <richardcochran@gmail.com> wrote:
>> >
>> > > +static inline int netif_rx_defer(struct sk_buff *skb)
>> > > +{
>> > > + if (skb_defer_rx_timestamp(skb))
>> > > + return NET_RX_SUCCESS;
>> > > + return netif_rx(skb);
>> > > +}
>> >
>> > Obvious question why not just put this in netif_rx.
>>
>> Well, if a packet gets defered, then that means that the PHY driver
>> has decided to hold the packet until it obtains the time stamp from
>> the PHY hardware. Then, the driver delivers the packet using netif_rx.
>>
>> So, we need to have two methods to deliver a frame, one with and one
>> without the hook, otherwise you get packets going round in circles.
>>
>> Take a look at the one PHY driver using this (so far), on line 1017 of
>> drivers/net/phy/dp83640.c, to see how it works.
>>
>> Thanks,
>> Richard
>>
>> PS I did consider at renaming netif_rx to __netif_rx and then
>> implementing netif_rx as shown above, but I found many, many callers
>> of netif_rx which are not drivers, so I worry that bad side effects
>> would appear from such a change.
>
> Why not use a timestamp present flag like the receive hashing code
> already does.
I agree with Stephen that we should be decreasing the number of driver
interfaces not increasing them.
Also, it makes no sense to add this for obsolete RX processing such
that netif_rx() is.
If drivers want to add fancy features like this timestamping stuff,
they better move on to NAPI, GRO, etc. first. Putting support for
new features into deprecating things like netif_rx() makes no
sense at all.
^ permalink raw reply
* Re: [PATCH v2] dl2k: EEPROM CRC calculation wrong endianess on bigendian machine
From: David Miller @ 2011-06-11 23:02 UTC (permalink / raw)
To: daniel; +Cc: netdev, bhutchings
In-Reply-To: <1307717716-13668-1-git-send-email-daniel@gaisler.com>
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Fri, 10 Jun 2011 16:55:16 +0200
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: fix MIPS fallout from "net: remove interrupt.h inclusion from netdevice.h"
From: David Miller @ 2011-06-11 23:00 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20110610133642.GA7451@p183.telecom.by>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri, 10 Jun 2011 16:36:43 +0300
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] be2net: Enable NETIF_F_TSO6 for VLAN traffic for BE
From: David Miller @ 2011-06-11 22:58 UTC (permalink / raw)
To: padmanabh.ratnakar; +Cc: netdev
In-Reply-To: <5c1f3a19-f30f-40b4-8715-86348d7917c5@exht1.ad.emulex.com>
From: Padmanabh Ratnakar <padmanabh.ratnakar@Emulex.Com>
Date: Fri, 10 Jun 2011 16:31:48 +0530
> NETIF_F_TSO6 for VLAN packets was not enabled for BE adapters.
> Enabling it.
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] virtio_net: introduce VIRTIO_NET_HDR_F_DATA_VALID
From: David Miller @ 2011-06-11 22:58 UTC (permalink / raw)
To: mst
Cc: jasowang, rusty, netdev, linux-kernel, virtualization, yvugenfi,
kvm, herbert
In-Reply-To: <20110610112828.GA21037@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 10 Jun 2011 14:28:28 +0300
> On Fri, Jun 10, 2011 at 06:56:17PM +0800, Jason Wang wrote:
>> There's no need for the guest to validate the checksum if it have been
>> validated by host nics. So this patch introduces a new flag -
>> VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum
>> examing in guest. The backend (tap/macvtap) may set this flag when
>> met skbs with CHECKSUM_UNNECESSARY to save cpu utilization.
>>
>> No feature negotiation is needed as old driver just ignore this flag.
>
> This wasn't required by the spec, but maybe it should be.
>
>> Iperf shows 12%-30% performance improvement for UDP traffic. For TCP,
>> when gro is on no difference as it produces skb with partial
>> checksum. But when gro is disabled, 20% or even higher improvement
>> could be measured by netperf.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 0/3] Fixes for ARM/ebsa110 am79c961 driver
From: David Miller @ 2011-06-11 22:56 UTC (permalink / raw)
To: rmk; +Cc: netdev
In-Reply-To: <20110610105122.GA27087@flint.arm.linux.org.uk>
From: Russell King <rmk@arm.linux.org.uk>
Date: Fri, 10 Jun 2011 11:51:22 +0100
> This series of patches fix some of the more serious issues discovered
> with GCC 4 and the ARM EBSA110 am79c961 ethernet driver last weekend
> while upgrading my firewall to 2.6.39.
All applied to net-2.6, thanks Russell.
^ permalink raw reply
* Re: [PATCH] net: DM9000: Add support for byte EEPROM access
From: David Miller @ 2011-06-11 22:55 UTC (permalink / raw)
To: broonie; +Cc: netdev, ben-linux
In-Reply-To: <1307703032-20349-1-git-send-email-broonie@opensource.wolfsonmicro.com>
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Fri, 10 Jun 2011 11:50:32 +0100
> From: Ben Dooks <ben-linux@fluff.org>
>
> Given many versions of ethtool's reluctance to do anything other than
> byte accesses to the EEPROM interface, it is easier to update the driver
> to support byte accesses so that all the ethtool versions that have been
> observed in Debian can write the EEPROM.
>
> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH v1] sctp: kzalloc() error handling on deleting last address
From: David Miller @ 2011-06-11 22:54 UTC (permalink / raw)
To: micchie; +Cc: yjwei, netdev
In-Reply-To: <42280E6C-8514-4C01-9B81-35DDE65BBE42@sfc.wide.ad.jp>
From: Michio Honda <micchie@sfc.wide.ad.jp>
Date: Fri, 10 Jun 2011 18:06:15 +0900
>>From be2da529aa45061e77ad96313175e141aaadc16a Mon Sep 17 00:00:00 2001
> From: Michio Honda <micchie@sfc.wide.ad.jp>
> Date: Fri, 10 Jun 2011 16:42:14 +0900
> Subject: [PATCH v1] sctp: kzalloc() error handling on deleting last address
>
> Signed-off-by: Michio Honda <micchie@sfc.wide.ad.jp>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] net: add Faraday FTGMAC100 Gigabit Ethernet driver
From: David Miller @ 2011-06-11 22:50 UTC (permalink / raw)
To: ratbert.chuang; +Cc: netdev, linux-kernel, eric.dumazet, ratbert
In-Reply-To: <1307611968-1595-1-git-send-email-ratbert.chuang@gmail.com>
From: Po-Yu Chuang <ratbert.chuang@gmail.com>
Date: Thu, 9 Jun 2011 17:32:48 +0800
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>
> FTGMAC100 Ethernet Media Access Controller supports 10/100/1000 Mbps
> and MII/GMII. This driver has been working on some ARM/NDS32 SoC's
> including Faraday A369 and Andes AG102.
>
> Signed-off-by: Po-Yu Chuang <ratbert@faraday-tech.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Greg KH @ 2011-06-11 22:40 UTC (permalink / raw)
To: Marius Kotsbak
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius B. Kotsbak
In-Reply-To: <4DF3E4E1.2070309-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Jun 11, 2011 at 11:57:53PM +0200, Marius Kotsbak wrote:
> On 11. juni 2011 22:06, Greg KH wrote:
> >>>> > >> + * This program is distributed in the hope that it will be useful,
> >>>> > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>>> > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>>> > >> + * GNU General Public License for more details.
> >>>> > >> + *
> >>>> > >> + * You should have received a copy of the GNU General Public License
> >>>> > >> + * along with this program; if not, write to the Free Software
> >>>> > >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> >>> > > These two paragraphs are not needed, and unless you want to track the
> >>> > > FSF's office changes for the next 40+ years, I'd really suggest not
> >>> > > putting it in there at all.
> >>> > >
> >> >
> >> > Same here, I have reused what I found in other modules. Do you have an
> >> > example of a module with the recommended header?
> > Just take out these two paragraphs and you should be fine, and be sure
> > that you really mean "any later" for your license and that you didn't
> > copy any code from a non "any later" file.
> >
>
> Japp, that is fine for me. Fixed the other stuff and sent updated patch
> now. How is the possibility of getting a stable backported version of
> this one accepted (to Ubuntu LTS/Natty kernel versions)?
Talk to the Ubuntu developers, they are the ones in charge of that.
--
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 -next] net/m68k: Include <linux/interrupt.h> where needed
From: David Miller @ 2011-06-11 21:58 UTC (permalink / raw)
To: geert; +Cc: adobriyan, netdev, linux-next, linux-kernel
In-Reply-To: <1307792335-9926-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sat, 11 Jun 2011 13:38:55 +0200
...
> Introduced by commit a6b7a407865a ("net: remove interrupt.h inclusion from
> netdevice.h").
>
> Include <linux/interrupt.h> in the individual drivers to fix the build.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius Kotsbak @ 2011-06-11 21:57 UTC (permalink / raw)
To: Greg KH; +Cc: davem, netdev, linux-usb, Marius B. Kotsbak
In-Reply-To: <20110611200625.GB14582@kroah.com>
On 11. juni 2011 22:06, Greg KH wrote:
>>>> > >> + * This program is distributed in the hope that it will be useful,
>>>> > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> > >> + * GNU General Public License for more details.
>>>> > >> + *
>>>> > >> + * You should have received a copy of the GNU General Public License
>>>> > >> + * along with this program; if not, write to the Free Software
>>>> > >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>>> > > These two paragraphs are not needed, and unless you want to track the
>>> > > FSF's office changes for the next 40+ years, I'd really suggest not
>>> > > putting it in there at all.
>>> > >
>> >
>> > Same here, I have reused what I found in other modules. Do you have an
>> > example of a module with the recommended header?
> Just take out these two paragraphs and you should be fine, and be sure
> that you really mean "any later" for your license and that you didn't
> copy any code from a non "any later" file.
>
Japp, that is fine for me. Fixed the other stuff and sent updated patch
now. How is the possibility of getting a stable backported version of
this one accepted (to Ubuntu LTS/Natty kernel versions)?
--
Marius
^ permalink raw reply
* [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius B. Kotsbak @ 2011-06-11 21:55 UTC (permalink / raw)
To: davem, netdev; +Cc: linux-usb, Marius B. Kotsbak
In-Reply-To: <20110611200625.GB14582@kroah.com>
Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
It has also an ACM interface that previous patches associates with the "option"
module. To access those interfaces, the modem must first be switched from modem
mode using a tool like usb_modeswitch.
As the proprietary protocol has been discovered by watching the MS Windows driver
behavior, there might be errors in the protocol handling, but stable and fast
connection has been established for hours with Norwegian operator NetCom that
distributes this modem with their LTE/4G subscription.
More and updated information about how to use this driver is available here:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
---
drivers/net/usb/Kconfig | 10 ++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/kalmia.c | 384 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 395 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/usb/kalmia.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 9d4f911..b6e4efc 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -385,6 +385,16 @@ config USB_NET_CX82310_ETH
router with USB ethernet port. This driver is for routers only,
it will not work with ADSL modems (use cxacru driver instead).
+config CONFIG_USB_NET_KALMIA
+ tristate "Samsung Kalmia based LTE USB modem"
+ depends on USB_USBNET
+ help
+ Choose this option if you have a Samsung Kalmia based USB modem
+ as Samsung GT-B3730.
+
+ To compile this driver as a module, choose M here: the
+ module will be called kalmia.
+
config USB_HSO
tristate "Option USB High Speed Mobile Devices"
depends on USB && RFKILL
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index c7ec8a5..c203fa2 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_USB_NET_MCS7830) += mcs7830.o
obj-$(CONFIG_USB_USBNET) += usbnet.o
obj-$(CONFIG_USB_NET_INT51X1) += int51x1.o
obj-$(CONFIG_USB_CDC_PHONET) += cdc-phonet.o
+obj-$(CONFIG_USB_NET_KALMIA) += kalmia.o
obj-$(CONFIG_USB_IPHETH) += ipheth.o
obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
obj-$(CONFIG_USB_NET_CX82310_ETH) += cx82310_eth.o
diff --git a/drivers/net/usb/kalmia.c b/drivers/net/usb/kalmia.c
new file mode 100644
index 0000000..d965fb1
--- /dev/null
+++ b/drivers/net/usb/kalmia.c
@@ -0,0 +1,384 @@
+/*
+ * USB network interface driver for Samsung Kalmia based LTE USB modem like the
+ * Samsung GT-B3730 and GT-B3710.
+ *
+ * Copyright (C) 2011 Marius Bjoernstad Kotsbak <marius@kotsbak.com>
+ *
+ * Sponsored by Quicklink Video Distribution Services Ltd.
+ *
+ * Based on the cdc_eem module.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ctype.h>
+#include <linux/ethtool.h>
+#include <linux/workqueue.h>
+#include <linux/mii.h>
+#include <linux/usb.h>
+#include <linux/crc32.h>
+#include <linux/usb/cdc.h>
+#include <linux/usb/usbnet.h>
+#include <linux/gfp.h>
+
+/*
+ * The Samsung Kalmia based LTE USB modems have a CDC ACM port for modem control
+ * handled by the "option" module and an ethernet data port handled by this
+ * module.
+ *
+ * The stick must first be switched into modem mode by usb_modeswitch
+ * or similar tool. Then the modem gets sent two initialization packets by
+ * this module, which gives the MAC address of the device. User space can then
+ * connect the modem using AT commands through the ACM port and then use
+ * DHCP on the network interface exposed by this module. Network packets are
+ * sent to and from the modem in a proprietary format discovered after watching
+ * the behavior of the windows driver for the modem.
+ *
+ * More information about the use of the modem is available in usb_modeswitch
+ * forum and the project page:
+ *
+ * http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
+ * https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
+ */
+
+/* #define DEBUG */
+/* #define VERBOSE */
+
+#define KALMIA_HEADER_LENGTH 6
+#define KALMIA_ALIGN_SIZE 4
+#define KALMIA_USB_TIMEOUT 10000
+
+/*-------------------------------------------------------------------------*/
+
+static int
+kalmia_send_init_packet(struct usbnet *dev, u8 *init_msg, u8 init_msg_len,
+ u8 *buffer, u8 expected_len)
+{
+ int act_len;
+ int status;
+
+ netdev_dbg(dev->net, "Sending init packet");
+
+ status = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 0x02),
+ init_msg, init_msg_len, &act_len, KALMIA_USB_TIMEOUT);
+ if (status != 0) {
+ netdev_err(dev->net,
+ "Error sending init packet. Status %i, length %i\n",
+ status, act_len);
+ return status;
+ }
+ else if (act_len != init_msg_len) {
+ netdev_err(dev->net,
+ "Did not send all of init packet. Bytes sent: %i",
+ act_len);
+ }
+ else {
+ netdev_dbg(dev->net, "Successfully sent init packet.");
+ }
+
+ status = usb_bulk_msg(dev->udev, usb_rcvbulkpipe(dev->udev, 0x81),
+ buffer, expected_len, &act_len, KALMIA_USB_TIMEOUT);
+
+ if (status != 0)
+ netdev_err(dev->net,
+ "Error receiving init result. Status %i, length %i\n",
+ status, act_len);
+ else if (act_len != expected_len)
+ netdev_err(dev->net, "Unexpected init result length: %i\n",
+ act_len);
+
+ return status;
+}
+
+static int
+kalmia_init_and_get_ethernet_addr(struct usbnet *dev, u8 *ethernet_addr)
+{
+ char init_msg_1[] =
+ { 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00,
+ 0x00, 0x00 };
+ char init_msg_2[] =
+ { 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0xf4,
+ 0x00, 0x00 };
+ char receive_buf[28];
+ int status;
+
+ status = kalmia_send_init_packet(dev, init_msg_1, sizeof(init_msg_1)
+ / sizeof(init_msg_1[0]), receive_buf, 24);
+ if (status != 0)
+ return status;
+
+ status = kalmia_send_init_packet(dev, init_msg_2, sizeof(init_msg_2)
+ / sizeof(init_msg_2[0]), receive_buf, 28);
+ if (status != 0)
+ return status;
+
+ memcpy(ethernet_addr, receive_buf + 10, ETH_ALEN);
+
+ return status;
+}
+
+static int
+kalmia_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+ u8 status;
+ u8 ethernet_addr[ETH_ALEN];
+
+ /* Don't bind to AT command interface */
+ if (intf->cur_altsetting->desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC)
+ return -EINVAL;
+
+ dev->in = usb_rcvbulkpipe(dev->udev, 0x81 & USB_ENDPOINT_NUMBER_MASK);
+ dev->out = usb_sndbulkpipe(dev->udev, 0x02 & USB_ENDPOINT_NUMBER_MASK);
+ dev->status = NULL;
+
+ dev->net->hard_header_len += KALMIA_HEADER_LENGTH;
+ dev->hard_mtu = 1400;
+ dev->rx_urb_size = dev->hard_mtu * 10; // Found as optimal after testing
+
+ status = kalmia_init_and_get_ethernet_addr(dev, ethernet_addr);
+
+ if (status < 0) {
+ usb_set_intfdata(intf, NULL);
+ usb_driver_release_interface(driver_of(intf), intf);
+ return status;
+ }
+
+ memcpy(dev->net->dev_addr, ethernet_addr, ETH_ALEN);
+ memcpy(dev->net->perm_addr, ethernet_addr, ETH_ALEN);
+
+ return status;
+}
+
+static struct sk_buff *
+kalmia_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
+{
+ struct sk_buff *skb2 = NULL;
+ u16 content_len;
+ unsigned char *header_start;
+ unsigned char ether_type_1, ether_type_2;
+ u8 remainder, padlen = 0;
+
+ if (!skb_cloned(skb)) {
+ int headroom = skb_headroom(skb);
+ int tailroom = skb_tailroom(skb);
+
+ if ((tailroom >= KALMIA_ALIGN_SIZE) && (headroom
+ >= KALMIA_HEADER_LENGTH))
+ goto done;
+
+ if ((headroom + tailroom) > (KALMIA_HEADER_LENGTH
+ + KALMIA_ALIGN_SIZE)) {
+ skb->data = memmove(skb->head + KALMIA_HEADER_LENGTH,
+ skb->data, skb->len);
+ skb_set_tail_pointer(skb, skb->len);
+ goto done;
+ }
+ }
+
+ skb2 = skb_copy_expand(skb, KALMIA_HEADER_LENGTH,
+ KALMIA_ALIGN_SIZE, flags);
+ if (!skb2)
+ return NULL;
+
+ dev_kfree_skb_any(skb);
+ skb = skb2;
+
+ done: header_start = skb_push(skb, KALMIA_HEADER_LENGTH);
+ ether_type_1 = header_start[KALMIA_HEADER_LENGTH + 12];
+ ether_type_2 = header_start[KALMIA_HEADER_LENGTH + 13];
+
+ netdev_dbg(dev->net, "Sending etherType: %02x%02x", ether_type_1,
+ ether_type_2);
+
+ /* According to empiric data for data packages */
+ header_start[0] = 0x57;
+ header_start[1] = 0x44;
+ content_len = skb->len - KALMIA_HEADER_LENGTH;
+ header_start[2] = (content_len & 0xff); /* low byte */
+ header_start[3] = (content_len >> 8); /* high byte */
+
+ header_start[4] = ether_type_1;
+ header_start[5] = ether_type_2;
+
+ /* Align to 4 bytes by padding with zeros */
+ remainder = skb->len % KALMIA_ALIGN_SIZE;
+ if (remainder > 0) {
+ padlen = KALMIA_ALIGN_SIZE - remainder;
+ memset(skb_put(skb, padlen), 0, padlen);
+ }
+
+ netdev_dbg(
+ dev->net,
+ "Sending package with length %i and padding %i. Header: %02x:%02x:%02x:%02x:%02x:%02x.",
+ content_len, padlen, header_start[0], header_start[1],
+ header_start[2], header_start[3], header_start[4],
+ header_start[5]);
+
+ return skb;
+}
+
+static int
+kalmia_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+ /*
+ * Our task here is to strip off framing, leaving skb with one
+ * data frame for the usbnet framework code to process.
+ */
+ const u8 HEADER_END_OF_USB_PACKET[] =
+ { 0x57, 0x5a, 0x00, 0x00, 0x08, 0x00 };
+ const u8 EXPECTED_UNKNOWN_HEADER_1[] =
+ { 0x57, 0x43, 0x1e, 0x00, 0x15, 0x02 };
+ const u8 EXPECTED_UNKNOWN_HEADER_2[] =
+ { 0x57, 0x50, 0x0e, 0x00, 0x00, 0x00 };
+ u8 i = 0;
+
+ /* incomplete header? */
+ if (skb->len < KALMIA_HEADER_LENGTH)
+ return 0;
+
+ do {
+ struct sk_buff *skb2 = NULL;
+ u8 *header_start;
+ u16 usb_packet_length, ether_packet_length;
+ int is_last;
+
+ header_start = skb->data;
+
+ if (unlikely(header_start[0] != 0x57 || header_start[1] != 0x44)) {
+ if (!memcmp(header_start, EXPECTED_UNKNOWN_HEADER_1,
+ sizeof(EXPECTED_UNKNOWN_HEADER_1)) || !memcmp(
+ header_start, EXPECTED_UNKNOWN_HEADER_2,
+ sizeof(EXPECTED_UNKNOWN_HEADER_2))) {
+ netdev_dbg(
+ dev->net,
+ "Received expected unknown frame header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ }
+ else {
+ netdev_err(
+ dev->net,
+ "Received unknown frame header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ return 0;
+ }
+ }
+ else
+ netdev_dbg(
+ dev->net,
+ "Received header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1], header_start[2],
+ header_start[3], header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+
+ /* subtract start header and end header */
+ usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH);
+ ether_packet_length = header_start[2] + (header_start[3] << 8);
+ skb_pull(skb, KALMIA_HEADER_LENGTH);
+
+ /* Some small packets misses end marker */
+ if (usb_packet_length < ether_packet_length) {
+ ether_packet_length = usb_packet_length
+ + KALMIA_HEADER_LENGTH;
+ is_last = true;
+ }
+ else {
+ netdev_dbg(dev->net, "Correct package length #%i", i
+ + 1);
+
+ is_last = (memcmp(skb->data + ether_packet_length,
+ HEADER_END_OF_USB_PACKET,
+ sizeof(HEADER_END_OF_USB_PACKET)) == 0);
+ if (!is_last) {
+ header_start = skb->data + ether_packet_length;
+ netdev_dbg(
+ dev->net,
+ "End header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ }
+ }
+
+ if (is_last) {
+ skb2 = skb;
+ }
+ else {
+ skb2 = skb_clone(skb, GFP_ATOMIC);
+ if (unlikely(!skb2))
+ return 0;
+ }
+
+ skb_trim(skb2, ether_packet_length);
+
+ if (is_last) {
+ return 1;
+ }
+ else {
+ usbnet_skb_return(dev, skb2);
+ skb_pull(skb, ether_packet_length);
+ }
+
+ i++;
+ }
+ while (skb->len);
+
+ return 1;
+}
+
+static const struct driver_info kalmia_info = {
+ .description = "Samsung Kalmia LTE USB dongle",
+ .flags = FLAG_WWAN,
+ .bind = kalmia_bind,
+ .rx_fixup = kalmia_rx_fixup,
+ .tx_fixup = kalmia_tx_fixup
+};
+
+/*-------------------------------------------------------------------------*/
+
+static const struct usb_device_id products[] = {
+ /* The unswitched USB ID, to get the module auto loaded: */
+ { USB_DEVICE(0x04e8, 0x689a) },
+ /* The stick swithed into modem (by e.g. usb_modeswitch): */
+ { USB_DEVICE(0x04e8, 0x6889),
+ .driver_info = (unsigned long) &kalmia_info, },
+ { /* EMPTY == end of list */} };
+MODULE_DEVICE_TABLE( usb, products);
+
+static struct usb_driver kalmia_driver = {
+ .name = "kalmia",
+ .id_table = products,
+ .probe = usbnet_probe,
+ .disconnect = usbnet_disconnect,
+ .suspend = usbnet_suspend,
+ .resume = usbnet_resume
+};
+
+static int __init kalmia_init(void)
+{
+ return usb_register(&kalmia_driver);
+}
+module_init( kalmia_init);
+
+static void __exit kalmia_exit(void)
+{
+ usb_deregister(&kalmia_driver);
+}
+module_exit( kalmia_exit);
+
+MODULE_AUTHOR("Marius Bjoernstad Kotsbak <marius@kotsbak.com>");
+MODULE_DESCRIPTION("Samsung Kalmia USB network driver");
+MODULE_LICENSE("GPL");
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Greg KH @ 2011-06-11 20:06 UTC (permalink / raw)
To: Marius Kotsbak; +Cc: davem, netdev, linux-usb, Marius B. Kotsbak
In-Reply-To: <4DF2B5E4.8070303@gmail.com>
On Sat, Jun 11, 2011 at 02:25:08AM +0200, Marius Kotsbak wrote:
> On 11. juni 2011 01:55, Greg KH wrote:
> > On Sat, Jun 11, 2011 at 01:34:30AM +0200, Marius B. Kotsbak wrote:
> >> Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
> >> It has also an ACM interface that previous patches associates with the "option"
> >> module. To access those interfaces, the modem must first be switched from modem
> >> mode using a tool like usb_modeswitch.
> > Do we need to blacklist this device from the option driver?
>
> It is already done, in commits:
>
> 80f9df3e0093ad9f1eeefd2ff7fd27daaa518d25
> 15b2f3204a5c878c32939094775fb7349f707263
Ah, nevermind then :)
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, write to the Free Software
> >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> > These two paragraphs are not needed, and unless you want to track the
> > FSF's office changes for the next 40+ years, I'd really suggest not
> > putting it in there at all.
> >
>
> Same here, I have reused what I found in other modules. Do you have an
> example of a module with the recommended header?
Just take out these two paragraphs and you should be fine, and be sure
that you really mean "any later" for your license and that you didn't
copy any code from a non "any later" file.
thanks,
greg k-h
^ permalink raw reply
* Question about LRO/GRO and TCP acknowledgements
From: Joris van Rantwijk @ 2011-06-11 19:59 UTC (permalink / raw)
To: netdev
Hi,
I'm trying to understand how Linux produces TCP acknowledgements
for segments received via LRO/GRO.
As far as I can see, the network driver uses GRO to collect several
received packets into one big super skb, which is then handled
during just one call to tcp_v4_rcv(). This will eventually result
in the sending of at most one ACK packet for the entire GRO packet.
Conventional wisdom (RFC 5681) says that a receiver should send at
least one ACK for every two data segments received. The sending TCP
needs these ACKs to update its congestion window (e.g. slow start).
It seems to me that the current implementation in Linux may send
just one ACK for a large number of received segments. This would
be a deviation from the standard. As a result the congestion
window of the sender would grow much slower than intended.
Maybe I misunderstand something in the network code (likely).
Could someone please explain me how this ACK issue is handled?
Thanks,
Joris van Rantwijk.
^ 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