On 19.04.2021 09:04, Pkshih wrote:
-Original Message-
From: Larry Finger [mailto:larry.fin...@gmail.com] On Behalf Of Larry Finger
Sent: Monday, April 19, 2021 9:23 AM
To: Pkshih; Maciej S. Szmigiero
Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org;
linux-ker
On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
On 08.04.2021 06:42, Pkshih wrote:
-Original Message-
From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
Sent: Thursday, April 08, 2021 4:53 AM
To: Larry Finger; Pkshih
Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org
On 08.04.2021 06:42, Pkshih wrote:
-Original Message-
From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
Sent: Thursday, April 08, 2021 4:53 AM
To: Larry Finger; Pkshih
Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org;
linux-ker...@vger.kernel.org;
johan
On 07.04.2021 06:21, Larry Finger wrote:
On 4/6/21 9:48 PM, Pkshih wrote:
On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
On 06.04.2021 12:00, Kalle Valo wrote:
"Maciej S. Szmigiero" writes:
On 29.03.2021 00:54, Maciej S.
On 06.04.2021 18:25, Larry Finger wrote:
On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
On 06.04.2021 12:00, Kalle Valo wrote:
"Maciej S. Szmigiero" writes:
On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
Hi,
It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using
On 06.04.2021 12:00, Kalle Valo wrote:
"Maciej S. Szmigiero" writes:
On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
Hi,
It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
since the driver does not update its beacon to account for TIM changes,
so a stati
On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
Hi,
It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
since the driver does not update its beacon to account for TIM changes,
so a station that is sleeping will never learn that it has packets
buffered at the AP.
Looking
Hi,
It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
since the driver does not update its beacon to account for TIM changes,
so a station that is sleeping will never learn that it has packets
buffered at the AP.
Looking at the code, the rtl8192cu driver implements neithe
On 19.10.2020 04:54, Jia-Ju Bai wrote:
> In rtl8180_tx(), skb->data is mapped to streaming DMA on line 476:
> mapping = dma_map_single(..., skb->data, ...);
>
> On line 459, skb->data is assigned to hdr after cast:
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
>
> Then hdr-
#x27;t suspended and resumed.
Fixes: 05212ba8132b42 ("r8169: set RxConfig after tx/rx is enabled for
RTL8169sb/8110sb devices")
Reported-by: Chris Clayton
Signed-off-by: Maciej S. Szmigiero
---
drivers/net/ethernet/realtek/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
).
>
> Fixes: 4fd48c4ac0a0 ("r8169: move common initializations to tp->hw_start")
> Reported-by: Ortwin Glück
> Reported-by: David Arendt
> Tested-by: Tony Atkinson
> Tested-by: David Arendt
> Tested-by: Ortwin Glück
> Signed-off-by: Heiner Kallweit
Please add:
Root-caused-by: Maciej S. Szmigiero
Thanks,
Maciej
On 19.09.2018 18:34, David Arendt wrote:
> Hi,
>
> the networking problem did not occur for 12 hours now, so I think this
> patch resolved the problem.
@Heiner:
It seems that the regression was introduced by your
commit 4fd48c4ac0a0 ("r8169: move common initializations to tp->hw_start").
Will yo
ich will fire on any link
speed known to the PHY. Such trigger can then be used for implementing a
poor man's substitute of the "link" LED on boards that lack it.
Let's add it.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Don't keep the "link" trigg
Hi Andrew,
On 01.11.2017 13:33, Maciej S. Szmigiero wrote:
> On 01.11.2017 13:31, Andrew Lunn wrote:
>>> Yes, I did it the same way as the existing code did for
>>> phy->phy_led_triggers
>>> for reasons of both consistency and also to be on the safe side be
te function so it is more obvious
what the code is doing.
Signed-off-by: Maciej S. Szmigiero
---
drivers/net/phy/phy_led_triggers.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/phy_led_triggers.c
b/drivers/net/phy/phy_led_trig
Hi Andrew,
On 01.11.2017 13:37, Andrew Lunn wrote:
> Hi Maciej
>
> I don't particularly like the
>
>if (!phy->link)
> goto out_change_speed;
>
> part of the existing code. Makes me thing of BASIC. goto is good for
> error handling, but this is not an error.
>
> If you f
Hi Andrew,
On 01.11.2017 13:31, Andrew Lunn wrote:
>> Yes, I did it the same way as the existing code did for phy->phy_led_triggers
>> for reasons of both consistency and also to be on the safe side because
>> maybe there is some non-obvious reason why it has to be freed
>> explicitly (?).
>
> H
Hi Andrew,
On 01.11.2017 13:16, Andrew Lunn wrote:
>> @@ -123,6 +153,10 @@ int phy_led_triggers_register(struct phy_device *phy)
>> while (i--)
>> phy_led_trigger_unregister(&phy->phy_led_triggers[i]);
>> devm_kfree(&phy->mdio.dev, phy->phy_led_triggers);
>> +out_unreg_link:
ich will fire on any link
speed known to the PHY. Such trigger can then be used for implementing a
poor man's substitute of the "link" LED on boards that lack it.
Let's add it.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Don't keep the "link" trigg
On 30.10.2017 19:36, Florian Fainelli wrote:
> On 10/28/2017 08:27 AM, Maciej S. Szmigiero wrote:
>> Currently, we create a LED trigger for any link speed known to a PHY.
>> These triggers only fire when their exact link speed had been negotiated
>> (they aren't cumul
ich will fire on any link
speed known to the PHY. Such trigger can then be used for implementing a
poor man's substitute of the "link" LED on boards that lack it.
Let's add it.
Signed-off-by: Maciej S. Szmigiero
---
drivers/net/phy/Kconfig| 7 +--
It looks like IPAC/ISAC chips register defines weren't in any particular
order.
Order them by their number to make it easier to spot holes.
Signed-off-by: Maciej S. Szmigiero
---
drivers/isdn/hardware/mISDN/ipac.h | 40 +++---
1 file changed, 20 inser
According to figure 39 in PEB3086 data sheet, version 1.4 this indication
replaces DR when layer 1 transition source state is F6.
This fixes mISDN layer 1 getting stuck in F6 state in TE mode on
Dialogic Diva 2.02 card (and possibly others) when NT deactivates it.
Signed-off-by: Maciej S
If fec MDIO write method succeeds its return value comes from
call to pm_runtime_get_sync().
But pm_runtime_get_sync() can also return 1.
In case of Micrel KSZ9031 PHY this value will then
be returned along the call chain of phy_write() ->
ksz9031_extended_write() -> ksz9031_center_flp_timing() ->
restore_regulatory_settings() should restore alpha2
as computed in restore_alpha2(), not raw user_alpha2 to
behave as described in the comment just above that code.
This fixes endless loop of calling CRDA for "00" and "97"
countries after resume from suspend on my laptop.
Looks like others had th
25 matches
Mail list logo
