You can check OBS hardware repo and look for already existing packages.
If there is not there, try to create your own one (at first in your home project, and later submit to OBS hardware project).
It shouldn't be too difficult.

Post:
/sbin/lspci -nnk | grep -i net

So the ID and maybe driver is shown.

(In reply to Takashi Iwai from comment #1)
> You can check OBS hardware repo and look for already existing packages.
> If there is not there, try to create your own one (at first in your home
> project, and later submit to OBS hardware project).
> It shouldn't be too difficult.

Thanks for the pointer Takashi.

I just checked that repo and I do not see any realtek drivers for the 8125 ( prior version ) or the 8126 ( version I have ).

Compiling the module and then signing it works ( which is what I have done ), but
I have not idea how to use OBS or to create a project there as you mentioned.

It is probably above my pay grade :-) at least right now which is why I provided the link to the driver and have confirmed that it does in fact work so hoping that someone can get it included into TW for me.

(In reply to Stephan Hemeier from comment #2)
> Post:
> /sbin/lspci -nnk | grep -i net
> 
> So the ID and maybe driver is shown.

Hi Stephan,

TW does not have a driver for the Realtek 8126 network adapter.

The link I mentioned above is what I found on their website which looks like it was originally for the 8125.

Here is the information you requested, however, keep in mind that it is after I downloaded and compiled the driver from that link and then signed it since I use secure boot.

Here's he lspci --nk | grep -i net results

04:00.0 Network controller [0280]: Intel Corporation Device [8086:272b] (rev 1a)
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. Device [10ec:8126] (rev 01)

Holler if you need anything else, THANK YOU!

My /sbin/lspci -nnk | grep -i net is not the same as your lspci --nk | grep -i net

So next time a little more carefully.

I have installed r8125 from my hardware Repo and get:
modprobeid 10ec:8126
Kernelmodulname r8125
filename:       /lib/modules/5.14.21-150500.55.36-default/weak-updates/updates/r8125.ko.xz
version:        9.012.03-NAPI
license:        GPL
description:    Realtek r8125 Ethernet controller driver
author:         Realtek and the Linux r8125 crew <netdev@vger.kernel.org>
suserelease:    SLE15-SP5
srcversion:     353F27D464BEFD974319666
alias:          pci:v000010ECd00005000sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008126sv*sd*bc*sc*i*
alias:          pci:v000010ECd00003000sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008162sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008125sv*sd*bc*sc*i*
So the driver is r8125, you can get it:

https://download.opensuse.org/repositories/home:/Sauerland:/hardware/openSUSE_Tumbleweed/

You have to  install the kmp, ueficert and blacklist rpm.

(In reply to Stephan Hemeier from comment #5)
> My /sbin/lspci -nnk | grep -i net is not the same as your lspci --nk | grep
> -i net
> 
> So next time a little more carefully.

My apologies, I am sorry for the mistake and for the delay in responding, I had a friend pass away a few days ago and then last night my aunt passed away :-( so my mind is not focusing very well at the moment.

Here is the output you request BUT, keep in mind that it is AFTER I compiled the driver from the realtek.com link I provided and AFTER, I signed the module so that the kernel would load it ( and imported the key with mokutil )

/sbin/lspci -nnk | grep -i net 

04:00.0 Network controller [0280]: Intel Corporation Device [8086:272b] (rev 1a)
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. Device [10ec:8126] (rev 01)

> 
> I have installed r8125 from my hardware Repo and get:
> modprobeid 10ec:8126
> Kernelmodulname r8125
> filename:      
> /lib/modules/5.14.21-150500.55.36-default/weak-updates/updates/r8125.ko.xz
> version:        9.012.03-NAPI
> license:        GPL
> description:    Realtek r8125 Ethernet controller driver
> author:         Realtek and the Linux r8125 crew <netdev@vger.kernel.org>
> suserelease:    SLE15-SP5
> srcversion:     353F27D464BEFD974319666
> alias:          pci:v000010ECd00005000sv*sd*bc*sc*i*
> alias:          pci:v000010ECd00008126sv*sd*bc*sc*i*
> alias:          pci:v000010ECd00003000sv*sd*bc*sc*i*
> alias:          pci:v000010ECd00008162sv*sd*bc*sc*i*
> alias:          pci:v000010ECd00008125sv*sd*bc*sc*i*
> So the driver is r8125, you can get it:
> 
> https://download.opensuse.org/repositories/home:/Sauerland:/hardware/
> openSUSE_Tumbleweed/
> 
> You have to  install the kmp, ueficert and blacklist rpm.

I may be misunderstanding but it seems that you compiled the driver and made it available, but I already did that and have it working.

My request was for the driver to make it to the TW repos so that it is automatically updated when I do zypper dup and so that I don't have to worry about compiling and signing when new kernel versions come out.

Does that make sense ? 

Am I missing something from your reply ?

Thanks for your patience during these challenging family times.

Joe

>My request was for the driver to make it to the TW repos so that it is >automatically updated when I do zypper dup and so that I don't have to worry >about compiling and signing when new kernel versions come out.

>Does that make sense ? 

Maybe into the hardware Repo, but not directly to Tumbleweed........

(In reply to Stephan Hemeier from comment #7)
> >My request was for the driver to make it to the TW repos so that it is >automatically updated when I do zypper dup and so that I don't have to worry >about compiling and signing when new kernel versions come out.
> 
> >Does that make sense ? 
> 
> Maybe into the hardware Repo, but not directly to Tumbleweed........

Sorry I don't understand.   

Are you saying it will be in the HW repo but it will NEVER appear in TW during a new install ?

When I installed I had to do an offline install since I didn't have a network connection because there was no 8125/8126 driver.

After the install was done I had to setup wifi so that I could install gcc and kernel-devel so that I could compile the drivers.

I must be misunderstanding you because I would be shocked if the latest driver for the new 5G wired network card would not eventually be included.

Please help me understand better.

The r8169 module from Kernel has r8125 support:
alias:          pci:v000010ECd00003000sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008125sv*sd*bc*sc*i*
alias:          pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias:          pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias:          pci:v000016ECd00000116sv*sd*bc*sc*i*
alias:          pci:v00001259d0000C107sv*sd*bc*sc*i*
alias:          pci:v00001186d00004302sv*sd*bc*sc*i*
alias:          pci:v00001186d00004300sv*sd*bc*sc*i*
alias:          pci:v00001186d00004300sv00001186sd00004B10bc*sc*i*
alias:          pci:v000010ECd00008169sv*sd*bc*sc*i*
alias:          pci:v000010FFd00008168sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008168sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008167sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008162sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008161sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008136sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008129sv*sd*bc*sc*i*
alias:          pci:v000010ECd00002600sv*sd*bc*sc*i*
alias:          pci:v000010ECd00002502sv*sd*bc*sc*i*

But not with your ID 8126......

So I do not know, if your ID will be backported to r8169 module , but I do not think, that any r8125.rpm will be shipped with original Tumbleweed or Leap.

That can only be done by serving an r8125 in the hardware Repo.
Also I don't know if we have to blacklist the r8169 from kernel, because that supports more hardware.

But Takashi Iwai can say more to these problems.

(In reply to Stephan Hemeier from comment #9)

> But not with your ID 8126......
> 
> So I do not know, if your ID will be backported to r8169 module , but I do
> not think, that any r8125.rpm will be shipped with original Tumbleweed or
> Leap.
> 
> That can only be done by serving an r8125 in the hardware Repo.
> Also I don't know if we have to blacklist the r8169 from kernel, because
> that supports more hardware.
> 
> But Takashi Iwai can say more to these problems.

This is REALLY new HW and it is the first motherboard I found that had the 8126.
I purposely avoid the 2.5G wired networking because I found so many issues googling around with motherboards from all different vendors.

Most motherboards seem to still have the 8125 even realtek.com just points you to the 8125 driver.

So if I understand you correctly, the 8169 module would probably work since it supports the 8125 ( which is the driver I'm using ) it is just not currently recognizing that ID and someone would need to backport that id to the r8169 module.

You can try to add the new entry for 8126 via sysfs and let r8169 driver binding with it without compilation.
  https://docs.kernel.org/PCI/pci.html?highlight=new_id

e.g. try to write like
  echo -n "10ec 8126 ffff ffff 0 0 0" > /sys/bus/pci/drivers/r8169/new_id
  echo -n "0000:05:00.0" > /sys/bus/pci/drivers/r8169/bind

(In reply to Takashi Iwai from comment #11)
> You can try to add the new entry for 8126 via sysfs and let r8169 driver
> binding with it without compilation.
>   https://docs.kernel.org/PCI/pci.html?highlight=new_id
> 
> e.g. try to write like
>   echo -n "10ec 8126 ffff ffff 0 0 0" > /sys/bus/pci/drivers/r8169/new_id
>   echo -n "0000:05:00.0" > /sys/bus/pci/drivers/r8169/bind

Ok, I tried what you suggested above.

First I load the module and verified it loaded:

lsmod | grep r8169

modprobe r8169

lsmod | grep r8169

r8169                 114688  0
mdio_devres            12288  1 r8169
libphy                245760  3 r8169,mdio_devres,realtek

Your 1st echo does not report any issues

echo -n "10ec 8126 ffff ffff 0 0 0" > /sys/bus/pci/drivers/r8169/new_id

Your 2nd echo fails

echo -n "0000:05:00.0" > /sys/bus/pci/drivers/r8169/bind

-bash: echo: write error: No such device

What am I doing wrong ?

Have you deletetd the r8125-kmp package?

Or disabled the module before loading r8169?

(In reply to Stephan Hemeier from comment #13)
> Have you deletetd the r8125-kmp package?
> 
> Or disabled the module before loading r8169?

I have been using the r8125 module which I compiled from the download link I provided and then signing the module so that the kernel will load it.

That has worked flawlessly for me, the only issue was that I'd have to keep compiling and signing whenever the kernel updates.

Unless I misunderstood Takashi message, here is what I did.

ip link set enp5s0 down    # The 8126 wired NIC 

rmmod r8125                # The one I compiled and signed

modprobe r8169             # So I could try adding as Takashi suggested

lsmod | grep r8169         # Just to verify it loaded 

Then I did the 2 command Takashi provided which produced the results from my prior message.

(In reply to Joe S from comment #12)
> (In reply to Takashi Iwai from comment #11)
> > You can try to add the new entry for 8126 via sysfs and let r8169 driver
> > binding with it without compilation.
> >   https://docs.kernel.org/PCI/pci.html?highlight=new_id
> > 
> > e.g. try to write like
> >   echo -n "10ec 8126 ffff ffff 0 0 0" > /sys/bus/pci/drivers/r8169/new_id
> >   echo -n "0000:05:00.0" > /sys/bus/pci/drivers/r8169/bind
> 
> Ok, I tried what you suggested above.
> 
> First I load the module and verified it loaded:
> 
> lsmod | grep r8169
> 
> modprobe r8169
> 
> lsmod | grep r8169
> 
> r8169                 114688  0
> mdio_devres            12288  1 r8169
> libphy                245760  3 r8169,mdio_devres,realtek
> 
> Your 1st echo does not report any issues
> 
> echo -n "10ec 8126 ffff ffff 0 0 0" > /sys/bus/pci/drivers/r8169/new_id
> 
> Your 2nd echo fails
> 
> echo -n "0000:05:00.0" > /sys/bus/pci/drivers/r8169/bind
> 
> -bash: echo: write error: No such device
> 
> What am I doing wrong ?

Check the entries in /sys/bus/pci/devices/*, and whether the given one "0000:05:00.0" is present and it's for your Realtek device.
If the device is present and still bind fails, you might see something in the kernel log.

(In reply to Takashi Iwai from comment #15)
>
> Check the entries in /sys/bus/pci/devices/*, and whether the given one
> "0000:05:00.0" is present and it's for your Realtek device.
> If the device is present and still bind fails, you might see something in
> the kernel log.

Ok here are the commands I did and the results 

modprobe r8169

lsmod | grep r8169
r8169                 114688  0
mdio_devres            12288  1 r8169
libphy                245760  3 r8169,mdio_devres,realtek

echo -n "10ec 8126 ffff ffff 0 0 0" > /sys/bus/pci/drivers/r8169/new_id

echo -n "0000:05:00.0" > /sys/bus/pci/drivers/r8169/bind
-bash: echo: write error: No such device

ls -al  '/sys/bus/pci/devices/0000:05:00.0'
lrwxrwxrwx 1 root root 0 Dec 22 23:23 /sys/bus/pci/devices/0000:05:00.0 -> ../../../devices/pci0000:00/0000:00:1c.3/0000:05:00.0

cat '/sys/bus/pci/devices/0000:05:00.0/device'
0x8126


I also ran journalctl -b -xef while doing the 2 echo commands and no messages were shown.

So it seems to see the 0000:05:00.0 device as the 8126 so I don't understand why your second echo says "No such device"

I'm not sure what went wrong, as there seems no proper error message.

For avoiding the misconfiguration or such, I'm building a test kernel with a patch that just adds the PCI entry for 8126 to TW kernel.
The 6.7.x kernel is being built in OBS home:tiwai:bsc1217417 repo.  Once after the build finishes (takes an hour or so), it'll appear at
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1217417/standard/

Please give it a try later, and give the dmesg output after the boot.
I don't expect this working, but it's still worth to try.

Created attachment 872067 [details]
dmesg log from 6.7 test kernel to try and get Realtek 8126 working

(In reply to Takashi Iwai from comment #17)
> I'm not sure what went wrong, as there seems no proper error message.
> 
> For avoiding the misconfiguration or such, I'm building a test kernel with a
> patch that just adds the PCI entry for 8126 to TW kernel.
> The 6.7.x kernel is being built in OBS home:tiwai:bsc1217417 repo.  Once
> after the build finishes (takes an hour or so), it'll appear at
>   http://download.opensuse.org/repositories/home:/tiwai:/bsc1217417/standard/
> 
> Please give it a try later, and give the dmesg output after the boot.
> I don't expect this working, but it's still worth to try.

That's for doing that, I appreciate it !

I downloaded and installed these 3 packages

   kernel-default-6.7.0-1.1.g898b843.x86_64.rpm
   kernel-default-devel-6.7.0-1.1.g898b843.x86_64.rpm
   kernel-devel-6.7.0-1.1.g898b843.noarch.rpm

NOTE: I installed the dev packages too because if it worked I was planning to recompile the vmware modules which I use.

lsmod | grep r8169

  r8169                 114688  0
  mdio_devres            12288  1 r8169
  libphy                245760  3 r8169,mdio_devres,realtek

Shows that the r8169 module is now loading with the new 6.7 kernel 

but ip a does not list the network adapter

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: wlo1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether f2:98:ea:e6:3c:ff brd ff:ff:ff:ff:ff:ff permaddr 90:65:84:fe:d1:b1
    altname wlp4s0f0

I also ran lspci -vvv and am including the output for the realtek 8126
which shows that r8169 module loaded too

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 8126 (rev 01)
    Subsystem: ASUSTeK Computer Inc. Device 88ac
    Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Interrupt: pin A routed to IRQ 19
    IOMMU group: 18
    Region 0: I/O ports at 4000 [size=256]
    Region 2: Memory at 77400000 (64-bit, non-prefetchable) [size=64K]
    Region 4: Memory at 77410000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
        Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
        Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Address: 0000000000000000  Data: 0000
        Masking: 00000000  Pending: 00000000
    Capabilities: [70] Express (v2) Endpoint, MSI 01
        DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10W
        DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
            MaxPayload 256 bytes, MaxReadReq 512 bytes
        DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
        LnkCap: Port #0, Speed 8GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
            ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
        LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
            ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
        LnkSta: Speed 8GT/s, Width x1
            TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+
             10BitTagComp- 10BitTagReq- OBFF Via message/WAKE#, ExtFmt- EETLPPrefix-
             EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
             FRS- TPHComp+ ExtTPHComp-
             AtomicOpsCap: 32bit- 64bit- 128bitCAS-
        DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled,
             AtomicOpsCtl: ReqEn-
        LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 2Retimers- DRS-
        LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
             Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot
        LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+
             EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest-
             Retimer- 2Retimers- CrosslinkRes: unsupported
    Capabilities: [b0] MSI-X: Enable- Count=32 Masked-
        Vector table: BAR=4 offset=00000000
        PBA: BAR=4 offset=00000800
    Capabilities: [d0] Vital Product Data
        Not readable
    Capabilities: [100 v2] Advanced Error Reporting
        UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
        UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
        UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
        CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
        CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
        AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
            MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
        HeaderLog: 00000000 00000000 00000000 00000000
    Capabilities: [148 v1] Virtual Channel
        Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
        Arb:    Fixed- WRR32- WRR64- WRR128-
        Ctrl:   ArbSelect=Fixed
        Status: InProgress-
        VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
            Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
            Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
            Status: NegoPending- InProgress-
    Capabilities: [170 v1] Device Serial Number 01-00-00-00-68-4c-e0-00
    Capabilities: [180 v1] Secondary PCI Express
        LnkCtl3: LnkEquIntrruptEn- PerformEqu-
        LaneErrStat: 0
    Capabilities: [190 v1] Transaction Processing Hints
        No steering table available
    Capabilities: [21c v1] Latency Tolerance Reporting
        Max snoop latency: 3145728ns
        Max no snoop latency: 3145728ns
    Capabilities: [224 v1] L1 PM Substates
        L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
              PortCommonModeRestoreTime=150us PortTPowerOnTime=150us
        L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
               T_CommonMode=0us LTR1.2_Threshold=317440ns
        L1SubCtl2: T_PwrOn=150us
    Capabilities: [234 v1] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
    Kernel modules: r8169

NOTE: I can send the full lscpi -vvv output if you want to see it.

I created 6.7.dmesg.log as you requested and have attached it.

The only 2 lines that reference the r8169 in the dmesg log are these 2 lines:

[    3.237151] r8169 0000:05:00.0: enabling device (0000 -> 0003)
[    3.237289] r8169 0000:05:00.0: error -ENODEV: unknown chip XID 649, contact r8169 maintainers (see MAINTAINERS file)

The 2nd line looks like it is the issue.

OK, then it implies that just adding the PCI entry alone doesn't suffice, and it'd need more tweaks.

It means that you'd need to ask the upstream devs of r8169 driver for the support of this missing model.  You can try to open a report on kernel bugzilla, but maybe the best would be to contact them via mailing list (or mail).
Feel free to put me to Cc if you ask them.

(In reply to Takashi Iwai from comment #20)
> OK, then it implies that just adding the PCI entry alone doesn't suffice,
> and it'd need more tweaks.
> 
> It means that you'd need to ask the upstream devs of r8169 driver for the
> support of this missing model.  You can try to open a report on kernel
> bugzilla, but maybe the best would be to contact them via mailing list (or
> mail).
> Feel free to put me to Cc if you ask them.

Ok, I have created the following bug with the kernel

   https://bugzilla.kernel.org/show_bug.cgi?id=218432

I found the maintainer info for the r8169 driver and have also emailed that mailing list and have cc'd you too.

Thank you very much for your continued efforts with this.

(In reply to Takashi Iwai from comment #20)
> OK, then it implies that just adding the PCI entry alone doesn't suffice,
> and it'd need more tweaks.
> 
> It means that you'd need to ask the upstream devs of r8169 driver for the
> support of this missing model.  You can try to open a report on kernel
> bugzilla, but maybe the best would be to contact them via mailing list (or
> mail).
> Feel free to put me to Cc if you ask them.

Hi Takashi,

I got the following response from upstream.

I forward their reply to you via email.

It looks like they provided a patch but merging those changes in is beyond what I know how to do.

Any chance you could build a new kernel again but with these changes and then I could test ?

Thank you !

Thanks!  I'm building a new kernel on the same OBS repo home:tiwai:bsc1217417 with the given patch.  The new kernel will be 6.7.2-*.g91001e5.

As included in the mail, the firmware is likely missing in the upstream linux-firmware, but I suppose the driver may work without it.  Let's see.

(In reply to Takashi Iwai from comment #23)
> Thanks!  I'm building a new kernel on the same OBS repo
> home:tiwai:bsc1217417 with the given patch.  The new kernel will be
> 6.7.2-*.g91001e5.
> 
> As included in the mail, the firmware is likely missing in the upstream
> linux-firmware, but I suppose the driver may work without it.  Let's see.

Thanks Takashi !

I just downloaded and tested the 6.7.2-*.g91001e5 kernel.

Looks like we get further than last time, however, looks like it wants an updated firmware.

Here is the "dmesg | grep 8169" output

[    3.176753] r8169 0000:05:00.0: enabling device (0000 -> 0003)
[    3.184887] r8169 0000:05:00.0: no dedicated PHY driver found for PHY ID 0x001cc862, maybe realtek.ko needs to be added to initramfs?
[    3.184912] r8169: probe of 0000:05:00.0 failed with error -49           

I have responded to the upstream developer with these same details and also updated the kernel bugzilla ( # 218432 ) with the results of the test.

It implies that the realtek PHY driver needs some update.  Hopefully just adding the new id.

(In reply to Takashi Iwai from comment #25)
> It implies that the realtek PHY driver needs some update.  Hopefully just
> adding the new id.

Thanks Takashi, is that something you can add and then I can test or do we need to wait for upstream to respond ?

Better to wait for the response from the upstream devs :)

(In reply to Takashi Iwai from comment #27)
> Better to wait for the response from the upstream devs :)

The kernel developer sent me an update to the fix I sent you.

Looks like he wants you to apply on top of the prior fix.

I have forward you his email.

If you are up to building again with both fixes, then I am happy to test again.

Thanks for your efforts!

The updated kernel is being built in OBS home:tiwai:bsc1217417-2 repo.
It'll appear later at
   http://download.opensuse.org/repositories/home:/tiwai:/bsc1217417-2/standard/
Give it a try.

BTW, at the next time, please just do the direct forward of the mail to me.  The way you forwarded broke the tabs and spaces in the patch, which made it inapplicable.  I had to edit all lines manually.

(In reply to Takashi Iwai from comment #29)
> The updated kernel is being built in OBS home:tiwai:bsc1217417-2 repo.
> It'll appear later at
>   
> http://download.opensuse.org/repositories/home:/tiwai:/bsc1217417-2/standard/
> Give it a try.
> 
> BTW, at the next time, please just do the direct forward of the mail to me. 
> The way you forwarded broke the tabs and spaces in the patch, which made it
> inapplicable.  I had to edit all lines manually.

Thanks Takashi, sorry you had that issue with the email.

I didn't do anything different from when I forward the first patch from upstream.

I use Thunderbird for email and  just hit forward on upstream's email and typed in your email address.

Possibly the issue is because the upstream developer hit reply to me and then when I forward that to you it already had the problem ?

Otherwise, I'm not sure what you want me to do differently if there is another patch but if you want me to do something other than hitting forward just let me know and I am happy to do it.

I'm not sure which side broke the space, but maybe it's Thunderbird.
The easiest way would would have been to just put Cc to me while communicating with the upstream dev.  Then I'll receive the original mail :)

In anyway, please let me know the result with the new test kernel.  That's the most interesting part.

(In reply to Takashi Iwai from comment #31)
> I'm not sure which side broke the space, but maybe it's Thunderbird.
> The easiest way would would have been to just put Cc to me while
> communicating with the upstream dev.  Then I'll receive the original mail :)
> 
> In anyway, please let me know the result with the new test kernel.  That's
> the most interesting part.

You may be right about it being TB.

I purposely had not included you on the upstream emails so I didn't waste your time until I had something concrete back from upstream but I will now make sure you are included on those emails.

I just replied to upstream with the results of the test with the new kernel and will include it below so that you have the results in this bug report too.

I just installed the test kernel provided with both patches.

Here is the dmesg | grep 8169 output using this new test kernel

[    3.630222] r8169 0000:05:00.0: enabling device (0000 -> 0003)
[    3.632148] r8169 0000:05:00.0 eth0: RTL8126A, e8:9c:25:78:c9:bf, XID 649, IRQ 207
[    3.632150] r8169 0000:05:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    3.633218] r8169 0000:05:00.0 enp5s0: renamed from eth0
[    4.212381] r8169 0000:05:00.0: Direct firmware load for rtl_nic/rtl8126a-2.fw failed with error -2
[    4.212384] r8169 0000:05:00.0: Unable to load firmware rtl_nic/rtl8126a-2.fw (-2)
[    4.236119] RTL8251B 5Gbps PHY r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC)
[    4.349625] r8169 0000:05:00.0 enp5s0: Link is Down
[    7.858055] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx

Although dmesg has these 2 error messages, I have network connectivity, ran a quick speed test and am getting the correct speeds.

[    4.212381] r8169 0000:05:00.0: Direct firmware load for rtl_nic/rtl8126a-2.fw failed with error -2
[    4.212384] r8169 0000:05:00.0: Unable to load firmware rtl_nic/rtl8126a-2.fw (-2)

Here is the 'lsmod | grep 8169' results so you can see what is loaded

r8169                 114688  0 
mdio_devres            12288  1 
r8169 libphy                245760  3 r8169,mdio_devres,realtek 

I will continue to test and report back if there are any network issues.

OK, it sounds promising.  The firmware isn't mandatory, and it's more about the configuration adjustment.  So it's no surprise that the driver works without the firmware.

Let's hope that the upstream dev submits the proper patch in a near future.  Then we can backport it to TW kernel, and that's it all.

(In reply to Takashi Iwai from comment #33)
> OK, it sounds promising.  The firmware isn't mandatory, and it's more about
> the configuration adjustment.  So it's no surprise that the driver works
> without the firmware.
> 
> Let's hope that the upstream dev submits the proper patch in a near future. 
> Then we can backport it to TW kernel, and that's it all.

I got a reply back from upstream where you were included in my response but they left you off their response.

I have forward that email to you and am pasting here so you have it in the bug report too.

*** Response from upstream

A user reported that first consumer mainboards show up with a RTL8126A
5Gbps MAC/PHY. This adds support for the integrated PHY, which is also
available stand-alone. From a PHY driver perspective it's treated the
same as the 2.5Gbps PHY's, we just have to support the new PHY ID.

Reported-by: Joe Salmeri
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/realtek.c | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 894172a3e..132784321 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -1047,6 +1047,16 @@ static struct phy_driver realtek_drvs[] = {
.resume = rtlgen_resume,
.read_page = rtl821x_read_page,
.write_page = rtl821x_write_page,
+ }, {
+ PHY_ID_MATCH_EXACT(0x001cc862),
+ .name = "RTL8251B 5Gbps PHY",
+ .get_features = rtl822x_get_features,
+ .config_aneg = rtl822x_config_aneg,
+ .read_status = rtl822x_read_status,
+ .suspend = genphy_suspend,
+ .resume = rtlgen_resume,
+ .read_page = rtl821x_read_page,
+ .write_page = rtl821x_write_page,
}, {
PHY_ID_MATCH_EXACT(0x001cc961),
.name = "RTL8366RB Gigabit Ethernet",




Looks like they signed off on the patch.

I believe he put it into the linux-next branch which I believe is what will become the 6.8 kernel.

Is this something that you would backport to a 6.7.x kernel or will I have to wait for 6.8 to appear in TW ?

I GREATLY appreciate all your efforts to work though this with me and help me get to the correct people to get support added !

For now, I plan to just keep using the test kernel you gave to make sure no problems crop up but so far it works fine.

Now the two proper patches have been submitted to the upstream, I backported them to stable branch (and SLE15-SP6 branch for Leap 15.6).
  https://lore.kernel.org/r/c2eaaf79-600a-4162-b439-8dbd7e7033fd@gmail.com
  https://lore.kernel.org/r/0c8e67ea-6505-43d1-bd51-94e7ecd6e222@gmail.com

For TW, it'll be likely included in 6.7.4 update kernel.

The firmware file was also merged to the upstream linux-firmware tree, and I updated kernel-firmware-* package now for TW, too.

With that, all done from the dev side.

I'll be on the lookout for a TW build with the 6.7.4 kernel.

> The firmware file was also merged to the upstream linux-firmware tree, and I
> updated kernel-firmware-* package now for TW, too.

So Heiner Kallweit got the firmware file from Realtek for the 8126 ?

If so, that's great !
 
> With that, all done from the dev side.

Thanks Takashi !

(In reply to Takashi Iwai from comment #36)
> The firmware file was also merged to the upstream linux-firmware tree, and I
> updated kernel-firmware-* package now for TW, too.
> 
> With that, all done from the dev side.

Hi Takashi,

FYI, I switched to TW 20240209 with the 6.7.4-1 kernel, so between that and your original test kernel I have been using the changes for about a month now and have had no issues.

Thanks for all your help with getting this support added.