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 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
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 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 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 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 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 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
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
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.
---
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
Cc: sta...@vger.kernel.org
---
This patch doesn't apply cleanly on some kernel versions, but the needed
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
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 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
rtl_wol_enable_rx() is called via the following call chain if WoL
is enabled:
rtl8169_down()
-> rtl_prepare_power_down()
-> rtl_wol_enable_rx()
Therefore we don't have to call this function here.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 4 +
version of the workaround to meet mainline
code style.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=209839
Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
Tested-by: xplo
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 64 -
version of the workaround to meet mainline
code style.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=209839
Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
Tested-by: xplo
Signed-off-by: Heiner Kallweit
---
v2:
- rebased to net
---
drivers/net/ethernet/realtek/r8169_m
On 26.01.2021 23:10, Tony Nguyen wrote:
> From: Corinna Vinschen
>
> Link speed advertising in igc has two problems:
>
> - When setting the advertisement via ethtool, the link speed is converted
> to the legacy 32 bit representation for the intel PHY code.
> This inadvertently drops ETHTOOL_
On 26.01.2021 10:02, Heiner Kallweit wrote:
> It was reported that on RTL8125 network breaks under heavy UDP load,
> e.g. torrent traffic ([0], from comment 27). Realtek confirmed a hw bug
> and provided me with a test version of the r8125 driver including a
> workaround. Tests confir
On 27.01.2021 19:07, Willem de Bruijn wrote:
> On Tue, Jan 26, 2021 at 2:40 PM Heiner Kallweit wrote:
>>
>> It was reported that on RTL8125 network breaks under heavy UDP load,
>> e.g. torrent traffic ([0], from comment 27). Realtek confirmed a hw bug
>> and provided me
On 27.01.2021 20:54, Willem de Bruijn wrote:
> On Wed, Jan 27, 2021 at 2:40 PM Heiner Kallweit wrote:
>>
>> On 27.01.2021 19:07, Willem de Bruijn wrote:
>>> On Tue, Jan 26, 2021 at 2:40 PM Heiner Kallweit
>>> wrote:
>>>>
>>>> It was rep
On 27.01.2021 21:35, Willem de Bruijn wrote:
> On Wed, Jan 27, 2021 at 3:32 PM Heiner Kallweit wrote:
>>
>> On 27.01.2021 20:54, Willem de Bruijn wrote:
>>> On Wed, Jan 27, 2021 at 2:40 PM Heiner Kallweit
>>> wrote:
>>>>
>>>> On 27.01
On 27.01.2021 23:48, Willem de Bruijn wrote:
> On Wed, Jan 27, 2021 at 4:34 PM Heiner Kallweit wrote:
>>
>> On 27.01.2021 21:35, Willem de Bruijn wrote:
>>> On Wed, Jan 27, 2021 at 3:32 PM Heiner Kallweit
>>> wrote:
>>>>
>>>> On 27.01
Tested-by: xplo
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 70 +--
1 file changed, 64 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index a569abe7f..457fa1
On 28.01.2021 19:36, Willem de Bruijn wrote:
> On Thu, Jan 28, 2021 at 2:44 AM Heiner Kallweit wrote:
>>
>> It was reported that on RTL8125 network breaks under heavy UDP load,
>> e.g. torrent traffic ([0], from comment 27). Realtek confirmed a hw bug
>> and provided me
On 28.01.2021 21:17, Heiner Kallweit wrote:
> On 28.01.2021 19:36, Willem de Bruijn wrote:
>> On Thu, Jan 28, 2021 at 2:44 AM Heiner Kallweit wrote:
>>>
>>> It was reported that on RTL8125 network breaks under heavy UDP load,
>>> e.g. torrent traffic ([0], from
with offsetof(struct udphdr, len)
Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
Tested-by: xplo
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 71 +--
1 file changed, 65 insertions(+), 6 deletions(-)
diff --git a/drivers/ne
On 01.02.2021 17:47, Kai-Heng Feng wrote:
> According to the vendor driver, the new chip with XID 0x54b is
> essentially the same as the one with XID 0x54a, but it doesn't need the
> firmware.
>
> So add support accordingly.
>
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/net/ethernet/realtek/
b to eventually call
phy_suspend(). Because the net_device is detached from the PHY already,
the PHY driver can't recognize that WoL is configured and powers down the
PHY.
Fixes: f1e911d5d0df ("r8169: add basic phylib support")
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/re
ions(+), 6 deletions(-)
>
for net-next
Reviewed-by: Heiner Kallweit
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 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 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
*cmd |= 0x7f0 << 18;
> + *cmd |= 0xf70 << 18;
> }
>
> DECLARE_RTL_COND(rtl_eriar_cond)
>
Acked-by: Heiner Kallweit
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
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 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 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 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.
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 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
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 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
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
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
Working on PCI VPD core code I came across the Chelsio drivers.
Let's improve the way how they handle PCI VPD.
This series touches only device-specific quirks in the core code,
therefore I think it should go via the netdev tree.
Heiner Kallweit (4):
PCI/VPD: Remove Chelsio T3 quirk
Presumably this is a leftover from T3 driver heritage. cxgb4 uses the
PCI core VPD access code that handles detection of VPD capabilities.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 -
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 --
2 files
cxgb3 driver doesn't use the PCI core code for VPD access, it has its own
implementation. Therefore we don't need a quirk for it in the core code.
Signed-off-by: Heiner Kallweit
---
drivers/pci/vpd.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/d
Now that the PCI VPD for Chelsio devices from T4 on has been changed and
VPD len is set to PCI_VPD_MAX_SIZE (32K), we don't have to change the
VPD len any longer.
Signed-off-by: Heiner Kallweit
---
.../net/ethernet/chelsio/cxgb4/cudbg_entity.h | 1 -
.../net/ethernet/chelsio/cxgb4/cudbg_
the PCI spec, let's set VPD len according to all data that can be
accessed via PCI VPD access, no matter of its structure.
Signed-off-by: Heiner Kallweit
---
drivers/pci/vpd.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/vpd.c b/drivers/pci/
On 04.02.2021 03:30, Jakub Kicinski wrote:
> On Tue, 2 Feb 2021 21:35:55 +0100 Heiner Kallweit wrote:
>> cxgb3 driver doesn't use the PCI core code for VPD access, it has its own
>> implementation. Therefore we don't need a quirk for it in the core code.
>>
&g
ng
an interface for manipulating the VPD size.
This series touches only device-specific quirks in the core code,
therefore I think it should go via the netdev tree.
v2:
- remove patch 1 from the series
Resending the series because it seems netdev patchwork swallowed it.
Heiner Kallweit (3):
the PCI spec, let's set VPD len according to all data that can be
accessed via PCI VPD access, no matter of its structure.
Signed-off-by: Heiner Kallweit
---
drivers/pci/vpd.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
Supposedly this is a leftover from T3 driver heritage. cxgb4 uses the
PCI core VPD access code that handles detection of VPD capabilities.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 -
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 --
2 files
Now that the PCI VPD for Chelsio devices from T4 has been changed and VPD
len is set to PCI_VPD_MAX_SIZE (32K), we don't have to change the VPD len
any longer.
Signed-off-by: Heiner Kallweit
---
.../net/ethernet/chelsio/cxgb4/cudbg_entity.h | 1 -
.../net/ethernet/chelsio/cxgb4/cudbg_
There's no benefit in trying to disable interrupts if NAPI is
scheduled already. This allows us to save a PCI write in this case.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/driver
ng
an interface for manipulating the VPD size.
This series touches only device-specific quirks in the core code,
therefore I think it should go via the netdev tree.
v2:
- remove patch 1 from the series
Heiner Kallweit (3):
cxgb4: remove unused vpd_cap_addr
PCI/VPD: Change Chelsio T4 qui
Now that the PCI VPD for Chelsio devices from T4 has been changed and VPD
len is set to PCI_VPD_MAX_SIZE (32K), we don't have to change the VPD len
any longer.
Signed-off-by: Heiner Kallweit
---
.../net/ethernet/chelsio/cxgb4/cudbg_entity.h | 1 -
.../net/ethernet/chelsio/cxgb4/cudbg_
the PCI spec, let's set VPD len according to all data that can be
accessed via PCI VPD access, no matter of its structure.
Signed-off-by: Heiner Kallweit
---
drivers/pci/vpd.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
Supposedly this is a leftover from T3 driver heritage. cxgb4 uses the
PCI core VPD access code that handles detection of VPD capabilities.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 -
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 --
2 files
On 05.02.2021 13:42, Raju Rangoju wrote:
> On Tuesday, February 02/02/21, 2021 at 21:35:55 +0100, Heiner Kallweit wrote:
>> cxgb3 driver doesn't use the PCI core code for VPD access, it has its own
>> implementation. Therefore we don't need a quirk for it in the core
On 05.02.2021 22:46, Bjorn Helgaas wrote:
> [+cc Casey, Rahul]
>
> On Fri, Feb 05, 2021 at 08:29:45PM +0100, Heiner Kallweit wrote:
>> cxgb4 uses the full VPD address space for accessing its EEPROM (with some
>> mapping, see t4_eeprom_ptov()). In cudbg_collect_vpd_data() it s
On 08.02.2021 15:03, Serge Semin wrote:
> It has been noticed that RTL8211E PHY stops detecting and reporting events
> when EEE is successfully advertised and RXC stopping in LPI is enabled.
> The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable"
> register) is set. At the same time L
On 08.02.2021 20:47, Rahul Lakkireddy wrote:
> On Friday, February 02/05/21, 2021 at 23:31:24 +0100, Heiner Kallweit wrote:
>> On 05.02.2021 22:46, Bjorn Helgaas wrote:
>>> [+cc Casey, Rahul]
>>>
>>> On Fri, Feb 05, 2021 at 08:29:45PM +0100, Heiner Kallweit
It is likely that this is a leftover from T3 driver heritage. cxgb4 uses
the PCI core VPD access code that handles detection of VPD capabilities.
Reviewed-by: Alexander Duyck
Signed-off-by: Heiner Kallweit
---
- resend after dropping patches 2 and 3 from the series
---
drivers/net/ethernet
On 09.02.2021 02:30, Andrew Lunn wrote:
> On Tue, Feb 09, 2021 at 12:17:06AM +0100, Michael Walle wrote:
>> It is nowhere used in the kernel. It also seems to be lacking the
>> proper fiber advertise flags. Remove it.
>
> Maybe also remove the #define for PHY_BCM_FLAGS_MODE_1000BX? Maybe
> there i
; ---
Thanks!
Reviewed-by: Heiner Kallweit
On 09.02.2021 11:15, Serge Semin wrote:
> On Mon, Feb 08, 2021 at 09:14:02PM +0100, Heiner Kallweit wrote:
>> On 08.02.2021 15:03, Serge Semin wrote:
>>> It has been noticed that RTL8211E PHY stops detecting and reporting events
>>> when EEE is successfully advertised
On 09.02.2021 17:40, Michael Walle wrote:
> Unfortunately, the IP101A and IP101G share the same PHY identifier.
> While most of the functions are somewhat backwards compatible, there is
> for example the APS_EN bit on the IP101A but on the IP101G this bit
> reserved. Also, the IP101G has many more
On 10.02.2021 01:32, Stephen Hemminger wrote:
> On Tue, 9 Feb 2021 18:35:54 +0100
> Anton Hvornum wrote:
>
>> Hi.
>>
>> I am a bit new to ethtool, kernel drivers and all the surrounding aspects.
>> I also recognize that my use case is of low priority and a bit niche,
>> but any response would be
On 09.02.2021 17:40, Michael Walle wrote:
> Registers >= 16 are paged. Be sure to set the page. It seems this was
> working for now, because the default is correct for the registers used
> in the driver at the moment. But this will also assume, nobody will
> change the page select register before l
On 10.02.2021 09:25, Michael Walle wrote:
> Hi,
>
> Am 2021-02-10 08:03, schrieb Heiner Kallweit:
>> On 09.02.2021 17:40, Michael Walle wrote:
>>> Registers >= 16 are paged. Be sure to set the page. It seems this was
>>> working for now, because the defau
On 10.02.2021 13:17, Michael Walle wrote:
> Am 2021-02-10 12:48, schrieb Russell King - ARM Linux admin:
>> On Wed, Feb 10, 2021 at 12:14:35PM +0100, Michael Walle wrote:
>>> Am 2021-02-10 11:49, schrieb Russell King - ARM Linux admin:
>>> The PHY doesn't support fiber and register 0..15 are always
On 10.02.2021 13:55, Robert Marko wrote:
> This adds driver for the Qualcomm QCA8072 and QCA8075 PHY-s.
>
> They are 2 or 5 port IEEE 802.3 clause 22 compliant
> 10BASE-Te, 100BASE-TX and 1000BASE-T PHY-s.
>
> They feature 2 SerDes, one for PSGMII or QSGMII connection with MAC,
> while second one
e function to rtl8169_runtime_resume().
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index
On 10.02.2021 17:47, Michael Walle wrote:
> Unfortunately, the IP101A and IP101G share the same PHY identifier.
> While most of the functions are somewhat backwards compatible, there is
> for example the APS_EN bit on the IP101A but on the IP101G this bit
> reserved. Also, the IP101G has many more
ater.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index bc588cde8..de439db75 100644
--- a/drivers/
On 10.02.2021 23:13, Saravana Kannan wrote:
> Hi,
>
> This email was triggered by this other email[1].
>
> Why is phy_attach_direct() directly calling device_bind_driver()
> instead of using bus_probe_device()? I'm asking because this is
> causing device links status to not get updated correctly
On 11.02.2021 00:29, Saravana Kannan wrote:
> On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn wrote:
>>
>> On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
>>> Hi,
>>>
>>> This email was triggered by this other email[1].
>>>
>>> Why is phy_attach_direct() directly calling device_bind_d
On 11.02.2021 09:57, Saravana Kannan wrote:
> On Wed, Feb 10, 2021 at 11:31 PM Heiner Kallweit wrote:
>>
>> On 11.02.2021 00:29, Saravana Kannan wrote:
>>> On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn wrote:
>>>>
>>>> On Wed, Feb 10, 2021 at 0
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
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 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 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 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 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
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 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
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
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
: 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
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
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 +
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
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 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
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.
>>>
>>>
401 - 500 of 1978 matches
Mail list logo
