qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: qemu-arm <qemu-arm@nongnu.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] hw/arm/virt: Fix PL061 node name and properties
Date: Fri, 22 May 2020 10:30:28 +0100	[thread overview]
Message-ID: <CAFEAcA9TzPcWWiJNTQ=EZzsSVy5qTPz5DXTePGmXWBTxZg7i7w@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdWrTbWTrLvMnX=60F+UqH6DJ9kDU1FZ5TnT2=mbah1yfg@mail.gmail.com>

On Fri, 22 May 2020 at 09:29, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Peter,
>
> On Thu, May 21, 2020 at 6:59 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> > On Tue, 19 May 2020 at 09:49, Geert Uytterhoeven
> > <geert+renesas@glider.be> wrote:
> > > Make the created node comply with the PL061 Device Tree bindings:
> > >   - Use generic node name "gpio" instead of "pl061",
> > >   - Add missing "#interrupt-cells" and "interrupt-controller"
> > >     properties.
> >
> > Where have these properties come from? They must be optional,
> > because in the version of the binding documentation from Linux
> > 5.0 they're not described:
> > https://elixir.bootlin.com/linux/v5.0/source/Documentation/devicetree/bindings/gpio/pl061-gpio.txt
>
> Many old DT bindings are incomplete.

Yeah, but production QEMU is out there in the world based on
the old DT binding documentation. So you can't unilaterally
make a part of the binding that wasn't documented and that QEMU
didn't emit mandatory. It might be preferable for new QEMU to
emit it, of course.

> When running the validation on a device tree passed to the guest
> (extracted from /sys/firmware/devicetree/base, converted to dts, and
>  manually fixed up the phandles), the following is reported about the
> pl061 node:
>
>     virt.dt.yaml: pl061@9030000: {'reg': [[0, 151191552, 0, 4096]],
> 'gpio-controller': True, 'phandle': [[32771]], '#gpio-cells': [[2]],
> 'clocks': [[32768]], '#interrupt-cells': [[2]], 'compatible':
> ['arm,pl061', 'arm,primecell'], 'clock-names': ['apb_pclk'],
> '$nodename': ['pl061@9030000']} is not valid under any of the given
> schemas
>     [...]
>             virt.dt.yaml: pl061@9030000: 'interrupts' is a required property
>
>     virt.dt.yaml: pl061@9030000: $nodename:0: 'pl061@9030000' does not
> match '^gpio@[0-9a-f]+$'
>     virt.dt.yaml: pl061@9030000: 'interrupt-controller' is a required property

This is just saying "the yaml says these things are mandatory".
You could equally get rid of them by marking them optional in
the yaml, right?

Also, complaining about the nodename seems like a bug in the
validation: it is not a mandatory part of the spec, just a
recommendation.

> > Since the devicetree spec says that the interrupt-controller
> > property "defines a node as an interrupt controller node"
> > and a GPIO chip isn't an interrupt controller, this seems
> > like some kind of error in the dtb binding. Maybe I'm
> > missing something...
>
> PL061 is an interrupt controller, as it can assert its interrupt output
> based on activity on GPIO input lines.

By that logic the PL011 UART is an interrupt controller, because
it can assert its interrupt output based on activity on the serial
port input lines.

A GPIO controller is not an interrupt controller inherently.
Maybe you can use it in a system design as an interrupt
controller if you want to, and in that system's dtb perhaps
it would make sense to label it as one, but the virt board's
PL061 is in no way an interrupt controller -- it's just a GPIO
controller.

> > What actually goes wrong if QEMU doesn't specify these
> > properties?
>
> It means that other devices that have their interrupt output connected
> to a PL061 GPIO input won't work, as their driver in the guest OS cannot
> find the interrupt.  Note that arm/virt.c currently doesn't instantiate
> such devices.

OK. But why would we want to run an interrupt line through the GPIO
controller when we have a perfectly good interrupt controller in
the system already?

It might be reasonable to add the properties now to avoid setting
a bear trap for ourselves in future; on the other hand if running
interrupt lines through the GPIO controller doesn't work then it
acts as a nudge to stop people adding devices that are wired
up in a weird way.

> > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > > index 7dc96abf72cf2b9a..99593d7bce4d85cb 100644
> > > --- a/hw/arm/virt.c
> > > +++ b/hw/arm/virt.c
> > > @@ -818,13 +818,15 @@ static void create_gpio(const VirtMachineState *vms)
> > >                                       qdev_get_gpio_in(vms->gic, irq));
> > >
> > >      uint32_t phandle = qemu_fdt_alloc_phandle(vms->fdt);
> > > -    nodename = g_strdup_printf("/pl061@%" PRIx64, base);
> > > +    nodename = g_strdup_printf("/gpio@%" PRIx64, base);
> >
> > Does the devicetree binding really mandate what the node name is?
> > I thought that finding the right device was doe via the
> > 'compatible' string and the nodename could be whatever the
> > device tree creator wanted.
>
> Matching is indeed done based on compatible value.

OK, then we don't need to change the node name here. Lots
of the other devices on the virt board have node names that
happen to use the device name rather than being more generic.

thanks
-- PMM


  reply	other threads:[~2020-05-22  9:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  8:49 [PATCH] hw/arm/virt: Fix PL061 node name and properties Geert Uytterhoeven
2020-05-21 16:59 ` Peter Maydell
2020-05-22  8:29   ` Geert Uytterhoeven
2020-05-22  9:30     ` Peter Maydell [this message]
2020-05-22  9:46       ` Philippe Mathieu-Daudé
2020-05-29  8:01       ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFEAcA9TzPcWWiJNTQ=EZzsSVy5qTPz5DXTePGmXWBTxZg7i7w@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=f4bug@amsat.org \
    --cc=geert@linux-m68k.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).