[PATCH v2 06/14] mmc: Use logging instead of pr_err()

[Quentin Schulz]

Hi Simon,

On 8/13/24 3:02 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Tue, 13 Aug 2024 at 06:29, Quentin Schulz <quentin.schulz at cherry.de>
> wrote:
>>
>> Hi Simon,
>>
>> On 8/13/24 2:16 PM, Simon Glass wrote:
>>> Hi Quentin,
>>>
>>> On Mon, 12 Aug 2024 at 02:58, Quentin Schulz <quentin.schulz at cherry.de>
> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On 8/11/24 4:50 PM, Simon Glass wrote:
>>>>> Hi Quentin,
>>>>>
>>>>> On Tue, 6 Aug 2024 at 08:10, Quentin Schulz <quentin.schulz at cherry.de>
> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On 7/21/24 5:25 PM, Simon Glass wrote:
>>>>>>> Use the log subsystem instead of dev, to avoid including function
> names
>>>>>>> in the code.
>>>>>>>
>>>>>>> The CONFIG_LOGF_FUNC option can be used to enable the function name.
>>>>>>>
>>>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>>>>> Reviewed-by: Sean Anderson <seanga2 at gmail.com>
>>>>>>> ---
>>>>>>>
>>>>>>> (no changes since v1)
>>>>>>>
>>>>>>>      drivers/mmc/mmc.c | 49
> ++++++++++++++++++++++++-----------------------
>>>>>>>      1 file changed, 25 insertions(+), 24 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>>>>>> index b18dc331f78..b0105afe5d6 100644
>>>>>>> --- a/drivers/mmc/mmc.c
>>>>>>> +++ b/drivers/mmc/mmc.c
>>>>>>> @@ -294,7 +294,7 @@ int mmc_poll_for_busy(struct mmc *mmc, int
> timeout_ms)
>>>>>>>
>>>>>>>                  if (status & MMC_STATUS_MASK) {
>>>>>>>      #if !defined(CONFIG_SPL_BUILD) ||
> defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
>>>>>>> -                     pr_err("Status Error: 0x%08x\n", status);
>>>>>>> +                     log_err("Status Error: %08x\n", status);
>>>>>>
>>>>>> Please don't remove the 0x prefix (will not comment on other patches
> in
>>>>>> this series if it happens again, please check :) ).
>>>>>
>>>>> OK...hex is the default though.
>>>>>
>>>>
>>>> Can you please clarify what you meant by "it's the default though"?
>>>
>>> U-Boot uses hex by default, so anything printed out or entered is
>>> normally in hex. There are a few exceptions, not all of them correct.
>>
>> Gotcha. This actually has been painful to me and I've made the mistake a
>> few times already, e.g. writing 256 blocks instead of 100 (100 aka 0x100
>> instead of base10 100). Are you aware whether this is made explicit in
>> the docs somewhere? So I could refer to it if I ever need to explain
> stuff?
> 
> I believe it was in the old Denx manual. I found it in a Digi one [2]:
> 
> Numbers used by U-Boot are always considered to be in hexadecimal format.
>> For example, U-Boot
>> understands number 30100000 as 0x30100000.
> 
> 
> Perhaps we should add something like that to doc/usage?
> 

Should have grepped in doc/ myself before asking others to do so for me :)

https://docs.u-boot.org/en/latest/usage/cmdline.html#representing-numbers 
documents this.

I would guess this is "good enough"? If not, not sure how to make this 
better? Hopefully, the commands that do not interpret as hex any string 
missing the 0x prefix have their help text specify this!

Cheers,
Quentin