e100 fails, eepro100 works

Hi, we have a couple of industrial PCs here with Intel PRO/100 controllers on board. Most of them work fine with the e100, but today I stumbled over one box that doesn't: Reception works (RX counter increases, ARP cache gets filled up), but transmission fails (TX counter is also zero). In

Re: e100 fails, eepro100 works

Auke Kok wrote: Can you include a full `dmesg` and `lcpci -vv -s 00:12.0` ? Also you're using 3.5.10-k2, can you try the current git tree version instead? I can send you the e100.c if wanted. Yes, please, to make sure that we'll really discuss the same version. Will then try to collect the

d80211: ieee80211_hw handlers in atomic context

Hello Jiri, Ivo suggested to bring this issue to a broader audience, specifically to the stack maintainer. Trying to run my Asus WL167G with rt2500usb I faced the following: BUG: scheduling while atomic: swapper/0x0102/0 c0103055 show_trace+0x12/0x14 c01035e0 dump_stack+0x1c/0x1e

Re: d80211: ieee80211_hw handlers in atomic context

Ivo van Doorn wrote: Hi, Ivo told me about a patch for d80211 that moved certain timers to thread context, effectively avoiding to call config from timer handlers, but I didn't find any trace yet. Is there some modification in this direction already scheduled? I'm not necessarily looking

Re: d80211: ieee80211_hw handlers in atomic context

Jiri Benc wrote: On Wed, 4 Oct 2006 18:34:57 +0200, Ivo van Doorn wrote: You could replace the timer with a workqueue, the original patch also did that, so I think it would be good enough this time as well. :) Yes, the timing isn't required to be precise here. Ok, I'm not promising success

Re: d80211: ieee80211_hw handlers in atomic context

Ivo van Doorn wrote: On Thursday 05 October 2006 13:37, Jiri Benc wrote: On Wed, 4 Oct 2006 19:22:38 +0200, Ivo van Doorn wrote: Well another point of concern for me is the TSF handling, those handlers are called from interrupt context as well, and also deliver problems for the USB drivers

[PATCH] d80211: Reinit keys on mode change

Switching the interface mode with some encryption keys set and then later touching any key, triggers an oops because ieee80211_if_reinit fails to NULL'ify the related pointers after free'ing the key on mode change. Long explanation, simple fix below. Signed-off-by: Jan Kiszka [EMAIL PROTECTED

Re: [2.6 patch] the scheduled eepro100 removal

Adrian Bunk wrote: This patch contains the scheduled removal of the eepro100 driver. I'm sorry to disturb the schedule, but I'm not sure right now if this pending issue of the e100 was meanwhile solved or declared a non-issue: http://lkml.org/lkml/2006/9/8/105 Auke, can you confirm that it

Re: d80211: How does TX flow control work?

Jiri Benc wrote: On Tue, 02 Jan 2007 14:08:21 +0100, Jan Kiszka wrote: What I (think to) understand is that a low-level drivers call ieee80211_stop_queue() if they run out of buffers. That flips a per-queue bit (IEEE80211_LINK_STATE_XOFF), prevents that any further frame is passed

Re: [PATCH] d80211: Fix inconsistent sta_lock usage

Ivo van Doorn wrote: +#define __bss_tim_set(__bss, __aid) __set_bit((__aid), (__bss)-tim) + __set/clear_bit demands unsigned long, tim is u8. That causes quite some warnings here. ... static inline void bss_tim_clear(struct ieee80211_local *local, struct

Re: [PATCH] d80211: Fix inconsistent sta_lock usage

Johannes Berg wrote: On Fri, 2007-01-05 at 21:08 +0100, Ivo van Doorn wrote: This patch uses the __set_bit and __clear_but as suggested by Christoph. It also removes the local argument since it was unused. NACK. This breaks spec compliance for drivers that use the TIM in their beacon

Re: d80211: How does TX flow control work?

Jan Kiszka wrote: Jiri Benc wrote: On Wed, 03 Jan 2007 19:10:01 +0100, Jan Kiszka wrote: BUG: warning at /usr/src/rt2x00/rt2x00/ieee80211/ieee80211.c:1256/ieee80211_tx() cfa02245 ieee80211_master_start_xmit+0x105/0x430 [80211] c024e35d __ip_ct_refresh_acct+0x4d/0x60 c024fd11 tcp_packet

Re: d80211: How does TX flow control work?

Jan Kiszka wrote: Jan Kiszka wrote: Jiri Benc wrote: On Wed, 03 Jan 2007 19:10:01 +0100, Jan Kiszka wrote: BUG: warning at /usr/src/rt2x00/rt2x00/ieee80211/ieee80211.c:1256/ieee80211_tx() cfa02245 ieee80211_master_start_xmit+0x105/0x430 [80211] c024e35d __ip_ct_refresh_acct+0x4d/0x60

[PATCH] d80211: don't symlink empty default keys

default link. Signed-off-by: Jan Kiszka [EMAIL PROTECTED] --- ieee80211/ieee80211_ioctl.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: rt2x00/ieee80211/ieee80211_ioctl.c === --- rt2x00.orig/ieee80211

Re: [PATCH] d80211: don't symlink empty default keys

Jan Kiszka wrote: This gets rid of annoying wlan0: cannot create symlink to default key in my syslog with latest rt2x00. The patch takes care that in case of (key/old_key == NULL set_tx_key) the existing default key symlink is removed correctly. Moreover, it tests for key!=NULL before

Re: [PATCH] d80211: don't symlink empty default keys

Jiri Benc wrote: On Tue, 09 Jan 2007 23:33:34 +0100, Jan Kiszka wrote: This gets rid of annoying wlan0: cannot create symlink to default key in my syslog with latest rt2x00. The patch takes care that in case of (key/old_key == NULL set_tx_key) the existing default key symlink is removed

[PATCH] d80211: fix default key symlink creation/cleanup

symlink to the default key before trying to register a new one. Moreover, it avoids to call ieee80211_key_sysfs_add_default for a NULL key. Signed-off-by: Jan Kiszka [EMAIL PROTECTED] --- net/d80211/ieee80211_ioctl.c |9 - net/d80211/ieee80211_sysfs_sta.c |3 ++- 2 files changed

Re: [PATCH 4/6] d80211: don't display name of invisible network device

2007/1/30, Johannes Berg [EMAIL PROTECTED]: On Mon, 2007-01-29 at 18:48 +0100, Jiri Benc wrote: Invisible master interface does not have meaningful name. Display the wiphy identifier in kernel messages instead. Also, remove the allocation of master interface name as it is purposeless now.

Re: [PATCH] d80211: ieee80211_hw handlers should be allowed to sleep

Ivo van Doorn wrote: On Wednesday 18 October 2006 15:06, Jiri Benc wrote: On Sat, 7 Oct 2006 11:23:15 +0200, Ivo van Doorn wrote: --- a/net/d80211/ieee80211.c +++ b/net/d80211/ieee80211.c @@ -2075,15 +2075,15 @@ void ieee80211_if_shutdown(struct net_de case IEEE80211_IF_TYPE_STA:

[PATCH] stmmac: Add support for SIMATIC IOT2000 platform

The IOT2000 is industrial controller platform, derived from the Intel Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the IOT2040 has two of them. They can be told apart based on the board asset tag in the DMI table. Based on patch by Sascha Weisenberger. Signed-off-by: Jan

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

On 2017-04-24 23:27, Andy Shevchenko wrote: > On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> The IOT2000 is industrial controller platform, derived from the Intel >> Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the >&

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

On 2017-04-25 09:30, Andy Shevchenko wrote: > On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2017-04-24 23:27, Andy Shevchenko wrote: >>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >>>

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

On 2017-04-25 11:46, Andy Shevchenko wrote: > On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2017-04-25 09:30, Andy Shevchenko wrote: >>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka <jan.kis...@siemens.com> wrote: >>>>

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

On 2017-04-25 12:07, Jan Kiszka wrote: > On 2017-04-25 11:46, Andy Shevchenko wrote: >> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >>> On 2017-04-25 09:30, Andy Shevchenko wrote: >>>> On Tue, Apr 25, 2017 at 8:44 AM, Jan K

Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform

On 2017-04-25 13:42, Andy Shevchenko wrote: > On Tue, Apr 25, 2017 at 1:09 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2017-04-25 12:07, Jan Kiszka wrote: >>> On 2017-04-25 11:46, Andy Shevchenko wrote: >>>> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka

[PATCH v5 1/5] stmmac: pci: Make stmmac_pci_info structure constant

From: Jan Kiszka <jan.kis...@siemens.com> By removing the PCI device reference from the structure and passing it as parameters to the interested functions, we can make quark_pci_info const. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevc

[PATCH v5 5/5] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses

From: Jan Kiszka <jan.kis...@siemens.com> Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 97 1 file changed, 64 insertions(+),

[PATCH v5 4/5] stmmac: pci: Select quark_pci_dmi_data from quark_default_data

From: Jan Kiszka <jan.kis...@siemens.com> No need to carry this reference in stmmac_pci_info - the Quark-specific setup handler knows that it needs to use the Quark-specific DMI table. This also allows to drop the stmmac_pci_info reference from the setup handler parameter list. Sign

[PATCH v5 0/5] stmmac: pci: Refactor DMI probing

Some cleanups of the way we probe DMI platforms in the driver. Reduces a bit of open-coding and makes the logic easier reusable for any potential DMI platform != Quark. Tested on IOT2000 and Galileo Gen2. Changes in v5: - fixed a remaining issue in patch 5 - dropped patch 6 for now Jan Jan

[PATCH v5 3/5] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic

From: Jan Kiszka <jan.kis...@siemens.com> Move the special case for the early Galileo firmware into quark_default_setup. This allows to use stmmac_pci_find_phy_addr for non-quark cases. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevc

[PATCH v5 2/5] stmmac: pci: Use stmmac_pci_info for all devices

From: Jan Kiszka <jan.kis...@siemens.com> Make stmmac_default_data compatible with stmmac_pci_info.setup and use an info structure for all devices. This allows to make the probing more regular. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Reviewed-by: Andy Shevchenko &

Re: [PATCH v5 0/5] stmmac: pci: Refactor DMI probing

On 2017-06-22 19:40, David Miller wrote: > From: Jan Kiszka <jan.kis...@siemens.com> > Date: Thu, 22 Jun 2017 08:17:56 +0200 > >> Some cleanups of the way we probe DMI platforms in the driver. Reduces >> a bit of open-coding and makes the logic easier reusable for an

Re: [PATCH 0/3] stmmac: pci: Refactor DMI probing

On 2017-05-22 18:35, David Miller wrote: > From: Jan Kiszka <jan.kis...@siemens.com> > Date: Mon, 22 May 2017 13:12:06 +0200 > >> Some cleanups of the way we probe DMI platforms in the driver. Reduces >> a bit of open-coding and makes the logic easier reusable for an

[PATCH v2 1/6] stmmac: pci: Make stmmac_pci_info structure constant

By removing the PCI device reference from the structure and passing it as parameters to the interested functions, we can make quark_pci_info const. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++ 1 file c

[PATCH v2 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses

Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 77 ++-- 1 file changed, 45 insertions(+), 32 deletions(-) diff --git a/drivers/net/ethernet/s

[PATCH v2 4/6] stmmac: pci: Select quark_pci_dmi_data from quark_default_data

No need to carry this reference in stmmac_pci_info - the Quark-specific setup handler knows that it needs to use the Quark-specific DMI table. This also allows to drop the stmmac_pci_info reference from the setup handler parameter list. Signed-off-by: Jan Kiszka <jan.kis...@siemens.

[PATCH v2 0/6] stmmac: pci: Refactor DMI probing

to do smaller steps All this remains cosmetic from a certain distance, but the result looks more appealing, at least to me. Jan Jan Kiszka (6): stmmac: pci: Make stmmac_pci_info structure constant stmmac: pci: Use stmmac_pci_info for all devices stmmac: pci: Make stmmac_pci_find_phy_addr

[PATCH v2 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info

By now, stmmac_pci_info only contains a single entry. Register this directly with the PCI device table, removing one indirection. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 35 +--- 1 file changed, 13 inse

[PATCH v2 2/6] stmmac: pci: Use stmmac_pci_info for all devices

Make stmmac_default_data compatible with stmmac_pci_info.setup and use an info structure for all devices. This allows to make the probing more regular. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 33 +++-

[PATCH v2 3/6] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic

Move the special case for the early Galileo firmware into quark_default_setup. This allows to use stmmac_pci_find_phy_addr for non-quark cases. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 19 --- 1 file chang

Re: [PATCH 3/3] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses

On 2017-05-22 13:33, Joe Perches wrote: > On Mon, 2017-05-22 at 13:12 +0200, Jan Kiszka wrote: >> Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr. > [] >> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c >> b/drivers/net/ethernet/stm

[PATCH 3/3] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses

Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 77 ++-- 1 file changed, 45 insertions(+), 32 deletions(-) diff --git a/drivers/net/ethernet/s

[PATCH 2/3] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic

Move the special case for the early Galileo firmware into quark_default_setup. This allows to use stmmac_pci_find_phy_addr for non-quark cases. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 19 --- 1 file chang

[PATCH 1/3] stmmac: pci: Overcome stmmac_pci_info structure

, we can make a setup function mandatory, and probing becomes more regular. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 122 +++ 1 file changed, 59 insertions(+), 63 deletions(-) diff --git a/drivers/net/et

[PATCH 0/3] stmmac: pci: Refactor DMI probing

Some cleanups of the way we probe DMI platforms in the driver. Reduces a bit of open-coding and makes the logic easier reusable for any potential DMI platform != Quark. Tested on IOT2000 and Galileo Gen2. Jan Jan Kiszka (3): stmmac: pci: Overcome stmmac_pci_info structure stmmac: pci: Make

Re: [PATCH v2 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info

On 2017-05-27 15:38, Andy Shevchenko wrote: > On Fri, May 26, 2017 at 7:07 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> By now, stmmac_pci_info only contains a single entry. > > _For now_. > >> Register this >> directly with the PCI device table, removing

Re: [PATCH v2 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses

On 2017-05-27 15:28, Andy Shevchenko wrote: > On Fri, May 26, 2017 at 7:07 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr. > >> struct stmmac_pci_dmi_data { >> - const char *name; &g

[PATCH v3 1/6] stmmac: pci: Make stmmac_pci_info structure constant

By removing the PCI device reference from the structure and passing it as parameters to the interested functions, we can make quark_pci_info const. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++ 1 file c

[PATCH v3 2/6] stmmac: pci: Use stmmac_pci_info for all devices

Make stmmac_default_data compatible with stmmac_pci_info.setup and use an info structure for all devices. This allows to make the probing more regular. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 36 +++-

[PATCH v3 4/6] stmmac: pci: Select quark_pci_dmi_data from quark_default_data

No need to carry this reference in stmmac_pci_info - the Quark-specific setup handler knows that it needs to use the Quark-specific DMI table. This also allows to drop the stmmac_pci_info reference from the setup handler parameter list. Signed-off-by: Jan Kiszka <jan.kis...@siemens.

[PATCH v3 3/6] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic

Move the special case for the early Galileo firmware into quark_default_setup. This allows to use stmmac_pci_find_phy_addr for non-quark cases. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 20 +--- 1 file chang

[PATCH v3 0/6] stmmac: pci: Refactor DMI probing

stmmac_pci_find_phy_addr according to review feedback Jan Jan Kiszka (6): stmmac: pci: Make stmmac_pci_info structure constant stmmac: pci: Use stmmac_pci_info for all devices stmmac: pci: Make stmmac_pci_find_phy_addr truly generic stmmac: pci: Select quark_pci_dmi_data from quark_default_data

[PATCH v3 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses

Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 77 ++-- 1 file changed, 45 insertions(+), 32 deletions(-) diff --git a/drivers/net/ethernet/s

[PATCH v3 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info

By now, stmmac_pci_info only contains a single entry. Register this directly with the PCI device table, removing one indirection. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 34 +--- 1 file changed, 12 inse

[PATCH v4 0/6] stmmac: pci: Refactor DMI probing

Some cleanups of the way we probe DMI platforms in the driver. Reduces a bit of open-coding and makes the logic easier reusable for any potential DMI platform != Quark. Tested on IOT2000 and Galileo Gen2. Changes in v4: - Refactor patch 5 according to feedback Jan Jan Kiszka (6): stmmac

[PATCH v4 1/6] stmmac: pci: Make stmmac_pci_info structure constant

By removing the PCI device reference from the structure and passing it as parameters to the interested functions, we can make quark_pci_info const. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> --- drivers/net/ethernet/st

[PATCH v4 5/6] stmmac: pci: Use dmi_system_id table for retrieving PHY addresses

Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 99 1 file changed, 66 insertions(+), 33 deletions(-) diff --git a/drivers/net/ethernet/s

[PATCH v4 4/6] stmmac: pci: Select quark_pci_dmi_data from quark_default_data

No need to carry this reference in stmmac_pci_info - the Quark-specific setup handler knows that it needs to use the Quark-specific DMI table. This also allows to drop the stmmac_pci_info reference from the setup handler parameter list. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Re

[PATCH v4 6/6] stmmac: pci: Remove setup handler indirection via stmmac_pci_info

By now, stmmac_pci_info only contains a single entry. Register this directly with the PCI device table, removing one indirection. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 34 +--- 1 file changed, 12 inse

[PATCH v4 3/6] stmmac: pci: Make stmmac_pci_find_phy_addr truly generic

Move the special case for the early Galileo firmware into quark_default_setup. This allows to use stmmac_pci_find_phy_addr for non-quark cases. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> --- drivers/net/ethernet/st

[PATCH v4 2/6] stmmac: pci: Use stmmac_pci_info for all devices

Make stmmac_default_data compatible with stmmac_pci_info.setup and use an info structure for all devices. This allows to make the probing more regular. Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> --- drivers/net/ethe

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

On 2017-03-15 12:04, Joao Pinto wrote: > This patch prepares DMA Operation Mode configuration for multiple queues. > The work consisted on breaking the DMA operation Mode configuration function > into RX and TX scope and adapting its mechanism in stmmac_main. > > Signed-off-by: Joao Pinto

[PATCH v2] stmmac: Add support for SIMATIC IOT2000 platform

The IOT2000 is industrial controller platform, derived from the Intel Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the IOT2040 has two of them. They can be told apart based on the board asset tag in the DMI table. Based on patch by Sascha Weisenberger. Signed-off-by: Jan

Re: [PATCH v1 0/4] stmmac: pci: Fix crash on Intel Galileo Gen2

mmac: pci: split out common_default_data() helper > > drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 41 > +++++++- > 1 file changed, 18 insertions(+), 23 deletions(-) > Tested-by: Jan Kiszka <jan.kis...@siemens.com> All fine again, thanks! Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

On 2017-05-08 14:02, Joao Pinto wrote: > Às 12:56 PM de 5/8/2017, Andy Shevchenko escreveu: >> On Mon, May 8, 2017 at 2:40 PM, Joao Pinto wrote: >>> Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu: On Mon, May 8, 2017 at 1:42 PM, Joao Pinto

Re: [PATCH net] e1000e: Remove Other from EIAC.

On 2018-01-31 08:26, Benjamin Poirier wrote: > It was reported that emulated e1000e devices in vmware esxi 6.5 Build > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after > e1000e_trigger_lsc() is called,