* Re: [PATCH] new UDPCP Communication Protocol
From: David Miller @ 2011-01-11 21:19 UTC (permalink / raw)
To: stefani
Cc: eric.dumazet, linux-kernel, akpm, netdev, shemminger, jj,
daniel.baluta, jochen, hagen, torvalds, pavel
In-Reply-To: <1294780480.17388.2.camel@wall-e>
From: Stefani Seibold <stefani@seibold.net>
Date: Tue, 11 Jan 2011 22:14:40 +0100
> If nobody need it and no user in the near future out there, why should i
> implement this? That is dogmatic only!
It's a hard requirement, sorry.
And I want you to do it especially because it shows clearly how poor
your implementation is, with all of it's code duplication.
You'll need yet another copy of all of this code to support ipv6.
Please implement this properly, and in doing so the ipv6 support will
be very simple if not trivial.
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Eric Dumazet @ 2011-01-11 21:30 UTC (permalink / raw)
To: Stefani Seibold
Cc: David Miller, linux-kernel, akpm, netdev, shemminger, jj,
daniel.baluta, jochen, hagen, torvalds, pavel
In-Reply-To: <1294780480.17388.2.camel@wall-e>
Le mardi 11 janvier 2011 à 22:14 +0100, Stefani Seibold a écrit :
> If nobody need it and no user in the near future out there, why should i
> implement this? That is dogmatic only!
>
Sure !
Problem is linux kernel code is not your own project.
Some community rules must be respected.
You call this dogmatic, you are right, since this makes your life less
easy.
However, for hundred of people working to maintain/improve linux kernel
code, especially in network stacks, this ends in less stress, when a
problem must be located, and fixed.
Note : We are trying to help you, not fighting against you, in the long
term, its a win-win for everybody.
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Stefani Seibold @ 2011-01-11 21:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, linux-kernel, akpm, netdev, shemminger, jj,
daniel.baluta, jochen, hagen, torvalds, pavel
In-Reply-To: <1294781427.3447.18.camel@edumazet-laptop>
Am Dienstag, den 11.01.2011, 22:30 +0100 schrieb Eric Dumazet:
> Le mardi 11 janvier 2011 à 22:14 +0100, Stefani Seibold a écrit :
>
> > If nobody need it and no user in the near future out there, why should i
> > implement this? That is dogmatic only!
> >
>
> Sure !
>
> Problem is linux kernel code is not your own project.
>
> Some community rules must be respected.
>
> You call this dogmatic, you are right, since this makes your life less
> easy.
>
Sorry thats not right, i only want write code for the trash bin.
> However, for hundred of people working to maintain/improve linux kernel
> code, especially in network stacks, this ends in less stress, when a
> problem must be located, and fixed.
>
> Note : We are trying to help you, not fighting against you, in the long
> term, its a win-win for everybody.
>
>
Sure, i know this and i would give you and all other contributers a big
thank you for the review.
But it should also okay, to argues against some proposal which makes
currently no sense.
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Stefani Seibold @ 2011-01-11 21:41 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, linux-kernel, akpm, netdev, shemminger, jj,
daniel.baluta, jochen, hagen, torvalds, pavel
In-Reply-To: <20110111.131953.180400101.davem@davemloft.net>
Am Dienstag, den 11.01.2011, 13:19 -0800 schrieb David Miller:
> From: Stefani Seibold <stefani@seibold.net>
> Date: Tue, 11 Jan 2011 22:14:40 +0100
>
> > If nobody need it and no user in the near future out there, why should i
> > implement this? That is dogmatic only!
>
> It's a hard requirement, sorry.
>
> And I want you to do it especially because it shows clearly how poor
> your implementation is, with all of it's code duplication.
>
First it is not so much code duplication. It it less than 20 percent of
the whole code. And most of this code was adapted to the need of the
protocol.
Second, the design is may in your opinion poor. I like it. What is
really poor is the kernel_...() socket functions, which are only simple
wrapper of the system calls without any performance improvement, skb
support and memory saving.
IPv6 would not very hard to implement and will be done if i get an go.
> You'll need yet another copy of all of this code to support ipv6.
>
> Please implement this properly, and in doing so the ipv6 support will
> be very simple if not trivial.
The implementation is clean and fast, it has absolut no side effect. It
is save to merge and all requirement was solved.
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Eric Dumazet @ 2011-01-11 21:46 UTC (permalink / raw)
To: Stefani Seibold
Cc: David Miller, linux-kernel, akpm, netdev, shemminger, jj,
daniel.baluta, jochen, hagen, torvalds, pavel
In-Reply-To: <1294782117.17531.18.camel@wall-e>
Le mardi 11 janvier 2011 à 22:41 +0100, Stefani Seibold a écrit :
> Second, the design is may in your opinion poor. I like it. What is
> really poor is the kernel_...() socket functions, which are only simple
> wrapper of the system calls without any performance improvement, skb
> support and memory saving.
>
The only thing you want is to have a callback to your own code to
deliver an decapsulated skb to your state machine.
Take a look at other layers on top of UDP
(L2TP comes to mind)
^ permalink raw reply
* [PATCH net-26] cxgb4vf: recover from failure in cxgb4vf_open()
From: Casey Leedom @ 2011-01-11 21:57 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
If the Link Start fails in cxgb4vf_open(), we need to back out any state
that we've built up ...
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 3c403f8..56166ae 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -749,13 +749,19 @@ static int cxgb4vf_open(struct net_device *dev)
netif_set_real_num_tx_queues(dev, pi->nqsets);
err = netif_set_real_num_rx_queues(dev, pi->nqsets);
if (err)
- return err;
- set_bit(pi->port_id, &adapter->open_device_map);
+ goto err_unwind;
err = link_start(dev);
if (err)
- return err;
+ goto err_unwind;
+
netif_tx_start_all_queues(dev);
+ set_bit(pi->port_id, &adapter->open_device_map);
return 0;
+
+err_unwind:
+ if (adapter->open_device_map == 0)
+ adapter_down(adapter);
+ return err;
}
/*
@@ -764,13 +770,12 @@ static int cxgb4vf_open(struct net_device *dev)
*/
static int cxgb4vf_stop(struct net_device *dev)
{
- int ret;
struct port_info *pi = netdev_priv(dev);
struct adapter *adapter = pi->adapter;
netif_tx_stop_all_queues(dev);
netif_carrier_off(dev);
- ret = t4vf_enable_vi(adapter, pi->viid, false, false);
+ t4vf_enable_vi(adapter, pi->viid, false, false);
pi->link_cfg.link_ok = 0;
clear_bit(pi->port_id, &adapter->open_device_map);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Marc Kleine-Budde @ 2011-01-11 22:01 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Wolfram Sang, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Oliver Hartkopp, David Miller
In-Reply-To: <4D2CA0AA.6080505-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 938 bytes --]
On 01/11/2011 07:25 PM, Wolfgang Grandegger wrote:
[...]
> I was told that Bosch's page for the C_CAN is here:
>
> http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/c_can/c_can.asp
>
> There it's also written for what bus interfaces the C_CAN is available for, e.g.:
>
> "The ASIC version is delivered with the AMBA APB bus interface from ARM."
On ARM we also have the AMBA bus abstraction in Linux, but I've never
worked with it. IIRC Wolfram (Cc'ed) has recently touched it.
> which is obviously used in the "Platform Controller Hub" eg20t.
But in the pch, they've attached the AMBA to the PCI bus.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH] tcp: disallow bind() to reuse addr/port
From: David Miller @ 2011-01-11 22:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: daniel.baluta, gasparch, netdev
In-Reply-To: <1294744462.2927.53.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 11 Jan 2011 12:14:22 +0100
> [PATCH] tcp: disallow bind() to reuse addr/port
>
> inet_csk_bind_conflict() logic currently disallows a bind() if
> it finds a friend socket (a socket bound on same address/port)
> satisfying a set of conditions :
>
> 1) Current (to be bound) socket doesnt have sk_reuse set
> OR
> 2) other socket doesnt have sk_reuse set
> OR
> 3) other socket is in LISTEN state
>
> We should add the CLOSE state in the 3) condition, in order to avoid two
> REUSEADDR sockets in CLOSE state with same local address/port, since
> this can deny further operations.
>
> Note : a prior patch tried to address the problem in a different (and
> buggy) way. (commit fda48a0d7a8412ced tcp: bind() fix when many ports
> are bound).
>
> Reported-by: Gaspar Chilingarov <gasparch@gmail.com>
> Reported-by: Daniel Baluta <daniel.baluta@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/fec: remove config FEC2 as it's used nowhere
From: David Miller @ 2011-01-11 22:03 UTC (permalink / raw)
To: shawn.guo
Cc: gerg, baruch, eric, bryan.wu, r64343, B32542, u.kleine-koenig, lw,
w.sang, s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <1294747672-4433-1-git-send-email-shawn.guo@freescale.com>
From: Shawn Guo <shawn.guo@freescale.com>
Date: Tue, 11 Jan 2011 20:07:52 +0800
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ehea: Increase the skb array usage
From: David Miller @ 2011-01-11 22:04 UTC (permalink / raw)
To: leitao; +Cc: netdev
In-Reply-To: <1294767957-25804-1-git-send-email-leitao@linux.vnet.ibm.com>
From: leitao@linux.vnet.ibm.com
Date: Tue, 11 Jan 2011 15:45:57 -0200
> From: Breno Leitao <leitao@linux.vnet.ibm.com>
>
> Currently the skb array is not fully allocated, and the allocation
> is done as it' s requested, which is not the expected way.
>
> This patch just allocate the full skb array at driver initialization.
> Also, this patch increases ehea version to 107.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH kernel 2.6.37] pcnet_cs: add new_id
From: David Miller @ 2011-01-11 22:04 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20110111205558.98fcab01.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Tue, 11 Jan 2011 20:55:58 +0900
>
> pcnet_cs:
> add another ID of "corega Ether CF-TD" 10Base-T PCMCIA card.
>
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied.
^ permalink raw reply
* Re: [PATCH] ah: reload pointers to skb data after calling skb_cow_data()
From: David Miller @ 2011-01-11 22:04 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, steffen.klassert
In-Reply-To: <4D2C8FBD.8060701@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 11 Jan 2011 18:13:33 +0100
>>From ba44ef6e00ca0f4c13e425f4a39e8749c56db843 Mon Sep 17 00:00:00 2001
> From: Dang Hongwu <hongwu.dang@6wind.com>
> Date: Tue, 11 Jan 2011 12:00:05 -0500
> Subject: [PATCH] ah: reload pointers to skb data after calling skb_cow_data()
>
> skb_cow_data() may allocate a new data buffer, so pointers on
> skb should be set after this function.
>
> Bug was introduced by commit dff3bb06 and 8631e9bd.
>
> Signed-off-by: Wang Xuefu <xuefu.wang@6wind.com>
> Acked-by: Krzysztof Witek <krzysztof.witek@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xfrm: check trunc_len in XFRMA_ALG_AUTH_TRUNC
From: David Miller @ 2011-01-11 22:04 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4D2C9B9C.9020800@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 11 Jan 2011 19:04:12 +0100
>>From 48dd29c69f150fc55bf3a477b9365d1575a9cfbe Mon Sep 17 00:00:00 2001
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Tue, 11 Jan 2011 13:23:51 -0500
> Subject: [PATCH] xfrm: check trunc_len in XFRMA_ALG_AUTH_TRUNC
>
> Maximum trunc length is defined by MAX_AH_AUTH_LEN (in bytes)
> and need to be checked when this value is set (in bits) by
> the user. In ah4.c and ah6.c a BUG_ON() checks this condiftion.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ah: update maximum truncated ICV length
From: David Miller @ 2011-01-11 22:05 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4D2C9C1B.1030907@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 11 Jan 2011 19:06:19 +0100
>>From 2ca463cf672f000d37a0aaa5e3d3738b50661926 Mon Sep 17 00:00:00 2001
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Thu, 23 Dec 2010 09:52:21 -0500
> Subject: [PATCH] ah: update maximum truncated ICV length
>
> For SHA256, RFC4868 requires to truncate ICV length to 128 bits,
> hence MAX_AH_AUTH_LEN should be updated to 16.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Stefani Seibold @ 2011-01-11 22:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, linux-kernel, akpm, netdev, shemminger, jj,
daniel.baluta, jochen, hagen, torvalds, pavel
In-Reply-To: <1294782386.3447.21.camel@edumazet-laptop>
Am Dienstag, den 11.01.2011, 22:46 +0100 schrieb Eric Dumazet:
> Le mardi 11 janvier 2011 à 22:41 +0100, Stefani Seibold a écrit :
>
> > Second, the design is may in your opinion poor. I like it. What is
> > really poor is the kernel_...() socket functions, which are only simple
> > wrapper of the system calls without any performance improvement, skb
> > support and memory saving.
> >
>
> The only thing you want is to have a callback to your own code to
> deliver an decapsulated skb to your state machine.
>
> Take a look at other layers on top of UDP
>
> (L2TP comes to mind)
>
I have looked on it. And it will not work since UDPCP is UDP. And so
IPPROTO_UDP (17) is still handled by the UDP handler.
Despite this it will also make no sense to rewrite the whole UDP socket
layer.
The only thing i have found with comes near to my requirements is the
rxrpc module, but i see no real different to my solution.
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] ipvs namespaces
From: David Miller @ 2011-01-11 22:34 UTC (permalink / raw)
To: horms
Cc: netfilter-devel, lvs-devel, netdev, kaber, ja, hans.schillstrom,
davem
In-Reply-To: <20110111062114.GA5630@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Tue, 11 Jan 2011 15:21:14 +0900
> Patrick seems to be rather quiet (perhaps he is on holidays?).
> Could you consider taking these changes through your tree as
> it would be nice to get this feature in 2.6.38?
Patrick seems to be coming back up to speed. And also we're trying
to setup a situation where Pablo is able to pick up the slack when
Patrick is away or busy.
So it's let's try to get your changes merged that way. :-)
^ permalink raw reply
* Re: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Wolfram Sang @ 2011-01-11 22:38 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Oliver Hartkopp, David Miller, Wolfgang Grandegger
In-Reply-To: <4D2CD34B.8000609-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1117 bytes --]
On Tue, Jan 11, 2011 at 11:01:47PM +0100, Marc Kleine-Budde wrote:
> On 01/11/2011 07:25 PM, Wolfgang Grandegger wrote:
>
> [...]
>
> > I was told that Bosch's page for the C_CAN is here:
> >
> > http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/c_can/c_can.asp
> >
> > There it's also written for what bus interfaces the C_CAN is available for, e.g.:
> >
> > "The ASIC version is delivered with the AMBA APB bus interface from ARM."
>
> On ARM we also have the AMBA bus abstraction in Linux, but I've never
> worked with it. IIRC Wolfram (Cc'ed) has recently touched it.
For a programmer, it feels very much like a platform-bus (you can even use
amba-devices on a platform_bus); it has the advantage of some identification
registers at the end of the address-space. The rest is more about how to
connect the core to the SoC. Does that help? I don't know what the actual
question is :)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Marc Kleine-Budde @ 2011-01-11 22:48 UTC (permalink / raw)
To: Wolfram Sang
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Oliver Hartkopp, David Miller, Wolfgang Grandegger
In-Reply-To: <20110111223843.GB18762-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1630 bytes --]
On 01/11/2011 11:38 PM, Wolfram Sang wrote:
> On Tue, Jan 11, 2011 at 11:01:47PM +0100, Marc Kleine-Budde wrote:
>> On 01/11/2011 07:25 PM, Wolfgang Grandegger wrote:
>>
>> [...]
>>
>>> I was told that Bosch's page for the C_CAN is here:
>>>
>>> http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/c_can/c_can.asp
>>>
>>> There it's also written for what bus interfaces the C_CAN is available for, e.g.:
>>>
>>> "The ASIC version is delivered with the AMBA APB bus interface from ARM."
>>
>> On ARM we also have the AMBA bus abstraction in Linux, but I've never
>> worked with it. IIRC Wolfram (Cc'ed) has recently touched it.
>
> For a programmer, it feels very much like a platform-bus (you can even use
> amba-devices on a platform_bus); it has the advantage of some identification
> registers at the end of the address-space. The rest is more about how to
> connect the core to the SoC. Does that help? I don't know what the actual
> question is :)
No real question so far. Bhupesh is hacking a generic c_can driver and
platform bus bindings. The question might be do we need the platform bus
bindings or is it better to have AMBA bindings? The platform driver
supports 16 and 32 bit attached devices, via IORESOURCE_MEM_{16,32}BIT.
Where do we have to look for the AMBA id registers?
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] ipvs namespaces
From: Simon Horman @ 2011-01-11 23:01 UTC (permalink / raw)
To: David Miller
Cc: netfilter-devel, lvs-devel, netdev, kaber, ja, hans.schillstrom,
davem
In-Reply-To: <20110111.143445.135961091.davem@davemloft.net>
On Tue, Jan 11, 2011 at 02:34:45PM -0800, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Tue, 11 Jan 2011 15:21:14 +0900
>
> > Patrick seems to be rather quiet (perhaps he is on holidays?).
> > Could you consider taking these changes through your tree as
> > it would be nice to get this feature in 2.6.38?
>
> Patrick seems to be coming back up to speed. And also we're trying
> to setup a situation where Pablo is able to pick up the slack when
> Patrick is away or busy.
>
> So it's let's try to get your changes merged that way. :-)
No problem, lets do that :-)
^ permalink raw reply
* Re: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Wolfram Sang @ 2011-01-11 23:05 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Oliver Hartkopp, David Miller, Wolfgang Grandegger
In-Reply-To: <4D2CDE49.3030302-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1297 bytes --]
> platform bus bindings. The question might be do we need the platform bus
> bindings or is it better to have AMBA bindings? The platform driver
> supports 16 and 32 bit attached devices, via IORESOURCE_MEM_{16,32}BIT.
platform_bus might be more generic. Depends on how many possibilities there
exist to connect the core to $something.
> Where do we have to look for the AMBA id registers?
I'll let the code speak (drivers/amba/bus.c):
/*
* Read pid and cid based on size of resource
* they are located at end of region
*/
for (pid = 0, i = 0; i < 4; i++)
pid |= (readl(tmp + size - 0x20 + 4 * i) & 255) <<
(i * 8);
for (cid = 0, i = 0; i < 4; i++)
cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
(i * 8);
amba_put_disable_pclk(dev);
if (cid == AMBA_CID)
dev->periphid = pid;
if (!dev->periphid)
ret = -ENODEV;
with AMBA_CID being (include/linux/amba/bus.h):
#define AMBA_CID 0xb105f00d
periphid is used to match the driver to the device then. If done correctly, it
should have been registered with ARM Ltd. before (AFAIK).
Good night,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH net-26] cxgb4vf: recover from failure in cxgb4vf_open()
From: David Miller @ 2011-01-11 23:44 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <1294783079-7481-1-git-send-email-leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Tue, 11 Jan 2011 13:57:59 -0800
> If the Link Start fails in cxgb4vf_open(), we need to back out any state
> that we've built up ...
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.4)
From: Stephen Hemminger @ 2011-01-11 23:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1294727650.4148.20.camel@edumazet-laptop>
On Tue, 11 Jan 2011 07:34:10 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 11 janvier 2011 à 07:18 +0100, Eric Dumazet a écrit :
> > Le lundi 10 janvier 2011 à 17:10 -0800, Stephen Hemminger a écrit :
> > > OK, put that in.
> >
> > Thanks !
> >
> > > >
> > > > Here we missed :
> > > >
> > > > q->tab = ntab;
> > > >
> >
> > We also need to change
> >
> > .peek = qdisc_peek_head,
> >
> > to
> >
> > .peek = choke_peek_head,
> >
> > static struct sk_buff *choke_peek_head(struct Qdisc *sch)
> > {
> > struct choke_sched_data *q = qdisc_priv(sch);
> >
> > return (q->head != q->tail) ? q->tab[q->head] : NULL;
> > }
> >
> >
>
>
> And to correctly work with CBQ (at least...), we need to update
> sch->q.qlen = choke_len(q) - q->holes;
> in dequeue() and enqueue()
>
> Here is the version I successfully tested, with 30000 packets in
> queue :)
>
> qdisc choke 11: parent 1:11 limit 70000b min 10000b max 30000b ewma 1 Plog 16 Scell_log 11
> Sent 62099201 bytes 112920 pkt (dropped 367712, overlimits 282668 requeues 0)
> rate 21344Kbit 4851pps backlog 39877589b 30001p requeues 0
> marked 0 early 282668 pdrop 0 other 0
Maybe we should take over one of the red counters for the probabilistic match drop.
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.4)
From: Eric Dumazet @ 2011-01-12 0:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110111154806.6525e210@s6510>
Le mardi 11 janvier 2011 à 15:48 -0800, Stephen Hemminger a écrit :
> On Tue, 11 Jan 2011 07:34:10 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > qdisc choke 11: parent 1:11 limit 70000b min 10000b max 30000b ewma 1 Plog 16 Scell_log 11
> > Sent 62099201 bytes 112920 pkt (dropped 367712, overlimits 282668 requeues 0)
> > rate 21344Kbit 4851pps backlog 39877589b 30001p requeues 0
> > marked 0 early 282668 pdrop 0 other 0
>
> Maybe we should take over one of the red counters for the probabilistic match drop.
>
aka chokedrop ;)
Anyway, iproute2 should be tweaked a bit, since limit/min/max are
packets, not bytes like RED. It would be nice to print probability
too ;)
AFAIK, requeue counter is not anymore used (On leaves at least), we
could re-use it for chokedrop
----
qdisc choke 11: parent 1:11 limit 70000p min 10000p max 30000p proba 0.08
Sent 62099201 bytes 112920 pkt (dropped 367712, overlimits 282668 chokedrop 999)
rate 21344Kbit 4851pps backlog 39877589b 30001p chokedrop 999
marked 0 early 282668 pdrop 0 other 0
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] ipvs namespaces
From: Pablo Neira Ayuso @ 2011-01-12 0:15 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, netfilter-devel, lvs-devel, netdev, kaber, ja,
hans.schillstrom, davem
In-Reply-To: <20110111230118.GK3848@verge.net.au>
On 12/01/11 00:01, Simon Horman wrote:
> On Tue, Jan 11, 2011 at 02:34:45PM -0800, David Miller wrote:
>> From: Simon Horman <horms@verge.net.au>
>> Date: Tue, 11 Jan 2011 15:21:14 +0900
>>
>>> Patrick seems to be rather quiet (perhaps he is on holidays?).
>>> Could you consider taking these changes through your tree as
>>> it would be nice to get this feature in 2.6.38?
>>
>> Patrick seems to be coming back up to speed. And also we're trying
>> to setup a situation where Pablo is able to pick up the slack when
>> Patrick is away or busy.
>>
>> So it's let's try to get your changes merged that way. :-)
>
> No problem, lets do that :-)
JFYI: I'll start iterating through the pending patches (since Dec 16th)
to apply them to 2.6.38-rc tomorrow.
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] ipvs namespaces
From: Simon Horman @ 2011-01-12 0:20 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Miller, netfilter-devel, lvs-devel, netdev, kaber, ja,
hans.schillstrom, davem
In-Reply-To: <4D2CF289.1@netfilter.org>
On Wed, Jan 12, 2011 at 01:15:05AM +0100, Pablo Neira Ayuso wrote:
> On 12/01/11 00:01, Simon Horman wrote:
> > On Tue, Jan 11, 2011 at 02:34:45PM -0800, David Miller wrote:
> >> From: Simon Horman <horms@verge.net.au>
> >> Date: Tue, 11 Jan 2011 15:21:14 +0900
> >>
> >>> Patrick seems to be rather quiet (perhaps he is on holidays?).
> >>> Could you consider taking these changes through your tree as
> >>> it would be nice to get this feature in 2.6.38?
> >>
> >> Patrick seems to be coming back up to speed. And also we're trying
> >> to setup a situation where Pablo is able to pick up the slack when
> >> Patrick is away or busy.
> >>
> >> So it's let's try to get your changes merged that way. :-)
> >
> > No problem, lets do that :-)
>
> JFYI: I'll start iterating through the pending patches (since Dec 16th)
> to apply them to 2.6.38-rc tomorrow.
Thanks Pablo.
^ 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