[PATCH] mmc: don't print 'MMC:' if there are no MMC devices

[Caleb Connolly]

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.connolly at 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)