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. Regards, Simon
