* Re: error while building the kernel Mainline
From: David Miller @ 2010-11-18 21:15 UTC (permalink / raw)
To: randy.dunlap
Cc: kaber, justinmattock, eric.dumazet, linux-net, linux-kernel,
netdev, horms, netfilter-devel
In-Reply-To: <20101118.131004.58430322.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 18 Nov 2010 13:10:04 -0800 (PST)
> From: Randy Dunlap <randy.dunlap@oracle.com>
> Date: Thu, 18 Nov 2010 13:03:18 -0800
>
>> On Thu, 18 Nov 2010 12:54:51 -0800 (PST) David Miller wrote:
>>
>>> From: Patrick McHardy <kaber@trash.net>
>>> Date: Thu, 18 Nov 2010 21:32:11 +0100
>>>
>>> > Thanks for testing. Dave, please apply directly, thanks!
>>
>> Dave,
>>
>> This patch does not fix the config/build error that I posted for linux-next.
>
> And it has bugs, now when NF_CONNTRACT is set to "m" IPVS isn't offered
> at all.
>
> So I'm reverting.
Ignore this, I was looking for "*_IPVS" in the config instead of
"*_IP_VS" for some stupid reason.
Patch is sane and I'll look into Randy's problem when I get a chance.
:-)
^ permalink raw reply
* Re: error while building the kernel Mainline
From: David Miller @ 2010-11-18 21:10 UTC (permalink / raw)
To: randy.dunlap
Cc: kaber, justinmattock, eric.dumazet, linux-net, linux-kernel,
netdev, horms, netfilter-devel
In-Reply-To: <20101118130318.073f6beb.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Thu, 18 Nov 2010 13:03:18 -0800
> On Thu, 18 Nov 2010 12:54:51 -0800 (PST) David Miller wrote:
>
>> From: Patrick McHardy <kaber@trash.net>
>> Date: Thu, 18 Nov 2010 21:32:11 +0100
>>
>> > Thanks for testing. Dave, please apply directly, thanks!
>
> Dave,
>
> This patch does not fix the config/build error that I posted for linux-next.
And it has bugs, now when NF_CONNTRACT is set to "m" IPVS isn't offered
at all.
So I'm reverting.
^ permalink raw reply
* Re: [PATCH 2/2] phylib: Add support for Marvell 88E1149R devices.
From: David Daney @ 2010-11-18 21:06 UTC (permalink / raw)
To: Grant Likely, David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101118204410.GB16908-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
On 11/18/2010 12:44 PM, Grant Likely wrote:
> On Thu, Nov 18, 2010 at 11:46:16AM -0800, David Miller wrote:
>> From: David Daney<ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>> Date: Wed, 17 Nov 2010 15:54:31 -0800
>>
>>> The 88E1149R is 10/100/1000 quad-gigabit Ethernet PHY. The
>>> .config_aneg function can be shared with 88E1118, but it needs its own
>>> .config_init.
>>>
>>> Signed-off-by: David Daney<ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>>
>> Please resend this when you've respun patch #1 based upon the feedback
>> you've been given.
>
> It looks to me that this patch has no dependencies on the first patch.
> ddaney; what say you?
>
It calls the marvell_of_reg_init() function introduced in the first
patch. Reordering the patches would be possible, but since nobody else
has cared enough to add 88E1149R support, it shouldn't affect anyone be
me.
I arbitrarily ordered it this way. If davem wishes, I could re-order
the patches and 88E1149R could be merged before the device tree part.
David Daney
^ permalink raw reply
* Re: error while building the kernel Mainline
From: Randy Dunlap @ 2010-11-18 21:03 UTC (permalink / raw)
To: David Miller
Cc: kaber, justinmattock, eric.dumazet, linux-net, linux-kernel,
netdev, horms, netfilter-devel
In-Reply-To: <20101118.125451.98885354.davem@davemloft.net>
On Thu, 18 Nov 2010 12:54:51 -0800 (PST) David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Thu, 18 Nov 2010 21:32:11 +0100
>
> > Thanks for testing. Dave, please apply directly, thanks!
Dave,
This patch does not fix the config/build error that I posted for linux-next.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 2/2] phylib: Add support for Marvell 88E1149R devices.
From: David Miller @ 2010-11-18 20:57 UTC (permalink / raw)
To: grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101118204410.GB16908-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Date: Thu, 18 Nov 2010 13:44:10 -0700
> On Thu, Nov 18, 2010 at 11:46:16AM -0800, David Miller wrote:
>> From: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>> Date: Wed, 17 Nov 2010 15:54:31 -0800
>>
>> > The 88E1149R is 10/100/1000 quad-gigabit Ethernet PHY. The
>> > .config_aneg function can be shared with 88E1118, but it needs its own
>> > .config_init.
>> >
>> > Signed-off-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>>
>> Please resend this when you've respun patch #1 based upon the feedback
>> you've been given.
>
> It looks to me that this patch has no dependencies on the first patch.
> ddaney; what say you?
It absolutely does, it references a function create by patch #1
In fact it's the whole _entire_ point of patch #1, to allow
patch #2 to be possible. Did you even check?
Otherwise I would waste his time asking for a respin.
^ permalink raw reply
* Re: error while building the kernel Mainline
From: David Miller @ 2010-11-18 20:54 UTC (permalink / raw)
To: kaber
Cc: justinmattock, eric.dumazet, linux-net, linux-kernel, netdev,
horms, netfilter-devel
In-Reply-To: <4CE58D4B.6070105@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 18 Nov 2010 21:32:11 +0100
> Thanks for testing. Dave, please apply directly, thanks!
Done.
^ permalink raw reply
* Re: [PATCH 2/2] phylib: Add support for Marvell 88E1149R devices.
From: Grant Likely @ 2010-11-18 20:44 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101118.114616.258106719.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Nov 18, 2010 at 11:46:16AM -0800, David Miller wrote:
> From: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Date: Wed, 17 Nov 2010 15:54:31 -0800
>
> > The 88E1149R is 10/100/1000 quad-gigabit Ethernet PHY. The
> > .config_aneg function can be shared with 88E1118, but it needs its own
> > .config_init.
> >
> > Signed-off-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
>
> Please resend this when you've respun patch #1 based upon the feedback
> you've been given.
It looks to me that this patch has no dependencies on the first patch.
ddaney; what say you?
g.
^ permalink raw reply
* Re: [PATCH 1/2] of/phylib: Use device tree properties to initialize Marvell PHYs.
From: Grant Likely @ 2010-11-18 20:40 UTC (permalink / raw)
To: David Daney
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Cyril Chemparathy,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnaud Patard
In-Reply-To: <1290038071-13296-2-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Wed, Nov 17, 2010 at 03:54:30PM -0800, David Daney wrote:
> Some aspects of PHY initialization are board dependent, things like
> indicator LED connections and some clocking modes cannot be determined
> by probing. The dev_flags element of struct phy_device can be used to
> control these things if an appropriate value can be passed from the
> Ethernet driver. We run into problems however if the PHY connections
> are specified by the device tree. There is no way for the Ethernet
> driver to know what flags it should pass.
>
> If we are using the device tree, the struct phy_device will be
> populated with the device tree node corresponding to the PHY, and we
> can extract extra configuration information from there.
>
> The next question is what should the format of that information be?
> It is highly device specific, and the device tree representation
> should not be tied to any arbitrary kernel defined constants. A
> straight forward representation is just to specify the exact bits that
> should be set using the "marvell,reg-init" property:
>
> phy5: ethernet-phy@5 {
> reg = <5>;
> device_type = "ethernet-phy";
Some notes:
- device_type is only relevant for real openfirmware platforms. It
should not appear in dts files.
- This example phy node needs a compatible property
- This new binding needs to be documented. You can use devicetree.org.
> marvell,reg-init =
> <0x00030010 0x5777>, /* Reg 3,16 <- 0x5777 */
> <0x00030011 0x00aa>, /* Reg 3,17 <- 0x00aa */
> <0x00030012 0x4105>, /* Reg 3,18 <- 0x4105 */
> <0x00030013 0x0060>; /* Reg 3,19 <- 0x0060 */
> <0x00020015 0x00300000>; /* clear bits 4..5 of Reg 2,21 */
> };
>
> The Marvell PHYs have a page select register at register 22 (0x16), we
> can specify any register by its page and register number. These are
> encoded in the high and low parts of the first word. The second word
> contains a mask and value to be ORed in its high and low parts. The
> new marvell_of_reg_init function leaves the page select register
> unchanged, so a call to it can be dropped into the .config_init
> functions without unduly affecting the state of the PHY.
Don't bother trying to pack the values tightly. Just use one cell per
value. ie: marvell,reg-init = < [page] [register] [mask] [value] >;
>
> If CONFIG_OF is not set, there is no of_node, or no "marvell,reg-init"
> property, the PHY initialization is unchanged.
>
> Signed-off-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: Cyril Chemparathy <cyril-l0cyMroinI0@public.gmane.org>
> Cc: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Cc: Arnaud Patard <arnaud.patard-dQbF7i+pzddAfugRpC6u6w@public.gmane.org>
> Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> drivers/net/phy/marvell.c | 91 +++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 91 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index f0bd1a1..33ad654 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -30,6 +30,7 @@
> #include <linux/ethtool.h>
> #include <linux/phy.h>
> #include <linux/marvell_phy.h>
> +#include <linux/of.h>
>
> #include <asm/io.h>
> #include <asm/irq.h>
> @@ -186,6 +187,85 @@ static int marvell_config_aneg(struct phy_device *phydev)
> return 0;
> }
>
> +#ifndef CONFIG_OF
ifndef CONFIG_OF_MDIO
Nit: I usually see these blocks constructed the other way around. Put
the true case first, and then follow it up with the empty false case.
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +#else
> +/*
> + * Set and/or override some configuration registers based on the
> + * marvell,reg-init property stored in the of_node for the phydev.
> + *
> + * marvell,reg-init = <reg-spec val-spec>,...;
> + *
> + * There may be one or more pairs of <reg-spec val-spec>:
> + * reg-spec [16..31]: Page address.
> + * reg-spec [0..15]: Register address.
> + *
> + * val-spec [16..31]: Mask bits.
> + * val-spec [0..15]: Register bits.
> + */
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + const __be32 *paddr;
> + int len, i, saved_page, current_page, page_changed, ret;
> +
> + if (!phydev->dev.of_node)
> + return 0;
> +
> + paddr = of_get_property(phydev->dev.of_node, "marvell,reg-init", &len);
> + if (!paddr || len < (2 * sizeof(u32)))
> + return 0;
> +
> + saved_page = phy_read(phydev, 22);
> + if (saved_page < 0)
> + return saved_page;
> + page_changed = 0;
> + current_page = saved_page;
> +
> + ret = 0;
> + len /= sizeof(u32);
> + for (i = 0; i < len / 2; i += 2) {
> + u32 reg_spec = be32_to_cpup(&paddr[i]);
> + u32 val_spec = be32_to_cpup(&paddr[i + 1]);
> + u16 reg = reg_spec & 0xffff;
> + u16 reg_page = reg_spec >> 16;
> + u16 val_bits = val_spec & 0xffff;
> + u16 mask = val_spec >> 16;
> + int val;
> +
> + if (reg_page != current_page) {
> + ret = phy_write(phydev, 22, reg_page);
> + if (ret < 0)
> + goto err;
> + current_page = reg_page;
> + page_changed = 1;
> + }
> +
> + val = 0;
> + if (mask) {
> + val = phy_read(phydev, reg);
> + if (val < 0) {
> + ret = val;
> + goto err;
> + }
> + val &= mask;
> + }
> + val |= val_bits;
> +
> + ret = phy_write(phydev, reg, (u16)val);
> + if (ret < 0)
> + goto err;
> +
> + }
> +err:
> + if (page_changed)
> + ret = phy_write(phydev, 22, saved_page);
This throws away the previous error code if a single write fails. It
may return a false success.
> + return ret;
> +}
> +#endif /* CONFIG_OF */
> +
> static int m88e1121_config_aneg(struct phy_device *phydev)
> {
> int err, oldpage, mscr;
> @@ -368,6 +448,9 @@ static int m88e1111_config_init(struct phy_device *phydev)
> return err;
> }
>
> + err = marvell_of_reg_init(phydev);
> + if (err < 0)
> + return err;
>
> err = phy_write(phydev, MII_BMCR, BMCR_RESET);
> if (err < 0)
> @@ -420,6 +503,10 @@ static int m88e1118_config_init(struct phy_device *phydev)
> if (err < 0)
> return err;
>
> + err = marvell_of_reg_init(phydev);
> + if (err < 0)
> + return err;
> +
> /* Reset address */
> err = phy_write(phydev, 0x16, 0x0);
> if (err < 0)
> @@ -491,6 +578,10 @@ static int m88e1145_config_init(struct phy_device *phydev)
> }
> }
>
> + err = marvell_of_reg_init(phydev);
> + if (err < 0)
> + return err;
> +
> return 0;
> }
>
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: error while building the kernel Mainline
From: Patrick McHardy @ 2010-11-18 20:32 UTC (permalink / raw)
To: Justin P. Mattock
Cc: David Miller, eric.dumazet, linux-net, linux-kernel, netdev,
horms, netfilter-devel
In-Reply-To: <4CE57C06.4080105@gmail.com>
Am 18.11.2010 20:18, schrieb Justin P. Mattock:
> On 11/18/2010 10:20 AM, Patrick McHardy wrote:
>> Am 18.11.2010 19:13, schrieb Justin P. Mattock:
>>> On 11/18/2010 09:50 AM, David Miller wrote:
>>>> From: Eric Dumazet<eric.dumazet@gmail.com>
>>>> Date: Thu, 18 Nov 2010 18:48:17 +0100
>>>>
>>>>> Let me guess...
>>>>>
>>>>> net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
>>>>> statically (in vmlinux) ?
>>>>>
>>>>> CONFIG_NF_CONNTRACK=m
>>>>> CONFIG_IP_VS=y
>>>>>
>>>>> We probably need some Kconfig magic ;)
>>>>
>>
>> Please try whether this patch fixes the problem.
>>
>> netfilter: fix IP_VS dependencies
>>
>> When NF_CONNTRACK is enabled, IP_VS uses conntrack symbols.
>> Therefore IP_VS can't be linked statically when conntrack
>> is built modular.
>>
>> Reported-by: Justin P. Mattock<justinmattock@gmail.com>
>> Signed-off-by: Patrick McHardy<kaber@trash.net>
>>
>>
>
>
> alright!! doing the above change
> CONFIG_NF_CONNTRACK=y gets a clean build.. as well as reverting
> everything and using your patch..
>
> Thanks for the fix..
Thanks for testing. Dave, please apply directly, thanks!
^ permalink raw reply
* Re: [PATCH] net: irda: irttp: sync error paths of data- and udata-requests
From: David Miller @ 2010-11-18 20:24 UTC (permalink / raw)
To: w.sang; +Cc: netdev, sameo
In-Reply-To: <1289936402-25277-1-git-send-email-w.sang@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Tue, 16 Nov 2010 20:40:02 +0100
> irttp_data_request() returns meaningful errorcodes, while irttp_udata_request()
> just returns -1 in similar situations. Sync the two and the loglevels of the
> accompanying output.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: David Miller <davem@davemloft.net>
> ---
>
> Thank you David for picking up the zero-byte-packet-patch. Now as it was
> applied, this one might be interesting, too (on top of it)? Nothing seriously
> needed, but looks more proper IMHO. LXR says that are callers of these
> functions check with < 0 anyhow.
Better error code reporting is always appreciated :-)
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] can: EG20T PCH: use BIT(X)
From: David Miller @ 2010-11-18 20:09 UTC (permalink / raw)
To: tomoya-linux
Cc: wg, w.sang, chripell, 21cnbao, sameo, socketcan-core, netdev,
linux-kernel, qi.wang, yong.y.wang, andrew.chih.howe.khor,
joel.clark, kok.howg.ewe, margie.foster
In-Reply-To: <4CE46E01.9030505@dsn.okisemi.com>
From: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Date: Thu, 18 Nov 2010 09:06:25 +0900
> Replace bit assignment value to BIT(X).
> For easy to readable/identifiable, replace all bit assigned macros to BIT(X)
>
> Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: EG20T PCH: add prefix to macro
From: David Miller @ 2010-11-18 20:05 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CE3B8CC.5060208-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Wed, 17 Nov 2010 20:13:16 +0900
> For easy to readable/identifiable, add prefix "PCH_" to all of #define macros.
>
> Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-11-18
From: David Miller @ 2010-11-18 20:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20101118184116.GD2468@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 18 Nov 2010 13:41:16 -0500
> Included is an build fix for b43legacy on ARM, a correction of a
> misnumbered WIPHY_FLAG_* value, a fix for the units passed to
> usb_wait_anchor_empty_timeout in carl9170, a relocation of ath9k's
> pm_qos request to avoid a warning about an unknown object, some device
> ID stuff for ath9k_htc, a corrected eeprom offset for AR9287 devices, a
> regulatory fix for extension channels, a fix on top of the regulatory
> fix that restores HT40 functionality, and an ath9k_htc fix for non-QoS
> frame handling that avoids "severe data loss with some APs".
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* alchemy/gpr: au1000_eth regression with v2.6.37rc2
From: Wolfgang Grandegger @ 2010-11-18 19:59 UTC (permalink / raw)
To: Linux-MIPS; +Cc: Netdev, Florian Fainelli
Hello,
I just realized that the v2.6.37-rc2 kernel does not boot any more on
the Alchemy GPR board. It works fine with v2.6.36. It hangs in the
probe function of the au1000_eth driver when probing the second
ethernet port (eth1):
au1000_eth_mii: probed
au1000-eth au1000-eth.0: (unregistered net_device): attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
au1000-eth au1000-eth.0: eth0: Au1xx0 Ethernet found at 0x10500000, irq 35
au1000_eth: au1000_eth version 1.7 Pete Popov <ppopov@embeddedalley.com>
... hangs ...
Similar messages should follow for eth1. I narrowed down (bisect'ed) the
problem to commit:
commit d0e7cb5d401695809ba8c980124ab1d8c66efc8b
Author: Florian Fainelli <florian@openwrt.org>
Date: Wed Sep 8 11:15:13 2010 +0000
au1000-eth: remove volatiles, switch to I/O accessors
Remove all the volatile keywords where they were used, switch to using the
proper readl/writel accessors.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The kernel actually hangs when accessing "&aup->mac->mii_control" in
au1000_mdio_read(), but only for eth1. Any idea what does go wrong?
In principle, I do not want to access the MII regs of the MAC because
eth0 and eth1 are connected to switches. But that's not possible, even
with "aup->phy_static_config=1" and "aup->phy_addr=0".
TIA,
Wolfgang.
^ permalink raw reply
* [PATCH] atm: fore200e: Fix build warning.
From: David Miller @ 2010-11-18 19:53 UTC (permalink / raw)
To: netdev
GCC (rightfully) complains that:
drivers/atm/fore200e.c:614:5: warning: operation on 'cmdq->head' may be undefined
This is due to the FORE200E_NEXT_ENTRY macro, which essentially
evaluates to:
i = ++i % m
Make it what's explicitly intended here which is:
i = (i + 1) % m
and the warning goes away.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/atm/fore200e.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index c8fc69c..c097619 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -92,7 +92,7 @@
#define FORE200E_INDEX(virt_addr, type, index) (&((type *)(virt_addr))[ index ])
-#define FORE200E_NEXT_ENTRY(index, modulo) (index = ++(index) % (modulo))
+#define FORE200E_NEXT_ENTRY(index, modulo) (index = ((index) + 1) % (modulo))
#if 1
#define ASSERT(expr) if (!(expr)) { \
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH 2/2] phylib: Add support for Marvell 88E1149R devices.
From: David Miller @ 2010-11-18 19:46 UTC (permalink / raw)
To: ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1290038071-13296-3-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
From: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Date: Wed, 17 Nov 2010 15:54:31 -0800
> The 88E1149R is 10/100/1000 quad-gigabit Ethernet PHY. The
> .config_aneg function can be shared with 88E1118, but it needs its own
> .config_init.
>
> Signed-off-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Please resend this when you've respun patch #1 based upon the feedback
you've been given.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] of/phylib: Use device tree properties to initialize Marvell PHYs.
From: Cyril Chemparathy @ 2010-11-18 19:32 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss@lists.ozlabs.org, grant.likely@secretlab.ca,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Arnaud Patard, Benjamin Herrenschmidt
In-Reply-To: <1290038071-13296-2-git-send-email-ddaney@caviumnetworks.com>
On 11/17/2010 06:54 PM, David Daney wrote:
> Some aspects of PHY initialization are board dependent, things like
> indicator LED connections and some clocking modes cannot be determined
> by probing. The dev_flags element of struct phy_device can be used to
> control these things if an appropriate value can be passed from the
> Ethernet driver. We run into problems however if the PHY connections
> are specified by the device tree. There is no way for the Ethernet
> driver to know what flags it should pass.
>
> If we are using the device tree, the struct phy_device will be
> populated with the device tree node corresponding to the PHY, and we
> can extract extra configuration information from there.
>
> The next question is what should the format of that information be?
> It is highly device specific, and the device tree representation
> should not be tied to any arbitrary kernel defined constants. A
> straight forward representation is just to specify the exact bits that
> should be set using the "marvell,reg-init" property:
>
> phy5: ethernet-phy@5 {
> reg = <5>;
> device_type = "ethernet-phy";
> marvell,reg-init =
> <0x00030010 0x5777>, /* Reg 3,16 <- 0x5777 */
> <0x00030011 0x00aa>, /* Reg 3,17 <- 0x00aa */
> <0x00030012 0x4105>, /* Reg 3,18 <- 0x4105 */
> <0x00030013 0x0060>; /* Reg 3,19 <- 0x0060 */
> <0x00020015 0x00300000>; /* clear bits 4..5 of Reg 2,21 */
> };
>
> The Marvell PHYs have a page select register at register 22 (0x16), we
> can specify any register by its page and register number. These are
> encoded in the high and low parts of the first word. The second word
> contains a mask and value to be ORed in its high and low parts. The
> new marvell_of_reg_init function leaves the page select register
> unchanged, so a call to it can be dropped into the .config_init
> functions without unduly affecting the state of the PHY.
>
> If CONFIG_OF is not set, there is no of_node, or no "marvell,reg-init"
> property, the PHY initialization is unchanged.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Cyril Chemparathy <cyril@ti.com>
> Cc: David Daney <ddaney@caviumnetworks.com>
> Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/net/phy/marvell.c | 91 +++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 91 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index f0bd1a1..33ad654 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -30,6 +30,7 @@
> #include <linux/ethtool.h>
> #include <linux/phy.h>
> #include <linux/marvell_phy.h>
> +#include <linux/of.h>
>
> #include <asm/io.h>
> #include <asm/irq.h>
> @@ -186,6 +187,85 @@ static int marvell_config_aneg(struct phy_device *phydev)
> return 0;
> }
>
> +#ifndef CONFIG_OF
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +#else
> +/*
> + * Set and/or override some configuration registers based on the
> + * marvell,reg-init property stored in the of_node for the phydev.
> + *
> + * marvell,reg-init = <reg-spec val-spec>,...;
> + *
> + * There may be one or more pairs of <reg-spec val-spec>:
> + * reg-spec [16..31]: Page address.
> + * reg-spec [0..15]: Register address.
> + *
> + * val-spec [16..31]: Mask bits.
> + * val-spec [0..15]: Register bits.
> + */
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + const __be32 *paddr;
> + int len, i, saved_page, current_page, page_changed, ret;
> +
> + if (!phydev->dev.of_node)
> + return 0;
> +
> + paddr = of_get_property(phydev->dev.of_node, "marvell,reg-init", &len);
> + if (!paddr || len < (2 * sizeof(u32)))
> + return 0;
> +
> + saved_page = phy_read(phydev, 22);
Please use MII_88E1121_PHY_PAGE (renamed if necessary) instead of 22 here.
> + if (saved_page < 0)
> + return saved_page;
> + page_changed = 0;
> + current_page = saved_page;
> +
> + ret = 0;
> + len /= sizeof(u32);
> + for (i = 0; i < len / 2; i += 2) {
> + u32 reg_spec = be32_to_cpup(&paddr[i]);
> + u32 val_spec = be32_to_cpup(&paddr[i + 1]);
> + u16 reg = reg_spec & 0xffff;
> + u16 reg_page = reg_spec >> 16;
> + u16 val_bits = val_spec & 0xffff;
> + u16 mask = val_spec >> 16;
> + int val;
> +
> + if (reg_page != current_page) {
> + ret = phy_write(phydev, 22, reg_page);
> + if (ret < 0)
> + goto err;
> + current_page = reg_page;
> + page_changed = 1;
> + }
> +
> + val = 0;
> + if (mask) {
> + val = phy_read(phydev, reg);
If this phy_read() were to fail...
> + if (val < 0) {
> + ret = val;
> + goto err;
> + }
> + val &= mask;
> + }
> + val |= val_bits;
> +
> + ret = phy_write(phydev, reg, (u16)val);
> + if (ret < 0)
> + goto err;
> +
> + }
> +err:
> + if (page_changed)
> + ret = phy_write(phydev, 22, saved_page);
> + return ret;
... this function may incorrectly return success if the phy_write()
succeeds.
Some mdio controllers verify turn around during read operations and
return failure if the phy fails to drive the data line low. On write
transactions turn around is driven by the controller, and failures may
go undetected.
[...]
Regards
- Cyril.
^ permalink raw reply
* Re: [PATCH] qlge: Fix incorrect usage of module parameters and netdev msg level
From: David Miller @ 2010-11-18 19:30 UTC (permalink / raw)
To: sonnyrao; +Cc: netdev, miltonm, ron.mercer, linux-driver, linux-kernel
In-Reply-To: <1290075903-3038-1-git-send-email-sonnyrao@linux.vnet.ibm.com>
Sonny, something is serious wrong with your email setup.
The number of Received headers in your outgoing emails is
enormous and as a result a large percentage of the lists
subscribers bounced your posting because it looks like it
is looping.
^ permalink raw reply
* RE: ixgbe dump
From: Skidmore, Donald C @ 2010-11-18 19:30 UTC (permalink / raw)
To: Yinghai Lu, Brandeburg, Jesse, David Miller; +Cc: NetDev, Kirsher, Jeffrey T
In-Reply-To: <4CE47FA6.8050600@kernel.org>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Yinghai Lu
>Sent: Wednesday, November 17, 2010 5:22 PM
>To: Brandeburg, Jesse; David Miller
>Cc: NetDev
>Subject: ixgbe dump
>
>[ 1546.287521] md: stopping all md devices.
>[ 1547.283729] kvm: exiting hardware virtualization
>[ 1547.292876] sd 2:2:1:0: [sdb] Synchronizing SCSI cache
>[ 1547.293831] sd 2:2:0:0: [sda] Synchronizing SCSI cache
>[ 1547.299627] BUG: unable to handle kernel NULL pointer dereference at
>0000000000000033
>[ 1547.315819] IP: [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
>[ 1547.316448] PGD 3ff4487067 PUD 3ff216b067 PMD 0
>[ 1547.335626] Oops: 0000 [#1] SMP
>[ 1547.335941] last sysfs file: /sys/kernel/kexec_loaded
>[ 1547.336381] CPU 0
>[ 1547.336548] Modules linked in:
>[ 1547.355798]
>[ 1547.355968] Pid: 25630, comm: kexec Not tainted 2.6.37-rc2-tip-yh-01961-
>g6034289-dirty #281 /Sun Fire X4800
>[ 1547.375849] RIP: 0010:[<ffffffff81746273>] [<ffffffff81746273>]
>ixgbe_set_rx_mode+0x265/0x38e
>[ 1547.395543] RSP: 0018:ffff881fb9d49ce8 EFLAGS: 00010287
>[ 1547.396080] RAX: 0000000000000000 RBX: ffff88dffe5a0940 RCX:
>ffff88dffe5a0940
>[ 1547.415635] RDX: 0000000000000000 RSI: 0000000000000001 RDI:
>ffffc90077780000
>[ 1547.416299] RBP: ffff881fb9d49d48 R08: 0000000000000000 R09:
>0000000000000000
>[ 1547.435860] R10: 000000000000a608 R11: 0000000000000000 R12:
>0000000000000000
>[ 1547.455516] R13: ffff88dffe5a0000 R14: 0000000000003400 R15:
>ffff881fb9d49db7
>[ 1547.456257] FS: 00000000006e0850(0063) GS:ffff88207d600000(0000)
>knlGS:0000000000000000
>[ 1547.475937] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>[ 1547.495330] CR2: 0000000000000033 CR3: 0000003ffa77e000 CR4:
>00000000000006f0
>[ 1547.496009] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>0000000000000000
>[ 1547.515594] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>0000000000000400
>[ 1547.516229] Process kexec (pid: 25630, threadinfo ffff881fb9d48000, task
>ffff881f8a57a2d0)
>[ 1547.536039] Stack:
>[ 1547.536244] 0000000000000040 0000002b00000000 ffff881ffedc1000
>0000000000000006
>[ 1547.555894] ffff88dffe5a1b40 0b00000081454ec8 ffff881fb9d49d48
>ffff88dffe5a0940
>[ 1547.575411] ffff881ffedc1000 000000000000001e 0000000000000000
>ffff881fb9d49db7
>[ 1547.576131] Call Trace:
>[ 1547.595251] [<ffffffff8174a8f4>] __ixgbe_shutdown+0x9d/0x153
>[ 1547.595770] [<ffffffff8174a9c4>] ixgbe_shutdown+0x1a/0x43
>[ 1547.615250] [<ffffffff814574bb>] pci_device_shutdown+0x2c/0x40
>[ 1547.615887] [<ffffffff8151c5e9>] device_shutdown+0x75/0xb0
>[ 1547.635268] [<ffffffff8108f461>] kernel_restart_prepare+0x2c/0x33
>[ 1547.635927] [<ffffffff810bc821>] kernel_kexec+0x38/0x6b
>[ 1547.655252] [<ffffffff8108f618>] sys_reboot+0x156/0x194
>[ 1547.655765] [<ffffffff8114422a>] ? __d_free+0x59/0x5e
>[ 1547.675145] [<ffffffff81144283>] ? d_free+0x54/0x66
>[ 1547.675612] [<ffffffff8114439d>] ? d_kill+0x3b/0x43
>[ 1547.695025] [<ffffffff81144a1c>] ? dput+0x40/0x140
>[ 1547.695539] [<ffffffff811351a9>] ? fput+0x1d7/0x1e6
>[ 1547.696045] [<ffffffff81036c0c>] ? sysret_check+0x27/0x62
>[ 1547.715426] [<ffffffff81cd9772>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>[ 1547.734897] [<ffffffff81036bdb>] system_call_fastpath+0x16/0x1b
>[ 1547.735428] Code: d2 e9 81 00 00 00 48 8b 83 00 12 00 00 8b 80 88 50 00
>00 0d 00 00 00 80 e9 a7 00 00 00 48 8b 81 00 0a 00 00 48 8b bb 00 12 00 00
><0f> b6 40 33 83 f8 3f 7f 0d 89 c6 c1 e6 06 81 c6 28 10 00 00 eb
>[ 1547.775262] RIP [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
>[ 1547.775909] RSP <ffff881fb9d49ce8>
>[ 1547.794997] CR2: 0000000000000033
>[ 1547.795987] ---[ end trace 4ed9616adc45007c ]---
>--
>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
Thanks for the dump.
I believe I've found the problem and will get a patch to Jeff shortly.
Thanks again,
-Don Skidmore <donald.c.skidmore@intel.com>
^ permalink raw reply
* [PATCH] qlge: Fix incorrect usage of module parameters and netdev msg level
From: Sonny Rao @ 2010-11-18 10:25 UTC (permalink / raw)
To: netdev; +Cc: Sonny Rao, Milton Miller, Ron Mercer, linux-driver, linux-kernel
Driver appears to be mistaking the permission field with default value
in the case of debug and qlge_irq_type.
Driver is also passing debug as a bitmask into netif_msg_init()
which really wants a number of bits, so fix that.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
---
drivers/net/qlge/qlge_main.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index d9a7626..66878bb 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -62,15 +62,15 @@ static const u32 default_msg =
/* NETIF_MSG_PKTDATA | */
NETIF_MSG_HW | NETIF_MSG_WOL | 0;
-static int debug = 0x00007fff; /* defaults above */
-module_param(debug, int, 0);
+static int debug = 15; /* defaults above */
+module_param(debug, int, 0664);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
#define MSIX_IRQ 0
#define MSI_IRQ 1
#define LEG_IRQ 2
static int qlge_irq_type = MSIX_IRQ;
-module_param(qlge_irq_type, int, MSIX_IRQ);
+module_param(qlge_irq_type, int, 0664);
MODULE_PARM_DESC(qlge_irq_type, "0 = MSI-X, 1 = MSI, 2 = Legacy.");
static int qlge_mpi_coredump;
--
1.5.6.5
^ permalink raw reply related
* Re: error while building the kernel Mainline
From: Justin P. Mattock @ 2010-11-18 19:18 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Miller, eric.dumazet, linux-net, linux-kernel, netdev,
horms, netfilter-devel
In-Reply-To: <4CE56E89.4000902@trash.net>
On 11/18/2010 10:20 AM, Patrick McHardy wrote:
> Am 18.11.2010 19:13, schrieb Justin P. Mattock:
>> On 11/18/2010 09:50 AM, David Miller wrote:
>>> From: Eric Dumazet<eric.dumazet@gmail.com>
>>> Date: Thu, 18 Nov 2010 18:48:17 +0100
>>>
>>>> Let me guess...
>>>>
>>>> net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
>>>> statically (in vmlinux) ?
>>>>
>>>> CONFIG_NF_CONNTRACK=m
>>>> CONFIG_IP_VS=y
>>>>
>>>> We probably need some Kconfig magic ;)
>>>
>
> Please try whether this patch fixes the problem.
>
> netfilter: fix IP_VS dependencies
>
> When NF_CONNTRACK is enabled, IP_VS uses conntrack symbols.
> Therefore IP_VS can't be linked statically when conntrack
> is built modular.
>
> Reported-by: Justin P. Mattock<justinmattock@gmail.com>
> Signed-off-by: Patrick McHardy<kaber@trash.net>
>
>
alright!! doing the above change
CONFIG_NF_CONNTRACK=y gets a clean build.. as well as reverting
everything and using your patch..
Thanks for the fix..
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH net-2.6] ipv6: Expose IFLA_PROTINFO timer values in msecs instead of jiffies
From: David Miller @ 2010-11-18 19:05 UTC (permalink / raw)
To: tgraf; +Cc: netdev, yoshfuji
In-Reply-To: <20101117114424.GA5838@canuck.infradead.org>
From: Thomas Graf <tgraf@infradead.org>
Date: Wed, 17 Nov 2010 06:44:24 -0500
> IFLA_PROTINFO exposes timer related per device settings in jiffies.
> Change it to expose these values in msecs like the sysctl interface
> does.
>
> I did not find any users of IFLA_PROTINFO which rely on any of these
> values and even if there are, they are likely already broken because
> there is no way for them to reliably convert such a value to another
> time format.
>
> Signed-off-by: Thomas Graf <tgraf@infradead.org>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
Good to fix this now, thanks a lot Thomas.
^ permalink raw reply
* Re: [PATCH net-next-2.6] igmp: refine skb allocations
From: David Miller @ 2010-11-18 19:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1289975802.2732.195.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 17 Nov 2010 07:36:42 +0100
> IGMP allocates MTU sized skbs. This may fail for large MTU (order-2
> allocations), so add a fallback to try lower sizes.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, although in the long run we need to be a lot more
intelligent here. However, this is a good start. :-)
^ permalink raw reply
* Re: extended netdevice naming proposal
From: Ben Hutchings @ 2010-11-18 19:00 UTC (permalink / raw)
To: Matt Domsch; +Cc: Bill Nottingham, linux-hotplug, netdev, narendra_k, jcm
In-Reply-To: <20101118185125.GA4952@auslistsprd01.us.dell.com>
On Thu, 2010-11-18 at 12:51 -0600, Matt Domsch wrote:
> On Thu, Nov 18, 2010 at 02:29:57AM +0000, Ben Hutchings wrote:
> > On Wed, 2010-11-17 at 21:10 -0500, Bill Nottingham wrote:
> > > Matt Domsch (Matt_Domsch@dell.com) said:
> > > > (location)(slot)#(port)/(instance).(vlan)
> > >
> > > AIUI, the kernel explicitly rejects '/' in the name (for fairly obvious
> > > sysfs reasons.) So you'd at least need a different delimiter. There may
> > > also be potential confusion with pci01#03:02.0001 with someone thinking
> > > that's bus/dev/fn, if we're being really petty.
> >
> > ':' is also reserved for alias interfaces, the old way of assigning
> > multiple IP addresses.
> >
> > I would say '-' is a good separator, but that might result in ambiguity
> > in IRQ names.
>
> How about underscore to separate VFs?
> (location)(slot)#(port)_(instance).(vlan)
That does seem like the best separator available.
> And 'em' as prefix for embedded?
[...]
That also fits the mnemonic Ethernet on Motherboard, which is nice.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [PATCH] net: move definitions of BPF_S_* to net/core/filter.c
From: David Miller @ 2010-11-18 19:00 UTC (permalink / raw)
To: hagen; +Cc: xiaosuo, penguin-kernel, eric.dumazet, netdev
In-Reply-To: <3003681dc01b47ffde9f75b4d0422268@localhost>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Wed, 17 Nov 2010 10:10:59 +0100
>
> On Wed, 17 Nov 2010 14:28:24 +0800, Changli Gao <xiaosuo@gmail.com> wrote:
>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Acked-by: Hagen Paul Pfeifer <hagen@jauu.net>
Applied, thanks everyone.
^ 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