From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Markus Armbruster <armbru@redhat.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <Alistair.Francis@wdc.com>,
Bin Meng <bin.meng@windriver.com>,
qemu-riscv@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH for-6.2] hw/misc/sifive_u_otp: Use IF_PFLASH for the OTP device instead of IF_NONE
Date: Fri, 19 Nov 2021 12:03:45 +0100 [thread overview]
Message-ID: <45ffa010-7c93-1020-46b2-84c0f2060c20@redhat.com> (raw)
In-Reply-To: <4a4c5223-905f-9974-3e54-e4ccd133c359@redhat.com>
On 11/19/21 12:02, Thomas Huth wrote:
> On 19/11/2021 11.40, Philippe Mathieu-Daudé wrote:
>> On 11/19/21 11:25, Thomas Huth wrote:
>>> Configuring a drive with "if=none" is meant for creation of a backend
>>> only, it should not get automatically assigned to a device frontend.
>>> Use "if=pflash" for the One-Time-Programmable device instead (like
>>> it is e.g. also done for the efuse device in hw/arm/xlnx-zcu102.c).
>>>
>>> Since the old way of configuring the device has already been published
>>> with the previous QEMU versions, we cannot remove this immediately, but
>>> have to deprecate it and support it for at least two more releases.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> docs/about/deprecated.rst | 6 ++++++
>>> hw/misc/sifive_u_otp.c | 9 ++++++++-
>>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>
>>> diff --git a/hw/misc/sifive_u_otp.c b/hw/misc/sifive_u_otp.c
>>> index 18aa0bd55d..cf6098ff2c 100644
>>> --- a/hw/misc/sifive_u_otp.c
>>> +++ b/hw/misc/sifive_u_otp.c
>>> @@ -209,7 +209,14 @@ static void sifive_u_otp_realize(DeviceState
>>> *dev, Error **errp)
>>> TYPE_SIFIVE_U_OTP, SIFIVE_U_OTP_REG_SIZE);
>>> sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->mmio);
>>> - dinfo = drive_get_next(IF_NONE);
>>> + dinfo = drive_get_next(IF_PFLASH);
>>> + if (!dinfo) {
>>> + dinfo = drive_get_next(IF_NONE);
>>
>> Isn't it a bug to call drive_get_next() from DeviceRealize()?
>>
>> Shouldn't drive_get_next() be restricted to the MachineClass?
>
> Yes, that would certainly be better - but considering that we are
> already past RC1 of the 6.2 release, I'd rather prefer to keep this
> patch rather as small as possible and do such refactorings during the
> next development cycle instead.
OK. For pflash:
Acked-by: Philippe Mathieu-Daudé <philmd@redhat.com>
next prev parent reply other threads:[~2021-11-19 11:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-19 10:25 [PATCH for-6.2] hw/misc/sifive_u_otp: Use IF_PFLASH for the OTP device instead of IF_NONE Thomas Huth
2021-11-19 10:40 ` Philippe Mathieu-Daudé
2021-11-19 11:02 ` Thomas Huth
2021-11-19 11:03 ` Philippe Mathieu-Daudé [this message]
2021-11-19 11:31 ` Markus Armbruster
2021-11-19 13:11 ` Alistair Francis
2021-11-22 0:44 ` Alistair Francis
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=45ffa010-7c93-1020-46b2-84c0f2060c20@redhat.com \
--to=philmd@redhat.com \
--cc=Alistair.Francis@wdc.com \
--cc=armbru@redhat.com \
--cc=bin.meng@windriver.com \
--cc=palmer@dabbelt.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=thuth@redhat.com \
/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).