On 06/09/2022 00.44, Martin Povišer wrote:

quoted

On 5. 9. 2022, at 17:32, Russell King (Oracle) [off-list ref] wrote:

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel