All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Mark Kettenis <mark.kettenis@xs4all.nl>,
	sjg@chromium.org, xypron.glpk@gmx.de, u-boot@lists.denx.de
Subject: Re: efi_loader breakage
Date: Wed, 27 Apr 2022 16:26:25 +0900	[thread overview]
Message-ID: <20220427072625.GD34649@laputa> (raw)
In-Reply-To: <20220427044813.GB34649@laputa>

On Wed, Apr 27, 2022 at 01:48:13PM +0900, AKASHI Takahiro wrote:
> On Tue, Apr 26, 2022 at 07:07:13PM +0200, Mark Kettenis wrote:
> > commit d97e98c887ed8fa4a339350c02f093f03cd1cf4d breaks the OpenBSD
> > bootloader.  Or rather, it seems that this breaks access to raw
> > devices through the UEFI interfaces, which is something the OpenBSD
> > bootloader relies on.
> > 
> > After this commit we end up calling dev_read() and dev_write() instead
> > of blk_dread() and blk_dwrite().  But dev_read() and dev_write() only
> > work if dev_get_blk() returns a valid struct blkdev, and that handles
> > only for UCLASS_PARTITION.  But when accessing raw devices we have a
> > UCLASS_BLK.
> 
> Probably I forgot this use case.
> 
> > The easy fix would be to support UCLASS_BLK in dev_get_blk(), but that
> > function has an explicit comment saying:
> 
> The best way to do is to modify efi_disk_rw_blocks().

I have already made necessary changes, but found another problem
(not relating to my patch) in device path handling.

So I will post the patch once I fix the latter issue as well.

-Takahiro Akashi


> -Takahiro Akashi
> 
> >         /*
> >          * We won't support UCLASS_BLK with dev_* interfaces.
> >          */
> > 			  
> > So I'm a bit at a loss what is needed here.

  reply	other threads:[~2022-04-27  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26 17:07 efi_loader breakage Mark Kettenis
2022-04-27  4:48 ` AKASHI Takahiro
2022-04-27  7:26   ` AKASHI Takahiro [this message]
2022-04-27  9:31     ` Mark Kettenis

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=20220427072625.GD34649@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.