net-next is closed anyway.
--
Ueimor
Chunhao Lin :
[...]
> @@ -5878,6 +5881,20 @@ static void rtl_pcie_state_l2l3_enable(struct
> rtl8169_private *tp, bool enable)
> RTL_W8(Config3, data);
> }
>
> +static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private *tp,
> + bool enable)
> +{
>
Peter Zijlstra :
> On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote:
> > Peter Zijlstra :
> > [...]
> > > There is only 1 variable afaict. Memory barriers need at least 2 in
> > > order to be able to do _anything_.
> >
> > I don&
Jia-Ju Bai :
>
> On 2018/1/19 9:11, Francois Romieu wrote:
> > Jia-Ju Bai :
> > [...]
> > > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> > > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
>
Jia-Ju Bai :
[...]
> The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
> netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
> goto err_stop_0;
> }
> But there is no
Peter Zijlstra :
[...]
> There is only 1 variable afaict. Memory barriers need at least 2 in
> order to be able to do _anything_.
I don't get your point: why don't {cur_tx, dirty_tx} qualify as said
two variables ?
--
Ueimor
David Miller :
[...]
> The amount of coverage this change is going to get is very small as
> well, meaning an even greater chance of regressions.
Yes.
> Therefore the only acceptable way to handle this is to have
> a white-list, specific chips that have been explicitly tested
> and are known to
Kirill Smelkov :
[...]
> I was keeping you in To and Cc all the time but got no reply at all since my
> first posting from ~ 1 month ago.
I thought it was longer than that. Sorry for the frustrating excess delay.
As Eric already said there is no problem and I am perfectly fine with
the current a
Daniel Drake :
[...]
> Also, is there a standard behaviour defined for ethernet drivers
> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
> if it believes the hardware is capable of it,
If so it isn't its designed behavior.
The r8169 driver does not enable specific WoL even
David Miller :
[...]
> Oops, this will need to be sent as a relative fixup as I've applied these
> two patches to net-next, sorry Francois.
No problem. It works perfectly this way.
--
Ueimor
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 8480dbf..a043fb1 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
[...]
> @@ -506,8 +506,9 @@ static void dscc4_release_ring(struct dscc4_dev_priv
> *dpriv)
> skbuff = d
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 799830f..6a9ffac 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
> @@ -518,23 +518,31 @@ static void dscc4_release_ring(struct dscc4_dev_priv
> *dpriv)
> static inline int t
Alexey Khoroshilov :
> The driver does not check if mapping dma memory succeed.
> The patch adds the checks and failure handling.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Please amend your subject line as:
Subject: [PATCH net-nex
Aviad Krawczyk :
[...]
> module_pci_driver - is not used in other drivers in the same segments, it
> is necessary ?
/me checks... Ok, there seems to be some overenthusiastic copy'paste.
See drivers/net/ethernet/intel/ixgb/ixgb_main.c:
[...]
/**
* ixgb_init_module - Driver Registration Routine
Aviad Krawczyk :
[...]
> hinic_remove - If insmod failed and someone calls rmmod, we will get a
> crash because the resource are already free. Therefore we test if the
> device exists, please tell me if you meant to something different
The module won't even proceed through the pci_driver remove m
Aviad Krawczyk :
[...]
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
> b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
> new file mode 100644
> index 000..fbc9de4
> --- /dev/null
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
[...]
> +/**
> + * hinic_init_hwdev
David Miller :
> From: Joshua Emele
> Date: Wed, 24 May 2017 15:43:18 -0700
[...]
> > The sky2_hw_down uses sky2_tx_complete to free pending frames stuck in
> > the HW queue. Because sky2_hw_down can be called from a process context,
> > the call to u64_stats_update_begin can result in deadlock.
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/ethernet/natsemi/ns83820.c
> b/drivers/net/ethernet/natsemi/ns83820.c
> index 729095db3e08..dfc64e1e31f9 100644
> --- a/drivers/net/ethernet/natsemi/ns83820.c
> +++ b/drivers/net/ethernet/natsemi/ns83820.c
[...]
> @@ -1183,6 +1193,32 @@ static
David Miller :
[...]
> One theory is that the interrupt masking isn't working properly
> and interrupts are still arriving and hitting the NAPI state even
> when we are actively polling NAPI.
>
> And this problem was masked by the locking done here.
Yes.
Ville, can you rule out irq sharing betw
Eric Dumazet :
> On Tue, Jan 10, 2017 at 9:35 AM, Cong Wang wrote:
> > On Mon, Jan 9, 2017 at 9:20 AM, Andrey Konovalov
> > wrote:
> >
> > The fix should be straight-forward. Mind to try the attached patch?
>
>
> You forgot to remove schedule() ?
It may be clearer to split alloc_tx in two pa
Pavel Machek :
[...]
> Considering the memory barriers... is something like this neccessary
> in the via-rhine ?
Yes.
> AFAICT... we need a barrier after making sure that descriptor is no
> longer owned by DMA (to make sure we don't get stale data in rest of
> descriptor)... and we need a barrie
Pavel Machek :
[...]
> Won't this up/down the interface, in a way userspace can observe?
It won't up/down the interface as it doesn't exactly mimic what the
network code does (there's more than rtnl_lock).
For the same reason it's broken if it races with the transmit path: it
can release driver
Lino Sanfilippo :
[...]
> OTOH Pavel said that he actually could produce a deadlock. Now I wonder if
> this is caused by that locking scheme (in a way I have not figured out yet)
> or if it is a different issue.
stmmac_tx_err races with stmmac_xmit.
--
Ueimor
Lino Sanfilippo :
> The driver uses a private lock for synchronization between the xmit
> function and the xmit completion handler, but since the NETIF_F_LLTX flag
> is not set, the xmit function is also called with the xmit_lock held.
>
> On the other hand the xmit completion handler first takes
Mark Lord :
[...]
> >From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
>
> The driver itself NEVER writes anything to that buffe
Hayes Wang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
> > Sent: Friday, November 11, 2016 8:13 PM
> [...]
> > Invalid packet size corrupted receive descriptors in Realtek's device
> > reminds of CVE-2009-4537.
>
> Do you mean that the driver would get
Hayes Wang :
> For some platforms, the data in memory is not the same with the one
> from the device. That is, the data of memory is unbelievable. The
> check is used to find out this situation.
Invalid packet size corrupted receive descriptors in Realtek's device
reminds of CVE-2009-4537.
Is th
d-udevd Not tainted 4.8.0+ #35
> Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
>
> on systems without memory that is 32-bit addressable by PCI devices.
>
> Signed-off-by: Ard Biesheuvel
Acked-by: Francois Romieu
Unless someone plans to plug an acenic, a 8382
Colin King :
> From: Colin Ian King
>
> tdinfo->skb_dma is a 7 element array of dma_addr_t hence cannot be
> null, so the pull pointer check on tdinfo->skb_dma is redundant.
> Remove it.
>
> Signed-off-by: Colin Ian King
Acked-by: Francois Romieu
--
Ueimor
Salil Kapur :
> I was looking at v3.12. Can we submit patches for stable versions?
It has already been fixed in 3.12.8 as 56399d8b44beae5b80e1eda0350ab6af72baf4d0
("netpoll: Fix missing TXQ unlock and and OOPS.") by davem.
3.12.8 dates back to 2014/01. The current 3.12.x version is 3.12.62.
--
Salil Kapur :
[...]
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index fc75c9e..9124f76 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -386,8 +386,10 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct
> sk_buff *skb,
>
Eric Dumazet :
[...]
> I would prefer having a definitive advice from Thomas Gleixner and/or
> others if disable_irq() is forbidden from IRQ path.
>
> As I said, about all netpoll() methods in net drivers use disable_irq()
> so a lot of patches would be needed.
s/about all/many/
There has been
Hau :
[...]
> > Either the driver resumes the device so that it can perform requested
> > operation or it signals .set_wol failure when the device is suspended.
> >
> > If the driver does something else, "spam removal" translates to "silent
> > failure".
>
> Because "tp->saved_wolopts" will be u
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 0e62d74..f07604f 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -1749,13 +1749,21 @@ static u32 __rtl8169_get_wol(struct
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 0e62d74..f07604f 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -1852,12 +1863,17 @@ static int rtl8169_set_wol(str
Netanel Belgazal :
[...]
> > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h
> > b/drivers/net/ethernet/amazon/ena/ena_com.h
> > new file mode 100644
> > index 000..e49ba43
> > --- /dev/null
> > [...]
> > +static inline void ena_com_update_intr_reg(struct ena_eth_io_intr_reg
> > *intr
Netanel Belgazal :
[...]
More stuff below.
> diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c
> b/drivers/net/ethernet/amazon/ena/ena_com.c
> new file mode 100644
> index 000..357e10f
> --- /dev/null
> +++ b/drivers/net/ethernet/amazon/ena/ena_com.c
[...]
> +static int ena_get_dev_sta
Netanel Belgazal :
[...]
Very limited review below.
> diff --git a/Documentation/networking/ena.txt
> b/Documentation/networking/ena.txt
> new file mode 100644
> index 000..528544f
> --- /dev/null
> +++ b/Documentation/networking/ena.txt
> @@ -0,0 +1,330 @@
> +Linux kernel driver for Elasti
Paul Menzel :
[...]
> As over five years have passed now, do you think that is still needed?
> I wonder why no module parameter was added back then, where users could
> enable ASPM if it works on their systems? Because there is no such
> situation and it always fails?
It was enabled again (d64ec8
Florian Westphal :
> Francois Romieu wrote:
[...]
> > Play it safe and keep the implicit local_irq_{save / restore} call ?
> >
> > It may not be needed but it will help avoiding any unexpected regression
> > report pointing at the NETDEV_TX_LOCKED removal change.
&g
Florian Westphal :
[...]
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index d0084d4..a3200ea 100644
> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
[...]
> @@ -2
tially infinite loop of
> out-of-bounds accesses.
>
> Signed-off-by: Rasmus Villemoes
(ok, i is signed)
Reviewed-by: Francois Romieu
Someone messed with my review on 2014/03/25 and got it wrong. :o/
Two years after the initial submission, there is zero change regarding use
of
Toralf Förster :
> Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack.
> I do wonder if the DMAR events points to an issue in the kernel ?
Please send a compressed log including all 'fault addr' lines as well
as the (module probe time) XID line from the r8169 driver.
--
Hau :
[...]
> Unless pcie nic has bug, pcie nic does not need to reset phy to let phy link
> on.
>
> There is a counter for phy speed down. If phy is in link down state, this
> counter will start to count down. When it count to 0, phy will speed down.
> Reset phy will reset this counter and pre
Chunhao Lin :
> For pcie nic, after setting link speed and thers is no link driver does not
> need
> to do phy reset untill link up.
>
> For some pcie nics, to do this will also reset phy speed down counter and
> prevent
> phy from auto speed down.
>
> This patch fix the issue reported in fol
Mike Galbraith :
[...]
> Hrm, relatively new + tasklet woes rings a bell. Ah, that..
>
>
> What's worse is that at the point where this code was written it was
> already well known that tasklets are a steaming pile of crap and
> should die.
>
>
> Source thereof https://lwn.net/Articles/588457
Chunhao Lin :
> When there is no AC power, NIC doesn't work after changing mac address.
> Please refer to following link.
> http://www.spinics.net/lists/netdev/msg356572.html
>
> This issue is caused by runtime power management. When there is no AC power,
> if we
> put NIC down (ifconfig down),
Chunhao Lin :
[...]
Fine with me.
Is there any chance for the set of chipset dependent registers that
are safe to be read when in D3 state to be documented ?
--
Ueimor
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 537974c..404be51 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -7853,6 +7859,11 @@ static int rtl8169_runtime_susp
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 537974c..a645f8d 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7730,10 +7730,13 @@ rtl8169_get_stats64(struct net_devic
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
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
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 @@ dm9000_probe(
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 "unsubscribe
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 and
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
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 fo
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 them
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)
>
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)
> }
>
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 ok
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)
> macc
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)
>
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
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, int
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 a
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 co
*ent)
> out:
> return rc;
>
> -err_out_msi_4:
> +err_out_msi_5:
> + dma_free_coherent(&pdev->dev, sizeof(*tp->CntArray), tp->CntArray,
> + tp->CntPhysAddr);
> +err_out_cnt_4:
> netif_napi_del(&tp->napi);
These label
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;
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: neithe
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 mayb
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 m
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 ar
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 t
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, especi
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 @@ sta
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 @@ stati
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
> + *
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 thi
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 rtl8169_priva
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 majordomo
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 descriptor reads a
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
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 work-arou
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
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
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(...)
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 rtl_w0w1_eri(struc
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
some
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 ?
- rtl_w1w0_ph
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
> +
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
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 .driver.pm
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_set_features and keep
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 major
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 1006
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 (tp->rtl_fw.fw
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 keep
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
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
> > adds
1 - 100 of 461 matches
Mail list logo
