Re: git: 46f982122c0d - main - sys: Bump non-ISA PNP removal to 16.0

On Mon, Oct 27, 2025 at 9:19 AM 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=46f982122c0d670ac181b748a5b8c2b221f61517
> >
> > commit 46f982122c0d670ac181b748a5b8c2b221f61517
> > Author:     Ed Maste <emaste@FreeBSD.org>
> > AuthorDate: 2025-10-24 18:39:00 +0000
> > Commit:     Ed Maste <emaste@FreeBSD.org>
> > 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 its
> resources at this point.  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
> uarts, atrtc, and attimer).  If we remove syscons that also removes the sc0
> 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.  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.
> 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 wire
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