Alexey Brodkin :
[...]
> If my comment doesn't make sense to you or I misunderstood your message
> could you please add more clarifications for your idea?
Sorry, I temporarily forgot it was the descriptor ring itself. :o/
It would make sense to qualify the descriptor members as __{le/be}32
Alexey Brodkin alexey.brod...@synopsys.com :
[...]
If my comment doesn't make sense to you or I misunderstood your message
could you please add more clarifications for your idea?
Sorry, I temporarily forgot it was the descriptor ring itself. :o/
It would make sense to qualify the descriptor
Alexey Brodkin :
> On 06/14/2013 02:20 AM, Francois Romieu wrote:
[...]
> >> +struct arc_emac_priv {
> >> + struct net_device_stats stats;
> >> + unsigned int clock_frequency;
> >> + unsigned int max_speed;
> >> +
> >> + /* Pointers to
Alexey Brodkin alexey.brod...@synopsys.com :
On 06/14/2013 02:20 AM, Francois Romieu wrote:
[...]
+struct arc_emac_priv {
+ struct net_device_stats stats;
+ unsigned int clock_frequency;
+ unsigned int max_speed;
+
+ /* Pointers to BD rings - CPU side */
+ struct arc_emac_bd_t
Alexey Brodkin :
[...]
> diff --git a/drivers/net/ethernet/arc/arc_emac.h
> b/drivers/net/ethernet/arc/arc_emac.h
> new file mode 100644
> index 000..6691db2
> --- /dev/null
> +++ b/drivers/net/ethernet/arc/arc_emac.h
[...]
> +struct arc_emac_priv {
> + struct net_device_stats stats;
> +
Andy Shevchenko :
[...]
> I just realize you are using circular buffer here. What about to use
> them with linux' native framework? Documentation/circular-buffers.txt
It's almost unused in drivers/net. I won't mind if it stays this way.
--
Ueimor
--
To unsubscribe from this list: send the line
Andy Shevchenko andy.shevche...@gmail.com :
[...]
I just realize you are using circular buffer here. What about to use
them with linux' native framework? Documentation/circular-buffers.txt
It's almost unused in drivers/net. I won't mind if it stays this way.
--
Ueimor
--
To unsubscribe from
Alexey Brodkin alexey.brod...@synopsys.com :
[...]
diff --git a/drivers/net/ethernet/arc/arc_emac.h
b/drivers/net/ethernet/arc/arc_emac.h
new file mode 100644
index 000..6691db2
--- /dev/null
+++ b/drivers/net/ethernet/arc/arc_emac.h
[...]
+struct arc_emac_priv {
+ struct
Alexey Brodkin :
> On 06/08/2013 12:33 AM, Francois Romieu wrote:
> > Alexey Brodkin :
[...]
> As replied to Joe I just want to name people contributed in this driver.
> What is a appropriate way to do it?
A polite way could be to see with contributors if it's ok for them to
a
Alexey Brodkin alexey.brod...@synopsys.com :
On 06/08/2013 12:33 AM, Francois Romieu wrote:
Alexey Brodkin alexey.brod...@synopsys.com :
[...]
As replied to Joe I just want to name people contributed in this driver.
What is a appropriate way to do it?
A polite way could be to see
Alexey Brodkin :
[...]
> diff --git a/drivers/net/ethernet/arc/arc_emac_main.c
> b/drivers/net/ethernet/arc/arc_emac_main.c
> new file mode 100644
> index 000..f098a27
> --- /dev/null
> +++ b/drivers/net/ethernet/arc/arc_emac_main.c
> @@ -0,0 +1,956 @@
> +/*
> + * Copyright (C) 2004,
Alexey Brodkin alexey.brod...@synopsys.com :
[...]
diff --git a/drivers/net/ethernet/arc/arc_emac_main.c
b/drivers/net/ethernet/arc/arc_emac_main.c
new file mode 100644
index 000..f098a27
--- /dev/null
+++ b/drivers/net/ethernet/arc/arc_emac_main.c
@@ -0,0 +1,956 @@
+/*
+ * Copyright
Steven Rostedt :
[...]
> I'm working on 3.6.11.5. Has the fix for the regression been pulled into
> mainline yet, and if so, what's the commit SHA1?
It's in mainline as b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 but davem
has not sent it into -stable yet.
--
Ueimor
--
To unsubscribe from this
Steven Rostedt rost...@goodmis.org :
[...]
I'm working on 3.6.11.5. Has the fix for the regression been pulled into
mainline yet, and if so, what's the commit SHA1?
It's in mainline as b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 but davem
has not sent it into -stable yet.
--
Ueimor
--
To
atom...@redhat.com :
[...]
> Failed GFP_ATOMIC allocations by the network stack result in dropped
> packets, which will be received on a subsequent retransmit, and an
> unnecessary, noisy warning with a kernel backtrace.
>
> These warnings are harmless, but they still cause users to panic and
>
atom...@redhat.com atom...@redhat.com :
[...]
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a subsequent retransmit, and an
unnecessary, noisy warning with a kernel backtrace.
These warnings are harmless, but they still cause users to
Petko Manolov :
> On Sat, 18 May 2013, Francois Romieu wrote:
> > > From: Petko Manolov
[...]
> > > Moving constant and structure definitions out of rtl8150.c;
> >
> > What's the point ?
>
> The general logic of having .h files applies.
Wh
Petko Manolov :
[...]
> > > + usb_fill_control_urb(async_urb, dev->udev,
> > > + usb_sndctrlpipe(dev->udev, 0), (void *) >dr,
> >
> > Useless void * cast.
>
> Wrong. The compiler actually moans quite a lot:
>
> /usr/src/git/rtl8150/rtl8150.c: In function
Petko Manolov pet...@nucleusys.com :
On Sat, 18 May 2013, Francois Romieu wrote:
From: Petko Manolov pet...@nucleusys.com
[...]
Moving constant and structure definitions out of rtl8150.c;
What's the point ?
The general logic of having .h files applies.
Which one ?
- share
Petko Manolov pet...@nucleusys.com :
[...]
+ usb_fill_control_urb(async_urb, dev-udev,
+ usb_sndctrlpipe(dev-udev, 0), (void *) req-dr,
Useless void * cast.
Wrong. The compiler actually moans quite a lot:
/usr/src/git/rtl8150/rtl8150.c: In function
Petko Manolov :
[...]
> This patch series adds rtl8150.h, which contains structure and constant
> definitons formerly found in rtl8150.c, removes socket buffer
> pre-allocated pool and uses dynamically allocated memory for the
> asynchronous URB requests, thus avoids clobbering the previously
Petko Manolov :
[...]
> @@ -681,16 +681,15 @@ static int rtl8150_ioctl(struct net_device *netdev,
> struct ifreq *rq, int cmd)
> }
>
> static const struct net_device_ops rtl8150_netdev_ops = {
> - .ndo_open = rtl8150_open,
> - .ndo_stop = rtl8150_close,
>
Petko Manolov :
[...]
> static int set_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
> {
> - return usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
> -RTL8150_REQ_SET_REGS, RTL8150_REQT_WRITE,
> -indx, 0, data,
Petko Manolov :
> From: Petko Manolov
>
> Moving constant and structure definitions out of rtl8150.c;
What's the point ?
[...]
> ---
> drivers/net/usb/rtl8150.c | 121 +--
> 1 file changed, 2 insertions(+), 119 deletions(-)
>
> diff --git
Petko Manolov :
[...]
> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> index 7d1897b..fd4bc2a 100644
> --- a/drivers/net/usb/rtl8150.c
> +++ b/drivers/net/usb/rtl8150.c
[...]
> static void rx_fixup(unsigned long data)
> {
> struct rtl8150 *dev = (struct rtl8150
Tony Prisk :
[...]
> diff --git a/drivers/net/ethernet/via/via-velocity.c
> b/drivers/net/ethernet/via/via-velocity.c
> index 5996cee..d8d5bc5 100644
> --- a/drivers/net/ethernet/via/via-velocity.c
> +++ b/drivers/net/ethernet/via/via-velocity.c
[...]
> @@ -84,6 +88,16 @@
> static int
Steven Rostedt :
> 3.6.11.4 stable review patch.
> If anyone has any objections, please let me know.
You should postpone it until the fix for a regression it induces when
user enable Tx checksumming is merged.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Steven Rostedt rost...@goodmis.org :
3.6.11.4 stable review patch.
If anyone has any objections, please let me know.
You should postpone it until the fix for a regression it induces when
user enable Tx checksumming is merged.
--
Ueimor
--
To unsubscribe from this list: send the line
Tony Prisk li...@prisktech.co.nz :
[...]
diff --git a/drivers/net/ethernet/via/via-velocity.c
b/drivers/net/ethernet/via/via-velocity.c
index 5996cee..d8d5bc5 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
[...]
@@ -84,6 +88,16 @@
static
Petko Manolov pet...@nucleusys.com :
From: Petko Manolov pet...@nucleusys.com
Moving constant and structure definitions out of rtl8150.c;
What's the point ?
[...]
---
drivers/net/usb/rtl8150.c | 121 +--
1 file changed, 2 insertions(+), 119 deletions(-)
Petko Manolov pet...@nucleusys.com :
[...]
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 7d1897b..fd4bc2a 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
[...]
static void rx_fixup(unsigned long data)
{
struct rtl8150 *dev = (struct
Petko Manolov pet...@nucleusys.com :
[...]
static int set_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
{
- return usb_control_msg(dev-udev, usb_sndctrlpipe(dev-udev, 0),
-RTL8150_REQ_SET_REGS, RTL8150_REQT_WRITE,
-
Petko Manolov pet...@nucleusys.com :
[...]
@@ -681,16 +681,15 @@ static int rtl8150_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
}
static const struct net_device_ops rtl8150_netdev_ops = {
- .ndo_open = rtl8150_open,
- .ndo_stop =
Petko Manolov pet...@nucleusys.com :
[...]
This patch series adds rtl8150.h, which contains structure and constant
definitons formerly found in rtl8150.c, removes socket buffer
pre-allocated pool and uses dynamically allocated memory for the
asynchronous URB requests, thus avoids clobbering
Ken Moffat :
[...]
> Cc'ing to netdev because I don't think this has had a response, and
A patch has been sent to netdev a few hours ago. It needs more work,
especially testing (hint, hint) as I don't have a proven test case yet.
Please note:
- if you don't use a 8168evl (check your dmesg for
Ken Moffat zarniwh...@ntlworld.com :
[...]
Cc'ing to netdev because I don't think this has had a response, and
A patch has been sent to netdev a few hours ago. It needs more work,
especially testing (hint, hint) as I don't have a proven test case yet.
Please note:
- if you don't use a 8168evl
Jongsung Kim :
> This patch adds the minimal driver to manage the
> Realtek RTL8201F 10/100Mbps Transceivers.
Your patch contains both "remove unused #define" and "support new hardware"
parts. I am not sure that the former is adequate for submission until
net-next opens.
> diff --git
Jongsung Kim neidhard@lge.com :
This patch adds the minimal driver to manage the
Realtek RTL8201F 10/100Mbps Transceivers.
Your patch contains both remove unused #define and support new hardware
parts. I am not sure that the former is adequate for submission until
net-next opens.
diff
Linus Torvalds :
[...]
> Any ideas?
1a9646497b163a8b9da5e70008d809dc91b32855 ("r8169: adjust the flow of hw_start"),
eee3786f7d3134e3edc54c1134511d520dd74285 ("r8169: Modify the method for setting
firmware") and 0427d0152eb3c2c2712afa427dd593c68fc09299
("r8169: Remove firmware code") may play a
Linus Torvalds torva...@linux-foundation.org :
[...]
Any ideas?
1a9646497b163a8b9da5e70008d809dc91b32855 (r8169: adjust the flow of hw_start),
eee3786f7d3134e3edc54c1134511d520dd74285 (r8169: Modify the method for setting
firmware) and 0427d0152eb3c2c2712afa427dd593c68fc09299
(r8169: Remove
Tony Prisk :
[...]
> +static int velocity_remove(void *pdev, enum velocity_bus_type bustype)
> +{
> + struct net_device *netdev;
> + struct velocity_info *vptr;
> + int pci = (bustype == BUS_PCI) ? 1 : 0;
> +
> + if (pci)
> + netdev = pci_get_drvdata(pdev);
> +
Tony Prisk li...@prisktech.co.nz :
[...]
+static int velocity_remove(void *pdev, enum velocity_bus_type bustype)
+{
+ struct net_device *netdev;
+ struct velocity_info *vptr;
+ int pci = (bustype == BUS_PCI) ? 1 : 0;
+
+ if (pci)
+ netdev =
Tony Prisk :
> I would like to add support to this driver for platform devices as
> found on VIA's APC8750 board. At the moment, I have a standalone
> platform version that works fine, but wanted to ask a few questions
> before sending a patch to merge this code into one driver.
>
> The current
Tony Prisk li...@prisktech.co.nz :
I would like to add support to this driver for platform devices as
found on VIA's APC8750 board. At the moment, I have a standalone
platform version that works fine, but wanted to ask a few questions
before sending a patch to merge this code into one driver.
David R :
> I'm been seeing some problems with my new ish AMD motherboard/processor
> combo and networking (r8169). I see the following page fault :-
>
> Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged
> [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x3000
>
David R da...@unsolicited.net :
I'm been seeing some problems with my new ish AMD motherboard/processor
combo and networking (r8169). I see the following page fault :-
Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged
[IO_PAGE_FAULT device=02:00.0 domain=0x0015
David Miller :
[...]
> I see there is still some discussion about dependencies between
> patch #5 and #6, is that resolved?
Yes.
> If so, should I just apply this series as-is ?
Yes.
- the series is imho -stable unfriendly: whoever wants to figure what
should be fed into a -stable branch
David Miller da...@davemloft.net :
[...]
I see there is still some discussion about dependencies between
patch #5 and #6, is that resolved?
Yes.
If so, should I just apply this series as-is ?
Yes.
- the series is imho -stable unfriendly: whoever wants to figure what
should be fed into a
hayeswang :
[...]
> Excuse me, I don't sure what is your question. Do you mean if the patch
> "[PATCH v2 net-next 5/8] r8169: Update the RTL8111G parameters" is necessary
> before the current patch? According to the settings from our hw engineers,
> some settings of the new chip are the same with
hayeswang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
> > There is close to zero added value for this stuff in the kernel.
> > You may as well move it completely into the firmware.
>
> Do you mean all of the phy settings ? I have checked these settings wi
Hayes Wang :
> Add a new chip for RTL8111G series.
It does not need any of the workarounds in patch #5, right ?
--
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
Hayes Wang :
> It would cause no link after suspending or shutdowning when the
> nic changes the speed to 10M and connects to a link partner which
> forces the speed to 100M.
>
> Check the link partner ability to determine which speed to set.
>
> Signed-off-by: Hayes Wang
...@realtek.com
Acked-by: Francois Romieu rom...@fr.zoreil.com
I have given it a short sanity testing with suspend or shutdown (no rpm)
on 8168evl or 8168e and it did not seem to regress (8168e and 8168evl).
The driver does not do what it is requested to when the r81xx - not the
link partner
Hayes Wang hayesw...@realtek.com :
Add a new chip for RTL8111G series.
It does not need any of the workarounds in patch #5, right ?
--
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
hayeswang hayesw...@realtek.com :
Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
There is close to zero added value for this stuff in the kernel.
You may as well move it completely into the firmware.
Do you mean all of the phy settings ? I have checked these settings with
our hw
hayeswang hayesw...@realtek.com :
[...]
Excuse me, I don't sure what is your question. Do you mean if the patch
[PATCH v2 net-next 5/8] r8169: Update the RTL8111G parameters is necessary
before the current patch? According to the settings from our hw engineers,
some settings of the new chip
Hayes Wang :
> For new version of Fedora and Ubuntu, we see all 0xff when dumping
> the hw regs through ethtool. Using a loop to read registers could
> fix it.
If it fixes a problem which lives outside of net-next, it should target
"net", not "net-next".
"new version" does not help when a
Hayes Wang :
[...]
> - move rtl_set_rx_tx_desc_registers to avoid the tx/rx are enabled
> before setting desc registers.
This is a wholesale change for the 810x family.
Please explain why issuing rtl_set_rx_tx_desc_registers before writing
ChipCmd is not enough and feed it through a
Hayes Wang :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 0211836..8d41508 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> +static void rtl8168g_2_hw_phy_config(struct
Hayes Wang :
> - Replace the current settings with rtl_writephy and rtl_readphy.
> For the hardware, the settings are same with previous ones. This
> make the setting method like the previous chips.
> - Add new PHY settings.
Would you mind spliting it in two ?
On closer inspection the
Hayes Wang hayesw...@realtek.com :
- Replace the current settings with rtl_writephy and rtl_readphy.
For the hardware, the settings are same with previous ones. This
make the setting method like the previous chips.
- Add new PHY settings.
Would you mind spliting it in two ?
On closer
Hayes Wang hayesw...@realtek.com :
[...]
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 0211836..8d41508 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
[...]
+static void
Hayes Wang hayesw...@realtek.com :
[...]
- move rtl_set_rx_tx_desc_registers to avoid the tx/rx are enabled
before setting desc registers.
This is a wholesale change for the 810x family.
Please explain why issuing rtl_set_rx_tx_desc_registers before writing
ChipCmd is not enough and feed it
Hayes Wang hayesw...@realtek.com :
For new version of Fedora and Ubuntu, we see all 0xff when dumping
the hw regs through ethtool. Using a loop to read registers could
fix it.
If it fixes a problem which lives outside of net-next, it should target
net, not net-next.
new version does not help
Hayes Wang :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 28fb50a..a9eedf7 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -3818,6 +3818,21 @@ static void rtl_init_mdio_ops(struct
hayeswang :
[...]
> Sorry for my unclear descriptor. I just think a case that the nic suspends or
> shutdowns without cable plugging. Then, the cable is plugged again. If the nic
> speed down to 10M and the link partner force 100M, the issue appears again. If
> the nic doesn't speed down for
hayeswang hayesw...@realtek.com :
[...]
Sorry for my unclear descriptor. I just think a case that the nic suspends or
shutdowns without cable plugging. Then, the cable is plugged again. If the nic
speed down to 10M and the link partner force 100M, the issue appears again. If
the nic doesn't
Hayes Wang hayesw...@realtek.com :
[...]
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 28fb50a..a9eedf7 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3818,6 +3818,21 @@ static void
hayeswang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
> [...]
> > Your description suggests that testing against the link
> > partner ability to work at 10M instead of testing for
^^ -> "and"
> > tp->link_
hayeswang hayesw...@realtek.com :
Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
Your description suggests that testing against the link
partner ability to work at 10M instead of testing for
^^ - and
tp-link_ok could be good enough
hayeswang :
[...]
> Do you have any suggestion about this?
Your description suggests that testing against the link partner ability
to work at 10M instead of testing for tp->link_ok could be good enough.
Does it make sense ?
--
Ueimor
--
To unsubscribe from this list: send the line
hayeswang hayesw...@realtek.com :
[...]
Do you have any suggestion about this?
Your description suggests that testing against the link partner ability
to work at 10M instead of testing for tp-link_ok could be good enough.
Does it make sense ?
--
Ueimor
--
To unsubscribe from this list: send
tions(+), 67 deletions(-)
Shortlog
----
Francois Romieu (2):
Revert "r8169: enable ALDPS for power saving".
Revert "r8169: enable internal ASPM and clock request settings".
Patch
-
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/rea
insertions(+), 67 deletions(-)
Shortlog
Francois Romieu (2):
Revert r8169: enable ALDPS for power saving.
Revert r8169: enable internal ASPM and clock request settings.
Patch
-
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index
Jörg Otte :
[...]
> To Summarize: Two net-regressions where introduced in v3.8 (driver r8169):
>
> 1) NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
> was introduced by commit
> e0c075577965d1c01b30038d38bf637b027a1df3
> ("r8169: enable ALDPS for power saving")
Hayes Wang authored
David Miller :
[...]
> Francois please review this series, thanks.
It does not seem wrong but I'll give it a try before sending a pull
request.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Hayes Wang :
> For new version of Fedora and Ubuntu, we see all 0xff when dumping
> the hw regs through ethtool. Using a loop to read registers could
> fix it.
/me wonders...
Will I be wrong if I reformulate so as to outline the role of 4 bytes
aligned accesses when walking the registers area ?
Hayes Wang :
> Remove useless action PHY_READ_EFUSE, and define the new action
> PHY_MDIO_CHG.
>
> PHY_MDIO_CHG is used to modify the mdio operation. By the way, the
> firmware could support setting mac ocp.
>
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
>
Hayes Wang :
> - replace rtl8168g-1.fw with rtl8168g-2.fw which support new method.
> - fix PHY power down is useless.
> - disable rx early which causes the rx abnormal.
> - fix the conflict between jumbo frame and flow control.
>
> Signed-off-by: Hayes Wang
It seems ok.
--
Ueimor
--
To
Hayes Wang :
> Some codes are belong to binary codes and should be removed.
Ok (almost).
--
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 http://vger.kernel.org/majordomo-info.html
Hayes Wang hayesw...@realtek.com :
Some codes are belong to binary codes and should be removed.
Ok (almost).
--
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
Hayes Wang hayesw...@realtek.com :
Remove useless action PHY_READ_EFUSE, and define the new action
PHY_MDIO_CHG.
PHY_MDIO_CHG is used to modify the mdio operation. By the way, the
firmware could support setting mac ocp.
[...]
diff --git a/drivers/net/ethernet/realtek/r8169.c
Hayes Wang hayesw...@realtek.com :
- replace rtl8168g-1.fw with rtl8168g-2.fw which support new method.
- fix PHY power down is useless.
- disable rx early which causes the rx abnormal.
- fix the conflict between jumbo frame and flow control.
Signed-off-by: Hayes Wang hayesw...@realtek.com
Hayes Wang hayesw...@realtek.com :
For new version of Fedora and Ubuntu, we see all 0xff when dumping
the hw regs through ethtool. Using a loop to read registers could
fix it.
/me wonders...
Will I be wrong if I reformulate so as to outline the role of 4 bytes
aligned accesses when walking
David Miller da...@davemloft.net :
[...]
Francois please review this series, thanks.
It does not seem wrong but I'll give it a try before sending a pull
request.
--
Ueimor
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Jörg Otte jrg.o...@gmail.com :
[...]
To Summarize: Two net-regressions where introduced in v3.8 (driver r8169):
1) NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
was introduced by commit
e0c075577965d1c01b30038d38bf637b027a1df3
(r8169: enable ALDPS for power saving)
Hayes Wang
Kirill Kapranov :
> NET/PHY: Eliminate the forced speed reduction algorithm.
> In case of the fixed speed set up for NIC
> (e.g. ethtool -s eth0 autoneg off speed 100 duplex full)
> with ethernet cable plugged off, mentioned algorithm
> slows down NIC speed, so the further "hooking up" gives
>
Kirill Kapranov kapran...@inbox.ru :
NET/PHY: Eliminate the forced speed reduction algorithm.
In case of the fixed speed set up for NIC
(e.g. ethtool -s eth0 autoneg off speed 100 duplex full)
with ethernet cable plugged off, mentioned algorithm
slows down NIC speed, so the further hooking
Jörg Otte :
[...]
> jojo@ahorn:~$ dmesg | grep XID
> [1.808847] r8169 :02:00.0 eth0: RTL8168evl/8111evl at
> 0xc9054000, 5c:9a:d8:69:2b:39, XID 0c900800 IRQ 42
Can you check if things improve with v3.8-rc2 after removing :
1. 9ecb9aabaf634677c77af467f4e3028b09d7bcda
r8169:
Jörg Otte :
[...]
> It's a regression, it never happend before 3.8-rc.
Please check that 'dmesg | grep XID' exhibits a 8168evl.
I'll showe and dig it. It's epidemic.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Jörg Otte jrg.o...@gmail.com :
[...]
It's a regression, it never happend before 3.8-rc.
Please check that 'dmesg | grep XID' exhibits a 8168evl.
I'll showe and dig it. It's epidemic.
--
Ueimor
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Jörg Otte jrg.o...@gmail.com :
[...]
jojo@ahorn:~$ dmesg | grep XID
[1.808847] r8169 :02:00.0 eth0: RTL8168evl/8111evl at
0xc9054000, 5c:9a:d8:69:2b:39, XID 0c900800 IRQ 42
Can you check if things improve with v3.8-rc2 after removing :
1.
Björn Christoph :
[...]
> Not sure what to do here. It's an Ubuntu kernel - should I take the
> one from the kernel GIT, compile it and activate some debugging or
> something to assist?
You should try to reproduce the problem with the kernel included r8169
driver and report any problem with it
Björn Christoph einkaufenb...@googlemail.com :
[...]
Not sure what to do here. It's an Ubuntu kernel - should I take the
one from the kernel GIT, compile it and activate some debugging or
something to assist?
You should try to reproduce the problem with the kernel included r8169
driver and
Wang YanQing :
[...]
> @@ -6903,6 +6903,14 @@ rtl_init_one(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> dev->dev_addr[i] = RTL_R8(MAC0 + i);
> memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
>
> + /*
> + *This is a fix for BIOS forget to set
> +
Wang YanQing udkni...@gmail.com :
[...]
@@ -6903,6 +6903,14 @@ rtl_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
dev-dev_addr[i] = RTL_R8(MAC0 + i);
memcpy(dev-perm_addr, dev-dev_addr, dev-addr_len);
+ /*
+ *This is a fix for BIOS forget to
Wang YanQing :
[...]
> After add some debug code, I found this NIC only accept ethernet
> broadcast package, it can't filter out the package send to its
> MAC address, but it works good for sending.So ifconfig show the
> RX/TX status means it can receive ARP package.(It don't its MAC
> address,
Wang YanQing udkni...@gmail.com :
[...]
After add some debug code, I found this NIC only accept ethernet
broadcast package, it can't filter out the package send to its
MAC address, but it works good for sending.So ifconfig show the
RX/TX status means it can receive ARP package.(It don't its
Jonathan Nieder :
[...]
> This has been applied as commit b00e69dee4cc in mainline; thanks!
>
> Fran??ois and David, would this be a candidate for inclusion in
> 3.0- and newer stable kernels?
- 3.0.51
b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
aee77e4accbeb2c86b1d294cd84fec4a12dde3bd
-
Jonathan Nieder jrnie...@gmail.com :
[...]
This has been applied as commit b00e69dee4cc in mainline; thanks!
Fran??ois and David, would this be a candidate for inclusion in
3.0- and newer stable kernels?
- 3.0.51
b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd
301 - 400 of 914 matches
Mail list logo
