We can remove the intermediary string conversion and use drv->fw_index
in the final snprintf directly.
Signed-off-by: Heiner Kallweit
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/in
On 11.02.2021 13:17, Pavel Machek wrote:
> On Thu 2021-01-14 12:05:21, Heiner Kallweit wrote:
>> On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
>>>
>>>
>>> On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
>>>>
>>>> A
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 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 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
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 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
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 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
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 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 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 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:
> 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 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
; ---
Thanks!
Reviewed-by: Heiner Kallweit
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
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 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
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 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 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
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
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
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_
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
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
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_
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
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
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):
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
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/
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
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
ions(+), 6 deletions(-)
>
for net-next
Reviewed-by: Heiner Kallweit
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
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/
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 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
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
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 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
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 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 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 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 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_
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
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 -
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 +
On 22.01.2021 15:35, Laurent Badel wrote:
> Some PHYs such as SMSC LAN87xx clear the interrupt mask register on
> software reset. Since mdio_bus_phy_restore() calls phy_init_hw() which
> does a software reset of the PHY, these PHYs will lose their interrupt
> mask configuration on resuming from h
,
and if the tg3 module loading is killed then there's also not much
benefit in retrying the VPD read.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/broadcom/tg3.c | 30 +++--
drivers/net/ethernet/broadcom/tg3.h | 1 +
2 files changed, 12 insertions(+),
= Large Resource Data Tag, see PCI 2.2 spec, VPD chapter
v2:
- don't set VPD_BASE / VPD_BASE_OLD separately
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/ch
On 19.01.2021 23:02, Jakub Kicinski wrote:
> On Sat, 16 Jan 2021 14:45:25 +0100 Heiner Kallweit wrote:
>> The comment is quite weird, there is no such thing as a vendor-specific
>> VPD id. 0x82 is the value of PCI_VPD_LRDT_ID_STRING. So what we are
>> doing here is simply chec
On 19.01.2021 13:40, Juerg Haefliger wrote:
> On Thu, 8 Oct 2020 20:50:28 +0200
> Eric Dumazet wrote:
>
>> On Thu, Oct 8, 2020 at 8:42 PM Heiner Kallweit wrote:
>>>
>>> On 08.10.2020 19:15, Eric Dumazet wrote:
>>>> On Thu, Oct 8, 2020 at 6:37 PM H
m each of the two files, which
>>>>> then always duplicates the contents (even when both are built-in), but
>>>>> at least builds the file the correct way.
>>>>
>>>> That's the same as V1, isn't it ?
>>>
>>> Ah, I had not
= Large Resource Data Tag, see PCI 2.2 spec, VPD chapter
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
b/drivers/net/ethernet/chelsio/cxgb4
On 15.01.2021 18:19, Badel, Laurent wrote:
> Description:
> External PHY reset from the FEC driver was introduced in commit [1] to
> mitigate an issue with iMX SoCs and LAN87xx PHYs. The issue occurs
> because the FEC driver turns off the reference clock for power saving
> reasons [2], which d
On 15.01.2021 16:59, Andrew Lunn wrote:
> On Fri, Jan 15, 2021 at 04:05:57PM +0100, Marek Vasut wrote:
>> On 1/15/21 4:00 PM, Andrew Lunn wrote:
>>> On Fri, Jan 15, 2021 at 02:42:39PM +0100, Marek Vasut wrote:
When either the SPI or PAR variant is compiled as module AND the other
variant
On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
>
>
> On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
>>
>> As I've said, if phylib/PHY driver is not restoring the state of the
>> PHY on resume from suspend-to-ram, then that's an issue with phylib
>> and/or the phy driver.
>
On 13.01.2021 23:01, Russell King - ARM Linux admin wrote:
> On Wed, Jan 13, 2021 at 10:34:53PM +0100, Heiner Kallweit wrote:
>> On 13.01.2021 13:36, claudiu.bez...@microchip.com wrote:
>>> On 13.01.2021 13:09, Heiner Kallweit wrote:
>>>> On 13.01.2021 10:29, clau
On 06.01.2021 20:34, Heiner Kallweit wrote:
> On 06.01.2021 20:22, Bjorn Helgaas wrote:
>> On Wed, Jan 06, 2021 at 06:50:22PM +0100, Heiner Kallweit wrote:
>>> If we know that a device has broken parity checking, then disable it.
>>> This avoids quirks like in r8169 wher
On 13.01.2021 13:36, claudiu.bez...@microchip.com wrote:
>
>
> On 13.01.2021 13:09, Heiner Kallweit wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 13.01.2021 10:29, claudiu.bez...@microchip.com
On 13.01.2021 10:29, claudiu.bez...@microchip.com wrote:
> Hi Heiner,
>
> On 08.01.2021 18:31, Heiner Kallweit wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 08.01.2021 16:45, Claudiu Beznea wro
On 12.01.2021 15:02, Andrew Lunn wrote:
>> I'd think that mdio-i2c.c is for generic code. When adding a
>> vendor-specific protocol, wouldn't it make sense to use a dedicated
>> source file for it?
>
> Hi Heiner
>
> There is no standardised way to access MDIO over i2c. So the existing
> code is v
On 11.01.2021 06:00, Marek Behún wrote:
> Some multigig SFPs from RollBall and Hilink do not expose functional
> MDIO access to the internal PHY of the SFP via I2C address 0x56
> (although there seems to be read-only clause 22 access on this address).
>
> Instead these SFPs PHY can be accessed via
Instead of doing the full DASH check each time r8168_check_dash() is
called, let's do it once in probe and store DASH capabilities in a
new rtl8169_private member.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 53 ++-
1 file change
Extend the mask to include the checksum failure bits. This allows to
simplify the condition in rtl8169_rx_csum().
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek
At least from chip version 25 the vendor driver sets these rx flags
for all chip versions if WOL is enabled. Therefore I wouldn't consider
it a quirk, so let's rename the function.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 20 --
Series includes further smaller improvements.
Heiner Kallweit (3):
r8169: align rtl_wol_suspend_quirk with vendor driver and rename it
r8169: improve rtl8169_rx_csum
r8169: improve DASH support
drivers/net/ethernet/realtek/r8169_main.c | 81 +--
1 file changed, 31
On 11.01.2021 20:45, Paul Thomas wrote:
> Hello, recently I was doing a lot of tracing/profiling to understand
> an issue we were having. Anyway, during this I ran across
> __napi_schedule_irqoff() where the comment in dev.c says "Variant of
> __napi_schedule() assuming hard irqs are masked".
>
>
On 11.01.2021 15:10, Marek Vasut wrote:
> On 1/11/21 2:50 PM, Heiner Kallweit wrote:
>> On 11.01.2021 14:38, Marek Vasut wrote:
>>> On 1/11/21 2:26 PM, Heiner Kallweit wrote:
>>> [...]
>>>
>>>> LGTM. When having a brief look at the driver I stu
On 11.01.2021 14:38, Marek Vasut wrote:
> On 1/11/21 2:26 PM, Heiner Kallweit wrote:
> [...]
>
>> LGTM. When having a brief look at the driver I stumbled across two things:
>>
>> 1. Do MAC/PHY support any pause mode? Then a call to
>> phy_support_(a)sym_pau
On 11.01.2021 13:53, Marek Vasut wrote:
> Unless the internal PHY is connected and started, the phylib will not
> poll the PHY for state and produce state updates. Connect the PHY and
> start/stop it.
>
> Signed-off-by: Marek Vasut
> Cc: Andrew Lunn
> Cc: Heiner Kallwei
Clean up the remainings of rtl_pll_power_down/up and rename
rtl_pll_power_down() to rtl_prepare_power_down().
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/realtek
-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 51 ++-
1 file changed, 22 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
index 9c87fb9f1..64fdc168f 100644
--- a/drivers/net
There's no known reason why PLL powerdown on D3 shouldn't be enabled
on chip versions 34, 35, 36, and 42. At least the vendor driver doesn't
exclude any of these chip versions.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 11 ---
1
This series includes improvements to handling of PLL power-down.
Heiner Kallweit (3):
r8169: enable PLL power-down for chip versions 34, 35, 36, 42
r8169: improve handling D3 PLL power-down
r8169: clean up rtl_pll_power_down/up functions
drivers/net/ethernet/realtek/r8169_main.c | 65
lains we can remove support for it in the near future.
v2:
- extend unknown chip version error message
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main
On 10.01.2021 03:17, Jakub Kicinski wrote:
> On Fri, 8 Jan 2021 13:24:16 +0100 Heiner Kallweit wrote:
>> RTL8168dp is ancient anyway, and I haven't seen any trace of its early
>> version 27 yet. This chip versions needs quite some special handling,
>> therefore
Instead of open-coding unaligned access let's use the predefined
unaligned access helpers.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 35 +--
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/re
So far we don't increase the max read request size if we switch to
jumbo mode before bringing up the interface for the first time.
Let's change this.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 9 +
1 file changed, 5 insertions(+), 4 deletion
Align behavior with r8168 vendor driver and don't reduce max read
request size for RTL8168e in jumbo mode.
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/re
Small improvements to jumbo configuration.
Heiner Kallweit (2):
r8169: align RTL8168e jumbo pcie read request size with vendor driver
r8169: tweak max read request size for newer chips also in jumbo mtu
mode
drivers/net/ethernet/realtek/r8169_main.c | 15 +++
1 file changed
On 08.01.2021 16:45, Claudiu Beznea wrote:
> KSZ9131 is used in setups with SAMA7G5. SAMA7G5 supports a special
> power saving mode (backup mode) that cuts the power for almost all
> parts of the SoC. The rail powering the ethernet PHY is also cut off.
> When resuming, in case the PHY has been conf
lains we can remove support for it in the near future.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_main.c
Use WARN_ONCE here to get a call trace in case of a problem.
This facilitates finding the offending code part.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet
If WOL isn't enabled, then there's no need to enable wakeup from D3
on system shutdown.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/d
Use WARN here to avoid stopping the system. In addition print the addr
and mask values that triggered the warning.
v2:
- return on WARN to avoid an invalid register write
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 4 +++-
1 file changed, 3 insertions(+), 1
This series includes a number of smaller improvements.
v2:
- return on WARN in patch 1
Heiner Kallweit (3):
r8169: replace BUG_ON with WARN in _rtl_eri_write
r8169: improve rtl_ocp_reg_failure
r8169: don't wakeup-enable device on shutdown if WOL is disabled
drivers/net/ethernet/re
On 06.01.2021 23:39, Andrew Lunn wrote:
> On Wed, Jan 06, 2021 at 02:03:40PM +0100, Heiner Kallweit wrote:
>> Switch to lockdep_assert_held(_once), similar to what is being done
>> in other subsystems. One advantage is that there's zero runtime
>> overhead if lockdep supp
On 06.01.2021 23:18, Alexander Duyck wrote:
> On Wed, Jan 6, 2021 at 5:32 AM Heiner Kallweit wrote:
>>
>> Use WARN here to avoid stopping the system. In addition print the addr
>> and mask values that triggered the warning.
>>
>> Signed-off-by: Heiner Kallweit
On 06.01.2021 20:22, Bjorn Helgaas wrote:
> On Wed, Jan 06, 2021 at 06:50:22PM +0100, Heiner Kallweit wrote:
>> If we know that a device has broken parity checking, then disable it.
>> This avoids quirks like in r8169 where on the first parity error
>> interrupt parity checkin
On 06.01.2021 14:26, Heiner Kallweit wrote:
> This series includes a number of smaller improvements.
>
> Heiner Kallweit (3):
> r8169: replace BUG_ON with WARN in _rtl_eri_write
> r8169: improve rtl_ocp_reg_failure
> r8169: don't wakeup-enable device on shut
Use new PCI core function pci_quirk_broken_parity() to disable
parity checking.
Signed-off-by: Heiner Kallweit
---
v2:
- remove additional changes from this patch
v3:
- improve commit message
---
arch/arm/mach-iop32x/n2100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Meanwhile the PCI core disables parity checking for a device that has
broken_parity_status set. Therefore we don't need the quirk any longer
to disable parity checking on the first parity error interrupt.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c
Thecus N2100.
Signed-off-by: Heiner Kallweit
Reviewed-by: Leon Romanovsky
---
drivers/pci/quirks.c | 17 +++--
include/linux/pci.h | 2 ++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 653660e3b..ab54e26b8 100644
101 - 200 of 1978 matches
Mail list logo
