* Re: [PATCH 2/5] netfilter: nft_rbtree: no need for spinlock from set destroy path
From: Pablo Neira Ayuso @ 2014-09-23 16:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netfilter-devel, davem, netdev
In-Reply-To: <1411473245.26859.188.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 23, 2014 at 04:54:05AM -0700, Eric Dumazet wrote:
> On Tue, 2014-09-23 at 13:01 +0200, Pablo Neira Ayuso wrote:
>
> > I'll send a follow up patch for nf-next to use rb_first() in that
> > patch. Thanks Eric.
>
> I did a test, and its indeed a bit faster to use rb_first(), by about 5%
>
> Real win is to be able to build a chain using rb_first()/rb_next(),
> (leaving the tree as is), then deleting the items in the chain, and
> simply reset rb_root.
>
> This only needs to reuse one pointer to store the item->next pointer.
>
> This is then about ~50% faster, because we do not constantly rebalance
> tree for every removed item.
Indeed.
struct nft_rbtree_elem {
struct rb_node node;
u16 flags;
struct nft_data key;
struct nft_data data[];
};
Actually, I could add to nft_data a pointer in the union area, but I'm
not very confortable with adding it for this specific case. At this
moment we're releasing this from rcu_callback which is "hiding" the
deletion time from the netlink interface.
But I'll keep this back in my head if we later on have some pointer
candidate to be reused in a nice way.
I'll send a patch to make the rb_first()/rb_next() conversion though.
Thanks for your comments!
^ permalink raw reply
* Re: [PATCH 1/5] mips: Set CONFIG_NET=y in defconfigs
From: Michal Marek @ 2014-09-23 16:06 UTC (permalink / raw)
To: David Miller
Cc: sfr, rdunlap, netdev, linux-next, linux-kernel, linux-kbuild,
linux-mips
In-Reply-To: <20140923.120237.1788295912902036193.davem@davemloft.net>
On 2014-09-23 18:02, David Miller wrote:
> From: Michal Marek <mmarek@suse.cz>
> Date: Tue, 23 Sep 2014 17:44:00 +0200
>
>> Commit 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK dependent on NET
>> instead of selecting NET") removed what happened to be the only instance
>> of 'select NET'. Defconfigs that were relying on the select now lack
>> networking support.
>>
>> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> Cc: linux-mips@linux-mips.org
>> Signed-off-by: Michal Marek <mmarek@suse.cz>
>
> On the contrary, since NET was being selected for them indirectly
> previously, weren't they depending instead upon NET being enabled?
>
> Likewise for SCSI_NETLINK, SCSI_FC_ATTRS, and whatever was triggering
> the select upon them?
They have SCSI_FC_ATTRS=y/m and were relying on the select statements
turning this into SCSI_NETLINK=y and CONFIG_NET=y.
Michal
^ permalink raw reply
* Re: [PATCH 1/5] mips: Set CONFIG_NET=y in defconfigs
From: David Miller @ 2014-09-23 16:02 UTC (permalink / raw)
To: mmarek
Cc: sfr, rdunlap, netdev, linux-next, linux-kernel, linux-kbuild,
linux-mips
In-Reply-To: <1411487044-14071-1-git-send-email-mmarek@suse.cz>
From: Michal Marek <mmarek@suse.cz>
Date: Tue, 23 Sep 2014 17:44:00 +0200
> Commit 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK dependent on NET
> instead of selecting NET") removed what happened to be the only instance
> of 'select NET'. Defconfigs that were relying on the select now lack
> networking support.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: linux-mips@linux-mips.org
> Signed-off-by: Michal Marek <mmarek@suse.cz>
On the contrary, since NET was being selected for them indirectly
previously, weren't they depending instead upon NET being enabled?
Likewise for SCSI_NETLINK, SCSI_FC_ATTRS, and whatever was triggering
the select upon them?
I'll remember this as yet another why 'select' is to be avoided at
just about all costs.
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-09-23 16:02 UTC (permalink / raw)
To: Seth Forshee
Cc: Arend van Spriel, brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140923143124.GC19016@ubuntu-hedt>
23.09.2014 18:31, Seth Forshee пишет:
> On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote:
>> 23.09.2014 18:25, Michael Tokarev wrote:
>>> 23.09.2014 17:50, Arend van Spriel wrote:
>>>> On 09/23/14 15:44, Seth Forshee wrote:
>> []
>>>>> It's been quite some time since I used them, but I think brcmsmac_tx is
>>>>> quite noisy so you may only want to enable that if you already suspect a
>>>>> tx problem. I always find it useful to enable the mac80211 and
>>>>> mac80211_msg events too when debugging wireless, and I often enable
>>>>> cfg80211 events as well (none of these are especially verbose).
>>
>> mac80211_msg does not exist, it looks like. fwiw.
>
> Did you check your kernel's config? You need to have
> CONFIG_MAC80211_MESSAGE_TRACING enabled.
Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless,
but not net/. Rebuilt, another trace is here --
http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz
Thanks,
/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: LTP recv/recvmsg tests failing on 3.17
From: David Miller @ 2014-09-23 15:59 UTC (permalink / raw)
To: willemb; +Cc: cebbert.lkml, netdev
In-Reply-To: <CA+FuTScNSGYxWtB-D_iL_7TQO=z4r5_29-W8d=VRwh1M6Ym_UQ@mail.gmail.com>
From: Willem de Bruijn <willemb@google.com>
Date: Tue, 23 Sep 2014 10:57:41 -0400
> I think applications simply cannot assume a consistent
> return value when passing unsupported combinations
> of flags. This is undefined behavior.
Agreed.
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Sebastian Hesselbarth @ 2014-09-23 15:45 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Antoine Tenart, thomas.petazzoni, zmxu, devicetree, netdev,
linux-kernel, alexandre.belloni, jszhang
In-Reply-To: <4014272.rJbSfrLcuB@wuerfel>
On 09/23/2014 04:37 PM, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 16:29:22 Antoine Tenart wrote:
>>
>> So I had a look on other Ethernet bindings. Would you agree with
>> something like the following?
>>
>> eth0: ethernet@f7b90000 {
>> ...
>> #address-cells = <1>;
>> #size-cells = <0>;
>> phy-handle = <ðphy0>;
>>
>> ethphy0: ethernet-phy@0 {
>> reg = <0>;
>> };
>> };
>
> Yes, that looks good.
nit: ethernet-phy@0 should not be part of the ethernet controller
but either part of a separate mdio-ctrl node or a separate node itself.
AFAIKS, Berlin SoCs have internal PHYs, i.e. no MII/MDIO-pins exposed
but only MLT-3 differential pairs. At least BG2CD also can connect its
ethernet IP to a PHY capable of HDMI Ethernet Channel (HEC).
So for BG2CD this has to look something like:
eth0: ethernet@f7b90000 {
...
phy-handle = <&hec>;
};
cec: cec@f7f00baa {
compatible = "marvell,berlin-cec";
reg = <0xf7f00baa 0x1234>;
/* CEC unit contains HEC PHY */
hec: ethernet-phy {
bla;
};
}
For reference, this is what we have for MVEBU SoCs with multiple ports
per controller:
eth: ethernet-ctrl@72000 {
compatible = "marvell,orion-eth";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x72000 0x4000>;
clocks = <&gate_clk 2>;
marvell,tx-checksum-limit = <1600>;
status = "disabled";
ethernet-port@0 {
compatible = "marvell,orion-eth-port";
reg = <0>;
interrupts = <29>;
/* overwrite MAC address in bootloader */
local-mac-address = [00 00 00 00 00 00];
phy-handle = <ðphy>;
};
};
mdio: mdio-bus@72004 {
compatible = "marvell,orion-mdio";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x72004 0x84>;
interrupts = <30>;
clocks = <&gate_clk 2>;
status = "disabled";
ethphy: ethernet-phy {
/* set phy address in board file */
};
};
Sebastian
^ permalink raw reply
* [PATCH 5/5] sparc: Set CONFIG_NET=y in defconfigs
From: Michal Marek @ 2014-09-23 15:44 UTC (permalink / raw)
To: sfr, rdunlap, davem
Cc: netdev, linux-next, linux-kernel, linux-kbuild, sparclinux
In-Reply-To: <1411487044-14071-1-git-send-email-mmarek@suse.cz>
Commit 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK dependent on NET
instead of selecting NET") removed what happened to be the only instance
of 'select NET'. Defconfigs that were relying on the select now lack
networking support.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: sparclinux@vger.kernel.org
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
arch/sparc/configs/sparc64_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sparc/configs/sparc64_defconfig b/arch/sparc/configs/sparc64_defconfig
index 9d8521b..6b68f12 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -29,6 +29,7 @@ CONFIG_PCI=y
CONFIG_PCI_MSI=y
CONFIG_SUN_OPENPROMFS=m
CONFIG_BINFMT_MISC=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
--
1.8.4.5
^ permalink raw reply related
* [PATCH 4/5] sh: Set CONFIG_NET=y in defconfigs
From: Michal Marek @ 2014-09-23 15:44 UTC (permalink / raw)
To: sfr, rdunlap, davem
Cc: netdev, linux-next, linux-kernel, linux-kbuild, linux-sh
In-Reply-To: <1411487044-14071-1-git-send-email-mmarek@suse.cz>
Commit 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK dependent on NET
instead of selecting NET") removed what happened to be the only instance
of 'select NET'. Defconfigs that were relying on the select now lack
networking support.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
arch/sh/configs/sdk7780_defconfig | 1 +
arch/sh/configs/sh2007_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/sh/configs/sdk7780_defconfig b/arch/sh/configs/sdk7780_defconfig
index 6a96b9a..bbd4c22 100644
--- a/arch/sh/configs/sdk7780_defconfig
+++ b/arch/sh/configs/sdk7780_defconfig
@@ -30,6 +30,7 @@ CONFIG_PCI_DEBUG=y
CONFIG_PCCARD=y
CONFIG_YENTA=y
CONFIG_HOTPLUG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
diff --git a/arch/sh/configs/sh2007_defconfig b/arch/sh/configs/sh2007_defconfig
index e741b1e..df25ae7 100644
--- a/arch/sh/configs/sh2007_defconfig
+++ b/arch/sh/configs/sh2007_defconfig
@@ -25,6 +25,7 @@ CONFIG_CMDLINE_OVERWRITE=y
CONFIG_CMDLINE="console=ttySC1,115200 ip=dhcp root=/dev/nfs rw nfsroot=/nfs/rootfs,rsize=1024,wsize=1024 earlyprintk=sh-sci.1"
CONFIG_PCCARD=y
CONFIG_BINFMT_MISC=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=y
--
1.8.4.5
^ permalink raw reply related
* [PATCH 3/5] powerpc: Set CONFIG_NET=y in defconfigs
From: Michal Marek @ 2014-09-23 15:44 UTC (permalink / raw)
To: sfr, rdunlap, davem
Cc: netdev, linux-next, linuxppc-dev, linux-kernel, linux-kbuild
In-Reply-To: <1411487044-14071-1-git-send-email-mmarek@suse.cz>
Commit 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK dependent on NET
instead of selecting NET") removed what happened to be the only instance
of 'select NET'. Defconfigs that were relying on the select now lack
networking support.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
arch/powerpc/configs/pmac32_defconfig | 1 +
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/ppc64e_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
arch/powerpc/configs/pseries_le_defconfig | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
index 553e662..0351b5f 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -31,6 +31,7 @@ CONFIG_HIBERNATION=y
CONFIG_APM_EMULATION=y
CONFIG_PCCARD=m
CONFIG_YENTA=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=y
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index f6c02f8..3651887 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -58,6 +58,7 @@ CONFIG_ELECTRA_CF=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig
index 587f551..c3a3269 100644
--- a/arch/powerpc/configs/ppc64e_defconfig
+++ b/arch/powerpc/configs/ppc64e_defconfig
@@ -33,6 +33,7 @@ CONFIG_SPARSEMEM_MANUAL=y
CONFIG_PCI_MSI=y
CONFIG_PCCARD=y
CONFIG_HOTPLUG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 50375f1..dd2a9ca 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -53,6 +53,7 @@ CONFIG_SCHED_SMT=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/powerpc/configs/pseries_le_defconfig b/arch/powerpc/configs/pseries_le_defconfig
index 4428ee4..63392f4 100644
--- a/arch/powerpc/configs/pseries_le_defconfig
+++ b/arch/powerpc/configs/pseries_le_defconfig
@@ -55,6 +55,7 @@ CONFIG_SCHED_SMT=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
--
1.8.4.5
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* [PATCH 2/5] parisc: Set CONFIG_NET=y in defconfigs
From: Michal Marek @ 2014-09-23 15:44 UTC (permalink / raw)
To: sfr, rdunlap, davem
Cc: netdev, linux-next, linux-kernel, linux-kbuild, linux-parisc
In-Reply-To: <1411487044-14071-1-git-send-email-mmarek@suse.cz>
Commit 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK dependent on NET
instead of selecting NET") removed what happened to be the only instance
of 'select NET'. Defconfigs that were relying on the select now lack
networking support.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
arch/parisc/configs/c8000_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/parisc/configs/c8000_defconfig b/arch/parisc/configs/c8000_defconfig
index 8249ac9..269c23d 100644
--- a/arch/parisc/configs/c8000_defconfig
+++ b/arch/parisc/configs/c8000_defconfig
@@ -33,6 +33,7 @@ CONFIG_PCI_LBA=y
# CONFIG_PDC_CHASSIS_WARN is not set
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
--
1.8.4.5
^ permalink raw reply related
* [PATCH 1/5] mips: Set CONFIG_NET=y in defconfigs
From: Michal Marek @ 2014-09-23 15:44 UTC (permalink / raw)
To: sfr, rdunlap, davem
Cc: netdev, linux-next, linux-kernel, linux-kbuild, linux-mips
In-Reply-To: <54218AEF.5090200@suse.cz>
Commit 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK dependent on NET
instead of selecting NET") removed what happened to be the only instance
of 'select NET'. Defconfigs that were relying on the select now lack
networking support.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-mips@linux-mips.org
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
arch/mips/configs/gpr_defconfig | 1 +
arch/mips/configs/ip27_defconfig | 1 +
arch/mips/configs/jazz_defconfig | 1 +
arch/mips/configs/loongson3_defconfig | 1 +
arch/mips/configs/malta_defconfig | 1 +
arch/mips/configs/malta_kvm_defconfig | 1 +
arch/mips/configs/malta_kvm_guest_defconfig | 1 +
arch/mips/configs/mtx1_defconfig | 1 +
arch/mips/configs/rm200_defconfig | 1 +
9 files changed, 9 insertions(+)
diff --git a/arch/mips/configs/gpr_defconfig b/arch/mips/configs/gpr_defconfig
index 8f219da..e24feb06 100644
--- a/arch/mips/configs/gpr_defconfig
+++ b/arch/mips/configs/gpr_defconfig
@@ -19,6 +19,7 @@ CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PCI=y
CONFIG_BINFMT_MISC=m
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
index cc07560..48e16d9 100644
--- a/arch/mips/configs/ip27_defconfig
+++ b/arch/mips/configs/ip27_defconfig
@@ -28,6 +28,7 @@ CONFIG_MIPS32_COMPAT=y
CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/mips/configs/jazz_defconfig b/arch/mips/configs/jazz_defconfig
index 2575302..4f37a59 100644
--- a/arch/mips/configs/jazz_defconfig
+++ b/arch/mips/configs/jazz_defconfig
@@ -18,6 +18,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_NET_KEY=m
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 4cb787f..1c6191e 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -59,6 +59,7 @@ CONFIG_MIPS32_COMPAT=y
CONFIG_MIPS32_O32=y
CONFIG_MIPS32_N32=y
CONFIG_PM_RUNTIME=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=y
diff --git a/arch/mips/configs/malta_defconfig b/arch/mips/configs/malta_defconfig
index e18741e..f57b96d 100644
--- a/arch/mips/configs/malta_defconfig
+++ b/arch/mips/configs/malta_defconfig
@@ -19,6 +19,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/mips/configs/malta_kvm_defconfig b/arch/mips/configs/malta_kvm_defconfig
index cf0e01f..d41742d 100644
--- a/arch/mips/configs/malta_kvm_defconfig
+++ b/arch/mips/configs/malta_kvm_defconfig
@@ -20,6 +20,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/mips/configs/malta_kvm_guest_defconfig b/arch/mips/configs/malta_kvm_guest_defconfig
index edd9ec9..a7806e8 100644
--- a/arch/mips/configs/malta_kvm_guest_defconfig
+++ b/arch/mips/configs/malta_kvm_guest_defconfig
@@ -19,6 +19,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PCI=y
+CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/mips/configs/mtx1_defconfig b/arch/mips/configs/mtx1_defconfig
index d269a53..9b6926d 100644
--- a/arch/mips/configs/mtx1_defconfig
+++ b/arch/mips/configs/mtx1_defconfig
@@ -27,6 +27,7 @@ CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_XFRM_USER=m
diff --git a/arch/mips/configs/rm200_defconfig b/arch/mips/configs/rm200_defconfig
index 29d79ae..db029f4 100644
--- a/arch/mips/configs/rm200_defconfig
+++ b/arch/mips/configs/rm200_defconfig
@@ -20,6 +20,7 @@ CONFIG_MODVERSIONS=y
CONFIG_PCI=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
+CONFIG_NET=y
CONFIG_PACKET=m
CONFIG_UNIX=y
CONFIG_NET_KEY=m
--
1.8.4.5
^ permalink raw reply related
* Re: LTP recv/recvmsg tests failing on 3.17
From: Chuck Ebbert @ 2014-09-23 15:39 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development
In-Reply-To: <CA+FuTScNSGYxWtB-D_iL_7TQO=z4r5_29-W8d=VRwh1M6Ym_UQ@mail.gmail.com>
On Tue, 23 Sep 2014 10:57:41 -0400
Willem de Bruijn <willemb@google.com> wrote:
> I think applications simply cannot assume a consistent
> return value when passing unsupported combinations
> of flags. This is undefined behavior.
Yeah, I think LTP is wrong here. There is no explicit test for invalid
combinations of flags and it was assuming there was.
But I was also wondering why we return EAGAIN here for no data waiting,
when we return EINVAL for the same case with a different type of data.
There's no spec and it's not documented, so I guess the answer is "it's
always been that way."
^ permalink raw reply
* Re: ip6_udp_tunnel fails to load
From: Eric Dumazet @ 2014-09-23 15:39 UTC (permalink / raw)
To: Eyal perry; +Cc: Andy Zhou, netdev, Or Gerlitz, Amir Vadai
In-Reply-To: <54218FED.4080102@dev.mellanox.co.il>
On Tue, 2014-09-23 at 18:21 +0300, Eyal perry wrote:
> Hello Andy,
>
> Lately I've start to observe a phenomena where the mlx4_en driver
> couldn't load on my system as a result of an 'Unknown symbol in module'.
>
> [ 1277.458715] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
> [ 1277.486810] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
>
> Apparently, the mlx4_en driver is depend on the vxlan driver, which
> depends on the ip6_udp_tunnel module which fails to load.
>
> 1. I've bisected this issue down to the following commit:
> fd38441 udp_tunnel: Seperate ipv6 functions into its own file.
>
> 2. on a different host with a different .config, the module is loads
> cleanly.
>
> 3. my sources are based on net-next commit
> 6d967f8 udp_tunnel: Only build ip6_udp_tunnel.c when IPV6 is selected
>
> I'll send you both of the .config files in a private message.
>
> This issue is making any driver which is depend on vxlan/ip6_udp_tunnel
> unusable, please take a look and fix
Have you tried this patch ?
https://patchwork.ozlabs.org/patch/392275/
Thanks
^ permalink raw reply
* Re: [PATCH net-next 04/14] tipc: add sock dump to new netlink api
From: David Miller @ 2014-09-23 15:37 UTC (permalink / raw)
To: richard.alpe; +Cc: netdev, tipc-discussion
In-Reply-To: <542155AF.4020805@ericsson.com>
From: Richard Alpe <richard.alpe@ericsson.com>
Date: Tue, 23 Sep 2014 13:12:47 +0200
> Ideally I would like to use the existing dump framework .dumpit
> (netlink_dump_start()) but I can't figure out a way to pass the socket
> for which to dump publications. I really don't want to reinvent the
> dumping mechanism. Any suggestions?
Look at inet_diag, and how the dump netlink request passes in a key
to match upon.
The key is of the form: include/uapi/linux/inet_diag.h:inet_diag_req{,_v2}
^ permalink raw reply
* Re: [patch net-next v2 8/9] switchdev: introduce Netlink API
From: Or Gerlitz @ 2014-09-23 15:32 UTC (permalink / raw)
To: Andy Gospodarek, Tom Herbert
Cc: Alexei Starovoitov, Thomas Graf, Jiri Pirko, John Fastabend,
Jamal Hadi Salim, netdev@vger.kernel.org, David S. Miller,
Neil Horman, Andy Gospodarek, Daniel Borkmann, Jesse Gross,
Pravin Shelar, Andy Zhou, Ben Hutchings, Stephen Hemminger,
Jeff Kirsher, Vladislav Yasevich, Cong Wang, Eric Dumazet,
Scott Feldman, Florian Fainelli, Roopa Prabhu, Joh
In-Reply-To: <20140923041130.GA10808@gospo.home.greyhouse.net>
On 9/23/2014 7:11 AM, Andy Gospodarek wrote:
> On Mon, Sep 22, 2014 at 07:16:47PM -0700, Tom Herbert wrote:
> [...]
>> Alexei, I believe you said previously said that SW should not dictate
>> HW models. I agree with this, but also believe the converse is true--
>> HW shouldn't dictate SW model. This is really why I'm raising the
>> question of what it means to integrate a switch into the host stack.
> Tom, when I read this I cannot help but remind myself that the
> intentions/hopes/dreams of those on this thread and how different their
> views can be on what it means to add additional 'offload support' to the
> kernel.
>
> There are clearly some that are most interested in how an eSwitch on an
> SR-IOV capable NIC be controlled can provide traditional forwarding help
> as well as offload the various technologies they hope to terminate
> at/inside their endpoint (host/guest/container) -- Thomas's _simple_
> use-case demonstrates this. ;) This is a logical extention/increase in
> functionality that is offered in many eSwitches that was previously
> hidden from the user with the first generation SR-IOV capable network
> devices on hosts/servers.
Indeed.
The idea is to leverage OVS to manage eSwitch (embedded NIC switch) as
well (NOT to offload OVS).
We envision a seamless integration of user environment which is based on
OVS with SRIOV eSwitch and the grounds for that were very well supported
in Jiri’s V1.
The eSwitch hardware does not need to have multiple tables and ‘enjoys’
the flat rule of OVS. The kernel datapath does not need to be aware of
the existence of HW nor its capabilities, it just pushes the flow also
to the switchdev which represents the eSwitch.
If the flow can be supported in HW it will be forwarded in HW and if not
it will be forwarded by the kernel
> [....]
>
> And now we also have the patchset that spawned what I think has been
> more excellent discussion. Jiri and Scott's patches bring up another,
> more generic model that while not currently backed by hardware provided
> an example/vision for what could be done if such hardware existed and
> how to consider interacting with that driver/hardware (that clearly has
> been met with some resistance, but the discussion has been great).
> There ultimate goals appear to be similar to those that want full
> offload/fordwarding support for a device, but via a different method
> than what some would consider standard.
>
> I am personally hopeful that most who are passionate about this will be
> able to get together next month at LPC (or send someone to represent
> them!) so that those interested can sit in the same room and try to
> better understand each others desires and start to form some concrete
> direction towards a solution that seems to meet the needs of most while
> not being an architectural disaster.
>
Yep. LPC is the time and place to go over the multiple use-cases
(phyiscal switch, eSwitch, eBPF, etc) that could (should) be supported
by the basic framework.
Or.
^ permalink raw reply
* Re: [PATCHv2] ipv4: Do not cache routing failures due to disabled forwarding.
From: David Miller @ 2014-09-23 15:28 UTC (permalink / raw)
To: Nicolas.Cavallari; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <54213080.9000803@green-communications.fr>
From: Nicolas Cavallari <Nicolas.Cavallari@green-communications.fr>
Date: Tue, 23 Sep 2014 10:34:08 +0200
> Any news on this patch ? Is there anything I can do so that this bug
> is finally fixed ?
Getting back to this is on my TODO list, I haven't forgotten about
it, thanks :)
^ permalink raw reply
* ip6_udp_tunnel fails to load
From: Eyal perry @ 2014-09-23 15:21 UTC (permalink / raw)
To: Andy Zhou; +Cc: netdev, Or Gerlitz, Amir Vadai
Hello Andy,
Lately I've start to observe a phenomena where the mlx4_en driver
couldn't load on my system as a result of an 'Unknown symbol in module'.
[ 1277.458715] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
[ 1277.486810] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
Apparently, the mlx4_en driver is depend on the vxlan driver, which
depends on the ip6_udp_tunnel module which fails to load.
1. I've bisected this issue down to the following commit:
fd38441 udp_tunnel: Seperate ipv6 functions into its own file.
2. on a different host with a different .config, the module is loads
cleanly.
3. my sources are based on net-next commit
6d967f8 udp_tunnel: Only build ip6_udp_tunnel.c when IPV6 is selected
I'll send you both of the .config files in a private message.
This issue is making any driver which is depend on vxlan/ip6_udp_tunnel
unusable, please take a look and fix
Best Regards,
Eyal.
^ permalink raw reply
* Re: [PATCH] ath: change logging functions to return void
From: Kalle Valo @ 2014-09-23 15:17 UTC (permalink / raw)
To: John W. Linville
Cc: Joe Perches, Vladimir Kondratiev, ath10k, linux-wireless, netdev,
linux-kernel, wil6210, ath6kl
In-Reply-To: <20140923144627.GG23806@tuxdriver.com>
"John W. Linville" <linville@tuxdriver.com> writes:
> On Tue, Sep 23, 2014 at 07:20:53AM +0300, Kalle Valo wrote:
>> Joe Perches <joe@perches.com> writes:
>>
>> > drivers/net/wireless/ath/wil6210/debug.c | 14 ++++----------
>> > drivers/net/wireless/ath/wil6210/wil6210.h | 7 +++++--
>> > 7 files changed, 32 insertions(+), 56 deletions(-)
>>
>> John, as this patch also contains a wil6210 change how do you want to
>> handle this?
>
> I had presumed that you would merge it through the ath tree, so I
> deleted it...
That's a clear case then, I'll take it :)
--
Kalle Valo
^ permalink raw reply
* pull request: wireless 2014-09-23
From: John W. Linville @ 2014-09-23 15:00 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6634 bytes --]
Dave,
Please consider pulling this one last batch of fixes intended for the 3.17 stream!
For the NFC bits, Samuel says:
"Hopefully not too late for a handful of NFC fixes:
- 2 potential build failures for ST21NFCA and ST21NFCB, triggered by a
depmod dependenyc cycle.
- One potential buffer overflow in the microread driver."
On top of that...
Emil Goode provides a fix for a brcmfmac off-by-one regression which
was introduced in the 3.17 cycle.
Loic Poulain fixes a polarity mismatch for a variable assignment
inside of rfkill-gpio.
Wojciech Dubowik prevents a NULL pointer dereference in ath9k.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit dda3b191eb6c5a56d443723dcb71ade60d97c04f:
net: rfkill: gpio: Enable module auto-loading for ACPI based switches (2014-09-16 16:09:01 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git tags/master-2014-09-23
for you to fetch changes up to f8adaf0ae978252c9f7e29e96aefcd8fcaf806ba:
brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels() (2014-09-23 10:48:26 -0400)
----------------------------------------------------------------
Christophe Ricard (2):
NFC: st21nfcb: Fix depmod dependency cycle
NFC: st21nfca: Fix potential depmod dependency cycle
Dan Carpenter (1):
NFC: microread: Potential overflows in microread_target_discovered()
Emil Goode (1):
brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()
John W. Linville (1):
Merge tag 'nfc-fixes-3.17-1' of git://git.kernel.org/.../sameo/nfc-fixes
Loic Poulain (1):
net: rfkill: gpio: Fix clock status
Wojciech Dubowik (1):
ath9k: Fix NULL pointer dereference on early irq
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 2 +-
drivers/nfc/microread/microread.c | 16 ++++++++++++----
drivers/nfc/st21nfca/Makefile | 5 +++--
drivers/nfc/st21nfcb/Makefile | 5 +++--
net/rfkill/rfkill-gpio.c | 2 +-
6 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index e6ac8d2e610c..4b148bbb2bf6 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -513,7 +513,7 @@ irqreturn_t ath_isr(int irq, void *dev)
* touch anything. Note this can happen early
* on if the IRQ is shared.
*/
- if (test_bit(ATH_OP_INVALID, &common->op_flags))
+ if (!ah || test_bit(ATH_OP_INVALID, &common->op_flags))
return IRQ_NONE;
/* shared irq, not for us */
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index f3a9804988a6..16a246bfc343 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -4921,7 +4921,7 @@ static void brcmf_count_20mhz_channels(struct brcmf_cfg80211_info *cfg,
struct brcmu_chan ch;
int i;
- for (i = 0; i <= total; i++) {
+ for (i = 0; i < total; i++) {
ch.chspec = (u16)le32_to_cpu(chlist->element[i]);
cfg->d11inf.decchspec(&ch);
diff --git a/drivers/nfc/microread/microread.c b/drivers/nfc/microread/microread.c
index f868333271aa..963a4a5dc88e 100644
--- a/drivers/nfc/microread/microread.c
+++ b/drivers/nfc/microread/microread.c
@@ -501,9 +501,13 @@ static void microread_target_discovered(struct nfc_hci_dev *hdev, u8 gate,
targets->sens_res =
be16_to_cpu(*(u16 *)&skb->data[MICROREAD_EMCF_A_ATQA]);
targets->sel_res = skb->data[MICROREAD_EMCF_A_SAK];
- memcpy(targets->nfcid1, &skb->data[MICROREAD_EMCF_A_UID],
- skb->data[MICROREAD_EMCF_A_LEN]);
targets->nfcid1_len = skb->data[MICROREAD_EMCF_A_LEN];
+ if (targets->nfcid1_len > sizeof(targets->nfcid1)) {
+ r = -EINVAL;
+ goto exit_free;
+ }
+ memcpy(targets->nfcid1, &skb->data[MICROREAD_EMCF_A_UID],
+ targets->nfcid1_len);
break;
case MICROREAD_GATE_ID_MREAD_ISO_A_3:
targets->supported_protocols =
@@ -511,9 +515,13 @@ static void microread_target_discovered(struct nfc_hci_dev *hdev, u8 gate,
targets->sens_res =
be16_to_cpu(*(u16 *)&skb->data[MICROREAD_EMCF_A3_ATQA]);
targets->sel_res = skb->data[MICROREAD_EMCF_A3_SAK];
- memcpy(targets->nfcid1, &skb->data[MICROREAD_EMCF_A3_UID],
- skb->data[MICROREAD_EMCF_A3_LEN]);
targets->nfcid1_len = skb->data[MICROREAD_EMCF_A3_LEN];
+ if (targets->nfcid1_len > sizeof(targets->nfcid1)) {
+ r = -EINVAL;
+ goto exit_free;
+ }
+ memcpy(targets->nfcid1, &skb->data[MICROREAD_EMCF_A3_UID],
+ targets->nfcid1_len);
break;
case MICROREAD_GATE_ID_MREAD_ISO_B:
targets->supported_protocols = NFC_PROTO_ISO14443_B_MASK;
diff --git a/drivers/nfc/st21nfca/Makefile b/drivers/nfc/st21nfca/Makefile
index db7a38ae05f7..7d688f97aa27 100644
--- a/drivers/nfc/st21nfca/Makefile
+++ b/drivers/nfc/st21nfca/Makefile
@@ -2,7 +2,8 @@
# Makefile for ST21NFCA HCI based NFC driver
#
-st21nfca_i2c-objs = i2c.o
+st21nfca_hci-objs = st21nfca.o st21nfca_dep.o
+obj-$(CONFIG_NFC_ST21NFCA) += st21nfca_hci.o
-obj-$(CONFIG_NFC_ST21NFCA) += st21nfca.o st21nfca_dep.o
+st21nfca_i2c-objs = i2c.o
obj-$(CONFIG_NFC_ST21NFCA_I2C) += st21nfca_i2c.o
diff --git a/drivers/nfc/st21nfcb/Makefile b/drivers/nfc/st21nfcb/Makefile
index 13d9f03b2fea..f4d835dd15f2 100644
--- a/drivers/nfc/st21nfcb/Makefile
+++ b/drivers/nfc/st21nfcb/Makefile
@@ -2,7 +2,8 @@
# Makefile for ST21NFCB NCI based NFC driver
#
-st21nfcb_i2c-objs = i2c.o
+st21nfcb_nci-objs = ndlc.o st21nfcb.o
+obj-$(CONFIG_NFC_ST21NFCB) += st21nfcb_nci.o
-obj-$(CONFIG_NFC_ST21NFCB) += st21nfcb.o ndlc.o
+st21nfcb_i2c-objs = i2c.o
obj-$(CONFIG_NFC_ST21NFCB_I2C) += st21nfcb_i2c.o
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 5fa54dd78e25..0f62326c0f5e 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -54,7 +54,7 @@ static int rfkill_gpio_set_power(void *data, bool blocked)
if (blocked && !IS_ERR(rfkill->clk) && rfkill->clk_enabled)
clk_disable(rfkill->clk);
- rfkill->clk_enabled = blocked;
+ rfkill->clk_enabled = !blocked;
return 0;
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: linux-next: build warning after merge of the net tree
From: Michal Marek @ 2014-09-23 14:59 UTC (permalink / raw)
To: Randy Dunlap, Stephen Rothwell, David Miller, netdev
Cc: linux-next, linux-kernel, linux-kbuild
In-Reply-To: <541A28BA.1060201@infradead.org>
On 2014-09-18 02:35, Randy Dunlap wrote:
> On 09/17/14 17:32, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the net tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced these warnings:
>>
>> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
>>
>
> I have looked into these and don't see why there is a problem.
> Any help would be appreciated.
This is a side effect of 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK
dependent on NET instead of selecting NET"). Previously, SCSI_FC_ATTRS
would select SCSI_NETLINK which would select CONFIG_NET. The above
warnings are just a tip of the iceberg, the more serious issue is that
ppc64_defconfig is lacking networking support. This is the downside of
savedefconfig, because the 'select' implications can disappear over
time. Looks like more defconfigs are affected by this:
$ grep -rL CONFIG_NET= arch/*/configs/ | xargs grep -l CONFIG_SCSI_FC_ATTRS=
arch/ia64/configs/generic_defconfig
arch/ia64/configs/gensparse_defconfig
arch/mips/configs/ip27_defconfig
arch/mips/configs/malta_defconfig
arch/mips/configs/rm200_defconfig
arch/mips/configs/malta_kvm_guest_defconfig
arch/mips/configs/gpr_defconfig
arch/mips/configs/jazz_defconfig
arch/mips/configs/mtx1_defconfig
arch/mips/configs/malta_kvm_defconfig
arch/mips/configs/loongson3_defconfig
arch/parisc/configs/c8000_defconfig
arch/powerpc/configs/pseries_defconfig
arch/powerpc/configs/pseries_le_defconfig
arch/powerpc/configs/ppc64e_defconfig
arch/powerpc/configs/ppc64_defconfig
arch/powerpc/configs/pmac32_defconfig
arch/sh/configs/sh2007_defconfig
arch/sh/configs/sdk7780_defconfig
arch/sparc/configs/sparc64_defconfig
Michal
^ permalink raw reply
* Re: LTP recv/recvmsg tests failing on 3.17
From: Willem de Bruijn @ 2014-09-23 14:57 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Network Development
In-Reply-To: <20140923091108.2788de76@as>
On Tue, Sep 23, 2014 at 10:11 AM, Chuck Ebbert <cebbert.lkml@gmail.com> wrote:
> LTP tests recv01, recvfrom01 and recvmsg01 are reporting failure on
> their "invalid flags" tests on 3.17. They pass a value of -1 for flags
> and expect to get EINVAL back, but now they get EAGAIN.
..
>
> Before this change, the first flag tested was MSG_OOB, which eventually
> causes EINVAL to be returned. Now this flag gets tested first, and
> ip_recv_err() returns EAGAIN.
>
> LTP setting every flag and expecting behavior to remain unchanged is
> probably wrong, but is EAGAIN correct here? I can't find any spec for
> this.
EINVAL does seem a suitable return value for invalid
combinations of flags, if those are explicitly checked. The
stack does not do this, though. Most flags are simply
ignored. For backward compatibility, this leniency is
likely required.
Previously, EINVAL was returned, but not because msg_flags
contained an unsupported combination. MSG_OOB happened
to be the first tested flag in the set and happens to return
EINVAL when no urgent data is waiting.
I think applications simply cannot assume a consistent
return value when passing unsupported combinations
of flags. This is undefined behavior.
^ permalink raw reply
* Re: [PATCH] ath: change logging functions to return void
From: John W. Linville @ 2014-09-23 14:46 UTC (permalink / raw)
To: Kalle Valo
Cc: Joe Perches, Vladimir Kondratiev, ath10k, linux-wireless, netdev,
linux-kernel, wil6210, ath6kl
In-Reply-To: <874mvzj7bu.fsf@kamboji.qca.qualcomm.com>
On Tue, Sep 23, 2014 at 07:20:53AM +0300, Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
>
> > The return values are not used by callers of these functions
> > so change the functions to return void.
> >
> > Other miscellanea:
> >
> > o add __printf verification to wil6210 logging functions
> > No format/argument mismatches found
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> > This change is associated to a desire to eventually
> > change printk to return void.
> >
> > drivers/net/wireless/ath/ath10k/debug.c | 18 +++++-------------
> > drivers/net/wireless/ath/ath10k/debug.h | 6 +++---
> > drivers/net/wireless/ath/ath6kl/common.h | 2 +-
> > drivers/net/wireless/ath/ath6kl/debug.c | 28 ++++++++--------------------
> > drivers/net/wireless/ath/ath6kl/debug.h | 13 ++++++-------
>
> For ath6kl and ath10k:
>
> Acked-by: Kalle Valo <kvalo@qca.qualcomm.com>
>
> > drivers/net/wireless/ath/wil6210/debug.c | 14 ++++----------
> > drivers/net/wireless/ath/wil6210/wil6210.h | 7 +++++--
> > 7 files changed, 32 insertions(+), 56 deletions(-)
>
> John, as this patch also contains a wil6210 change how do you want to
> handle this?
I had presumed that you would merge it through the ath tree, so I
deleted it...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Antoine Tenart @ 2014-09-23 14:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Antoine Tenart, sebastian.hesselbarth, alexandre.belloni,
thomas.petazzoni, zmxu, jszhang, netdev, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <3708177.kEGF9Dk44n@wuerfel>
On Tue, Sep 23, 2014 at 04:33:48PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 16:01:13 Antoine Tenart wrote:
> >
> > On Tue, Sep 23, 2014 at 02:38:39PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 23 September 2014 14:15:30 Antoine Tenart wrote:
> > > > +Optional properties:
> > > > +- port-id: should be '0','1' or '2'.
> > > > +- phy-addr: MDIO address of the PHY.
> > > > +- local-mac-address: see ethernet.txt file in the same directory.
> > > > +
> > > >
> > >
> > > I believe new bindings should not use "phy-addr" properties, but
> > > instead use a phy-handle property pointing to a phy device instead.
> >
> > That's the MDIO address of the PHY. It's a bit difficult to use a phy
> > device as the driver uses the libphy. And that would break the platform
> > using it.
> >
> > Or maybe you have something in mind?
>
> I don't understand what you mean. Doesn't libphy imply using a phy_device?
> What I meant was that you should be able to just call the standard
> of_phy_connect() and other interfaces to deal with phylib.
>
Yes sure, I read again my answer and... well I should have had a better
look on the matter.
Anyway, as the proposed binding seems to be OK with you, I'll update the
series accordingly.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-23 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Antoine Tenart, thomas.petazzoni, zmxu, devicetree, netdev,
linux-kernel, alexandre.belloni, jszhang, sebastian.hesselbarth
In-Reply-To: <20140923142922.GE18924@kwain>
On Tuesday 23 September 2014 16:29:22 Antoine Tenart wrote:
>
> So I had a look on other Ethernet bindings. Would you agree with
> something like the following?
>
> eth0: ethernet@f7b90000 {
> ...
> #address-cells = <1>;
> #size-cells = <0>;
> phy-handle = <ðphy0>;
>
> ethphy0: ethernet-phy@0 {
> reg = <0>;
> };
> };
Yes, that looks good.
Arnd
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-23 14:33 UTC (permalink / raw)
To: Antoine Tenart
Cc: sebastian.hesselbarth, alexandre.belloni, thomas.petazzoni, zmxu,
jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20140923140113.GC18924@kwain>
On Tuesday 23 September 2014 16:01:13 Antoine Tenart wrote:
>
> On Tue, Sep 23, 2014 at 02:38:39PM +0200, Arnd Bergmann wrote:
> > On Tuesday 23 September 2014 14:15:30 Antoine Tenart wrote:
> > > +Optional properties:
> > > +- port-id: should be '0','1' or '2'.
> > > +- phy-addr: MDIO address of the PHY.
> > > +- local-mac-address: see ethernet.txt file in the same directory.
> > > +
> > >
> >
> > I believe new bindings should not use "phy-addr" properties, but
> > instead use a phy-handle property pointing to a phy device instead.
>
> That's the MDIO address of the PHY. It's a bit difficult to use a phy
> device as the driver uses the libphy. And that would break the platform
> using it.
>
> Or maybe you have something in mind?
I don't understand what you mean. Doesn't libphy imply using a phy_device?
What I meant was that you should be able to just call the standard
of_phy_connect() and other interfaces to deal with phylib.
Arnd
^ 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