[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d4120fa-3a20-4cc4-a078-ee94e03229f9@gmail.com>
Date: Fri, 22 Aug 2025 08:39:35 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andreas Klinger <ak@...klinger.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: jic23@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, lars@...afoo.de, javier.carrasco.cruz@...il.com,
arthur.becker@...tec.com, perdaniel.olsson@...s.com,
mgonellabolduc@...onoff.com, muditsharma.info@...il.com, clamor95@...il.com,
emil.gedenryd@...s.com, devicetree@...r.kernel.org,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/3] iio: light: add support for veml6046x00 RGBIR
color sensor
On 21/08/2025 21:53, Andreas Klinger wrote:
> Hi Andy,
>
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> schrieb am Do, 21. Aug 12:43:
>>>>> + part_id = le16_to_cpu(reg);
>>>>> + if (part_id != 0x0001)
>>>>> + dev_info(dev, "Unknown ID %#04x\n", part_id);
>>>>
>>>> For 0 it will print 0 and not 0x0000. Is it okay?
>>>
>>> I just tried and it prints 0x00 if the part_id is 0.
>>
>> This is interesting... So it's not 0, nor 0x0000?
>
> No. It prints 0x00 on my BeagleBoneBlack with kernel 6.16.0-rc5.
I think this makes sense because of the '#' -flag. The "0x" is appended
because of it, and this consumes 2 characters from the 4 character
field, leaving only 2 chars left for the value.
What I find interesting is that gcc on my PC does:
printf("%#04x\n", 0);
printf("%#04x\n", 1);
printf("%#04x\n", 10);
printf("%#04x\n", 17);
0000
0x01
0x0a
0x11
gcc version 15.2.1 20250808 (Red Hat 15.2.1-1) (GCC)
It'd be nice to learn why the zero is treated differently? Andy, did you
have some insight as you asked this?
Yours,
-- Matti
Powered by blists - more mailing lists