From lxoliva at fsfla.org  Fri Oct 16 05:29:14 2026
From: lxoliva at fsfla.org (Alexandre Oliva)
Date: Fri, 16 Oct 2026 02:29:14 -0300
Subject: GNU Linux-libre 7.3-rc7-gnu: testing welcome
Message-ID: <orv7722oyd.fsf@lxoliva.fsfla.org>

I've just pushed 7.3-rc7-gnu to the git repo.

There have been some significant changes to Rust modules such as
NOVA_CORE and DRM_TYR.

I'd appreciate if someone who regularly builds kernels with Rust enabled
would give this rc a spin and let me know in case I've broken something.

TIA,

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/

From lxoliva at fsfla.org  Fri Oct 16 05:54:12 2026
From: lxoliva at fsfla.org (Alexandre Oliva)
Date: Fri, 16 Oct 2026 02:54:12 -0300
Subject: Large tables of "magic numbers" in r8169 driver
In-Reply-To: <1d03f40184b19f1aa344227bd98932a901629f18.camel@posteo.net> (John
 Scott's message of "Mon, 10 Aug 2026 18:33:49 +0000")
References: <1d03f40184b19f1aa344227bd98932a901629f18.camel@posteo.net>
Message-ID: <orqzhq2nsr.fsf@lxoliva.fsfla.org>

Hello, John,

Thanks for raising this issue.

On Aug 10, 2026, John Scott <jscott at posteo.net> wrote:

> kernel's in-tree driver for these Realtek Ethernet NICs has many
> tables of magic numbers that are opaque and seem to have been crafted
> with internal information at Realtek.

Opaque and undocumented tables of initializers for hardware registers
are quite unfortunate, but they're pure data, so we don't reject them.

We draw the line at nonfree code.  That's easy to identify when it's
clearly marked as such, say, by a nonfree license.  It's not so easy
when it's numbers encoding a sourceless program.  Sometimes it involves
sniffing the numbers and making an educated, conservative guess.

> drivers/net/ethernet/realtek/r8169_main.c for example, and look for
> the definition of the rtl_enable_ltr() function around line 3000, as

These are definitely not disguised code.

> well as "fix-up" code in rtl8411b_fix_phy_down().

This is more borderline.  It was previously spelled as a long sequence
of r8168_mac_ocp_write statements, and we used to accept that, so when
it was changed to an array of numbers, we kept on accepting it.

Looking at the numbers, it doesn't look like code at first, but later on
it starts seeming more and more plausible as code, but not quite enough
for me to place it beyond the line without more evidence than I could
get.

> I want to make sure it wasn't missed
> and its inclusion is intentional.

Thanks!

> For some NICs though (I think I have an RTL8168 handy?) I don't think
> the firmware is necessary, so this driver is still useful but is
> complicated by the fact that it supports both very old and very new
> NICs. If the secret numbers are only needed for the new generation,
> maybe the tables can be zeroed out in anticipation that older NICS
> will never reach the code.

We could do that indeed, but I'd rather have *some* evidence that this
is indeed executable code, rather than hardware register initialization
sequences with obscure data, before making such a change.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/