Re: [PATCH net] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

Chunhao Lin : [...] > I add checking driver's pm runtime status in rtl8169_get_stats64() to fix > this issue. Would you consider taking the device out of suspended mode during rtl8169_get_stats64 to prevent outdated stats ? -- Ueimor

Re: [PATCH net] r8169:fix "rtl_counters_cond == 1 (loop: 1000, delay: 10)" log spam.

Chunhao Lin : [...] > I add checking driver's pm runtime status in rtl8169_get_stats64() to fix > this issue. Would you consider taking the device out of suspended mode during rtl8169_get_stats64 to prevent outdated stats ? -- Ueimor

Re: [PATCH v2] net: ethernet: davicom: fix devicetree irq resource

Robert Jarzmik : > Francois Romieu writes: [...] > > If you have some spare time, it would be nice to avoid db->irq_wake leak > > on probe failure or driver removal. > Sorry but not in this patch. Of course. Different topic => different patch. > I suppose the right

Re: [PATCH v2] net: ethernet: davicom: fix devicetree irq resource

Robert Jarzmik : [...] > diff --git a/drivers/net/ethernet/davicom/dm9000.c > b/drivers/net/ethernet/davicom/dm9000.c > index cf94b72dbacd..2bae5c8c1f85 100644 > --- a/drivers/net/ethernet/davicom/dm9000.c > +++ b/drivers/net/ethernet/davicom/dm9000.c [...] > @@ -1500,15 +1496,21 @@

Re: [PATCH v2] net: ethernet: davicom: fix devicetree irq resource

Robert Jarzmik : [...] > diff --git a/drivers/net/ethernet/davicom/dm9000.c > b/drivers/net/ethernet/davicom/dm9000.c > index cf94b72dbacd..2bae5c8c1f85 100644 > --- a/drivers/net/ethernet/davicom/dm9000.c > +++ b/drivers/net/ethernet/davicom/dm9000.c [...] > @@ -1500,15

Re: [PATCH v2] net: ethernet: davicom: fix devicetree irq resource

Robert Jarzmik <robert.jarz...@free.fr> : > Francois Romieu <rom...@fr.zoreil.com> writes: [...] > > If you have some spare time, it would be nice to avoid db->irq_wake leak > > on probe failure or driver removal. > Sorry but not in this patch. Of course. Differe

Re: [PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt()

SF Markus Elfring : > From: Markus Elfring > Date: Sat, 2 Jan 2016 15:25:34 +0100 > > Replace explicit initialisation for two local variables at the beginning > by assignments. It makes no sense for the 'adapter' variable. -- Ueimor -- To unsubscribe from this list: send the line

Re: [PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt()

SF Markus Elfring : > From: Markus Elfring > Date: Sat, 2 Jan 2016 15:25:34 +0100 > > Replace explicit initialisation for two local variables at the beginning > by assignments. It makes no sense for the 'adapter' variable. --

Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection

Julia Lawall : > On Fri, 1 Jan 2016, SF Markus Elfring wrote: [...] > > > Normally, one returns -ENOMEM for this case, but it looks like this > > > function is returning 0 on failure. > > > > Should a symbol like "false" be used instead of such a special number? > > Maybe it's better than 0

Re: [PATCH 1/3] net-gianfar: Less function calls in gfar_ethflow_to_filer_table() after error detection

Julia Lawall : > On Fri, 1 Jan 2016, SF Markus Elfring wrote: [...] > > > Normally, one returns -ENOMEM for this case, but it looks like this > > > function is returning 0 on failure. > > > > Should a symbol like "false" be used instead of such a special number? > > Maybe

Re: [PATCH net-next 1/3] r8169:Fix typo in setting RTL8168EP and RTL8168H D3cold PFM mode

Chunhao Lin : > The register for setting D3code PFM mode is MISC_1, not DLLPR. > > Signed-off-by: Chunhao Lin Reviewed-by: Francois Romieu -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@v

Re: [PATCH net-next 1/3] r8169:Fix typo in setting RTL8168EP and RTL8168H D3cold PFM mode

Chunhao Lin <h...@realtek.com> : > The register for setting D3code PFM mode is MISC_1, not DLLPR. > > Signed-off-by: Chunhao Lin <h...@realtek.com> Reviewed-by: Francois Romieu <rom...@fr.zoreil.com> -- Ueimor -- To unsubscribe from this list: send the lin

Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to order 4 allocation

Pavel Machek : [...] > Ok, so what went on is easy.. any ideas how to fix it ? The driver should 1) prohibit holes in its receive ring, 2) allocate before pushing data up in the stack 3) drop packets when it can't allocate a fresh buffer and 4) stop releasing receive buffers - and any resource

Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to order 4 allocation

Pavel Machek : [...] > Ok, so what went on is easy.. any ideas how to fix it ? The driver should 1) prohibit holes in its receive ring, 2) allocate before pushing data up in the stack 3) drop packets when it can't allocate a fresh buffer and 4) stop releasing receive buffers - and

Re: severe regression in alx ethernet driver

Jarod Wilson : [...] > They do at least have a signed-off-by in the patches attached to the bug, > so I'm working on touching up the descriptions and formatting, regression > testing them on my laptop that has an alx-driven E2200 in it (which isn't > affected by this bug), and then I can ship

Re: severe regression in alx ethernet driver

Jarod Wilson : [...] > They do at least have a signed-off-by in the patches attached to the bug, > so I'm working on touching up the descriptions and formatting, regression > testing them on my laptop that has an alx-driven E2200 in it (which isn't > affected by this bug), and

Re: [PATCH 3/3 v2] dl2k: Implement suspend

Ondrej Zary : [...] > diff --git a/drivers/net/ethernet/dlink/dl2k.c > b/drivers/net/ethernet/dlink/dl2k.c > index 9e9baa0..28a96d3 100644 > --- a/drivers/net/ethernet/dlink/dl2k.c > +++ b/drivers/net/ethernet/dlink/dl2k.c [...] > @@ -1824,11 +1831,55 @@ rio_remove1 (struct pci_dev *pdev) >

Re: [PATCH 3/3 v2] dl2k: Implement suspend

Ondrej Zary : [...] > diff --git a/drivers/net/ethernet/dlink/dl2k.c > b/drivers/net/ethernet/dlink/dl2k.c > index 9e9baa0..28a96d3 100644 > --- a/drivers/net/ethernet/dlink/dl2k.c > +++ b/drivers/net/ethernet/dlink/dl2k.c [...] > @@ -1824,11 +1831,55 @@ rio_remove1

Re: [PATCH 3/3] dl2k: Implement suspend

Ondrej Zary : [...] > diff --git a/drivers/net/ethernet/dlink/dl2k.c > b/drivers/net/ethernet/dlink/dl2k.c > index 9e9baa0..b53dfa7 100644 > --- a/drivers/net/ethernet/dlink/dl2k.c > +++ b/drivers/net/ethernet/dlink/dl2k.c > @@ -1824,11 +1824,57 @@ rio_remove1 (struct pci_dev *pdev) > } >

Re: [PATCH 1/3] dl2k: Handle memory allocation errors in alloc_list

Ondrej Zary : > If memory allocation fails in alloc_list(), free the already allocated > memory and return -ENODEV. In rio_open(), call alloc_list() first and > abort if it fails. Move HW access (set RFDListPtr) out ot alloc_list(). > > Signed-off-by: Ondrej Zary ENODEV vs ENOMEM aside, it's

Re: [PATCH 1/3] dl2k: Handle memory allocation errors in alloc_list

Ondrej Zary : > If memory allocation fails in alloc_list(), free the already allocated > memory and return -ENODEV. In rio_open(), call alloc_list() first and > abort if it fails. Move HW access (set RFDListPtr) out ot alloc_list(). > > Signed-off-by: Ondrej Zary

Re: [PATCH 3/3] dl2k: Implement suspend

Ondrej Zary : [...] > diff --git a/drivers/net/ethernet/dlink/dl2k.c > b/drivers/net/ethernet/dlink/dl2k.c > index 9e9baa0..b53dfa7 100644 > --- a/drivers/net/ethernet/dlink/dl2k.c > +++ b/drivers/net/ethernet/dlink/dl2k.c > @@ -1824,11 +1824,57 @@ rio_remove1 (struct

Re: [PATCH] dl2k: Implement suspend

Ondrej Zary : [...] > diff --git a/drivers/net/ethernet/dlink/dl2k.c > b/drivers/net/ethernet/dlink/dl2k.c > index ccca479..23d13c5 100644 > --- a/drivers/net/ethernet/dlink/dl2k.c > +++ b/drivers/net/ethernet/dlink/dl2k.c [..] > @@ -522,6 +515,28 @@ rio_open (struct net_device *dev) >

Re: [PATCH] dl2k: Implement suspend

Ondrej Zary : [...] > diff --git a/drivers/net/ethernet/dlink/dl2k.c > b/drivers/net/ethernet/dlink/dl2k.c > index ccca479..23d13c5 100644 > --- a/drivers/net/ethernet/dlink/dl2k.c > +++ b/drivers/net/ethernet/dlink/dl2k.c [..] > @@ -522,6 +515,28 @@ rio_open (struct

Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Mans Rullgard : > diff --git a/drivers/net/ethernet/aurora/nb8800.c > b/drivers/net/ethernet/aurora/nb8800.c > new file mode 100644 > index 000..11cd389 > --- /dev/null > +++ b/drivers/net/ethernet/aurora/nb8800.c [...] > +static int nb8800_xmit(struct sk_buff *skb, struct net_device *dev) >

Re: [PATCH v5] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Mans Rullgard : > diff --git a/drivers/net/ethernet/aurora/nb8800.c > b/drivers/net/ethernet/aurora/nb8800.c > new file mode 100644 > index 000..11cd389 > --- /dev/null > +++ b/drivers/net/ethernet/aurora/nb8800.c [...] > +static int nb8800_xmit(struct sk_buff *skb, struct

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Måns Rullgård : > Francois Romieu writes: [...] > > It looks like it receives, then tries to allocate new resources. If so > > it may deplete the ring and you should instead consider allocating new > > resources first, then receive data if alloc + map suceeded. > > Th

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Måns Rullgård <m...@mansr.com> : > Francois Romieu <rom...@fr.zoreil.com> writes: [...] > > It looks like it receives, then tries to allocate new resources. If so > > it may deplete the ring and you should instead consider allocating new > > resources first,

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Mans Rullgard : [...] > diff --git a/drivers/net/ethernet/aurora/nb8800.c > b/drivers/net/ethernet/aurora/nb8800.c > new file mode 100644 > index 000..ce61439 > --- /dev/null > +++ b/drivers/net/ethernet/aurora/nb8800.c [...] > +static int nb8800_mdio_read(struct mii_bus *bus, int phy_id,

Re: [PATCH v4] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

Mans Rullgard : [...] > diff --git a/drivers/net/ethernet/aurora/nb8800.c > b/drivers/net/ethernet/aurora/nb8800.c > new file mode 100644 > index 000..ce61439 > --- /dev/null > +++ b/drivers/net/ethernet/aurora/nb8800.c [...] > +static int nb8800_mdio_read(struct mii_bus

Re: [PATCH] via-rhine: fix VLAN receive handling error in 4.2.x

Andrej Ota : > Fixes commit 810f19bcb862 ("via-rhine: add consistent memory barrier in > vlan receive code.") which broke VLAN tag parsing on receive. > > Because eth_type_trans() consumes ethernet header worth of bytes, a call > to read TCI from packet using rhine_rx_vlan_tag() no longer works

Re: [PATCH] via-rhine: fix VLAN receive handling error in 4.2.x

Andrej Ota : > Fixes commit 810f19bcb862 ("via-rhine: add consistent memory barrier in > vlan receive code.") which broke VLAN tag parsing on receive. > > Because eth_type_trans() consumes ethernet header worth of bytes, a call > to read TCI from packet using rhine_rx_vlan_tag()

Re: via-rhine: fix VLAN receive handling error in 4.2.x

Andrej : [...] > Choosing between changing rhine_get_vlan_tci(), which retrieves TCI from > skb->data, or moving eth_type_trans() invocation after rhine_rx_vlan_tag(), > I chose the latter. Can you send a patch with a proper Signed-off-by and a single line 'Fixes: 810f19bcb862 ("via-rhine: add

Re: via-rhine: fix VLAN receive handling error in 4.2.x

Andrej : [...] > Choosing between changing rhine_get_vlan_tci(), which retrieves TCI from > skb->data, or moving eth_type_trans() invocation after rhine_rx_vlan_tag(), > I chose the latter. Can you send a patch with a proper Signed-off-by and a single line 'Fixes: 810f19bcb862

Re: [PATCH v2] r8169: Fix sleeping function called during get_stats64

> return rc; > > -err_out_msi_4: > +err_out_msi_5: > + dma_free_coherent(>dev, sizeof(*tp->CntArray), tp->CntArray, > + tp->CntPhysAddr); > +err_out_cnt_4: > netif_napi_del(>napi); These labels are supposed to suggest what sho

Re: [PATCH net] r8169: Fix sleeping function called during get_stats64

Corinna Vinschen : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 24dcbe6..630811a 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > + if (!paddr) > + return false;

Re: [PATCH v2] r8169: Fix sleeping function called during get_stats64

*ent) > out: > return rc; > > -err_out_msi_4: > +err_out_msi_5: > + dma_free_coherent(>dev, sizeof(*tp->CntArray), tp->CntArray, > + tp->CntPhysAddr); > +err_out_cnt_4: > netif_napi_del(>napi); These labels are supposed

Re: [PATCH net] r8169: Fix sleeping function called during get_stats64

Corinna Vinschen : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 24dcbe6..630811a 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > + if (!paddr) > +

Re: [RFC, RFT PATCH 1/2] dl2k: Add support for IP1000A-based cards

Ondrej Zary : [...] > Actually, gigabit works with this patch. The "PHY magic" part contains > mii_write(9, 0x0700) which makes gigabit work. It'd be extatic if you could set mii->supports_gmii for the appropriate PHY so that dl2k.c::rio_get_settings returns sensible gigabit status (note:

Re: [RFC, RFT PATCH 1/2] dl2k: Add support for IP1000A-based cards

Ondrej Zary li...@rainbow-software.org : [...] Actually, gigabit works with this patch. The PHY magic part contains mii_write(9, 0x0700) which makes gigabit work. It'd be extatic if you could set mii-supports_gmii for the appropriate PHY so that dl2k.c::rio_get_settings returns sensible

Re: ipg and dl2k mess

Ondrej Zary : [...] > The patch below is enough to make my IP1000A card work with dl2k driver - no > more lost packets and hangs. Haven't tested gigabit speed yet - the PHY will > probably need some tweaking but that should be easy. Neither dl2k nor ipg uses napi. They are a bit dusty. > So

Re: ipg and dl2k mess

Ondrej Zary li...@rainbow-software.org : [...] The patch below is enough to make my IP1000A card work with dl2k driver - no more lost packets and hangs. Haven't tested gigabit speed yet - the PHY will probably need some tweaking but that should be easy. Neither dl2k nor ipg uses napi. They are

Re: [PATCH] sky2: Add module parameter for passing the MAC address

Liviu Dudau : > On Wed, Aug 05, 2015 at 05:40:57PM +0100, Stephen Hemminger wrote: [...] > > Yes, I can see that this can be a real problem, and other drivers > > solve the problem. The standard method is to assign a random mac address > > (and then let scripts overwrite) rather than introducing

Re: [PATCH] sky2: Add module parameter for passing the MAC address

Liviu Dudau liviu.du...@arm.com : On Wed, Aug 05, 2015 at 05:40:57PM +0100, Stephen Hemminger wrote: [...] Yes, I can see that this can be a real problem, and other drivers solve the problem. The standard method is to assign a random mac address (and then let scripts overwrite) rather than

Re: [PATCH] wan: dscc4: use msecs_to_jiffies for conversions

David Miller : [...] > Whoever wrote these things probably wanted whatever this amounts > to when HZ=100, so that is the only valid transformation you can > make to fix this up here. It's linux kernel illiterate style from 13 years ago but I commented dscc4_pci_reset. wait_ack_cec and xpr_ack

Re: [PATCH] wan: dscc4: use msecs_to_jiffies for conversions

David Miller da...@davemloft.net : [...] Whoever wrote these things probably wanted whatever this amounts to when HZ=100, so that is the only valid transformation you can make to fix this up here. It's linux kernel illiterate style from 13 years ago but I commented dscc4_pci_reset.

Re: [net:r8169] kernel 4.0.0 double "link down" on boot

rh_ : > I see these double "link down" now in 4.0 > > [ 19.927880] r8169 :03:00.2 eth0: link down > [ 19.927902] r8169 :03:00.2 eth0: link down > [ 22.32] r8169 :03:00.2 eth0: link up > > Everything seems to be working fine. Is this an indicator of a problem? No. > Safe

Re: [net:r8169] kernel 4.0.0 double link down on boot

rh_ richard_hubb...@lavabit.com : I see these double link down now in 4.0 [ 19.927880] r8169 :03:00.2 eth0: link down [ 19.927902] r8169 :03:00.2 eth0: link down [ 22.32] r8169 :03:00.2 eth0: link up Everything seems to be working fine. Is this an indicator of a

Re: [PATCH v1] mv643xx_eth: only account for work done in rxq_process in poll callback.

Nicolas Schichan : [...] > I was trying to minimize the code changes wrt the current source, but if you > want that change to be in the same patch, I can certainly respin a V2 with it. No need to respin, you elegantly minimized the changes. The body of the while loop could be more spartan,

Re: [PATCH v1] mv643xx_eth: only account for work done in rxq_process in poll callback.

Nicolas Schichan nschic...@freebox.fr : [...] I was trying to minimize the code changes wrt the current source, but if you want that change to be in the same patch, I can certainly respin a V2 with it. No need to respin, you elegantly minimized the changes. The body of the while loop could be

Re: [PATCH v1] mv643xx_eth: only account for work done in rxq_process in poll callback.

Nicolas Schichan : [...] > diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c > b/drivers/net/ethernet/marvell/mv643xx_eth.c > index 1c75829..52bc56b 100644 > --- a/drivers/net/ethernet/marvell/mv643xx_eth.c > +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c [...] > @@ -1050,7 +1049,7 @@

Re: [PATCH v1] mv643xx_eth: only account for work done in rxq_process in poll callback.

Nicolas Schichan nschic...@freebox.fr : [...] diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index 1c75829..52bc56b 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c [...] @@ -1050,7

Re: [PATCH] atheros/atlx: Simplify bit manipulations

Rasmus Villemoes : [...] > diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c > b/drivers/net/ethernet/atheros/atlx/atl2.c > index 84a09e8ddd9c..46d1b959daa8 100644 > --- a/drivers/net/ethernet/atheros/atlx/atl2.c > +++ b/drivers/net/ethernet/atheros/atlx/atl2.c > @@ -1278,14 +1278,10 @@

Re: [PATCH] atheros/atlx: Simplify bit manipulations

Rasmus Villemoes li...@rasmusvillemoes.dk : [...] diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c b/drivers/net/ethernet/atheros/atlx/atl2.c index 84a09e8ddd9c..46d1b959daa8 100644 --- a/drivers/net/ethernet/atheros/atlx/atl2.c +++ b/drivers/net/ethernet/atheros/atlx/atl2.c @@

Re: [PATCH] ethernet: atheros: Add nss-gmac driver

Stephen Wang : > This driver adds support for the internal GMACs on IPQ806x SoCs. > It supports the device-tree and will register up to 4 ethernet > interfaces. > > Signed-off-by: Stephen Wang > --- [...] > +/* > + * NSS GMAC data plane ops, default would be slowpath and can be override by > +

Re: [PATCH] ethernet: atheros: Add nss-gmac driver

Stephen Wang wstep...@codeaurora.org : This driver adds support for the internal GMACs on IPQ806x SoCs. It supports the device-tree and will register up to 4 ethernet interfaces. Signed-off-by: Stephen Wang wstep...@codeaurora.org --- [...] +/* + * NSS GMAC data plane ops, default would

Re: [PATCH net-next 0/9] r8169:update hardware ephy parameter

Chunhao Lin : > Update hardware ephy parameter to improve pcie compatibility. Neither the code nor the commit message helps to figure which kind of behavioral change should/could be expected. Bandwidth ? Latency ? Power management ? Compliance ? Stability ? -- Ueimor -- To unsubscribe from

Re: [PATCH net-next 7/9] r8169:update rtl8168dp ephy parameter

Chunhao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index a979519..42eda35 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > static void rtl_hw_start_8168d_4(struct

Re: [PATCH net-next 5/9] r8169:update rtl8168fb ephy parameter

Chunhao Lin : [rtl_hw_start_8168f_1 and rtl_hw_start_8168f_2 changes] Different ephy_info data, same code. You may consider factoring it out. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH net-next 5/9] r8169:update rtl8168fb ephy parameter

Chunhao Lin h...@realtek.com : [rtl_hw_start_8168f_1 and rtl_hw_start_8168f_2 changes] Different ephy_info data, same code. You may consider factoring it out. -- Ueimor -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org

Re: [PATCH net-next 7/9] r8169:update rtl8168dp ephy parameter

Chunhao Lin h...@realtek.com : [...] diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index a979519..42eda35 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c [...] static void rtl_hw_start_8168d_4(struct

Re: [PATCH net-next 0/9] r8169:update hardware ephy parameter

Chunhao Lin h...@realtek.com : Update hardware ephy parameter to improve pcie compatibility. Neither the code nor the commit message helps to figure which kind of behavioral change should/could be expected. Bandwidth ? Latency ? Power management ? Compliance ? Stability ? -- Ueimor -- To

Re: [PATCH 2/3] r8169: Use load_acquire() and store_release() to reduce memory barrier overhead

Alexander Duyck : > On 11/13/2014 01:30 PM, Francois Romieu wrote: > > Alexander Duyck : > > [...] > >> In addition the r8169 uses a rmb() however I believe it is placed > >> incorrectly > >> as I assume it supposed to be ordering descripto

Re: [PATCH 2/3] r8169: Use load_acquire() and store_release() to reduce memory barrier overhead

Alexander Duyck alexander.du...@gmail.com : On 11/13/2014 01:30 PM, Francois Romieu wrote: Alexander Duyck alexander.h.du...@redhat.com : [...] In addition the r8169 uses a rmb() however I believe it is placed incorrectly as I assume it supposed to be ordering descriptor reads after

Re: [PATCH 2/3] r8169: Use load_acquire() and store_release() to reduce memory barrier overhead

Alexander Duyck : [...] > In addition the r8169 uses a rmb() however I believe it is placed incorrectly > as I assume it supposed to be ordering descriptor reads after the check for > ownership. Not exactly. It's a barrier against compiler optimization from 2004. It should not matter. However I

Re: [PATCH 2/3] r8169: Use load_acquire() and store_release() to reduce memory barrier overhead

Alexander Duyck alexander.h.du...@redhat.com : [...] In addition the r8169 uses a rmb() however I believe it is placed incorrectly as I assume it supposed to be ordering descriptor reads after the check for ownership. Not exactly. It's a barrier against compiler optimization from 2004. It

Re: e100: Laptop battery drain and WoL settings from EEPROM

Ondrej Zary : [...] > > Looks like this laptop is probably WoL-capable even on battery. > > > > Measured the current from AC adapter: > > around 20mA with WoL inactive (shut down from Windows or by power button in > > GRUB) around 40mA with WoL active (shut down from Linux) > > > > So to

Re: e100: Laptop battery drain and WoL settings from EEPROM

Ondrej Zary li...@rainbow-software.org : [...] Looks like this laptop is probably WoL-capable even on battery. Measured the current from AC adapter: around 20mA with WoL inactive (shut down from Windows or by power button in GRUB) around 40mA with WoL active (shut down from Linux) So

Re: [PATCH net-next v2 2/3] r8152: clear theflagofSCHEDULE_TASKLETin tasklet

Hayes Wang : > Francois Romieu [mailto:rom...@fr.zoreil.com] > > Sent: Monday, November 03, 2014 6:53 AM > [...] > > test_and_clear_bit (dense) or clear_bit would be more idiomatic. > > Excuse me. Any suggestion? > Should I use clear_bit directly, or something else

Re: [PATCH net-next v2 2/3] r8152: clear theflagofSCHEDULE_TASKLETin tasklet

Hayes Wang hayesw...@realtek.com : Francois Romieu [mailto:rom...@fr.zoreil.com] Sent: Monday, November 03, 2014 6:53 AM [...] test_and_clear_bit (dense) or clear_bit would be more idiomatic. Excuse me. Any suggestion? Should I use clear_bit directly, or something else? Or, do I have

Re: [PATCH net-next v2 2/3] r8152: clear the flagofSCHEDULE_TASKLET in tasklet

Hayes Wang : > David Miller [da...@davemloft.net] [...] > > If another thread of control sets the bit between the test and the > > clear, you will lose an event. > > It is fine. The flag is used to schedule a tasklet, so if the tasklet is > starting running, all the other plans for scheduling a

Re: [PATCH net-next v2 2/3] r8152: clear the flagofSCHEDULE_TASKLET in tasklet

Hayes Wang hayesw...@realtek.com : David Miller [da...@davemloft.net] [...] If another thread of control sets the bit between the test and the clear, you will lose an event. It is fine. The flag is used to schedule a tasklet, so if the tasklet is starting running, all the other plans for

Re: [PATCH v2 net-next] r8169:add support for RTL8168EP

Hau : [...] > Do you mean I should collect similar hardware parameters setting into one > function ? or I should set hardware parameters according to hardware > feature support version? static void r8168dp_ocp_write(...) [...] static void r8168ep_ocp_write(...) [...] static void ocp_write(...)

Re: [PATCH v2 net-next] r8169:add support for RTL8168EP

Hau h...@realtek.com : [...] Do you mean I should collect similar hardware parameters setting into one function ? or I should set hardware parameters according to hardware feature support version? static void r8168dp_ocp_write(...) [...] static void r8168ep_ocp_write(...) [...] static void

Re: [PATCH v2 net-next] r8169:add support for RTL8168EP

Chun-Hao Lin : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 54476ba..3efdf4d 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > @@ -1276,6 +1273,52 @@ static void

Re: [PATCH v2 net-next] r8169:add support for RTL8168EP

Chun-Hao Lin h...@realtek.com : [...] diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 54476ba..3efdf4d 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c [...] @@ -1276,6 +1273,52 @@ static void

Re: [PATCH net-next 07/10] r8169:change function name of function "rtl_w1w0_eri"

Chun-Hao Lin : > Change the name of this function to "rtl_w0_w1_eri". > It is more suitable for this function's behavior. Afaiks it used to follow the same rule as the one I outlined in the comment to #6/10 for rtl_w0_w1_phy. Could you elaborate (or say so if it should be clear for me after

Re: [PATCH net-next 06/10] r8169:change function name and behavior of function "rtl_w1w0_phy"

Chun-Hao Lin : > Change function name from "rtl_w1w0_phy" to "rtl_w0w1_phy". > And its behavior from "or first then mask" to "mask first then or". - I don't mind if its changed for a reason but the commit message doesn't tell why. Is it related to the overlap of the masks below ? -

Re: [PATCH net-next 06/10] r8169:change function name and behavior of function rtl_w1w0_phy

Chun-Hao Lin h...@realtek.com : Change function name from rtl_w1w0_phy to rtl_w0w1_phy. And its behavior from or first then mask to mask first then or. - I don't mind if its changed for a reason but the commit message doesn't tell why. Is it related to the overlap of the masks below ? -

Re: [PATCH net-next 07/10] r8169:change function name of function rtl_w1w0_eri

Chun-Hao Lin h...@realtek.com : Change the name of this function to rtl_w0_w1_eri. It is more suitable for this function's behavior. Afaiks it used to follow the same rule as the one I outlined in the comment to #6/10 for rtl_w0_w1_phy. Could you elaborate (or say so if it should be clear for

Re: [PATCH net-next] r8169:add support for RTL8168EP

Chun-Hao Lin : > RTL8168EP is Realtek PCIe Gigabit Ethernet controller. > It is a successor chip of RTL8168DP. > > This patch add support for this chip. It does more than that. Did Hayes review it ? > Signed-off-by: Chun-Hao Lin > --- > drivers/net/ethernet/realtek/r8169.c | 611 >

Re: [PATCH net-next] r8169:add support for RTL8168EP

Chun-Hao Lin h...@realtek.com : RTL8168EP is Realtek PCIe Gigabit Ethernet controller. It is a successor chip of RTL8168DP. This patch add support for this chip. It does more than that. Did Hayes review it ? Signed-off-by: Chun-Hao Lin h...@realtek.com ---

Re: [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net

Joe Perches : > On Tue, 2014-09-23 at 21:02 +0200, Francois Romieu wrote: [...] > > How about kernel tinification ? > > The tiny case where a large number of ethernet drivers are included? No. A couple of bytes here and there vs a cosmetic kernel wide change. -- Ueimor -- To u

Re: [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net

Mark Einon : [...] > > No need for the #define here, just assigne et131x_pm_ops to .driver.pm > > directly, its members will be NULL and thus never called. Also, you can > > make et131x_pm_ops const. > > Ok, I can change this. > > Btw, this appears to be a fairly standard way of using

Re: [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net

Mark Einon mark.ei...@gmail.com : [...] No need for the #define here, just assigne et131x_pm_ops to .driver.pm directly, its members will be NULL and thus never called. Also, you can make et131x_pm_ops const. Ok, I can change this. Btw, this appears to be a fairly standard way of using

Re: [RFC PATCH linux-next] et131x: Promote staging et131x driver to drivers/net

Joe Perches j...@perches.com : On Tue, 2014-09-23 at 21:02 +0200, Francois Romieu wrote: [...] How about kernel tinification ? The tiny case where a large number of ethernet drivers are included? No. A couple of bytes here and there vs a cosmetic kernel wide change. -- Ueimor

Re: [PATCH net 1/2] r8169: fix the default setting of rx vlan

Hayes Wang : > Francois Romieu [mailto:rom...@fr.zoreil.com] > > Sent: Saturday, September 13, 2014 3:40 AM > [...] > > The same fix should be relevant for NETIF_F_RXCSUM. You may thus as > > well remove the "changed" test in __rtl8169_se

Re: 3.17-rc5 fails compile (arch/x86/pci/irq.c)

Pete Clements : > Fyi: i386 up -- problem introduced in rc3. Fix available for ~2 weeks: https://lkml.kernel.org/r/1409382916-10649-1-git-send-email-jiang@linux.intel.com -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: 3.17-rc5 fails compile (arch/x86/pci/irq.c)

Pete Clements c...@clem.clem-digital.net : Fyi: i386 up -- problem introduced in rc3. Fix available for ~2 weeks: https://lkml.kernel.org/r/1409382916-10649-1-git-send-email-jiang@linux.intel.com -- Ueimor -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the

Re: [PATCH net 1/2] r8169: fix the default setting of rx vlan

Hayes Wang hayesw...@realtek.com : Francois Romieu [mailto:rom...@fr.zoreil.com] Sent: Saturday, September 13, 2014 3:40 AM [...] The same fix should be relevant for NETIF_F_RXCSUM. You may thus as well remove the changed test in __rtl8169_set_features and keep everything

Re: [PATCH net 1/2] r8169: fix the default setting of rx vlan

Hayes Wang : > If the parameter "features" of __rtl8169_set_features() is equal to > dev->features, the variable "changed" is alwayes 0, and nothing would > be changed. [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 91652e7..f3ce284

Re: [PATCH net 1/2] r8169: fix the default setting of rx vlan

Hayes Wang hayesw...@realtek.com : If the parameter features of __rtl8169_set_features() is equal to dev-features, the variable changed is alwayes 0, and nothing would be changed. [...] diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index

Re: [PATCH net-next 4/4] r8152: support firmware files

Hayes Wang : > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > index 937d132..63542cc 100644 > --- a/drivers/net/usb/r8152.c > +++ b/drivers/net/usb/r8152.c [...] > +static void rtl_request_firmware(struct r8152 *tp) > +{ > + char *fw_name = NULL; > + > + if

Re: [PATCH net-next 4/4] r8152: support firmware files

Hayes Wang hayesw...@realtek.com : diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 937d132..63542cc 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c [...] +static void rtl_request_firmware(struct r8152 *tp) +{ + char *fw_name = NULL; + + if

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

Ethan Zhao : [...] > you leave us without a tool to track the net core part. Would you like to > hack the kernel code and rebuild just for peek the dropping packets ? Search 'dropwatch' on your favorite engine search. [...] > More radically, and maybe you should write patches to fix them to

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

Ethan Zhao ethan.ker...@gmail.com : [...] you leave us without a tool to track the net core part. Would you like to hack the kernel code and rebuild just for peek the dropping packets ? Search 'dropwatch' on your favorite engine search. [...] More radically, and maybe you should write patches

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

Ethan Zhao : > On Sat, Jul 19, 2014 at 6:19 PM, Francois Romieu wrote: > > Ethan Zhao : [...] > > I'd rather see ethtool stats provides one of those: > > 1. hardware stats only > Sounds very clear, is it done clear, if so we need other tools ? > Then why net core

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

Ethan Zhao : > ?? 2014??7??192:21??Rajesh Borundia > ?? [...] > > I think ethtool stats are adapter specific. Driver does not maintain > > rx_dropped stats and we also don't get it from adapter. I am not > > sure if ethtool stats should match ifconfig stats as ifconfig also > >

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

Ethan Zhao ethan.ker...@gmail.com : ?? 2014??7??192:21??Rajesh Borundia rajesh.borun...@qlogic.com ?? [...] I think ethtool stats are adapter specific. Driver does not maintain rx_dropped stats and we also don't get it from adapter. I am not sure if ethtool stats should match

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

Ethan Zhao ethan.ker...@gmail.com : On Sat, Jul 19, 2014 at 6:19 PM, Francois Romieu rom...@fr.zoreil.com wrote: Ethan Zhao ethan.ker...@gmail.com : [...] I'd rather see ethtool stats provides one of those: 1. hardware stats only Sounds very clear, is it done clear, if so we need other

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