Hello, On Thu, Jun 05, 2025 at 09:23:02PM +0200, Salvatore Bonaccorso wrote: > Hi Samuel, > > On Wed, Jun 04, 2025 at 09:58:57PM +0200, Salvatore Bonaccorso wrote: > > Hi Samuel, > > > > On Sun, Jun 01, 2025 at 11:01:46PM +0100, Samuel Henrique wrote: > > > Source: linux > > > Severity: normal > > > > > > RTL8125D and RTL8125D.rev2 have been available in consumer products since at > > > least October 2024 (e.g.: Asus Z890 motherboards). > > > > > > The "firmware-realtek" package already has the required files in unstable and > > > testing: > > > /usr/lib/firmware/rtl_nic/rtl8125d-1.fw > > > /usr/lib/firmware/rtl_nic/rtl8125d-2.fw > > > > > > I believe we just need to backport the following linux commits to fully enable > > > their support on Debian: > > > https://github.com/torvalds/linux/commit/f75d1fbe7809bc5ed134204b920fd9e2fc5db1df > > > https://github.com/torvalds/linux/commit/b3593df26ab19f114d613693fa8a92ab202803d0 > > > > > > Please consider backporting them so that Debian trixie supports these > > > motherboards. Without this, installing Debian trixie on these systems will be a > > > hassle. > > > > We had today a brief discussion about your request in the weekly > > kernel team meeting, and we do not really aim to start backporting > > such changes with may become more problematic in future while we > > frequently rebase versions in stable (as we follow the stable upstream > > releases). We though about it, and think this might be worth asking > > the stable maintainers upstream for inclusion, which I will do next. > > > > If the request is accepted then fine, and we can as well pick the > > change in advance in the next uploads. But if it gets denied I have do > > defer you to please use the backports kernel (once trixie is > > released). > > I had a brief look at this today an the second commit won't apply > cleanly. I suspect we will open a can of worms here, so if you feel > strong about having that support in the 6.12.y series can you please > apporach upstream and ask for inclusion? I also took a look and to keep backporting halfway sane a few more commits are needed--as Salvatore also found out. My current wip state has: f75d1fbe7809bc5ed134204b920fd9e2fc5db1df b299ea0069284186b0d3d54aebe87f0d195d457a b3593df26ab19f114d613693fa8a92ab202803d0 e340bff27e63ed61a1e9895bed546107859e48a7 b11bff90f2ad52c5c55c822ecd20326619a73898 and I gave up resolving the merge conflict that applying e340bff27e63ed61a1e9895bed546107859e48a7 results in. For b299ea0069284186b0d3d54aebe87f0d195d457a it would also be helpful if 330dc2297c82953dff402e0b4176a5383a618538 was backported, but that pulls in another patch as the function r8169_mod_reg8_cond doesn't exist in 6.12 yet. That makes me doubt that upstream picks these via stable. If that already helps, maybe the stable maintainers are willing to pick just f75d1fbe7809bc5ed134204b920fd9e2fc5db1df into 6.12.y?! In sum I support Salvatore's statement to defer to backport kernels once trixie is released. Best regards Uwe
Attachment:
signature.asc
Description: PGP signature