* Re: [PATCH] phy: Elimination the forced speed reduction algorithm.
From: David Miller @ 2013-03-15 12:51 UTC (permalink / raw)
To: joe
Cc: kapranoff, netdev, bhutchings, peppe.cavallaro, bruce.w.allan,
linux-kernel
In-Reply-To: <1363351729.2433.4.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Fri, 15 Mar 2013 05:48:49 -0700
> The phy code also uses non standard kernel style tests like
> if (CONSTANT == variable)
> instead of
> if (variable == CONSTANT)
Right, to trigger compile time errors when "=" is accidently used
instead of "==".
But the whole driver is like this already.
^ permalink raw reply
* Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli @ 2013-03-15 12:53 UTC (permalink / raw)
To: David Miller
Cc: grant.likely, rob.herring, rob, jason, andrew, linux, benh,
paulus, buytenh, thomas.petazzoni, gregkh, devicetree-discuss,
linux-doc, linux-kernel, linux-arm-kernel, linuxppc-dev, netdev
In-Reply-To: <20130315.085510.974056254781971889.davem@davemloft.net>
Le 03/15/13 13:55, David Miller a écrit :
> From: David Miller <davem@davemloft.net>
> Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
>
>> From: Florian Fainelli <florian@openwrt.org>
>> Date: Thu, 14 Mar 2013 19:08:31 +0100
>>
>>> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
>>> instead of rolling its own implementation. As a result, all users of this
>>> mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
>>> The mvmdio driver is also updated to support an interrupt line which reports
>>> SMI error/completion, and to allow traditionnal platform device registration
>>> instead of just device tree.
>>>
>>> David, I think it makes sense for you to merge all of this, since we do
>>> not want the architecture files to be desynchronized from the mv643xx_eth to
>>> avoid runtime breakage. The potential for merge conflicts should be very small.
>>
>> All applied to net-next, thanks.
>
> Actually, reverted. Please send me code which actually compiles:
>
> drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’:
> drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function)
> drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in
> drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’:
> drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function)
> make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1
>
> And don't use Kconfig dependencies to work around this, fix it properly.
Is there any platform out there for which we do not have a NO_IRQ
definition by now? If so, what is it?
--
Florian
^ permalink raw reply
* Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: David Miller @ 2013-03-15 12:53 UTC (permalink / raw)
To: florian
Cc: grant.likely, rob.herring, rob, jason, andrew, linux, benh,
paulus, buytenh, thomas.petazzoni, gregkh, devicetree-discuss,
linux-doc, linux-kernel, linux-arm-kernel, linuxppc-dev, netdev
In-Reply-To: <1363284515-9865-1-git-send-email-florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Thu, 14 Mar 2013 19:08:31 +0100
> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
> instead of rolling its own implementation. As a result, all users of this
> mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
> The mvmdio driver is also updated to support an interrupt line which reports
> SMI error/completion, and to allow traditionnal platform device registration
> instead of just device tree.
>
> David, I think it makes sense for you to merge all of this, since we do
> not want the architecture files to be desynchronized from the mv643xx_eth to
> avoid runtime breakage. The potential for merge conflicts should be very small.
All applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: David Miller @ 2013-03-15 12:55 UTC (permalink / raw)
To: florian
Cc: grant.likely, rob.herring, rob, jason, andrew, linux, benh,
paulus, buytenh, thomas.petazzoni, gregkh, devicetree-discuss,
linux-doc, linux-kernel, linux-arm-kernel, linuxppc-dev, netdev
In-Reply-To: <20130315.085321.1047694772636447477.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
> From: Florian Fainelli <florian@openwrt.org>
> Date: Thu, 14 Mar 2013 19:08:31 +0100
>
>> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
>> instead of rolling its own implementation. As a result, all users of this
>> mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
>> The mvmdio driver is also updated to support an interrupt line which reports
>> SMI error/completion, and to allow traditionnal platform device registration
>> instead of just device tree.
>>
>> David, I think it makes sense for you to merge all of this, since we do
>> not want the architecture files to be desynchronized from the mv643xx_eth to
>> avoid runtime breakage. The potential for merge conflicts should be very small.
>
> All applied to net-next, thanks.
Actually, reverted. Please send me code which actually compiles:
drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’:
drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function)
drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’:
drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function)
make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1
And don't use Kconfig dependencies to work around this, fix it properly.
^ permalink raw reply
* Re: [net-next 0/2] be2net patch set
From: David Miller @ 2013-03-15 12:57 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <73a526ce-eb3f-43fc-8678-5d524915b7c4@CMEXHTCAS2.ad.emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Thu, 14 Mar 2013 18:11:32 +0530
> Pls apply.
>
> Somnath Kotur (2):
> be2net: enable interrupts in be_probe() (RoCE and other ULPs need
> them)
> be2net: Use new F/W mailbox cmd to manipulate interrupts.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] drivers:net: Remove dma_alloc_coherent OOM messages
From: David Miller @ 2013-03-15 12:57 UTC (permalink / raw)
To: joe
Cc: netdev, e1000-devel, linux-arm-kernel, linux-wireless, wil6210,
b43-dev, linux-kernel
In-Reply-To: <1363302441.2146.30.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Thu, 14 Mar 2013 16:07:21 -0700
> I believe these error messages are already logged
> on allocation failure by warn_alloc_failed and so
> get a dump_stack on OOM.
>
> Remove the unnecessary additional error logging.
>
> Around these deletions:
>
> o Alignment neatening.
> o Remove unnecessary casts of dma_alloc_coherent.
> o Hoist assigns from ifs.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* Re: [GIT net] Open vSwitch
From: David Miller @ 2013-03-15 13:01 UTC (permalink / raw)
To: jesse; +Cc: netdev, dev
In-Reply-To: <1363306506-885-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 14 Mar 2013 17:15:00 -0700
> A few different bug fixes, including several for issues with userspace
> communication that have gone unnoticed up until now. These are intended
> for net/3.9.
Pulled, thanks.
^ permalink raw reply
* Re: linux-3.6+, gre+ipsec+forwarding = IP fragmentation broken
From: Timo Teras @ 2013-03-15 13:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130315133820.006a42f6@vostro>
On Fri, 15 Mar 2013 13:38:20 +0200
Timo Teras <timo.teras@iki.fi> wrote:
> [snip]
> Though, this implies that GSO cannot be used in ip_gre if ttl != inherit.
>
> I added some ip_gre debugging and the following seems to happen:
>
> - the mtu is calculated correctly on xmit path:
> dst_mtu(&rt->dst) = 1458 (the tunnel's XFRMed IPv4 path)
>
> - skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu);
> is called with mtu=1430, which seems correct
>
> - dst_mtu(skb_dst(skb)) seems to still return after above call the
> value 1472 which is wrong. so update_pmtu is not working.
>
> - skb->dev->ifindex implies skb->dev points to gre device when
> update_pmtu is being called (and not the ethX from which the packet
> was received), so ip_rt_update_pmtu() which eventually calls
> build_skb_flow_key() is likely using wrong ifindex for the flow
One more observation is that the outer dst is an input route. And it
seems that input routes do not consult nexthop exception tables for
setting the rt_pmtu. Thus rt_pmtu is never set for forwarding entries.
- Timo
^ permalink raw reply
* Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli @ 2013-03-15 13:03 UTC (permalink / raw)
To: David Miller
Cc: andrew-g2DYL2Zd6BY, linux-lFZ/pmaqli7XmaaqVzeoHQ,
jason-NLaQJdtUoK4Be96aLqz0jA, linux-doc-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, netdev-u79uwXL29TY76Z2rM5mHXA,
paulus-eUNUBHrolfbYtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
buytenh-OLH4Qvv75CYX/NnBR394Jw
In-Reply-To: <20130315.090517.2027403317215151155.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Le 03/15/13 14:05, David Miller a écrit :
> From: Florian Fainelli <florian@openwrt.org>
> Date: Fri, 15 Mar 2013 13:53:10 +0100
>
>> Le 03/15/13 13:55, David Miller a écrit :
>>> From: David Miller <davem@davemloft.net>
>>> Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
>>>
>>>> From: Florian Fainelli <florian@openwrt.org>
>>>> Date: Thu, 14 Mar 2013 19:08:31 +0100
>>>>
>>>>> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus
>>>>> driver
>>>>> instead of rolling its own implementation. As a result, all users of
>>>>> this
>>>>> mv643xx_eth driver are converted to register an "orion-mdio"
>>>>> platform_device.
>>>>> The mvmdio driver is also updated to support an interrupt line which
>>>>> reports
>>>>> SMI error/completion, and to allow traditionnal platform device
>>>>> registration
>>>>> instead of just device tree.
>>>>>
>>>>> David, I think it makes sense for you to merge all of this, since we
>>>>> do
>>>>> not want the architecture files to be desynchronized from the
>>>>> mv643xx_eth to
>>>>> avoid runtime breakage. The potential for merge conflicts should be
>>>>> very small.
>>>>
>>>> All applied to net-next, thanks.
>>>
>>> Actually, reverted. Please send me code which actually compiles:
>>>
>>> drivers/net/ethernet/marvell/mvmdio.c: In function
>>> ‘orion_mdio_wait_ready’:
>>> drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’
>>> undeclared (first use in this function)
>>> drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared
>>> identifier is reported only once for each function it appears in
>>> drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’:
>>> drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’
>>> undeclared (first use in this function)
>>> make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1
>>>
>>> And don't use Kconfig dependencies to work around this, fix it
>>> properly.
>>
>> Is there any platform out there for which we do not have a NO_IRQ
>> definition by now? If so, what is it?
>
> Obviously if x86_64 doesn't even build your changes, that is one such
> platform. Also, is grep not working on your computer?
I built tested on PowerPC and ARM which are the platforms actually
*using* these drivers and forgot that you build for x86_64.
>
> Platforms are absolutely no required to have this define, zero is the
> only valid "no IRQ" which is portable in any way.
>
> This is an old and tired topic, portable code does not use NO_IRQ, and
> that's simply the end of it.
I changed not to rely on NO_IRQ anymore. Thanks!
--
Florian
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: David Miller @ 2013-03-15 13:05 UTC (permalink / raw)
To: florian
Cc: grant.likely, rob.herring, rob, jason, andrew, linux, benh,
paulus, buytenh, thomas.petazzoni, gregkh, devicetree-discuss,
linux-doc, linux-kernel, linux-arm-kernel, linuxppc-dev, netdev
In-Reply-To: <514319B6.7030307@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Fri, 15 Mar 2013 13:53:10 +0100
> Le 03/15/13 13:55, David Miller a écrit :
>> From: David Miller <davem@davemloft.net>
>> Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
>>
>>> From: Florian Fainelli <florian@openwrt.org>
>>> Date: Thu, 14 Mar 2013 19:08:31 +0100
>>>
>>>> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus
>>>> driver
>>>> instead of rolling its own implementation. As a result, all users of
>>>> this
>>>> mv643xx_eth driver are converted to register an "orion-mdio"
>>>> platform_device.
>>>> The mvmdio driver is also updated to support an interrupt line which
>>>> reports
>>>> SMI error/completion, and to allow traditionnal platform device
>>>> registration
>>>> instead of just device tree.
>>>>
>>>> David, I think it makes sense for you to merge all of this, since we
>>>> do
>>>> not want the architecture files to be desynchronized from the
>>>> mv643xx_eth to
>>>> avoid runtime breakage. The potential for merge conflicts should be
>>>> very small.
>>>
>>> All applied to net-next, thanks.
>>
>> Actually, reverted. Please send me code which actually compiles:
>>
>> drivers/net/ethernet/marvell/mvmdio.c: In function
>> ‘orion_mdio_wait_ready’:
>> drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’
>> undeclared (first use in this function)
>> drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared
>> identifier is reported only once for each function it appears in
>> drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’:
>> drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’
>> undeclared (first use in this function)
>> make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1
>>
>> And don't use Kconfig dependencies to work around this, fix it
>> properly.
>
> Is there any platform out there for which we do not have a NO_IRQ
> definition by now? If so, what is it?
Obviously if x86_64 doesn't even build your changes, that is one such
platform. Also, is grep not working on your computer?
Platforms are absolutely no required to have this define, zero is the
only valid "no IRQ" which is portable in any way.
This is an old and tired topic, portable code does not use NO_IRQ, and
that's simply the end of it.
^ permalink raw reply
* Re: [PATCH] smsc75xx: configuration help incorrectly mentions smsc95xx
From: David Miller @ 2013-03-15 13:07 UTC (permalink / raw)
To: rhdv; +Cc: netdev
In-Reply-To: <1363289346-3084-1-git-send-email-rhdv@xs4all.nl>
From: Robert de Vries <rhdv@xs4all.nl>
Date: Thu, 14 Mar 2013 20:29:06 +0100
> The Kconfig file help information incorrectly mentions that the
> SMSC LAN75xx config option is for SMSC LAN95xx devices.
>
> Signed-off-by: Robert de Vries <rhdv@xs4all.nl>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1 v2] Fix dst_neigh_lookup/dst_neigh_lookup_skb return value handling bug
From: David Miller @ 2013-03-15 13:07 UTC (permalink / raw)
To: zhouzhouyi; +Cc: netdev, yizhouzhou
In-Reply-To: <1363317710-30151-1-git-send-email-zhouzhouyi@gmail.com>
From: Zhouyi Zhou <zhouzhouyi@gmail.com>
Date: Fri, 15 Mar 2013 11:21:50 +0800
> When neighbour table is full, dst_neigh_lookup/dst_neigh_lookup_skb will return
> -ENOBUFS which is absolutely non zero, while all the code in kernel which use
> above functions assume failure only on zero return which will cause panic. (for
> example: : https://bugzilla.kernel.org/show_bug.cgi?id=54731).
>
> This patch corrects above error with smallest changes to kernel source code and
> also correct two return value check missing bugs in drivers/infiniband/hw/cxgb4/cm.c
>
> Tested on my x86_64 SMP machine
>
> Reported-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> Tested-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] Documentation: fix neigh/default/gc_thresh1 default value.
From: David Miller @ 2013-03-15 13:12 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1363337387-9536-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 15 Mar 2013 16:49:47 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> The default value is 128, not 256
> #grep gc_thresh1 net/ -rI
> net/decnet/dn_neigh.c: .gc_thresh1 = 128,
> net/ipv6/ndisc.c: .gc_thresh1 = 128,
> net/ipv4/arp.c: .gc_thresh1 = 128,
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] driver/qlogic: replace ip_fast_csum with csum_replace2
From: David Miller @ 2013-03-15 13:12 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1363337407-9573-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 15 Mar 2013 16:50:07 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> replace ip_fast_csum with csum_replace2 to save cpu cycles
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: replace ip_fast_csum with csum_replace2
From: David Miller @ 2013-03-15 13:12 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1363337418-9609-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 15 Mar 2013 16:50:18 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> replace ip_fast_csum with csum_replace2 to save cpu cycles
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] isdn: hisax: netjet requires VIRT_TO_BUS
From: Arnd Bergmann @ 2013-03-15 13:41 UTC (permalink / raw)
To: David Miller
Cc: geert, linux-kernel, linux-arm-kernel, isdn, netdev, dhowells
In-Reply-To: <20130315.083344.2224038988420448687.davem@davemloft.net>
On Friday 15 March 2013, David Miller wrote:
> The first usage seems reason, but the temtation is going to be quite
> strong to misuse to block out drivers when there is "no value" in
> spending time necessary to simply make them endian clean instead.
Right. I'll let someone else start that discussion then if they
really want to see that patch.
Arnd
^ permalink raw reply
* DaVinci platform unable to boot via NFS
From: Prabhakar Lad @ 2013-03-15 13:41 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, dlos, Sekhar Nori, LAK
Hi Mugunthan,
With 3.9 release I am not able to boot any davinci board via nfs, finally
digging Into I found that there were recent changes for Ethernet davinci.
Finally I reverting this to some safe commit I was able to boot via nfs.
I reverted back as following:-
git checkout f9a8f83b04e0c362a2fc660dbad980d24af209fc drivers/net/ethernet/ti/
Can you please take a look at and fix it.
Cheers,
--Prabhakar Lad
http://in.linkedin.com/pub/prabhakar-lad/19/92b/955
^ permalink raw reply
* Re: [PATCH 1/1] Fix dst_neigh_lookup/dst_neigh_lookup_skb return value handling bug
From: Steve Wise @ 2013-03-15 13:42 UTC (permalink / raw)
To: Zhouyi Zhou
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
yizhouzhou-6xnC4QlcT6v/PtFMR13I2A, swise-ut6Up61K2wZBDgjK7y7TUQ,
roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1363232492-4562-1-git-send-email-zhouzhouyi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Trying to implement secondary loopback
From: Thomas Martitz @ 2013-03-15 13:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: richard -rw- weinberger, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com,
herbert@gondor.apana.org.au
In-Reply-To: <87ip4t598t.fsf@xmission.com>
Am 15.03.2013 09:59, schrieb Eric W. Biederman:
>>
>>
>> I have trouble understanding this approach. Does it mean that I have
>> to expose two interfaces from my kernel module. I.e. call
>> register_netdev() twice?
>
> The suggestion was to have one driver, driving two identical nics
> plugged into the same machine with a cable between them. That creates no
> special cases on your side for testing.
The NIC doesn't exist yet, I'm developing it along with the driver (both
part of my Master thesis). I'm implementing it in VHDL for an FPGA that
is on a PCIe card, and I can only use one card.
During development of the NIC I want to approach from the kernel module
level over to PCIe, MAC hardware and finally PHY level. For each of
these I want to establish a loopback mechanism for testing and
verification as I progress (and loopback because the level below doesn't
exist yet).
>
> Shrug. It is your driver, and your hardware, feel free to
> develop however you want.
>
>> Or use a "struct pernet_operations" to create
>> a netdev on a per-namespace basis.
>> If I do either of the above I end up with two "struct netdev" and two
>> MAC addresses, which I don't really want. Also I would need to
>> transfer from one netdev to the other in the driver's ndo_start_xmit()
>> method instead of simply calling netif_rx().
>>
>> Perhaps I'm misunderstanding, I'm s
>>
>> During my development, looping back the data in ndo_start_xmit() is
>> only a first step. The next step is to pass the data via PCIe and
>> getting the same data back later. This is why I want to keep the
>> loopback as simple/straightforward as possible.
>
> I guess the question is why do you want to loopback the data?
>
> For testing your NIC driver? Or are you trying some strange scheme
> where you try and offload processing between sockets on the same machine?
>
I want the loopback during development of the NIC hardware. Once the NIC
is done I drop the loopback and the card will be used for real networking.
Thus, I want the loopback to a) test my driver, and b) test the hardware
(for each milestone) as I'm implementing it.
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply
* Re: Trying to implement secondary loopback
From: richard -rw- weinberger @ 2013-03-15 13:56 UTC (permalink / raw)
To: Thomas Martitz
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
In-Reply-To: <514326FF.6020205@hhi.fraunhofer.de>
On Fri, Mar 15, 2013 at 2:49 PM, Thomas Martitz
<thomas.martitz@hhi.fraunhofer.de> wrote:
> I want the loopback during development of the NIC hardware. Once the NIC is
> done I drop the loopback and the card will be used for real networking.
> Thus, I want the loopback to a) test my driver, and b) test the hardware
> (for each milestone) as I'm implementing it.
Sorry, I still don't get why you need a loopback device for that.
--
Thanks,
//richard
^ permalink raw reply
* Re: Trying to implement secondary loopback
From: Thomas Martitz @ 2013-03-15 14:08 UTC (permalink / raw)
To: richard -rw- weinberger
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
In-Reply-To: <CAFLxGvwvH_krBDJ2i-si1LX2SKbeeRmXGR+0ZbtEB2oKWt-GoA@mail.gmail.com>
Am 15.03.2013 14:56, schrieb richard -rw- weinberger:
> On Fri, Mar 15, 2013 at 2:49 PM, Thomas Martitz
> <thomas.martitz@hhi.fraunhofer.de> wrote:
>> I want the loopback during development of the NIC hardware. Once the NIC is
>> done I drop the loopback and the card will be used for real networking.
>> Thus, I want the loopback to a) test my driver, and b) test the hardware
>> (for each milestone) as I'm implementing it.
>
> Sorry, I still don't get why you need a loopback device for that.
>
What's wrong with loopback? It's the simplest method to get basic
bidirectional data transfer going.
Can you suggest an alternative approach?
Best regards.
-----
visit us at
OFC 2013 / March 19-21 / Anaheim Convention Center, CA, USA / booth 11807
NABSHOW 2013 / April 8-11 / Las Vegas Convention Center, Nevada, USA / booth C7843
www.hhi.fraunhofer.de/events
^ permalink raw reply
* [net PATCH 1/1] drivers: net: ethernet: ti: davinci_emac: fix usage of cpdma_check_free_tx_desc()
From: Mugunthan V N @ 2013-03-15 14:10 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-omap, Mugunthan V N
Fix which was done in the following commit in cpsw driver has
to be taken forward to davinci emac driver as well.
commit d35162f89b8f00537d7b240b76d2d0e8b8d29aa0
Author: Daniel Mack <zonque@gmail.com>
Date: Tue Mar 12 06:31:19 2013 +0000
net: ethernet: cpsw: fix usage of cpdma_check_free_tx_desc()
Commit fae50823d0 ("net: ethernet: davinci_cpdma: Add boundary for rx
and tx descriptors") introduced a function to check the current
allocation state of tx packets. The return value is taken into account
to stop the netqork queue on the adapter in case there are no free
slots.
However, cpdma_check_free_tx_desc() returns 'true' if there is room in
the bitmap, not 'false', so the usage of the function is wrong.
Reported-by: Prabhakar Lad <prabhakar.csengg@gmail.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 52c0536..ae1b77a 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1102,7 +1102,7 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
/* If there is no more tx desc left free then we need to
* tell the kernel to stop sending us tx frames.
*/
- if (unlikely(cpdma_check_free_tx_desc(priv->txchan)))
+ if (unlikely(!cpdma_check_free_tx_desc(priv->txchan)))
netif_stop_queue(ndev);
return NETDEV_TX_OK;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] phy: Elimination the forced speed reduction algorithm.
From: Kirill Kapranov @ 2013-03-15 14:15 UTC (permalink / raw)
To: David Miller
Cc: netdev, bhutchings, peppe.cavallaro, joe, bruce.w.allan,
linux-kernel
In-Reply-To: <20130315.083524.1244515166306242265.davem@davemloft.net>
15/03/2013 08:35 -0400, David Miller wrote:
> From: Kirill Kapranov <kapranoff@inbox.ru>
> Date: Thu, 14 Mar 2013 14:40:52 +0400
>
> > @@ -867,7 +821,6 @@ void phy_state_machine(struct work_struct *work)
> > netif_carrier_on(phydev->attached_dev);
> > } else {
> > if (0 == phydev->link_timeout--) {
> > - phy_force_reduction(phydev);
> > needs_aneg = 1;
> > }
>
> This is not a single-statement basic block, and therefore you
> should remove the surrounding braces.
Thank You, the excess braces will be removed.
^ permalink raw reply
* Re: Trying to implement secondary loopback
From: richard -rw- weinberger @ 2013-03-15 14:16 UTC (permalink / raw)
To: Thomas Martitz
Cc: Eric W. Biederman, netdev@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, herbert@gondor.apana.org.au
In-Reply-To: <51432B72.20408@hhi.fraunhofer.de>
On Fri, Mar 15, 2013 at 3:08 PM, Thomas Martitz
<thomas.martitz@hhi.fraunhofer.de> wrote:
> What's wrong with loopback? It's the simplest method to get basic
> bidirectional data transfer going.
>
> Can you suggest an alternative approach?
The real question is, why do you need a second one?
I assume your driver (for the non-existing hardware) is a ethernet driver,
and now you're looking for a way to test your shiny new ethX device, correct?
--
Thanks,
//richard
^ permalink raw reply
* Re: DaVinci platform unable to boot via NFS
From: Sekhar Nori @ 2013-03-15 14:17 UTC (permalink / raw)
To: Prabhakar Lad; +Cc: mugunthanvnm, dlos, LAK, netdev, Daniel Mack, Mark Jackson
In-Reply-To: <CA+V-a8sNLBi1zB942ZbK26POrzcq7oOpNW9yPG5dG_gX7ZZ1oQ@mail.gmail.com>
Prabhakar,
On 3/15/2013 7:11 PM, Prabhakar Lad wrote:
> Hi Mugunthan,
>
> With 3.9 release I am not able to boot any davinci board via nfs, finally
> digging Into I found that there were recent changes for Ethernet davinci.
> Finally I reverting this to some safe commit I was able to boot via nfs.
> I reverted back as following:-
> git checkout f9a8f83b04e0c362a2fc660dbad980d24af209fc drivers/net/ethernet/ti/
>
> Can you please take a look at and fix it.
>
> Cheers,
> --Prabhakar Lad
> http://in.linkedin.com/pub/prabhakar-lad/19/92b/955
>
A similar bug was reported on cpsw and the following patch from Daniel
seems to have helped.
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d35162f89b8f00537d7b240b76d2d0e8b8d29aa0
I made a similar fix for davinci_emac.c and the resulting diff is below
(not tested or built).
Can you please check if this helps in DaVinci case?
Thanks,
Sekhar
----8<----
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 52c0536..ae1b77a 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1102,7 +1102,7 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
/* If there is no more tx desc left free then we need to
* tell the kernel to stop sending us tx frames.
*/
- if (unlikely(cpdma_check_free_tx_desc(priv->txchan)))
+ if (unlikely(!cpdma_check_free_tx_desc(priv->txchan)))
netif_stop_queue(ndev);
return NETDEV_TX_OK;
^ permalink raw reply related
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