From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: [PATCH 0/4] Support marking individual qbus buses as 'full'
Date: Fri, 3 Sep 2021 16:14:31 +0100 [thread overview]
Message-ID: <20210903151435.22379-1-peter.maydell@linaro.org> (raw)
By default, QEMU will allow devices to be plugged into a bus up to
the bus class's device count limit. If the user creates a device on
the command line or via the monitor and doesn't explicitly specify
the bus to plug it in, QEMU will plug it into the first non-full bus
that it finds.
This is fine in most cases, but some machines have multiple buses of
a given type, some of which are dedicated to on-board devices and
some of which have an externally exposed connector for user-pluggable
devices.
In particular, the various MPS2 and MPS3 boards have multiple
I2C buses. Some of these are used purely for on-board devices like
the touchscreen controller or the DDR4 EEPROM, and some are routed
to the "shield" expansion connector. Currently if the user creates
an I2C device (eg with "-device tmp105") it gets plugged into whatever
the search happens to find first, which for some of these boards
is one of the internal-devices-only buses.
The first patch in this series adds a new function qbus_mark_full()
which marks an individual qbus as full, and makes the "find an
available bus" search code honour that. The intention is that the
board code can handle internal-devices-only buses like
* create the bus controller
* create all the internal devices, and plug them into that bus
* call qbus_mark_full() on the bus
Patches 2-4 use this to mark the internal-only i2c buses on
the various mps2/mps3 machines as 'full'. (As it happens, we
don't model any of the internal i2c devices on these boards
yet, so the 'full' buses won't have any devices on them.)
This is a minor behaviour change for existing command-lines
for these boards, since an i2c device will now get plugged in
in a different place; but none of these boards are versioned
and very few people will be manually creating i2c devices anyway.
thanks
-- PMM
Peter Maydell (4):
qdev: Support marking individual buses as 'full'
hw/arm/mps2-tz.c: Add extra data parameter to MakeDevFn
hw/arm/mps2-tz.c: Mark internal-only I2C buses as 'full'
hw/arm/mps2.c: Mark internal-only I2C buses as 'full'
include/hw/qdev-core.h | 24 +++++++++++
hw/arm/mps2-tz.c | 92 +++++++++++++++++++++++++++++-------------
hw/arm/mps2.c | 12 +++++-
softmmu/qdev-monitor.c | 7 +++-
4 files changed, 106 insertions(+), 29 deletions(-)
--
2.20.1
next reply other threads:[~2021-09-03 15:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-03 15:14 Peter Maydell [this message]
2021-09-03 15:14 ` [PATCH 1/4] qdev: Support marking individual buses as 'full' Peter Maydell
2021-09-04 8:48 ` Richard Henderson
2021-09-03 15:14 ` [PATCH 2/4] hw/arm/mps2-tz.c: Add extra data parameter to MakeDevFn Peter Maydell
2021-09-04 8:52 ` Richard Henderson
2021-09-03 15:14 ` [PATCH 3/4] hw/arm/mps2-tz.c: Mark internal-only I2C buses as 'full' Peter Maydell
2021-09-04 8:53 ` Richard Henderson
2021-09-03 15:14 ` [PATCH 4/4] hw/arm/mps2.c: " Peter Maydell
2021-09-04 8:54 ` Richard Henderson
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=20210903151435.22379-1-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=armbru@redhat.com \
--cc=pbonzini@redhat.com \
--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).