* re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
From: devzero @ 2014-11-12 21:46 UTC (permalink / raw)
To: netdev; +Cc: thockin
hi,
as i`m doing a little project with this older devices, i have come across this issue again and had some fun to dig deeper into it.
it`s a little bit academic, as i can do ifconfig eth0 hw ether..... as a workaround, but it sucks to hack that into startup scripts and i also have seen udev not playing nicely with it.
apparently the problem is being caused by a timing issue in the natsemi driver.
i added some debug printk`s in natsemi.c -> eeprom_read() after each occurrence of eeprom_delay(ee_addr); , and the problem went away.
there is a hint about timing sensitivity in the code:
/* Delay between EEPROM clock transitions.
No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need
a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that
made udelay() unreliable.
The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
deprecated.
*/
looking at the source of natsemi-diag.c made me wonder why that utility is using
#define eeprom_delay(ee_addr) inl(ee_addr)
instead of
#define eeprom_delay(ee_addr) readl(ee_addr)
and apparently, that also fixes the problem (but gives a compile warning):
drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ:
drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of âinlâ makes integer from pointer without a cast [enabled by default]
In file included from include/linux/io.h:22:0,
from include/linux/pci.h:54,
from drivers/net/ethernet/natsemi/natsemi.c:38:
looking at a more recent version of natsemi-diag.c , i even found this one:
ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c
/* Delay between EEPROM clock transitions.
This flushes the write buffer to prevent quick double-writes.
*/
#define eeprom_delay(ee_addr) inl(ee_addr); inl(ee_addr)
The question is how to make a proper fix, as i don`t know what to pass to inl() , as it seems it should not get an mmapped adress but an i/o port instead !?
"The in*() functions return data read from the specified I/O port"
"The read*() functions read data from device memory previously mapped by map_memory()"
regards
roland
ps: CC driver maintainer from Kernel Maintainers file.
Roland Kletzing | 17 Dec 13:38 2012
bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
Hello,
i recently played with my older evo t20/wyse 3235le thin clients and flashed
a linux kernel into those, apparently there seems an issue with the natsemi
driver.
after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and
ifconfig shows just zero`s: 00:00:00:00:00:00.
despite that , the nic is working fine for me (in this test setup i set the
mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef )
apparently, the driver fails to read the proper mac from the eeprom, as
"natsemi-diag -ee" (from nictools-pci in debian squeeze) shows, that there
is a valid "Ethernet MAC Station Address" stored inside the eeprom. (see
below)
looks like a driver bug !?
does anybody have a clue what`s going wrong here?
regards
roland
#lspci
00:00.0 Host bridge: Cyrix Corporation PCI Master
00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815
(MacPhyter) Ethernet Controller
00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua]
00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev
06)
#dmesg |egrep "natsemi|eth"
natsemi dp8381x driver, version 2.1, Sept 11, 2006
natsemi 0000:00:0f.0: setting latency timer to 64
natsemi eth0: NatSemi DP8381[56] at 0x4010000 (0000:00:0f.0),
00:00:00:00:00:00, IRQ 10, port TP.
eth0: DSPCFG accepted after 0 usec.
eth0: link up.
eth0: Setting full-duplex based on negotiated link capability.
#natsemi-diag -aa
natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a NatSemi DP83815 adapter at 0xf800.
Natsemi 83815 series with station address de:ad:be:ef:be:ef
Transceiver setting Autonegotation advertise 10/100 Mbps half and full
duplex.
This device appears to be active, so some registers will not be read.
To see all register values use the '-f' flag.
NatSemi DP83815 chip registers at 0xf800
0x000: 00000004 e805e000 00000002 00000000 ******** 00f1cd65 00000001
00000000
0x020: 03abd200 d0f01002 00000000 00000000 03abd000 18700010 00000000
00000000
0x040: ******** 00200000 00000004 0000efbe ffff000b 30303030 00000403
00000000
0x060: ******** ******** ******** ******** ******** ******** ********
********
0x080: 00003100 0000786d 00002000 00005c21 000005e1 000045e1 00000005
00002801
0x0A0: ******** ******** ******** ******** ******** ******** ********
********
0x0C0: 00000615 00000002 00000000 00000000 00000000 00000000 00000100
00000030
0x0E0: 00000000 000000bf 00000804 00008200 00000000 00000000 00000000
00000000
Interrupt sources are pending (00000200).
Tx queue emptied indication.
Receive mode is 0xc8200000: Normal unicast and hashed multicast.
Rx filter contents: adde efbe efbe 0000 0000 0000 0000 0000
#natsemi-diag -ee
natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a NatSemi DP83815 adapter at 0xf800.
Natsemi 83815 series with station address de:ad:be:ef:be:ef
Transceiver setting Autonegotation advertise 10/100 Mbps half and full
duplex.
EEPROM address length 6, 64 words.
EEPROM contents (64 words):
0x00: 100b 0020 0b34 41fb 0000 0000 0000 4000
0x08: 0d32 dff4 1905 aa48 0000 0000 129c 4c4c
0x10: ca52 2ccc 0cb2 9c6c 0c6c 8c0c 2020 6080
0x18: 0800 0000 0000 0000 0000 0000 0000 0000
0x20: 0000 0000 0000 0000 0000 0000 0000 0000
0x28: 0000 0000 0000 0000 0000 0000 0000 0000
0x30: 0000 0000 0000 0000 0000 0000 0000 0000
0x38: 0000 0000 0000 0000 0000 0000 0000 e418
Decoded EEPROM contents:
PCI Subsystem IDs -- Vendor 0x100b, Device 0x0020.
PCI timer settings -- minimum grant 11, maximum latency 52.
Ethernet MAC Station Address 00:80:64:1a:e8:bf.
Wake-On-LAN password 00:00:00:00:00:00.
Transceiver setting 0x--f-: advertise 10/100 Mbps half and full duplex.
Flow control enabled.
EEPROM active region checksum read as aa48, vs aa48 calculated value.
^ permalink raw reply
* Re: [PATCH net-next,v2] hyperv: Add processing of MTU reduced by the host
From: David Miller @ 2014-11-12 21:21 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1415830064-1440-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Wed, 12 Nov 2014 14:07:44 -0800
> If the host uses packet encapsulation feature, the MTU may be reduced by the
> host due to headroom reservation for encapsulation. This patch handles this
> new MTU value.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied, thanks for adding the comment.
^ permalink raw reply
* Re: [PATCH net] netlink: Properly unbind in error conditions.
From: David Miller @ 2014-11-12 20:49 UTC (permalink / raw)
To: shimoda.hiroaki; +Cc: netdev, rgb
In-Reply-To: <20141113042410.013c5d044aa442a05832d6d9@gmail.com>
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date: Thu, 13 Nov 2014 04:24:10 +0900
> Even if netlink_kernel_cfg::unbind is implemented the unbind() method is
> not called, because cfg->unbind is omitted in __netlink_kernel_create().
> And fix wrong argument of test_bit() and off by one problem.
>
> At this point, no unbind() method is implemented, so there is no real
> issue.
>
> Fixes: 4f520900522f ("netlink: have netlink per-protocol bind function return an error code.")
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* RE: [PATCH net-next] hyperv: Add processing of MTU reduced by the host
From: Haiyang Zhang @ 2014-11-12 20:31 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, KY Srinivasan, olaf@aepfle.de,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org
In-Reply-To: <20141112.150423.1660890641226643870.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, November 12, 2014 3:04 PM
> To: Haiyang Zhang
> Cc: netdev@vger.kernel.org; KY Srinivasan; olaf@aepfle.de;
> jasowang@redhat.com; linux-kernel@vger.kernel.org; driverdev-
> devel@linuxdriverproject.org
> Subject: Re: [PATCH net-next] hyperv: Add processing of MTU reduced by
> the host
>
> From: Haiyang Zhang <haiyangz@microsoft.com>
> Date: Wed, 12 Nov 2014 20:02:11 +0000
>
> > The Hyper-V host doesn't support MTU below 1500. If we try setting MTU
> to a
> > value < 1500, the host will use 1500 automatically and return 1500 in
> the
> > RNDIS_OID_GEN_MAXIMUM_FRAME_SIZE query and guest will also use it.
> That's
> > why I set the lower limit to ETH_DATA_LEN.
> >
> > Are you suggesting that we keep the 68 as the lower limit, and let the
> host
> > auto-reset it to 1500 when we trying to set an MTU < 1500?
>
> Then you need to add a comment, because without any information or
> context that change looks wrong.
I will add a comment.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH] ip_tunnel: Ops registration for secondary encap (fou, gue)
From: David Miller @ 2014-11-12 20:11 UTC (permalink / raw)
To: therbert; +Cc: netdev, rdunlap
In-Reply-To: <CA+mtBx9aXUxZZodQi=QcDx22EzeX+Ch2p1qnpT2w6F2jmou3GA@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 12 Nov 2014 12:07:19 -0800
> On Wed, Nov 12, 2014 at 12:03 PM, David Miller <davem@davemloft.net> wrote:
>> From: Tom Herbert <therbert@google.com>
>> Date: Wed, 12 Nov 2014 11:54:09 -0800
>>
>>> Instead of calling fou and gue functions directly from ip_tunnel
>>> use ops for these that were previously registered. This patch adds the
>>> logic to add and remove encapsulation operations for ip_tunnel,
>>> and modified fou (and gue) to register with ip_tunnels.
>>>
>>> This patch also addresses a circular dependency between ip_tunnel
>>> and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y
>>> and CONFIG_NET_FOU=m. References to fou an gue have been removed from
>>> ip_tunnel.c
>>>
>>> Reported-by: Randy Dunlap <rdunlap@infradead.org>
>>> Signed-off-by: Tom Herbert <therbert@google.com>
>>
>> Applied, please in the future be explicit about the target tree by
>> saying "[PATCH net-next]" or similar in your Subj.
>>
>> I'm pretty sure this isn't the first time I've had to ask this of
>> you. :-/
>>
> I was unsure which branch to target since the bug was reported in
> linux-next. Is next-next appropriate in this case?
Tom, this code doesn't even exist in the 'net' tree, how could it
possibly apply to anything other than 'net-next'?
^ permalink raw reply
* Re: [PATCH net-next] amd-xgbe: Fix sparse endian warnings
From: David Miller @ 2014-11-12 20:10 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev, dan.carpenter
In-Reply-To: <20141112163749.2808.95593.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Wed, 12 Nov 2014 10:37:49 -0600
> Change the types of the descriptor entries in the xgbe_ring_desc struct
> from u32 to __le32 to fix endian warnings issued by sparse.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/3] dev_disable_lro() improvements for stacked devices
From: David Miller @ 2014-11-12 20:08 UTC (permalink / raw)
To: mkubecek; +Cc: vfalico, netdev, linux-kernel, j.vosburgh, andy, jiri
In-Reply-To: <20141112131546.GA8745@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Wed, 12 Nov 2014 14:15:46 +0100
> On Tue, Nov 11, 2014 at 09:47:52PM -0500, David Miller wrote:
>>
>> Please do it generically.
>>
>> Having a special stanza for each layered device type in
>> dev_disable_lro() is beyond stupid. Especially when it
>> can in fact be done cleanly.
>
> I gave it some thought and I would like ask one question first:
>
> Does the upper-lower relationship always mean that upper device receives
> packets through its lower device(s) so that LRO should always be
> disabled for lower devices whenever there are some? Or should it be
> limited only to an explicit list of device types (vlan, macvlan, bond,
> team)?
This should be the case, anyone else?
^ permalink raw reply
* Re: [PATCH] net: pxa168_eth: move SET_NETDEV_DEV a bit earlier
From: David Miller @ 2014-11-12 20:08 UTC (permalink / raw)
To: jszhang
Cc: antoine.tenart, arnd, sebastian.hesselbarth, netdev, linux-kernel,
linux-arm-kernel
In-Reply-To: <1415790527-6494-1-git-send-email-jszhang@marvell.com>
From: Jisheng Zhang <jszhang@marvell.com>
Date: Wed, 12 Nov 2014 19:08:47 +0800
> This is to ensure the net_device's dev.parent is set before we used it
> in dma_zalloc_coherent() from init_hash_table().
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Please always be explicit about what tree you generated this patch against
and therefore expect it to be applied to by saying "[PATCH net-next]" or
similar in your Subject line.
Because this only applies cleanly to net-next, that's where I installed
it.
Thanks.
^ permalink raw reply
* Re: [PATCH] ip_tunnel: Ops registration for secondary encap (fou, gue)
From: Tom Herbert @ 2014-11-12 20:07 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, rdunlap
In-Reply-To: <20141112.150349.1546991259336520485.davem@davemloft.net>
On Wed, Nov 12, 2014 at 12:03 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Wed, 12 Nov 2014 11:54:09 -0800
>
>> Instead of calling fou and gue functions directly from ip_tunnel
>> use ops for these that were previously registered. This patch adds the
>> logic to add and remove encapsulation operations for ip_tunnel,
>> and modified fou (and gue) to register with ip_tunnels.
>>
>> This patch also addresses a circular dependency between ip_tunnel
>> and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y
>> and CONFIG_NET_FOU=m. References to fou an gue have been removed from
>> ip_tunnel.c
>>
>> Reported-by: Randy Dunlap <rdunlap@infradead.org>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>
> Applied, please in the future be explicit about the target tree by
> saying "[PATCH net-next]" or similar in your Subj.
>
> I'm pretty sure this isn't the first time I've had to ask this of
> you. :-/
>
I was unsure which branch to target since the bug was reported in
linux-next. Is next-next appropriate in this case?
Thanks,
Tom
> Thanks Tom.
^ permalink raw reply
* Re: [PATCH net] net: ptp: fix time stamp matching logic for VLAN packets.
From: David Miller @ 2014-11-12 20:06 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, stefan.sorensen
In-Reply-To: <1415788432-21617-1-git-send-email-richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com>
Date: Wed, 12 Nov 2014 11:33:52 +0100
> Commit ae5c6c6d "ptp: Classify ptp over ip over vlan packets" changed the
> code in two drivers that matches time stamps with PTP frames, with the goal
> of allowing VLAN tagged PTP packets to receive hardware time stamps.
>
> However, that commit failed to account for the VLAN header when parsing
> IPv4 packets. This patch fixes those two drivers to correctly match VLAN
> tagged IPv4/UDP PTP messages with their time stamps.
>
> This patch should also be applied to v3.17.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Applied and queued up for -stable, thanks Richard.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Fix static checker warning
From: David Miller @ 2014-11-12 20:05 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, kumaras
In-Reply-To: <1415784666-30224-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 12 Nov 2014 15:01:06 +0530
> Fix static checker warning that got introduced in commit e2ac9628959cc152
> ("cxgb4: Cleanup macros so they follow the same style and look consistent, part
> 2") due to accidental checkin of bogus line.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch -next] amd-xgbe: fix ->rss_hash_type
From: David Miller @ 2014-11-12 20:04 UTC (permalink / raw)
To: dan.carpenter; +Cc: thomas.lendacky, netdev, kernel-janitors
In-Reply-To: <20141112083135.GA12795@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 12 Nov 2014 11:31:35 +0300
> There was a missing break statement so we set everything to
> PKT_HASH_TYPE_L3 even when we intended to use PKT_HASH_TYPE_L4.
>
> Fixes: 5b9dfe299e55 ('amd-xgbe: Provide support for receive side scaling')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> This driver has a lot of Sparse endian warnings.
> http://lwn.net/Articles/205624/
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
> index 7daa2cd..55ba1dc 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
> @@ -1601,6 +1601,7 @@ static int xgbe_dev_read(struct xgbe_channel *channel)
> case RX_DESC3_L34T_IPV6_UDP:
> packet->rss_hash_type = PKT_HASH_TYPE_L4;
>
> + break;
Please don't add this spurious empty line before the break;, thanks.
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add processing of MTU reduced by the host
From: David Miller @ 2014-11-12 20:04 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <ecc2fd8e646147fabb30d3120c889431@DFM-DB3MBX15-06.exchange.corp.microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Wed, 12 Nov 2014 20:02:11 +0000
> The Hyper-V host doesn't support MTU below 1500. If we try setting MTU to a
> value < 1500, the host will use 1500 automatically and return 1500 in the
> RNDIS_OID_GEN_MAXIMUM_FRAME_SIZE query and guest will also use it. That's
> why I set the lower limit to ETH_DATA_LEN.
>
> Are you suggesting that we keep the 68 as the lower limit, and let the host
> auto-reset it to 1500 when we trying to set an MTU < 1500?
Then you need to add a comment, because without any information or
context that change looks wrong.
^ permalink raw reply
* Re: [PATCH] ip_tunnel: Ops registration for secondary encap (fou, gue)
From: David Miller @ 2014-11-12 20:03 UTC (permalink / raw)
To: therbert; +Cc: netdev, rdunlap
In-Reply-To: <1415822049-24978-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 12 Nov 2014 11:54:09 -0800
> Instead of calling fou and gue functions directly from ip_tunnel
> use ops for these that were previously registered. This patch adds the
> logic to add and remove encapsulation operations for ip_tunnel,
> and modified fou (and gue) to register with ip_tunnels.
>
> This patch also addresses a circular dependency between ip_tunnel
> and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y
> and CONFIG_NET_FOU=m. References to fou an gue have been removed from
> ip_tunnel.c
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, please in the future be explicit about the target tree by
saying "[PATCH net-next]" or similar in your Subj.
I'm pretty sure this isn't the first time I've had to ask this of
you. :-/
Thanks Tom.
^ permalink raw reply
* RE: [PATCH net-next] hyperv: Add processing of MTU reduced by the host
From: Haiyang Zhang @ 2014-11-12 20:02 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, KY Srinivasan, olaf@aepfle.de,
jasowang@redhat.com, linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org
In-Reply-To: <20141112.144640.703336197189868183.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, November 12, 2014 2:47 PM
> To: Haiyang Zhang
> Cc: netdev@vger.kernel.org; KY Srinivasan; olaf@aepfle.de;
> jasowang@redhat.com; linux-kernel@vger.kernel.org; driverdev-
> devel@linuxdriverproject.org
> Subject: Re: [PATCH net-next] hyperv: Add processing of MTU reduced by
> the host
>
> From: Haiyang Zhang <haiyangz@microsoft.com>
> Date: Tue, 11 Nov 2014 15:27:52 -0800
>
> > - if (mtu < 68 || mtu > limit)
> > + if (mtu < ETH_DATA_LEN || mtu > limit)
> > return -EINVAL;
>
> This is not correct.
>
> The test is against the minimally supported MTU, which should
> be 68 not ETH_DATA_LEN which is 1500.
The Hyper-V host doesn't support MTU below 1500. If we try setting MTU to a
value < 1500, the host will use 1500 automatically and return 1500 in the
RNDIS_OID_GEN_MAXIMUM_FRAME_SIZE query and guest will also use it. That's
why I set the lower limit to ETH_DATA_LEN.
Are you suggesting that we keep the 68 as the lower limit, and let the host
auto-reset it to 1500 when we trying to set an MTU < 1500?
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH net] cxgb4 : dcb open-lldp interop fixes
From: David Miller @ 2014-11-12 20:00 UTC (permalink / raw)
To: anish; +Cc: netdev, hariprasad, leedom
In-Reply-To: <1415777451-14144-1-git-send-email-anish@chelsio.com>
From: Anish Bhatt <anish@chelsio.com>
Date: Tue, 11 Nov 2014 23:30:51 -0800
> * In LLD_MANAGED mode, traffic classes were being returned in reverse order to
> lldp agent.
> * Priotype of strict is no longer the default returned.
> * Change behaviour of getdcbx() based on discussions on lldp-devel
>
> These were missed as there was no working fetch interface for open-lldp when
> running in LLD_MANAGED mode till now.
>
> Fixes: 76bcb31efc06 ("cxgb4 : Add DCBx support codebase and dcbnl_ops")
>
> Signed-off-by: Anish Bhatt <anish@chelsio.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] ip_tunnel: Ops registration for secondary encap (fou, gue)
From: Tom Herbert @ 2014-11-12 19:54 UTC (permalink / raw)
To: davem, netdev; +Cc: rdunlap
Instead of calling fou and gue functions directly from ip_tunnel
use ops for these that were previously registered. This patch adds the
logic to add and remove encapsulation operations for ip_tunnel,
and modified fou (and gue) to register with ip_tunnels.
This patch also addresses a circular dependency between ip_tunnel
and fou that was causing link errors when CONFIG_NET_IP_TUNNEL=y
and CONFIG_NET_FOU=m. References to fou an gue have been removed from
ip_tunnel.c
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/net/fou.h | 25 ++------------
include/net/ip_tunnels.h | 16 +++++++++
net/ipv4/fou.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv4/ip_tunnel.c | 78 ++++++++++++++++++++++++++++++--------------
4 files changed, 157 insertions(+), 47 deletions(-)
diff --git a/include/net/fou.h b/include/net/fou.h
index 25b26ff..19b8a0c 100644
--- a/include/net/fou.h
+++ b/include/net/fou.h
@@ -8,31 +8,12 @@
#include <net/ip_tunnels.h>
#include <net/udp.h>
+size_t fou_encap_hlen(struct ip_tunnel_encap *e);
+static size_t gue_encap_hlen(struct ip_tunnel_encap *e);
+
int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
u8 *protocol, struct flowi4 *fl4);
int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
u8 *protocol, struct flowi4 *fl4);
-static size_t fou_encap_hlen(struct ip_tunnel_encap *e)
-{
- return sizeof(struct udphdr);
-}
-
-static size_t gue_encap_hlen(struct ip_tunnel_encap *e)
-{
- size_t len;
- bool need_priv = false;
-
- len = sizeof(struct udphdr) + sizeof(struct guehdr);
-
- if (e->flags & TUNNEL_ENCAP_FLAG_REMCSUM) {
- len += GUE_PLEN_REMCSUM;
- need_priv = true;
- }
-
- len += need_priv ? GUE_LEN_PRIV : 0;
-
- return len;
-}
-
#endif
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 5bc6ede..25a59eb 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -117,6 +117,22 @@ struct ip_tunnel_net {
struct hlist_head tunnels[IP_TNL_HASH_SIZE];
};
+struct ip_tunnel_encap_ops {
+ size_t (*encap_hlen)(struct ip_tunnel_encap *e);
+ int (*build_header)(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, struct flowi4 *fl4);
+};
+
+#define MAX_IPTUN_ENCAP_OPS 8
+
+extern const struct ip_tunnel_encap_ops __rcu *
+ iptun_encaps[MAX_IPTUN_ENCAP_OPS];
+
+int ip_tunnel_encap_add_ops(const struct ip_tunnel_encap_ops *op,
+ unsigned int num);
+int ip_tunnel_encap_del_ops(const struct ip_tunnel_encap_ops *op,
+ unsigned int num);
+
#ifdef CONFIG_INET
int ip_tunnel_init(struct net_device *dev);
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 740ae09..fe09077 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -668,6 +668,30 @@ static const struct genl_ops fou_nl_ops[] = {
},
};
+size_t fou_encap_hlen(struct ip_tunnel_encap *e)
+{
+ return sizeof(struct udphdr);
+}
+EXPORT_SYMBOL(fou_encap_hlen);
+
+size_t gue_encap_hlen(struct ip_tunnel_encap *e)
+{
+ size_t len;
+ bool need_priv = false;
+
+ len = sizeof(struct udphdr) + sizeof(struct guehdr);
+
+ if (e->flags & TUNNEL_ENCAP_FLAG_REMCSUM) {
+ len += GUE_PLEN_REMCSUM;
+ need_priv = true;
+ }
+
+ len += need_priv ? GUE_LEN_PRIV : 0;
+
+ return len;
+}
+EXPORT_SYMBOL(gue_encap_hlen);
+
static void fou_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,
struct flowi4 *fl4, u8 *protocol, __be16 sport)
{
@@ -787,6 +811,57 @@ int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
}
EXPORT_SYMBOL(gue_build_header);
+#ifdef CONFIG_NET_FOU_IP_TUNNELS
+
+static const struct ip_tunnel_encap_ops __read_mostly fou_iptun_ops = {
+ .encap_hlen = fou_encap_hlen,
+ .build_header = fou_build_header,
+};
+
+static const struct ip_tunnel_encap_ops __read_mostly gue_iptun_ops = {
+ .encap_hlen = gue_encap_hlen,
+ .build_header = gue_build_header,
+};
+
+static int ip_tunnel_encap_add_fou_ops(void)
+{
+ int ret;
+
+ ret = ip_tunnel_encap_add_ops(&fou_iptun_ops, TUNNEL_ENCAP_FOU);
+ if (ret < 0) {
+ pr_err("can't add fou ops\n");
+ return ret;
+ }
+
+ ret = ip_tunnel_encap_add_ops(&gue_iptun_ops, TUNNEL_ENCAP_GUE);
+ if (ret < 0) {
+ pr_err("can't add gue ops\n");
+ ip_tunnel_encap_del_ops(&fou_iptun_ops, TUNNEL_ENCAP_FOU);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void ip_tunnel_encap_del_fou_ops(void)
+{
+ ip_tunnel_encap_del_ops(&fou_iptun_ops, TUNNEL_ENCAP_FOU);
+ ip_tunnel_encap_del_ops(&gue_iptun_ops, TUNNEL_ENCAP_GUE);
+}
+
+#else
+
+static int ip_tunnel_encap_add_fou_ops(void)
+{
+ return 0;
+}
+
+static int ip_tunnel_encap_del_fou_ops(void)
+{
+}
+
+#endif
+
static int __init fou_init(void)
{
int ret;
@@ -794,6 +869,14 @@ static int __init fou_init(void)
ret = genl_register_family_with_ops(&fou_nl_family,
fou_nl_ops);
+ if (ret < 0)
+ goto exit;
+
+ ret = ip_tunnel_encap_add_fou_ops();
+ if (ret < 0)
+ genl_unregister_family(&fou_nl_family);
+
+exit:
return ret;
}
@@ -801,6 +884,8 @@ static void __exit fou_fini(void)
{
struct fou *fou, *next;
+ ip_tunnel_encap_del_fou_ops();
+
genl_unregister_family(&fou_nl_family);
/* Close all the FOU sockets */
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index c3587e1..63e745a 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -57,10 +57,6 @@
#include <net/rtnetlink.h>
#include <net/udp.h>
-#if IS_ENABLED(CONFIG_NET_FOU)
-#include <net/fou.h>
-#endif
-
#if IS_ENABLED(CONFIG_IPV6)
#include <net/ipv6.h>
#include <net/ip6_fib.h>
@@ -494,19 +490,50 @@ EXPORT_SYMBOL_GPL(ip_tunnel_rcv);
static int ip_encap_hlen(struct ip_tunnel_encap *e)
{
- switch (e->type) {
- case TUNNEL_ENCAP_NONE:
+ const struct ip_tunnel_encap_ops *ops;
+ int hlen = -EINVAL;
+
+ if (e->type == TUNNEL_ENCAP_NONE)
return 0;
-#if IS_ENABLED(CONFIG_NET_FOU)
- case TUNNEL_ENCAP_FOU:
- return fou_encap_hlen(e);
- case TUNNEL_ENCAP_GUE:
- return gue_encap_hlen(e);
-#endif
- default:
+
+ if (e->type >= MAX_IPTUN_ENCAP_OPS)
return -EINVAL;
- }
+
+ rcu_read_lock();
+ ops = rcu_dereference(iptun_encaps[e->type]);
+ if (likely(ops && ops->encap_hlen))
+ hlen = ops->encap_hlen(e);
+ rcu_read_unlock();
+
+ return hlen;
+}
+
+const struct ip_tunnel_encap_ops __rcu *
+ iptun_encaps[MAX_IPTUN_ENCAP_OPS] __read_mostly;
+
+int ip_tunnel_encap_add_ops(const struct ip_tunnel_encap_ops *ops,
+ unsigned int num)
+{
+ return !cmpxchg((const struct ip_tunnel_encap_ops **)
+ &iptun_encaps[num],
+ NULL, ops) ? 0 : -1;
}
+EXPORT_SYMBOL(ip_tunnel_encap_add_ops);
+
+int ip_tunnel_encap_del_ops(const struct ip_tunnel_encap_ops *ops,
+ unsigned int num)
+{
+ int ret;
+
+ ret = (cmpxchg((const struct ip_tunnel_encap_ops **)
+ &iptun_encaps[num],
+ ops, NULL) == ops) ? 0 : -1;
+
+ synchronize_net();
+
+ return ret;
+}
+EXPORT_SYMBOL(ip_tunnel_encap_del_ops);
int ip_tunnel_encap_setup(struct ip_tunnel *t,
struct ip_tunnel_encap *ipencap)
@@ -534,18 +561,19 @@ EXPORT_SYMBOL_GPL(ip_tunnel_encap_setup);
int ip_tunnel_encap(struct sk_buff *skb, struct ip_tunnel *t,
u8 *protocol, struct flowi4 *fl4)
{
- switch (t->encap.type) {
- case TUNNEL_ENCAP_NONE:
+ const struct ip_tunnel_encap_ops *ops;
+ int ret = -EINVAL;
+
+ if (t->encap.type == TUNNEL_ENCAP_NONE)
return 0;
-#if IS_ENABLED(CONFIG_NET_FOU)
- case TUNNEL_ENCAP_FOU:
- return fou_build_header(skb, &t->encap, protocol, fl4);
- case TUNNEL_ENCAP_GUE:
- return gue_build_header(skb, &t->encap, protocol, fl4);
-#endif
- default:
- return -EINVAL;
- }
+
+ rcu_read_lock();
+ ops = rcu_dereference(iptun_encaps[t->encap.type]);
+ if (likely(ops && ops->build_header))
+ ret = ops->build_header(skb, &t->encap, protocol, fl4);
+ rcu_read_unlock();
+
+ return ret;
}
EXPORT_SYMBOL(ip_tunnel_encap);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH net-next] udp: Neaten function pointer calls and add braces
From: David Miller @ 2014-11-12 19:52 UTC (permalink / raw)
To: joe; +Cc: netdev, peter
In-Reply-To: <1415771960.16070.21.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Tue, 11 Nov 2014 21:59:20 -0800
> Standardize function pointer uses.
>
> Convert calling style from:
> (*foo)(args...);
> to:
> foo(args...);
>
> Other miscellanea:
>
> o Add braces around loops with single ifs on multiple lines
> o Realign arguments around these functions
> o Invert logic in if to return immediately.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* Re: [PATCH net-next 2/2] r8152: adjust rtl_start_rx
From: David Miller @ 2014-11-12 19:49 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2ECE46C@RTITMBSV03.realtek.com.tw>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 12 Nov 2014 06:29:46 +0000
> David Miller [mailto:davem@davemloft.net]
>> Sent: Wednesday, November 12, 2014 1:44 PM
> [...]
>> What do other USB network drivers do in similar situations?
>
> According to the usbnet.c, it would make sure to submit the
> number of min(10, RX_QLEN(dev)) rx buffers. If there are
> not enough rx buffers, it schedule a tasklet for next try.
>
> The brief flow is as following.
> 1. Call open().
> - schedule a tasklet.
> 2. Tasklet is called.
> if (dev->rxq.qlen < RX_QLEN(dev)) {
> - submit rx buffers util the number of
> min(10, RX_QLEN(dev)). If the error
> occurs, break the loop.
> - If the dev->rxq.qlen < RX_QLEN(dev),
> schedule the tasklet.
> }
That sounds like a better recovery model, why don't you mimick it?
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] Code adjustment
From: David Miller @ 2014-11-12 19:49 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-91-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 12 Nov 2014 10:05:02 +0800
> v3:
> Remove the test_bit for patch #2.
>
> v2:
> Correct the spelling error for the comment of patch #3.
>
> v1:
> Adjust some codes to make them more reasonable.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add processing of MTU reduced by the host
From: David Miller @ 2014-11-12 19:46 UTC (permalink / raw)
To: haiyangz; +Cc: netdev, kys, olaf, jasowang, linux-kernel, driverdev-devel
In-Reply-To: <1415748472-27463-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Tue, 11 Nov 2014 15:27:52 -0800
> - if (mtu < 68 || mtu > limit)
> + if (mtu < ETH_DATA_LEN || mtu > limit)
> return -EINVAL;
This is not correct.
The test is against the minimally supported MTU, which should
be 68 not ETH_DATA_LEN which is 1500.
^ permalink raw reply
* Re: [PATCH net] netlink: Properly unbind in error conditions.
From: Richard Guy Briggs @ 2014-11-12 19:44 UTC (permalink / raw)
To: Hiroaki SHIMODA; +Cc: davem, netdev
In-Reply-To: <20141113042410.013c5d044aa442a05832d6d9@gmail.com>
On 14/11/13, Hiroaki SHIMODA wrote:
> Even if netlink_kernel_cfg::unbind is implemented the unbind() method is
> not called, because cfg->unbind is omitted in __netlink_kernel_create().
> And fix wrong argument of test_bit() and off by one problem.
>
> At this point, no unbind() method is implemented, so there is no real
> issue.
>
> Fixes: 4f520900522f ("netlink: have netlink per-protocol bind function return an error code.")
> Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
> Cc: Richard Guy Briggs <rgb@redhat.com>
> ---
> net/netlink/af_netlink.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index f1de72de273e..0007b8180397 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -1440,7 +1440,7 @@ static void netlink_unbind(int group, long unsigned int groups,
> return;
>
> for (undo = 0; undo < group; undo++)
> - if (test_bit(group, &groups))
> + if (test_bit(undo, &groups))
Nice find! (Cut-and-waste from line 1480...)
> nlk->netlink_unbind(undo);
> }
>
> @@ -1492,7 +1492,7 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
> netlink_insert(sk, net, nladdr->nl_pid) :
> netlink_autobind(sock);
> if (err) {
> - netlink_unbind(nlk->ngroups - 1, groups, nlk);
> + netlink_unbind(nlk->ngroups, groups, nlk);
Yup, agreed.
> return err;
> }
> }
> @@ -2509,6 +2509,7 @@ __netlink_kernel_create(struct net *net, int unit, struct module *module,
> nl_table[unit].module = module;
> if (cfg) {
> nl_table[unit].bind = cfg->bind;
> + nl_table[unit].unbind = cfg->unbind;
Yup, thanks.
> nl_table[unit].flags = cfg->flags;
> if (cfg->compare)
> nl_table[unit].compare = cfg->compare;
Acked-by: Richard Guy Briggs <rgb@redhat.com>
> --
> 2.0.4
>
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* [PATCH net] netlink: Properly unbind in error conditions.
From: Hiroaki SHIMODA @ 2014-11-12 19:24 UTC (permalink / raw)
To: davem; +Cc: netdev, rgb
Even if netlink_kernel_cfg::unbind is implemented the unbind() method is
not called, because cfg->unbind is omitted in __netlink_kernel_create().
And fix wrong argument of test_bit() and off by one problem.
At this point, no unbind() method is implemented, so there is no real
issue.
Fixes: 4f520900522f ("netlink: have netlink per-protocol bind function return an error code.")
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Cc: Richard Guy Briggs <rgb@redhat.com>
---
net/netlink/af_netlink.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index f1de72de273e..0007b8180397 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1440,7 +1440,7 @@ static void netlink_unbind(int group, long unsigned int groups,
return;
for (undo = 0; undo < group; undo++)
- if (test_bit(group, &groups))
+ if (test_bit(undo, &groups))
nlk->netlink_unbind(undo);
}
@@ -1492,7 +1492,7 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
netlink_insert(sk, net, nladdr->nl_pid) :
netlink_autobind(sock);
if (err) {
- netlink_unbind(nlk->ngroups - 1, groups, nlk);
+ netlink_unbind(nlk->ngroups, groups, nlk);
return err;
}
}
@@ -2509,6 +2509,7 @@ __netlink_kernel_create(struct net *net, int unit, struct module *module,
nl_table[unit].module = module;
if (cfg) {
nl_table[unit].bind = cfg->bind;
+ nl_table[unit].unbind = cfg->unbind;
nl_table[unit].flags = cfg->flags;
if (cfg->compare)
nl_table[unit].compare = cfg->compare;
--
2.0.4
^ permalink raw reply related
* Re: [patch net-next 1/2] net: move vlan pop/push functions into common code
From: Pravin Shelar @ 2014-11-12 19:20 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, David Miller, Jamal Hadi Salim, Tom Herbert, Eric Dumazet,
Willem de Bruijn, Daniel Borkmann, mst, fw, Paul.Durrant,
Thomas Graf
In-Reply-To: <20141112115933.GD1882@nanopsycho.orion>
On Wed, Nov 12, 2014 at 3:59 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Nov 11, 2014 at 06:24:15PM CET, pshelar@nicira.com wrote:
>>On Tue, Nov 11, 2014 at 2:13 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> So it can be used from out of openvswitch code.
>>> Did couple of cosmetic changes on the way, namely variable naming and
>>> adding support for 8021AD proto.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>> ---
>>> include/linux/skbuff.h | 2 ++
>>> net/core/skbuff.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++
>>> net/openvswitch/actions.c | 76 ++---------------------------------------
>>> 3 files changed, 90 insertions(+), 74 deletions(-)
>>>
>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>>> index 103fbe8..3b0445c 100644
>>> --- a/include/linux/skbuff.h
>>> +++ b/include/linux/skbuff.h
>>> @@ -2673,6 +2673,8 @@ void skb_scrub_packet(struct sk_buff *skb, bool xnet);
>>> unsigned int skb_gso_transport_seglen(const struct sk_buff *skb);
>>> struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features);
>>> struct sk_buff *skb_vlan_untag(struct sk_buff *skb);
>>> +int skb_vlan_pop(struct sk_buff *skb);
>>> +int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
>>>
>>> struct skb_checksum_ops {
>>> __wsum (*update)(const void *mem, int len, __wsum wsum);
>>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>>> index 7001896..75e53d4 100644
>>> --- a/net/core/skbuff.c
>>> +++ b/net/core/skbuff.c
>>> @@ -4151,6 +4151,92 @@ err_free:
>>> }
>>> EXPORT_SYMBOL(skb_vlan_untag);
>>>
>>> +/* remove VLAN header from packet and update csum accordingly. */
>>> +static int __skb_vlan_pop(struct sk_buff *skb, u16 *vlan_tci)
>>> +{
>>> + struct vlan_hdr *vhdr;
>>> + int err;
>>> +
>>> + if (!pskb_may_pull(skb, VLAN_ETH_HLEN))
>>> + return -ENOMEM;
>>> +
>>> + if (!skb_cloned(skb) || skb_clone_writable(skb, VLAN_ETH_HLEN))
>>> + return 0;
>>> +
>>> + err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
>>> + if (unlikely(err))
>>> + return err;
>>> +
>>> + if (skb->ip_summed == CHECKSUM_COMPLETE)
>>> + skb->csum = csum_sub(skb->csum, csum_partial(skb->data
>>> + + (2 * ETH_ALEN), VLAN_HLEN, 0));
>>> +
>>> + vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
>>> + *vlan_tci = ntohs(vhdr->h_vlan_TCI);
>>> +
>>> + memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN);
>>> + __skb_pull(skb, VLAN_HLEN);
>>> +
>>> + vlan_set_encap_proto(skb, vhdr);
>>> + skb->mac_header += VLAN_HLEN;
>>> + if (skb_network_offset(skb) < ETH_HLEN)
>>> + skb_set_network_header(skb, ETH_HLEN);
>>> + skb_reset_mac_len(skb);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +int skb_vlan_pop(struct sk_buff *skb)
>>> +{
>>> + u16 vlan_tci;
>>> + __be16 vlan_proto;
>>> + int err;
>>> +
>>> + if (likely(vlan_tx_tag_present(skb))) {
>>> + skb->vlan_tci = 0;
>>> + } else {
>>> + if (unlikely((skb->protocol != htons(ETH_P_8021Q) &&
>>> + skb->protocol != htons(ETH_P_8021AD)) ||
>>> + skb->len < VLAN_ETH_HLEN))
>>> + return 0;
>>> +
>>> + err = __skb_vlan_pop(skb, &vlan_tci);
>>> + if (err)
>>> + return err;
>>> + }
>>> + /* move next vlan tag to hw accel tag */
>>> + if (likely((skb->protocol != htons(ETH_P_8021Q) &&
>>> + skb->protocol != htons(ETH_P_8021AD)) ||
>>> + skb->len < VLAN_ETH_HLEN))
>>> + return 0;
>>> +
>>> + vlan_proto = skb->protocol;
>>> + err = __skb_vlan_pop(skb, &vlan_tci);
>>> + if (unlikely(err))
>>> + return err;
>>> +
>>> + __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL(skb_vlan_pop);
>>> +
>>> +int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
>>> +{
>>> + if (vlan_tx_tag_present(skb)) {
>>> + /* push down current VLAN tag */
>>> + if (!__vlan_put_tag(skb, skb->vlan_proto,
>>> + vlan_tx_tag_get(skb)))
>>> + return -ENOMEM;
>>> +
>>Since you are restructuring this code, can you also change
>>__vlan_put_tag() to not free skb on error. So that these two new
>>functions can have common error handling code.
>
> That is not directly related to this patchset. I believe that should be
> changed in separate patch later on.
If you are not going to change this then I am not sure how tcf_vlan()
(that is introduced in next patch) can have common error handling
code.
^ permalink raw reply
* Re: Device Tree Binding for Marvell DSA Switch on imx28 board over Mdio Interface
From: Florian Fainelli @ 2014-11-12 19:19 UTC (permalink / raw)
To: Oliver Graute, netdev
In-Reply-To: <CA+KjHfYZdZ88ZFzFCPN-bGphh+mnSWy6i0WNzFYv=gOsafXA7g@mail.gmail.com>
On 11/12/2014 05:07 AM, Oliver Graute wrote:
> Hello,
>
> how do I specify the DSA node and the MDIO node in the Device Tree
> Binding to integrate a Marvell 88e6071 switch with a imx28 board?
If you do not CC the people actively working on this, chances are that
they will just miss your email.
>
> On my board the Marvell switch 88e6071 is connected via phy1 (on a
> imx28 PCB) to phy5 on the Marvell switch (on a Switch PCB). All phys
> are connected via the same MDIO Bus.
>
> I enabled the Marvell DSA Support Driver, Gianfar Ethernet Driver and
> Freescale PQ MDIO Driver in the Kernel (I' am not sure if this is the
> right choice for imx28 fec ethernet controller is it?)
>
> I already know that I need to adapt the DSA driver for this new
> switch. But currently I can't access the switch ports because my MDIO
> Bus is not configured correctly. It always ends with:
>
> dmesg | grep -E "mii|dsa|mdio"
> [ 2.528900] libphy: fec_enet_mii_bus: probed
> [ 3.028061] !!!!Enter dsa Probe!!!!!
> [ 3.037640] !!!!!Enter dsa_of_probe!!!!!
> [ 3.041736] !!!!before of_parse_phandle dsa,mii-bus!!!!!
> [ 3.047123] !!!! mdio->name=ethernet-phy !!!!!
> [ 3.051658] !!!!before of_mdio_find_bus!!!!!
> [ 3.055950] !!!!!enter of_mdio_find_bus!!!!!
> [ 3.074074] !!!!!enter of_mdio_bus_match!!!!!
> [ 3.078451] !!!!!enter of_mdio_bus_match!!!!!
> [ 3.088915] !!!!Leave of_mdio_find_bus !!!!!
> [ 3.093268] !!!! return of_mdio_find_bus =22 !!!!!
> [ 3.098166] dsa_of_probe returns=-22
> [ 3.101858] dsa: probe of dsa.5 failed with error -22
> [ 19.169423] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
> [Micrel KSZ8041] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
> [ 20.038786] fec 800f4000.ethernet eth1: Freescale FEC PHY driver
> [Micrel KSZ8041] (mii_bus:phy_addr=800f0000.etherne:01, irq=-1)
>
> because the method of_mdio_find_bus returns with EINVAL
>
> I suspect that the problem is the fact that the Kernel is not getting
> connected to the MDIO bus.
> what is wrong here?
>
> dsa@0 {
> compatible = "marvell,dsa";
> #address-cells = <2>;
> #size-cells = <0>;
> interrupts = <10>;
> dsa,ethernet = <ð1>;
> dsa,mii-bus = <ðphy1>;
This should be phandle to the MDIO bus controller, not a node within
its, so in your case this should be dsa,mii-bus = <&mdio_bus>;
>
> switch@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <5 0>; /* MDIO address 5, switch 0 in tree */
>
> port@0 {
> reg = <0>;
> label = "lan1";
> phy-handle = <ðphy1>;
> };
>
> port@1 {
> reg = <1>;
> label = "lan2";
> };
>
> port@2 {
> reg = <2>;
> label = "lan3";
> };
>
> port@3 {
> reg = <3>;
> label = "lan4";
> };
>
> port@4 {
> reg = <4>;
> label = "lan5";
> };
>
> port@5 {
> reg = <5>;
> label = "cpu";
> };
>
> };
> };
>
>
> eth1: eth1 {
> status = "okay";
> ethernet1-port@1 {
> phy-handle = <ðphy1>;
You probably want to use a fixed-link node here to provide a link status
that is always UP as seen from the CPU Ethernet MAC perspective, so
something like this:
fixed-link {
speed = <1000>;
full-duplex;
};
> };
> };
>
>
> mdio_bus: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "mdio";
> //compatible = "fsl,gianfar-mdio";
> compatible = "fsl,mpc875-fec-mdio", "fsl,pq1-fec-mdio";
> reg = <0xe00 0x188>;
> status = "okay";
>
> ethphy0: ethernet-phy@0 {
> reg = <0>;
>
> };
>
> ethphy1: ethernet-phy@1 {
> reg = <1>;
> };
> //reg = <0xff>; */ /* No PHY attached */
> //speed = <1000>;
> //duple = <1>;
> };
>
> Best regards,
>
> Oliver Graute
> --
> 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
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