Hi Tom, On 14/11/2024 19:02, Tom Rini wrote: > On Wed, Nov 13, 2024 at 03:47:16PM +0100, Caleb Connolly wrote: >> >> >> On 13/11/2024 15:24, Tom Rini wrote: >>> On Wed, Nov 13, 2024 at 06:30:08AM +0100, Caleb Connolly wrote: >>> >>>> It may be the case that MMC support is enabled even though the board >>>> we're booting on doesn't have any MMC devices. Move the print over to >>>> the print_mmc_devices() function where we can only print it if we >>>> actually have MMC devices. >>>> >>>> Signed-off-by: Caleb Connolly <caleb.conno...@linaro.org> >>> >>> I'm not sure I like this. What we do / don't find on startup is part of >>> the not-exactly-API. It's true that if we don't print an MMC line at >>> all, and we should have MMC, the user (and any scripts that parse >>> console output) but now we're also increasing the code size a little bit >>> too. I can be convinced this is a good idea, but I'm not there yet. >> >> Hmm, fair enough. I'll offer some more context, maybe there's a smarter >> approach here I'm not seeing. >> >> The main place this shows up is on Qualcomm boards. Since all Qualcomm >> armv8 targets are supported with qcom_defconfig (just by adjusting which >> DTB is used), we can't know at build time whether the board has MMC. >> >> I guess my thinking behind this patch comes from a bigger picture desire >> to get UFS and MMC more aligned. The number of devices with UFS is >> definitely going up, and I would argue that U-Boot's inconsistent >> treatment of these two storage classes (obviously a result of their >> relative age and support in the codebase) is really unintuitive and >> weird for users (nevermind that the "scsi" command is used for UFS >> devices, cute though it is). >> >> I'm really wary to open this whole can of worms, since I guess it would >> require some larger efforts and collaboration to fix. But maybe this >> patch (or one like it) would be better suited in the context of some >> larger effort to unify storage backends? > > I get it now, thanks. And yeah, this is part of our inconsistency in > printing information. I'd rather leave things alone here (assuming the > MMC: printout is reasonable in the case of no devices, similar to how > the Net: printout is reasonable in that case) and wait for a longer term > / high level solution wherein for example as we go down the device tree > we give some consistent level of information for everything (and more or > less info depending on verbosity configured perhaps). >
Thanks for taking a look. Something like what you're suggesting sounds good to me, and I agree it's fine to leave things as-is until we have such a plan. Kind regards, -- // Caleb (they/them)
