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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1be6caa4-abbd-4f3b-8c63-b637f0f9ed15@tuxedocomputers.com>
Date: Tue, 20 Jan 2026 10:42:28 +0100
From: Georg Gottleuber <ggo@...edocomputers.com>
To: Yao Zi <me@...ao.cc>, 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



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.

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

> Note some out-of-tree driver derived from the vendor one fallback to a
> static MAC address[1], so it doesn't mean your eFuse has MAC address
> written if you only observe the MAC address doesn't change between
> reboots.
> 
> Best regards,
> Yao Zi
> 
> [1]: https://github.com/ziyao233/yt6801-vendor-driver/blob/0efb3e86702ad2b19e7f9d19172a8e1df143e8c7/fuxi-gmac-common.c#L17-L32