qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: bin.meng@windriver.com, mark.cave-ayland@ilande.co.uk,
	qemu-devel@nongnu.org, edgar.iglesias@gmail.com,
	sundeep.lkml@gmail.com, qemu-block@nongnu.org,
	andrew.smirnov@gmail.com, hskinnemoen@google.com, joel@jms.id.au,
	atar4qemu@gmail.com, alistair@alistair23.me, b.galvani@gmail.com,
	nieklinnenbank@gmail.com, qemu-arm@nongnu.org, clg@kaod.org,
	kwolf@redhat.com, qemu-riscv@nongnu.org, andrew@aj.id.au,
	f4bug@amsat.org, Andrew.Baumann@microsoft.com,
	jcd@tribudubois.net, kfting@nuvoton.com, hreitz@redhat.com,
	palmer@dabbelt.com
Subject: Re: [PATCH RFC 0/2] Eliminate drive_get_next()
Date: Mon, 15 Nov 2021 17:01:15 +0100	[thread overview]
Message-ID: <87fsrxflx0.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA9gQCQv7XENgT-ap+2qhiggZTt-yEHQ1WJ6__5hHRRU1A@mail.gmail.com> (Peter Maydell's message of "Mon, 15 Nov 2021 14:05:50 +0000")

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 15 Nov 2021 at 12:55, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> This is RFC because I'm unsure about the removal of
>>
>>     /* Reason: init() method uses drive_get_next() */
>>     dc->user_creatable = false;
>>
>> in PATCH 1.  Both users appear to wire up some GPIO.  If that's
>> necessary for the thing to work, we should just replace the comment.
>
> Looking at the code, it sort of is and sort of isn't. The GPIO line
> is the chip-select line. If you don't connect it then (because the
> ssi-sd device configures cs_polarity to SSI_CS_LOW, requesting an
> active-low chip-select) the device will always be selected. If
> the machine created an SSI bus with no SSI device attached to it
> then in theory the user could create an ssi-sd device and connect
> it there and have it work. But in practice it's really unlikely:
> machines create SSI buses with specific wired-in devices on them,
> and the guest OS knows what it has to do to enable the chip select
> for the device it wants to talk to (often some known GPIO pin on
> a GPIO controller).
>
> So I would keep the user_creatable = false, with a reason of
> "user should wire up GPIO chip-select line". But see below for

I'll do it this way.

> a pile of contrary precedent.
>
> (The chip-select GPIO is created in the parent class, incidentally.)
>
>> Aside: there may be devices that need manual wiring to work, yet don't
>> have user_creatable unset.  Bugs if you ask me.  I don't have smart
>> ideas on how to track them down.
>
> Me neither. I notice that the TYPE_M25P80 is also an SSI peripheral
> with an active-low chipselect but that one doesn't set user_creatable
> to false. TYPE_SSD0323 also is user-creatable and that one has an
> active-high chipselect, which means the user can create a device but
> it will then never be usable because it will ignore all transactions.
> (More generally, looks like most subclasses of TYPE_SSI_PERIPHERAL
> don't set user_creatable = false.)

For sysbus devices, we clear user_creatable by default, because sysbus
devices pretty much always[*] need wiring.  Is this the case for SSI bus
devices, too?


[*] The most prominent exception is "dynamic sysbus", which I believe
was a mistake.



      reply	other threads:[~2021-11-15 16:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15 12:55 [PATCH RFC 0/2] Eliminate drive_get_next() Markus Armbruster
2021-11-15 12:55 ` [PATCH RFC 1/2] hw/sd/ssi-sd: Do not create SD card within controller's realize Markus Armbruster
2021-11-15 13:40   ` Peter Maydell
2021-11-15 13:48     ` Markus Armbruster
2021-11-15 12:55 ` [PATCH RFC 2/2] hw: Replace drive_get_next() by drive_get() Markus Armbruster
2021-11-15 13:38   ` Peter Maydell
2021-11-15 13:48     ` Markus Armbruster
2021-11-15 13:59   ` Philippe Mathieu-Daudé
2021-11-15 15:57     ` Markus Armbruster
2021-11-15 21:15       ` Philippe Mathieu-Daudé
2021-11-16  7:47         ` Markus Armbruster
2021-11-16  8:52       ` Cédric Le Goater
2021-11-16  9:29         ` Markus Armbruster
2021-11-16 12:14           ` Cédric Le Goater
2021-11-15 14:05 ` [PATCH RFC 0/2] Eliminate drive_get_next() Peter Maydell
2021-11-15 16:01   ` Markus Armbruster [this message]

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=87fsrxflx0.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=Andrew.Baumann@microsoft.com \
    --cc=alistair@alistair23.me \
    --cc=andrew.smirnov@gmail.com \
    --cc=andrew@aj.id.au \
    --cc=atar4qemu@gmail.com \
    --cc=b.galvani@gmail.com \
    --cc=bin.meng@windriver.com \
    --cc=clg@kaod.org \
    --cc=edgar.iglesias@gmail.com \
    --cc=f4bug@amsat.org \
    --cc=hreitz@redhat.com \
    --cc=hskinnemoen@google.com \
    --cc=jcd@tribudubois.net \
    --cc=joel@jms.id.au \
    --cc=kfting@nuvoton.com \
    --cc=kwolf@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=nieklinnenbank@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=sundeep.lkml@gmail.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).