On Thu, 19 Feb 2026 at 14:55, Igor Mammedov <[email protected]> wrote:
>
> On Thu, 19 Feb 2026 13:00:13 +0000
> Peter Maydell <[email protected]> wrote:
>
> > On Thu, 19 Feb 2026 at 12:17, Igor Mammedov <[email protected]> wrote:
> > >
> > > On Wed, 18 Feb 2026 19:08:36 +0000
> > > Peter Maydell <[email protected]> wrote:
> >
> > > > Please can you also add support for exposing this device
> > > > in the device tree ?
> > >
> > > It's possible,
> > > but we probably should not enable it if acpi variant was requested,
> > > to avoid confusion on guest side.
> >
> > Why? Almost every other device on this board we advertise
> > via DTB for device tree guests and via ACPI for ACPI guests.

> If we expose both guest may try to load both drivers causing conflict or 
> misbehavior.

Huh? A guest will do one of:
 1 read the ACPI tables, and load the driver based on the ACPI data
 2 read the DTB, and load the driver based on the DTB

Nothing tries to read both at once, or it would get totally
confused.

> I can try and see what arm kernel would do in presence if both
> but that's not the point.

We know already that this works fine, because almost every
piece of hardware in the virt board is described in both
the dtb and the ACPI tables.

> One should consider plain GWDT whatchdog as a different device
> when compared to WDAT one.
> The later one is basically an synthetic watchdog with it's own driver.
> From guest pov they are different devices (using the same registers/irqs).

But there is only one piece of hardware here, right?
I don't have an opinion on what the best way to tell the
guest about that in the ACPI tables is. I just want us
to report the presence of the watchdog in both DTB and ACPI,
so that it is usable whichever the guest is using.

> > > > Can we have a command line option name that isn't ACPI
> > > > specific, please? There's nothing inherent to ACPI about
> > > > "I would like a watchdog device".
> > >
> > > that is specifically asking for ACPI flavor being used/configured.
> > > acpi specific option conflates 2 things:
> > >    1. watchdog device creation (of the board choice) with properties 
> > > tuned for WDAT usage
> > >    2. how to expose it on firmware level (in this case ACPI WDAT table)
> >
> > Right, and I think that's the wrong way to approach this,
> > at least for the virt board. We should either always create
> > or allow the user to ask us to create a watchdog device.
> > And then we should do what we do for all the other devices,
> > which is expose it via both the mechanisms that we have
> > for telling the guest about hardware (ACPI and DTB).
>
> Looks like I wasn't clear, WDAT is not a description
> of the hardware watchdog. It's a 'abstract watchdog device',
> that uses a set IO/MMIO operations from WDAT table to manage
> whatever hardware watchdog board provides. Guest uses WDAT
> specific driver to manage it.

Does the user need to care about how we report the hardware in
the ACPI tables? Is there not a way we can report it that works
for all guests?

thanks
-- PMM

Reply via email to