* [GIT] Networking
From: David Miller @ 2011-01-12 0:24 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, netfilter-devel, linux-wireless, linux-kernel
Mostly driver stuff (as usual), a TCP bind fix, some checksum
offloading cures, and random other small bits all over.
1) Fix signedness bugs in phonet, from Dan Carpenter.
2) Sequence number checking fixes in DCCP from Samuel Jero and
Gerrit Renker.
3) Support both ports of FEC ethernet device properly, from
Shawn Guo.
4) Memory leak fix in hamradio and ATM ambassador driver from Jesper
Juhl.
5) MSI interrupt and statistic handling fixes in bnx2x from Vladislav
Zolotarov and Eilon Greenstein.
6) Autonegotiation and VLAN fixes in sky2 from Stephen Hemminger.
7) Power management fixes in forcedeth from Rafael J. Wysocki.
8) Fix handling of NLM_F_ROOT | NLM_F_MATCH (can be mistaken as
a NLM_F_DUMP request) in genetlink. From Jan Engelhardt.
9) Kernel doc fixes in net/sock.h and net/core/filter.c from Randy
Dunlap
10) Do PHY init, and thus firmware request, at ->open() time to
workaround bootup 60 second delay when r8169 is built statically
into the kernel. From Francois Romieu.
11) Checksumming offload flags are handled improperly, in particular
when VLAN's are nested. From Jesse Gross.
12) Various Intel wired driver fixes from Bruce Allan, Jeff Kirsher,
Dirk Brandewie, Yi Zou, and Alexander Duyck.
13) Software interrupts are disabled way too long when reading counters
(for "iptables -L" output, for example). Fix from Eric Dumazet.
14) bfin_mac driver has to disable checksum offloading when a writeback
cache is in use, since corrupt packets can result, fix from
Sonic Zhang.
15) Firmware version detection and ethtool diag dixes in qlcnic from
Amit Kumar Salecha and Sony Chacko.
16) Mailbox register coherency, and ->open() failure unwinding fixes
in cxgb4vf from Casey Leedom.
17) On user copy failure, we erroneously leave the connection request
parameter size set, in CAIF protocol. Fix from Dan Rosenberg.
18) MLX4 driver needs to be able to allocate different numbers of
TX vs. RX queues, add a helper for that and use it. From Tom
Herbert.
19) Only HTB scheduler handles packet counting in statistics properly
wrt. segmented SKBs. Fix this by creating a helper function and
using it everywhere. From Eric Dumazet.
20) Firewire needs to be able to invalidate specific ARP entries since
it uses ARP to discover private info about firewiare network nodes.
From Maxim Levitsky.
21) IPV6 not handled properly in CAIF, fix from Sjur Braendeland and
Kumar Sanghvi.
22) Firmware parsing function in r8169 needs some minor tweaks, from
Hayes Wang.
23) TCP binding bug fix from Eric Dumazet.
24) ehea RX ring initialization fix on device up from Breno Leitao.
25) AUTH truncation bug fixes in IPSEC from Nicolas Dichtel.
26) AH protocol header parsing needs to reload pointers after
skb COW, also from Nicolas Dichtel.
27) Fix netfilter conntrack race between table dumping and destroy of
entries, from Stephen Hemminger.
28) RCU annotation addition to bridge netfilter broke broute table,
fix from Florian Westphal.
Please pull, thanks a lot!
The following changes since commit 0c21e3aaf6ae85bee804a325aa29c325209180fd:
Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/hch/hfsplus (2011-01-07 17:16:27 -0800)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alexander Duyck (3):
ixgbe: cleanup flow director hash computation to improve performance
ixgbe: further flow director performance optimizations
ixgbe: update ntuple filter configuration
Breno Leitao (1):
ehea: Increase the skb array usage
Bruce Allan (6):
e1000e: cleanup variables set but not used
e1000e: convert calls of ops.[read|write]_reg to e1e_[r|w]phy
e1000e: properly bounds-check string functions
e1000e: use either_crc_le() rather than re-write it
e1000e: power off PHY after reset when interface is down
e1000e: add custom set_d[0|3]_lplu_state function pointer for 82574
Casey Leedom (2):
cxgb4vf: fix mailbox data/control coherency domain race
cxgb4vf: recover from failure in cxgb4vf_open()
Changli Gao (1):
net: ppp: use {get,put}_unaligned_be{16,32}
Dan Carpenter (1):
phonet: some signedness bugs
Dan Rosenberg (1):
caif: don't set connection request param size before copying data
Dang Hongwu (1):
ah: reload pointers to skb data after calling skb_cow_data()
David S. Miller (2):
Merge branch 'dccp' of git://eden-feed.erg.abdn.ac.uk/net-next-2.6
Merge branch 'master' of git://1984.lsi.us.es/net-2.6
Dirk Brandewie (1):
e1000: Add support for the CE4100 reference platform
Eric Dumazet (3):
netfilter: x_tables: dont block BH while reading counters
net_sched: factorize qdisc stats handling
tcp: disallow bind() to reuse addr/port
Florian Westphal (1):
netfilter: ebtables: make broute table work again
Gerrit Renker (1):
dccp: make upper bound for seq_window consistent on 32/64 bit
Jan Engelhardt (1):
netlink: test for all flags of the NLM_F_DUMP composite
Jesper Juhl (2):
hamradio: Resolve memory leak due to missing firmware release in add_mcs()
Madge Ambassador ATM Adapter driver: Always release_firmware() in ucode_init() and don't leak memory.
Jesse Gross (6):
net offloading: Accept NETIF_F_HW_CSUM for all protocols.
net offloading: Generalize netif_get_vlan_features().
net offloading: Pass features into netif_needs_gso().
net offloading: Convert dev_gso_segment() to use precomputed features.
net offloading: Convert skb_need_linearize() to use precomputed features.
net offloading: Convert checksums to use centrally computed features.
Ken Kawasaki (1):
pcnet_cs: add new_id
Kumar Sanghvi (1):
CAIF: Fix IPv6 support in receive path for GPRS/3G
Maxim Levitsky (1):
arp: allow to invalidate specific ARP entries
Mike Frysinger (4):
netdev: bfin_mac: clean up printk messages
netdev: bfin_mac: mark setup_system_regs as static
netdev: bfin_mac: drop unused Mac data
netdev: bfin_mac: let boards set vlan masks
Nicolas Dichtel (2):
xfrm: check trunc_len in XFRMA_ALG_AUTH_TRUNC
ah: update maximum truncated ICV length
Rafael J. Wysocki (1):
forcedeth: Do not use legacy PCI power management
Randy Dunlap (2):
net/sock.h: make some fields private to fix kernel-doc warning(s)
net: fix kernel-doc warning in core/filter.c
Samuel Jero (2):
dccp: fix return value for sequence-invalid packets
dccp: fix bug in updating the GSR
Shawn Guo (6):
net/fec: fix MMFR_OP type in fec_enet_mdio_write
net/fec: remove the use of "index" which is legacy
net/fec: add mac field into platform data and consolidate fec_get_mac
net/fec: improve pm for better suspend/resume
net/fec: add dual fec support for mx28
net/fec: remove config FEC2 as it's used nowhere
Sonic Zhang (1):
netdev: bfin_mac: disable hardware checksum if writeback cache is enabled
Sony Chacko (1):
qlcnic: fix ethtool diagnostics test
Stephen Hemminger (3):
sky2: fix limited auto negotiation
sky2: convert to new VLAN model (v0.2)
netfilter: fix race in conntrack between dump_table and destroy
Tom Herbert (2):
net: Add alloc_netdev_mqs function
mlx4: Call alloc_etherdev to allocate RX and TX queues
Vladislav Zolotarov (4):
bnx2x: Don't prevent RSS configuration in INT#x and MSI interrupt modes.
bnx2x: registers dump fixes
bnx2x: Move to D0 before clearing MSI/MSI-X configuration.
bnx2x: Fix the race on bp->stats_pending.
Yi Zou (1):
ixgbe: make sure per Rx queue is disabled before unmapping the receive buffer
amit salecha (2):
qlcnic: fix flash fw version read
qlcnic: change module parameter permissions
françois romieu (1):
r8169: delay phy init until device opens.
hayeswang (1):
net/r8169: Update the function of parsing firmware
Documentation/networking/dccp.txt | 1 +
drivers/atm/ambassador.c | 19 +-
drivers/net/Kconfig | 9 +-
drivers/net/bfin_mac.c | 74 ++--
drivers/net/bfin_mac.h | 11 +-
drivers/net/bnx2x/bnx2x.h | 1 +
drivers/net/bnx2x/bnx2x_dump.h | 988 +++++++++++++++++++--------------
drivers/net/bnx2x/bnx2x_ethtool.c | 22 +-
drivers/net/bnx2x/bnx2x_init.h | 220 ++++++++
drivers/net/bnx2x/bnx2x_main.c | 70 +--
drivers/net/bnx2x/bnx2x_reg.h | 74 +++
drivers/net/bnx2x/bnx2x_stats.c | 5 +
drivers/net/cxgb4vf/cxgb4vf_main.c | 15 +-
drivers/net/cxgb4vf/t4vf_hw.c | 11 +
drivers/net/e1000/e1000_hw.c | 328 +++++++++---
drivers/net/e1000/e1000_hw.h | 59 ++-
drivers/net/e1000/e1000_main.c | 35 ++
drivers/net/e1000/e1000_osdep.h | 19 +-
drivers/net/e1000e/82571.c | 77 +++-
drivers/net/e1000e/e1000.h | 3 +
drivers/net/e1000e/es2lan.c | 4 +-
drivers/net/e1000e/ethtool.c | 54 ++-
drivers/net/e1000e/hw.h | 1 +
drivers/net/e1000e/ich8lan.c | 77 +--
drivers/net/e1000e/lib.c | 3 +-
drivers/net/e1000e/netdev.c | 53 ++-
drivers/net/e1000e/phy.c | 40 +-
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 6 +-
drivers/net/fec.c | 248 ++++++---
drivers/net/fec.h | 5 +-
drivers/net/forcedeth.c | 34 +-
drivers/net/hamradio/yam.c | 4 +-
drivers/net/ixgbe/ixgbe.h | 21 +-
drivers/net/ixgbe/ixgbe_82599.c | 749 ++++++++++----------------
drivers/net/ixgbe/ixgbe_ethtool.c | 142 ++++--
drivers/net/ixgbe/ixgbe_main.c | 169 +++++--
drivers/net/ixgbe/ixgbe_type.h | 91 ++--
drivers/net/mlx4/en_netdev.c | 3 +-
drivers/net/pcmcia/pcnet_cs.c | 1 +
drivers/net/ppp_async.c | 10 +-
drivers/net/ppp_deflate.c | 9 +-
drivers/net/ppp_generic.c | 9 +-
drivers/net/ppp_mppe.c | 7 +-
drivers/net/ppp_synctty.c | 3 +-
drivers/net/qlcnic/qlcnic.h | 24 +-
drivers/net/qlcnic/qlcnic_ethtool.c | 2 +-
drivers/net/qlcnic/qlcnic_init.c | 63 +++-
drivers/net/qlcnic/qlcnic_main.c | 10 +-
drivers/net/r8169.c | 143 +++++-
drivers/net/sky2.c | 143 +++---
drivers/net/sky2.h | 6 +-
drivers/net/xen-netfront.c | 2 +-
include/linux/bfin_mac.h | 1 +
include/linux/etherdevice.h | 4 +-
include/linux/fec.h | 3 +
include/linux/if_bridge.h | 2 +-
include/linux/netdevice.h | 24 +-
include/linux/netfilter/x_tables.h | 10 +-
include/net/ah.h | 2 +-
include/net/arp.h | 1 +
include/net/phonet/phonet.h | 4 +-
include/net/sch_generic.h | 20 +-
include/net/sock.h | 4 +
net/caif/caif_socket.c | 2 +-
net/caif/chnl_net.c | 18 +-
net/core/dev.c | 149 +++---
net/core/filter.c | 2 +-
net/core/rtnetlink.c | 2 +-
net/dccp/dccp.h | 3 +-
net/dccp/input.c | 2 +-
net/dccp/sysctl.c | 4 +-
net/ethernet/eth.c | 12 +-
net/ipv4/ah4.c | 7 +-
net/ipv4/arp.c | 29 +-
net/ipv4/inet_connection_sock.c | 5 +-
net/ipv4/inet_diag.c | 2 +-
net/ipv4/netfilter/arp_tables.c | 45 +--
net/ipv4/netfilter/ip_tables.c | 45 +--
net/ipv6/ah6.c | 8 +-
net/ipv6/inet6_connection_sock.c | 2 +-
net/ipv6/netfilter/ip6_tables.c | 45 +--
net/netfilter/nf_conntrack_netlink.c | 18 +-
net/netfilter/x_tables.c | 3 +-
net/netlink/genetlink.c | 2 +-
net/phonet/af_phonet.c | 6 +-
net/sched/act_csum.c | 3 +-
net/sched/act_ipt.c | 3 +-
net/sched/act_mirred.c | 3 +-
net/sched/act_nat.c | 3 +-
net/sched/act_pedit.c | 3 +-
net/sched/act_police.c | 3 +-
net/sched/act_simple.c | 3 +-
net/sched/act_skbedit.c | 3 +-
net/sched/sch_atm.c | 6 +-
net/sched/sch_cbq.c | 6 +-
net/sched/sch_drr.c | 8 +-
net/sched/sch_dsmark.c | 3 +-
net/sched/sch_hfsc.c | 6 +-
net/sched/sch_htb.c | 17 +-
net/sched/sch_ingress.c | 3 +-
net/sched/sch_multiq.c | 3 +-
net/sched/sch_netem.c | 6 +-
net/sched/sch_prio.c | 3 +-
net/sched/sch_red.c | 3 +-
net/sched/sch_sfq.c | 3 +-
net/sched/sch_tbf.c | 3 +-
net/sched/sch_teql.c | 3 +-
net/xfrm/xfrm_user.c | 6 +-
109 files changed, 2901 insertions(+), 1867 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [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
* 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: [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: [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: [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: [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: [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: 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: [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: [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] 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: [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] 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: 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 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] 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] 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] 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-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
* [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] 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
* 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: 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: 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
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