[PATCH v2 00/24] blk: Rationalise the block interface

[Simon Glass]

Hi Johan,

On Sun, 14 Aug 2022 at 00:34, Johan Jonker <jbx6244 at gmail.com> wrote:
>
>
>
> On 8/12/22 17:11, Simon Glass wrote:
> > Hi Johan,
> >
> > On Fri, 12 Aug 2022 at 07:51, Johan Jonker <jbx6244 at gmail.com> wrote:
> >>
> >> Hi Simon and others,
> >>
> >> Some comments. Have a look if it's useful.
> >> Include is an example of how currently a new Rockchip external RKNAND FTL block device must be included in U-boot.
> >> Changes must be made all over the place. EFI has now become a somewhat "obligation" for block devices, then handling
> >> should be made more easy I propose.
> >>
> >> 1:
> >> The creation and removal of block devices is kind of dynamic with the blk_create_device function.
> >> Is it possible to make the necessary functions in efi_device_path.c and part.c more flexible as well by
> >> a new "blk_create_efi_device()" and "blk_remove_efi_device()" function? So everything combined in one function.
> >
> > Do you mean to automatically create a device with the right uclass?
> > Yes I think that could be done, but I have not looked at it.
>
> Hi,
>
> Some comments...
> Reduced the number of public CC's.
> I have included a patch with call back function as example, so efi_device_path.c and part.c don't have to be changed for every new block device.
> Make EFI framework code without class specific things.
> TODO define     { UCLASS_XXXXX, "xxxxx" }, in class driver and not in a fixed array.
> Look up for xxxxx ==> UCLASS_XXXXX needs a lot more work which is out of scope for my capacity now.

I'm not keen on callbacks, but we could use events if necessary.

Would you please send your patches based on my series and to the
mailing list? You can mark them RFC if you are unsure, but I really
cannot see myself replying to patches that are sent as an attachment
and don't appear in patchwork :-)

Regards,
Simon