* [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
* 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
* 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
* 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: [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: 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: 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 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: [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: 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: 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: 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 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: 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: 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: Patrick McHardy @ 2010-11-18 21:48 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, justinmattock, eric.dumazet, linux-net,
linux-kernel, netdev, horms, netfilter-devel
In-Reply-To: <20101118.131527.45904827.davem@davemloft.net>
Am 18.11.2010 22:15, schrieb David Miller:
> 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.
I always make the same mistake :)
> Patch is sane and I'll look into Randy's problem when I get a chance.
> :-)
I've already asked the tproxy guys to look into this, it's a
different problem that requires more tproxy knowledge than
have.
^ permalink raw reply
* [PATCH] qlge: Fix incorrect usage of module parameters and netdev msg level
From: Sonny Rao @ 2010-11-18 21:50 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Milton Miller, Linux Driver, linux-kernel@vger.kernel.org,
Ron Mercer, sonnyrao
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 wants a number of bits. Ron Mercer suggests we should
change this to pass in -1 so the defaults get used instead,
which makes the default much less verbose.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
---
v2: Changed debug to be -1 and updated changelog
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 = -1; /* 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;
^ permalink raw reply related
* Re: Fwd: a Great Idea - include Kademlia networking protocol in kernel -- REVISITED
From: Marcos @ 2010-11-18 22:21 UTC (permalink / raw)
To: Honglei Cong, netdev
In-Reply-To: <AANLkTi=RQjvwpTwZtkjcyjgMVsZbYfi=34wSd-_JE3pP@mail.gmail.com>
>> Yes, of course, all that will have to be considered. But I'm
>> suggesting that such a move is an investment in the future, that the
>> the number of machines that will want or request peer-2-peer
>> connectivity will (or should) only increase. Done right, such a move
>> should *simplify* things. We're biased to think in centralized ways
>> because of the centuries-old history of *who* has the resources. But
>> as networking, computation, and storage become commodified further,
>> whole new topologies for the *right* architecture become available.
>> The idea of "the OS" itself morphs. And the *only* way maximize the
> Agree with u. But 'kernel' is not.
...Consider a unified model of two orthogonal resources: processor --
memory. In theory such a unified model should be realizable. For
example, if we fix the processor side (say the user's machine), then
you can move around the memory side, unify different memory stores:
cache, RAM, local HD, Networked file storage (naturally logarithmic
scaling). There's no more need to "install applications": it's all
installed out there somewhere (probably from the same place where it
was created), you just need to "page it in". Create an abstract,
user-controlled, peer grouping model that allows arbitrary "trust (or
privacy) groups" where "node discovery" (say new annoucements) and
"shared memory" is allowed and watch the Social Linux Network Brain
evolve. (I better not even mention an integrated voting model
yet....)
Too idealistic?
marcos
pangaia.sourceforge.net
^ permalink raw reply
* Re: [PATCH] qlge: Fix incorrect usage of module parameters and netdev msg level
From: Ron Mercer @ 2010-11-18 22:17 UTC (permalink / raw)
To: Sonny Rao
Cc: netdev@vger.kernel.org, Milton Miller, Linux Driver,
linux-kernel@vger.kernel.org, sonnyrao@linux.vnet.ibm.com
In-Reply-To: <20101118215002.GS32203@us.ibm.com>
On Thu, Nov 18, 2010 at 01:50:02PM -0800, Sonny Rao wrote:
> 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 wants a number of bits. Ron Mercer suggests we should
> change this to pass in -1 so the defaults get used instead,
> which makes the default much less verbose.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
Milton/Sonny,
Did you happen to test this to see if the log output was the same?
^ permalink raw reply
* Re: alchemy/gpr: au1000_eth regression with v2.6.37rc2
From: Florian Fainelli @ 2010-11-18 22:30 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linux-MIPS, Netdev
In-Reply-To: <4CE58593.50509@grandegger.com>
Hello Wolfgang,
Le Thursday 18 November 2010 20:59:15, Wolfgang Grandegger a écrit :
> 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?
I do not understand so far while it hangs only for eth1. My device only has
one ethernet MAC, so I could not notice the problem. Looking at this close,
there are a couple of u32 const* usages in au1000_mdio_{read,write} which are
looking wrong to me now. Can you try to remove these?
>
> 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".
If you think this is another issue, I will fix it in another patch.
--
Florian
^ permalink raw reply
* [PATCH] net: fix kernel-doc for sk_filter_rcu_release
From: Randy Dunlap @ 2010-11-18 23:02 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix kernel-doc warning for sk_filter_rcu_release():
Warning(net/core/filter.c:586): missing initial short description on line:
* sk_filter_rcu_release: Release a socket filter by rcu_head
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
net/core/filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-2637-r2g4-kerndoc.orig/net/core/filter.c
+++ lnx-2637-r2g4-kerndoc/net/core/filter.c
@@ -589,7 +589,7 @@ int sk_chk_filter(struct sock_filter *fi
EXPORT_SYMBOL(sk_chk_filter);
/**
- * sk_filter_rcu_release: Release a socket filter by rcu_head
+ * sk_filter_rcu_release - Release a socket filter by rcu_head
* @rcu: rcu_head that contains the sk_filter to free
*/
static void sk_filter_rcu_release(struct rcu_head *rcu)
^ permalink raw reply
* Re: [PATCH] qlge: Fix incorrect usage of module parameters and netdev msg level
From: Sonny Rao @ 2010-11-18 23:12 UTC (permalink / raw)
To: ron.mercer, netdev@vger.kernel.org, Milton Miller, Linux Driver,
"linux-kernel@vger.kernel.org" <lin
In-Reply-To: <20101118221713.GB14333@linux-ox1b.qlogic.org>
On Thu, Nov 18, 2010 at 02:17:14PM -0800, Ron Mercer wrote:
> On Thu, Nov 18, 2010 at 01:50:02PM -0800, Sonny Rao wrote:
> > 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 wants a number of bits. Ron Mercer suggests we should
> > change this to pass in -1 so the defaults get used instead,
> > which makes the default much less verbose.
> >
> > Signed-off-by: Milton Miller <miltonm@bga.com>
> > Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
>
> Milton/Sonny,
> Did you happen to test this to see if the log output was the same?
Well, I haven't tried the -1 but I suspect it is much more sane than
the 15 I had before because that was excessively verbose and I always
ended up turning it down. I'll try it out and see.
--
Sonny Rao, LTC OzLabs, BML team
^ permalink raw reply
* [PATCH 1/4] X25: pushdown bkl in ioctls
From: Andrew Hendry @ 2010-11-18 23:20 UTC (permalink / raw)
To: netdev
Push down the bkl in the ioctls so they can be removed one at a time.
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
---
net/x25/af_x25.c | 41 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index f7af98d..c99029b 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1357,14 +1357,16 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
void __user *argp = (void __user *)arg;
int rc;
- lock_kernel();
switch (cmd) {
case TIOCOUTQ: {
- int amount = sk->sk_sndbuf - sk_wmem_alloc_get(sk);
+ int amount;
+ lock_kernel();
+ amount = sk->sk_sndbuf - sk_wmem_alloc_get(sk);
if (amount < 0)
amount = 0;
rc = put_user(amount, (unsigned int __user *)argp);
+ unlock_kernel();
break;
}
@@ -1375,23 +1377,29 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
* These two are safe on a single CPU system as
* only user tasks fiddle here
*/
+ lock_kernel();
if ((skb = skb_peek(&sk->sk_receive_queue)) != NULL)
amount = skb->len;
rc = put_user(amount, (unsigned int __user *)argp);
+ unlock_kernel();
break;
}
case SIOCGSTAMP:
rc = -EINVAL;
+ lock_kernel();
if (sk)
rc = sock_get_timestamp(sk,
(struct timeval __user *)argp);
+ unlock_kernel();
break;
case SIOCGSTAMPNS:
rc = -EINVAL;
+ lock_kernel();
if (sk)
rc = sock_get_timestampns(sk,
(struct timespec __user *)argp);
+ unlock_kernel();
break;
case SIOCGIFADDR:
case SIOCSIFADDR:
@@ -1410,27 +1418,36 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
rc = -EPERM;
if (!capable(CAP_NET_ADMIN))
break;
+ lock_kernel();
rc = x25_route_ioctl(cmd, argp);
+ unlock_kernel();
break;
case SIOCX25GSUBSCRIP:
+ lock_kernel();
rc = x25_subscr_ioctl(cmd, argp);
+ unlock_kernel();
break;
case SIOCX25SSUBSCRIP:
rc = -EPERM;
if (!capable(CAP_NET_ADMIN))
break;
+ lock_kernel();
rc = x25_subscr_ioctl(cmd, argp);
+ unlock_kernel();
break;
case SIOCX25GFACILITIES: {
struct x25_facilities fac = x25->facilities;
+ lock_kernel();
rc = copy_to_user(argp, &fac,
sizeof(fac)) ? -EFAULT : 0;
+ unlock_kernel();
break;
}
case SIOCX25SFACILITIES: {
struct x25_facilities facilities;
rc = -EFAULT;
+ lock_kernel();
if (copy_from_user(&facilities, argp,
sizeof(facilities)))
break;
@@ -1466,12 +1483,15 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
break;
x25->facilities = facilities;
rc = 0;
+ unlock_kernel();
break;
}
case SIOCX25GDTEFACILITIES: {
+ lock_kernel();
rc = copy_to_user(argp, &x25->dte_facilities,
sizeof(x25->dte_facilities));
+ unlock_kernel();
if (rc)
rc = -EFAULT;
break;
@@ -1480,6 +1500,7 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
case SIOCX25SDTEFACILITIES: {
struct x25_dte_facilities dtefacs;
rc = -EFAULT;
+ lock_kernel();
if (copy_from_user(&dtefacs, argp, sizeof(dtefacs)))
break;
rc = -EINVAL;
@@ -1496,13 +1517,16 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
break;
x25->dte_facilities = dtefacs;
rc = 0;
+ unlock_kernel();
break;
}
case SIOCX25GCALLUSERDATA: {
struct x25_calluserdata cud = x25->calluserdata;
+ lock_kernel();
rc = copy_to_user(argp, &cud,
sizeof(cud)) ? -EFAULT : 0;
+ unlock_kernel();
break;
}
@@ -1510,6 +1534,7 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
struct x25_calluserdata calluserdata;
rc = -EFAULT;
+ lock_kernel();
if (copy_from_user(&calluserdata, argp,
sizeof(calluserdata)))
break;
@@ -1517,24 +1542,29 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
if (calluserdata.cudlength > X25_MAX_CUD_LEN)
break;
x25->calluserdata = calluserdata;
+ unlock_kernel();
rc = 0;
break;
}
case SIOCX25GCAUSEDIAG: {
struct x25_causediag causediag;
+ lock_kernel();
causediag = x25->causediag;
rc = copy_to_user(argp, &causediag,
sizeof(causediag)) ? -EFAULT : 0;
+ unlock_kernel();
break;
}
case SIOCX25SCAUSEDIAG: {
struct x25_causediag causediag;
rc = -EFAULT;
+ lock_kernel();
if (copy_from_user(&causediag, argp, sizeof(causediag)))
break;
x25->causediag = causediag;
+ unlock_kernel();
rc = 0;
break;
@@ -1543,6 +1573,7 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
case SIOCX25SCUDMATCHLEN: {
struct x25_subaddr sub_addr;
rc = -EINVAL;
+ lock_kernel();
if(sk->sk_state != TCP_CLOSE)
break;
rc = -EFAULT;
@@ -1553,21 +1584,25 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
if(sub_addr.cudmatchlength > X25_MAX_CUD_LEN)
break;
x25->cudmatchlength = sub_addr.cudmatchlength;
+ unlock_kernel();
rc = 0;
break;
}
case SIOCX25CALLACCPTAPPRV: {
rc = -EINVAL;
+ lock_kernel();
if (sk->sk_state != TCP_CLOSE)
break;
clear_bit(X25_ACCPT_APPRV_FLAG, &x25->flags);
+ unlock_kernel();
rc = 0;
break;
}
case SIOCX25SENDCALLACCPT: {
rc = -EINVAL;
+ lock_kernel();
if (sk->sk_state != TCP_ESTABLISHED)
break;
/* must call accptapprv above */
@@ -1575,6 +1610,7 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
break;
x25_write_internal(sk, X25_CALL_ACCEPTED);
x25->state = X25_STATE_3;
+ unlock_kernel();
rc = 0;
break;
}
@@ -1583,7 +1619,6 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
rc = -ENOIOCTLCMD;
break;
}
- unlock_kernel();
return rc;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] X25: remove bkl in timestamp ioctls
From: Andrew Hendry @ 2010-11-18 23:21 UTC (permalink / raw)
To: netdev
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
---
net/x25/af_x25.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index c99029b..2259783 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1387,19 +1387,15 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
case SIOCGSTAMP:
rc = -EINVAL;
- lock_kernel();
if (sk)
rc = sock_get_timestamp(sk,
(struct timeval __user *)argp);
- unlock_kernel();
break;
case SIOCGSTAMPNS:
rc = -EINVAL;
- lock_kernel();
if (sk)
rc = sock_get_timestampns(sk,
(struct timespec __user *)argp);
- unlock_kernel();
break;
case SIOCGIFADDR:
case SIOCSIFADDR:
@@ -1689,19 +1685,15 @@ static int compat_x25_ioctl(struct socket *sock, unsigned int cmd,
break;
case SIOCGSTAMP:
rc = -EINVAL;
- lock_kernel();
if (sk)
rc = compat_sock_get_timestamp(sk,
(struct timeval __user*)argp);
- unlock_kernel();
break;
case SIOCGSTAMPNS:
rc = -EINVAL;
- lock_kernel();
if (sk)
rc = compat_sock_get_timestampns(sk,
(struct timespec __user*)argp);
- unlock_kernel();
break;
case SIOCGIFADDR:
case SIOCSIFADDR:
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] X25: remove bkl in inq and outq ioctls
From: Andrew Hendry @ 2010-11-18 23:21 UTC (permalink / raw)
To: netdev
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
---
net/x25/af_x25.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 2259783..2f235a6 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1361,12 +1361,10 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
case TIOCOUTQ: {
int amount;
- lock_kernel();
amount = sk->sk_sndbuf - sk_wmem_alloc_get(sk);
if (amount < 0)
amount = 0;
rc = put_user(amount, (unsigned int __user *)argp);
- unlock_kernel();
break;
}
@@ -1377,11 +1375,11 @@ static int x25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
* These two are safe on a single CPU system as
* only user tasks fiddle here
*/
- lock_kernel();
+ lock_sock(sk);
if ((skb = skb_peek(&sk->sk_receive_queue)) != NULL)
amount = skb->len;
+ release_sock(sk);
rc = put_user(amount, (unsigned int __user *)argp);
- unlock_kernel();
break;
}
--
1.7.1
^ 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