linux-kernel - Re: [PATCH net-next v1 3/3] r8169: add support for chip RTL9151AS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1029930d-39d9-4003-a0ee-026b687af27d@gmail.com>
Date: Sat, 24 Jan 2026 22:24:28 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: 许俊伟 <javen_xu@...lsil.com.cn>,
 Paolo Abeni <pabeni@...hat.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "nic_swsd@...ltek.com" <nic_swsd@...ltek.com>,
 "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
 "davem@...emloft.net" <davem@...emloft.net>,
 "edumazet@...gle.com" <edumazet@...gle.com>,
 "kuba@...nel.org" <kuba@...nel.org>, "horms@...nel.org" <horms@...nel.org>
Subject: Re: [PATCH net-next v1 3/3] r8169: add support for chip RTL9151AS

On 1/22/2026 2:42 AM, 许俊伟 wrote:
>> On 1/12/26 11:20 PM, Heiner Kallweit wrote:
>>> On 1/12/2026 3:45 AM, javen wrote:
>>>> From: Javen Xu <javen_xu@...lsil.com.cn>
>>>>
>>>> This patch adds support for chip RTL9151AS. Since lacking of Hardware
>>>> version IDs, we use TX_CONFIG_V2 to recognize RTL9151AS and coming
>> chips.
>>>> rtl_chip_infos_extend is used to store IC information for RTL9151AS
>>>> and coming chips. The TxConfig value between RTL9151AS and RTL9151A
>>>> is
>>>>
>>>> different.
>>>>
>>>> Signed-off-by: Javen Xu <javen_xu@...lsil.com.cn>
>>>> ---
>>>>  drivers/net/ethernet/realtek/r8169.h      |  3 ++-
>>>>  drivers/net/ethernet/realtek/r8169_main.c | 28
>>>> +++++++++++++++++++++--
>>>>  2 files changed, 28 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/realtek/r8169.h
>>>> b/drivers/net/ethernet/realtek/r8169.h
>>>> index 2c1a0c21af8d..f66c279cbee6 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169.h
>>>> +++ b/drivers/net/ethernet/realtek/r8169.h
>>>> @@ -72,7 +72,8 @@ enum mac_version {
>>>>      RTL_GIGA_MAC_VER_70,
>>>>      RTL_GIGA_MAC_VER_80,
>>>>      RTL_GIGA_MAC_NONE,
>>>> -    RTL_GIGA_MAC_VER_LAST = RTL_GIGA_MAC_NONE - 1
>>>> +    RTL_GIGA_MAC_VER_LAST = RTL_GIGA_MAC_NONE - 1,
>>>> +    RTL_GIGA_MAC_VER_CHECK_EXTEND
>>>>  };
>>>>
>>>>  struct rtl8169_private;
>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
>>>> b/drivers/net/ethernet/realtek/r8169_main.c
>>>> index 9b89bbf67198..164ad6570059 100644
>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>>>> @@ -95,8 +95,8 @@
>>>>  #define JUMBO_16K   (SZ_16K - VLAN_ETH_HLEN - ETH_FCS_LEN)
>>>>
>>>>  static const struct rtl_chip_info {
>>>> -    u16 mask;
>>>> -    u16 val;
>>>> +    u32 mask;
>>>> +    u32 val;
>>>>      enum mac_version mac_version;
>>>>      const char *name;
>>>>      const char *fw_name;
>>>> @@ -205,10 +205,20 @@ static const struct rtl_chip_info {
>>>>      { 0xfc8, 0x040, RTL_GIGA_MAC_VER_03, "RTL8110s" },
>>>>      { 0xfc8, 0x008, RTL_GIGA_MAC_VER_02, "RTL8169s" },
>>>>
>>>> +    /* extend chip version*/
>>>> +    { 0x7cf, 0x7c8, RTL_GIGA_MAC_VER_CHECK_EXTEND },
>>>> +
>>>>      /* Catch-all */
>>>>      { 0x000, 0x000, RTL_GIGA_MAC_NONE }  };
>>>>
>>>> +static const struct rtl_chip_info rtl_chip_infos_extend[] = {
>>>> +    { 0x7fffffff, 0x00000000, RTL_GIGA_MAC_VER_64, "RTL9151AS",
>>>> +FIRMWARE_9151A_1},
>>>> +
>>>
>>> Seems all bits except bit 31 are used for chip detection. However
>>> register is named TX_CONFIG_V2, even though only bit 31 is left for actual tx
>> configuration.
>>> Is the register name misleading, or is the mask incorrect?
>>
>> @Heiner (double checking to avoid more confusion on my side): are you fine
>> with the register name? It's unclear to me if you are fine with just the 2
>> merged patches or even with this one.
>>
>> Thanks,
>>
>> Paolo
> 
> Hi, Paolo & Heiner
> 
> It appears that this patch has not been accepted yet. Should I resubmit it as a 
> separate  patch?
> 
I will slightly extend your patch to display the new extended XID properly
in places where the XID is printed, and submit it on your behalf.

> Thank,
> Javen Xu

Heiner