linux-kernel - Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for Motorcomm YT6801

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: <aW9sZwDpQu88BRPG@pie>
Date: Tue, 20 Jan 2026 11:52:07 +0000
From: Yao Zi <me@...ao.cc>
To: Georg Gottleuber <ggo@...edocomputers.com>,
	"Russell King (Oracle)" <linux@...linux.org.uk>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, Frank.Sae@...or-comm.com,
	hkallweit1@...il.com, vladimir.oltean@....com, wens@...e.org,
	jszhang@...nel.org, 0x1207@...il.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, jeffbai@...c.io, kexybiscuit@...c.io,
	Christoffer Sandberg <cs@...edocomputers.com>
Subject: Re: [PATCH RESEND net-next v6 0/3] Add DWMAC glue driver for
 Motorcomm YT6801

On Tue, Jan 20, 2026 at 10:42:28AM +0100, Georg Gottleuber wrote:
> 
> 
> Am 20.01.26 um 03:45 schrieb Yao Zi:
> > On Mon, Jan 19, 2026 at 06:57:48PM +0100, Georg Gottleuber wrote:
> >> Am 19.01.26 um 18:45 schrieb Georg Gottleuber:
> >>> Hi,
> >>>
> >>> thanks for the quick reply.
> >>>
> >>> Am 19.01.26 um 16:43 schrieb Russell King (Oracle):
> >>>> On Mon, Jan 19, 2026 at 04:33:17PM +0100, Georg Gottleuber wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I tested this driver with our TUXEDO InfinityBook Pro AMD Gen9. Iperf
> >>>>> revealed that tx is only 100Mbit/s:
> >>>>>
> >>> ...
> >>>>>
> >>>>> With our normally used DKMS module, Ethernet works with full-duplex and
> >>>>> gigabit. Attached are some logs from lspci and dmesg. Do you have any
> >>>>> idea how I can debug this further?
> >>>>
> >>>> My suggestion would be:
> >>>>
> >>>> - Look at the statistics, e.g.
> >>>>
> >>>>    ip -s li sh dev enp2s0
> >>>
> >>> That looks good (after iperf):
> >>>
> >>> 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> >>> mode DEFAULT group default qlen 1000
> >>>     link/ether ba:90:88:24:49:4f brd ff:ff:ff:ff:ff:ff
> >>>     RX:  bytes packets errors dropped  missed   mcast
> >>>        2091654   31556      0       0       0       0
> >>>     TX:  bytes packets errors dropped carrier collsns
> >>>       88532451    1518      0       0       0       0
> >>>
> >>>
> >>>> - apply
> >>>>   https://lore.kernel.org/r/E1vgtBc-00000005D6v-040n@rmk-PC.armlinux.org.uk
> >>>>   to enable more statistics to work, and check the network driver
> >>>>   statistics:
> >>>>
> >>>>    ethtool --statistics enp2s0
> >>>>
> >>>> to see if there's any clues for what is going on.
> >>>
> >>> That looks also good, I think. I saved it before and after the test with
> >>> iperf. See attachments.
> >>
> >> Oh, there was something else interesting in dmesg. See attachment.
> >>
> >>> Regards,
> >>> Georg
> > 
> >> [    0.933480] dwmac-motorcomm 0000:02:00.0: error -ENOENT: failed to read maca0lr from eFuse
> >> [    0.933483] dwmac-motorcomm 0000:02:00.0: eFuse contains no valid MAC address
> >> [    0.933485] dwmac-motorcomm 0000:02:00.0: fallback to random MAC address
> > 
> > Some vendors didn't write a MAC address to the eFuse. With these YT6801
> > chips, the failure is expected.
> 
> I believe we have a fixed address, as our DKMS driver always uses it (it
> is also displayed in the BIOS).
> 
> > Which DKMS driver do you use? Could you read out a permanent address
> > with your DKMS driver? If not, this piece of log should have nothing to
> > do with the rate problem.
> 
> DKMS module we use:
> https://gitlab.com/tuxedocomputers/development/packages/tuxedo-yt6801
> 
> Apparently, your driver can also read the permanent address. I rebooted
> nine times to test it, and it worked nine times. So it was probably a
> glitch that doesn't occur very often.

Thanks for the hint. I'm sure I've encountered similar cases once or
twice during development, but it stopped happening later, so I
considered it's somehow fixed. I'll test more and see what's going wrong
here.

> 
> Do you have any ideas on how I can further debug the rate problem?

Sadly I don't have any good suggestions. The Motorcomm glue is
mysterious and totally undocumented, so it's hard to find out what's
missing or wrong. I had to debug the driver by modifying this and vendor
driver and then comparing behavior differences.

Do you build the driver into the kernel, or as a module? I'll try to
reproduce your case locally and investigate it, but as a hobbyist I
cannot make any promises, really sorry about it.

Best regards,
Yao Zi