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: <bffa03f0eb9f405388b5436882776111@realsil.com.cn>
Date: Thu, 22 Jan 2026 01:42:26 +0000
From: 许俊伟 <javen_xu@...lsil.com.cn>
To: Paolo Abeni <pabeni@...hat.com>, Heiner Kallweit <hkallweit1@...il.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/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?

Thank,
Javen Xu