From nobody Tue Oct 28 05:12:20 2025 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cwdlt43Vkz6DDwt for ; Tue, 28 Oct 2025 05:12:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cwdlt1J1Hz3wPq for ; Tue, 28 Oct 2025 05:12:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-33d7589774fso5305972a91.0 for ; Mon, 27 Oct 2025 22:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1761628328; x=1762233128; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=o4moMeATqCR2FkJ0Z/88fylZfPCfjqBbtRxBCsEYvhk=; b=UOoU4heKnieb8ZYDsujmdMOVh3mdSxIPKK7o62/aiv/+lMWuqdK0k+xV/ONwmLobYM 1l3YOjLma0Bl9h2ECLe00MUOGdOTP6cWE3+9mUsGUBnn3gwFpzce+gowY+bi7uDvDs5S iCpxbqIw+vFsJyIP28Fmm6g85MwHmB/gkb3iNIc3yh6NlroCOM/GLEJdTNoUDf3fKOdr I0j+WQcX7q9ubM4gL+gdkh0nsVAv6g3YmvbaZDWW0bbFXYLCw+i8+4YIxHTbv2UWxoc3 OltO11xqrfdOfX90X9UZ1/w0BWTG8B9fg5Khvc7e36YKwZEdldfIKmJ6y+kMvKihk4XX 1Cgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761628328; x=1762233128; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o4moMeATqCR2FkJ0Z/88fylZfPCfjqBbtRxBCsEYvhk=; b=pQoYr41L2slMvRHcB2mOiEA7qL6RC2KGCl3hG1kpvp/4mU+kDk6UeFH8JuGdZqhdTD xorzoTUCz1kAbKTLkc40ZiuMZ6TQ/5wZxxZsLL2OuyN+6Ei0pwLhxgHPb5VhtvpA0PHu KwDY6I8JuE4cOpR5t72gpHmkONinMeZMhb7KAFgb1FbsENNE198tuXc67XVwXTGnAAlB sceFUpjVKm5wauOtG+g3ao4epD9qkXzokvxPIDIGm6DneY+jdO7MqOI7v7JUBn99RtRX LZLd3TxEtvQa7n+AC3JwvytI1XkoyktG+s28oa2aFUE3VdGKPZNhHgxWO/bpNiCjsKMm Lq1Q== X-Forwarded-Encrypted: i=1; AJvYcCVvNWUkH6IJAZZBsm6iA97jo2T0ZRj1twQKU8ydoJXosjOyeG5OWIsnPEW6Gg91TjfObPE7ETC5LjKW867qLqYBrj787Q==@freebsd.org X-Gm-Message-State: AOJu0YyHWjeuk56RcIgo8LidEse1za85kHwkCmWcj30pplv+R4ASv9o4 RBS2X+BCoMrZH9mqYWZ3CkNz6IqY1Hf5H/hI0npZ9BV/z5mwgPAr5/jMLtGVa1iMoxqy1zlG+4e WwNUzlB8ZczFHleMISi5+AENz6y/amlurV8+o7KZyYw== X-Gm-Gg: ASbGncsyokOM9Y+9swybV2LDjWpGZ4C7TMWuDc/Xtc4I9QRlznEkzaC/ELqTPv6mxG9 Oy4at64uZZ5w8WubzJ4FnMRKKIjq9a/sXsh5NXLdKOx6tS1pfdSol5NnE4QODInb0MnzjgFm4ZI D9/ZA/5pgEos18MsNxe1+Ctq/yj5AwxX94XdvyJCdHUaDuiTYceWdSPjy/BqLoto3raaN0qpNx7 SAkbdhOmVtRpWN2DOMwwzGm5Juze3eXtjpf6OE1XwFOC1gBGmbyDeWWb4RC+Eck8xmp4t0= X-Google-Smtp-Source: AGHT+IHjzk7tYkyaSuAwJWs7VYSviZ41WQMxHlNv4m/Owqm3k57C+DkoGLRrzdjH0nOnteOfHldntgW1LA+w1BVC4tQ= X-Received: by 2002:a17:90a:c2c8:b0:33b:b453:c900 with SMTP id 98e67ed59e1d1-34027a7b8b7mr2678762a91.19.1761628327714; Mon, 27 Oct 2025 22:12:07 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202510252258.59PMwthG074834@gitrepo.freebsd.org> <4496e47d-cc0c-4259-adcf-e3d739f134a8@FreeBSD.org> In-Reply-To: <4496e47d-cc0c-4259-adcf-e3d739f134a8@FreeBSD.org> From: Warner Losh Date: Mon, 27 Oct 2025 23:12:20 -0600 X-Gm-Features: AWmQ_bm82OkSNXPXDYxwRX4r1rWCJN45mnTjKLzCRrF28k7euPd2phqAEyg8-Mw Message-ID: Subject: Re: git: 46f982122c0d - main - sys: Bump non-ISA PNP removal to 16.0 To: John Baldwin Cc: Ed Maste , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b32f680642310e18" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cwdlt1J1Hz3wPq --000000000000b32f680642310e18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 27, 2025 at 9:19=E2=80=AFAM John Baldwin wrot= e: > On 10/25/25 18:58, Ed Maste wrote: > > The branch main has been updated by emaste: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=3D46f982122c0d670ac181b748a5b8c2b= 221f61517 > > > > commit 46f982122c0d670ac181b748a5b8c2b221f61517 > > Author: Ed Maste > > AuthorDate: 2025-10-24 18:39:00 +0000 > > Commit: Ed Maste > > CommitDate: 2025-10-25 22:57:15 +0000 > > > > sys: Bump non-ISA PNP removal to 16.0 > > > > This may include atkbdc, which is not being removed in 15.0. > > Note that this message is not about removing drivers, but about removing > entries > from /boot/device.hints (GENERIC.hints) (unless we intend to remove > support for > hinted devices entirely from isa(4)?). Was there a user report that > motivated > mentioning atkbdc here, or was that just based on past memory? I'd be > really > surprised if ACPI was failing to enumerate the keyboard controller and it= s > resources at this point. It is debatable if we should make disabling ACP= I > work > out of the box (which is what most of /boot/device.hints does) vs strippi= ng > more entries ouf of device.hints on amd64 (in particular, atkbdc, psm, th= e > uarts, atrtc, and attimer). If we remove syscons that also removes the s= c0 > hint. > We should remove all the legacy device hints from device.hints entirely. And this stupid message. However, we still need to have a device.hints.legacy that can be added back for systems that are too old for ACPI. There's a lot of silly embedded gear that's still in widespread use (I got lots of complaints the last time I broke it). They have half-implemented ACPI that doesn't enumerate legacy devices,but none-the-less they have it. > It's less clear to me if we want to ban hinted ISA devices entirely. Tha= t > pretty much breaks !ACPI booting which can matter for some custom applian= ce > systems that use home-grown firmware that may not include a full DSDT. > It's > fine if we require those downstreams to ship a modified device.hints. I'= m > less > convinced it's useful to require them to also patch isa(4) to support > hinted > children Yes. That's why I think we should likely just remove the message here entirely. The embedded system that are trouble have ACPI, but don't enumerate many of the legacy devices that are none-the-less present. This creates a situation where for those systems we MUST have entries. But for other systems, like a STEAM deck that doesn't have legacy devices we CAN'T have them. When I added the device, I'd hoped that at least the devices would be in ISA PNP tables, but that's not true on these systems (or we ignore them because DSDT is present). I'd propose that we create a new loader.conf variable for this. Today, we have loader_conf_files that's a list of device.hints and loader.conf. However, that makes it tricky to replace one with an alternative. At $WORK we have symlinks for device.hints for wiring reasons. It's easier. But for FreeBSD I think we should separate this out into two variables, but I'm open to other designs that let us substitute one file for another, or to have a list of files (we may be able to construct device.hints.legacy such that it can just be added after device.hints and we'll be fine). We could also then have logic in lua to determine automatically for these odd-balls when to use device.hints.legacy. But there'd likely be some bumps with that since we added COM1/COM2 wiring to device.hints for ACPI enumerated device to wir= e the addresses to uart0/uart1. If we had this logic,we could then just create a 'force adding device.hints.legacy' variable that would bypass the automation. ACPI lua bindings is coming soon, I think, since kaypowkitty's GSOC project provides at least some of what we need for this (we don't need it, unless we want to walk the acpi tables since the AP2 devices have symbios entries we can key off of). Warner --000000000000b32f680642310e18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 27,= 2025 at 9:19=E2=80=AFAM John Baldwin <jhb@freebsd.org> wrote:
On 10/25/25 18:58, Ed Maste wrote:
> The branch main has been updated by emaste:
>
> URL: https://= cgit.FreeBSD.org/src/commit/?id=3D46f982122c0d670ac181b748a5b8c2b221f61517<= /a>
>
> commit 46f982122c0d670ac181b748a5b8c2b221f61517
> Author:=C2=A0 =C2=A0 =C2=A0Ed Maste <emaste@FreeBSD.org>
> AuthorDate: 2025-10-24 18:39:00 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Ed Maste <emaste@FreeBSD.org>
> CommitDate: 2025-10-25 22:57:15 +0000
>
>=C2=A0 =C2=A0 =C2=A0 sys: Bump non-ISA PNP removal to 16.0
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 This may include atkbdc, which is not being remove= d in 15.0.

Note that this message is not about removing drivers, but about removing en= tries
from /boot/device.hints (GENERIC.hints) (unless we intend to remove support= for
hinted devices entirely from isa(4)?).=C2=A0 Was there a user report that m= otivated
mentioning atkbdc here, or was that just based on past memory?=C2=A0 I'= d be really
surprised if ACPI was failing to enumerate the keyboard controller and its<= br> resources at this point.=C2=A0 It is debatable if we should make disabling = ACPI work
out of the box (which is what most of /boot/device.hints does) vs stripping=
more entries ouf of device.hints on amd64 (in particular, atkbdc, psm, the<= br> uarts, atrtc, and attimer).=C2=A0 If we remove syscons that also removes th= e sc0
hint.

stupid message.= =C2=A0However, we still need to have a device.hints.legacy that can be
added back for systems that are too old for ACPI. There's a lot o= f silly embedded gear
that's still in widespread use (I got l= ots of complaints the last time I broke it). They
have half-imple= mented ACPI that doesn't enumerate legacy devices,but none-the-less
they have it.
=C2=A0
It's less clear to me if we want to ban hinted ISA devices entirely.=C2= =A0 That
pretty much breaks !ACPI booting which can matter for some custom appliance=
systems that use home-grown firmware that may not include a full DSDT.=C2= =A0 It's
fine if we require those downstreams to ship a modified device.hints.=C2=A0= I'm less
convinced it's useful to require them to also patch isa(4) to support h= inted
children

Yes. That's why I think we sho= uld likely just remove the message here entirely.
The embedded sy= stem that are trouble have ACPI, but don't enumerate many of
= the legacy devices that are none-the-less present. This creates a situation= where
for those systems we MUST have entries. But for other syst= ems, like a STEAM
deck that doesn't have legacy devices we CA= N'T have them.=C2=A0 When I added the device,
I'd hoped t= hat at least the devices would be in ISA PNP tables, but that's not tru= e
on these systems (or we ignore them because DSDT is present).

I'd propose that we create a new loader.conf va= riable=C2=A0 for this. Today, we have loader_conf_files
that'= s a list of device.hints and loader.conf. However, that makes it tricky to = replace one with
an alternative. At $WORK we have symlinks for de= vice.hints for wiring reasons. It's easier.
But for FreeBSD I= think we should separate this out into two variables, but I'm open to<= /div>
other designs that let us substitute one file for another, or to = have a list of files (we may
be able to construct device.hints.le= gacy such that it can just be added after device.hints
and we'= ;ll be fine).

We could also then have logic in lua= to determine automatically for these odd-balls
when to use devic= e.hints.legacy.=C2=A0 But there'd likely=C2=A0be some bumps with that s= ince
we added COM1/COM2 wiring to device.hints for ACPI enumerate= d device to wire
the addresses to uart0/uart1. If we had this log= ic,we could then just create a 'force
adding device.hints.leg= acy' variable that would bypass the automation.=C2=A0 ACPI lua bindings=
is coming soon, I think, since kaypowkitty's=C2=A0GSOC proje= ct provides at least some of
what we need for this (we don't = need it, unless we want to walk the acpi tables since the AP2
dev= ices have symbios entries we can key off of).

Warn= er
--000000000000b32f680642310e18--