* Re: [PATCH net-next 0/2] fix two more udp pull header issues
From: Willem de Bruijn @ 2016-04-14 2:57 UTC (permalink / raw)
To: David Miller
Cc: Network Development, Tom Herbert, Sam Kumar, Willem de Bruijn
In-Reply-To: <20160413.222554.1942915187151383805.davem@davemloft.net>
On Wed, Apr 13, 2016 at 10:25 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Thu, 7 Apr 2016 18:12:57 -0400
>
>> Follow up patches to the fixes to RxRPC and SunRPC. A scan of the
>> code showed two other interfaces that expect UDP packets to have
>> a udphdr when queued: read packet length with ioctl SIOCINQ and
>> receive payload checksum with socket option IP_CHECKSUM.
>
> As we are seeing, lots of places depend upon the old way of queueing
> up UDP frames. :-/
Yes, I greatly underestimated that. I should have done a much more
thorough scan before submitting. Hopefully we've caught them all now.
> Applied, thanks for mopping all of this up.
Apologies for breaking it in the first place!
^ permalink raw reply
* Re: [PATCH] drivers/net/ethernet/jme.c: Deinline jme_reset_mac_processor, save 2816 bytes
From: David Miller @ 2016-04-14 2:57 UTC (permalink / raw)
To: dvlasenk; +Cc: linux-kernel, netdev
In-Reply-To: <1460140787-12610-1-git-send-email-dvlasenk@redhat.com>
From: Denys Vlasenko <dvlasenk@redhat.com>
Date: Fri, 8 Apr 2016 20:39:47 +0200
> This function compiles to 895 bytes of machine code.
>
> Clearly, this isn't a time-critical function.
> For one, it has a number of udelay(1) calls.
>
> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
No x.c file should be using inline anyways, applied to net-next,
thanks a lot!
^ permalink raw reply
* Re: [PATCH net-next v3] packet: uses kfree_skb() for errors.
From: David Miller @ 2016-04-14 2:56 UTC (permalink / raw)
To: weongyo.linux; +Cc: netdev, willemb
In-Reply-To: <1460132748-23561-1-git-send-email-weongyo.linux@gmail.com>
From: Weongyo Jeong <weongyo.linux@gmail.com>
Date: Fri, 8 Apr 2016 09:25:48 -0700
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 1ecfa71..4e054bb 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -2042,6 +2042,7 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
> u8 *skb_head = skb->data;
> int skb_len = skb->len;
> unsigned int snaplen, res;
> + bool err = false;
>
> if (skb->pkt_type == PACKET_LOOPBACK)
> goto drop;
It is non-canonical to use a variable named 'err' as a boolean.
Instead, all programmers expect a variable named 'err' to be an
integer type and to hold an error code.
Therefore please use a more appropriate name for this variable.
Name it in a way which describes the exact important condition
which is true or false.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: stmmac: GMAC4.xx: Fix TX descriptor preparation
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: alexandre.torgue; +Cc: netdev, peppe.cavallaro, dan.carpenter, kernel-janitors
In-Reply-To: <1460107083-25577-1-git-send-email-alexandre.torgue@st.com>
From: Alexandre TORGUE <alexandre.torgue@st.com>
Date: Fri, 8 Apr 2016 11:18:03 +0200
> On GMAC4.xx each descriptor contains 2 buffers of 16KB (each).
> Initially, those 2 buffers was filled in dwmac4_rd_prepare_tx_desc but
> it is actually not needed. Indeed, stmmac driver supports frame up to
> 9000 bytes (jumbo). So only one buffer is needed.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH RESEND] net: ethernet: renesas: ravb_main: test clock rate to avoid division by 0
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: wsa; +Cc: netdev, linux-renesas-soc, sergei.shtylyov
In-Reply-To: <1460114922-4148-1-git-send-email-wsa@the-dreams.de>
From: Wolfram Sang <wsa@the-dreams.de>
Date: Fri, 8 Apr 2016 13:28:42 +0200
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> The clk API may return 0 on clk_get_rate, so we should check the result before
> using it as a divisor.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sock: tigthen lockdep checks for sock_owned_by_user
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-cifs-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1460121087-2859-1-git-send-email-hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
From: Hannes Frederic Sowa <hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
Date: Fri, 8 Apr 2016 15:11:27 +0200
> sock_owned_by_user should not be used without socket lock held. It seems
> to be a common practice to check .owned before lock reclassification, so
> provide a little help to abstract this check away.
>
> Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Hannes Frederic Sowa <hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6, token: allow for clearing the current device token
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: daniel; +Cc: hannes, robbat2, netdev
In-Reply-To: <307b4d32099f606d0fbe0ce9fecd3a039b796361.1460123261.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 8 Apr 2016 15:55:00 +0200
> The original tokenized iid support implemented via f53adae4eae5 ("net: ipv6:
> add tokenized interface identifier support") didn't allow for clearing a
> device token as it was intended that this addressing mode was the only one
> active for globally scoped IPv6 addresses. Later we relaxed that restriction
> via 617fe29d45bd ("net: ipv6: only invalidate previously tokenized addresses"),
> and we should also allow for clearing tokens as there's no good reason why
> it shouldn't be allowed.
>
> Fixes: 617fe29d45bd ("net: ipv6: only invalidate previously tokenized addresses")
> Reported-by: Robin H. Johnson <robbat2@gentoo.org>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] [linux-next] Doc: networking: Fix typo in dsa
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: standby24x7; +Cc: linux-kernel, corbet, linux-doc, netdev
In-Reply-To: <1460127625-6956-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Sat, 9 Apr 2016 00:00:25 +0900
> This patch fix typos in Documentation/networking/dsa.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: force inlining of netif_tx_start/stop_queue, sock_hold, __sock_put
From: David Miller @ 2016-04-14 2:43 UTC (permalink / raw)
To: dvlasenk; +Cc: linux-kernel, netdev, netfilter-devel
In-Reply-To: <1460130714-7779-1-git-send-email-dvlasenk@redhat.com>
From: Denys Vlasenko <dvlasenk@redhat.com>
Date: Fri, 8 Apr 2016 17:51:54 +0200
> Sometimes gcc mysteriously doesn't inline
> very small functions we expect to be inlined. See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
> Arguably, gcc should do better, but gcc people aren't willing
> to invest time into it, asking to use __always_inline instead.
>
> With this .config:
> http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
> the following functions get deinlined many times.
...
> This patch fixes this via s/inline/__always_inline/.
>
> Code size decrease after the patch is ~2.5k:
>
> text data bss dec hex filename
> 56719876 56364551 36196352 149280779 8e5d80b vmlinux_before
> 56717440 56364551 36196352 149278343 8e5ce87 vmlinux
>
> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCHv3 net-next 0/6] bridge: support sending rntl info when we set attributes through sysfs/ioctl
From: David Miller @ 2016-04-14 2:42 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, bridge, nikolay
In-Reply-To: <cover.1460131308.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 9 Apr 2016 00:03:27 +0800
> This patchset is used to support sending rntl info to user in some places,
> and ensure that whenever those attributes change internally or from sysfs,
> that a netlink notification is sent out to listeners.
>
> It also make some adjustment in bridge sysfs so that we can implement this
> easily.
>
> I've done some tests on this patchset, like:
...
> This test covers all the attributes that brctl and sysfs support to set.
Series applied, thanks.
^ permalink raw reply
* Urgent Loans!
From: Fidelity Mortgage Loan @ 2016-04-13 23:19 UTC (permalink / raw)
To: Recipients
Loan Offer at 3%, Feel Free to REPLY back to us for more info
^ permalink raw reply
* [PATCH V3 00/29] bitops: add parity functions
From: zengzhaoxiu @ 2016-04-14 2:36 UTC (permalink / raw)
To: linux-kernel
Cc: Zhaoxiu Zeng, adi-buildroot-devel, Andrew Morton, Anton Blanchard,
Arnd Bergmann, Benjamin Tissoires, Borislav Petkov, Bruce Allan,
Christophe Leroy, David Herrmann, David S. Miller, Denys Vlasenko,
Dmitry Torokhov, Duson Lin, Guenter Roeck, Hans de Goede,
Hans Verkuil, Hartmut Knaack, Heiko Carstens, H
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
When I do "grep parity -r linux", I found many parity calculations
distributed in many drivers.
This patch series does:
1. provide generic and architecture-specific parity calculations
2. remove drivers' local parity calculations, use bitops' parity
functions instead
3. replace "hweightN(x) & 1" with "parityN(x)" to improve readability,
and improve performance on some CPUs that without popcount support
I did not use GCC's __builtin_parity* functions, based on the following reasons:
1. I don't know where to identify which version of GCC from the beginning
supported __builtin_parity for the architecture.
2. For the architecture that doesn't has popcount instruction, GCC instead use
"call __paritysi2" (__paritydi2 for 64-bits). So if use __builtin_parity, we must
provide __paritysi2 and __paritydi2 functions for these architectures.
Additionally, parity4,8,16 might be "__builtin_parity(x & mask)", but the "& mask"
operation is totally unnecessary.
3. For the architecture that has popcount instruction, we do the same things.
4. For powerpc, sparc, and x86, we do runtime patching to use popcount instruction
if the CPU support.
I have compiled successfully with x86_64_defconfig, i386_defconfig, pseries_defconfig
and sparc64_defconfig.
Changes to v2:
- Add constant PARITY_MAGIC (proposals by Sam Ravnborg)
- Add include/asm-generic/bitops/popc-parity.h (proposals by Chris Metcalf)
- Tile uses popc-parity.h directly
- Mips uses popc-parity.h if has usable __builtin_popcount
- Add few comments in powerpc's and sparc's parity.S
- X86, remove custom calling convention
Changes to v1:
- Add runtime patching for powerpc, sparc, and x86
- Avr32 use grenric parity too
- Fix error in ssfdc's patch, and add commit message
- Don't change the original code composition of drivers/iio/gyro/adxrs450.c
- Directly assignement to phy_cap.parity in drivers/scsi/isci/phy.c
Regards,
=== diffstat ===
Zhaoxiu Zeng (29):
bitops: add parity functions
Include generic parity.h in some architectures' bitops.h
Add alpha-specific parity functions
Add blackfin-specific parity functions
Add ia64-specific parity functions
Tile and MIPS (if has usable __builtin_popcount) use popcount parity
functions
Add powerpc-specific parity functions
Add sparc-specific parity functions
Add x86-specific parity functions
sunrpc: use parity8
mips: use parity functions in cerr-sb1.c
bch: use parity32
media: use parity8 in vivid-vbi-gen.c
media: use parity functions in saa7115
input: use parity32 in grip_mp
input: use parity64 in sidewinder
input: use parity16 in ams_delta_serio
scsi: use parity32 in isci's phy
mtd: use parity16 in ssfdc
mtd: use parity functions in inftlcore
crypto: use parity functions in qat_hal
mtd: use parity16 in sm_ftl
ethernet: use parity8 in sun/niu.c
input: use parity8 in pcips2
input: use parity8 in sa1111ps2
iio: use parity32 in adxrs450
serial: use parity32 in max3100
input: use parity8 in elantech
ethernet: use parity8 in broadcom/tg3.c
arch/alpha/include/asm/bitops.h | 27 +++++
arch/arc/include/asm/bitops.h | 1 +
arch/arm/include/asm/bitops.h | 1 +
arch/arm64/include/asm/bitops.h | 1 +
arch/avr32/include/asm/bitops.h | 1 +
arch/blackfin/include/asm/bitops.h | 31 ++++++
arch/c6x/include/asm/bitops.h | 1 +
arch/cris/include/asm/bitops.h | 1 +
arch/frv/include/asm/bitops.h | 1 +
arch/h8300/include/asm/bitops.h | 1 +
arch/hexagon/include/asm/bitops.h | 1 +
arch/ia64/include/asm/bitops.h | 31 ++++++
arch/m32r/include/asm/bitops.h | 1 +
arch/m68k/include/asm/bitops.h | 1 +
arch/metag/include/asm/bitops.h | 1 +
arch/mips/include/asm/bitops.h | 7 ++
arch/mips/mm/cerr-sb1.c | 67 ++++---------
arch/mn10300/include/asm/bitops.h | 1 +
arch/openrisc/include/asm/bitops.h | 1 +
arch/parisc/include/asm/bitops.h | 1 +
arch/powerpc/include/asm/bitops.h | 11 +++
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/parity_64.S | 142 +++++++++++++++++++++++++++
arch/powerpc/lib/ppc_ksyms.c | 5 +
arch/s390/include/asm/bitops.h | 1 +
arch/sh/include/asm/bitops.h | 1 +
arch/sparc/include/asm/bitops_32.h | 1 +
arch/sparc/include/asm/bitops_64.h | 18 ++++
arch/sparc/kernel/sparc_ksyms_64.c | 6 ++
arch/sparc/lib/Makefile | 2 +-
arch/sparc/lib/parity.S | 128 ++++++++++++++++++++++++
arch/tile/include/asm/bitops.h | 2 +
arch/x86/include/asm/arch_hweight.h | 5 +
arch/x86/include/asm/arch_parity.h | 117 ++++++++++++++++++++++
arch/x86/include/asm/bitops.h | 4 +-
arch/xtensa/include/asm/bitops.h | 1 +
drivers/crypto/qat/qat_common/qat_hal.c | 32 ++----
drivers/iio/gyro/adxrs450.c | 4 +-
drivers/input/joystick/grip_mp.c | 16 +--
drivers/input/joystick/sidewinder.c | 24 +----
drivers/input/mouse/elantech.c | 10 +-
drivers/input/mouse/elantech.h | 1 -
drivers/input/serio/ams_delta_serio.c | 8 +-
drivers/input/serio/pcips2.c | 2 +-
drivers/input/serio/sa1111ps2.c | 2 +-
drivers/media/i2c/saa7115.c | 17 +---
drivers/media/platform/vivid/vivid-vbi-gen.c | 9 +-
drivers/mtd/inftlcore.c | 17 +---
drivers/mtd/sm_ftl.c | 5 +-
drivers/mtd/ssfdc.c | 31 ++----
drivers/net/ethernet/broadcom/tg3.c | 6 +-
drivers/net/ethernet/sun/niu.c | 10 +-
drivers/scsi/isci/phy.c | 15 +--
drivers/tty/serial/max3100.c | 2 +-
include/asm-generic/bitops.h | 1 +
include/asm-generic/bitops/arch_parity.h | 39 ++++++++
include/asm-generic/bitops/const_parity.h | 36 +++++++
include/asm-generic/bitops/parity.h | 7 ++
include/asm-generic/bitops/popc-parity.h | 32 ++++++
include/linux/bitops.h | 10 ++
lib/bch.c | 14 +--
net/sunrpc/auth_gss/gss_krb5_keys.c | 6 +-
62 files changed, 745 insertions(+), 235 deletions(-)
create mode 100644 arch/powerpc/lib/parity_64.S
create mode 100644 arch/sparc/lib/parity.S
create mode 100644 arch/x86/include/asm/arch_parity.h
create mode 100644 include/asm-generic/bitops/arch_parity.h
create mode 100644 include/asm-generic/bitops/const_parity.h
create mode 100644 include/asm-generic/bitops/parity.h
create mode 100644 include/asm-generic/bitops/popc-parity.h
--
2.5.0
^ permalink raw reply
* Re: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets
From: David Miller @ 2016-04-14 2:30 UTC (permalink / raw)
To: decui
Cc: olaf, gregkh, jasowang, linux-kernel, joe, netdev, apw, devel,
haiyangz
In-Reply-To: <1460079411-31982-1-git-send-email-decui@microsoft.com>
From: Dexuan Cui <decui@microsoft.com>
Date: Thu, 7 Apr 2016 18:36:51 -0700
> +struct vmpipe_proto_header {
> + u32 pkt_type;
> + u32 data_size;
> +} __packed;
There is no reason to specify __packed here.
The types are strongly sized to word aligned quantities.
No holes are possible in this structure, nor is any padding
possible either.
Do not ever slap __packed onto protocol or HW defined structures,
simply just define them properly with proper types and explicit
padding when necessary.
> + struct {
> + struct vmpipe_proto_header hdr;
> + char buf[HVSOCK_SND_BUF_SZ];
> + } __packed send;
And so on, and so forth..
I'm really disappointed that I couldn't even get one hunk into this
patch submission without finding a major problem.
I expect this patch to take several more iterations before I can even
come close to applying it. So please set your expectations properly,
and also it seems like nobody else wants to even review this stuff
either. It is you who needs to find a way to change all of this, not
me.
^ permalink raw reply
* Re: [PATCH net-next 0/2] fix two more udp pull header issues
From: David Miller @ 2016-04-14 2:25 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, tom, samanthakumar, willemb
In-Reply-To: <1460067179-67789-1-git-send-email-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Thu, 7 Apr 2016 18:12:57 -0400
> Follow up patches to the fixes to RxRPC and SunRPC. A scan of the
> code showed two other interfaces that expect UDP packets to have
> a udphdr when queued: read packet length with ioctl SIOCINQ and
> receive payload checksum with socket option IP_CHECKSUM.
As we are seeing, lots of places depend upon the old way of queueing
up UDP frames. :-/
Applied, thanks for mopping all of this up.
^ permalink raw reply
* Re: [PATCH] net-next: mediatek: add support for IRQ grouping
From: David Miller @ 2016-04-14 2:22 UTC (permalink / raw)
To: blogic; +Cc: nbd, matthias.bgg, netdev, linux-mediatek, linux-kernel
In-Reply-To: <1460053499-53659-1-git-send-email-blogic@openwrt.org>
From: John Crispin <blogic@openwrt.org>
Date: Thu, 7 Apr 2016 20:24:59 +0200
> The ethernet core has 3 IRQs. Using the IRQ grouping registers we are able
> to separate TX and RX IRQs, which allows us to service them on separate
> cores. This patch splits the IRQ handler into 2 separate functions, one
> for TX and another for RX. The TX housekeeping is split out of the NAPI
> handler. Instead we use a tasklet to handle housekeeping.
>
> Signed-off-by: John Crispin <blogic@openwrt.org>
Don't do this with tasklets.
Do your TX reclaim in a NAPI poll just like the RX side.
^ permalink raw reply
* Re: [RESEND PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode
From: Weidong Wang @ 2016-04-14 2:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: David Miller, f.fainelli, netdev, linux-kernel
In-Reply-To: <570E558C.9010304@cogentembedded.com>
On 2016/4/13 22:19, Sergei Shtylyov wrote:
> Hello.
>
> On 4/13/2016 2:59 PM, Weidong Wang wrote:
>
>> When tested the PHY SGMII Loopback,:
>> 1.set the LOOPBACK bit,
>> 2.set the autoneg to AUTONEG_DISABLE, it calls the
>> genphy_setup_forced which will clear the bit.
>>
>> So just keep the LOOPBACK bit while setup forced mode.
>>
>> Signed-off-by: Weidong Wang <wangweidong1@huawei.com>
>> ---
>> drivers/net/phy/phy_device.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index e551f3a..8da4b80 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1124,7 +1124,9 @@ static int genphy_config_advert(struct phy_device *phydev)
>> int genphy_setup_forced(struct phy_device *phydev)
>> {
>> int ctl = 0;
>> + int val = phy_read(phydev, MII_BMCR);
>
> Please place this declaration first, DaveM prefers declarations to be sorted from longest to shortest.
>
>>
>> + ctl |= val & BMCR_LOOPBACK;
>
> Just =, removing the 'ctl' initializer, please.
>
> [...]
>
> MBR, Sergei
>
Got it.
Regards,
Weidong
>
>
^ permalink raw reply
* Re: [PATCH RFC 2/5] net: phy: sun8i-h3-ephy: Add driver for Allwinner H3 Ethernet PHY
From: Chen-Yu Tsai @ 2016-04-14 2:04 UTC (permalink / raw)
To: Florian Fainelli
Cc: Chen-Yu Tsai, Maxime Ripard, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, netdev, linux-arm-kernel,
linux-kernel, devicetree, LABBE Corentin, Andrew Lunn,
Hans De Goede
In-Reply-To: <570BF9A6.2040109@gmail.com>
On Tue, Apr 12, 2016 at 3:23 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 04/04/16 09:22, Chen-Yu Tsai wrote:
>> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and
>> configured through a memory mapped hardware register.
>>
>> This same register also configures the MAC interface mode and TX clock
>> source. Also covered by the register, but not supported in this driver,
>> are TX/RX clock delay chains and inverters, and an RMII module.
>
> This is not really a PHY driver, more a driver for a special piece of
> hardware responsible for properly configuring a more standard integrated
> PHY which is then driven via standard MDIO accesses, right?
>
> The intention to make this driver re-usable is fine, but still makes me
> wonder if it should not be put in a file which is linked into the
> Ethernet MAC driver, and utilized by this one in a way that may be more
> "ad-hoc" than what you are proposing here.
>
> One thing that is not obvious here, is how is the device parenting done?
> Are we able to associate a phy_device to this SUN8I_H3_EPHY platform
> device here?
AFAIK you can't tie a platform device to an MDIO bus and phy_device.
I looked around for any examples and found none.
We're going to run into a similar issue with an MFD device later on.
The X-Powers AC200 is a I2C based combo chip which includes an Ethernet
PHY.
> Another thing is that the Ethernet MAC driver is fully aware of when
> putting an Ethernet PHY into suspend, shutdown, or fully functional
> power state should occur, if you have a separate platform driver here
> which does not listen for such kinds of events (hint: none are generated
> right now), then you cannot implement a working power state interface
> between the MAC, SHIM and PHY here, even though you would want that.
For this particular piece of hardware it would be possible to move the
code into the MAC driver itself. For the AC200, not so much. Using the
generic PHY framework to do power up / down would be a possibility.
Regards
ChenYu
^ permalink raw reply
* Re: [PATCH net-next 4/8] dsa: Move gpio reset into switch driver
From: David Miller @ 2016-04-14 2:03 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev, vivien.didelot
In-Reply-To: <1460591998-20598-5-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Thu, 14 Apr 2016 01:59:54 +0200
> @@ -3178,6 +3178,7 @@ int mv88e6xxx_probe(struct mdio_device *mdiodev, struct dsa_switch_driver *ops,
> struct mv88e6xxx_priv_state *ps;
> struct dsa_switch *ds;
> const char *name;
> + int err;
>
> ds = devm_kzalloc(dev, sizeof(*ds) + sizeof(*ps), GFP_KERNEL);
> if (!ds)
> @@ -3199,6 +3200,17 @@ int mv88e6xxx_probe(struct mdio_device *mdiodev, struct dsa_switch_driver *ops,
> return -ENODEV;
> }
>
> + ps->reset = devm_gpiod_get(&mdiodev->dev, "reset", GPIOD_ASIS);
> + err = PTR_ERR(ps->reset);
> + if (err) {
> + if (err == -ENOENT) {
> + /* Optional, so not an error */
> + ps->reset = NULL;
> + } else {
> + return err;
> + }
> + }
PTR_ERR() just casts the pointer into an integer, regardless of it's
value, and regardless of whether it is an error code or a real pointer
successfully returned from devm_gpiod_get().
So I don't think this code is correct.
You need an IS_ERR() check in there somewhere.
^ permalink raw reply
* Re: [PATCH 0/3] Netfilter fixes for net
From: David Miller @ 2016-04-14 1:51 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1460588094-3933-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 14 Apr 2016 00:54:51 +0200
> The following patchset contains Netfilter fixes for your net tree. More
> specifically, they are:
>
> 1) Fix missing filter table per-netns registration in arptables, from
> Florian Westphal.
>
> 2) Resolve out of bound access when parsing TCP options in
> nf_conntrack_tcp, patch from Jozsef Kadlecsik.
>
> 3) Prefer NFPROTO_BRIDGE extensions over NFPROTO_UNSPEC in ebtables,
> this resolves conflict between xt_limit and ebt_limit, from Phil Sutter.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Use passed in table for nexthop lookups
From: David Miller @ 2016-04-14 1:41 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1460052674-1204-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 7 Apr 2016 11:11:14 -0700
> Similar to 3bfd847203c6 ("net: Use passed in table for nexthop lookups")
> for IPv4, if the route spec contains a table id use that to lookup the
> next hop first and fall back to a full lookup if it fails (per the fix
> 4c9bcd117918b ("net: Fix nexthop lookups")).
> @@ -1940,7 +1940,38 @@ static struct rt6_info *ip6_route_info_create(struct fib6_config *cfg)
> if (!(gwa_type & IPV6_ADDR_UNICAST))
> goto out;
>
> - grt = rt6_lookup(net, gw_addr, NULL, cfg->fc_ifindex, 1);
> + if (cfg->fc_table) {
> + struct flowi6 fl6 = {
> + .flowi6_oif = cfg->fc_ifindex,
> + .daddr = *gw_addr,
> + .saddr = cfg->fc_prefsrc,
> + };
> + struct fib6_table *table;
> + int flags = 0;
> +
> + err = -EHOSTUNREACH;
> + table = fib6_get_table(net, cfg->fc_table);
> + if (!table)
> + goto out;
> +
> + if (!ipv6_addr_any(&cfg->fc_prefsrc))
> + flags |= RT6_LOOKUP_F_HAS_SADDR;
> +
> + grt = ip6_pol_route(net, table, cfg->fc_ifindex,
> + &fl6, flags);
> +
> + /* if table lookup failed, fall back
> + * to full lookup
> + */
This is semantically different from the referenced ipv4 change.
Lack of a matching table for cfg->fc_table does not result in a
failure on the ipv4 side. It falls back in that case.
But here in this ipv6 patch, you do fail if fib6_get_table() gives
NULL.
One thing that drives me absolutely crazy is all of the subtle
semantic differences between our ipv4 and ipv6 stack, so I refuse to
knowingly add new such cases.
Therefore, please make the ipv6 behavior match exactly what ipv4
does.
Thanks.
^ permalink raw reply
* Re: [RFC] Is it a bug for nfs on udp6 mode or kernel?
From: Ding Tianhong @ 2016-04-14 0:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-nfs-approval, tom, Netdev, linux-kernel@vger.kernel.org,
dhowells, viro, chuck.lever
In-Reply-To: <1460564226.10638.28.camel@edumazet-glaptop3.roam.corp.google.com>
On 2016/4/14 0:17, Eric Dumazet wrote:
> On Wed, 2016-04-13 at 19:28 +0800, Ding Tianhong wrote:
>> Hi everyone:
>>
>> I have met this problem when I try to test udp6 for nfs connection, my environment is:
>>
>> Server:
>> kernel: 4.1.15
>> IP:xxxx::36/64
>> MTU:1500
>> Setting: /etc/exports:/home/nfs *(rw,sync,no_subtree_check,no_root_squash)
>>
>> Client:
>> kernel: 4.1.18
>> IP:xxxx::90/64
>> MTU:1500
>> command: mount -t nfs -o vers=3,proto=udp6,rsize=4096,wsize=4096 [xxxx::36]:/home/nfs /home/tmp
>>
>> I check the nfs parameter configuration, it looks fine and could work well for proto=tcp6.
>>
>> Then I have mount correctly and try to run the command "ls", it hang.
>>
>> When I use the rsize=1024 and wsize=1024 to mount, the problem disappeared, so I guess it is the problem for GSO or GRO for UDP。
>>
>> Then I try to debug the problem, first I tcpdump the package from cline to server, and found that
>> the client have send readdirplus message to server correctly, and then the Server send a 4k package
>> to client(the big package will frag to 4 package by GSO), till now it looks fine, and the Client Nic could
>> receive the 4 skb then send to upper stack to ipv6 and udp, I found the incoming 4 package has been merged
>> to one and send to upper stack just like sunrpc, but I try to open the rpc_debug, it looks that the rpc could
>> not receive message.
>>
>>
>> I built a simple demo to test the udp stack, use the client socket to send big package to server socket, it work well,
>> so I think the udp is fine, maybe the bug is in sunrpc.
>>
>> The test is very simple, does any body met the same problem like me, thanks for any suggestion.
>>
>> Ding
>
> Have you tried to disable UFO ?
>
> ethtool -K eth... ufo off
>
>
Hi Eric:
Already disabled, my nic don't support UFO.
Thanks.
Ding
>
> .
>
^ permalink raw reply
* Re: [PATCH v2 01/15] wcn36xx: Clean up wcn36xx_smd_send_beacon
From: Bjorn Andersson @ 2016-04-14 0:59 UTC (permalink / raw)
To: Eugene Krasnikov, Kalle Valo
Cc: Pontus Fuchs, wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1459721806-11817-1-git-send-email-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Sun 03 Apr 15:16 PDT 2016, Bjorn Andersson wrote:
> From: Pontus Fuchs <pontus.fuchs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Needed for coming improvements. No functional changes.
>
Kalle, Eugene,
Have you picked up these patches yet?
As I was debugging a firmware crash when trying to start hostap on the
DragonBoard410c I found an issue with this patch, would like to know if
I should send an incremental patch or resend this one.
> Signed-off-by: Pontus Fuchs <pontus.fuchs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/net/wireless/ath/wcn36xx/hal.h | 7 +++++--
> drivers/net/wireless/ath/wcn36xx/smd.c | 12 +++++-------
> 2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h b/drivers/net/wireless/ath/wcn36xx/hal.h
> index b947de0fb2e5..4fd77ccc2287 100644
> --- a/drivers/net/wireless/ath/wcn36xx/hal.h
> +++ b/drivers/net/wireless/ath/wcn36xx/hal.h
> @@ -51,8 +51,8 @@
> #define WALN_HAL_STA_INVALID_IDX 0xFF
> #define WCN36XX_HAL_BSS_INVALID_IDX 0xFF
>
> -/* Default Beacon template size */
> -#define BEACON_TEMPLATE_SIZE 0x180
> +/* Default Beacon template size. */
> +#define BEACON_TEMPLATE_SIZE 0x17C
This affects the wcn36xx_hal_send_probe_resp_req_msg as well, making the
firmware on DB410c crash upon receiving the UPDATE_PROBE_RSP_TEMPLATE_REQ.
I think we should keep it at 0x180 and subtract sizeof(u32) from the
template size in send_beacon_req_msg, because the second length is
really part of the buffer.
>
> /* Param Change Bitmap sent to HAL */
> #define PARAM_BCN_INTERVAL_CHANGED (1 << 0)
> @@ -2884,6 +2884,9 @@ struct update_beacon_rsp_msg {
> struct wcn36xx_hal_send_beacon_req_msg {
> struct wcn36xx_hal_msg_header header;
>
> + /* length of the template + 6. Only qcom knows why */
> + u32 beacon_length6;
> +
> /* length of the template. */
> u32 beacon_length;
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 74f56a81ad9a..ff3ed2461a69 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -1380,19 +1380,17 @@ int wcn36xx_smd_send_beacon(struct wcn36xx *wcn, struct ieee80211_vif *vif,
> mutex_lock(&wcn->hal_mutex);
> INIT_HAL_MSG(msg_body, WCN36XX_HAL_SEND_BEACON_REQ);
>
> - /* TODO need to find out why this is needed? */
> - msg_body.beacon_length = skb_beacon->len + 6;
> + msg_body.beacon_length = skb_beacon->len;
> + /* TODO need to find out why + 6 is needed */
> + msg_body.beacon_length6 = msg_body.beacon_length + 6;
As far as I can tell from the prima code and SMD dumps this should be 4,
as in sizeof(u32). This looks like a mishap in the layering of prima.
>
> - if (BEACON_TEMPLATE_SIZE > msg_body.beacon_length) {
> - memcpy(&msg_body.beacon, &skb_beacon->len, sizeof(u32));
> - memcpy(&(msg_body.beacon[4]), skb_beacon->data,
> - skb_beacon->len);
> - } else {
> + if (msg_body.beacon_length > BEACON_TEMPLATE_SIZE) {
> wcn36xx_err("Beacon is to big: beacon size=%d\n",
> msg_body.beacon_length);
> ret = -ENOMEM;
> goto out;
> }
> + memcpy(msg_body.beacon, skb_beacon->data, skb_beacon->len);
> memcpy(msg_body.bssid, vif->addr, ETH_ALEN);
>
> /* TODO need to find out why this is needed? */
PS. I confirmed that the update_beacon_rsp_msg does not come with the
prepended length...for some reason.
Regards,
Bjorn
--
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: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Peter Zijlstra @ 2016-04-14 0:58 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ingo Molnar, Mike Galbraith, Jason Wang, davem, netdev,
linux-kernel, Ingo Molnar
In-Reply-To: <20160413163940-mutt-send-email-mst@redhat.com>
On Wed, Apr 13, 2016 at 04:51:36PM +0300, Michael S. Tsirkin wrote:
> On Wed, Apr 13, 2016 at 03:28:03PM +0200, Peter Zijlstra wrote:
> > Nope, not true. Current isn't actually in the tree, and any other task
> > is subject to being moved at any time.
> > Even if current was in the tree, there is no guarantee it is
> > ->rb_leftmost; imagine a task being migrated in that has a smaller
> > vruntime.
> >
> > So this really cannot work without locks :/
> >
> > I've not thought about the actual problem you're trying to solve; but I
> > figured I'd let you know this before you continue down this path.
> static bool expected_to_run_fair(struct cfs_rq *cfs_rq, struct task_struct *task, s64 t)
> {
> struct sched_entity *left;
> struct sched_entity *curr = &task->se;
> if (!curr || !curr->on_rq)
> return false;
>
> left = __pick_first_entity(cfs_rq);
> if (!left)
> return true;
>
> return (s64)(curr->vruntime + calc_delta_fair(t, curr) -
> left->vruntime) < 0;
> }
>
> Left here is on tree so it's not going away, right?
No, left is the leftmost entry on the tree, it can go away at any time.
You cannot touch the tree without locks.
Someone can come an migrate the task to another CPU, start executing it
and it can die between you finding the left pointer and dereferencing
it.
^ permalink raw reply
* Re: [RFC] Is it a bug for nfs on udp6 mode or kernel?
From: Ding Tianhong @ 2016-04-14 0:56 UTC (permalink / raw)
To: Benjamin Coddington
Cc: linux-nfs-approval, tom, Netdev, linux-kernel@vger.kernel.org,
dhowells, viro, chuck.lever
In-Reply-To: <alpine.OSX.2.19.9992.1604131003530.55780@planck>
On 2016/4/13 22:11, Benjamin Coddington wrote:
> On Wed, 13 Apr 2016, Ding Tianhong wrote:
>
>> Hi everyone:
>>
>> I have met this problem when I try to test udp6 for nfs connection, my environment is:
>>
>> Server:
>> kernel: 4.1.15
>> IP:xxxx::36/64
>> MTU:1500
>> Setting: /etc/exports:/home/nfs *(rw,sync,no_subtree_check,no_root_squash)
>>
>> Client:
>> kernel: 4.1.18
>> IP:xxxx::90/64
>> MTU:1500
>> command: mount -t nfs -o vers=3,proto=udp6,rsize=4096,wsize=4096 [xxxx::36]:/home/nfs /home/tmp
>>
>> I check the nfs parameter configuration, it looks fine and could work well for proto=tcp6.
>>
>> Then I have mount correctly and try to run the command "ls", it hang.
>>
>> When I use the rsize=1024 and wsize=1024 to mount, the problem disappeared, so I guess it is the problem for GSO or GRO for UDP。
>>
>> Then I try to debug the problem, first I tcpdump the package from cline to server, and found that
>> the client have send readdirplus message to server correctly, and then the Server send a 4k package
>> to client(the big package will frag to 4 package by GSO), till now it looks fine, and the Client Nic could
>> receive the 4 skb then send to upper stack to ipv6 and udp, I found the incoming 4 package has been merged
>> to one and send to upper stack just like sunrpc, but I try to open the rpc_debug, it looks that the rpc could
>> not receive message.
>>
>>
>> I built a simple demo to test the udp stack, use the client socket to send big package to server socket, it work well,
>> so I think the udp is fine, maybe the bug is in sunrpc.
>>
>> The test is very simple, does any body met the same problem like me, thanks for any suggestion.
>>
>> Ding
>
> I had a similar problem. Do you have upstream
>
> 405c92f ("ipv6: add defensive check for CHECKSUM_PARTIAL skbs in ip_fragment")
> 682b1a9 ("ipv6: no CHECKSUM_PARTIAL on MSG_MORE corked sockets")
>
Hi Ben:
Thanks for the feedback, my kernel is 4.1.15, not merged these two patch, I will check and try, thanks a lot.
> Turning off GSO and GRO caused sunrpc to work properly before this.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1271759
>
Sorry, I don't have permission to read this, but thanks for this message.:)
Ding
> Ben
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Peter Zijlstra @ 2016-04-14 0:55 UTC (permalink / raw)
To: Jason Wang
Cc: Eliezer Tamir, Eric Dumazet, Ingo Molnar, Mike Galbraith, davem,
netdev, linux-kernel, mst, Ingo Molnar jacob.e.keller@intel.com
In-Reply-To: <54056459.4060100@redhat.com>
On Tue, Sep 02, 2014 at 02:31:53PM +0800, Jason Wang wrote:
> Yes, but current code can not do this. In most of the cases, the new
> woke up process have no chance to run if another process is busy loop in
> the same cpu.
That sounds weird; a process that slept will have an effective vruntime
deficit vs one that has been running for a while.
^ 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