Re: [PATCH v2 2/3] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc

["andriy.shevchenko@linux.intel.com" <andriy.shevchenko@linux.intel.com>]

On Mon, Feb 24, 2025 at 10:43:54AM +0000, Aditya Garg wrote:
> > On 24 Feb 2025, at 4:11 PM, andriy.shevchenko@linux.intel.com wrote:
> > On Mon, Feb 24, 2025 at 10:32:27AM +0000, Aditya Garg wrote:
> >>>> On 24 Feb 2025, at 3:54 PM, andriy.shevchenko@linux.intel.com wrote:
> >>> On Mon, Feb 24, 2025 at 10:18:48AM +0000, Aditya Garg wrote:
> >>>>>> On 24 Feb 2025, at 3:28 PM, andriy.shevchenko@linux.intel.com wrote:
> >>>>> On Sat, Feb 22, 2025 at 03:46:03PM +0000, Aditya Garg wrote:
> >>>>>>>> On 20 Feb 2025, at 10:09 PM, Aditya Garg <gargaditya08@live.com> wrote:

...

> >>>>>>> %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but
> >>>>>>> it's useful to be able to print generic 4-character codes formatted as
> >>>>>>> an integer. Extend it to add format specifiers for printing generic
> >>>>>>> 32-bit FOURCCs with various endian semantics:
> >>>>>>> 
> >>>>>>> %p4ch   Host-endian
> >>>>>>> %p4cl Little-endian
> >>>>>>> %p4cb Big-endian
> >>>>>>> %p4cr Reverse-endian
> >>>>>>> 
> >>>>>>> The endianness determines how bytes are interpreted as a u32, and the
> >>>>>>> FOURCC is then always printed MSByte-first (this is the opposite of
> >>>>>>> V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would
> >>>>>>> allow printing LSByte-first FOURCCs stored in host endian order
> >>>>>>> (other than the hex form being in character order, not the integer
> >>>>>>> value).
> >>>>> 
> >>>>> ...
> >>>>> 
> >>>>>> BTW, after looking at the comments by Martin [1], its actually better to use
> >>>>>> existing specifiers for the appletbdrm driver.  The driver needs the host
> >>>>>> endian as proposed by this patch, so instead of that, we can use %.4s
> >>>>> 
> >>>>> Do you mean this patch will not be needed? If this a case, that would be the
> >>>>> best solution.
> >>>> 
> >>>> I tested with %4pE, and the results are different from expected. So this
> >>>> would be preferred. Kindly see my latest email with a proposed workaround for
> >>>> the sparse warnings.
> >>> 
> >>> %.4s sounded okay, but %4pE is always about escaping and the result may occupy
> >>> %4x memory (octal escaping of non-printable characters). Of course, you may vary
> >>> the escaping classes, but IIRC the octal or hex escaping is unconditional.
> >> 
> >> %.4s is used for unsigned int iirc, here it's __le32.
> > 
> > No, it's used to 'char *'. in case one may guarantee that it at least is
> > four characters long.

> Still the argument here is __le32. %p4h is showing reverse values than what
> %4pE as well as %.4s shows.

For __le32 the %.4s will print from LSB to MSB and otherwise for __be32.
You can provide any conversion you want to have it stable between
the endianesses. In any case looking at the DRM patch it might be that
the entire driver got the endianess wrong. Have you checked my comment
there?

> >>>>>> [1]: https://lore.kernel.org/asahi/E753B391-D2CB-4213-AF82-678ADD5A7644@cutebit.org/
> >>>>>> 
> >>>>>> Alternatively we could add a host endian only. Other endians are not really
> >>>>>> used by any driver AFAIK. The host endian is being used by appletbdrm and
> >>>>>> Asahi Linux’ SMC driver only.

-- 
With Best Regards,
Andy Shevchenko