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

["Jaehoon Chung" <jh80.chung@samsung.com>]

Hi,

> -----Original Message-----
> From: Caleb Connolly <caleb.connolly@linaro.org>
> Sent: Wednesday, November 13, 2024 11:47 PM
> To: Tom Rini <trini@konsulko.com>
> Cc: Christian Marangi <ansuelsmth@gmail.com>; Dragan Simic <dsimic@manjaro.org>; Ilias Apalodimas
> <ilias.apalodimas@linaro.org>; Jaehoon Chung <jh80.chung@samsung.com>; Jerome Forissier
> <jerome.forissier@linaro.org>; Jonas Karlman <jonas@kwiboo.se>; Marek Vasut
> <marek.vasut+renesas@mailbox.org>; Peng Fan <peng.fan@nxp.com>; Peter Robinson <pbrobinson@gmail.com>;
> Rasmus Villemoes <rasmus.villemoes@prevas.dk>; Simon Glass <sjg@chromium.org>; Sughosh Ganu
> <sughosh.ganu@linaro.org>; u-boot@lists.denx.de
> Subject: Re: [PATCH] mmc: don't print 'MMC:' if there are no MMC devices
>
>
>
> 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@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'm also not sure if it has to apply this at this time.
Partially, I understood what you said about your case.

But In my case, the printing MMC information was useful to do debug at booting time.
(correct dtb or not, or wrong configuration, etc)

Best Regards,
Jaehoon Chung

>
> 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?
>
> Kind regards,
> >
>
> --
> // Caleb (they/them)