On Fri, May 22, 2026 at 05:14:54PM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 22 May 2026 at 09:00, Tom Rini <[email protected]> wrote: > > > > On Thu, May 21, 2026 at 05:30:12PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On 2026-05-19T15:18:15, Tom Rini <[email protected]> wrote: > > > > > > > This series fixes bootdev_get_bootflow to not require the ops > > > > field in the driver to be set and then removes the empty struct from the > > > > places which had been creating one. > > > > > > Two more empty bootdev_ops structures fit this pattern: > > > nvme_bootdev_ops and usb_bootdev_ops. Please can you fold those into > > > v2 so we clean them all up together? > > > > I'll follow-up and remove those later, and also update the doc and > > remove the mmc one. > > OK > > > > > > > As part of Marek Vasut's work to add static and/or const to structs that > > > > should have it, but do not, it exposed a small problem with the bootdev > > > > uclass. > > > > > > BTW for patch 1 it would be useful to update the comment for > > > bootdev_get_ops() to indicate it can return NULL - normally, we don't > > > allow this. > > > > Don't allow which? I get the feeling you're saying I need to audit the > > reset of the uclasses for optional ops fields and then see who is just > > setting an empty struct and fix them too.. > > No, I just mean that there should normally be an ops pointer, unless > the uclass itself does not support any operations. The case of using > NULL for the ops pointer is really just an optimisation. I'm fine with > it, but it might create confusion for people, so it would be good to > document it in the uclass header file, where supported.
I'll make sure the documentation is clearer in the follow-up series. I think at this point the majority of implementation do not set one, btw. -- Tom
signature.asc
Description: PGP signature
