* Re: eth0: hw csum failure
From: Stephen Hemminger @ 2011-12-05 16:18 UTC (permalink / raw)
To: Pavel Mateja; +Cc: netdev
In-Reply-To: <201112051351.26798.pavel@netsafe.cz>
I meant fixed in 3.2-rc4 and queued for 3.1 stable.
^ permalink raw reply
* Re: eth0: hw csum failure
From: Stephen Hemminger @ 2011-12-05 16:17 UTC (permalink / raw)
To: Pavel Mateja; +Cc: netdev
In-Reply-To: <201112051351.26798.pavel@netsafe.cz>
> If i did git bisect right it was caused by commit
> 4b275d7efa1c4412f0d572fcd7f78ed0919370b3
> bridge: Pseudo-header required for the checksum of ICMPv6
>
> Problem disappears when I turn off HW checksum via ethtool.
>
> Can anybody help?
Fixed in 3.1 (and queued for 3.0 stable).
commit fa2da8cdae1dd64f78fc915ca1d1a4a93c71e7cb
Author: stephen hemminger <shemminger@vyatta.com>
Date: Tue Nov 15 08:09:14 2011 +0000
bridge: correct IPv6 checksum after pull
Bridge multicast snooping of ICMPv6 would incorrectly report a checksum prob
when used with Ethernet devices like sky2 that use CHECKSUM_COMPLETE.
When bytes are removed from skb, the computed checksum needs to be adjusted.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Tested-by: Martin Volf <martin.volf.42@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: sky2 tx watchdog timeout with 1Gb speed
From: Stephen Hemminger @ 2011-12-05 16:16 UTC (permalink / raw)
To: Milan Kocian; +Cc: netdev
In-Reply-To: <20111205124725.GA19385@ntm.wq.cz>
On Mon, 5 Dec 2011 13:47:25 +0100
Milan Kocian <milon@wq.cz> wrote:
> On Sat, Nov 26, 2011 at 05:03:31PM -0800, Stephen Hemminger wrote:
> >
> > I think the problem might be that the board doesn't really have all the DMA pins
> > wired. You might try enabling iommu, or limiting to <4G of memory.
>
> hello stephen,
>
> you are probably right. I found that with this mb (Gigabyte GA-965GM-S2) was
> more problems with linux. So I replaced this old crap with new one :-).
> Many thanks for your time.
>
> Best regards,
There was a similar glitch with some skge users.
I have a patch to limit driver to 32bit only. If you send the DMI information,
it can be made automatic.
^ permalink raw reply
* Re: [RFC 2/3] if_ether.h: Add IEEE 802.1 Local Experimental Ethertype 1.
From: Rémi Denis-Courmont @ 2011-12-05 15:46 UTC (permalink / raw)
To: Sjur Brændeland; +Cc: netdev, Alexey Orishko, David S. Miller
In-Reply-To: <CAJK669ZhM_KSOd0MS7jTVvJ16KqNzPCj-Ns1ytN5NPg5PxgoOQ@mail.gmail.com>
Le lundi 5 décembre 2011 16:33:50 Sjur Brændeland, vous avez écrit :
> Hi Rémi,
>
> > It's even weirder then. If you have control over both ends and the NCM
> > 1.0 interface is not adequate, then you really should use your own CDC
> > class for the purpose.
>
> The reason we use NCM is performance: CDC normally gives less than 100Mbps,
> while NCM can give you up to 200Mbps.
NCM is a sub-profile of CDC, so that statement makes no sense to me.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the tree
From: wwguy @ 2011-12-05 15:42 UTC (permalink / raw)
To: John W. Linville
Cc: Stephen Rothwell, David Miller, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Berg, Johannes
In-Reply-To: <20111205145320.GA2531@tuxdriver.com>
On Mon, 2011-12-05 at 06:53 -0800, John W. Linville wrote:
> On Mon, Dec 05, 2011 at 03:34:16PM +1100, Stephen Rothwell wrote:
> > On Mon, 5 Dec 2011 12:34:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next merge of the net-next tree got a conflict in
> > > drivers/net/wireless/iwlwifi/iwl-agn.c between commits from the
> >
> > wireless (sorry)
> >
> > > tree and commit 7335613ae27a ("iwlwifi: move all mac80211 related
> > > functions to one place") from the net-next tree.
> > >
> > > I just used the net-next version (which may require some fixes).
>
> Yeah, I'll try to get that straightened-out over the next day or two.
>
John, anything I can help?
Thanks
Wey
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: at91/net: add macb ethernet controller in 9g45 DT
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-12-05 15:25 UTC (permalink / raw)
To: Nicolas Ferre
Cc: netdev, devicetree-discuss, linux-kernel, grant.likely, jamie,
linux-arm-kernel
In-Reply-To: <1ec7a786c94564a9b15a61239f41a2a3fba8578a.1323086095.git.nicolas.ferre@atmel.com>
On 12:59 Mon 05 Dec , Nicolas Ferre wrote:
> Add the Cadence macb ethernet controller in at91sam9g45 .dtsi and
> enable it in at91sam9m10g45ek board device tree file.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix: resync from vendor's copy
From: Ben Hutchings @ 2011-12-05 15:18 UTC (permalink / raw)
To: Mark Lord; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <4EDCD828.2090904@teksavvy.com>
On Mon, 2011-12-05 at 09:41 -0500, Mark Lord wrote:
[...]
> static int ax88772b_bind(struct usbnet *dev, struct usb_interface *intf)
> {
> ...
> /* register support for hardware checksums */
> dev->net->hw_features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
>
> /* enable hardware checksums */
> dev->net->features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
> ax88772b_set_features(dev->net, dev->net->features);
> ...
> }
> -------------------------------snip-----------------------------------
>
> Does this look correct -- any improvements/fixes to suggest?
[...]
NETIF_F_HW_CSUM means the hardware implements generic IP-style
checksumming: the stack specifies the offset at which to start
checksumming and the offset at which to store the checksum, and the
hardware does not attempt to parse the headers.
If this hardware recognises specific protocols and works out the offsets
itself, then you must claim NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM instead.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: r8169 performance?
From: Chris Adams @ 2011-12-05 14:54 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, hayeswang
In-Reply-To: <20111205064403.GA3426@electric-eye.fr.zoreil.com>
Once upon a time, Francois Romieu <romieu@fr.zoreil.com> said:
> Chris Adams <cmadams@hiwaay.net> :
> [...]
> > On the "problem" computer (on Fedora 16, kernel 3.1.2):
> >
> > [ 7.101106] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> > [ 7.102665] r8169 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> > [ 7.107308] r8169 0000:02:00.0: setting latency timer to 64
> > [ 7.107370] r8169 0000:02:00.0: irq 42 for MSI/MSI-X
> > [ 7.107703] r8169 0000:02:00.0: eth0: RTL8168d/8111d at 0xffffc900112fc000, 00:19:66:f2:dc:0b, XID 081000c0 IRQ 42
> >
> > On the "okay" computer (on Fedora 14, kernel 2.6.35.14):
> >
> > [ 9.053574] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> > [ 9.053594] r8169 0000:06:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> > [ 9.053689] r8169 0000:06:00.0: setting latency timer to 64
> > [ 9.053740] r8169 0000:06:00.0: irq 47 for MSI/MSI-X
> > [ 9.053830] r8169 0000:06:00.0: eth0: RTL8168d/8111d at 0xffffc90012998000, 6c:f0:49:b7:67:91, XID 083000c0 IRQ 47
>
> Almost the same: RTL_GIGA_MAC_VER_25 versus RTL_GIGA_MAC_VER_26 (faster).
Ahh, my eyes didn't see that one bit difference.
> The only difference in the driver is the hw_phy_config part.
There's also a difference in the interrupt handling (looks like only in
the receive FIFO overflow case). Also, they load different firmware (so
I guess my problem could be firmware related, which I guess only RealTek
could find/fix).
I guess my question is this: is there a chance this can be solved with
driver changes, or should I just accept that the on-board NIC has poor
performance and install an add-in NIC?
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
^ permalink raw reply
* [PATCH] net/fec: fix the use of pdev->id
From: Shawn Guo @ 2011-12-05 15:01 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, Shawn Guo
The pdev->id is used in several places for different purpose. All
these uses assume it's always the id of fec device which is >= 0.
However this is only true for non-DT case. When DT plays, pdev->id
is always -1, which will break these pdev->id users.
Instead of fixing all these users one by one, this patch introduces
a new member 'dev_id' to 'struct fec_enet_private' for holding the
correct fec device id, and replaces all the existing uses of pdev->id
with this dev_id.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 1124ce0..c136230 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -232,6 +232,7 @@ struct fec_enet_private {
struct platform_device *pdev;
int opened;
+ int dev_id;
/* Phylib and MDIO interface */
struct mii_bus *mii_bus;
@@ -837,7 +838,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
/* Adjust MAC if using macaddr */
if (iap == macaddr)
- ndev->dev_addr[ETH_ALEN-1] = macaddr[ETH_ALEN-1] + fep->pdev->id;
+ ndev->dev_addr[ETH_ALEN-1] = macaddr[ETH_ALEN-1] + fep->dev_id;
}
/* ------------------------------------------------------------------------- */
@@ -953,7 +954,7 @@ static int fec_enet_mii_probe(struct net_device *ndev)
char mdio_bus_id[MII_BUS_ID_SIZE];
char phy_name[MII_BUS_ID_SIZE + 3];
int phy_id;
- int dev_id = fep->pdev->id;
+ int dev_id = fep->dev_id;
fep->phy_dev = NULL;
@@ -1031,7 +1032,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* mdio interface in board design, and need to be configured by
* fec0 mii_bus.
*/
- if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id > 0) {
+ if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && fep->dev_id > 0) {
/* fec1 uses fec0 mii_bus */
fep->mii_bus = fec0_mii_bus;
return 0;
@@ -1063,7 +1064,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
fep->mii_bus->read = fec_enet_mdio_read;
fep->mii_bus->write = fec_enet_mdio_write;
fep->mii_bus->reset = fec_enet_mdio_reset;
- snprintf(fep->mii_bus->id, MII_BUS_ID_SIZE, "%x", pdev->id + 1);
+ snprintf(fep->mii_bus->id, MII_BUS_ID_SIZE, "%x", fep->dev_id + 1);
fep->mii_bus->priv = fep;
fep->mii_bus->parent = &pdev->dev;
@@ -1521,6 +1522,7 @@ fec_probe(struct platform_device *pdev)
int i, irq, ret = 0;
struct resource *r;
const struct of_device_id *of_id;
+ static int dev_id;
of_id = of_match_device(fec_dt_ids, &pdev->dev);
if (of_id)
@@ -1548,6 +1550,7 @@ fec_probe(struct platform_device *pdev)
fep->hwp = ioremap(r->start, resource_size(r));
fep->pdev = pdev;
+ fep->dev_id = dev_id++;
if (!fep->hwp) {
ret = -ENOMEM;
--
1.7.4.1
^ permalink raw reply related
* Re: linux-next: manual merge of the net-next tree with the tree
From: John W. Linville @ 2011-12-05 14:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Wey-Yi Guy,
Johannes Berg
In-Reply-To: <20111205153416.e1dd01e5368ce7c016d99a59@canb.auug.org.au>
On Mon, Dec 05, 2011 at 03:34:16PM +1100, Stephen Rothwell wrote:
> On Mon, 5 Dec 2011 12:34:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the net-next tree got a conflict in
> > drivers/net/wireless/iwlwifi/iwl-agn.c between commits from the
>
> wireless (sorry)
>
> > tree and commit 7335613ae27a ("iwlwifi: move all mac80211 related
> > functions to one place") from the net-next tree.
> >
> > I just used the net-next version (which may require some fixes).
Yeah, I'll try to get that straightened-out over the next day or two.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/asix: resync from vendor's copy
From: Mark Lord @ 2011-12-05 14:41 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <1320860895.2781.6.camel@bwh-desktop>
David / Ben / anyone..
I'm trying to puzzle out the rx/tx checksum feature flags,
and there does seem to be a lot of variance among drivers
as to how these are used.
The ASIX chips have hardware support for IP and TCP checksumming
for both IPv4 and IPv6. So I'm thinking this code (below) is the
most appropriate method for use in asix.c:
------------------------------- asix.h -----------------------------------
...
#define AX_RXCOE_IPCE 0x0001
#define AX_RXCOE_IPVE 0x0002
#define AX_RXCOE_V6VE 0x0004
#define AX_RXCOE_TCPE 0x0008
#define AX_RXCOE_UDPE 0x0010
#define AX_RXCOE_ICMP 0x0020
#define AX_RXCOE_IGMP 0x0040
#define AX_RXCOE_ICV6 0x0080
#define AX_RXCOE_TCPV6 0x0100
#define AX_RXCOE_UDPV6 0x0200
#define AX_RXCOE_ICMV6 0x0400
#define AX_RXCOE_IGMV6 0x0800
#define AX_RXCOE_ICV6V6 0x1000
#define AX_RXCOE_FOPC 0x8000
#define AX_RXCOE_DEF_CSUM (AX_RXCOE_IPCE | AX_RXCOE_IPVE | \
AX_RXCOE_V6VE | AX_RXCOE_TCPE | \
AX_RXCOE_UDPE | AX_RXCOE_ICV6 | \
AX_RXCOE_TCPV6 | AX_RXCOE_UDPV6)
#define AX_RXCOE_64TE 0x0100
#define AX_RXCOE_PPPOE 0x0200
#define AX_RXCOE_RPCE 0x8000
#define AX_TXCOE_IP 0x0001
#define AX_TXCOE_TCP 0x0002
#define AX_TXCOE_UDP 0x0004
#define AX_TXCOE_ICMP 0x0008
#define AX_TXCOE_IGMP 0x0010
#define AX_TXCOE_ICV6 0x0020
#define AX_TXCOE_TCPV6 0x0100
#define AX_TXCOE_UDPV6 0x0200
#define AX_TXCOE_ICMV6 0x0400
#define AX_TXCOE_IGMV6 0x0800
#define AX_TXCOE_ICV6V6 0x1000
#define AX_TXCOE_DEF_CSUM (AX_TXCOE_TCP | AX_TXCOE_UDP | \
AX_TXCOE_TCPV6 | AX_TXCOE_UDPV6)
...
------------------------------- asix.c -----------------------------------
static int ax88772b_set_features(struct net_device *netdev, u32 features)
{
struct usbnet *dev = netdev_priv(netdev);
u16 tx_csum = (features & NETIF_F_HW_CSUM) ? AX_TXCOE_DEF_CSUM : 0;
u16 rx_csum = (features & NETIF_F_RXCSUM ) ? AX_RXCOE_DEF_CSUM : 0;
ax8817x_write_cmd(dev, AX_CMD_WRITE_TXCOE_CTL, tx_csum, 0, 0, NULL);
ax8817x_write_cmd(dev, AX_CMD_WRITE_RXCOE_CTL, rx_csum, 0, 0, NULL);
return 0;
}
...
static int ax88772b_bind(struct usbnet *dev, struct usb_interface *intf)
{
...
/* register support for hardware checksums */
dev->net->hw_features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
/* enable hardware checksums */
dev->net->features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
ax88772b_set_features(dev->net, dev->net->features);
...
}
-------------------------------snip-----------------------------------
Does this look correct -- any improvements/fixes to suggest?
I am still trying to find out about all of the other possible hardware bits,
but the AX_TXCOE_DEF_CSUM and AX_RXCOE_DEF_CSUM patterns are the ones
that Asix themselves were using in the vendor driver.
Thanks.
^ permalink raw reply
* Re: [RFC 2/3] if_ether.h: Add IEEE 802.1 Local Experimental Ethertype 1.
From: Sjur Brændeland @ 2011-12-05 14:33 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev, Alexey Orishko, David S. Miller
In-Reply-To: <ff290c739be323dec89d19ed905feb94@chewa.net>
Hi Rémi,
> It's even weirder then. If you have control over both ends and the NCM 1.0
> interface is not adequate, then you really should use your own CDC class
> for the purpose.
The reason we use NCM is performance: CDC normally gives less than 100Mbps,
while NCM can give you up to 200Mbps.
Regards,
Sjur
^ permalink raw reply
* Re: [RFC 2/3] if_ether.h: Add IEEE 802.1 Local Experimental Ethertype 1.
From: Rémi Denis-Courmont @ 2011-12-05 14:03 UTC (permalink / raw)
To: Sjur Brændeland; +Cc: netdev, Alexey Orishko, David S. Miller
In-Reply-To: <CAJK669bK8kBXfc=j1q5NWEDCgSZwO0O=LsZ8z5GzB0S07gwBEQ@mail.gmail.com>
On Mon, 5 Dec 2011 14:14:30 +0100, Sjur Brændeland <sjurbren@gmail.com>
wrote:
>> I don't think you can just go and steal a reserved EtherType. What if
>> some user-space (using packet sockets) or out-of-tree kernel driver
>> does actual "experiment" with this type?
>
> I don't think defining this type in if_ether.h would harm anyone ;-)
>
> I think your comments are applicable for the patch:
> "caif: Add support for CAIF over CDC NCM USB interface".
That patch makes no sense without this patch. I comment on the first patch
in the series that exhibits the problem.
> Currently CAIF over CDC NCM USB is only deployed for the Ethernet link
> between Host and Modem internally in a Smart Phone, and not out of the
> Smart Phone (Tethering). The modem's Ethernet interface is connected to
> the CAIF stack and not to the modem's IP stack.On the Linux Host,
> CAIF takes this EthType into use *only* for a Ethernet interface with
> the VID/PID of a ST-E CAIF modem.
It's even weirder then. If you have control over both ends and the NCM 1.0
interface is not adequate, then you really should use your own CDC class
for the purpose.
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* Re: [net-next 1/6] e1000e: Avoid wrong check on TX hang
From: Flavio Leitner @ 2011-12-05 13:49 UTC (permalink / raw)
To: Michael Wang; +Cc: Jeff Kirsher, davem, netdev, gospo, sassmann
In-Reply-To: <4EDC82AE.40806@linux.vnet.ibm.com>
On Mon, 05 Dec 2011 16:37:02 +0800
Michael Wang <wangyun@linux.vnet.ibm.com> wrote:
> Hi, Jeff
>
> Please reserve "From: Michael Wang <wangyun@linux.vnet.ibm.com>" in
> content. And because Flavio not respond these days, I add his name
> for him.
>
> Thanks,
> Michael Wang
>
> On 12/05/2011 04:20 PM, Jeff Kirsher wrote:
>
> > Based on the original patch submitted my Michael Wang
> > <wangyun@linux.vnet.ibm.com>.
>
> From: Michael Wang <wangyun@linux.vnet.ibm.com>
>
> > Descriptors may not be write-back while checking TX hang with flag
> > FLAG2_DMA_BURST on.
> > So when we detect hang, we just flush the descriptor and detect
> > again for once.
> >
> > -v2 change 1 to true and 0 to false and remove extra ()
> >
> > CC: Michael Wang <wangyun@linux.vnet.ibm.com>
> > CC: Flavio Leitner <fbl@redhat.com>
>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Agree with the fixes. thanks,
Signed-off-by: Flavio Leitner <fbl@redhat.com>
^ permalink raw reply
* Re: Integration of Open vSwitch
From: Jamal Hadi Salim @ 2011-12-05 13:49 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Chris Wright, Herbert Xu,
Eric Dumazet, netdev, John Fastabend, Stephen Hemminger,
David Miller
In-Reply-To: <CAEP_g=8UM17Jbv2Y7ag7kO7BuXENDiitKydXMjiNtB+-uyxvKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Jesse,
I empathize with effort youve put in, i really do; youve
already created the messaging from user space to kernel
and dammit it works; however, i dont agree with your reasoning.
The classifier action code is _exactly_ the same infrastructure.
The user space API/messaging already exists. If there are actions
or a classifier missing - add it.
I wish i had the time to re-write the pieces i think need
changing. If the plan is to migrate to the current tc action
code, I will be fine with it - but you are not even suggesting
that.
I think i will punt this to DaveM to make the call.
cheers,
jamal
On Fri, 2011-12-02 at 15:30 -0800, Jesse Gross wrote:
>
> I completely agree with the desire to share code where there's overlap
> and it makes sense (I was actually just working on some refactoring to
> increase code reuse before this).
>
> I think one of the key things to focus on is the userspace/kernel
> interface since we'll have much less opportunity to significantly
> change that over time. Getting both compatibility and performance is
> something that we've worked on a fair amount and have arrived at a
> solution that meets the needs of OVS (and probably only OVS) pretty
> well. I think it's a nice model but keeping that while refactoring on
> top of the tc layer seems challenging to do cleanly because the flow
> information is needed by both the flow lookup and userspace
> communication. Stringing that through generic code seems fairly
> unappealing.
>
> So I agree with you in principle and if you are right that things tend
> to converge there should be more room for code reuse over time. Right
> now though I would just focus on the high level bits.
^ permalink raw reply
* Re: ipv4: Perform peer validation on cached route lookup.
From: Dan Carpenter @ 2011-12-05 13:31 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20111205132714.GA27452@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 92 bytes --]
The continue in __ip_route_output_key() has the same issue as well.
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* re: ipv4: Perform peer validation on cached route lookup.
From: Dan Carpenter @ 2011-12-05 13:27 UTC (permalink / raw)
To: davem; +Cc: netdev
Hello David S. Miller,
This is a semi-automatic email about new static checker warnings.
The patch efbc368dcc64: "ipv4: Perform peer validation on cached
route lookup." from Dec 1, 2011, leads to the following Smatch
complaint:
net/ipv4/route.c +2369 ip_route_input_common()
error: we previously assumed 'rth' could be null (see line 2378)
net/ipv4/route.c
2368 for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
2369 rth = rcu_dereference(rth->dst.rt_next)) {
^^^^^^^^^^^^^^^^
The dereference here will oops
2370 if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
2371 ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
2372 (rth->rt_route_iif ^ iif) |
2373 (rth->rt_key_tos ^ tos)) == 0 &&
2374 rth->rt_mark == skb->mark &&
2375 net_eq(dev_net(rth->dst.dev), net) &&
2376 !rt_is_expired(rth)) {
2377 rth = ipv4_validate_peer(rth);
2378 if (!rth)
2379 continue;
if we hit this new continue statement.
2380 if (noref) {
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC 2/3] if_ether.h: Add IEEE 802.1 Local Experimental Ethertype 1.
From: Sjur Brændeland @ 2011-12-05 13:14 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev, Alexey Orishko, David S. Miller
In-Reply-To: <5636a5efd90c56b538569ab019d7be4c@chewa.net>
Hi Rémi,
>> Add EthType 0x88b5.
>> This Ethertype value is available for public use for prototype and
>> vendor-specific protocol development,as defined in Amendment 802a
>> to IEEE Std 802.
>
> I don't think you can just go and steal a reserved EtherType. What if some
> user-space (using packet sockets) or out-of-tree kernel driver does actual
> "experiment" with this type?
I don't think defining this type in if_ether.h would harm anyone ;-)
I think your comments are applicable for the patch:
"caif: Add support for CAIF over CDC NCM USB interface".
Currently CAIF over CDC NCM USB is only deployed for the Ethernet link
between Host and Modem internally in a Smart Phone, and not out of the
Smart Phone (Tethering). The modem's Ethernet interface is connected to
the CAIF stack and not to the modem's IP stack.On the Linux Host,
CAIF takes this EthType into use *only* for a Ethernet interface with
the VID/PID of a ST-E CAIF modem.
With this setup I have a hard time seeing the big risk of interference with
others using this Ethernet Type.
We use Ethernet for this point-to-point link because NCM 1.0 only
defines Ethernet as the only bearer. The long term solution for CAIF over
NCM should be based on MBIM 1.0 specification, where vendor specific
services can be define. We could then transmit CAIF frames directly
in a vendor specific service without the use of a Ethernet header.
> Why don't you define your own link-layer, e.g. with a vendor-specific CDC
> profile?
I look into this...
BTW: Could you please do "reply-all" next time, so I get your mail in my inbox.
Regards,
Sjur
^ permalink raw reply
* [BUG] net: WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xb7/0xe0()
From: Sasha Levin @ 2011-12-05 13:01 UTC (permalink / raw)
To: marcel, padovan, davem; +Cc: Dave Jones, linux-kernel, netdev
Hi,
When closing and opening a HCI device, a device id may be assigned
before the previous one was fully released. It manifests itself for
example in a warning when the new sysfs entry is being added before the
previous one was deleted:
[ 5711.916643] ------------[ cut here ]------------
[ 5711.918640] WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xb7/0xe0()
[ 5711.920203] sysfs: cannot create duplicate filename '/devices/virtual/bluetooth/hci0'
[ 5711.921866] Pid: 20596, comm: trinity Not tainted 3.2.0-rc4-next-20111205-sasha-00003-gd1b8117 #48
[ 5711.923256] Call Trace:
[ 5711.923651] [<ffffffff810aec45>] warn_slowpath_common+0x75/0xb0
[ 5711.924600] [<ffffffff810aece1>] warn_slowpath_fmt+0x41/0x50
[ 5711.925503] [<ffffffff812196d7>] sysfs_add_one+0xb7/0xe0
[ 5711.926357] [<ffffffff81219785>] create_dir+0x85/0xe0
[ 5711.927267] [<ffffffff812198fb>] sysfs_create_dir+0x7b/0xc0
[ 5711.928555] [<ffffffff817a7201>] kobject_add_internal+0x121/0x200
[ 5711.929947] [<ffffffff817a73dd>] kobject_add+0x6d/0xb0
[ 5711.931170] [<ffffffff819f8e1b>] device_add+0xcb/0x700
[ 5711.932073] [<ffffffff819f8c8c>] ? dev_set_name+0x3c/0x40
[ 5711.932911] [<ffffffff821d166c>] ? hci_register_dev+0x56c/0x690
[ 5711.933859] [<ffffffff821e23e2>] hci_add_sysfs+0x52/0x150
[ 5711.934733] [<ffffffff821d16a6>] hci_register_dev+0x5a6/0x690
[ 5711.935678] [<ffffffff81d423fb>] vhci_open+0xfb/0x190
[ 5711.936777] [<ffffffff818a5cd1>] misc_open+0x81/0x110
[ 5711.937951] [<ffffffff811a4f9f>] chrdev_open+0x7f/0x150
[ 5711.939152] [<ffffffff811a4f20>] ? cdev_put+0x10/0x10
[ 5711.940410] [<ffffffff8119e122>] __dentry_open+0x282/0x3b0
[ 5711.941513] [<ffffffff8119f274>] nameidata_to_filp+0x74/0x80
[ 5711.942448] [<ffffffff811aed2c>] do_last+0x1bc/0x940
[ 5711.943268] [<ffffffff811af586>] path_openat+0xd6/0x440
[ 5711.944124] [<ffffffff8104a1f3>] ? sched_clock+0x13/0x20
[ 5711.945104] [<ffffffff810d6605>] ? sched_clock_local+0x25/0x90
[ 5711.946065] [<ffffffff811af934>] do_filp_open+0x44/0xa0
[ 5711.947261] [<ffffffff810a3a1d>] ? sub_preempt_count+0x9d/0xd0
[ 5711.948614] [<ffffffff823db830>] ? _raw_spin_unlock+0x30/0x60
[ 5711.949917] [<ffffffff811be6d5>] ? alloc_fd+0x185/0x1f0
[ 5711.951126] [<ffffffff8119f79c>] do_sys_open+0xfc/0x1d0
[ 5711.951949] [<ffffffff8119f88b>] sys_open+0x1b/0x20
[ 5711.952742] [<ffffffff823dcf52>] system_call_fastpath+0x16/0x1b
[ 5711.953739] ---[ end trace 6eef4878a8c24f09 ]---
But it may also cause more things which are not as visible.
Please let me know if I can help with debugging this issue.
--
Sasha.
^ permalink raw reply
* eth0: hw csum failure
From: Pavel Mateja @ 2011-12-05 12:51 UTC (permalink / raw)
To: netdev
Hi,
I'm trying new kernel and I got my dmesg flooded with traces:
[ 78.068024] eth0: hw csum failure.
[ 78.068030] Pid: 0, comm: kworker/0:0 Not tainted 3.1.0-rc3+ #13
[ 78.068033] Call Trace:
[ 78.068035] <IRQ> [<ffffffff81225bc6>] ? netdev_rx_csum_fault+0x29/0x31
[ 78.068048] [<ffffffff8121fb86>] ? __skb_checksum_complete_head+0x41/0x53
[ 78.068058] [<ffffffffa02da598>] ? br_multicast_rcv+0x7e8/0xca1 [bridge]
[ 78.068063] [<ffffffff8118b424>] ? swiotlb_map_sg_attrs+0xe8/0x10e
[ 78.068077] [<ffffffffa0051547>] ? ahci_qc_prep+0x59/0x108 [libahci]
[ 78.068083] [<ffffffffa0050e15>] ? ahci_qc_issue+0x11/0xdb [libahci]
[ 78.068093] [<ffffffffa0021bd2>] ? ata_qc_issue+0x28b/0x2c5 [libata]
[ 78.068099] [<ffffffff8102ec2c>] ? select_task_rq_fair+0x369/0x610
[ 78.068108] [<ffffffffa0024fb2>] ? ata_qc_set_pc_nbytes+0x1b/0x1b [libata]
[ 78.068114] [<ffffffffa02d4fb8>] ? br_handle_frame_finish+0x90/0x1fe [bridge]
[ 78.068121] [<ffffffffa02d52cc>] ? br_handle_frame+0x1a6/0x1be [bridge]
[ 78.068127] [<ffffffffa02d5126>] ? br_handle_frame_finish+0x1fe/0x1fe [bridge]
[ 78.068132] [<ffffffff81223181>] ? __netif_receive_skb+0x162/0x2a8
[ 78.068136] [<ffffffff812264eb>] ? netif_receive_skb+0x63/0x69
[ 78.068140] [<ffffffff8122691a>] ? napi_gro_receive+0x1d/0x2b
[ 78.068143] [<ffffffff81226567>] ? napi_skb_finish+0x1c/0x31
[ 78.068151] [<ffffffffa00c4c9f>] ? sky2_poll+0x781/0x99c [sky2]
[ 78.068155] [<ffffffff812269ea>] ? net_rx_action+0x61/0x14f
[ 78.068161] [<ffffffff81039e2b>] ? __do_softirq+0xb5/0x16f
[ 78.068166] [<ffffffff812ce2ac>] ? call_softirq+0x1c/0x30
[ 78.068170] [<ffffffff8100375b>] ? do_softirq+0x2e/0x63
[ 78.068174] [<ffffffff8103a087>] ? irq_exit+0x3c/0x9a
[ 78.068177] [<ffffffff810034a1>] ? do_IRQ+0x82/0x98
[ 78.068182] [<ffffffff812c792b>] ? common_interrupt+0x6b/0x6b
[ 78.068184] <EOI> [<ffffffff81008056>] ? mwait_idle+0x7f/0xa5
[ 78.068192] [<ffffffff81008049>] ? mwait_idle+0x72/0xa5
[ 78.068195] [<ffffffff8100123b>] ? cpu_idle+0xa0/0xda
[ 78.068199] [<ffffffff812c7654>] ? _raw_spin_unlock_irqrestore+0x5/0xf
[ 78.068205] [<ffffffff812bb779>] ? start_secondary+0x1c9/0x1cf
If i did git bisect right it was caused by commit
4b275d7efa1c4412f0d572fcd7f78ed0919370b3
bridge: Pseudo-header required for the checksum of ICMPv6
Problem disappears when I turn off HW checksum via ethtool.
Can anybody help?
--
Pavel Mateja
^ permalink raw reply
* Re: sky2 tx watchdog timeout with 1Gb speed
From: Milan Kocian @ 2011-12-05 12:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20111126170331.744025f1@s6510.linuxnetplumber.net>
On Sat, Nov 26, 2011 at 05:03:31PM -0800, Stephen Hemminger wrote:
>
> I think the problem might be that the board doesn't really have all the DMA pins
> wired. You might try enabling iommu, or limiting to <4G of memory.
hello stephen,
you are probably right. I found that with this mb (Gigabyte GA-965GM-S2) was
more problems with linux. So I replaced this old crap with new one :-).
Many thanks for your time.
Best regards,
--
Milan Kocian
^ permalink raw reply
* [PATCH net-next] ipv4: arp: Cleanup in arp.c
From: igorm @ 2011-12-05 12:25 UTC (permalink / raw)
To: netdev; +Cc: davem, Igor Maravic
From: Igor Maravic <igorm@etf.rs>
Use "IS_ENABLED(CONFIG_FOO)" macro instead of
"defined(CONFIG_FOO) || defined(CONFIG_FOO_MODULE)"
Signed-off-by: Igor Maravic <igorm@etf.rs>
---
net/ipv4/arp.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index ff324eb..381a087 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -277,9 +277,9 @@ static int arp_constructor(struct neighbour *neigh)
default:
break;
case ARPHRD_ROSE:
-#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
+#if IS_ENABLED(CONFIG_AX25)
case ARPHRD_AX25:
-#if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE)
+#if IS_ENABLED(CONFIG_NETROM)
case ARPHRD_NETROM:
#endif
neigh->ops = &arp_broken_ops;
@@ -629,13 +629,13 @@ struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
arp->ar_pro = htons(ETH_P_IP);
break;
-#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
+#if IS_ENABLED(CONFIG_AX25)
case ARPHRD_AX25:
arp->ar_hrd = htons(ARPHRD_AX25);
arp->ar_pro = htons(AX25_P_IP);
break;
-#if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE)
+#if IS_ENABLED(CONFIG_NETROM)
case ARPHRD_NETROM:
arp->ar_hrd = htons(ARPHRD_NETROM);
arp->ar_pro = htons(AX25_P_IP);
@@ -643,13 +643,13 @@ struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
#endif
#endif
-#if defined(CONFIG_FDDI) || defined(CONFIG_FDDI_MODULE)
+#if IS_ENABLED(CONFIG_FDDI)
case ARPHRD_FDDI:
arp->ar_hrd = htons(ARPHRD_ETHER);
arp->ar_pro = htons(ETH_P_IP);
break;
#endif
-#if defined(CONFIG_TR) || defined(CONFIG_TR_MODULE)
+#if IS_ENABLED(CONFIG_TR)
case ARPHRD_IEEE802_TR:
arp->ar_hrd = htons(ARPHRD_IEEE802);
arp->ar_pro = htons(ETH_P_IP);
@@ -1036,7 +1036,7 @@ static int arp_req_set(struct net *net, struct arpreq *r,
return -EINVAL;
}
switch (dev->type) {
-#if defined(CONFIG_FDDI) || defined(CONFIG_FDDI_MODULE)
+#if IS_ENABLED(CONFIG_FDDI)
case ARPHRD_FDDI:
/*
* According to RFC 1390, FDDI devices should accept ARP
@@ -1282,7 +1282,7 @@ void __init arp_init(void)
}
#ifdef CONFIG_PROC_FS
-#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
+#if IS_ENABLED(CONFIG_AX25)
/* ------------------------------------------------------------------------ */
/*
@@ -1330,7 +1330,7 @@ static void arp_format_neigh_entry(struct seq_file *seq,
read_lock(&n->lock);
/* Convert hardware address to XX:XX:XX:XX ... form. */
-#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
+#if IS_ENABLED(CONFIG_AX25)
if (hatype == ARPHRD_AX25 || hatype == ARPHRD_NETROM)
ax2asc2((ax25_address *)n->ha, hbuffer);
else {
@@ -1343,7 +1343,7 @@ static void arp_format_neigh_entry(struct seq_file *seq,
if (k != 0)
--k;
hbuffer[k] = 0;
-#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
+#if IS_ENABLED(CONFIG_AX25)
}
#endif
sprintf(tbuf, "%pI4", n->primary_key);
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 2/2] ARM: at91/net: add macb ethernet controller in 9g45 DT
From: Nicolas Ferre @ 2011-12-05 11:59 UTC (permalink / raw)
To: robherring2, devicetree-discuss, netdev, plagnioj
Cc: linux-arm-kernel, grant.likely, linux-kernel, jamie,
Nicolas Ferre
In-Reply-To: <714ca7492d8d45b50eab34448c4b70933ce5701c.1323086095.git.nicolas.ferre@atmel.com>
Add the Cadence macb ethernet controller in at91sam9g45 .dtsi and
enable it in at91sam9m10g45ek board device tree file.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
v3: - form a thread with "macb DT support" patch
- remove "local-mac-address" from 9m10g45ek.dts file but use it in
documentation example.
Documentation/devicetree/bindings/net/macb.txt | 1 +
arch/arm/boot/dts/at91sam9g45.dtsi | 7 +++++++
arch/arm/boot/dts/at91sam9m10g45ek.dts | 5 +++++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 2e24f05..44afa0e 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -21,4 +21,5 @@ Examples:
reg = <0xfffc4000 0x4000>;
interrupts = <21>;
phy-mode = "rmii";
+ local-mac-address = [3a 0e 03 04 05 06];
};
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index e89b1d7..67f94d3 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -101,6 +101,13 @@
atmel,use-dma-tx;
status = "disabled";
};
+
+ macb0: ethernet@fffbc000 {
+ compatible = "cdns,at32ap7000-macb", "cdns,macb";
+ reg = <0xfffbc000 0x100>;
+ interrupts = <25 4>;
+ status = "disabled";
+ };
};
};
};
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 85b34f5..a387e77 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -30,6 +30,11 @@
usart1: serial@fff90000 {
status = "okay";
};
+
+ macb0: ethernet@fffbc000 {
+ phy-mode = "rmii";
+ status = "okay";
+ };
};
};
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 1/2] net/macb: add DT support for Cadence macb/gem driver
From: Nicolas Ferre @ 2011-12-05 11:59 UTC (permalink / raw)
To: robherring2-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, plagnioj-sclMFOaUSTBWk0Htik3J/w
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1322847782-22650-1-git-send-email-nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Allow the device tree to provide the mac address and the phy mode.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
[nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org: change "compatible" node property, doc and DT hwaddr]
Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
[jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org: add "gem" compatibility strings and doc]
Acked-by: Jamie Iles<jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>
---
v3: add "gem" compatibility strings
v2: modify macb_get_hwaddr_dt() parameter
Documentation/devicetree/bindings/net/macb.txt | 24 ++++++++
drivers/net/ethernet/cadence/macb.c | 73 +++++++++++++++++++++---
drivers/net/ethernet/cadence/macb.h | 2 +
3 files changed, 91 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/macb.txt
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
new file mode 100644
index 0000000..2e24f05
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -0,0 +1,24 @@
+* Cadence MACB/GEM Ethernet controller
+
+Required properties:
+- compatible: Should be "cdns,[<chip>-]{macb|gem}"
+ Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
+ Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
+ Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
+ the Cadence GEM, or the generic form: "cdns,gem".
+- reg: Address and length of the register set for the device
+- interrupts: Should contain macb interrupt
+- phy-mode: String, operation mode of the PHY interface.
+ Supported values are: "mii", "rmii", "gmii", "rgmii".
+
+Optional properties:
+- local-mac-address: 6 bytes, mac address
+
+Examples:
+
+ macb0: ethernet@fffc4000 {
+ compatible = "cdns,at32ap7000-macb";
+ reg = <0xfffc4000 0x4000>;
+ interrupts = <21>;
+ phy-mode = "rmii";
+ };
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 64d6146..baf1a0d 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -23,6 +23,8 @@
#include <linux/platform_data/macb.h>
#include <linux/platform_device.h>
#include <linux/phy.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
#include "macb.h"
@@ -191,7 +193,6 @@ static int macb_mii_probe(struct net_device *dev)
{
struct macb *bp = netdev_priv(dev);
struct phy_device *phydev;
- struct macb_platform_data *pdata;
int ret;
phydev = phy_find_first(bp->mii_bus);
@@ -200,14 +201,11 @@ static int macb_mii_probe(struct net_device *dev)
return -1;
}
- pdata = bp->pdev->dev.platform_data;
/* TODO : add pin_irq */
/* attach the mac to the phy */
ret = phy_connect_direct(dev, phydev, &macb_handle_link_change, 0,
- pdata && pdata->is_rmii ?
- PHY_INTERFACE_MODE_RMII :
- PHY_INTERFACE_MODE_MII);
+ bp->phy_interface);
if (ret) {
netdev_err(dev, "Could not attach to PHY\n");
return ret;
@@ -1244,6 +1242,52 @@ static const struct net_device_ops macb_netdev_ops = {
#endif
};
+#if defined(CONFIG_OF)
+static const struct of_device_id macb_dt_ids[] = {
+ { .compatible = "cdns,at32ap7000-macb" },
+ { .compatible = "cdns,at91sam9260-macb" },
+ { .compatible = "cdns,macb" },
+ { .compatible = "cdns,pc302-gem" },
+ { .compatible = "cdns,gem" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, macb_dt_ids);
+
+static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+
+ if (np)
+ return of_get_phy_mode(np);
+
+ return -ENODEV;
+}
+
+static int __devinit macb_get_hwaddr_dt(struct macb *bp)
+{
+ struct device_node *np = bp->pdev->dev.of_node;
+ if (np) {
+ const char *mac = of_get_mac_address(np);
+ if (mac) {
+ memcpy(bp->dev->dev_addr, mac, ETH_ALEN);
+ return 0;
+ }
+ }
+
+ return -ENODEV;
+}
+#else
+static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
+{
+ return -ENODEV;
+}
+static int __devinit macb_get_hwaddr_dt(struct macb *bp)
+{
+ return -ENODEV;
+}
+#endif
+
static int __init macb_probe(struct platform_device *pdev)
{
struct macb_platform_data *pdata;
@@ -1318,10 +1362,22 @@ static int __init macb_probe(struct platform_device *pdev)
config |= macb_dbw(bp);
macb_writel(bp, NCFGR, config);
- macb_get_hwaddr(bp);
- pdata = pdev->dev.platform_data;
+ err = macb_get_hwaddr_dt(bp);
+ if (err < 0)
+ macb_get_hwaddr(bp);
+
+ err = macb_get_phy_mode_dt(pdev);
+ if (err < 0) {
+ pdata = pdev->dev.platform_data;
+ if (pdata && pdata->is_rmii)
+ bp->phy_interface = PHY_INTERFACE_MODE_RMII;
+ else
+ bp->phy_interface = PHY_INTERFACE_MODE_MII;
+ } else {
+ bp->phy_interface = err;
+ }
- if (pdata && pdata->is_rmii)
+ if (bp->phy_interface == PHY_INTERFACE_MODE_RMII)
#if defined(CONFIG_ARCH_AT91)
macb_or_gem_writel(bp, USRIO, (MACB_BIT(RMII) |
MACB_BIT(CLKEN)));
@@ -1444,6 +1500,7 @@ static struct platform_driver macb_driver = {
.driver = {
.name = "macb",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(macb_dt_ids),
},
};
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 1931078..335e288 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -532,6 +532,8 @@ struct macb {
unsigned int link;
unsigned int speed;
unsigned int duplex;
+
+ phy_interface_t phy_interface;
};
static inline bool macb_is_gem(struct macb *bp)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] net/macb: add DT support
From: Nicolas Ferre @ 2011-12-05 11:51 UTC (permalink / raw)
To: Jamie Iles
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111205114838.GC21006@totoro>
On 12/05/2011 12:48 PM, Jamie Iles :
> On Fri, Dec 02, 2011 at 06:53:58PM +0100, Nicolas Ferre wrote:
>> On 12/02/2011 06:28 PM, Jamie Iles :
> [...]
>>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>>> index 103c6e6..89060e6 100644
>>> --- a/drivers/net/ethernet/cadence/macb.c
>>> +++ b/drivers/net/ethernet/cadence/macb.c
>>> @@ -1247,6 +1247,8 @@ static const struct of_device_id macb_dt_ids[] = {
>>> { .compatible = "cdns,at32ap7000-macb" },
>>> { .compatible = "cdns,at91sam9260-macb" },
>>> { .compatible = "cdns,macb" },
>>> + { .compatible = "cdns,pc302-gem" },
>>> + { .compatible = "cdns,gem" },
>>> { /* sentinel */ }
>>> };
>>
>> BTW, I think we may also modify the MII/RMII selection code for
>> adding gigabit selection... but maybe you already have the patches?
>
> No, I don't have access to a version of the GEM with gigabit support.
> The platforms I was working on used it as a 10/100 controller, but had
> to use the GEM to get hardware timestamping support.
Ok, Thanks for your feedback. I send a v3 patch now.
Best regards,
--
Nicolas Ferre
^ 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