From: Simon Glass <sjg@chromium.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>,
U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH 1/1] block: fix blk_get_devnum_by_typename()
Date: Wed, 3 Aug 2022 12:14:00 -0600 [thread overview]
Message-ID: <CAPnjgZ0-b5-ecoiQnUBZwdTSiwPXVcV_xrZBvj5NHAf-UP_nLw@mail.gmail.com> (raw)
In-Reply-To: <cc92818f-1cc1-70d5-bc47-bf50f5719656@canonical.com>
Hi Heinrich,
On Tue, 2 Aug 2022 at 10:22, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
>
>
> On 8/2/22 14:41, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 2 Aug 2022 at 03:50, Heinrich Schuchardt
> > <heinrich.schuchardt@canonical.com> wrote:
> >>
> >> Both the 'host' and the 'efiloader' block devices use the same parent
> >> uclass root. Thus the parent uclass is not an indicator the interface type.
> >>
> >> Currently the following fails:
> >>
> >> setenv efi_selftest block device
> >> bootefi selftest
> >> part list efiloader 0
> >>
> >> Struct blk_desc contains the interface type. So we can check it directly
> >> without caring about the parent uclass.
> >>
> >> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> >> ---
> >> drivers/block/blk-uclass.c | 10 +++-------
> >> 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > We've had this discussion before, but this patch will make it
>
> Yes, you blocked the obvious solution.
Yes, I explained the problem with that at the time.
>
> > difficult to migrate away from IF_TYPE.
>
> My patch does not have any impact on the migration as function
> blk_get_devnum_by_typename() will simply vanish together with IF_TYPE.
>
> Migrating away from IF_TYPE could follow the following path if you
> wanted to keep struct blk_desc:
>
> Just replace devnum by the udevice in struct blk_desc and add the GUI
> representation of the device type (e.g. "mmc") as field to struct blk_ops.
>
> The field devnum only made sense in the world of legacy drivers.
> By the way why do I still find CONFIG_IS_ENABLED(BLK) in block drivers?
>
> A better solution would be to completely do away with struct blk_desc
> and instead always use the udevice.
>
> >
> > Instead we should fix EFI. Having the root as a parent of a block
> > device seems wrong to me. What is the actual device that provides the
> > block device?
>
> There is no actual parent device. In
> lib/efi_selftest/efi_selftest_block_device.c the block device is a RAM
> disk. This is the same situation as with the sandbox host device where
> you have chosen root as the dummy parent for good reason.
Is it a RAM disk on disk, or an in-memory one?
>
> In
> "[1/1] drivers: add memory disk support"
> https://patchwork.ozlabs.org/project/uboot/patch/20220419211641.316935-1-heinrich.schuchardt@canonical.com/
> I have proposed a further block device type that has no actual parent.
>
> The idea of using a parent device to match a block device was always a
> dead end. Let's bury it now.
Possibly, but it is how we can drop the IF_TYPE stuff. Let me spend a
bit of time looking at this and see what can be done.
[..]
Regards,
Simon
next prev parent reply other threads:[~2022-08-03 18:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 9:49 [PATCH 1/1] block: fix blk_get_devnum_by_typename() Heinrich Schuchardt
2022-08-02 12:41 ` Simon Glass
2022-08-02 16:22 ` Heinrich Schuchardt
2022-08-03 18:14 ` Simon Glass [this message]
2022-08-04 6:06 ` Heinrich Schuchardt
2022-08-07 15:48 ` Simon Glass
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=CAPnjgZ0-b5-ecoiQnUBZwdTSiwPXVcV_xrZBvj5NHAf-UP_nLw@mail.gmail.com \
--to=sjg@chromium.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.de \
/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).