Hayes Wang :
> Michel D?nzer [mailto:mic...@daenzer.net]
[...]
> > Without this, the ethernet port on my ASUS A88X Pro mainboard stops
> > working sometimes, with messages like these in dmesg:
> >
> > AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0
> > domain=0x001e
Hayes Wang hayesw...@realtek.com :
Michel D?nzer [mailto:mic...@daenzer.net]
[...]
Without this, the ethernet port on my ASUS A88X Pro mainboard stops
working sometimes, with messages like these in dmesg:
AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0
domain=0x001e
and continue after the next the PCI
> reset occurs. This causes the device stays in L2/L3 link state, and the system
> couldn't find the device.
>
> Signed-off-by: Hayes Wang
Acked-by: Francois Romieu
Thanks, the explanation of the race between software induced PCI reset
and transit
be queued and continue after the next the PCI
reset occurs. This causes the device stays in L2/L3 link state, and the system
couldn't find the device.
Signed-off-by: Hayes Wang hayesw...@realtek.com
Acked-by: Francois Romieu rom...@fr.zoreil.com
Thanks, the explanation of the race between software
Richard Weinberger :
> Am 09.07.2014 00:47, schrieb Francois Romieu:
[...]
> > What are you taking about ? netconsole does not need to receive.
>
> Isn't netconsole is only one user of netpoll ?
Out of tree users are irrelevant. See netpoll r
Richard Weinberger :
[...]
> This won't work as netpoll runs with IRQs disabled.
> ->ndo_poll_controller() has to make sure that SKBs can be received and
> transmitted
> while IRQs are off. I thought calling the channel callback by hand would be
> enough to receive SKBs.
What are you taking
Hayes Wang :
> For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, the nic couldn't
> leave the power saving mode of L23 for certain situation. This causes
> the device lost for the system. Disable the L23 mode to avoid it.
Ok with the patch as it exactly addresses the required hw_start
Hayes Wang hayesw...@realtek.com :
For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, the nic couldn't
leave the power saving mode of L23 for certain situation. This causes
the device lost for the system. Disable the L23 mode to avoid it.
Ok with the patch as it exactly addresses the
Richard Weinberger rich...@nod.at :
[...]
This won't work as netpoll runs with IRQs disabled.
-ndo_poll_controller() has to make sure that SKBs can be received and
transmitted
while IRQs are off. I thought calling the channel callback by hand would be
enough to receive SKBs.
What are you
Richard Weinberger rich...@nod.at :
Am 09.07.2014 00:47, schrieb Francois Romieu:
[...]
What are you taking about ? netconsole does not need to receive.
Isn't netconsole is only one user of netpoll ?
Out of tree users are irrelevant. See netpoll related comments
Luis R. Rodriguez :
> On Sat, Jun 21, 2014 at 12:52:05PM +0200, Francois Romieu wrote:
> > Luis R. Rodriguez :
[...]
> Note that in the worst case if udev is present in the worst case if the
> firmware is not present loading can take up to timeout * num CPUs [0],
> but work
Luis R. Rodriguez mcg...@suse.com :
On Sat, Jun 21, 2014 at 12:52:05PM +0200, Francois Romieu wrote:
Luis R. Rodriguez mcg...@suse.com :
[...]
Note that in the worst case if udev is present in the worst case if the
firmware is not present loading can take up to timeout * num CPUs [0
Luis R. Rodriguez :
> I was just porting over an ethernet driver [0] to use
> request_firmware_nowait()
> since firmware loading seems can take over a minute on one device, while
> at it I noticed no other ethernet drivers yet use this API so figure
> this may be a trend coming if devices are
Luis R. Rodriguez mcg...@suse.com :
I was just porting over an ethernet driver [0] to use
request_firmware_nowait()
since firmware loading seems can take over a minute on one device, while
at it I noticed no other ethernet drivers yet use this API so figure
this may be a trend coming if
Stefan Priebe - Profihost AG :
[...]
> That sounds great! Is there anything I can do or some code I can port to veth?
You may add an empty handler for .ndo_poll_controller in drivers/net/veth.c
and give it a try on current kernel.
It should not be too bad.
--
Ueimor
--
To unsubscribe from
Stefan Priebe - Profihost AG s.pri...@profihost.ag :
[...]
That sounds great! Is there anything I can do or some code I can port to veth?
You may add an empty handler for .ndo_poll_controller in drivers/net/veth.c
and give it a try on current kernel.
It should not be too bad.
--
Ueimor
--
To
Udo van den Heuvel :
[...]
> On two boxes with rtl network chip I see connections going down.
Do you notice netdev watchdog messages in the kernel log ?
[...]
> 3.14.1 has the issue.
Does it qualify as a (recent ?) regression or is it a fresh new setup ?
> How can I fix this more elegantly ?
Udo van den Heuvel udo...@xs4all.nl :
[...]
On two boxes with rtl network chip I see connections going down.
Do you notice netdev watchdog messages in the kernel log ?
[...]
3.14.1 has the issue.
Does it qualify as a (recent ?) regression or is it a fresh new setup ?
How can I fix this more
Darek Marcinkiewicz :
> On Sun, May 04, 2014 at 08:43:51PM +0200, Francois Romieu wrote:
[...]
> > Regarding tx_dnext updates, you may add a short notice in ec_bhf_start_xmit
> > and ec_bhf_process_tx explaining that the periodic poller will somehow end
> > working with th
Darek Marcinkiewicz :
> On Sat, May 03, 2014 at 01:40:29PM +0200, Francois Romieu wrote:
[...]
> Thank you. I am attaching 2 of thse to this repsonse - the other two
> are no longer relevant due to the changes I made into the driver.
> One of the attached patches is slightly modfi
Darek Marcinkiewicz rek...@newterm.pl :
On Sat, May 03, 2014 at 01:40:29PM +0200, Francois Romieu wrote:
[...]
Thank you. I am attaching 2 of thse to this repsonse - the other two
are no longer relevant due to the changes I made into the driver.
One of the attached patches is slightly modfied
Darek Marcinkiewicz rek...@newterm.pl :
On Sun, May 04, 2014 at 08:43:51PM +0200, Francois Romieu wrote:
[...]
Regarding tx_dnext updates, you may add a short notice in ec_bhf_start_xmit
and ec_bhf_process_tx explaining that the periodic poller will somehow end
working with the right value
er work when load increases and
the usual Tx lock avoidance patterns would kick in (current locking is
gross).
Did Beckhoff document their FPGA PCI interface ?
--
Ueimor
>From d2a5bfdc7854e9b3cffcab9249299354fa5037d0 Mon Sep 17 00:00:00 2001
Message-Id:
From: Francois Romieu
Date: Sat, 3 M
:
d2a5bfdc7854e9b3cffcab9249299354fa5037d0.1399110121.git.rom...@fr.zoreil.com
From: Francois Romieu rom...@fr.zoreil.com
Date: Sat, 3 May 2014 11:15:26 +0200
Subject: [PATCH 1/4] ec_bhf: inverted xmas tree.
X-Organisation: Land of Sunshine Inc.
Signed-off-by: Francois Romieu rom...@fr.zoreil.com
---
drivers/net/ethernet/ec_bhf.c | 8
Udo :
[...]
> [354436.656703] r8169 :01:00.0 eth0: Rx ERROR. status = 342ac40d
> [354615.387915] r8169 :01:00.0 eth0: Rx ERROR. status = 342cc075
> (and a load more of them)
>
> What is wrong? Hardware?
Ethernet CRC is wrong.
Which kind of 816x is it (see XID in kernel log) ?
--
Darek Marcinkiewicz :
[changes]
(you may add those after the "---" above the diffstat)
[...]
> diff --git a/drivers/net/ethernet/ec_bh.c b/drivers/net/ethernet/ec_bh.c
> new file mode 100644
> index 000..2ed2cee
> --- /dev/null
> +++ b/drivers/net/ethernet/ec_bh.c
[...]
> +#define
Darek Marcinkiewicz rek...@newterm.pl :
[changes]
(you may add those after the --- above the diffstat)
[...]
diff --git a/drivers/net/ethernet/ec_bh.c b/drivers/net/ethernet/ec_bh.c
new file mode 100644
index 000..2ed2cee
--- /dev/null
+++ b/drivers/net/ethernet/ec_bh.c
[...]
+#define
Udo udo...@xs4all.nl :
[...]
[354436.656703] r8169 :01:00.0 eth0: Rx ERROR. status = 342ac40d
[354615.387915] r8169 :01:00.0 eth0: Rx ERROR. status = 342cc075
(and a load more of them)
What is wrong? Hardware?
Ethernet CRC is wrong.
Which kind of 816x is it (see XID in kernel log)
Struan Bartlett :
[...]
> --- a/drivers/net/netconsole.c2014-03-31 04:40:15.0 +0100
> +++ b/drivers/net/netconsole.c2014-04-01 11:58:50.0 +0100
> @@ -15,6 +15,7 @@
> * generic card hooks
> * works non-modular
> * 2003-09-07
Struan Bartlett struan.bartl...@gmail.com :
[...]
--- a/drivers/net/netconsole.c2014-03-31 04:40:15.0 +0100
+++ b/drivers/net/netconsole.c2014-04-01 11:58:50.0 +0100
@@ -15,6 +15,7 @@
* generic card hooks
* works non-modular
*
hayeswang :
[...]
> Besides, I don't wish to modify the setting by ethtool when re-loading
> the driver or rebooting every time.
Why ?
The recipe is different but there isn't much setup difference between a
module param and an ethtool command that is run through udev. The latter
is more
hayeswang hayesw...@realtek.com :
[...]
Besides, I don't wish to modify the setting by ethtool when re-loading
the driver or rebooting every time.
Why ?
The recipe is different but there isn't much setup difference between a
module param and an ethtool command that is run through udev. The
Hayes Wang :
> The tx descriptor version of RTL8111B belong to RTL_TD_0.
>
> Signed-off-by: Hayes Wang
Acked-by: Francois Romieu
All 8168b chipsets should had shared the same Tx descriptor layout.
2b7b431858c284b62c18baaf2cea571be2797d5a ("r8169: TSO fixes.") got it
righ
Hayes Wang hayesw...@realtek.com :
The tx descriptor version of RTL8111B belong to RTL_TD_0.
Signed-off-by: Hayes Wang hayesw...@realtek.com
Acked-by: Francois Romieu rom...@fr.zoreil.com
All 8168b chipsets should had shared the same Tx descriptor layout
(linux.n...@intel.com removed from the Cc: list)
poma :
[...]
> Francois, do you have this[1] patch applicable for the recent 'r8169.c'?
>
> $ patch -p5 < r8169-xmit.patch
> patching file r8169.c
> Hunk #1 FAILED at 5870.
> Hunk #2 succeeded at 5540 with fuzz 2 (offset -482 lines).
> Hunk #3
(linux.n...@intel.com removed from the Cc: list)
poma pomidorabelis...@gmail.com :
[...]
Francois, do you have this[1] patch applicable for the recent 'r8169.c'?
$ patch -p5 r8169-xmit.patch
patching file r8169.c
Hunk #1 FAILED at 5870.
Hunk #2 succeeded at 5540 with fuzz 2 (offset -482
黃清隆 :
[...]
> diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c
> b/drivers/scsi/arcmsr/arcmsr_hba.c
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-02-20 19:11:05.0 +0800
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-02-21 01:47:26.0 +0800
[...]
> @@ -2894,6 +3372,89 @@
黃清隆 ching2...@areca.com.tw :
[...]
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c
b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-02-20 19:11:05.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-02-21 01:47:26.0 +0800
[...]
@@ -2894,6
hayeswang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
> > Hayes Wang :
> > > Replace netif_rx with netif_receive_skb to avoid disabling irq frequently
> > > for increasing the efficiency.
> >
> > read_bulk_callback is issued in irq context
Hayes Wang :
> Replace netif_rx with netif_receive_skb to avoid disabling irq frequently
> for increasing the efficiency.
read_bulk_callback is issued in irq context. It could thus use plain
spin_lock / spin_unlock instead of the irq disabling version.
--
Ueimor
--
To unsubscribe from this
Hayes Wang hayesw...@realtek.com :
Replace netif_rx with netif_receive_skb to avoid disabling irq frequently
for increasing the efficiency.
read_bulk_callback is issued in irq context. It could thus use plain
spin_lock / spin_unlock instead of the irq disabling version.
--
Ueimor
--
To
hayeswang hayesw...@realtek.com :
Francois Romieu [mailto:rom...@fr.zoreil.com]
Hayes Wang hayesw...@realtek.com :
Replace netif_rx with netif_receive_skb to avoid disabling irq frequently
for increasing the efficiency.
read_bulk_callback is issued in irq context. It could thus use
Sander Eikelenboom :
[...]
> I have got a regression with a 3.14-mw kernel (last commit is
> 4ba9920e5e9c0e16b5ed24292d45322907bb9035):
> It looks like it's related to the rtl8169 ...
>
> --
> Sander
>
> Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here
>
Sander Eikelenboom li...@eikelenboom.it :
[...]
I have got a regression with a 3.14-mw kernel (last commit is
4ba9920e5e9c0e16b5ed24292d45322907bb9035):
It looks like it's related to the rtl8169 ...
--
Sander
Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] [ cut here
Hayes Wang :
[...]
> diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
> index 4b1c0f3..3e09887 100644
> --- a/drivers/net/usb/cdc_ether.c
> +++ b/drivers/net/usb/cdc_ether.c
> @@ -486,6 +486,7 @@ static const struct driver_info wwan_info = {
> #define ZTE_VENDOR_ID
Hayes Wang :
[...]
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index b8bc3eb..a8ea848 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
[...]
> @@ -274,6 +274,9 @@ enum rtl_register_content {
> #define RTL8152_MAX_TX 10
> #define
Hayes Wang hayesw...@realtek.com :
[...]
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b8bc3eb..a8ea848 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
[...]
@@ -274,6 +274,9 @@ enum rtl_register_content {
#define RTL8152_MAX_TX 10
Hayes Wang hayesw...@realtek.com :
[...]
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 4b1c0f3..3e09887 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -486,6 +486,7 @@ static const struct driver_info wwan_info = {
#define
Christophe Leroy :
> The patch adds WAN support for Infineon FALC56 - PEF2256 E1 Chipset.
>
> Signed-off-by: Jerome Chantelauze
> Acked-by: Christophe Leroy
>
> diff -urN a/drivers/net/wan/pef2256.c b/drivers/net/wan/pef2256.c
> --- a/drivers/net/wan/pef2256.c 1970-01-01
Christophe Leroy christophe.le...@c-s.fr :
The patch adds WAN support for Infineon FALC56 - PEF2256 E1 Chipset.
Signed-off-by: Jerome Chantelauze jerome.chantelauze@c-s.fr
Acked-by: Christophe Leroy christophe.le...@c-s.fr
diff -urN a/drivers/net/wan/pef2256.c
Florian Fainelli :
[...]
> How about scheduling the WAN drivers for removal? Does anybody
> actually use them nowadays?
There is still some interest in WAN drivers, see Christophe Leroy
posting on 2013/10/13 "[PATCH] WAN: Adding support for Infineon PEF2256
E1 chipset" (buggy but it's a
Florian Fainelli f.faine...@gmail.com :
[...]
How about scheduling the WAN drivers for removal? Does anybody
actually use them nowadays?
There is still some interest in WAN drivers, see Christophe Leroy
posting on 2013/10/13 [PATCH] WAN: Adding support for Infineon PEF2256
E1 chipset (buggy but
Julia Lawall :
[...]
> There has already been a discussion about this, and a patch has already
> been proposed. It has to do with lock managament. I will look for the
> email.
The underlying problem has to do with disabled irq. netif_receive_skb
assumes irq to be enabled. Current
Julia Lawall julia.law...@lip6.fr :
[...]
There has already been a discussion about this, and a patch has already
been proposed. It has to do with lock managament. I will look for the
email.
The underlying problem has to do with disabled irq. netif_receive_skb
assumes irq to be enabled.
Joe Perches :
[...]
> David selects them regardless.
>
> from Documentation/networking/netdev-FAQ.txt:
I don't believe that those who read Documentation/stable_kernel_rules.txt
will magically read networking/netdev-FAQ.txt as well nor figure that
while they should not mark the patches stables
Joe Perches :
[...]
> diff --git a/Documentation/stable_kernel_rules.txt
> b/Documentation/stable_kernel_rules.txt
> index b0714d8..a2d6da0 100644
> --- a/Documentation/stable_kernel_rules.txt
> +++ b/Documentation/stable_kernel_rules.txt
> @@ -29,6 +29,11 @@ Rules on what kind of patches are
Joe Perches j...@perches.com :
[...]
diff --git a/Documentation/stable_kernel_rules.txt
b/Documentation/stable_kernel_rules.txt
index b0714d8..a2d6da0 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -29,6 +29,11 @@ Rules on what kind of
Joe Perches j...@perches.com :
[...]
David selects them regardless.
from Documentation/networking/netdev-FAQ.txt:
I don't believe that those who read Documentation/stable_kernel_rules.txt
will magically read networking/netdev-FAQ.txt as well nor figure that
while they should not mark the
Igor Gnatenko :
> Since 136d8f377e1575463b47840bc5f1b22d94bf8f63 commit we have kernel
> panic on:
> 01:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
>
> Screen: https://www.dropbox.com/s/mu3t3wxpxbn4ou5/IMAG0507.jpg
>
> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1008323
Igor Gnatenko i.gnatenko.br...@gmail.com :
Since 136d8f377e1575463b47840bc5f1b22d94bf8f63 commit we have kernel
panic on:
01:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
Screen: https://www.dropbox.com/s/mu3t3wxpxbn4ou5/IMAG0507.jpg
RHBZ:
Roberto Spadim :
[...]
> ethtool show eth2 and eth1 as up and running and eth2 as fibre but
> it's a TP board?!
It happens with old model r8169 boards that go south during netdev
whatchdog recovery handler.
Please send the XID line included in dmesg output at startup.
> i'm considering eth2 a
Roberto Spadim robe...@spadim.com.br :
[...]
ethtool show eth2 and eth1 as up and running and eth2 as fibre but
it's a TP board?!
It happens with old model r8169 boards that go south during netdev
whatchdog recovery handler.
Please send the XID line included in dmesg output at startup.
i'm
Keep it small though literate.
---
drivers/net/usb/sr9700.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index f7f46e6..3f05b35 100644
--- a/drivers/net/usb/sr9700.c
+++
Liu, please check those.
---
drivers/net/usb/sr9700.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 3f05b35..3ae3caf 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -99,8 +99,9 @@ static
- use all columns
- the driver uses both 'netdev' and 'net'. Let's use 'netdev' ('net' is
shorter but it tastes of network namespaces)
- don't dereference dev->net when there is a local netdev at hand
- use some existing #define (please check those)
- skb_set_tail_pointer to avoid compiler cast
- use all columns
- the driver uses both 'netdev' and 'net'. Let's use 'netdev' ('net' is
shorter but it tastes of network namespaces)
- don't dereference dev-net when there is a local netdev at hand
- use some existing #define (please check those)
- skb_set_tail_pointer to avoid compiler cast
Liu, please check those.
---
drivers/net/usb/sr9700.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 3f05b35..3ae3caf 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -99,8 +99,9 @@ static
Keep it small though literate.
---
drivers/net/usb/sr9700.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index f7f46e6..3f05b35 100644
--- a/drivers/net/usb/sr9700.c
+++
sr_skb->len = len;
> + sr_skb->data = skb->data + 3;
> + sr_skb->tail = skb->data + len;
> + sr_skb->truesize = len + sizeof(struct sk_buff);
> + usbnet_skb_return(dev, sr_skb)
Anton Arapov :
[...]
> Oh well,... I didn't have a time for this right now, nor project is
> not exactly in the state I'm willing to show (mostly webui)
I have sorted the r8169 oopses by kernel revision to start with the most
recent kernels. I don't get why the r8169 driver appears in the
Anton Arapov an...@redhat.com :
[...]
Oh well,... I didn't have a time for this right now, nor project is
not exactly in the state I'm willing to show (mostly webui)
I have sorted the r8169 oopses by kernel revision to start with the most
recent kernels. I don't get why the r8169 driver
,
+ .disable_hub_initiated_lpm = 1,
+};
Please line things up (see my first review).
[...]
Francois Romieu
?? 2013-08-21 04:46:12
liujunliang_ljl
?? gregkh; sunhecheng; linux-usb; netdev; linux-kernel
?? Re: [PATCH-SR9700] Merge USB 1.1 Ethernet Adapter SR9700
Chris Clayton :
[...]
> [0.207094] acpi PNP0A08:00: ACPI _OSC support notification failed,
> disabling PCIe ASPM
> [0.207155] acpi PNP0A08:00: Unable to request _OSC control (_OSC support
> mask: 0x08)
[...]
> [5.311191] r8169 :07:00.0: can't disable ASPM; OS doesn't have ASPM
liujunliang_ljl :
[...]
> We want to merge SR9700 device driver into the Linux Kernel. The following
> is the Linux 3.10.7 version patch for SR9700, Please give us the assessment
> and support.
Welcome. Go ahead.
[...]
> diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
> new
liujunliang_ljl liujunliang_...@163.com :
[...]
We want to merge SR9700 device driver into the Linux Kernel. The following
is the Linux 3.10.7 version patch for SR9700, Please give us the assessment
and support.
Welcome. Go ahead.
[...]
diff --git a/drivers/net/usb/sr9700.c
Chris Clayton chris2...@gmail.com :
[...]
[0.207094] acpi PNP0A08:00: ACPI _OSC support notification failed,
disabling PCIe ASPM
[0.207155] acpi PNP0A08:00: Unable to request _OSC control (_OSC support
mask: 0x08)
[...]
[5.311191] r8169 :07:00.0: can't disable ASPM; OS
ujhely...@gmail.com :
[...]
> Some phy's can be configured to enable wake on lan (e.g. at803x or marvell
> 88E1318S).
> There is no way how to enable wol on CPSW with such connected phys. This patch
> adds this support. It is provided by calling the phy's related code.
>
> Tested on board with
ujhely...@gmail.com ujhely...@gmail.com :
[...]
Some phy's can be configured to enable wake on lan (e.g. at803x or marvell
88E1318S).
There is no way how to enable wol on CPSW with such connected phys. This patch
adds this support. It is provided by calling the phy's related code.
Tested
Theodore Ts'o :
[...]
> To apply, please send a proposal outlining what you do, what you'd bring
> to the kernel summit
An umbrella to start with. :o)
While the (highly variable amount of) kernel work I do is intellectually
rewarding at times, it's not exactly the kind of cool or important
Theodore Ts'o ty...@thunk.org :
[...]
To apply, please send a proposal outlining what you do, what you'd bring
to the kernel summit
An umbrella to start with. :o)
While the (highly variable amount of) kernel work I do is intellectually
rewarding at times, it's not exactly the kind of cool or
hayeswang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
> > The forward declaration is not needed.
>
> The r8152_submit_rx() need the declaration of read_bulk_callback(), and the
> read_bulk_callback() need the declaration of r8152_submit_rx(), too. It likes
> a
Hayes Wang :
[...]
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 11c51f2..abb0b9f 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
[...]
> @@ -315,13 +318,34 @@ struct tx_desc {
> u32 opts2;
> };
>
> +struct rx_agg {
> + struct
Hayes Wang hayesw...@realtek.com :
[...]
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 11c51f2..abb0b9f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
[...]
@@ -315,13 +318,34 @@ struct tx_desc {
u32 opts2;
};
+struct rx_agg {
+
hayeswang hayesw...@realtek.com :
Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
The forward declaration is not needed.
The r8152_submit_rx() need the declaration of read_bulk_callback(), and the
read_bulk_callback() need the declaration of r8152_submit_rx(), too. It likes
a dead
(no top-post nor lazy quote please)
David Shwatrz :
[...]
> In the napi_gro_receive() we check that the device supports
> NETIF_F_GRO, but I don't see that we inspect checksum or that
> NETIF_F_GRO is depends on checksum.
napi_gro_receive is irrelevant. Let aside tunnel, the real work happens
David Shwatrz :
[...]
> what is the current state of checksum offloading support has to do
> with it ? maybe you meant current state of NAPI support ?
netif_receive_skb vs napi_gro_receive choice.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
(no top-post nor lazy quote please)
David Shwatrz dshwa...@gmail.com :
[...]
In the napi_gro_receive() we check that the device supports
NETIF_F_GRO, but I don't see that we inspect checksum or that
NETIF_F_GRO is depends on checksum.
napi_gro_receive is irrelevant. Let aside tunnel, the real
David Shwatrz dshwa...@gmail.com :
[...]
what is the current state of checksum offloading support has to do
with it ? maybe you meant current state of NAPI support ?
netif_receive_skb vs napi_gro_receive choice.
--
Ueimor
--
To unsubscribe from this list: send the line unsubscribe
Julia Lawall :
> François Romieu :
[...]
> > Can you send a netif_receive_skb replacement patch for it ?
>
> Just to be sure, I just replace netif_rx by netif_receive_skb, nothing
> else?
Yes. It should imho be fine with a comment incluing your analysis and a
few words about the current state
Julia Lawall julia.law...@lip6.fr :
François Romieu rom...@fr.zoreil.com :
[...]
Can you send a netif_receive_skb replacement patch for it ?
Just to be sure, I just replace netif_rx by netif_receive_skb, nothing
else?
Yes. It should imho be fine with a comment incluing your analysis and a
Julia Lawall :
> To my limited understanding, in a NAPI polling function, one should use
> netif_receive_skb, rather than netif_rx.
Nit: or napi_gro_receive (+ napi_gro_flush with __napi_complete) when the
device offers some checksum offloading features.
> However, the via-velocity driver
Julia Lawall julia.law...@lip6.fr :
To my limited understanding, in a NAPI polling function, one should use
netif_receive_skb, rather than netif_rx.
Nit: or napi_gro_receive (+ napi_gro_flush with __napi_complete) when the
device offers some checksum offloading features.
However, the
Amit Uttamchandani :
> Add poll controller function for velocity nic.
Thanks.
You did not state if it was tested. Was it ?
--
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 info at
Amit Uttamchandani auttamchand...@logicube.com :
Add poll controller function for velocity nic.
Thanks.
You did not state if it was tested. Was it ?
--
Ueimor
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
David Miller :
[...]
> Francois, please review.
The style is consistent with the driver.
The commit message may state that this 8411 chipset does not require
any special action in rtl_link_chg_patch (whence differing from the
previous "F" 8411).
Most of the code shared by rtl_hw_start_8168g_2
David Miller da...@davemloft.net :
[...]
Francois, please review.
The style is consistent with the driver.
The commit message may state that this 8411 chipset does not require
any special action in rtl_link_chg_patch (whence differing from the
previous F 8411).
Most of the code shared by
opensou...@tigusoft.pl :
> On Sunday 16 June 2013 18:39:21 Francois Romieu wrote:
>
> Thank you for feedback. We provide XID, IRQ and additional info below.
Executive summary:
1. affected Realtek nics are 8168evl (XID 0c900800) and an old PCI
(XID 1800)
2. failing marvell ni
opensou...@tigusoft.pl opensou...@tigusoft.pl :
On Sunday 16 June 2013 18:39:21 Francois Romieu wrote:
Thank you for feedback. We provide XID, IRQ and additional info below.
Executive summary:
1. affected Realtek nics are 8168evl (XID 0c900800) and an old PCI
(XID 1800)
2. failing
opensou...@tigusoft.pl :
[...]
> Thanks for helping to debug and find this problem: tigusoft.pl , #grsecurity
> ,
> Arach , Admin2501 , R.Freeman
>
>
> We await any instructions how to debug this further.
Please send the XID of Realtek devices you own ('dmesg | grep XID').
r8169 support
opensou...@tigusoft.pl opensou...@tigusoft.pl :
[...]
Thanks for helping to debug and find this problem: tigusoft.pl , #grsecurity
,
Arach , Admin2501 , R.Freeman
We await any instructions how to debug this further.
Please send the XID of Realtek devices you own ('dmesg | grep XID').
201 - 300 of 914 matches
Mail list logo
