Re: [PATCH net 1/7] b44: Initialize 64-bit stats seqcount

On Tue, Aug 1, 2017 at 12:11 PM, Florian Fainelli wrote: > On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a > lockdep splat indicating this seqcount is not correctly initialized, fix > that. > > Fixes: eeda8585522b ("b44: add 64 bit stats") > Signed-off-by: Florian Fainelli

[PATCH net 1/7] b44: Initialize 64-bit stats seqcount

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. Fixes: eeda8585522b ("b44: add 64 bit stats") Signed-off-by: Florian Fainelli --- drivers/net/ethernet/broadcom/b44.c | 1 +

[PATCH net 1/7] b44: Initialize 64-bit stats seqcount

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that. Fixes: eeda8585522b ("b44: add 64 bit stats") Signed-off-by: Florian Fainelli --- drivers/net/ethernet/broadcom/b44.c | 1 + 1 file changed, 1

Re: [PATCH net 1/2] selftests/bpf: subtraction bounds test

On 07/21/2017 03:36 PM, Edward Cree wrote: There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test which, with the bogus handling, will produce ranges of [0,0] and thus allowed accesses; whereas the

Re: [PATCH net 1/2] selftests/bpf: subtraction bounds test

On 07/21/2017 03:36 PM, Edward Cree wrote: There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test which, with the bogus handling, will produce ranges of [0,0] and thus allowed accesses; whereas the

[PATCH net 1/2] selftests/bpf: subtraction bounds test

There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test which, with the bogus handling, will produce ranges of [0,0] and thus allowed accesses; whereas the correct handling will give a range of [-255, 255]

[PATCH net 1/2] selftests/bpf: subtraction bounds test

There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test which, with the bogus handling, will produce ranges of [0,0] and thus allowed accesses; whereas the correct handling will give a range of [-255, 255]

[PATCH net 1/2] net: bcmgenet: Fix unmapping of fragments in bcmgenet_xmit()

In case we fail to map a single fragment, we would be leaving the transmit ring populated with stale entries. This commit introduces the helper function bcmgenet_put_txcb() which takes care of rewinding the per-ring write pointer back to where we left. It also consolidates the functionality of

[PATCH net 1/2] net: bcmgenet: Fix unmapping of fragments in bcmgenet_xmit()

In case we fail to map a single fragment, we would be leaving the transmit ring populated with stale entries. This commit introduces the helper function bcmgenet_put_txcb() which takes care of rewinding the per-ring write pointer back to where we left. It also consolidates the functionality of

Re: [PATCH net 1/3] net: hns: Add TX CSUM check when fill TX description

Hi, David On 2017/7/4 18:28, David Miller wrote: > From: Lin Yun Sheng > Date: Tue, 4 Jul 2017 18:47:31 +0800 > >> From: Yunsheng Lin >> >> If driver support checksum offload, should check netdev feature >> before fill TX description and get CSUM

Re: [PATCH net 1/3] net: hns: Add TX CSUM check when fill TX description

Hi, David On 2017/7/4 18:28, David Miller wrote: > From: Lin Yun Sheng > Date: Tue, 4 Jul 2017 18:47:31 +0800 > >> From: Yunsheng Lin >> >> If driver support checksum offload, should check netdev feature >> before fill TX description and get CSUM err bit from RX >> description. HNS driver do

Re: [PATCH net 1/3] net: hns: Add TX CSUM check when fill TX description

From: Lin Yun Sheng Date: Tue, 4 Jul 2017 18:47:31 +0800 > From: Yunsheng Lin > > If driver support checksum offload, should check netdev feature > before fill TX description and get CSUM err bit from RX > description. HNS driver do the check in

Re: [PATCH net 1/3] net: hns: Add TX CSUM check when fill TX description

From: Lin Yun Sheng Date: Tue, 4 Jul 2017 18:47:31 +0800 > From: Yunsheng Lin > > If driver support checksum offload, should check netdev feature > before fill TX description and get CSUM err bit from RX > description. HNS driver do the check in RX derction but it doesn't > do the check in TX

[PATCH net 1/3] net: hns: Add TX CSUM check when fill TX description

From: Yunsheng Lin If driver support checksum offload, should check netdev feature before fill TX description and get CSUM err bit from RX description. HNS driver do the check in RX derction but it doesn't do the check in TX direction. Signed-off-by: lipeng

[PATCH net 1/3] net: hns: Add TX CSUM check when fill TX description

From: Yunsheng Lin If driver support checksum offload, should check netdev feature before fill TX description and get CSUM err bit from RX description. HNS driver do the check in RX derction but it doesn't do the check in TX direction. Signed-off-by: lipeng Reviewed-by: Daode Huang

Re: [PATCH NET 1/2] net: phy: Add phy loopback support in net phy framework

Hi, Andrew On 2017/6/23 11:16, Andrew Lunn wrote: >> +int genphy_loopback(struct phy_device *phydev, bool enable) >> +{ >> +int value; >> + >> +if (enable) { >> +value = phy_read(phydev, MII_BMCR); >> +phy_write(phydev, MII_BMCR, value | BMCR_LOOPBACK); >> +}

Re: [PATCH NET 1/2] net: phy: Add phy loopback support in net phy framework

Hi, Andrew On 2017/6/23 11:16, Andrew Lunn wrote: >> +int genphy_loopback(struct phy_device *phydev, bool enable) >> +{ >> +int value; >> + >> +if (enable) { >> +value = phy_read(phydev, MII_BMCR); >> +phy_write(phydev, MII_BMCR, value | BMCR_LOOPBACK); >> +}

Re: [PATCH NET 1/2] net: phy: Add phy loopback support in net phy framework

> +int genphy_loopback(struct phy_device *phydev, bool enable) > +{ > + int value; > + > + if (enable) { > + value = phy_read(phydev, MII_BMCR); > + phy_write(phydev, MII_BMCR, value | BMCR_LOOPBACK); > + } else { > + value = phy_read(phydev,

Re: [PATCH NET 1/2] net: phy: Add phy loopback support in net phy framework

> +int genphy_loopback(struct phy_device *phydev, bool enable) > +{ > + int value; > + > + if (enable) { > + value = phy_read(phydev, MII_BMCR); > + phy_write(phydev, MII_BMCR, value | BMCR_LOOPBACK); > + } else { > + value = phy_read(phydev,

[PATCH NET 1/2] net: phy: Add phy loopback support in net phy framework

This patch add set_loopback in phy_driver, which is used by Mac driver to enable or disable a phy. it also add a generic genphy_loopback function, which use BMCR loopback bit to enable or disable a phy. Signed-off-by: Lin Yun Sheng --- drivers/net/phy/marvell.c| 1 +

[PATCH NET 1/2] net: phy: Add phy loopback support in net phy framework

This patch add set_loopback in phy_driver, which is used by Mac driver to enable or disable a phy. it also add a generic genphy_loopback function, which use BMCR loopback bit to enable or disable a phy. Signed-off-by: Lin Yun Sheng --- drivers/net/phy/marvell.c| 1 +

[PATCH net 1/2] net: ethernet: mediatek: fix inconsistency between TXD and the used buffer

From: Sean Wang Fix inconsistency between the TXD descriptor and the used buffer that would cause unexpected logic at mtk_tx_unmap() during skb housekeeping. Signed-off-by: Sean Wang --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17

[PATCH net 1/2] net: ethernet: mediatek: fix inconsistency between TXD and the used buffer

From: Sean Wang Fix inconsistency between the TXD descriptor and the used buffer that would cause unexpected logic at mtk_tx_unmap() during skb housekeeping. Signed-off-by: Sean Wang --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 - 1 file changed, 8 insertions(+), 9

[PATCH net 1/1] proc/sysctl: Fix the int overflow for jiffies conversion

From: Gao Feng The function do_proc_dointvec_jiffies_conv uses LONG_MX/HZ as the max value to avoid overflow. But actually the *valp is int type, so it still causes overflow. For example, echo 2147483647 > ./sys/net/ipv4/tcp_keepalive_time Then, cat

[PATCH net 1/1] proc/sysctl: Fix the int overflow for jiffies conversion

From: Gao Feng The function do_proc_dointvec_jiffies_conv uses LONG_MX/HZ as the max value to avoid overflow. But actually the *valp is int type, so it still causes overflow. For example, echo 2147483647 > ./sys/net/ipv4/tcp_keepalive_time Then, cat ./sys/net/ipv4/tcp_keepalive_time The output

[PATCH net 1/2] r8152: set the RMS of RTL8153 according to the mtu

Set the received maximum size (RMS) according to the mtu size. It is unnecessary to receive a packet which is more than the size we could transmit. Besides, this could let the rx buffer be used effectively. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 16

[PATCH net 1/2] r8152: set the RMS of RTL8153 according to the mtu

Set the received maximum size (RMS) according to the mtu size. It is unnecessary to receive a packet which is more than the size we could transmit. Besides, this could let the rx buffer be used effectively. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 16 1 file

Re: [PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers

On Fri, Dec 16, 2016 at 7:18 PM, Nicolas Pitre wrote: > On Fri, 16 Dec 2016, Arnd Bergmann wrote: > >> With posix timers having become optional, we get a build error with >> the cpts time sync option of the CPSW driver: >> >> drivers/net/ethernet/ti/cpts.c: In function

Re: [PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers

On Fri, Dec 16, 2016 at 7:18 PM, Nicolas Pitre wrote: > On Fri, 16 Dec 2016, Arnd Bergmann wrote: > >> With posix timers having become optional, we get a build error with >> the cpts time sync option of the CPSW driver: >> >> drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts': >>

[PATCH net 1/8] net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values

From: Doug Berger The location of the RBUF overflow and error counters has moved between different version of the GENET MAC. This commit corrects the driver to read from the correct locations depending on the version of the GENET MAC. refs #SWLINUX-4311 Fixes:

[PATCH net 1/8] net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values

From: Doug Berger The location of the RBUF overflow and error counters has moved between different version of the GENET MAC. This commit corrects the driver to read from the correct locations depending on the version of the GENET MAC. refs #SWLINUX-4311 Fixes: 1c1008c793fa ("net: bcmgenet:

Re: [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

On Wed, 25 Jan 2017 10:50:51 +0800 Hayes Wang wrote: > Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() > from calling napi_schedule() directly during runtime suspend. > > After calling napi_disable() or clearing the flag of WORK_ENABLE, >

Re: [PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

On Wed, 25 Jan 2017 10:50:51 +0800 Hayes Wang wrote: > Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() > from calling napi_schedule() directly during runtime suspend. > > After calling napi_disable() or clearing the flag of WORK_ENABLE, > scheduling the napi is

[PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() from calling napi_schedule() directly during runtime suspend. After calling napi_disable() or clearing the flag of WORK_ENABLE, scheduling the napi is useless. Signed-off-by: Hayes Wang ---

[PATCH net 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() from calling napi_schedule() directly during runtime suspend. After calling napi_disable() or clearing the flag of WORK_ENABLE, scheduling the napi is useless. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 8

[PATCH net 1/2] r8152: split rtl8152_suspend function

Split rtl8152_suspend() into rtl8152_system_suspend() and rtl8152_rumtime_suspend(). Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 57 ++--- 1 file changed, 40 insertions(+), 17 deletions(-) diff --git

[PATCH net 1/2] r8152: split rtl8152_suspend function

Split rtl8152_suspend() into rtl8152_system_suspend() and rtl8152_rumtime_suspend(). Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 57 ++--- 1 file changed, 40 insertions(+), 17 deletions(-) diff --git a/drivers/net/usb/r8152.c

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Ansis Atteka [mailto:aatt...@nicira.com] > Sent: Tuesday, January 03, 2017 8:41 AM [...] > Hayes, in your iperf reproduction environment did you > 1) connect sender and receiver directly with an Ethernet cable? > 2) use iperf's TCP mode instead of UDP mode, because I believe that > with UDP mode

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Ansis Atteka [mailto:aatt...@nicira.com] > Sent: Tuesday, January 03, 2017 8:41 AM [...] > Hayes, in your iperf reproduction environment did you > 1) connect sender and receiver directly with an Ethernet cable? > 2) use iperf's TCP mode instead of UDP mode, because I believe that > with UDP mode

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 17-01-02 07:40 PM, Ansis Atteka wrote: .. > I think that I am getting closer to the root cause of this bug. Also, > I have a workaround that at least makes r8152 functionally stable in > my Dell TB15 dock. Mark, would you mind giving a chance to the patch > that I have in the bottom of this

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 17-01-02 07:40 PM, Ansis Atteka wrote: .. > I think that I am getting closer to the root cause of this bug. Also, > I have a workaround that at least makes r8152 functionally stable in > my Dell TB15 dock. Mark, would you mind giving a chance to the patch > that I have in the bottom of this

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Sat, Dec 31, 2016 at 4:07 PM, Ansis Atteka wrote: > On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote: >> Mark Lord >> [...] >>> > Not sure why, because there really is no other way for the data to >>> > appear where it does at the

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Sat, Dec 31, 2016 at 4:07 PM, Ansis Atteka wrote: > On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote: >> Mark Lord >> [...] >>> > Not sure why, because there really is no other way for the data to >>> > appear where it does at the beginning of that URB buffer. >>> > >>> > This does seem a

[PATCH net 1/3] net: stmmac: dwmac-oxnas: fix of-node leak

Use the syscon lookup-by-phandle helper so that the reference taken by of_parse_phandle() is released when done with the node. Fixes: 5ed7414062e7 ("net: stmmac: Add OXNAS Glue Driver") Signed-off-by: Johan Hovold --- drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 10

[PATCH net 1/3] net: stmmac: dwmac-oxnas: fix of-node leak

Use the syscon lookup-by-phandle helper so that the reference taken by of_parse_phandle() is released when done with the node. Fixes: 5ed7414062e7 ("net: stmmac: Add OXNAS Glue Driver") Signed-off-by: Johan Hovold --- drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 10 ++ 1 file

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote: > Mark Lord > [...] >> > Not sure why, because there really is no other way for the data to >> > appear where it does at the beginning of that URB buffer. >> > >> > This does seem a rather unexpected

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote: > Mark Lord > [...] >> > Not sure why, because there really is no other way for the data to >> > appear where it does at the beginning of that URB buffer. >> > >> > This does seem a rather unexpected burden to place upon someone >> > reporting a

Re: [PATCH net 1/9] virtio-net: remove the warning before XDP linearizing

On 2016年12月24日 03:31, Daniel Borkmann wrote: Hi Jason, On 12/23/2016 03:37 PM, Jason Wang wrote: Since we use EWMA to estimate the size of rx buffer. When rx buffer size is underestimated, it's usual to have a packet with more than one buffers. Consider this is not a bug, remove the warning

Re: [PATCH net 1/9] virtio-net: remove the warning before XDP linearizing

On 2016年12月24日 03:31, Daniel Borkmann wrote: Hi Jason, On 12/23/2016 03:37 PM, Jason Wang wrote: Since we use EWMA to estimate the size of rx buffer. When rx buffer size is underestimated, it's usual to have a packet with more than one buffers. Consider this is not a bug, remove the warning

Re: [PATCH net 1/9] virtio-net: remove the warning before XDP linearizing

Hi Jason, On 12/23/2016 03:37 PM, Jason Wang wrote: Since we use EWMA to estimate the size of rx buffer. When rx buffer size is underestimated, it's usual to have a packet with more than one buffers. Consider this is not a bug, remove the warning and correct the comment before XDP linearizing.

Re: [PATCH net 1/9] virtio-net: remove the warning before XDP linearizing

Hi Jason, On 12/23/2016 03:37 PM, Jason Wang wrote: Since we use EWMA to estimate the size of rx buffer. When rx buffer size is underestimated, it's usual to have a packet with more than one buffers. Consider this is not a bug, remove the warning and correct the comment before XDP linearizing.

[PATCH net 1/9] virtio-net: remove the warning before XDP linearizing

Since we use EWMA to estimate the size of rx buffer. When rx buffer size is underestimated, it's usual to have a packet with more than one buffers. Consider this is not a bug, remove the warning and correct the comment before XDP linearizing. Cc: John Fastabend

[PATCH net 1/9] virtio-net: remove the warning before XDP linearizing

Since we use EWMA to estimate the size of rx buffer. When rx buffer size is underestimated, it's usual to have a packet with more than one buffers. Consider this is not a bug, remove the warning and correct the comment before XDP linearizing. Cc: John Fastabend Signed-off-by: Jason Wang ---

Re: [PATCH net 1/2] net: netcp: ethss: fix errors in ethtool ops

From: Murali Karicheri Date: Mon, 19 Dec 2016 17:55:56 -0500 > From: WingMan Kwok > > In ethtool ops, it needs to retrieve the corresponding > ethss module (gbe or xgbe) from the net_device structure. > Prior to this patch, the retrieving procedure only >

Re: [PATCH net 1/2] net: netcp: ethss: fix errors in ethtool ops

From: Murali Karicheri Date: Mon, 19 Dec 2016 17:55:56 -0500 > From: WingMan Kwok > > In ethtool ops, it needs to retrieve the corresponding > ethss module (gbe or xgbe) from the net_device structure. > Prior to this patch, the retrieving procedure only > checks for the gbe module. This patch

[PATCH net 1/2] net: netcp: ethss: fix errors in ethtool ops

From: WingMan Kwok In ethtool ops, it needs to retrieve the corresponding ethss module (gbe or xgbe) from the net_device structure. Prior to this patch, the retrieving procedure only checks for the gbe module. This patch fixes the issue by checking the xgbe module if the

[PATCH net 1/2] net: netcp: ethss: fix errors in ethtool ops

From: WingMan Kwok In ethtool ops, it needs to retrieve the corresponding ethss module (gbe or xgbe) from the net_device structure. Prior to this patch, the retrieving procedure only checks for the gbe module. This patch fixes the issue by checking the xgbe module if the net_device structure

[PATCH net 1/3] net: phy: fix sign type error in genphy_config_eee_advert

In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is checked to know if the register could be accessed but the result is assigned to a 'u32'. Changing to 'int' to correctly get errors from phy_read_mmd_indirect. Fixes: d853d145ea3e ("net: phy: add an option to disable EEE

[PATCH net 1/3] net: phy: fix sign type error in genphy_config_eee_advert

In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is checked to know if the register could be accessed but the result is assigned to a 'u32'. Changing to 'int' to correctly get errors from phy_read_mmd_indirect. Fixes: d853d145ea3e ("net: phy: add an option to disable EEE

Re: [PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers

On Fri, 16 Dec 2016, Arnd Bergmann wrote: > With posix timers having become optional, we get a build error with > the cpts time sync option of the CPSW driver: > > drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts': > drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of

Re: [PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers

On Fri, 16 Dec 2016, Arnd Bergmann wrote: > With posix timers having become optional, we get a build error with > the cpts time sync option of the CPSW driver: > > drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts': > drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of

[PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers

With posix timers having become optional, we get a build error with the cpts time sync option of the CPSW driver: drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts': drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of function 'ptp_classify_raw';did you mean

[PATCH net 1/3] cpsw/netcp: cpts depends on posix_timers

With posix timers having become optional, we get a build error with the cpts time sync option of the CPSW driver: drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts': drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of function 'ptp_classify_raw';did you mean

[PATCH net 1/3] dpaa_eth: use big endian accessors

From: Claudiu Manoil Ensure correct access to the big endian QMan HW through proper accessors. Signed-off-by: Claudiu Manoil Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 71

[PATCH net 1/3] dpaa_eth: use big endian accessors

From: Claudiu Manoil Ensure correct access to the big endian QMan HW through proper accessors. Signed-off-by: Claudiu Manoil Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 71 ++ 1 file changed, 37 insertions(+), 34 deletions(-)

[PATCH net 1/4] fsl/fman: fix 1G support for QSGMII interfaces

QSGMII ports were not advertising 1G speed. Signed-off-by: Madalin Bucur Reviewed-by: Camelia Groza --- drivers/net/ethernet/freescale/fman/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/fman/mac.c

[PATCH net 1/4] fsl/fman: fix 1G support for QSGMII interfaces

QSGMII ports were not advertising 1G speed. Signed-off-by: Madalin Bucur Reviewed-by: Camelia Groza --- drivers/net/ethernet/freescale/fman/mac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c index

[PATCH net 1/3] net: bridge: add helper to offload ageing time

The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME switchdev attr is actually set when initializing a bridge port, and when configuring the bridge ageing time from ioctl/netlink/sysfs. Add a __set_ageing_time helper to offload the ageing time to physical switches, and add the SWITCHDEV_F_DEFER flag since

[PATCH net 1/3] net: bridge: add helper to offload ageing time

The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME switchdev attr is actually set when initializing a bridge port, and when configuring the bridge ageing time from ioctl/netlink/sysfs. Add a __set_ageing_time helper to offload the ageing time to physical switches, and add the SWITCHDEV_F_DEFER flag since

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-12-08 10:23 PM, Hayes Wang wrote: > Mark Lord > > I find an issue about autosuspend, and it may result in the same > problem with you. I don't sure if this is helpful to you, because > it only occurs when enabling the autosuspend. Thanks. I am using ASIX adapters now. I

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-12-08 10:23 PM, Hayes Wang wrote: > Mark Lord > > I find an issue about autosuspend, and it may result in the same > problem with you. I don't sure if this is helpful to you, because > it only occurs when enabling the autosuspend. Thanks. I am using ASIX adapters now. I did try the

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord I find an issue about autosuspend, and it may result in the same problem with you. I don't sure if this is helpful to you, because it only occurs when enabling the autosuspend. Best Regards, Hayes /* * Copyright (c) 2014 Realtek Semiconductor Corp. All rights

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord I find an issue about autosuspend, and it may result in the same problem with you. I don't sure if this is helpful to you, because it only occurs when enabling the autosuspend. Best Regards, Hayes /* * Copyright (c) 2014 Realtek Semiconductor Corp. All rights reserved. * * This

[PATCH net 1/7] net: ethernet: stmmac: dwmac-socfpga: fix use-after-free on probe errors

Make sure to call stmmac_dvr_remove() before returning on late probe errors so that memory is freed, clocks are disabled, and the netdev is deregistered before its resources go away. Fixes: 3c201b5a84ed ("net: stmmac: socfpga: Remove re-registration of reset controller") Signed-off-by: Johan

[PATCH net 1/7] net: ethernet: stmmac: dwmac-socfpga: fix use-after-free on probe errors

Make sure to call stmmac_dvr_remove() before returning on late probe errors so that memory is freed, clocks are disabled, and the netdev is deregistered before its resources go away. Fixes: 3c201b5a84ed ("net: stmmac: socfpga: Remove re-registration of reset controller") Signed-off-by: Johan

Re: [PATCH net 1/2] tun: handle ubuf refcount correctly when meet erros

On Wed, Nov 30, 2016 at 01:17:51PM +0800, Jason Wang wrote: > We trigger uarg->callback() immediately after we decide do datacopy > even if caller want to do zerocopy. This will cause the callback > (vhost_net_zerocopy_callback) decrease the refcount. But when we meet > an error afterwards, the

Re: [PATCH net 1/2] tun: handle ubuf refcount correctly when meet erros

On Wed, Nov 30, 2016 at 01:17:51PM +0800, Jason Wang wrote: > We trigger uarg->callback() immediately after we decide do datacopy > even if caller want to do zerocopy. This will cause the callback > (vhost_net_zerocopy_callback) decrease the refcount. But when we meet > an error afterwards, the

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord [...] > > Not sure why, because there really is no other way for the data to > > appear where it does at the beginning of that URB buffer. > > > > This does seem a rather unexpected burden to place upon someone > > reporting a regression in a USB network driver that

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord [...] > > Not sure why, because there really is no other way for the data to > > appear where it does at the beginning of that URB buffer. > > > > This does seem a rather unexpected burden to place upon someone > > reporting a regression in a USB network driver that corrupts user data.

[PATCH net 1/2] tun: handle ubuf refcount correctly when meet erros

We trigger uarg->callback() immediately after we decide do datacopy even if caller want to do zerocopy. This will cause the callback (vhost_net_zerocopy_callback) decrease the refcount. But when we meet an error afterwards, the error handling in vhost handle_tx() will try to decrease it again.

[PATCH net 1/2] tun: handle ubuf refcount correctly when meet erros

We trigger uarg->callback() immediately after we decide do datacopy even if caller want to do zerocopy. This will cause the callback (vhost_net_zerocopy_callback) decrease the refcount. But when we meet an error afterwards, the error handling in vhost handle_tx() will try to decrease it again.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

From: Mark Lord Date: Fri, 25 Nov 2016 07:49:35 -0500 > On 16-11-25 04:53 AM, Greg KH wrote: >> On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >>> There is no possibility for them to be used for anything other than >>> USB receive buffers, for this driver only.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

From: Mark Lord Date: Fri, 25 Nov 2016 07:49:35 -0500 > On 16-11-25 04:53 AM, Greg KH wrote: >> On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >>> There is no possibility for them to be used for anything other than >>> USB receive buffers, for this driver only. Nothing in the driver

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Fri, Nov 25, 2016 at 07:49:35AM -0500, Mark Lord wrote: > On 16-11-25 04:53 AM, Greg KH wrote: > > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: > >> There is no possibility for them to be used for anything other than > >> USB receive buffers, for this driver only. Nothing in the

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 09:22 AM, Greg KH wrote: > On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote: >> On 16-11-25 07:34 AM, Mark Lord wrote: >>> On 16-11-25 04:53 AM, Greg KH wrote: Note, there are "cheap" USB monitors that can be quite handy and that work on Linux:

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Fri, Nov 25, 2016 at 07:49:35AM -0500, Mark Lord wrote: > On 16-11-25 04:53 AM, Greg KH wrote: > > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: > >> There is no possibility for them to be used for anything other than > >> USB receive buffers, for this driver only. Nothing in the

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 09:22 AM, Greg KH wrote: > On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote: >> On 16-11-25 07:34 AM, Mark Lord wrote: >>> On 16-11-25 04:53 AM, Greg KH wrote: Note, there are "cheap" USB monitors that can be quite handy and that work on Linux:

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote: > On 16-11-25 07:34 AM, Mark Lord wrote: > > On 16-11-25 04:53 AM, Greg KH wrote: > >> Note, there are "cheap" USB monitors that can be quite handy and that work > >> on Linux: > >>http://www.totalphase.com/products/beagle-usb12/ > >

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote: > On 16-11-25 07:34 AM, Mark Lord wrote: > > On 16-11-25 04:53 AM, Greg KH wrote: > >> Note, there are "cheap" USB monitors that can be quite handy and that work > >> on Linux: > >>http://www.totalphase.com/products/beagle-usb12/ > >

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:52 AM, Hayes Wang wrote: .. > What is the value of /sys/bus/usb/devices/.../power/control ? That entry does not exist -- power control is completely disabled on this board. Good try, though -- USB power control still causes me trouble on PCs with mice and remote controls. But not

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:52 AM, Hayes Wang wrote: .. > What is the value of /sys/bus/usb/devices/.../power/control ? That entry does not exist -- power control is completely disabled on this board. Good try, though -- USB power control still causes me trouble on PCs with mice and remote controls. But not

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >> There is no possibility for them to be used for anything other than >> USB receive buffers, for this driver only. Nothing in the driver >> or kernel ever writes to those buffers after initial

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >> There is no possibility for them to be used for anything other than >> USB receive buffers, for this driver only. Nothing in the driver >> or kernel ever writes to those buffers after initial

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > Note, there are "cheap" USB monitors that can be quite handy and that work on > Linux: > http://www.totalphase.com/products/beagle-usb12/ USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 04:53 AM, Greg KH wrote: > Note, there are "cheap" USB monitors that can be quite handy and that work on > Linux: > http://www.totalphase.com/products/beagle-usb12/ USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 07:34 AM, Mark Lord wrote: > On 16-11-25 04:53 AM, Greg KH wrote: >> Note, there are "cheap" USB monitors that can be quite handy and that work >> on Linux: >> http://www.totalphase.com/products/beagle-usb12/ > > USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 01:51 AM, Hayes Wang wrote: > > Forgive me. I provide wrong information. This is about RTL8153, not RTL8152. No problem. Thanks for trying though.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 07:34 AM, Mark Lord wrote: > On 16-11-25 04:53 AM, Greg KH wrote: >> Note, there are "cheap" USB monitors that can be quite handy and that work >> on Linux: >> http://www.totalphase.com/products/beagle-usb12/ > > USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 01:51 AM, Hayes Wang wrote: > > Forgive me. I provide wrong information. This is about RTL8153, not RTL8152. No problem. Thanks for trying though.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-25 01:11 AM, Hayes Wang wrote: > Mark Lord [mailto:ml...@pobox.com] .. >> If that "return 0" statement is ever executed, doesn't it result >> in the loss/leak of a buffer? > > They would be found back by calling rtl_start_rx(), when the rx > is restarted. Good. I figured it was probably

<    1   2   3   4   5   6   7   8   9   10   >