> On 24 Feb 2025, at 4:19 PM, andriy.shevchenko@xxxxxxxxxxxxxxx wrote: > > On Mon, Feb 24, 2025 at 10:43:54AM +0000, Aditya Garg wrote: >>>> On 24 Feb 2025, at 4:11 PM, andriy.shevchenko@xxxxxxxxxxxxxxx wrote: >>> On Mon, Feb 24, 2025 at 10:32:27AM +0000, Aditya Garg wrote: >>>>>> On 24 Feb 2025, at 3:54 PM, andriy.shevchenko@xxxxxxxxxxxxxxx wrote: >>>>> On Mon, Feb 24, 2025 at 10:18:48AM +0000, Aditya Garg wrote: >>>>>>>> On 24 Feb 2025, at 3:28 PM, andriy.shevchenko@xxxxxxxxxxxxxxx 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@xxxxxxxx> 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? drm drivers have a %p4cc already upstream. I think we need that then. > >>>>>>>> [1]: https://lore.kernel.org/asahi/E753B391-D2CB-4213-AF82-678ADD5A7644@xxxxxxxxxxx/ >>>>>>>> >>>>>>>> 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 > >
