On Fri 2021-02-12 13:28:56, Sakari Ailus wrote:
On Thu, Feb 11, 2021 at 06:14:28PM +0100, Petr Mladek wrote:
On Tue 2021-02-09 19:47:55, Sakari Ailus wrote:
Hi Andy,
On Tue, Feb 09, 2021 at 11:58:40AM +0200, Andy Shevchenko wrote:
On Tue, Feb 09, 2021 at 11:20:32AM +0200, Sakari Ailus wrote:
On Mon, Feb 08, 2021 at 10:43:30PM +0200, Andy Shevchenko wrote:
On Mon, Feb 8, 2021 at 10:11 PM Sakari Ailus sakari.ailus@linux.intel.com wrote:
> + %p4cc BG12 little-endian (0x32314742)
This misses examples of the (strange) escaping cases and wiped whitespaces to make sure everybody understands that 'D 12' will be the same as 'D1 2' (side note: which I disagree on, perhaps something should be added into documentation why).
I discussed this with Hans and we concluded spaces shouldn't be dropped.
Spaces can be present in the codes themselves in any case.
Great!
...
> +static noinline_for_stack > +char *fourcc_string(char *buf, char *end, const u32 *fourcc, > + struct printf_spec spec, const char *fmt) > +{
> + char output[sizeof("(xx)(xx)(xx)(xx) little-endian (0x01234567)")];
Do we have any evidence / document / standard that the above format is what people would find good? From existing practices (I consider other printings elsewhere and users in this series) I find '(xx)' form for hex numbers is weird. The standard practice is to use \xHH (without parentheses).
Earlier in the review it was proposed that special handling of codes below 32 should be added, which I did. Using the parentheses is apparently an existing practice elsewhere.
Where? \xHH is quite well established format for escaping. Never heard about '(xx)' variant before this very series.
What about using the same approach as drm_get_format_name()? I mean printing '?' when the character is not printable. The exact value is printed later anyway.
The advantage is that it will always printk 4 characters.
"?" can be expanded by the shell. We (me and Hans) both though a dot (".") would be good. These aren't going to be present in valid fourcc codes in any case.
The dot (".") looks fine to me.
Best Regards, Petr