* Re: [PATCH 2/3] net/fec: add device tree support
From: Greg Ungerer @ 2011-06-20 0:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Shawn Guo, patches, netdev, devicetree-discuss,
Jason Liu, linux-kernel, David S. Miller
In-Reply-To: <201106191411.32137.arnd@arndb.de>
On 19/06/11 22:11, Arnd Bergmann wrote:
> On Sunday 19 June 2011 13:39:32 Greg Ungerer wrote:
>>> +#ifdef CONFIG_OF
>>> +static const struct of_device_id fec_dt_ids[] = {
>>> + { .compatible = "fsl,fec", .data =&fec_devtype[0], },
>>> + {},
>>> +};
>>> +
>>> +static const struct of_device_id *
>>> +fec_get_of_device_id(struct platform_device *pdev)
>>> +{
>>> + return of_match_device(fec_dt_ids,&pdev->dev);
>>> +}
>>> +#else
>>> +#define fec_dt_ids NULL
>>> +static inline struct of_device_id *
>>> +fec_get_of_device_id(struct platform_device *pdev)
>>> +{
>>> + return NULL;
>>> +}
>>> +#endif
>>> +
>>> static unsigned char macaddr[ETH_ALEN];
>>> module_param_array(macaddr, byte, NULL, 0);
>>> MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
>>> @@ -1363,6 +1385,11 @@ fec_probe(struct platform_device *pdev)
>>> struct net_device *ndev;
>>> int i, irq, ret = 0;
>>> struct resource *r;
>>> + const struct of_device_id *of_id;
>>> +
>>> + of_id = fec_get_of_device_id(pdev);
>>
>> fec_get_of_device_id() is defined inside of "#ifdef CONFIG_OF". This
>> use of it will break compilation when this is not defined.
>>
>
>
> Why? Note the #else path defining an empty function.
Sorry, missed that :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [PATCH 0/2] Allow NICs to pass Frame Checksum up the stack.
From: Ben Greear @ 2011-06-19 23:58 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, mirqus, netdev
In-Reply-To: <20110619.165456.1382315060825422595.davem@davemloft.net>
On 06/19/2011 04:54 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Sun, 19 Jun 2011 16:51:31 -0700
>
>> The last email in the features thread that I saw was a question to
>> you.
>
> I'm frustrated with the author because he keeps submitting what
> amounts to schemes that have the same problem or are incredibly ugly,
> and it's becomming a waste of my time to continue discussing the
> matter.
>
>> Is the original author's work worth trying to salvage, or should
>> the next person to attempt this ignore all that and start fresh?
>
> The above should make that obvious.
Well, do you have a suggested plan of attack for this?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 0/2] Allow NICs to pass Frame Checksum up the stack.
From: David Miller @ 2011-06-19 23:54 UTC (permalink / raw)
To: greearb; +Cc: bhutchings, mirqus, netdev
In-Reply-To: <4DFE8B83.3040501@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Sun, 19 Jun 2011 16:51:31 -0700
> The last email in the features thread that I saw was a question to
> you.
I'm frustrated with the author because he keeps submitting what
amounts to schemes that have the same problem or are incredibly ugly,
and it's becomming a waste of my time to continue discussing the
matter.
> Is the original author's work worth trying to salvage, or should
> the next person to attempt this ignore all that and start fresh?
The above should make that obvious.
^ permalink raw reply
* Re: [PATCH 0/2] Allow NICs to pass Frame Checksum up the stack.
From: Ben Greear @ 2011-06-19 23:51 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, mirqus, netdev
In-Reply-To: <20110619.162141.790923043226083093.davem@davemloft.net>
On 06/19/2011 04:21 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Fri, 17 Jun 2011 13:58:55 -0700
>
>> It's idle for 11 days. Seems dead in the water if you ask me.
>
> Because nobody wants to put in the effort to implement it properly.
>
> It's not an excuse for polluting the kernel with extraneous ethtool
> commands just because a fundamental issue is not being worked on.
>
> If this is important to you, you have all the power in the world to
> make it move forward.
>
> Your choice.
The last email in the features thread that I saw was a question to you.
Is the original author's work worth trying to salvage, or should
the next person to attempt this ignore all that and start fresh?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 0/7] net: fixup time stamping batch #1
From: David Miller @ 2011-06-19 23:36 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, eric.dumazet
In-Reply-To: <cover.1308489767.git.richard.cochran@omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sun, 19 Jun 2011 15:31:38 +0200
> As Eric Dumazet helpfully pointed out, the placing the transmit time
> stamp hook after giving the skb to hardware races with the completion
> ISR, for those drivers which free the buffer in the ISR.
>
> This series fixes up the first batch of time stamping hook patches.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] sgi-xp: fix a use after free
From: David Miller @ 2011-06-19 23:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: holt, netdev
In-Reply-To: <1308523956.3539.105.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 20 Jun 2011 00:52:36 +0200
> Its illegal to dereference skb after dev_kfree_skb(skb)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Robin Holt <holt@sgi.com>
> ---
> David, I am not sure Robin is active these days, maybe you can take this
> patch, since its clearly network related ?
Right.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] hp100: fix an skb->len race
From: David Miller @ 2011-06-19 23:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: richardcochran, netdev
In-Reply-To: <1308523413.3539.97.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 20 Jun 2011 00:43:33 +0200
> As soon as skb is given to hardware and spinlock released, TX completion
> can free skb under us. Therefore, we should update netdev stats before
> spinlock release.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: Ethernet low-level frame debugging support
From: Mark Smith @ 2011-06-19 23:27 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4DFE59E0.9070503@candelatech.com>
Hi Ben,
On Sun, 19 Jun 2011 13:19:44 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 06/18/2011 06:14 PM, Mark Smith wrote:
> > Hi,
> >
> > Firstly, I think this is a potentially quite useful feature for
> > networking people and that I hope it makes it into the kernel proper.
> >
> > One thing I've thought is that perhaps it might be made and named a bit
> > more generally, as NICs will also drop frames for other reasons other
> > than FCs failures e.g. runt frames. So perhaps something like "true
> > promiscuous" or "full promiscuous" might be a more general name, and if
> > it is enabled, then all NIC error checking that can be switched off is
> > switched off. Looking at the chipset data sheets for a few NICs that I
> > have / have had (netgear FA312 (natsemi ns83815), smc epic100, ne2000),
> > they all seem to have registers which allow switching off many if not
> > all of the NIC error checking settings.
>
> I called it 'save-rxerr' in ethtool...I think that is general enough?
>
Yes, I think so.
> The early patch that saves the FCS just passes the 4-byte FCS up the stack.
> It doesn't change the ability to receive bad frames or not..that is in the
> later patches.
>
> >
> > The other thing I've thought could be useful would be to be able to
> > send runts by not padding the frames when they're less then 64 bytes.
> > I've been able to test if this is possible with the netgear FA312, as
> > the chipset does the padding. I connected it back to back with an
> > e1000e I have, switched off the chipset automatic padding on the FA312,
> > sent small traffic, and then saw that the e1000e's internal
> > rx_short_length_errors counter correspondingly increased. Of course I
> > can't see them with tcpdump on the e1000e because it is dropping them.
>
> Maybe the SO_NOFCS option could change to SO_DRVOPTS and take a bit-field
> instead of just be on/off. NOFCS could be one flag, NOPAD another, etc.
Separating them out as individual flags would probably be best in a
testing situation. Allowing for other flags, and perhaps even flags and
variables could be useful. One thing I've been a bit intrigued about is
that on the FA312 chipset, one of the registers allows you to change
the length of the inter frame gap. I'm not sure why you'd want to,
however it would appear to have been useful enough for national
semiconductor to put it into a production and commodity chipset. In my
browsing I remember also seeing registers to do things like change the
collision recovery algorithm or timing.
> That would give ability to send non-padded frames if the driver has
> support.
>
I think there might be a possibility that all or a lot of them would
support sending frames that aren't padded.
The goal of my test above was only really to see if a network card
would send a runt, with the FA312 being an easy one to test with,
because all I had to do is poke one of the registers to switch on and
off padding, rather than having to modify a driver and build and run up
a test kernel or driver, as I don't have a test/development environment
already setup.
For cards that don't do padding in hardware, perhaps it might be as
easy as making the skb_padto call conditional.
Regards,
Mark.
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/1] r8169: fix static initializers.
From: David Miller @ 2011-06-19 23:26 UTC (permalink / raw)
To: romieu; +Cc: netdev, nic_swsd, hayeswang
In-Reply-To: <20110617210124.GA2347@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Fri, 17 Jun 2011 23:01:24 +0200
> Please pull from branch 'davem.r8169' in repository
>
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git davem.r8169
>
> to get the change below.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/5] net: Support ethtool ops for rx of errored frames.
From: David Miller @ 2011-06-19 23:24 UTC (permalink / raw)
To: greearb; +Cc: romieu, netdev
In-Reply-To: <4DFE832C.7000100@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Sun, 19 Jun 2011 16:15:56 -0700
> This would be separate from the 'features' patches that are floating
> around.
netdev->features is how you should implement your patch, please don't
create new facilities.
With netdev->features they can be validated against netdev->hw_features
which, in this case, r8169 would have this feature bit clear.
That's how all of this stuff is designed to work, the driver says what
the hardware can do and thus ethtool generically can validate attempts
to turn on features.
No new facilities are necessary at all.
^ permalink raw reply
* Re: [PATCH 2/2] proc: Usable inode numbers for the namespace file descriptors.
From: David Miller @ 2011-06-19 23:22 UTC (permalink / raw)
To: ebiederm; +Cc: containers, adobriyan, netdev, equinox, linux-kernel, serge
In-Reply-To: <m1mxhgav9c.fsf_-_@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 17 Jun 2011 16:33:19 -0700
>
> Assign a unique proc inode to each namespace, yielding an
> identifier that userspace can use for identifying a namespace.
>
> This has been a long requested feature and only blocked because
> a naive implementation would put the id in a global space and
> would ultimately require having a namespace for the names of
> namespaces, making migration and certain virtualization tricks
> impossible.
>
> We still don't have per superblock inode numbers for proc, which
> appears necessary for application unaware checkpoint/restart and
> migrations (if the application is using namespace filedescriptors)
> but that is now allowd by the design if it becomes important.
>
> I have preallocated the ipc and uts initial proc inode numbers so
> their structures can be statically initialized.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
For networking bits:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 0/2] Allow NICs to pass Frame Checksum up the stack.
From: David Miller @ 2011-06-19 23:21 UTC (permalink / raw)
To: greearb; +Cc: bhutchings, mirqus, netdev
In-Reply-To: <4DFBC00F.4000500@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Fri, 17 Jun 2011 13:58:55 -0700
> It's idle for 11 days. Seems dead in the water if you ask me.
Because nobody wants to put in the effort to implement it properly.
It's not an excuse for polluting the kernel with extraneous ethtool
commands just because a fundamental issue is not being worked on.
If this is important to you, you have all the power in the world to
make it move forward.
Your choice.
^ permalink raw reply
* Re: [PATCH 0/2] Allow NICs to pass Frame Checksum up the stack.
From: David Miller @ 2011-06-19 23:20 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1308339615-5866-1-git-send-email-greearb@candelatech.com>
From: greearb@candelatech.com
Date: Fri, 17 Jun 2011 12:40:13 -0700
> This series provides ethtool support to set and get the rx-checksum
> flag, and adds support to the e100 driver.
Please don't create entire new ethtool ops just to set what amounts
precisely to a boolean flag, that's what ETHTOOL_{S,G}FLAGS is for.
The fact that we've exhausted 32-bits of flags in netdev->features
is not an acceptable reason to avoid using those interfaces.
^ permalink raw reply
* Re: [PATCH v2 1/5] net: Support ethtool ops for rx of errored frames.
From: Ben Greear @ 2011-06-19 23:15 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20110619224800.GA2861@electric-eye.fr.zoreil.com>
On 06/19/2011 03:48 PM, Francois Romieu wrote:
> Ben Greear<greearb@candelatech.com> :
>> On 06/18/2011 02:34 PM, Francois Romieu wrote:
>>> greearb@candelatech.com<greearb@candelatech.com> :
>>> [...]
>>>> This can be useful when sniffing dodgy networks.
>>>
>>> Do you plan to add something similar - i.e. not per packet - for the Tx path ?
>>
>> Ability to tx errored frames? I posted a patch to enable sending
>> frames with custom (ie, invalid) Ethernet FCS, but you have to
>> enable it per-socket, and it will only work with AF_PACKET sockets.
>>
>> Can you offer more details on what you are asking for?
>
> Realtek's 816[89] and 810[23] have no room in their Tx descriptors to
> control ethernet checksum generation. There is a global register (TxConfig)
> though. Before looking at the per-socket information, the driver would need
> to be instructed to disable Tx hardware ethernet checksumming globally.
Ok. I think I'll take a stab at adding a more general low-level-flags
API to ethtool, with a bitfield that can be used to twiddle these sorts
of things. That way, we won't have to add new methods every time we
poke a new feature in.
This would be separate from the 'features' patches that are floating around.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [Patch] netpoll: copy dev name of slaves to struct netpoll
From: David Miller @ 2011-06-19 23:13 UTC (permalink / raw)
To: amwang; +Cc: netdev
In-Reply-To: <1308303817-3498-1-git-send-email-amwang@redhat.com>
From: Amerigo Wang <amwang@redhat.com>
Date: Fri, 17 Jun 2011 17:43:37 +0800
> Otherwise we will not see the name of the slave dev in error
> message:
>
> [ 388.469446] (null): doesn't support polling, aborting.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] sctp: HEARTBEAT negotiation after ASCONF
From: David Miller @ 2011-06-19 23:10 UTC (permalink / raw)
To: micchie; +Cc: yjwei, netdev
In-Reply-To: <9C3219F3-AD39-40CF-8422-241D26ECA4D7@sfc.wide.ad.jp>
From: Michio Honda <micchie@sfc.wide.ad.jp>
Date: Thu, 16 Jun 2011 17:56:42 +0900
> @@ -989,6 +991,8 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
> ((new_transport->state == SCTP_INACTIVE) ||
> (new_transport->state == SCTP_UNCONFIRMED)))
> new_transport = asoc->peer.active_path;
> + if (new_transport->state == SCTP_UNCONFIRMED)
> + continue;
>
> /* Change packets if necessary. */
> if (new_transport != transport) {
This code path uses the asoc->peer.active_path is the new_transport
is in the SCTP_UNCONFIRMED state. Are you sure your new check is
correct in that case?
Shouldn't you be testing the variable "new_transport" instead?
^ permalink raw reply
* Re: [PATCH v2 1/5] net: Support ethtool ops for rx of errored frames.
From: Francois Romieu @ 2011-06-19 22:48 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4DFE57DA.8090404@candelatech.com>
Ben Greear <greearb@candelatech.com> :
> On 06/18/2011 02:34 PM, Francois Romieu wrote:
> >greearb@candelatech.com<greearb@candelatech.com> :
> >[...]
> >>This can be useful when sniffing dodgy networks.
> >
> >Do you plan to add something similar - i.e. not per packet - for the Tx path ?
>
> Ability to tx errored frames? I posted a patch to enable sending
> frames with custom (ie, invalid) Ethernet FCS, but you have to
> enable it per-socket, and it will only work with AF_PACKET sockets.
>
> Can you offer more details on what you are asking for?
Realtek's 816[89] and 810[23] have no room in their Tx descriptors to
control ethernet checksum generation. There is a global register (TxConfig)
though. Before looking at the per-socket information, the driver would need
to be instructed to disable Tx hardware ethernet checksumming globally.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/2] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: David Miller @ 2011-06-19 22:57 UTC (permalink / raw)
To: marius.kotsbak; +Cc: netdev, linux-usb, marius
In-Reply-To: <1308519957-28860-1-git-send-email-marius@kotsbak.com>
From: "Marius B. Kotsbak" <marius.kotsbak@gmail.com>
Date: Sun, 19 Jun 2011 23:45:56 +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>
Please submit only one patch for adding a new driver.
Adding a second patch that fixes the driver in various ways is
just noise, put those fixes into this one initial patch instead.
Thanks.
^ permalink raw reply
* [PATCH] sgi-xp: fix a use after free
From: Eric Dumazet @ 2011-06-19 22:52 UTC (permalink / raw)
To: David Miller, Robin Holt; +Cc: netdev
Its illegal to dereference skb after dev_kfree_skb(skb)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Robin Holt <holt@sgi.com>
---
David, I am not sure Robin is active these days, maybe you can take this
patch, since its clearly network related ?
drivers/misc/sgi-xp/xpnet.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/sgi-xp/xpnet.c b/drivers/misc/sgi-xp/xpnet.c
index ee5109a..42f0673 100644
--- a/drivers/misc/sgi-xp/xpnet.c
+++ b/drivers/misc/sgi-xp/xpnet.c
@@ -495,14 +495,14 @@ xpnet_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
}
+ dev->stats.tx_packets++;
+ dev->stats.tx_bytes += skb->len;
+
if (atomic_dec_return(&queued_msg->use_count) == 0) {
dev_kfree_skb(skb);
kfree(queued_msg);
}
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += skb->len;
-
return NETDEV_TX_OK;
}
^ permalink raw reply related
* [PATCH] hp100: fix an skb->len race
From: Eric Dumazet @ 2011-06-19 22:43 UTC (permalink / raw)
To: David Miller; +Cc: richardcochran, netdev
In-Reply-To: <20110619.120536.1593516819440469613.davem@davemloft.net>
As soon as skb is given to hardware and spinlock released, TX completion
can free skb under us. Therefore, we should update netdev stats before
spinlock release.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/hp100.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
index 8e10d2f..c3ecb11 100644
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -1580,12 +1580,12 @@ static netdev_tx_t hp100_start_xmit_bm(struct sk_buff *skb,
hp100_outl(ringptr->pdl_paddr, TX_PDA_L); /* Low Prio. Queue */
lp->txrcommit++;
- spin_unlock_irqrestore(&lp->lock, flags);
- /* Update statistics */
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
+ spin_unlock_irqrestore(&lp->lock, flags);
+
return NETDEV_TX_OK;
drop:
^ permalink raw reply related
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius Kotsbak @ 2011-06-19 21:53 UTC (permalink / raw)
To: Oliver Neukum
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius B. Kotsbak
In-Reply-To: <201106141146.19097.oneukum-l3A5Bk7waGM@public.gmane.org>
On 14. juni 2011 11:46, Oliver Neukum wrote:
> Am Dienstag, 14. Juni 2011, 11:32:00 schrieb Marius Kotsbak:
>> Den 14. juni 2011 10:49, skrev Oliver Neukum:
>>> Am Samstag, 11. Juni 2011, 23:55:18 schrieb Marius B. Kotsbak:
>>>
>>>> +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];
>>> You are doing DMA on the stack. This will fail on some architectures.
>>>
>> Okay, a bit strange that this API is available then. Which API functions
>> should be used in this case?
> The API is correct. You just need to copy the init strings into buffers
> allocated with kmalloc.
>
This should be addressed in the extra patch just sent. And it still
works on my x86-64.
The 2 patches might be squashed if desired.
>
> Will the compiler put those strings into the image or build them on
> the stack each time the function is called? Shouldn't they be static?
>
Fixed. It probably improves performance too.
>> Anyway it should not do any damage for anyone (I think even the driver
>> disk is available with this included). The module could in fact also do
>> the switch into modem mode to avoid the dependency on usb_modeswitch.
> Please don't do that. It has been decided to put such things into usb_modeswitch
> for now.
Okay, I can see the reasoning behind that. The problem is just that it
would be nice to avoid it because >1.1.4 versions of it does not work
with this modem, but that can be addressed there as well.
--
Marius
--
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
* [PATCH 2/2] Various fixes for better support of non-x86 architectures.
From: Marius B. Kotsbak @ 2011-06-19 21:45 UTC (permalink / raw)
To: davem, netdev; +Cc: linux-usb, Marius B. Kotsbak
In-Reply-To: <1308519957-28860-1-git-send-email-marius@kotsbak.com>
-Support for big endian.
-Do not use USB buffers at the stack.
-Safer/more efficient code for local constants.
Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
---
drivers/net/usb/kalmia.c | 40 ++++++++++++++++++++++++----------------
1 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/kalmia.c b/drivers/net/usb/kalmia.c
index d965fb1..d4edeb2 100644
--- a/drivers/net/usb/kalmia.c
+++ b/drivers/net/usb/kalmia.c
@@ -100,27 +100,35 @@ kalmia_send_init_packet(struct usbnet *dev, u8 *init_msg, u8 init_msg_len,
static int
kalmia_init_and_get_ethernet_addr(struct usbnet *dev, u8 *ethernet_addr)
{
- char init_msg_1[] =
+ const static char init_msg_1[] =
{ 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00,
0x00, 0x00 };
- char init_msg_2[] =
+ const static char init_msg_2[] =
{ 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0xf4,
0x00, 0x00 };
- char receive_buf[28];
+ const static int buflen = 28;
+ char *usb_buf;
int status;
- status = kalmia_send_init_packet(dev, init_msg_1, sizeof(init_msg_1)
- / sizeof(init_msg_1[0]), receive_buf, 24);
+ usb_buf = kmalloc(buflen, GFP_DMA | GFP_KERNEL);
+ if (!usb_buf)
+ return -ENOMEM;
+
+ memcpy(usb_buf, init_msg_1, 12);
+ status = kalmia_send_init_packet(dev, usb_buf, sizeof(init_msg_1)
+ / sizeof(init_msg_1[0]), usb_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);
+ memcpy(usb_buf, init_msg_2, 12);
+ status = kalmia_send_init_packet(dev, usb_buf, sizeof(init_msg_2)
+ / sizeof(init_msg_2[0]), usb_buf, 28);
if (status != 0)
return status;
- memcpy(ethernet_addr, receive_buf + 10, ETH_ALEN);
+ memcpy(ethernet_addr, usb_buf + 10, ETH_ALEN);
+ kfree(usb_buf);
return status;
}
@@ -190,7 +198,8 @@ kalmia_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
dev_kfree_skb_any(skb);
skb = skb2;
- done: header_start = skb_push(skb, KALMIA_HEADER_LENGTH);
+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];
@@ -201,9 +210,8 @@ kalmia_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
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 */
+ put_unaligned_le16(content_len, &header_start[2]);
header_start[4] = ether_type_1;
header_start[5] = ether_type_2;
@@ -231,13 +239,13 @@ 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[] =
+ const static u8 HEADER_END_OF_USB_PACKET[] =
{ 0x57, 0x5a, 0x00, 0x00, 0x08, 0x00 };
- const u8 EXPECTED_UNKNOWN_HEADER_1[] =
+ const static u8 EXPECTED_UNKNOWN_HEADER_1[] =
{ 0x57, 0x43, 0x1e, 0x00, 0x15, 0x02 };
- const u8 EXPECTED_UNKNOWN_HEADER_2[] =
+ const static u8 EXPECTED_UNKNOWN_HEADER_2[] =
{ 0x57, 0x50, 0x0e, 0x00, 0x00, 0x00 };
- u8 i = 0;
+ int i = 0;
/* incomplete header? */
if (skb->len < KALMIA_HEADER_LENGTH)
@@ -285,7 +293,7 @@ kalmia_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
/* 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);
+ ether_packet_length = get_unaligned_le16(&header_start[2]);
skb_pull(skb, KALMIA_HEADER_LENGTH);
/* Some small packets misses end marker */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius B. Kotsbak @ 2011-06-19 21:45 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius B. Kotsbak
In-Reply-To: <201106141146.19097.oneukum-l3A5Bk7waGM@public.gmane.org>
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-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
---
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..84d4608 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 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-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
+ *
+ * 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-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("Samsung Kalmia USB network driver");
+MODULE_LICENSE("GPL");
--
1.7.4.1
--
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 related
* Re: rcu_sched_state detected stall on CPU 0, 3.0-rc2
From: Andy Isaacson @ 2011-06-19 21:20 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Paul E. McKenney, linux-kernel, netdev, linux-pm
In-Reply-To: <20110613060453.GA21778@hexapodia.org>
On Sun, Jun 12, 2011 at 11:04:53PM -0700, Andy Isaacson wrote:
> On Sun, Jun 12, 2011 at 10:30:05PM -0400, Ben Hutchings wrote:
> > > Of course now that I'm trying to debug, I am seeing many successful
> > > suspend-resume cycles. I don't see any signs of difference between the
> > > cases that hung and the cases that are now succeeding.
> > >
> > > CCing netdev, because I suspend by running pm-suspend, and in at least
> > > one failure, an ethtool running under pm-suspend seemed to be the
> > > problem:
> > >
> > > root 11558 pts/8 S+ \_ /bin/sh /usr/lib/pm-utils/sleep.d/00powers
> > > root 11559 pts/8 S+ \_ /bin/sh /usr/sbin/pm-powersave
> > > root 11576 pts/8 S+ \_ /bin/sh /usr/lib/pm-utils/power.d/
> > > root 11577 pts/8 D+ \_ ethtool -s eth0 wol g
> > [...]
> >
> > Wake-on-LAN configuration is entirely handled by the relevant driver;
> > the ethtool core just copies the parameters in and out. It looks like
> > there is some sort of deadlock or missing unlock in the driver. So my
> > question would be which driver is running eth0?
>
> I attached the whole gzipped dmesg, but anyways, it's e1000e:
>
> [ 1.168733] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
> [ 1.168879] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> [ 1.169346] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [ 1.169494] e1000e 0000:00:19.0: setting latency timer to 64
> [ 1.169603] usbcore: registered new interface driver usbfs
> [ 1.169675] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
> [ 1.169794] usbcore: registered new interface driver hub
> [ 1.181231] usbcore: registered new device driver usb
> [ 1.181879] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [ 1.190984] thermal LNXTHERM:00: registered as thermal_zone0
> [ 1.191129] ACPI: Thermal Zone [THM0] (48 C)
> [ 1.205191] SCSI subsystem initialized
> [ 1.207349] libata version 3.00 loaded.
> [ 1.352926] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:26:2d:f3:14:0f
> [ 1.353243] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [ 1.353473] e1000e 0000:00:19.0: eth0: MAC: 9, PHY: 10, PBA No: A002FF-0FF
> [snip]
> [ 1221.836727] PM: Entering mem sleep
> [ 1221.836855] Suspending console(s) (use no_console_suspend to debug)
> [ 1222.018735] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [ 1222.063181] sd 0:0:0:0: [sda] Stopping disk
> [ 1222.272665] ehci_hcd 0000:00:1d.0: PCI INT D disabled
> [ 1222.272668] ehci_hcd 0000:00:1a.0: PCI INT D disabled
> [ 1222.304428] i915 0000:00:02.0: power state changed by ACPI to D3
> [ 1222.378384] e1000e 0000:00:19.0: PCI INT A disabled
> [ 1222.378393] e1000e 0000:00:19.0: PME# enabled
> [ 1222.378400] e1000e 0000:00:19.0: wake-up capability enabled by ACPI
>
> ethtool does show up in the failure dmesg:
>
> [56520.872462] INFO: task ethtool:18105 blocked for more than 120 seconds.
> [56520.872465] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [56520.872468] ethtool D 7fffffffffffffff 0 18105 18104 0x00000000
> [56520.872473] ffff880105d99ad8 0000000000000082 ffffffff810d0c05 ffff880137d15730
> [56520.872479] ffff880130fd3780 ffff880105d99fd8 ffff880105d99fd8 0000000000012500
> [56520.872485] ffff8801333794d0 ffff880130fd3780 ffff880105d99fd8 ffff880137ffbe00
> [56520.872490] Call Trace:
> [56520.872499] [<ffffffff810d0c05>] ? zone_statistics+0x7c/0x83
> [56520.872504] [<ffffffff8131c13e>] schedule_timeout+0x34/0xde
> [56520.872509] [<ffffffff8131bef8>] wait_for_common+0xa3/0x11a
> [56520.872514] [<ffffffff8103c393>] ? try_to_wake_up+0x1ac/0x1ac
> [56520.872519] [<ffffffff8131c023>] wait_for_completion+0x1d/0x1f
> [56520.872524] [<ffffffff8109557d>] synchronize_sched+0x5a/0x5c
> [56520.872528] [<ffffffff8105beac>] ? find_ge_pid+0x41/0x41
> [56520.872536] [<ffffffff8122f67a>] wakeup_source_remove+0x60/0x64
> [56520.872541] [<ffffffff8122f785>] wakeup_source_unregister+0x13/0x1f
> [56520.872546] [<ffffffff8122f7f1>] device_wakeup_disable+0x60/0x6b
> [56520.872550] [<ffffffff8122f942>] device_set_wakeup_enable+0x2d/0x2f
> [56520.872573] [<ffffffffa003a56a>] e1000_set_wol+0x9b/0x9f [e1000e]
> [56520.872580] [<ffffffff81261c8e>] dev_ethtool+0x338/0x1c06
> [56520.872585] [<ffffffff810d4be4>] ? __do_fault+0x313/0x34a
> [56520.872591] [<ffffffff810329ef>] ? should_resched+0xe/0x2d
> [56520.872595] [<ffffffff8131be41>] ? _cond_resched+0xe/0x22
> [56520.872600] [<ffffffff8126019d>] dev_ioctl+0x503/0x688
> [56520.872605] [<ffffffff81319009>] ? __slab_alloc+0x330/0x342
> [56520.872610] [<ffffffff8124ac72>] ? sock_alloc_inode+0x24/0xb7
> [56520.872615] [<ffffffff8124b0c2>] sock_do_ioctl+0x3b/0x46
> [56520.872619] [<ffffffff8124b4f1>] sock_ioctl+0x20d/0x21b
> [56520.872625] [<ffffffff810feb02>] ? get_empty_filp+0x93/0x11b
> [56520.872630] [<ffffffff8110b218>] do_vfs_ioctl+0x460/0x4a1
> [56520.872635] [<ffffffff8124ca82>] ? sock_alloc_file+0xb3/0x114
> [56520.872640] [<ffffffff8131d13e>] ? _raw_spin_lock+0xe/0x10
> [56520.872646] [<ffffffff810fc23d>] ? fd_install+0x31/0x5d
> [56520.872650] [<ffffffff8110b2a0>] sys_ioctl+0x47/0x6b
> [56520.872655] [<ffffffff8131ddc2>] system_call_fastpath+0x16/0x1b
I've been using 3.0.0-rc2 at 3c25fa74 and haven't seen this problem
reoccur, so I guess it was either transient or fixed by something in
7f45e5c..3c25fa7. Thanks for the help, everyone.
-andy
^ permalink raw reply
* Re: Ethernet low-level frame debugging support
From: Ben Greear @ 2011-06-19 20:19 UTC (permalink / raw)
To: Mark Smith; +Cc: netdev
In-Reply-To: <20110619104431.23a22fe9@opy.nosense.org>
On 06/18/2011 06:14 PM, Mark Smith wrote:
> Hi,
>
> Firstly, I think this is a potentially quite useful feature for
> networking people and that I hope it makes it into the kernel proper.
>
> One thing I've thought is that perhaps it might be made and named a bit
> more generally, as NICs will also drop frames for other reasons other
> than FCs failures e.g. runt frames. So perhaps something like "true
> promiscuous" or "full promiscuous" might be a more general name, and if
> it is enabled, then all NIC error checking that can be switched off is
> switched off. Looking at the chipset data sheets for a few NICs that I
> have / have had (netgear FA312 (natsemi ns83815), smc epic100, ne2000),
> they all seem to have registers which allow switching off many if not
> all of the NIC error checking settings.
I called it 'save-rxerr' in ethtool...I think that is general enough?
The early patch that saves the FCS just passes the 4-byte FCS up the stack.
It doesn't change the ability to receive bad frames or not..that is in the
later patches.
>
> The other thing I've thought could be useful would be to be able to
> send runts by not padding the frames when they're less then 64 bytes.
> I've been able to test if this is possible with the netgear FA312, as
> the chipset does the padding. I connected it back to back with an
> e1000e I have, switched off the chipset automatic padding on the FA312,
> sent small traffic, and then saw that the e1000e's internal
> rx_short_length_errors counter correspondingly increased. Of course I
> can't see them with tcpdump on the e1000e because it is dropping them.
Maybe the SO_NOFCS option could change to SO_DRVOPTS and take a bit-field
instead of just be on/off. NOFCS could be one flag, NOPAD another, etc.
That would give ability to send non-padded frames if the driver has
support.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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