On 06.11.20 10:43, Wong Vee Khee wrote:
> From: Voon Weifeng
>
> Set all EHL/TGL phy_addr to -1 so that the driver will automatically
> detect it at run-time by probing all the possible 32 addresses.
>
> Signed-off-by: Voon Weifeng
> Signed-off-by: Wong Vee Khee
> ---
> drivers/net/ethernet/s
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, I
On 2017-06-22 19:40, David Miller wrote:
> From: Jan Kiszka
> 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 any
>> potential DMI platfor
From: Jan Kiszka
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
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 36
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
From: Jan Kiszka
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
Reviewed-by
From: Jan Kiszka
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
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 20
From: Jan Kiszka
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
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23
From: Jan Kiszka
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 97
1 file changed, 64 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 99
1 file changed, 66 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b
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
Reviewed-by: Andy Shevchenko
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
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
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++
1 file
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
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 36 +++-
1
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 34 +---
1 file changed, 12 insertions(+), 22 deletions(-)
diff
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
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 20 +---
1 file changed
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 34 +---
1 file changed, 12 insertions(+), 22 deletions(-)
diff
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 36 +++-
1 file changed, 23 insertions
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++
1 file changed, 11 insertions(+), 12
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
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
---
drivers/net/ethernet/stmicro
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 77 ++--
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b
On 2017-05-27 15:38, Andy Shevchenko wrote:
> On Fri, May 26, 2017 at 7:07 PM, Jan Kiszka wrote:
>> By now, stmmac_pci_info only contains a single entry.
>
> _For now_.
>
>> Register this
>> directly with the PCI device table, removing one indirection.
>
>
On 2017-05-27 15:28, Andy Shevchenko wrote:
> On Fri, May 26, 2017 at 7:07 PM, Jan Kiszka wrote:
>> Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
>
>> struct stmmac_pci_dmi_data {
>> - const char *name;
>> - const char *asset_tag
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 35 +---
1 file changed, 13 insertions(+), 22 deletions(-)
diff
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 33 +++-
1 file changed, 21 insertions
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 23 +++
1 file changed, 11 insertions(+), 12
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
---
drivers/net/ethernet/stmicro
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 77 ++--
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b
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
On 2017-05-22 18:35, David Miller wrote:
> From: Jan Kiszka
> 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 any
>> potential DMI platfor
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
, we can make a setup function
mandatory, and probing becomes more regular.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 122 +++
1 file changed, 59 insertions(+), 63 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
Avoids reimplementation of DMI matching in stmmac_pci_find_phy_addr.
Signed-off-by: Jan Kiszka
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 77 ++--
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b
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
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions
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
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
All fine again, thanks!
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
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 wrote:
> Às 11:12 AM de 5/8/2017, Andy Shevch
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
> ---
>
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
On 2017-04-25 13:42, Andy Shevchenko wrote:
> On Tue, Apr 25, 2017 at 1:09 PM, Jan Kiszka 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
>>>> 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 wrote:
>>> On 2017-04-25 09:30, Andy Shevchenko wrote:
>>>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka wrote:
>>>>&g
On 2017-04-25 11:46, Andy Shevchenko wrote:
> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka wrote:
>> On 2017-04-25 09:30, Andy Shevchenko wrote:
>>> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka wrote:
>>>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>>&
On 2017-04-25 09:30, Andy Shevchenko wrote:
> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka wrote:
>> On 2017-04-24 23:27, Andy Shevchenko wrote:
>>> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka wrote:
>>>> The IOT2000 is industrial controller platform, derived fr
On 2017-04-24 23:27, Andy Shevchenko wrote:
> On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka wrote:
>> 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. T
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
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
>
s delete an
existing 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 |
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
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. Mor
er
a new 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.
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()
>>>> ieee80211_master_start_xmit
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()
>>> ieee80211_master_start_xmit+0x105/0x430 [80211]
>>> __ip_ct_
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
> bea
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
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()
>> ieee80211_master_start_xmit+0x105/0x430 [80211]
>> __ip_ct_refresh_acct+0x4d/0x60
>> tcp_p
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
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
Hi,
can someone explain how TX flow control in d80211 is supposed to work? I
failed to understand the full design so far.
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), preven
: Jan Kiszka <[EMAIL PROTECTED]>
[Sorry, patch is against rt2x00 CVS. I'm lacking time and bandwidth to pull
the d80211 git repos and rebase.]
---
ieee80211/ieee80211_i.h | 24 ++--
ieee80211/ieee80211_ioctl.c |4 +++-
ieee80211/sta_info.c|2
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 <[EM
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_TYP
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 US
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 su
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 l
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
show_trace+0x12/0x14
dump_stack+0x1c/0x1e
schedule+0x5f/0x652
w
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 th
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 contrast
70 matches
Mail list logo
