* Re: Staging: cpc-usb CAN driver TODO list
From: Wolfgang Grandegger @ 2009-09-07 7:05 UTC (permalink / raw)
To: Sebastian Haas; +Cc: Oliver Hartkopp, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4A0A2.2070907@ems-wuensche.com>
Hi Sebastian,
On 09/07/2009 07:56 AM, Sebastian Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Oliver,
>
> I'm not yet sure how to actually start the development. There is so much
> to do, and I've not much time to spend on this, unfortunately. Because
> of this I can't rewrite the whole driver on my own in order to get a
> Socket-CAN driver but I can provide support, review patches, rent
> devices and make tests here.
>
> Oliver, you are not familiar with USB and I'm not very familiar with CAN
> netdev internals, why not combining these twos. You are writing the CAN
> part and write the USB part.
>
> I'll also write a specification which contains any information you need
> to develop a CAN driver for the device (commands, sequences, error
> handling).
Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
Note that we do a lot of Socket-CAN work in our free time, which is a
limited resource. Progress depends on funding to a certain extend.
Wolfgang.
^ permalink raw reply
* Re: Network hangs with 2.6.30.5
From: Jarek Poplawski @ 2009-09-07 7:21 UTC (permalink / raw)
To: Holger Hoffstaette; +Cc: netdev, Eric Dumazet
In-Reply-To: <pan.2009.09.03.19.55.37.672875@googlemail.com>
On 03-09-2009 21:55, Holger Hoffstaette wrote:
> On Thu, 03 Sep 2009 21:27:08 +0200, Eric Dumazet wrote:
>
>> Holger Hoffstaette a écrit :
>>> Problem found! At least for me..
>>>
>>>> On 01-09-2009 17:32, Holger Hoffstaette wrote:
>>>>> On Tue, 01 Sep 2009 16:17:08 +0200, Holger Hoffstaette wrote:
>>>>>
>>>>> [network regressions in .30]
>>> I got the git .30.y stable tree and reverted various e1000 commits that
>>> seemed to coincide with the various .30-rc releases but nothing helped.
>>> Also no relation to offloads etc.
>>>
>>> However I did notice that the "stuck squid" problem seemed to magically
>>> fix itself after a few seconds - then hang again, fix itself after
>>> timeouts etc. So I suspected something TCP related and BINGO!
>>>
>>> Turns out I had both tcp_tw_recycle and tcp_tw_reuse set to 1 for
>>> reasons I don't want to explain. :)
>>>
>>> I can now arbitrarily fix the hanging behaviour by setting
>>> tcp_tw_recycle to 0, and cause hangs by setting it to 1 again. For
>>> obvious reasons this seems to affect squid more than other tasks with
>>> more long-lived connections. What is the right behaviour? beats me.
>>>
>>> tcp_tw_reuse does not appear to play a role, so the real culprit at
>>> least in my case seems to be tcp_tw_recycle. In previous releases this
>>> (and tw_reuse) was necessary for various server tasks.
>>>
>>> Nevertheless, something has changed between .29 and .30 that "broke" the
>>> previous behaviour. Whether this is progress or an regression I cannot
>>> say. Maybe someone else has an idea?
>>>
>>>
>> Well... not yet :)
>>
>> We probably can reproduce this problem with any NIC...
>>
>> Could you send from the 'buggy' setup
>>
>> $ grep . /proc/sys/net/ipv4/*
>
> Sure:
...
> Was that somewhat helpful? I can certainly create a full trace but that's
> going to be big.
Congratulations for finding the culprit!
While Eric is analyzing your data, I guess you could try reverting
some stuff around this tcp_tw_recycle, and my tcp ignorance would
point these commits for the beginning:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commitdiff;h=fc1ad92dfc4e363a055053746552cdb445ba5c57
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commitdiff;h=c887e6d2d9aee56ee7c9f2af4cec3a5efdcc4c72
Regards,
Jarek P.
PS: you don't have to remove anybody from the Cc line on this list.;-)
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Sebastian Haas @ 2009-09-07 8:01 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Oliver Hartkopp, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4B0C6.5080608@grandegger.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wolfgang,
Wolfgang Grandegger schrieb:
> Hi Sebastian,
>
> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Oliver,
>>
>> I'm not yet sure how to actually start the development. There is so much
>> to do, and I've not much time to spend on this, unfortunately. Because
>> of this I can't rewrite the whole driver on my own in order to get a
>> Socket-CAN driver but I can provide support, review patches, rent
>> devices and make tests here.
>>
>> Oliver, you are not familiar with USB and I'm not very familiar with CAN
>> netdev internals, why not combining these twos. You are writing the CAN
>> part and write the USB part.
>>
>> I'll also write a specification which contains any information you need
>> to develop a CAN driver for the device (commands, sequences, error
>> handling).
>
> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
> Note that we do a lot of Socket-CAN work in our free time, which is a
> limited resource. Progress depends on funding to a certain extend.
Money is also a limited resource. ;-)
Let's become serious again, I know and respect that many of Socket-CAN
and the Staging developers spend their free time working on it. We will
of course work on the driver, but since we've not much time it may take
several months. If someone wants to help, we would be very glad and
happy to support the person as far as we can with devices, answers and
tests.
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqkveMACgkQpqRB8PJG7Xyu3ACeMhuOoVMQ043tib6HH9NhQPBw
uTQAnjCFIqzv6dQl9iRiWopVYWAirdKb
=MRvL
-----END PGP SIGNATURE-----
--
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax : +49-8441-81860
http://www.ems-wuensche.com
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: David Miller @ 2009-09-07 8:50 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <4AA14377.9020200@trash.net>
I gave these patches a very basic bashing with NIU, and it
seems to work from what I've tried.
I know that Jarek has expressed some questions about the callback
scheme used by the new mq classful qdisc, as well as some other
issues, but we can refine this using followon patches.
For now I'm pushing this out so that it gets wider testing.
Thanks everyone!
^ permalink raw reply
* Re: [PATCH NEXT 0/6] nexten: fixes and enhancements
From: David Miller @ 2009-09-07 8:54 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1252208592-2240-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sat, 5 Sep 2009 20:43:06 -0700
> Series of 6 driver enhancements / fixes, please apply to net-next-2.6.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: David Miller @ 2009-09-07 8:57 UTC (permalink / raw)
To: shemminger; +Cc: khc, sfr, linux-next, netdev
In-Reply-To: <20090904083346.43885303@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 4 Sep 2009 08:33:46 -0700
> This is a brute force removal of the wierd slave interface done for DLCI -> SDLA
> transmit. Before it was using non-standard return values and freeing skb in caller.
> This changes it to using normal return values, and freeing in the callee.
> Luckly only one driver pair was doing this. Not tested on real hardware,
> in fact I wonder if this driver pair is even being used by any users.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Irregardless of what we should do with the SDLA driver, this patch
should go in while that code is still in the tree.
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix hydra printk format warning
From: David Miller @ 2009-09-07 8:57 UTC (permalink / raw)
To: randy.dunlap; +Cc: linux-m68k, netdev, geert, zippel
In-Reply-To: <20090904172037.b2dd7f20.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Fri, 4 Sep 2009 17:20:37 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> m68k:
> drivers/net/hydra.c:178: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'resource_size_t'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* [net-next-2.6, 1/2] be2net: Changes to support flashing of the be2 network adapter
From: David Miller @ 2009-09-07 8:58 UTC (permalink / raw)
To: ajitk; +Cc: netdev
Both patches applied, thanks.
^ permalink raw reply
* Re: [PATCH] WAN: remove deprecated PCI_DEVICE_ID from PCI200SYN driver.
From: David Miller @ 2009-09-07 8:58 UTC (permalink / raw)
To: khc; +Cc: netdev
In-Reply-To: <m3ljktek61.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Sat, 05 Sep 2009 12:54:30 +0200
> PCI200SYN has its own PCI subsystem device ID for 3+ years, now it's
> time to remove the generic PLX905[02] ID from the driver. Anyone with
> old EEPROM data will have to run the upgrade.
>
> Having the generic PLX905[02] (PCI-local bus bridge) ID is harmful
> as the driver tries to handle other devices based on these bridges.
>
> Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Wolfgang Grandegger @ 2009-09-07 8:58 UTC (permalink / raw)
To: Sebastian Haas; +Cc: Oliver Hartkopp, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4BDE6.7000707@ems-wuensche.com>
On 09/07/2009 10:01 AM, Sebastian Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wolfgang,
>
> Wolfgang Grandegger schrieb:
>> Hi Sebastian,
>>
>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Oliver,
>>>
>>> I'm not yet sure how to actually start the development. There is so much
>>> to do, and I've not much time to spend on this, unfortunately. Because
>>> of this I can't rewrite the whole driver on my own in order to get a
>>> Socket-CAN driver but I can provide support, review patches, rent
>>> devices and make tests here.
>>>
>>> Oliver, you are not familiar with USB and I'm not very familiar with CAN
>>> netdev internals, why not combining these twos. You are writing the CAN
>>> part and write the USB part.
>>>
>>> I'll also write a specification which contains any information you need
>>> to develop a CAN driver for the device (commands, sequences, error
>>> handling).
>>
>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>> Note that we do a lot of Socket-CAN work in our free time, which is a
>> limited resource. Progress depends on funding to a certain extend.
> Money is also a limited resource. ;-)
>
> Let's become serious again, I know and respect that many of Socket-CAN
> and the Staging developers spend their free time working on it. We will
> of course work on the driver, but since we've not much time it may take
> several months. If someone wants to help, we would be very glad and
> happy to support the person as far as we can with devices, answers and
> tests.
OK, no problem. I really appreciate your support for Socket-CAN so far.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH] IXP42x HSS support for setting internal clock rate
From: David Miller @ 2009-09-07 8:59 UTC (permalink / raw)
To: khc; +Cc: netdev
In-Reply-To: <m3ab19cx0q.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Sat, 05 Sep 2009 15:59:49 +0200
> HSS usually uses external clocks, so it's not a big deal. Internal clock
> is used for direct DTE-DTE connections and when the DCE doesn't provide
> it's own clock.
>
> This also depends on the oscillator frequency. Intel seems to have
> calculated the clock register settings for 33.33 MHz (66.66 MHz timer
> base). Their settings seem quite suboptimal both in terms of average
> frequency (60 ppm is unacceptable for G.703 applications, their primary
> intended usage(?)) and jitter.
>
> Many (most?) platforms use a 33.333 MHz oscillator, a 10 ppm difference
> from Intel's base.
>
> Instead of creating static tables, I've created a procedure to program
> the HSS clock register. The register consists of 3 parts (A, B, C).
> The average frequency (= bit rate) is:
> 66.66x MHz / (A + (B + 1) / (C + 1))
> The procedure aims at the closest average frequency, possibly at the
> cost of increased jitter. Nobody would be able to directly drive an
> unbufferred transmitter with a HSS anyway, and the frequency error is
> what it really counts.
...
> Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
Applied, thanks Krzysztof.
^ permalink raw reply
* [PATCH 07/12 v2] gigaset: improve error recovery
From: Tilman Schmidt @ 2009-09-07 8:59 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
Cc: Daniel Walker, Hansjoerg Lipp
In-Reply-To: <20090906-patch-gigaset-07.tilman-ZTO5kqT2PaM@public.gmane.org>
When the Gigaset base stops responding, try resetting the USB
connection to recover.
Impact: error handling improvement
Signed-off-by: Tilman Schmidt <tilman-ZTO5kqT2PaM@public.gmane.org>
---
drivers/isdn/gigaset/bas-gigaset.c | 69 +++++++++++++++++++++++------------
1 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/drivers/isdn/gigaset/bas-gigaset.c b/drivers/isdn/gigaset/bas-gigaset.c
index 9e7108a..44bcfd9 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -134,6 +134,7 @@ struct bas_cardstate {
#define BS_ATRDPEND 0x040 /* urb_cmd_in in use */
#define BS_ATWRPEND 0x080 /* urb_cmd_out in use */
#define BS_SUSPEND 0x100 /* USB port suspended */
+#define BS_RESETTING 0x200 /* waiting for HD_RESET_INTERRUPT_PIPE_ACK */
static struct gigaset_driver *driver = NULL;
@@ -319,6 +320,21 @@ static int gigaset_set_line_ctrl(struct cardstate *cs, unsigned cflag)
return -EINVAL;
}
+/* set/clear bits in base connection state, return previous state
+ */
+static inline int update_basstate(struct bas_cardstate *ucs,
+ int set, int clear)
+{
+ unsigned long flags;
+ int state;
+
+ spin_lock_irqsave(&ucs->lock, flags);
+ state = ucs->basstate;
+ ucs->basstate = (state & ~clear) | set;
+ spin_unlock_irqrestore(&ucs->lock, flags);
+ return state;
+}
+
/* error_hangup
* hang up any existing connection because of an unrecoverable error
* This function may be called from any context and takes care of scheduling
@@ -350,12 +366,9 @@ static inline void error_hangup(struct bc_state *bcs)
*/
static inline void error_reset(struct cardstate *cs)
{
- /* close AT command channel to recover (ignore errors) */
- req_submit(cs->bcs, HD_CLOSE_ATCHANNEL, 0, BAS_TIMEOUT);
-
- //FIXME try to recover without bothering the user
- dev_err(cs->dev,
- "unrecoverable error - please disconnect Gigaset base to reset\n");
+ /* reset interrupt pipe to recover (ignore errors) */
+ update_basstate(cs->hw.bas, BS_RESETTING, 0);
+ req_submit(cs->bcs, HD_RESET_INTERRUPT_PIPE, 0, BAS_TIMEOUT);
}
/* check_pending
@@ -398,8 +411,13 @@ static void check_pending(struct bas_cardstate *ucs)
case HD_DEVICE_INIT_ACK: /* no reply expected */
ucs->pending = 0;
break;
- /* HD_READ_ATMESSAGE, HD_WRITE_ATMESSAGE, HD_RESET_INTERRUPTPIPE
- * are handled separately and should never end up here
+ case HD_RESET_INTERRUPT_PIPE:
+ if (!(ucs->basstate & BS_RESETTING))
+ ucs->pending = 0;
+ break;
+ /*
+ * HD_READ_ATMESSAGE and HD_WRITE_ATMESSAGE are handled separately
+ * and should never end up here
*/
default:
dev_warn(&ucs->interface->dev,
@@ -449,21 +467,6 @@ static void cmd_in_timeout(unsigned long data)
error_reset(cs);
}
-/* set/clear bits in base connection state, return previous state
- */
-inline static int update_basstate(struct bas_cardstate *ucs,
- int set, int clear)
-{
- unsigned long flags;
- int state;
-
- spin_lock_irqsave(&ucs->lock, flags);
- state = ucs->basstate;
- ucs->basstate = (state & ~clear) | set;
- spin_unlock_irqrestore(&ucs->lock, flags);
- return state;
-}
-
/* read_ctrl_callback
* USB completion handler for control pipe input
* called by the USB subsystem in interrupt context
@@ -762,7 +765,8 @@ static void read_int_callback(struct urb *urb)
break;
case HD_RESET_INTERRUPT_PIPE_ACK:
- gig_dbg(DEBUG_USBREQ, "HD_RESET_INTERRUPT_PIPE_ACK");
+ update_basstate(ucs, 0, BS_RESETTING);
+ dev_notice(cs->dev, "interrupt pipe reset\n");
break;
case HD_SUSPEND_END:
@@ -1429,6 +1433,7 @@ static void req_timeout(unsigned long data)
case HD_CLOSE_ATCHANNEL:
dev_err(bcs->cs->dev, "timeout closing AT channel\n");
+ error_reset(bcs->cs);
break;
case HD_CLOSE_B2CHANNEL:
@@ -1438,6 +1443,13 @@ static void req_timeout(unsigned long data)
error_reset(bcs->cs);
break;
+ case HD_RESET_INTERRUPT_PIPE:
+ /* error recovery escalation */
+ dev_err(bcs->cs->dev,
+ "reset interrupt pipe timeout, attempting USB reset\n");
+ usb_queue_reset_device(bcs->cs->hw.bas->interface);
+ break;
+
default:
dev_warn(bcs->cs->dev, "request 0x%02x timed out, clearing\n",
pending);
@@ -1930,6 +1942,15 @@ static int gigaset_write_cmd(struct cardstate *cs,
goto notqueued;
}
+ /* translate "+++" escape sequence sent as a single separate command
+ * into "close AT channel" command for error recovery
+ * The next command will reopen the AT channel automatically.
+ */
+ if (len == 3 && !memcmp(buf, "+++", 3)) {
+ rc = req_submit(cs->bcs, HD_CLOSE_ATCHANNEL, 0, BAS_TIMEOUT);
+ goto notqueued;
+ }
+
if (len > IF_WRITEBUF)
len = IF_WRITEBUF;
if (!(cb = kmalloc(sizeof(struct cmdbuf_t) + len, GFP_ATOMIC))) {
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: David Miller @ 2009-09-07 9:00 UTC (permalink / raw)
To: tilman; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp
In-Reply-To: <20090906-patch-gigaset-00.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
> Would you please take these into your net tree for 2.6.32.
So do we have an ISDN maintainer or not?
If Karsten is still maintaining things, your work should
go through him not me.
This also applies to the 4 part CAPI patch set you sent as
well.
I'm tossing these from patchwork as they're not my realm.
:-)
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-07 9:07 UTC (permalink / raw)
To: Daniel Walker; +Cc: davem, linux-kernel, netdev, i4ldeveloper, Hansjoerg Lipp
In-Reply-To: <1252286806.2139.1.camel@desktop>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Daniel,
thanks for taking a look at my patches.
On Sun, 06 Sep 2009 18:26:46 -0700, Daniel Walker wrote:
> patches 6,7,10, and 12 all have checkpatch errors. Could you fix those?
I have reissued patch 7, exchanging the "static" and "inline" keywords
as requested.
The other patches I'd much prefer to keep as they are. The "ERRORs"
checkpatch.pl reported for them are results of keeping to the existing
formatting of the patched files. Completely reformatting them would
cloud the actual changes made by the patches.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-07 9:11 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp
In-Reply-To: <20090907.020038.248900438.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
David Miller schrieb:
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
>
>> Would you please take these into your net tree for 2.6.32.
>
> So do we have an ISDN maintainer or not?
>
> If Karsten is still maintaining things, your work should
> go through him not me.
Last atime I asked, you said me you would take ISDN patches.
Could you two please sort this out? I am just a humble driver
maintainer knowing nothing about maintainer politics.
> This also applies to the 4 part CAPI patch set you sent as
> well.
>
> I'm tossing these from patchwork as they're not my realm.
> :-)
I guess I have no recourse against that.
:-(
T.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: David Miller @ 2009-09-07 9:18 UTC (permalink / raw)
To: tilman; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp, isdn
In-Reply-To: <4AA4CE49.7040501@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Mon, 07 Sep 2009 11:11:37 +0200
> David Miller schrieb:
>> From: Tilman Schmidt <tilman@imap.cc>
>> Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
>>
>>> Would you please take these into your net tree for 2.6.32.
>>
>> So do we have an ISDN maintainer or not?
>>
>> If Karsten is still maintaining things, your work should
>> go through him not me.
>
> Last atime I asked, you said me you would take ISDN patches.
> Could you two please sort this out?
Sure.
Karsten, are you going to handle ISDN and ISDN driver patches
and queue them up to me?
> I am just a humble driver maintainer knowing nothing about
> maintainer politics.
Understood.
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Jarek Poplawski @ 2009-09-07 9:46 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev
In-Reply-To: <20090907.015039.154939751.davem@davemloft.net>
On 07-09-2009 10:50, David Miller wrote:
> I gave these patches a very basic bashing with NIU, and it
> seems to work from what I've tried.
>
> I know that Jarek has expressed some questions about the callback
> scheme used by the new mq classful qdisc, as well as some other
> issues, but we can refine this using followon patches.
>
> For now I'm pushing this out so that it gets wider testing.
Sure, it should make the further discussion easier (at least until
a new backward compatibilty starts to matter ;-).
Thanks,
Jarek P.
^ permalink raw reply
* [PATCH 2.6.31-rc9] mv643xx_eth.c: remove unused txq_set_wrr()
From: Mikael Pettersson @ 2009-09-07 9:59 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: linux-kernel, netdev
The txq_set_wrr() function in drivers/net/mv643xx_eth.c is
unused, not even referenced under #if 0 or something like that,
which results in a compile-time warning:
drivers/net/mv643xx_eth.c:1070: warning: 'txq_set_wrr' defined but not used
Fix: remove it.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
---
drivers/net/mv643xx_eth.c | 34 ----------------------------------
1 file changed, 34 deletions(-)
--- linux-2.6.31-rc9/drivers/net/mv643xx_eth.c.~1~ 2009-09-06 12:20:57.000000000 +0200
+++ linux-2.6.31-rc9/drivers/net/mv643xx_eth.c 2009-09-07 11:36:32.000000000 +0200
@@ -1066,40 +1066,6 @@ static void txq_set_fixed_prio_mode(stru
}
}
-static void txq_set_wrr(struct tx_queue *txq, int weight)
-{
- struct mv643xx_eth_private *mp = txq_to_mp(txq);
- int off;
- u32 val;
-
- /*
- * Turn off fixed priority mode.
- */
- off = 0;
- switch (mp->shared->tx_bw_control) {
- case TX_BW_CONTROL_OLD_LAYOUT:
- off = TXQ_FIX_PRIO_CONF;
- break;
- case TX_BW_CONTROL_NEW_LAYOUT:
- off = TXQ_FIX_PRIO_CONF_MOVED;
- break;
- }
-
- if (off) {
- val = rdlp(mp, off);
- val &= ~(1 << txq->index);
- wrlp(mp, off, val);
-
- /*
- * Configure WRR weight for this queue.
- */
-
- val = rdlp(mp, off);
- val = (val & ~0xff) | (weight & 0xff);
- wrlp(mp, TXQ_BW_WRR_CONF(txq->index), val);
- }
-}
-
/* mii management interface *************************************************/
static irqreturn_t mv643xx_eth_err_irq(int irq, void *dev_id)
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Oliver Hartkopp @ 2009-09-07 10:10 UTC (permalink / raw)
To: Sebastian Haas
Cc: Wolfgang Grandegger, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4CB3F.3060200@grandegger.com>
Wolfgang Grandegger wrote:
> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wolfgang,
>>
>> Wolfgang Grandegger schrieb:
>>> Hi Sebastian,
>>>
>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Oliver,
>>>>
>>>> I'm not yet sure how to actually start the development. There is so
>>>> much
>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>> devices and make tests here.
>>>>
>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>> CAN
>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>> part and write the USB part.
>>>>
>>>> I'll also write a specification which contains any information you need
>>>> to develop a CAN driver for the device (commands, sequences, error
>>>> handling).
>>>
>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>> limited resource. Progress depends on funding to a certain extend.
>> Money is also a limited resource. ;-)
>>
>> Let's become serious again, I know and respect that many of Socket-CAN
>> and the Staging developers spend their free time working on it. We will
>> of course work on the driver, but since we've not much time it may take
>> several months. If someone wants to help, we would be very glad and
>> happy to support the person as far as we can with devices, answers and
>> tests.
>
> OK, no problem. I really appreciate your support for Socket-CAN so far.
Indeed. Me too.
I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
all the procfs and the chardev stuff and then create a CAN netdev when you
identified an USB node analogue to
/* Detect available channels */
for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
dev = alloc_sja1000dev(0);
if (dev == NULL) {
err = -ENOMEM;
goto failure_cleanup;
}
card->net_dev[i] = dev;
priv = netdev_priv(dev);
priv->priv = card;
SET_NETDEV_DEV(dev, &pdev->dev);
as you know from your ems_pcmcia.c driver
and
struct net_device *alloc_sja1000dev(int sizeof_priv)
{
struct net_device *dev;
struct sja1000_priv *priv;
dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
if (!dev)
return NULL;
priv = netdev_priv(dev);
priv->dev = dev;
priv->can.bittiming_const = &sja1000_bittiming_const;
priv->can.do_set_bittiming = sja1000_set_bittiming;
priv->can.do_set_mode = sja1000_set_mode;
if (sizeof_priv)
priv->priv = (void *)priv + sizeof(struct sja1000_priv);
return dev;
}
as you know from the sja1000.c (which can probably be used for the
LPC2119_PRODUCT_ID we should try to implement first).
Then we need something like this stuff
static const struct net_device_ops sja1000_netdev_ops = {
.ndo_open = sja1000_open,
.ndo_stop = sja1000_close,
.ndo_start_xmit = sja1000_start_xmit,
};
int register_sja1000dev(struct net_device *dev)
{
if (!sja1000_probe_chip(dev))
return -ENODEV;
dev->netdev_ops = &sja1000_netdev_ops;
dev->flags |= IFF_ECHO; /* we support local echo */
set_reset_mode(dev);
chipset_init(dev);
return register_candev(dev);
}
from sja1000.c
And then we have an USB CAN node that has a belonging CAN netdevice (maybe
there is something else we can look at that's used in other USB ethernet
adapters).
I know from the PEAK USB driver at
http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
that i just needed to duplicate and modify the usb rx/tx stuff and redirect
the CAN frames into the network stack. But this PEAK driver does not have a
netlink configuration interface and can only be taken as a limited example ...
I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
?) is prepared as described above, one can go and connect the rx/tx dataflow
and the netlink configuration.
Unfortunately i'm short of time the next two weeks but maybe you can start and
create such a new C-file (probably based on ems_pcmcia.c) ?
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-09-07 10:15 UTC (permalink / raw)
To: Ira W. Snyder
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Rusty Russell, s.hetze
In-Reply-To: <20090903183945.GF28651@ovro.caltech.edu>
On Thu, Sep 03, 2009 at 11:39:45AM -0700, Ira W. Snyder wrote:
> On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> > What it is: vhost net is a character device that can be used to reduce
> > the number of system calls involved in virtio networking.
> > Existing virtio net code is used in the guest without modification.
> >
> > There's similarity with vringfd, with some differences and reduced scope
> > - uses eventfd for signalling
> > - structures can be moved around in memory at any time (good for migration)
> > - support memory table and not just an offset (needed for kvm)
> >
> > common virtio related code has been put in a separate file vhost.c and
> > can be made into a separate module if/when more backends appear. I used
> > Rusty's lguest.c as the source for developing this part : this supplied
> > me with witty comments I wouldn't be able to write myself.
> >
> > What it is not: vhost net is not a bus, and not a generic new system
> > call. No assumptions are made on how guest performs hypercalls.
> > Userspace hypervisors are supported as well as kvm.
> >
> > How it works: Basically, we connect virtio frontend (configured by
> > userspace) to a backend. The backend could be a network device, or a
> > tun-like device. In this version I only support raw socket as a backend,
> > which can be bound to e.g. SR IOV, or to macvlan device. Backend is
> > also configured by userspace, including vlan/mac etc.
> >
> > Status:
> > This works for me, and I haven't see any crashes.
> > I have done some light benchmarking (with v4), compared to userspace, I
> > see improved latency (as I save up to 4 system calls per packet) but not
> > bandwidth/CPU (as TSO and interrupt mitigation are not supported). For
> > ping benchmark (where there's no TSO) troughput is also improved.
> >
> > Features that I plan to look at in the future:
> > - tap support
> > - TSO
> > - interrupt mitigation
> > - zero copy
> >
>
> Hello Michael,
>
> I've started looking at vhost with the intention of using it over PCI to
> connect physical machines together.
>
> The part that I am struggling with the most is figuring out which parts
> of the rings are in the host's memory, and which parts are in the
> guest's memory.
All rings are in guest's memory, to match existing virtio code. vhost
assumes that the memory space of the hypervisor userspace process covers
the whole of guest memory. And there's a translation table.
Ring addresses are userspace addresses, they do not undergo translation.
> If I understand everything correctly, the rings are all userspace
> addresses, which means that they can be moved around in physical memory,
> and get pushed out to swap.
Unless they are locked, yes.
> AFAIK, this is impossible to handle when
> connecting two physical systems, you'd need the rings available in IO
> memory (PCI memory), so you can ioreadXX() them instead. To the best of
> my knowledge, I shouldn't be using copy_to_user() on an __iomem address.
> Also, having them migrate around in memory would be a bad thing.
>
> Also, I'm having trouble figuring out how the packet contents are
> actually copied from one system to the other. Could you point this out
> for me?
The code in net/packet/af_packet.c does it when vhost calls sendmsg.
> Is there somewhere I can find the userspace code (kvm, qemu, lguest,
> etc.) code needed for interacting with the vhost misc device so I can
> get a better idea of how userspace is supposed to work?
Look in archives for kvm@vger.kernel.org. the subject is qemu-kvm: vhost net.
> (Features
> negotiation, etc.)
>
> Thanks,
> Ira
That's not yet implemented as there are no features yet. I'm working on
tap support, which will add a feature bit. Overall, qemu does an ioctl
to query supported features, and then acks them with another ioctl. I'm
also trying to avoid duplicating functionality available elsewhere. So
that to check e.g. TSO support, you'd just look at the underlying
hardware device you are binding to.
--
MST
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] Add an alternative cs89x0 driver
From: Sascha Hauer @ 2009-09-07 10:24 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: netdev
In-Reply-To: <20090826104634.GA14425@e-circ.dyndns.org>
Hi Kurt,
On Wed, Aug 26, 2009 at 12:46:34PM +0200, Kurt Van Dijck wrote:
> Hi Sacha,
>
> I'm using a 2.6.25.
> Converting to your platform_device based driver,
> I needed to configure the irq (see patch, irq flags).
> Looking in the old cs89x0.c, it's done in the driver. Should I have
> configured the irq level elsewhere? Or is this patch valid to do?
This is the way to go. I don't know if the cs89x0 has configurable
interrupt levels though.
Sascha
>
> Kurt
>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> ---
> Index: drivers/net/cirrus-cs89x0.c
> ===================================================================
> --- drivers/net/cirrus-cs89x0.c (revision 7107)
> +++ drivers/net/cirrus-cs89x0.c (working copy)
> @@ -487,7 +487,8 @@
> }
>
> /* install interrupt handler */
> - result = request_irq(ndev->irq, &cirrus_interrupt, 0, ndev->name, ndev);
> + result = request_irq(ndev->irq, &cirrus_interrupt,
> + IRQF_TRIGGER_HIGH, ndev->name, ndev);
> if (result < 0) {
> printk(KERN_ERR "%s: could not register interrupt %d\n",
> ndev->name, ndev->irq);
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Wolfgang Grandegger @ 2009-09-07 10:27 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Sebastian Haas, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4DC09.8070803@hartkopp.net>
On 09/07/2009 12:10 PM, Oliver Hartkopp wrote:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>>
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>>
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>
> Indeed. Me too.
>
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
>
> /* Detect available channels */
> for (i = 0; i< EMS_PCMCIA_MAX_CHAN; i++) {
> dev = alloc_sja1000dev(0);
> if (dev == NULL) {
> err = -ENOMEM;
> goto failure_cleanup;
> }
>
> card->net_dev[i] = dev;
> priv = netdev_priv(dev);
> priv->priv = card;
> SET_NETDEV_DEV(dev,&pdev->dev);
>
> as you know from your ems_pcmcia.c driver
>
> and
>
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
> struct net_device *dev;
> struct sja1000_priv *priv;
>
> dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
> if (!dev)
> return NULL;
>
> priv = netdev_priv(dev);
>
> priv->dev = dev;
> priv->can.bittiming_const =&sja1000_bittiming_const;
> priv->can.do_set_bittiming = sja1000_set_bittiming;
> priv->can.do_set_mode = sja1000_set_mode;
>
> if (sizeof_priv)
> priv->priv = (void *)priv + sizeof(struct sja1000_priv);
>
> return dev;
> }
>
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
>
> Then we need something like this stuff
>
> static const struct net_device_ops sja1000_netdev_ops = {
> .ndo_open = sja1000_open,
> .ndo_stop = sja1000_close,
> .ndo_start_xmit = sja1000_start_xmit,
> };
>
> int register_sja1000dev(struct net_device *dev)
> {
> if (!sja1000_probe_chip(dev))
> return -ENODEV;
>
> dev->netdev_ops =&sja1000_netdev_ops;
>
> dev->flags |= IFF_ECHO; /* we support local echo */
>
> set_reset_mode(dev);
> chipset_init(dev);
>
> return register_candev(dev);
> }
>
> from sja1000.c
>
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
>
> I know from the PEAK USB driver at
>
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
>
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
>
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
>
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?
Also, there are USB network driver in "drivers/net/usb/" which might
serve as examples.
Wolfgang.
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Sebastian Haas @ 2009-09-07 11:06 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Wolfgang Grandegger, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4DC09.8070803@hartkopp.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Okay, thanks for the tips. Lets see what I can create today.
Sebastian
Oliver Hartkopp schrieb:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>
> Indeed. Me too.
>
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
>
> /* Detect available channels */
> for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
> dev = alloc_sja1000dev(0);
> if (dev == NULL) {
> err = -ENOMEM;
> goto failure_cleanup;
> }
>
> card->net_dev[i] = dev;
> priv = netdev_priv(dev);
> priv->priv = card;
> SET_NETDEV_DEV(dev, &pdev->dev);
>
> as you know from your ems_pcmcia.c driver
>
> and
>
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
> struct net_device *dev;
> struct sja1000_priv *priv;
>
> dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
> if (!dev)
> return NULL;
>
> priv = netdev_priv(dev);
>
> priv->dev = dev;
> priv->can.bittiming_const = &sja1000_bittiming_const;
> priv->can.do_set_bittiming = sja1000_set_bittiming;
> priv->can.do_set_mode = sja1000_set_mode;
>
> if (sizeof_priv)
> priv->priv = (void *)priv + sizeof(struct sja1000_priv);
>
> return dev;
> }
>
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
>
> Then we need something like this stuff
>
> static const struct net_device_ops sja1000_netdev_ops = {
> .ndo_open = sja1000_open,
> .ndo_stop = sja1000_close,
> .ndo_start_xmit = sja1000_start_xmit,
> };
>
> int register_sja1000dev(struct net_device *dev)
> {
> if (!sja1000_probe_chip(dev))
> return -ENODEV;
>
> dev->netdev_ops = &sja1000_netdev_ops;
>
> dev->flags |= IFF_ECHO; /* we support local echo */
>
> set_reset_mode(dev);
> chipset_init(dev);
>
> return register_candev(dev);
> }
>
> from sja1000.c
>
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
>
> I know from the PEAK USB driver at
>
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
>
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
>
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
>
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?
>
> Best regards,
> Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqk6TcACgkQpqRB8PJG7XzpQACePuMXFX6pSg7EyssTNnDfVomv
Lm0AnA7WKWLHfRny2iF5krEaT966WmPJ
=07pa
-----END PGP SIGNATURE-----
--
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax : +49-8441-81860
http://www.ems-wuensche.com
^ permalink raw reply
* Re: [PATCH 1/2] Add an alternative cs89x0 driver
From: Kurt Van Dijck @ 2009-09-07 12:35 UTC (permalink / raw)
To: Sascha Hauer; +Cc: netdev
In-Reply-To: <20090907102434.GC31592@pengutronix.de>
On Mon, Sep 07, 2009 at 12:24:34PM +0200, Sascha Hauer wrote:
> Date: Mon, 7 Sep 2009 12:24:34 +0200
> Subject: Re: [PATCH 1/2] Add an alternative cs89x0 driver
> From: Sascha Hauer <s.hauer@pengutronix.de>
> To: Kurt Van Dijck <kurt.van.dijck@eia.be>
> Cc: netdev@vger.kernel.org
> List-ID: <netdev.vger.kernel.org>
>
> Hi Kurt,
>
> On Wed, Aug 26, 2009 at 12:46:34PM +0200, Kurt Van Dijck wrote:
> > Hi Sacha,
> >
> > I'm using a 2.6.25.
> > Converting to your platform_device based driver,
> > I needed to configure the irq (see patch, irq flags).
> > Looking in the old cs89x0.c, it's done in the driver. Should I have
> > configured the irq level elsewhere? Or is this patch valid to do?
>
> This is the way to go. I don't know if the cs89x0 has configurable
> interrupt levels though.
I haven't read any spec about cs89x0, but by looking in the existing
code:
1) IRQF_TRIGGER_HIGH seems like the default
2) the old driver didn't do any irq config in the chip either.
May I assume you were lucky testing the driver on a platform that had
IRQF_TRIGGER_HIGH per default?
I have it running (with patch) on a iMX31 (arm)
Kurt
>
> Sascha
>
> >
> > Kurt
> >
> > Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> > ---
> > Index: drivers/net/cirrus-cs89x0.c
> > ===================================================================
> > --- drivers/net/cirrus-cs89x0.c (revision 7107)
> > +++ drivers/net/cirrus-cs89x0.c (working copy)
> > @@ -487,7 +487,8 @@
> > }
> >
> > /* install interrupt handler */
> > - result = request_irq(ndev->irq, &cirrus_interrupt, 0, ndev->name, ndev);
> > + result = request_irq(ndev->irq, &cirrus_interrupt,
> > + IRQF_TRIGGER_HIGH, ndev->name, ndev);
> > if (result < 0) {
> > printk(KERN_ERR "%s: could not register interrupt %d\n",
> > ndev->name, ndev->irq);
> >
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] headers: net/ipv[46]/protocol.c header trim
From: Alexey Dobriyan @ 2009-09-07 12:38 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/ipv4/protocol.c | 19 ++-----------------
net/ipv6/protocol.c | 15 ++-------------
2 files changed, 4 insertions(+), 30 deletions(-)
--- a/net/ipv4/protocol.c
+++ b/net/ipv4/protocol.c
@@ -22,26 +22,11 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
-
-#include <asm/uaccess.h>
-#include <asm/system.h>
+#include <linux/cache.h>
#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/string.h>
-#include <linux/socket.h>
-#include <linux/in.h>
-#include <linux/inet.h>
#include <linux/netdevice.h>
-#include <linux/timer.h>
-#include <net/ip.h>
+#include <linux/spinlock.h>
#include <net/protocol.h>
-#include <linux/skbuff.h>
-#include <net/sock.h>
-#include <net/icmp.h>
-#include <net/udp.h>
-#include <net/ipip.h>
-#include <linux/igmp.h>
struct net_protocol *inet_protos[MAX_INET_PROTOS] ____cacheline_aligned_in_smp;
static DEFINE_SPINLOCK(inet_proto_lock);
--- a/net/ipv6/protocol.c
+++ b/net/ipv6/protocol.c
@@ -20,20 +20,9 @@
* - Removed unused variable 'inet6_protocol_base'
* - Modified inet6_del_protocol() to correctly maintain copy bit.
*/
-
-#include <linux/errno.h>
-#include <linux/types.h>
-#include <linux/socket.h>
-#include <linux/sockios.h>
-#include <linux/net.h>
-#include <linux/in6.h>
+#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/if_arp.h>
-
-#include <net/sock.h>
-#include <net/snmp.h>
-
-#include <net/ipv6.h>
+#include <linux/spinlock.h>
#include <net/protocol.h>
struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
^ 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