On 15.04.2021 20:59, Heiner Kallweit wrote:
> Currently, if the user changes the pause settings, the default settings
> will be restored after an interface down/up cycle, and also when
> resuming from suspend. This doesn't seem to provide the best user
> experience. Change
se is disabled.
Small drawback: When switching back mtu from jumbo to non-jumbo then
pause remains disabled (but user can enable it using ethtool).
I think that's a not too common scenario and acceptable.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 14 +++
On 15.04.2021 01:12, Jakub Kicinski wrote:
> On Wed, 14 Apr 2021 08:23:15 +0200 Heiner Kallweit wrote:
>> This adds support for the [g|s]et_pauseparam ethtool ops. It considers
>> that the chip doesn't support pause frame use in jumbo mode.
>
> what happens if the
illa.kernel.org/show_bug.cgi?id=212617
Fixes: 9cf9b84cc701 ("r8169: make use of phy_set_asym_pause")
Reported-by: Roman Mamedov
Tested-by: Roman Mamedov
Signed-off-by: Heiner Kallweit
Cc: sta...@vger.kernel.org
---
This patch doesn't apply cleanly on some kernel versions, but the needed
On 14.04.2021 09:49, Greg KH wrote:
> On Wed, Apr 14, 2021 at 09:40:51AM +0200, Heiner Kallweit wrote:
>> It has been reported [0] that using pause frames in jumbo mode impacts
>> performance. There's no available chip documentation, but vendor
>> drivers r8168 and r812
illa.kernel.org/show_bug.cgi?id=212617
Fixes: 9cf9b84cc701 ("r8169: make use of phy_set_asym_pause")
Reported-by: Roman Mamedov
Tested-by: Roman Mamedov
Signed-off-by: Heiner Kallweit
---
This patch doesn't apply cleanly on some kernel versions, but the needed
changes are trivial.
---
This adds support for the [g|s]et_pauseparam ethtool ops. It considers
that the chip doesn't support pause frame use in jumbo mode.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/dr
On 13.04.2021 22:59, Xose Vazquez Perez wrote:
> A non-recurring bug, on 5.11.12-300.fc34.x86_64 (Fedora kernel).
>
> Thanks.
>
>
> 0c:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
>
> [ 2.96
On 09.04.2021 20:41, Radu Pirea (NXP OSS) wrote:
> Add driver for tja1103 driver and for future NXP C45 PHYs.
>
> Signed-off-by: Radu Pirea (NXP OSS)
> ---
> MAINTAINERS | 6 +
> drivers/net/phy/Kconfig | 6 +
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/nxp-c45.c |
On 09.04.2021 17:24, Paolo Abeni wrote:
> napi_disable() is subject to an hangup, when the threaded
> mode is enabled and the napi is under heavy traffic.
>
> If the relevant napi has been scheduled and the napi_disable()
> kicks in before the next napi_threaded_wait() completes - so
> that the la
On 07.04.2021 17:50, Heiner Kallweit wrote:
> Resume callback of the PHY driver is called after the one for the MAC
> driver. The PHY driver resume callback calls phy_init_hw(), and this is
> potentially problematic if the MAC driver calls phy_start() in its resume
> callback. O
On 08.04.2021 20:35, Sven Van Asbroeck wrote:
> Hi George,
>
> On Thu, Apr 8, 2021 at 2:26 PM Sven Van Asbroeck wrote:
>>
>> George, I will send a patch for you to try shortly. Except if you're
>> already ahead :)
>
> Would this work for you? It does for me.
>
> diff --git a/drivers/net/etherne
On 08.04.2021 20:00, George McCollister wrote:
> On Thu, Apr 8, 2021 at 12:46 PM Sven Van Asbroeck wrote:
>>
>> Hi George,
>>
>> On Thu, Apr 8, 2021 at 1:36 PM George McCollister
>> wrote:
>>>
>>> Can you explain the difference in behavior with what I was observing
>>> on the LAN7431?
>>
>> I'm n
On 08.04.2021 19:23, Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck
>
> This reverts commit 3e21a10fdea3c2e4e4d1b72cb9d720256461af40.
>
> The reverted patch completely breaks all network connectivity on the
> lan7430. tcpdump indicates missing bytes when receiving ping
> packets from an exte
hether your case remains
the only one or whether there will be more similar reports.
In this case we had to think about a fix that doesn't need new
functionality or check whether backporting the new functionality
would be acceptable.
> Best Regards,
> Joakim Zhang
>
Heiner
>> ---
On 08.04.2021 07:45, Joakim Zhang wrote:
>
>> -Original Message-
>> From: Heiner Kallweit
>> Sent: 2021年4月7日 23:53
>> To: Andrew Lunn ; Russell King - ARM Linux
>> ; Jakub Kicinski ; David Miller
>> ; Fugang Duan
>> Cc: netdev@vger.kernel.org
Use the new mac_managed_pm flag to indicate that the driver takes care
of PHY power management.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet
Use the new mac_managed_pm flag to work around an issue with KSZ8081 PHY
that becomes unstable when a soft reset is triggered during aneg.
Reported-by: Joakim Zhang
Tested-by: Joakim Zhang
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/freescale/fec_main.c | 3 +++
1 file changed, 3
to become unstable if a soft reset is triggered during aneg.
The new flag allows MAC drivers to indicate that they take care of
suspending/resuming the PHY. Then the MAC PM callbacks can handle
any dependency between MAC and PHY PM.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy
to become unstable if a soft reset is triggered during aneg.
The new flag allows MAC drivers to indicate that they take care of
suspending/resuming the PHY. Then the MAC PM callbacks can handle
any dependency between MAC and PHY PM.
Heiner Kallweit (3):
net: phy: make PHY PM ops a no-op if MAC
On 07.04.2021 12:05, Joakim Zhang wrote:
>
> Hi Heiner,
>
>> -Original Message-
>> From: Joakim Zhang
>> Sent: 2021年4月7日 15:46
>> To: Heiner Kallweit ; christian.me...@t2data.com;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davemlof
On 07.04.2021 03:43, Joakim Zhang wrote:
>
> Hi Heiner,
>
>> -Original Message-
>> From: Heiner Kallweit
>> Sent: 2021年4月7日 2:22
>> To: Joakim Zhang ; christian.me...@t2data.com;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davemloft.net;
>&
On 06.04.2021 20:32, Florian Fainelli wrote:
>
>
> On 4/6/2021 4:42 AM, Heiner Kallweit wrote:
>>
>> Waiting for ANEG_COMPLETE to be set wouldn't be a good option. Aneg may never
>> complete for different reasons, e.g. no physical link. And even if we use a
On 06.04.2021 13:42, Heiner Kallweit wrote:
> On 06.04.2021 12:07, Joakim Zhang wrote:
>>
>>> -Original Message-
>>> From: Heiner Kallweit
>>> Sent: 2021年4月6日 14:29
>>> To: Joakim Zhang ; christian.me...@t2data.com;
>>> and...@lunn
On 06.04.2021 12:07, Joakim Zhang wrote:
>
>> -Original Message-
>> From: Heiner Kallweit
>> Sent: 2021年4月6日 14:29
>> To: Joakim Zhang ; christian.me...@t2data.com;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davemloft.net;
>> k...@kernel.org
&
On 06.04.2021 04:07, Joakim Zhang wrote:
>
> Hi Heiner,
>
>> -Original Message-
>> From: Heiner Kallweit
>> Sent: 2021年4月5日 20:10
>> To: christian.me...@t2data.com; Joakim Zhang ;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davemlof
On 05.04.2021 15:53, Christian Melki wrote:
> On 4/5/21 2:09 PM, Heiner Kallweit wrote:
>> On 05.04.2021 10:43, Christian Melki wrote:
>>> On 4/5/21 12:48 AM, Heiner Kallweit wrote:
>>>> On 04.04.2021 16:09, Heiner Kallweit wrote:
>>>>> On 04.04.
On 05.04.2021 10:43, Christian Melki wrote:
> On 4/5/21 12:48 AM, Heiner Kallweit wrote:
>> On 04.04.2021 16:09, Heiner Kallweit wrote:
>>> On 04.04.2021 12:07, Joakim Zhang wrote:
>>>> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
>&
On 04.04.2021 16:09, Heiner Kallweit wrote:
> On 04.04.2021 12:07, Joakim Zhang wrote:
>> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
>> off PHY power") invokes phy_init_hw() when MDIO bus resume, it will
>> soft reset PHY if PHY driver
On 04.04.2021 12:07, Joakim Zhang wrote:
> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
> off PHY power") invokes phy_init_hw() when MDIO bus resume, it will
> soft reset PHY if PHY driver implements soft_reset callback.
> commit 764d31cacfe4 ("net: phy: micrel: set soft_reset
All callers pass 0 as offset. Therefore remove the parameter and use
a fixed offset 0 in pci_vpd_find_tag().
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/broadcom/bnx2.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 3 +--
drivers/net/ethernet/broadcom/bnxt
gt; v3: https://lore.kernel.org/r/992c800e-2e12-16b0-4845-6311b295d...@gmail.com/
> - improve commit message of patch 2
>
> v4:
> - add pci_disable_parity() (not conditional on CONFIG_PCI_QUIRKS)
> - remove setting of dev->broken_parity_status
>
>
> Bjorn Helgaas (1):
>
On 29.03.2021 11:02, Lv Yunlong wrote:
> In rtl8169_start_xmit, it calls rtl8169_tso_csum_v2(tp, skb, opts) and
> rtl8169_tso_csum_v2() calls __skb_put_padto(skb, padto, false). If
> __skb_put_padto() failed, it will free the skb in the first time and
> return error. Then rtl8169_start_xmit will go
On 28.03.2021 21:59, Måns Rullgård wrote:
> Andre Edich writes:
>
>> Generally, each PHY has their own configuration and it can be done
>> through an external PHY driver. The smsc95xx driver uses only the
>> hard-coded internal PHY configuration.
>>
>> This patch adds phylib support to probe ext
On 26.03.2021 22:26, Bjorn Helgaas wrote:
> [+cc Randy, Andrew (though I'm sure you have zero interest in this
> ancient question :))]
>
> On Wed, Dec 09, 2020 at 09:31:21AM +0100, Heiner Kallweit wrote:
>> pci_set_mwi() and pci_try_set_mwi() do exactly the same, just th
On 27.03.2021 19:32, James Feeney wrote:
>
>> Downgrading the kernel resolves the problem, but I don't see any bonding
>> commits between linux-lts-5.10.25 and linux-lts 5.10.26.
>
> My mistake - 9392b8219b62b0536df25c9de82b33f8a00881ef *was* included in
> 5.10.26. Thus the "Invalid argument"
On 25.03.2021 21:29, Marek Behún wrote:
> On Thu, 25 Mar 2021 15:54:52 +
> Russell King - ARM Linux admin wrote:
>
>> The 88X3310 and 88X3340 can be differentiated by bit 3 in the revision.
>> In other words, 88X3310 is 0x09a0..0x09a7, and 88X3340 is
>> 0x09a8..0x09af. We could add a separate
On 25.03.2021 16:40, Anand Moon wrote:
> Hi Heiner
>
>
> On Thu, 25 Mar 2021 at 18:49, Heiner Kallweit wrote:
>>
>> On 25.03.2021 13:42, Anand Moon wrote:
>>> On most of the Amlogic SoC I observed that Ethernet would not get
>>> initialize when try to d
On 25.03.2021 14:33, Anand Moon wrote:
> Hi Andrew,
>
> On Thu, 25 Mar 2021 at 18:27, Andrew Lunn wrote:
>>
>> On Thu, Mar 25, 2021 at 12:42:20PM +, Anand Moon wrote:
>>> Fix the parsing of check of pattern ethernet-phy-ieee802.3 used
>>> by the device tree to initialize the mdio phy.
>>>
>>>
On 25.03.2021 13:42, Anand Moon wrote:
> On most of the Amlogic SoC I observed that Ethernet would not get
> initialize when try to deploy the mainline kernel, earlier I tried to
> fix this issue with by setting ethernet reset but it did not resolve
> the issue see below.
> resets = <&reset R
We can simply use rtl_hw_start_8168c_2() also for chip version 21.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek
On 23.03.2021 17:46, Wong Vee Khee wrote:
> Add generic code to enable C45 PHY loopback into the common phy-c45.c
> file. This will allow C45 PHY drivers aceess this by setting
> .set_loopback.
>
> Suggested-by: Heiner Kallweit
> Signed-off-by: Wong Vee Khee
> ---
> d
On 23.03.2021 09:48, Wong Vee Khee wrote:
> From: Tan Tee Min
>
> Add support for PHY loopback for the Marvell 88E2110 PHY.
>
> This allow user to perform selftest using ethtool.
>
> Signed-off-by: Tan Tee Min
> Signed-off-by: Wong Vee Khee
> ---
> drivers/net/phy/marvell10g.c | 12 +
Add support for the ethtool get_ringparam operation.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index
: 567ca57faa62 ("r8169: add rtl8169_up")
Tested-by: Paul Blazejowski
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8
I get the following error on linux-next when bringing the device up.
It's such an obvious error that I wonder how it could pass your QA.
led_trigger_event() disables interrupts, and spin_unlock_bh() complains
about this. The following fixes the warning for me.
I'd say this means also commit "iwlw
Use the lower_32_bits/upper_32_bits macros to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek
On 18.03.2021 10:09, Wong Vee Khee wrote:
> When using Clause-22 to probe for PHY devices such as the Marvell
> 88E2110, PHY ID with value 0 is read from the MII PHYID registers
> which caused the PHY framework failed to attach the Marvell PHY
> driver.
>
> Fixed this by adding a check of PHY ID e
netdev/fdf0074a-2572-5914-6f3e-77202cbf9...@gmail.com/
>
> Suggested-by: Vladimir Oltean
> Signed-off-by: Michael Walle
> ---
Reviewed-by: Heiner Kallweit
On 18.03.2021 18:04, Vladimir Oltean wrote:
> On Thu, Mar 18, 2021 at 05:38:13PM +0100, Michael Walle wrote:
>> Am 2021-03-18 17:21, schrieb Heiner Kallweit:
>>> On 18.03.2021 16:17, Vladimir Oltean wrote:
>>>> On Thu, Mar 18, 2021 at 03:54:00PM +0100, Heiner Kallweit
On 18.03.2021 17:02, Florian Fainelli wrote:
>
>
> On 3/18/2021 6:25 AM, Heiner Kallweit wrote:
>> On 18.03.2021 10:09, Wong Vee Khee wrote:
>>> When using Clause-22 to probe for PHY devices such as the Marvell
>>> 88E2110, PHY ID with value 0 is read from
On 18.03.2021 16:17, Vladimir Oltean wrote:
> On Thu, Mar 18, 2021 at 03:54:00PM +0100, Heiner Kallweit wrote:
>> On 18.03.2021 15:23, Michael Walle wrote:
>>> at803x_aneg_done() is pretty much dead code since the patch series
>>> "net: phy: improve and simplify p
On 18.03.2021 15:23, Michael Walle wrote:
> at803x_aneg_done() is pretty much dead code since the patch series
> "net: phy: improve and simplify phylib state machine" [1]. Remove it.
>
Well, it's not dead, it's resting .. There are few places where
phy_aneg_done() is used. So you would need to ex
On 18.03.2021 10:09, Wong Vee Khee wrote:
> When using Clause-22 to probe for PHY devices such as the Marvell
> 88E2110, PHY ID with value 0 is read from the MII PHYID registers
> which caused the PHY framework failed to attach the Marvell PHY
> driver.
>
> Fixed this by adding a check of PHY ID e
On 16.03.2021 09:57, Wong Vee Khee wrote:
> When using Clause-22 to probe for PHY devices such as the Marvell
> 88E2110, PHY ID with value 0 is read from the MII PHYID registers
> which caused the PHY framework failed to attach the Marvell PHY
> driver.
>
The issue occurs with a MAC driver that s
Simplify the code by using dma_set_mask_and_coherent().
Signed-off-by: Heiner Kallweit
---
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
b/drivers/net/wireless/intel
Use DECLARE_BITMAP macro to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/net/wireless/intel/iwlwifi/fw/img.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/img.h
b/drivers/net/wireless/intel/iwlwifi/fw/img.h
index
If a chip supports additional API calls that are not supported by the
driver yet, then this is no reason to bother users with a warning.
Therefore switch the message to debug level.
Signed-off-by: Heiner Kallweit
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 10 --
1 file changed
Series includes smaller improvements.
Heiner Kallweit (3):
iwlwifi: use DECLARE_BITMAP macro
iwlwifi: switch "index larger than supported by driver" warning to
debug level
iwlwifi: use dma_set_mask_and_coherent
drivers/net/wireless/intel/iwlwifi/fw/img.h | 4 ++--
d
On 11.03.2021 17:00, gmail wrote:
> 15. huhtik. 2020, 19.18, Heiner Kallweit <mailto:hkallwe...@gmail.com>> kirjoitti:
>
> On 15.04.2020 16:39, Lauri Jakku wrote:
>
> Hi, There seems to he Something odd problem, maybe timing
> related. Stripped versio
On 10.03.2021 22:15, Florian Fainelli wrote:
> On 3/10/21 1:07 PM, Heiner Kallweit wrote:
>> On 10.03.2021 21:41, Florian Fainelli wrote:
>>> B50212E PHYs have been observed to get into an incorrect state with the
>>> visible effect of having both activity and link LEDs
On 10.03.2021 21:41, Florian Fainelli wrote:
> B50212E PHYs have been observed to get into an incorrect state with the
> visible effect of having both activity and link LEDs flashing
> alternatively instead of being turned off as intended when
> genphy_suspend() was issued. The BCM54810 is a simila
In r8169 standard irq coalescing is disabled per default, and setting
gro_flush_timeout = 2 and napi_defer_hard_irqs = 1 reduces interrupt
number significantly, e.g. in iperf.
Therefore I wonder whether it would make sense to set reasonable defaults
for both parameters in the driver, similar to
On 09.03.2021 09:33, Jia-Ju Bai wrote:
> When kcalloc() returns NULL to nl_table, no error return code of
> netlink_proto_init() is assigned.
> To fix this bug, err is assigned with -ENOMEM in this case.
>
Didn't we talk enough about your incorrect patches yesterday?
This one is incorrect again.
On 08.03.2021 13:18, Jia-Ju Bai wrote:
>
>
> On 2021/3/8 18:19, Heiner Kallweit wrote:
>> On 08.03.2021 10:31, Jia-Ju Bai wrote:
>>> When sock_alloc_send_skb() returns NULL to skb, no error return code of
>>> dgram_sendmsg() is assigned.
>>> To fix this
On 08.03.2021 10:31, Jia-Ju Bai wrote:
> When sock_alloc_send_skb() returns NULL to skb, no error return code of
> dgram_sendmsg() is assigned.
> To fix this bug, err is assigned with -ENOMEM in this case.
>
Please stop sending such nonsense. Basically all such patches you
sent so far are false p
On 07.03.2021 10:31, Jia-Ju Bai wrote:
> Hi Leon,
>
> I am quite sorry for my incorrect patches...
> My static analysis tool reports some possible bugs about error handling code,
> and thus I write some patches for the bugs that seem to be true in my opinion.
> Because I am not familiar with many
On 06.03.2021 15:07, Jia-Ju Bai wrote:
> When fib_entry is NULL, no error return code of
> mlxsw_sp_router_nve_promote_decap() is assigned.
> To fix this bug, err is assigned with -EINVAL in this case.
>
Again, are you sure this is a bug? To me it looks like it is
intentional to not return an erro
*cmd |= 0x7f0 << 18;
> + *cmd |= 0xf70 << 18;
> }
>
> DECLARE_RTL_COND(rtl_eriar_cond)
>
Acked-by: Heiner Kallweit
On 04.03.2021 15:18, Jia-Ju Bai wrote:
> When mlx5_is_fpga_lookaside() returns a non-zero value, no error
> return code is assigned.
> To fix this bug, err is assigned with -EINVAL as error return code.
>
To me it looks like the current behavior is intentional.
Did you verify that it's actually a
On 03.03.2021 08:39, Valdis Klētnieks wrote:
> On Wed, 03 Mar 2021 07:51:06 +0100, Heiner Kallweit said:
>>> # Firmware loader
>>> CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8106e-1.fw"
>>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>>>
>>
On 03.03.2021 07:09, Valdis Klētnieks wrote:
> So my kernel build died..
>
> UPD drivers/base/firmware_loader/builtin/rtl_nic/rtl8106e-1.fw.gen.S
> make[4]: *** No rule to make target '/lib/firmware/rtl_nic/rtl8106e-1.fw',
> needed by 'drivers/base/firmware_loader/builtin/rtl_nic/rtl8106e-1
On 26.02.2021 15:16, Andrew Lunn wrote:
>>> OK, I see. Then there's no reason to complain upstream.
>>> Either use the mainline B53 DSA driver of fix interrupt mode
>>> downstream.
>>
>> I agree.
>>
>> This b53 driver has one PHY with the same BCM63XX phy_id, causing a
>> double probe. I'll send th
On 26.02.2021 13:18, Kai-Heng Feng wrote:
> On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit wrote:
>>
>> On 26.02.2021 08:12, Kalle Valo wrote:
>>> Kai-Heng Feng writes:
>>>
>>>> Now we have a generic D3 shutdown quirk, so convert the original
>&
On 26.02.2021 08:12, Kalle Valo wrote:
> Kai-Heng Feng writes:
>
>> Now we have a generic D3 shutdown quirk, so convert the original
>> approach to a PCI quirk.
>>
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/net/wireless/realtek/rtw88/pci.c | 2 --
>> drivers/pci/quirks.c
On 26.02.2021 10:49, Daniel González Cabanelas wrote:
> El vie, 26 feb 2021 a las 10:32, Heiner Kallweit
> () escribió:
>>
>> On 26.02.2021 10:10, Daniel González Cabanelas wrote:
>>> El vie, 26 feb 2021 a las 8:13, Heiner Kallweit
>>> () escribió:
>>&g
On 26.02.2021 10:32, Heiner Kallweit wrote:
> On 26.02.2021 10:10, Daniel González Cabanelas wrote:
>> El vie, 26 feb 2021 a las 8:13, Heiner Kallweit
>> () escribió:
>>>
>>> On 25.02.2021 23:28, Daniel González Cabanelas wrote:
>>>> El
On 26.02.2021 10:10, Daniel González Cabanelas wrote:
> El vie, 26 feb 2021 a las 8:13, Heiner Kallweit
> () escribió:
>>
>> On 25.02.2021 23:28, Daniel González Cabanelas wrote:
>>> El jue, 25 feb 2021 a las 21:05, Heiner Kallweit
>>> () escribió:
>>&g
On 25.02.2021 23:28, Daniel González Cabanelas wrote:
> El jue, 25 feb 2021 a las 21:05, Heiner Kallweit
> () escribió:
>>
>> On 25.02.2021 17:36, Daniel González Cabanelas wrote:
>>> El jue, 25 feb 2021 a las 8:22, Heiner Kallweit
>>> () escribió:
>>&g
On 25.02.2021 23:28, Daniel González Cabanelas wrote:
> El jue, 25 feb 2021 a las 21:05, Heiner Kallweit
> () escribió:
>>
>> On 25.02.2021 17:36, Daniel González Cabanelas wrote:
>>> El jue, 25 feb 2021 a las 8:22, Heiner Kallweit
>>> () escribió:
>>&g
On 25.02.2021 17:36, Daniel González Cabanelas wrote:
> El jue, 25 feb 2021 a las 8:22, Heiner Kallweit
> () escribió:
>>
>> On 25.02.2021 00:54, Daniel González Cabanelas wrote:
>>> El mié, 24 feb 2021 a las 23:01, Florian Fainelli
>>> () escribió:
>>>
-by: Josef Oškera
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index e7a59dc5f..35b015c9a 100644
--- a/d
On 25.02.2021 00:54, Daniel González Cabanelas wrote:
> El mié, 24 feb 2021 a las 23:01, Florian Fainelli
> () escribió:
>>
>>
>>
>> On 2/24/2021 1:44 PM, Heiner Kallweit wrote:
>>> On 24.02.2021 16:44, Daniel González Cabanelas wrote:
>>>>
On 24.02.2021 16:44, Daniel González Cabanelas wrote:
> The current bcm63xx_enet driver doesn't asign the internal phy IRQ. As a
> result of this it works in polling mode.
>
> Fix it using the phy_device structure to assign the platform IRQ.
>
> Tested under a BCM6348 board. Kernel dmesg before t
gt; wrote:
>>>> On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
>>>>> Right, adding something like a genphy_{read,write}_mmd() doesn't make
>>>>> too much sense for now. What I meant is just exporting mmd_phy_indirect().
>>&g
Use macro pm_ptr(), this helps to avoid some ifdeffery.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
On 17.02.2021 13:42, Vladimir Oltean wrote:
> On Wed, Feb 17, 2021 at 08:38:30PM +0800, DENG Qingfang wrote:
>> On Wed, Feb 17, 2021 at 7:55 AM Linus Walleij
>> wrote:
>>> +
>>> + /* Pad out to at least 60 bytes */
>>> + if (unlikely(eth_skb_pad(skb)))
>>> + return NULL;
On 17.02.2021 12:01, Linus Walleij wrote:
> On Wed, Feb 17, 2021 at 8:08 AM Heiner Kallweit wrote:
>
>>> +#define RTL8366S_HDR_LEN 4
>>> +#define RTL8366S_ETHERTYPE 0x8899
>>
>> I found this protocol referenced as Realtek Remote Control Protocol (RRC
On 17.02.2021 07:21, DENG Qingfang wrote:
> Add support for Realtek RTL8366S switch tag
>
> Signed-off-by: DENG Qingfang
> ---
> include/net/dsa.h | 2 +
> net/dsa/Kconfig| 6 +++
> net/dsa/Makefile | 1 +
> net/dsa/tag_rtl8366s.c | 98 ++
On 16.02.2021 09:53, Du Cheng wrote:
> align * in block comments on each line
>
> changes v3:
> - add SUBSYSTEM in subject line
> - add explanation to past version of this patch
>
> changes v2:
> - move closing of comment to the same line
>
> changes v1:
> - align * in block comments
>
> Signed
On 15.02.2021 17:58, Bjarni Jonasson wrote:
> The 'coma mode' (configurable through sw or hw) provides an
> optional feature that may be used to control when the PHYs become active.
> The typical usage is to synchronize the link-up time across
> all PHY instances. This patch releases coma mode if n
On 15.02.2021 17:57, Bjarni Jonasson wrote:
> The current IB serdes calibration algorithm (performed by the onboard 8051)
> has proven to be unstable for the VSC8514 QSGMII phy.
> A new algorithm has been developed based on
> 'Frequency-offset Jittered-Injection' or 'FoJi' method which solves
> all
On 15.02.2021 17:57, Bjarni Jonasson wrote:
> At Power-On Reset, transients may cause the LCPLL to lock onto a
> clock that is momentarily unstable. This is normally seen in QSGMII
> setups where the higher speed 6G SerDes is being used.
> This patch adds an initial LCPLL Reset to the PHY (first in
-by: Armin Wolf
Signed-off-by: Heiner Kallweit
---
- This fix applies on net-next. For net I submitted a separate patch.
---
drivers/net/ethernet/realtek/r8169_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_ma
-by: Armin Wolf
Signed-off-by: Heiner Kallweit
---
- This fix will not apply on net-next. I submit a separate patch for net-next.
---
drivers/net/ethernet/realtek/r8169_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethern
's rename it to
PHY_MAC_INTERRUPT. This is in line with phy_mac_interrupt(), which is
called from the MAC interrupt handler to handle PHY events.
Signed-off-by: Heiner Kallweit
---
Documentation/networking/phy.rst| 2 +-
drivers/net/ethernet/broadcom/genet/bcmmii.c| 2 +-
drivers/
On 12.02.2021 19:00, Shyam Sundar S K wrote:
> Frequent link up/down events can happen when a Bel Fuse SFP part is
> connected to the amd-xgbe device. Try to avoid the frequent link
> issues by resetting the PHY as documented in Bel Fuse SFP datasheets.
>
> Signed-off-by: Sudheesh Mavila
> Signed
On 11.02.2021 22:19, Alex Elder wrote:
> When initializing the IPA core clock and interconnects, it's
> possible we'll get an EPROBE_DEFER error. This isn't really an
> error, it's just means we need to be re-probed later.
>
> Check the return code when initializing these, and if it's
> EPROBE_DE
.kernel.org/netdev/1610120754-14331-1-git-send-email-claudiu.bez...@microchip.com/
Fixes: 611d779af7ca ("net: phy: fix MDIO bus PM PHY resuming")
Reported-by: Claudiu Beznea
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy_device.c | 53
1 file c
Cleaning up tx descriptors first increases the chance that
rtl_rx() can allocate new skb's from the cache.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/re
1 - 100 of 1978 matches
Mail list logo
