The BT coex event is not an error condition. Don't print an error
message in this case. The same even in sta_event.c prints a
message using the debug level already.
Signed-off-by: Stefan Agner
---
drivers/net/wireless/marvell/mwifiex/uap_event.c | 2 +-
1 file changed, 1 insertion(
-off-by: Stefan Agner
---
drivers/net/ethernet/freescale/fec_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 6db69ba30dcd..c8315d880c8c 100644
--- a/drivers/net/ethernet/freescale
ltLinux/linux/issues/103
Signed-off-by: Stefan Agner
---
net/netfilter/nft_osf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nft_osf.c b/net/netfilter/nft_osf.c
index 5af74b37f423..a35fb59ace73 100644
--- a/net/netfilter/nft_osf.c
+++ b/net/netfilter/nft_
On 2017-05-10 21:49, Andy Duan wrote:
> From: Stefan Agner Sent: Thursday, May 11, 2017 12:08 PM
>>To: Andy Duan
>>Cc: David Miller ; and...@lunn.ch;
>>feste...@gmail.com; netdev@vger.kernel.org; linux-
>>ker...@vger.kernel.org
>>Subject: Re: [PATCH] net: fe
c: select queue depending on VLAN priority
>>
>>From: Stefan Agner
>>Date: Mon, 8 May 2017 22:37:08 -0700
>>
>>> Since the addition of the multi queue code with commit 59d0f7465644
>>> ("net: fec: init multi queue date structure") the queue selection
On 2017-05-09 06:39, David Miller wrote:
> From: Stefan Agner
> Date: Mon, 8 May 2017 22:37:08 -0700
>
>> Since the addition of the multi queue code with commit 59d0f7465644
>> ("net: fec: init multi queue date structure") the queue selection
>> has been
Since the addition of the multi queue code with commit 59d0f7465644
("net: fec: init multi queue date structure") the queue selection
has been handelt by the default transmit queue selection
implementation which tries to evenly distribute the traffic across
all available queues. This selection pres
On 2017-05-07 19:13, Andy Duan wrote:
> From: Andrew Lunn Sent: Friday, May 05, 2017 8:24 PM
>>To: Andy Duan
>>Cc: Stefan Agner ; feste...@gmail.com;
>>netdev@vger.kernel.org; netdev-ow...@vger.kernel.org
>>Subject: Re: FEC on i.MX 7 transmit queue timeout
>>
&
On 2017-05-04 19:03, Andy Duan wrote:
> On 2017年05月05日 05:36, Stefan Agner wrote:
>> On 2017-05-03 20:08, Andy Duan wrote:
>>> From: Stefan Agner Sent: Thursday, May 04, 2017 9:22 AM
>>>> To: Andy Duan
>>>> Cc: fugang.d...@freescale.com; feste...@gmail.c
On 2017-05-03 20:08, Andy Duan wrote:
> From: Stefan Agner Sent: Thursday, May 04, 2017 9:22 AM
>>To: Andy Duan
>>Cc: fugang.d...@freescale.com; feste...@gmail.com;
>>netdev@vger.kernel.org; netdev-ow...@vger.kernel.org
>>Subject: Re: FEC on i.MX 7 transmit queue ti
Hi Andy,
On 2017-04-20 19:48, Andy Duan wrote:
> On 2017年04月20日 07:15, Stefan Agner wrote:
>> I tested again with imx6sx-fec compatible string. I could reproduce it
>> on a Colibri with i.MX 7Dual. But not always: It really depends whether
>> queue 2 is counting up or no
On 2017-04-20 00:22, Johannes Berg wrote:
> On Wed, 2017-04-19 at 23:55 -0700, Stefan Agner wrote:
>> Use type enum nl80211_rate_info for bitrate information. This fixes
>> a warning when compiling with clang:
>> warning: implicit conversion from enumeration type '
different enumeration type 'enum nl80211_channel_type'
Signed-off-by: Stefan Agner
---
net/mac80211/ibss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 98999d3d5262..5b748025147d 100644
--- a/net/mac80211/ibss.c
+++ b
Use type enum nl80211_rate_info for bitrate information. This fixes
a warning when compiling with clang:
warning: implicit conversion from enumeration type 'enum nl80211_rate_info'
to different enumeration type 'enum nl80211_attrs'
Signed-off-by: Stefan Agner
---
net/wi
On 2017-04-19 01:45, Andy Duan wrote:
> On 2017年04月19日 13:56, Stefan Agner wrote:
>> On 2017-04-18 22:28, Andy Duan wrote:
>>> From: Stefan Agner Sent: Wednesday, April 19, 2017 1:02 PM
>>>> To: Andy Duan
>>>> Cc: fugang.d...@freescale.com; feste...@gmai
On 2017-04-18 22:28, Andy Duan wrote:
> From: Stefan Agner Sent: Wednesday, April 19, 2017 1:02 PM
>>To: Andy Duan
>>Cc: fugang.d...@freescale.com; feste...@gmail.com;
>>netdev@vger.kernel.org; netdev-ow...@vger.kernel.org
>>Subject: Re: FEC on i.MX 7 transmit queue ti
Hi Andy,
On 2017-04-18 19:24, Andy Duan wrote:
> On 2017年04月19日 03:46, Stefan Agner wrote:
>> Hi,
>>
>> I noticed last week on upstream (v4.11-rc6) on a Colibri iMX7 board that
>> after a while (~10 minutes) the detdev wachdog prints a stacktrace and
>> the driv
Hi,
I noticed last week on upstream (v4.11-rc6) on a Colibri iMX7 board that
after a while (~10 minutes) the detdev wachdog prints a stacktrace and
the driver then continuously dumps the TX ring. I then did a quick test
with 4.10, and realized it actually suffers the same issue, so it seems
not to
The attribute declaration is typically before the definition. Move
the __maybe_unused attribute declaration before the struct keyword.
Signed-off-by: Stefan Agner
---
Changes in v2:
- Move __maybe_unused after the complete type
drivers/net/ethernet/cirrus/cs89x0.c | 2 +-
1 file changed, 1
On 2017-04-17 13:09, David Miller wrote:
> From: Stefan Agner
> Date: Sun, 16 Apr 2017 23:20:32 -0700
>
>> The attribute declaration is typically before the definition. Move
>> the __maybe_unused attribute declaration before the struct keyword.
>>
>> Signed-off-
The attribute declaration is typically before the definition. Move
the __maybe_unused attribute declaration before the struct keyword.
Signed-off-by: Stefan Agner
---
drivers/net/ethernet/cirrus/cs89x0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet
When using bridge without bridge netfilter enabled the message
displayed is rather confusing and leads to belive that a deprecated
feature is in use. Use IS_MODULE to be explicit that the message only
affects users which use bridge netfilter as module and reword the
message.
Signed-off-by: Stefan
[added Tom Gundersen as he seemed to have worked on udev's net link
built-in]
On 2016-04-12 08:44, David Miller wrote:
> From: Bob Ham
> Date: Tue, 12 Apr 2016 09:58:12 +0100
>
>> On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:
>>
>>> Or in other words
On 2016-04-11 18:29, David Miller wrote:
> From: Stefan Agner
> Date: Mon, 11 Apr 2016 15:46:08 -0700
>
>> What is the expectation/definition when link configuration should be
>> possible? Only after the network device got opened or before?
>
> Only after it is open.
Hi All,
I traced an issue in which we tried configuring duplex mode and speed in
a systemd-udevd .link file failed with the following error:
"Could not set speed or duplex of eth0 to 0 Mbps (half): No such device"
The FEC driver (fec_main.c) does not initialize phy_dev until the device
has been o
On 2016-02-10 14:10, Florian Fainelli wrote:
> Hi Stefan,
>
> On 10/02/16 11:25, Stefan Agner wrote:
>> Hi David, Hi Florian,
>>
>> We use a Micrel KSZ8041NL and we observe sometimes continuous RX errors
>> (PHY's RXER counter is continuously incre
Hi David, Hi Florian,
We use a Micrel KSZ8041NL and we observe sometimes continuous RX errors
(PHY's RXER counter is continuously incrementing, activity LED blinks
and no communication is possible). It seems that only some PHY's are
affected (3-4%) and only in certain temperature ranges (the PHY I
On 2015-07-15 15:15, Marc Kleine-Budde wrote:
> On 07/15/2015 03:05 PM, Stefan Agner wrote:
>> Hi Marc, hi Wolfgang,
>>
>> Any comment on this two patches? I don't think these have made it in any
>> tree...
>
> Sorry - Should I add stable in Cc for 1/2 or
Hi Marc, hi Wolfgang,
Any comment on this two patches? I don't think these have made it in any
tree...
--
Stefan
On 2015-05-18 18:33, Stefan Agner wrote:
> If a valid power regulator or a dummy regulator is used (which
> happens to be the case when no regulator is specified), restar
29 matches
Mail list logo
