From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 262A7C433DB for ; Tue, 9 Feb 2021 09:58:51 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B28F664DE8 for ; Tue, 9 Feb 2021 09:58:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B28F664DE8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 059176EAAB; Tue, 9 Feb 2021 09:58:50 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id BC1BA6EAAB for ; Tue, 9 Feb 2021 09:58:47 +0000 (UTC) IronPort-SDR: ognXsWFLBRTwrKIbZtKd7PiDufqfL0q0bWzWShenIq5DbQNc3oO1fwUWDrPGR+EDVvp7APpfI/ mCzcUkD6lokQ== X-IronPort-AV: E=McAfee;i="6000,8403,9889"; a="161606294" X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="161606294" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2021 01:58:47 -0800 IronPort-SDR: T0qTs/2i2PqBJXc5IrRTpS6kpOrU/SRzXxopGHG1/kUrdforSp9RRZLCJI15PCgXsR6DLCOQT6 lslQrLAfLUyQ== X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="374903061" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2021 01:58:43 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1l9Pn6-003Bop-Ba; Tue, 09 Feb 2021 11:58:40 +0200 Date: Tue, 9 Feb 2021 11:58:40 +0200 From: Andy Shevchenko To: Sakari Ailus Subject: Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs Message-ID: References: <20210208200903.28084-1-sakari.ailus@linux.intel.com> <20210208200903.28084-2-sakari.ailus@linux.intel.com> <20210209092032.GC32460@paasikivi.fi.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210209092032.GC32460@paasikivi.fi.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Petr Mladek , Dave Stevenson , Rasmus Villemoes , Linux Kernel Mailing List , dri-devel , Hans Verkuil , Sergey Senozhatsky , Steven Rostedt , Laurent Pinchart , Joe Perches , Mauro Carvalho Chehab , Linux Media Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 > > 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). > > The spaces are expected to be at the end only. I can add such example if > you like. There are no fourcc codes with spaces in the middle in neither > V4L2 nor DRM, and I don't think the expectation is to have them either. But then the code suggests otherwise. Perhaps we need to extract skip_trailing_spaces() from strim() and use it here. ... > > > +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. > Note that neither DRM nor V4L2 currently has such fourcc codes currently. ... > > > + p = special_hex_number(p, output + sizeof(output) - 2, *fourcc, > > > + sizeof(u32)); > > > > This is perfectly one line (in this file we have even longer lines). > > Sure, you can do that, and I can then review your patch and point to the > coding style documentation. :-) Yes, you can. The problem is that we agreed with others to improve readability by letting some lines to be longer, so the code can lie on one line rather be broken on two or more. -- With Best Regards, Andy Shevchenko _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04029C433E6 for ; Tue, 9 Feb 2021 10:02:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AECB064EBC for ; Tue, 9 Feb 2021 10:02:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231245AbhBIKB4 (ORCPT ); Tue, 9 Feb 2021 05:01:56 -0500 Received: from mga07.intel.com ([134.134.136.100]:40622 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230055AbhBIJ7s (ORCPT ); Tue, 9 Feb 2021 04:59:48 -0500 IronPort-SDR: EzexextpcHXkR3+sRv7i+mak/SosG3+LuIk0w2lNK6uKkBvTZaKpF6jZWrRPHO+mM2jg25fXnA 9SnBM6rhe3eA== X-IronPort-AV: E=McAfee;i="6000,8403,9889"; a="245925083" X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="245925083" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2021 01:58:47 -0800 IronPort-SDR: T0qTs/2i2PqBJXc5IrRTpS6kpOrU/SRzXxopGHG1/kUrdforSp9RRZLCJI15PCgXsR6DLCOQT6 lslQrLAfLUyQ== X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="374903061" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2021 01:58:43 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1l9Pn6-003Bop-Ba; Tue, 09 Feb 2021 11:58:40 +0200 Date: Tue, 9 Feb 2021 11:58:40 +0200 From: Andy Shevchenko To: Sakari Ailus Cc: Linux Kernel Mailing List , Linux Media Mailing List , Petr Mladek , Dave Stevenson , dri-devel , Hans Verkuil , Laurent Pinchart , Mauro Carvalho Chehab , Sergey Senozhatsky , Steven Rostedt , Joe Perches , Jani Nikula , Rasmus Villemoes Subject: Re: [PATCH v6 1/3] lib/vsprintf: Add support for printing V4L2 and DRM fourccs Message-ID: References: <20210208200903.28084-1-sakari.ailus@linux.intel.com> <20210208200903.28084-2-sakari.ailus@linux.intel.com> <20210209092032.GC32460@paasikivi.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210209092032.GC32460@paasikivi.fi.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org 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 > > 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). > > The spaces are expected to be at the end only. I can add such example if > you like. There are no fourcc codes with spaces in the middle in neither > V4L2 nor DRM, and I don't think the expectation is to have them either. But then the code suggests otherwise. Perhaps we need to extract skip_trailing_spaces() from strim() and use it here. ... > > > +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. > Note that neither DRM nor V4L2 currently has such fourcc codes currently. ... > > > + p = special_hex_number(p, output + sizeof(output) - 2, *fourcc, > > > + sizeof(u32)); > > > > This is perfectly one line (in this file we have even longer lines). > > Sure, you can do that, and I can then review your patch and point to the > coding style documentation. :-) Yes, you can. The problem is that we agreed with others to improve readability by letting some lines to be longer, so the code can lie on one line rather be broken on two or more. -- With Best Regards, Andy Shevchenko