* Re: [stable] net: Handle different key sizes between address families in flow cache
From: David Miller @ 2011-11-04 20:41 UTC (permalink / raw)
To: kim.phillips; +Cc: stable, eric.dumazet, zheng.z.yan, netdev, david.ward
In-Reply-To: <20111104144659.3e0a30afffffd9dd73cf740e@freescale.com>
From: Kim Phillips <kim.phillips@freescale.com>
Date: Fri, 4 Nov 2011 14:46:59 -0500
> commit aa1c366e4febc7f5c2b84958a2dd7cd70e28f9d0 upstream.
>
> With the conversion of struct flowi to a union of AF-specific structs, some
> operations on the flow cache need to account for the exact size of the key.
>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Cc: stable@vger.kernel.org # v3.0.x
I'm fine with this, -stable folks please apply.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: add calxeda xgmac ethernet driver
From: Rob Herring @ 2011-11-04 20:52 UTC (permalink / raw)
To: Grant Likely
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <CACxGe6sAFUwQc5Nk=gGLC+si-_C32AWu=E14vBkSm7YCFhazFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Grant,
On 11/04/2011 11:57 AM, Grant Likely wrote:
> On Wed, Oct 26, 2011 at 10:56 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>
>> Add support for the XGMAC 10Gb ethernet device in the Calxeda Highbank
>> SOC.
>>
>> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>
> Sinker question: is this a driver for an entirely new GMAC device
> (designed from scratch) or is it based on an existing IP block?
>
Of course I'd rather use a existing driver. It is a new IP block.
>> +/**
>> + * xgmac_init - Entry point for the driver
>> + * Description: This function is the entry point for the driver.
>> + */
>> +static int __init xgmac_init(void)
>> +{
>> + return platform_driver_register(&xgmac_driver);
>> +}
>> +module_init(xgmac_init);
>> +
>> +/**
>> + * xgmac_cleanup_module - Cleanup routine for the driver
>> + * Description: This function is the cleanup routine for the driver.
>> + */
>> +static void __exit xgmac_exit(void)
>> +{
>> + platform_driver_unregister(&xgmac_driver);
>> +}
>> +module_exit(xgmac_exit);
>
> You can drop some boilerplate with module_platform_driver() now.
Okay.
Rob
^ permalink raw reply
* Re: [patch] bonding: comparing a u8 with -1 is always false
From: Dan Carpenter @ 2011-11-04 20:53 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Weiping Pan, Andy Gospodarek, netdev, David S. Miller,
kernel-janitors, Ben Hutchings
In-Reply-To: <10444.1320436921@death>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
On Fri, Nov 04, 2011 at 01:02:01PM -0700, Jay Vosburgh wrote:
>
> Since you #define SPEED_UNKNOWN to -1 (below), how does this
> actually change anything? Did you mean 0xffff (because struct
> ethtool_cmd's speed is a u16)?
>
Sorry I could have explained this better in the changelog. The
slave->speed is stored in a u32 and the -1 works fine as is.
Obviously, as you point out the define doesn't change anything. I
just changed it so it would look symetric with DUPLEX_UNKNOWN.
But I think you missed that I defined #define DUPLEX_UNKNOWN 0xff.
Before it we used a -1 for both and that didn't work.
I can resend this with a note about the SPEED_UNKNOWN cleanup if
you'd like. I'll do that tomorrow or Sunday.
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [net-next 03/10] seeq: Move the SEEQ drivers
From: Jeff Kirsher @ 2011-11-04 21:10 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: torvalds@linux-foundation.org, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Hamish Coleman
In-Reply-To: <20111104172446.GB12913@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]
On Fri, 2011-11-04 at 10:24 -0700, Russell King - ARM Linux wrote:
> Okay, this is the only patch I saw (for the SEEQ drivers), but I notice
> that more of the ARM drivers have moved. The result is not nice. Or
> even workable.
>
> While looking for my ether1, ether3 and etherh drivers in Kconfig, I
> enable every option which is presented to me under the new 'ethernet
> drivers' stuff. I'm offered my ether3 driver under the SEEQ stuff -
> that's fine. But what about the rest?
>
> Well...
>
> drivers/net/ethernet/intel/Kconfig:
> config NET_VENDOR_INTEL
> bool "Intel devices"
> default y
> depends on PCI || PCI_MSI
>
> drivers/net/ethernet/i825xx/Kconfig:
> config NET_VENDOR_I825XX
> bool "Intel (82586/82593/82596) devices"
> default y
> depends on NET_VENDOR_INTEL && (ISA || ISA_DMA_API || ARM || \
> ARCH_ACORN || MCA || MCA_LEGACY || SNI_RM || SUN3 || \
> GSC || BVME6000 || MVME16x || EXPERIMENTAL)
>
> if NET_VENDOR_I825XX
> config ARM_ETHER1
> tristate "Acorn Ether1 support"
> depends on ARM && ARCH_ACORN
>
> This is NOT a PCI driver, yet it has ended up with a requirement for
> CONFIG_PCI to be set, which is nonsense for this platform because it
> has no PCI.
>
> What about etherh?
> drivers/net/ethernet/natsemi/Kconfig:
> config NET_VENDOR_NATSEMI
> bool "National Semi-conductor devices"
> default y
> depends on MCA || MAC || MACH_JAZZ || PCI || XTENSA_PLATFORM_XT2000
>
> drivers/net/ethernet/8390/Kconfig:
> config NET_VENDOR_8390
> bool "National Semi-conductor 8390 devices"
> default y
> depends on NET_VENDOR_NATSEMI && (AMIGA_PCMCIA || PCI || SUPERH || \
> ISA || MCA || EISA || MAC || M32R || MACH_TX49XX || \
> MCA_LEGACY || H8300 || ARM || MIPS || ZORRO || PCMCIA || \
> EXPERIMENTAL)
> if NET_VENDOR_8390
> config ARM_ETHERH
> tristate "I-cubed EtherH/ANT EtherM support"
> depends on ARM && ARCH_ACORN
>
> Again, exactly the same thing.
>
> Thankfully, ARM_AM79C961A is right, so that's two out of five correct.
>
> I've no idea what the right solution is to this complex maze of Kconfig
> stuff. Do I through an 'ARM' into the NET_VENDOR_INTEL and
> NET_VENDOR_NATSEMI dependencies?
>
> While I realise this is a big change, and bugs like this are likely, it
> would've been nice to be copied on more of the patches which affect
> drivers I maintain.
I just submitted a patch to resolve this issue with the "sub" Kconfig's
having a dependency which is not reflected in the "parent" Kconfig.
http://patchwork.ozlabs.org/patch/123250/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] gianfar: add support for wake-on-packet
From: Scott Wood @ 2011-11-04 21:11 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, netdev, afleming
In-Reply-To: <1320410403-14639-1-git-send-email-chenhui.zhao@freescale.com>
On 11/04/2011 07:40 AM, Zhao Chenhui wrote:
> diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> index 2c6be03..543e36c 100644
> --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> @@ -56,6 +56,9 @@ Properties:
> hardware.
> - fsl,magic-packet : If present, indicates that the hardware supports
> waking up via magic packet.
> + - fsl,wake-on-filer : If present, indicates that the hardware supports
> + waking up via arp request to local ip address or unicast packet to
> + local mac address.
Is there any way to determine this at runtime via the device's registers?
I think TSEC_ID2[TSEC_CFG] can be used. The manual describes it
awkwardly, but it looks like 0x20 is the bit for the filer.
> @@ -751,7 +764,6 @@ static int gfar_of_init(struct platform_device *ofdev, struct net_device **pdev)
> FSL_GIANFAR_DEV_HAS_PADDING |
> FSL_GIANFAR_DEV_HAS_CSUM |
> FSL_GIANFAR_DEV_HAS_VLAN |
> - FSL_GIANFAR_DEV_HAS_MAGIC_PACKET |
> FSL_GIANFAR_DEV_HAS_EXTENDED_HASH |
> FSL_GIANFAR_DEV_HAS_TIMER;
This is an unrelated change. Are there any eTSECs that don't support
magic packet?
> +static int gfar_get_ip(struct net_device *dev)
> +{
> + struct gfar_private *priv = netdev_priv(dev);
> + struct in_device *in_dev = (struct in_device *)dev->ip_ptr;
> + struct in_ifaddr *ifa;
> +
> + if (in_dev != NULL) {
> + ifa = (struct in_ifaddr *)in_dev->ifa_list;
> + if (ifa != NULL) {
> + memcpy(priv->ip_addr, &ifa->ifa_address, 4);
> + return 0;
> + }
> + }
> + return -ENOENT;
> +}
Unnecessary cast, ifa_list is already struct in_ifaddr *.
Better, use for_primary_ifa(), and document that you won't wake on ARP
packets for secondary IP addresses.
> static int gfar_suspend(struct device *dev)
> {
> @@ -1268,9 +1443,17 @@ static int gfar_suspend(struct device *dev)
> struct gfar __iomem *regs = priv->gfargrp[0].regs;
> unsigned long flags;
> u32 tempval;
> -
> int magic_packet = priv->wol_en &&
> - (priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
> + (priv->wol_opts & GIANFAR_WOL_MAGIC);
> + int arp_packet = priv->wol_en &&
> + (priv->wol_opts & GIANFAR_WOL_ARP);
> +
> + if (arp_packet) {
> + pmc_enable_wake(priv->ofdev, PM_SUSPEND_MEM, 1);
> + pmc_enable_lossless(1);
> + gfar_arp_suspend(ndev);
> + return 0;
> + }
How do we know this isn't standby?
> @@ -577,11 +578,18 @@ static void gfar_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> {
> struct gfar_private *priv = netdev_priv(dev);
>
> + wol->supported = 0;
> + wol->wolopts = 0;
> +
> if (priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET) {
> - wol->supported = WAKE_MAGIC;
> - wol->wolopts = priv->wol_en ? WAKE_MAGIC : 0;
> - } else {
> - wol->supported = wol->wolopts = 0;
> + wol->supported |= WAKE_MAGIC;
> + wol->wolopts |= (priv->wol_opts & GIANFAR_WOL_MAGIC) ?
> + WAKE_MAGIC : 0;
> + }
> + if (priv->device_flags & FSL_GIANFAR_DEV_HAS_ARP_PACKET) {
> + wol->supported |= WAKE_ARP;
> + wol->wolopts |= (priv->wol_opts & GIANFAR_WOL_ARP) ?
> + WAKE_ARP : 0;
> }
> }
Shouldn't we just make sure we don't set a bit in priv->wol_opts if we
don't support it? Maybe create the "supported" mask at init time, so we
can use logical bit ops rather than a bunch of if statements?
> @@ -591,16 +599,21 @@ static int gfar_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> unsigned long flags;
>
> if (!(priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET) &&
> - wol->wolopts != 0)
> - return -EINVAL;
> -
> - if (wol->wolopts & ~WAKE_MAGIC)
> + !(priv->device_flags & FSL_GIANFAR_DEV_HAS_ARP_PACKET))
> return -EINVAL;
>
> - device_set_wakeup_enable(&dev->dev, wol->wolopts & WAKE_MAGIC);
> -
> spin_lock_irqsave(&priv->bflock, flags);
> - priv->wol_en = !!device_may_wakeup(&dev->dev);
> + if (wol->wolopts & WAKE_MAGIC) {
> + priv->wol_en = 1;
> + priv->wol_opts = GIANFAR_WOL_MAGIC;
> + } else if (wol->wolopts & WAKE_ARP) {
> + priv->wol_en = 1;
> + priv->wol_opts = GIANFAR_WOL_ARP;
What if both WAKE_MAGIC and WAKE_ARP are set?
And shouldn't you make sure we actually support the one being requested,
rather than just making sure that we support one of the wake modes?
-Scott
^ permalink raw reply
* Re: [PATCH 7/7] gianfar: add support for wake-on-packet
From: Scott Wood @ 2011-11-04 21:13 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: netdev, linuxppc-dev, afleming
In-Reply-To: <4EB45515.6060405@freescale.com>
On 11/04/2011 04:11 PM, Scott Wood wrote:
> On 11/04/2011 07:40 AM, Zhao Chenhui wrote:
>> static int gfar_suspend(struct device *dev)
>> {
>> @@ -1268,9 +1443,17 @@ static int gfar_suspend(struct device *dev)
>> struct gfar __iomem *regs = priv->gfargrp[0].regs;
>> unsigned long flags;
>> u32 tempval;
>> -
>> int magic_packet = priv->wol_en &&
>> - (priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
>> + (priv->wol_opts & GIANFAR_WOL_MAGIC);
>> + int arp_packet = priv->wol_en &&
>> + (priv->wol_opts & GIANFAR_WOL_ARP);
>> +
>> + if (arp_packet) {
>> + pmc_enable_wake(priv->ofdev, PM_SUSPEND_MEM, 1);
>> + pmc_enable_lossless(1);
>> + gfar_arp_suspend(ndev);
>> + return 0;
>> + }
>
> How do we know this isn't standby?
Or suspend to disk, for that matter?
-Scott
^ permalink raw reply
* Re: [PATCH 6/7] fsl_pmc: Add API to enable device as wakeup event source
From: Scott Wood @ 2011-11-04 21:14 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, netdev
In-Reply-To: <1320410349-14600-1-git-send-email-chenhui.zhao@freescale.com>
On 11/04/2011 07:39 AM, Zhao Chenhui wrote:
> @@ -45,6 +46,72 @@ static int has_lossless;
> * code can be compatible with both 32-bit & 36-bit */
> extern void mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
>
> +#ifdef CONFIG_FSL_PMC
> +/**
> + * pmc_enable_wake - enable OF device as wakeup event source
> + * @pdev: platform device affected
> + * @state: PM state from which device will issue wakeup events
> + * @enable: True to enable event generation; false to disable
> + *
> + * This enables the device as a wakeup event source, or disables it.
> + *
> + * RETURN VALUE:
> + * 0 is returned on success
> + * -EINVAL is returned if device is not supposed to wake up the system
> + * Error code depending on the platform is returned if both the platform and
> + * the native mechanism fail to enable the generation of wake-up events
> + */
> +int pmc_enable_wake(struct platform_device *pdev,
> + suspend_state_t state, bool enable)
"pmc" is too generic for a global function. If this can be either
enable or disable, perhaps it should be something like
mpc85xx_pmc_set_wake().
> +{
> + int ret = 0;
> + struct device_node *clk_np;
> + u32 *pmcdr_mask;
> +
> + if (!pmc_regs) {
> + printk(KERN_WARNING "PMC is unavailable\n");
> + return -ENOMEM;
> + }
-ENOMEM is not appropriate here, maybe -ENODEV?
Should print __func__ so the user knows what's complaining.
> + if (enable && !device_may_wakeup(&pdev->dev))
> + return -EINVAL;
> +
> + clk_np = of_parse_phandle(pdev->dev.of_node, "clk-handle", 0);
> + if (!clk_np)
> + return -EINVAL;
> +
> + pmcdr_mask = (u32 *)of_get_property(clk_np, "fsl,pmcdr-mask", NULL);
> + if (!pmcdr_mask) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + /* clear to enable clock in low power mode */
> + if (enable)
> + clrbits32(&pmc_regs->pmcdr, *pmcdr_mask);
> + else
> + setbits32(&pmc_regs->pmcdr, *pmcdr_mask);
We should probably initialize PMCDR to all bits set (or at least all
ones we know are valid) -- the default should be "not a wakeup source".
> +/**
> + * pmc_enable_lossless - enable lossless ethernet in low power mode
> + * @enable: True to enable event generation; false to disable
> + */
> +void pmc_enable_lossless(int enable)
> +{
> + if (enable && has_lossless)
> + setbits32(&pmc_regs->pmcsr, PMCSR_LOSSLESS);
> + else
> + clrbits32(&pmc_regs->pmcsr, PMCSR_LOSSLESS);
> +}
> +EXPORT_SYMBOL_GPL(pmc_enable_lossless);
> +#endif
Won't we overwrite this later?
-Scott
^ permalink raw reply
* Re: [net-next 03/10] seeq: Move the SEEQ drivers
From: Joe Perches @ 2011-11-04 21:16 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jeff Kirsher, torvalds, davem, netdev, gospo, sassmann,
Hamish Coleman
In-Reply-To: <20111104172446.GB12913@n2100.arm.linux.org.uk>
On Fri, 2011-11-04 at 17:24 +0000, Russell King - ARM Linux wrote:
> Okay, this is the only patch I saw (for the SEEQ drivers), but I notice
> that more of the ARM drivers have moved. The result is not nice. Or
> even workable.
>
> While looking for my ether1, ether3 and etherh drivers in Kconfig, I
> enable every option which is presented to me under the new 'ethernet
> drivers' stuff. I'm offered my ether3 driver under the SEEQ stuff -
> that's fine. But what about the rest?
[]
> While I realise this is a big change, and bugs like this are likely, it
> would've been nice to be copied on more of the patches which affect
> drivers I maintain.
Hi Russell.
What drivers in drivers/net do you maintain?
I believe this is the list in MAINTAINERS for you:
ARM/EBSA110 MACHINE SUPPORT
F: drivers/net/ethernet/amd/am79c961a.*
ARM/RISCPC ARCHITECTURE
F: drivers/net/ethernet/i825xx/ether1*
F: drivers/net/ethernet/seeq/ether3*
Are there others? If yes, what are they?
^ permalink raw reply
* Re: [net-next 03/10] seeq: Move the SEEQ drivers
From: Russell King - ARM Linux @ 2011-11-04 21:25 UTC (permalink / raw)
To: Joe Perches
Cc: Jeff Kirsher, torvalds, davem, netdev, gospo, sassmann,
Hamish Coleman
In-Reply-To: <1320441367.2113.4.camel@Joe-Laptop>
On Fri, Nov 04, 2011 at 11:16:07PM +0200, Joe Perches wrote:
> On Fri, 2011-11-04 at 17:24 +0000, Russell King - ARM Linux wrote:
> > Okay, this is the only patch I saw (for the SEEQ drivers), but I notice
> > that more of the ARM drivers have moved. The result is not nice. Or
> > even workable.
> >
> > While looking for my ether1, ether3 and etherh drivers in Kconfig, I
> > enable every option which is presented to me under the new 'ethernet
> > drivers' stuff. I'm offered my ether3 driver under the SEEQ stuff -
> > that's fine. But what about the rest?
> []
> > While I realise this is a big change, and bugs like this are likely, it
> > would've been nice to be copied on more of the patches which affect
> > drivers I maintain.
>
> Hi Russell.
>
> What drivers in drivers/net do you maintain?
>
> I believe this is the list in MAINTAINERS for you:
>
> ARM/EBSA110 MACHINE SUPPORT
> F: drivers/net/ethernet/amd/am79c961a.*
> ARM/RISCPC ARCHITECTURE
> F: drivers/net/ethernet/i825xx/ether1*
> F: drivers/net/ethernet/seeq/ether3*
>
> Are there others? If yes, what are they?
If that's what's in mainline, then etherh has been dropped from that
list through this move. It's drivers/net/ethernet/8390/etherh*, so
that needs adding back for "ARM/RISCPC ARCHITECTURE".
It was correct - below seems to be what happened...
commit 115978859272b958366d4a08c99a24f9625fa663
Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed Jul 13 15:38:08 2011 -0700
i825xx: Move the Intel 82586/82593/82596 based drivers
@@ -1014,7 +1014,7 @@ F: arch/arm/include/asm/hardware/ioc.h
F: arch/arm/include/asm/hardware/iomd.h
F: arch/arm/include/asm/hardware/memc.h
F: arch/arm/mach-rpc/
-F: drivers/net/arm/ether*
+F: drivers/net/arm/ether3*
That change was probably correct at the time, because this one which
came before it:
commit 644570b830266ff33ff5f3542b9c838f93a55ea6
Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat Apr 2 06:20:12 2011 -0700
8390: Move the 8390 related drivers
which moved the etherh driver without updating MAINTAINERS for that
change.
^ permalink raw reply
* Re: pull request: wireless 2011-11-04
From: David Miller @ 2011-11-04 21:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111104191343.GB13505@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 4 Nov 2011 15:13:44 -0400
> The following changes since commit 1a67a573b8d9f02211f36fbab50f6265dc49384a:
>
> Merge git://git.samba.org/sfrench/cifs-2.6 (2011-11-03 21:07:58 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Pulled, thanks John.
^ permalink raw reply
* Re: [stable] net: Handle different key sizes between address families in flow cache
From: Greg KH @ 2011-11-04 21:24 UTC (permalink / raw)
To: Kim Phillips
Cc: David Miller, stable, eric.dumazet, zheng.z.yan, netdev,
David Ward
In-Reply-To: <20111104144659.3e0a30afffffd9dd73cf740e@freescale.com>
On Fri, Nov 04, 2011 at 02:46:59PM -0500, Kim Phillips wrote:
> commit aa1c366e4febc7f5c2b84958a2dd7cd70e28f9d0 upstream.
>
> With the conversion of struct flowi to a union of AF-specific structs, some
> operations on the flow cache need to account for the exact size of the key.
>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Cc: stable@vger.kernel.org # v3.0.x
> ---
> This patch is the result of a clean cherry-pick onto v3.0.8.
> It restores IPSec fwding performance from ~4kpps back to ~44kpps on
> a P2020DS board.
Too bad you forgot to build this patch after you applied it:
CC init/main.o
In file included from include/linux/security.h:39:0,
from init/main.c:32:
include/net/flow.h: In function ‘flow_key_size’:
include/net/flow.h:174:3: error: size of unnamed array is negative
include/net/flow.h:177:3: error: size of unnamed array is negative
Please be kind to your poor over-worked stable kernel maintainer and do
the decent thing and TEST YOUR PATCH before you ask him to accept it.
bah, I think it's time for the weekend to start a bit earlier than normal...
greg k-h
^ permalink raw reply
* Re: [net-next 03/10] seeq: Move the SEEQ drivers
From: Russell King - ARM Linux @ 2011-11-04 21:35 UTC (permalink / raw)
To: Jeff Kirsher
Cc: torvalds@linux-foundation.org, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Hamish Coleman
In-Reply-To: <1320441002.5386.4.camel@jtkirshe-mobl>
On Fri, Nov 04, 2011 at 02:10:02PM -0700, Jeff Kirsher wrote:
> I just submitted a patch to resolve this issue with the "sub" Kconfig's
> having a dependency which is not reflected in the "parent" Kconfig.
>
> http://patchwork.ozlabs.org/patch/123250/
Thanks, that seems to fix the issues for me. For that patch:
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
^ permalink raw reply
* Re: [PATCH 0/8] tg3: Driver bugfixes
From: David Miller @ 2011-11-04 21:35 UTC (permalink / raw)
To: mcarlson; +Cc: netdev
In-Reply-To: <1320434105-12898-1-git-send-email-mcarlson@broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Fri, 4 Nov 2011 12:14:57 -0700
> This patchset implements a few error path workarounds and corrects a few
> problems around tg3_reset_task() scheduling.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: Fix comments for Nagle algorithm
From: David Miller @ 2011-11-04 21:36 UTC (permalink / raw)
To: kinwin2008; +Cc: netdev, linux-kernel, kuznet, jmorris, kaber
In-Reply-To: <CAHp4QVu6jX2wRAvBWgeG_HDN-Q+XgVxCcwNTN4nUL2vd0oLs8A@mail.gmail.com>
Patch is massively corrupted by your email client, making it useless
to us.
Please read Documentation/email-clients.txt and resubmit this patch only
after you've successfully emailed the patch to yourself and verified that
you can apply it successfully.
^ permalink raw reply
* Re: [PATCH] macvlan: receive multicast with local address
From: David Miller @ 2011-11-04 21:40 UTC (permalink / raw)
To: shemminger; +Cc: arnd, netdev
In-Reply-To: <20111102151153.028e222f@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 2 Nov 2011 15:11:53 -0700
> When implementing VRRP v2 using macvlan several problems were
> discovered. VRRP is weird in that all routers participating
> in a redundant group use the same virtual MAC address.
> Macvlan is a natural driver to use for this but it doesn't
> work. The problem is that packets with a macvlan device's
> source address are not received.
>
> The problem is actually a regression that date back almost 2 years now.
> The original problems started with:
>
> commit 618e1b7482f7a8a4c6c6e8ccbe140e4c331df4e9
> Author: Arnd Bergmann <arnd@arndb.de>
> Date: Thu Nov 26 06:07:10 2009 +0000
>
> macvlan: implement bridge, VEPA and private mode
>
> This patches restores the original 2.6.32 behavior. Allowing multicast
> packets received with the VRRP source address to be received.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [net] i825xx:xscale:8390:freescale: Fix Kconfig dependancies
From: David Miller @ 2011-11-04 21:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1320229852-18161-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 2 Nov 2011 03:30:52 -0700
> i825xx and xscale are "sub" Kconfigs to NET_VENDOR_INTEL, so
> NET_VENDOR_INTEL should contain ALL the dependencies of the
> "sub" Kconfigs.
>
> Same with 8390 is a "sub" Kconfig to NET_VENDOR_NATSEMI, so
> NET_VENDOR_NATSEMI needs to contains ALL the dependencies.
>
> Freescale Kconfig only had fs_enet as a sub Kconfig, and already
> contained the needed dependencies, just cleaned up the dependencies.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, but:
> + XTENSA_PLATFORM_XT2000 || ZORRO
> +
> ---help---
I removed that extraneous white-space-only line before "--help--"
^ permalink raw reply
* Re: [net-next 03/10] seeq: Move the SEEQ drivers
From: Jeff Kirsher @ 2011-11-04 21:42 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Joe Perches, torvalds@linux-foundation.org, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Hamish Coleman
In-Reply-To: <20111104212555.GD12913@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]
On Fri, 2011-11-04 at 14:25 -0700, Russell King - ARM Linux wrote:
> On Fri, Nov 04, 2011 at 11:16:07PM +0200, Joe Perches wrote:
> > On Fri, 2011-11-04 at 17:24 +0000, Russell King - ARM Linux wrote:
> > > Okay, this is the only patch I saw (for the SEEQ drivers), but I notice
> > > that more of the ARM drivers have moved. The result is not nice. Or
> > > even workable.
> > >
> > > While looking for my ether1, ether3 and etherh drivers in Kconfig, I
> > > enable every option which is presented to me under the new 'ethernet
> > > drivers' stuff. I'm offered my ether3 driver under the SEEQ stuff -
> > > that's fine. But what about the rest?
> > []
> > > While I realise this is a big change, and bugs like this are likely, it
> > > would've been nice to be copied on more of the patches which affect
> > > drivers I maintain.
> >
> > Hi Russell.
> >
> > What drivers in drivers/net do you maintain?
> >
> > I believe this is the list in MAINTAINERS for you:
> >
> > ARM/EBSA110 MACHINE SUPPORT
> > F: drivers/net/ethernet/amd/am79c961a.*
> > ARM/RISCPC ARCHITECTURE
> > F: drivers/net/ethernet/i825xx/ether1*
> > F: drivers/net/ethernet/seeq/ether3*
> >
> > Are there others? If yes, what are they?
>
> If that's what's in mainline, then etherh has been dropped from that
> list through this move. It's drivers/net/ethernet/8390/etherh*, so
> that needs adding back for "ARM/RISCPC ARCHITECTURE".
>
> It was correct - below seems to be what happened...
>
> commit 115978859272b958366d4a08c99a24f9625fa663
> Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Wed Jul 13 15:38:08 2011 -0700
>
> i825xx: Move the Intel 82586/82593/82596 based drivers
>
> @@ -1014,7 +1014,7 @@ F: arch/arm/include/asm/hardware/ioc.h
> F: arch/arm/include/asm/hardware/iomd.h
> F: arch/arm/include/asm/hardware/memc.h
> F: arch/arm/mach-rpc/
> -F: drivers/net/arm/ether*
> +F: drivers/net/arm/ether3*
>
> That change was probably correct at the time, because this one which
> came before it:
>
> commit 644570b830266ff33ff5f3542b9c838f93a55ea6
> Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Sat Apr 2 06:20:12 2011 -0700
>
> 8390: Move the 8390 related drivers
>
> which moved the etherh driver without updating MAINTAINERS for that
> change.
This was my bad. There was a lot of discussion and shuffling of drivers
early on to make sure we have the drivers in the right location, and I
initially had all the drivers/net/arm/ether* drivers in the same
location. I can put together a patch to resolve this if no one has one
in the works.
Sorry about that Russell.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] netlink: validate NLA_MSECS length
From: David Miller @ 2011-11-04 21:48 UTC (permalink / raw)
To: johannes; +Cc: netdev, tgraf
In-Reply-To: <1320314852.3950.36.camel@jlt3.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 03 Nov 2011 11:07:32 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> L2TP for example uses NLA_MSECS like this:
> policy:
> [L2TP_ATTR_RECV_TIMEOUT] = { .type = NLA_MSECS, },
> code:
> if (info->attrs[L2TP_ATTR_RECV_TIMEOUT])
> cfg.reorder_timeout = nla_get_msecs(info->attrs[L2TP_ATTR_RECV_TIMEOUT]);
>
> As nla_get_msecs() is essentially nla_get_u64() plus the
> conversion to a HZ-based value, this will not properly
> reject attributes from userspace that aren't long enough
> and might overrun the message.
>
> Add NLA_MSECS to the attribute minlen array to check the
> size properly.
>
> Cc: Thomas Graf <tgraf@suug.ch>
> Cc: stable@vger.kernel.org
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] netlink: clarify attribute length check documentation
From: David Miller @ 2011-11-04 21:48 UTC (permalink / raw)
To: johannes; +Cc: netdev, tgraf
In-Reply-To: <1320315005.3950.37.camel@jlt3.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 03 Nov 2011 11:10:05 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> The documentation for how the length of attributes
> is checked is wrong ("Exact length" isn't true, the
> policy checks are for "minimum length") and a bit
> misleading. Make it more complete and explain what
> really happens.
>
> Cc: Thomas Graf <tgraf@suug.ch>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: add wireless TX status socket option
From: David Miller @ 2011-11-04 21:51 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1320317796.3950.43.camel@jlt3.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 03 Nov 2011 11:56:36 +0100
...
> To get rid of that hack, introduce a real wifi TX
> status option for data frame transmissions.
>
> This works similar to the existing TX timestamping
> in that it reflects the SKB back to the socket's
> error queue with a SCM_WIFI_STATUS cmsg that has
> an int indicating ACK status (0/1).
...
> I'd like to merge this through the wireless tree since
> some new features sort of depend on it. Thoughts?
No objections, feel free to put this into the wireless tree.
^ permalink raw reply
* Re: [PATCH v3 0/3] SUNRPC: rcbind clients virtualization
From: J. Bruce Fields @ 2011-11-04 22:10 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
devel@openvz.org
In-Reply-To: <4EAA78DD.2000408@parallels.com>
On Fri, Oct 28, 2011 at 01:41:49PM +0400, Stanislav Kinsbursky wrote:
> 28.10.2011 13:30, J. Bruce Fields пишет:
> >On Fri, Oct 28, 2011 at 01:24:45PM +0400, Stanislav Kinsbursky wrote:
> >>This patch-set was created before you've sent your NFSd plan and we
> >>disacussed Lockd per netns.
> >>So, this sentence: "NFSd service will be per netns too from my pow"
> >>is obsolete. And Lockd will be one for all.
> >
> >I believe lockd should be pert-netns--at least that's what the server
> >needs.
> >
> >(The single lockd thread may handle requests from all netns, but it
> >should behave like a different service depending on netns, so its data
> >structures, etc. will need to be per-ns.
> >
>
> Sure. Looks like we have misunderstanding here. When I said, that
> Lockd should be one for all, I meaned, that we will have only one
> kthread for all ns (not one per ns). Private data will be per net
> ns, of course.
>
> BTW, Bruce, please, have a brief look at my e-mail to
> linux-nfs@vger.kernel.org named "SUNRPC: non-exclusive pipe
> creation".
> I've done a lot in "RPC pipefs per net ns" task, and going to send
> first patches soon. But right now I'm really confused will this
> non-exclusive pipes creation and almost ready so remove this
> functionality. But I'm afraid, that I've missed something. Would be
> greatly appreciate for your opinion about my question.
Sorry for the delay--it looks reasonable to me on a quick skim, but I'm
assuming it's Trond that will need to review this.
--b.
>
> >--b.
> >
> >>Or you are asking about something else?
> >>
> >>>--b.
> >>>
> >>>>And also we have NFSd file system, which
> >>>>is not virtualized yet.
> >>>>
> >>>>The following series consists of:
> >>>>
> >>>>---
> >>>>
> >>>>Stanislav Kinsbursky (3):
> >>>> SUNRPC: move rpcbind internals to sunrpc part of network namespace context
> >>>> SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
> >>>> SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
> >>>>
> >>>>
> >>>> net/sunrpc/netns.h | 5 ++
> >>>> net/sunrpc/rpcb_clnt.c | 103 ++++++++++++++++++++++++++----------------------
> >>>> 2 files changed, 61 insertions(+), 47 deletions(-)
> >>>>
> >>>>--
> >>>>Signature
> >>
> >>
> >>--
> >>Best regards,
> >>Stanislav Kinsbursky
>
>
> --
> Best regards,
> Stanislav Kinsbursky
^ permalink raw reply
* [PATCH] sky2: fix regression on Yukon Optima
From: Stephen Hemminger @ 2011-11-04 22:17 UTC (permalink / raw)
To: Pavel Mateja, David Miller; +Cc: netdev
In-Reply-To: <201110171434.50436.pavel@netsafe.cz>
Changes to support other Optima types, introduced an accidental
regression that caused 88E8059 to come up in 10Mbit/sec.
The Yukon Optima supports a reverse auto-negotiation feature that
was incorrectly setup, and not needed. The feature could be used to
allow wake-on-lan at higher speeds. But doing it correctly would require
other changes to initialization.
Reported-by: Pavel Mateja <pavel@netsafe.cz>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
This version is for current driver organization (post 3.1).
Same fix applies but to drivers/net/sky2.c in -stable.
--- a/drivers/net/ethernet/marvell/sky2.c 2011-11-02 15:38:11.677011133 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c 2011-11-04 15:01:51.310888300 -0700
@@ -366,17 +366,6 @@ static void sky2_phy_init(struct sky2_hw
gm_phy_write(hw, port, PHY_MARV_FE_SPEC_2, spec);
}
} else {
- if (hw->chip_id >= CHIP_ID_YUKON_OPT) {
- u16 ctrl2 = gm_phy_read(hw, port, PHY_MARV_EXT_CTRL_2);
-
- /* enable PHY Reverse Auto-Negotiation */
- ctrl2 |= 1u << 13;
-
- /* Write PHY changes (SW-reset must follow) */
- gm_phy_write(hw, port, PHY_MARV_EXT_CTRL_2, ctrl2);
- }
-
-
/* disable energy detect */
ctrl &= ~PHY_M_PC_EN_DET_MSK;
^ permalink raw reply
* Re: [PATCH] sky2: fix regression on Yukon Optima
From: David Miller @ 2011-11-04 22:20 UTC (permalink / raw)
To: shemminger; +Cc: pavel, netdev
In-Reply-To: <20111104151717.0f4666ac@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 4 Nov 2011 15:17:17 -0700
> Changes to support other Optima types, introduced an accidental
> regression that caused 88E8059 to come up in 10Mbit/sec.
>
> The Yukon Optima supports a reverse auto-negotiation feature that
> was incorrectly setup, and not needed. The feature could be used to
> allow wake-on-lan at higher speeds. But doing it correctly would require
> other changes to initialization.
>
> Reported-by: Pavel Mateja <pavel@netsafe.cz>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> This version is for current driver organization (post 3.1).
> Same fix applies but to drivers/net/sky2.c in -stable.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* what's in a bus_info
From: Rick Jones @ 2011-11-04 22:27 UTC (permalink / raw)
To: netdev; +Cc: rusty, mst
...or would an interface name smell as sweet? (as PCI bus addressing)
Is there a "standard" for what is returned in bus_info of
ethtool_drvinfo? I have been very used to seeing PCI bus addressing
information in that field (at least as displayed by ethtool -i) and when
I went to "leverage how to" from other drivers, to add "native" ethtool
-i support to virtio_net, I ended-up with "eth0" rather than the PCI
information I see in lspci output and in ethtool -i against other
devices. Including an emulated e1000 interface in the same kernel.
What I'm doing is calling pci_name(), feeding it with to_pci_dev() from
the address of the struct device in the struct net_device. The perhaps
overly paranoid work-in-progress:
static void virtnet_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
{
struct device *dev_dev;
struct pci_dev *pci_dev = NULL;
dev_dev = &(dev->dev);
if (dev_dev != NULL)
pci_dev = to_pci_dev(dev_dev);
strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
strlcpy(info->version,"I am versionless", sizeof(info->version));
strlcpy(info->fw_version,"I have no firmware",
sizeof(info->fw_version));
strlcpy(info->bus_info,
(pci_dev != NULL) ? pci_name(pci_dev) : "",
sizeof(info->bus_info));
}
So, with the emulated e1000 I get:
raj@raj-ubuntu-guest:~$ ethtool -i eth0
driver: e1000
version: 7.3.21-k8-NAPI
firmware-version: N/A
bus-info: 0000:00:11.0
raj@raj-ubuntu-guest:~$
and I see that the e1000 driver calls pci_name(). However, the code
above, when I boot the guest with the virtio device gives me:
raj@raj-ubuntu-guest:~$ ethtool -i eth0
driver: virtio_net
version: I am versionless
firmware-version: I have no firmware
bus-info: eth0
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
Am I chasing the wrong pointers? Is it a function of virtio?
rick jones
BTW, I notice some drivers call strlcpy and some strncpy, and some even
call strcpy. Is there one that is meant to be preferred over the others?
^ permalink raw reply
* Re: pull request: wireless 2011-11-04
From: Rafał Miłecki @ 2011-11-04 22:30 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20111104191343.GB13505@tuxdriver.com>
2011/11/4 John W. Linville <linville@tuxdriver.com>:
> commit 22097fd297c85ec6c2e700d506f231f7cae442e1
>
> Dave,
>
> Here is the first batch of wireless fixes intended for 3.2 -- hooray!
John, could you take a look at 2 patches?
[PATCH 3.2 REQ V2] b43: HT-PHY: report signal to mac80211
[PATCH V2 3.2] b43: fill ctl1 word on all newer PHYs, fix PHY errors
I don't think there were commited for 3.2 or rejected by you.
Were there any problems with that 2 patches?
--
Rafał
^ 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