On 06/09/2022 00.44, Martin Povišer wrote: > >> On 5. 9. 2022, at 17:32, Russell King (Oracle) <linux@xxxxxxxxxxxxxxx> wrote: > >> I still need a resolution between you and Hector over the smc_key >> issue - specifically, do I pick up the patch that adds support for >> %p4ch, or do we re-architect the smc_key thing and also in doing so >> get rid of the need for your "endian conversion" thing. > > Idea about the %p4ch thing: We will leave the keys true > to their nature (i.e. 32-bit integer), and at least initially > for the prints we will employ macros > > #define SMC_KEYFMT “%c%c%c%c” > #define SMC_KEYFMT_VAL(val) (val)>>24,(val)>>16,(val)>>8,(val) > > used like > > printk(“blah blah” SMC_KEYFMT “ blah\n”, SMC_KEYFMT_VAL(key)); > > This has the nice property that it is pretty much like the specifier, > and later can be easily replaced with the real thing. Not the prettiest, but I'll take this over trying to mess around with string buffer conversions or anything involving non-native endianness if the printk specifier patch is going to be controversial. I'd prefer shorter macro names though, like SMC_KFMT/SMC_KVAL(), to avoid further lengthening already-long printk lines. - Hector