[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220126090527.ksuah5m6xctx7jjo@ldmartin-desk2>
Date: Wed, 26 Jan 2022 01:05:27 -0800
From: Lucas De Marchi <lucas.demarchi@...el.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Emma Anholt <emma@...olt.net>, David Airlie <airlied@...ux.ie>,
nouveau@...ts.freedesktop.org,
Rasmus Villemoes <linux@...musvillemoes.dk>,
dri-devel@...ts.freedesktop.org,
Chris Wilson <chris@...is-wilson.co.uk>,
Vishal Kulkarni <vishal@...lsio.com>,
Francis Laniel <laniel_francis@...vacyrequired.com>,
Kentaro Takeda <takedakn@...data.co.jp>,
amd-gfx@...ts.freedesktop.org, Ben Skeggs <bskeggs@...hat.com>,
Jakub Kicinski <kuba@...nel.org>,
Petr Mladek <pmladek@...e.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Leo Li <sunpeng.li@....com>, intel-gfx@...ts.freedesktop.org,
Raju Rangoju <rajur@...lsio.com>,
Julia Lawall <julia.lawall@...6.fr>,
Rahul Lakkireddy <rahul.lakkireddy@...lsio.com>,
Steven Rostedt <rostedt@...dmis.org>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org,
Christian König <christian.koenig@....com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
Alex Deucher <alexander.deucher@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH 3/3] drm: Convert open yes/no strings to yesno()
On Wed, Jan 19, 2022 at 09:30:47PM +0200, Andy Shevchenko wrote:
>On Tue, Jan 18, 2022 at 11:24:50PM -0800, Lucas De Marchi wrote:
>> linux/string_helpers.h provides a helper to return "yes"/"no"
>> strings. Replace the open coded versions with yesno(). The places were
>> identified with the following semantic patch:
>>
>> @@
>> expression b;
>> @@
>>
>> - b ? "yes" : "no"
>> + yesno(b)
>>
>> Then the includes were added, so we include-what-we-use, and parenthesis
>> adjusted in drivers/gpu/drm/v3d/v3d_debugfs.c. After the conversion we
>> still see the same binary sizes:
>>
>> text data bss dec hex filename
>> 1442171 60344 800 1503315 16f053 ./drivers/gpu/drm/radeon/radeon.ko
>> 1442171 60344 800 1503315 16f053 ./drivers/gpu/drm/radeon/radeon.ko.old
>> 5985991 324439 33808 6344238 60ce2e ./drivers/gpu/drm/amd/amdgpu/amdgpu.ko
>> 5985991 324439 33808 6344238 60ce2e ./drivers/gpu/drm/amd/amdgpu/amdgpu.ko.old
>> 411986 10490 6176 428652 68a6c ./drivers/gpu/drm/drm.ko
>> 411986 10490 6176 428652 68a6c ./drivers/gpu/drm/drm.ko.old
>> 1970292 109515 2352 2082159 1fc56f ./drivers/gpu/drm/nouveau/nouveau.ko
>> 1970292 109515 2352 2082159 1fc56f ./drivers/gpu/drm/nouveau/nouveau.ko.old
>
>...
>
>> #include <linux/module.h>
>> #include <linux/sched.h>
>> #include <linux/slab.h>
>> +#include <linux/string_helpers.h>
>
>+ blank line?
>
>> +#include <linux/string_helpers.h>
>
>...
>
>> seq_printf(m, "\tDP branch device present: %s\n",
>> - branch_device ? "yes" : "no");
>> + yesno(branch_device));
>
>Now it's possible to keep this on one line.
>
>...
>
>> drm_printf_indent(p, indent, "imported=%s\n",
>> - obj->import_attach ? "yes" : "no");
>> + yesno(obj->import_attach));
>
>81 here, but anyway, ditto!
>
>...
>
>> */
>
>+blank line here?
>
>> +#include <linux/string_helpers.h>
>> +
>> #include "aux.h"
>> #include "pad.h"
>
>...
>
>> seq_printf(m, "MMU: %s\n",
>> - (ident2 & V3D_HUB_IDENT2_WITH_MMU) ? "yes" : "no");
>> + yesno(ident2 & V3D_HUB_IDENT2_WITH_MMU));
>> seq_printf(m, "TFU: %s\n",
>> - (ident1 & V3D_HUB_IDENT1_WITH_TFU) ? "yes" : "no");
>> + yesno(ident1 & V3D_HUB_IDENT1_WITH_TFU));
>> seq_printf(m, "TSY: %s\n",
>> - (ident1 & V3D_HUB_IDENT1_WITH_TSY) ? "yes" : "no");
>> + yesno(ident1 & V3D_HUB_IDENT1_WITH_TSY));
>> seq_printf(m, "MSO: %s\n",
>> - (ident1 & V3D_HUB_IDENT1_WITH_MSO) ? "yes" : "no");
>> + yesno(ident1 & V3D_HUB_IDENT1_WITH_MSO));
>> seq_printf(m, "L3C: %s (%dkb)\n",
>> - (ident1 & V3D_HUB_IDENT1_WITH_L3C) ? "yes" : "no",
>> + yesno(ident1 & V3D_HUB_IDENT1_WITH_L3C),
>> V3D_GET_FIELD(ident2, V3D_HUB_IDENT2_L3C_NKB));
>
>I believe it's fine to join back to have less LOCs (yes, it will be 83 or so,
>but I believe in these cases it's very much okay).
now that we are converting to str_yes_no(), we will have a few more
chars. Some maintainers may be more strict on the 80 or 100 chars. I
will assume whatever is in the code base is the preferred form.
thanks
Lucas De Marchi
>
>--
>With Best Regards,
>Andy Shevchenko
>
>
Powered by blists - more mailing lists