All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Emma Anholt" <emma@anholt.net>,
	"David Airlie" <airlied@linux.ie>,
	nouveau@lists.freedesktop.org,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Vishal Kulkarni" <vishal@chelsio.com>,
	"Francis Laniel" <laniel_francis@privacyrequired.com>,
	"Kentaro Takeda" <takedakn@nttdata.co.jp>,
	amd-gfx@lists.freedesktop.org, "Ben Skeggs" <bskeggs@redhat.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Petr Mladek" <pmladek@suse.com>,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Leo Li" <sunpeng.li@amd.com>,
	intel-gfx@lists.freedesktop.org,
	"Raju Rangoju" <rajur@chelsio.com>,
	"Julia Lawall" <julia.lawall@lip6.fr>,
	"Rahul Lakkireddy" <rahul.lakkireddy@chelsio.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"Christian König" <christian.koenig@amd.com>,
	"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>,
	linux-security-module@vger.kernel.org, netdev@vger.kernel.org,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH 3/3] drm: Convert open yes/no strings to yesno()
Date: Wed, 26 Jan 2022 01:05:27 -0800	[thread overview]
Message-ID: <20220126090527.ksuah5m6xctx7jjo@ldmartin-desk2> (raw)
In-Reply-To: <Yehm5/DJ5Ljo1EWs@smile.fi.intel.com>

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
>
>

WARNING: multiple messages have this Message-ID (diff)
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Emma Anholt" <emma@anholt.net>,
	"David Airlie" <airlied@linux.ie>,
	nouveau@lists.freedesktop.org,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Vishal Kulkarni" <vishal@chelsio.com>,
	netdev@vger.kernel.org,
	"Francis Laniel" <laniel_francis@privacyrequired.com>,
	"Kentaro Takeda" <takedakn@nttdata.co.jp>,
	amd-gfx@lists.freedesktop.org, "Ben Skeggs" <bskeggs@redhat.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Petr Mladek" <pmladek@suse.com>, "Leo Li" <sunpeng.li@amd.com>,
	intel-gfx@lists.freedesktop.org,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Julia Lawall" <julia.lawall@lip6.fr>,
	"Rahul Lakkireddy" <rahul.lakkireddy@chelsio.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>,
	"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>,
	linux-security-module@vger.kernel.org,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Raju Rangoju" <rajur@chelsio.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 3/3] drm: Convert open yes/no strings to yesno()
Date: Wed, 26 Jan 2022 01:05:27 -0800	[thread overview]
Message-ID: <20220126090527.ksuah5m6xctx7jjo@ldmartin-desk2> (raw)
In-Reply-To: <Yehm5/DJ5Ljo1EWs@smile.fi.intel.com>

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
>
>

WARNING: multiple messages have this Message-ID (diff)
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Emma Anholt" <emma@anholt.net>,
	"David Airlie" <airlied@linux.ie>,
	nouveau@lists.freedesktop.org,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Vishal Kulkarni" <vishal@chelsio.com>,
	netdev@vger.kernel.org,
	"Francis Laniel" <laniel_francis@privacyrequired.com>,
	"Kentaro Takeda" <takedakn@nttdata.co.jp>,
	amd-gfx@lists.freedesktop.org, "Ben Skeggs" <bskeggs@redhat.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Petr Mladek" <pmladek@suse.com>, "Leo Li" <sunpeng.li@amd.com>,
	intel-gfx@lists.freedesktop.org,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Julia Lawall" <julia.lawall@lip6.fr>,
	"Rahul Lakkireddy" <rahul.lakkireddy@chelsio.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>,
	"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>,
	linux-security-module@vger.kernel.org,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Raju Rangoju" <rajur@chelsio.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH 3/3] drm: Convert open yes/no strings to yesno()
Date: Wed, 26 Jan 2022 01:05:27 -0800	[thread overview]
Message-ID: <20220126090527.ksuah5m6xctx7jjo@ldmartin-desk2> (raw)
In-Reply-To: <Yehm5/DJ5Ljo1EWs@smile.fi.intel.com>

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
>
>

WARNING: multiple messages have this Message-ID (diff)
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Emma Anholt" <emma@anholt.net>,
	"David Airlie" <airlied@linux.ie>,
	nouveau@lists.freedesktop.org,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Vishal Kulkarni" <vishal@chelsio.com>,
	netdev@vger.kernel.org,
	"Francis Laniel" <laniel_francis@privacyrequired.com>,
	"Kentaro Takeda" <takedakn@nttdata.co.jp>,
	amd-gfx@lists.freedesktop.org, "Ben Skeggs" <bskeggs@redhat.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Petr Mladek" <pmladek@suse.com>, "Leo Li" <sunpeng.li@amd.com>,
	intel-gfx@lists.freedesktop.org,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Julia Lawall" <julia.lawall@lip6.fr>,
	"Rahul Lakkireddy" <rahul.lakkireddy@chelsio.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>,
	"Sergey Senozhatsky" <sergey.senozhatsky@gmail.com>,
	linux-security-module@vger.kernel.org,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Raju Rangoju" <rajur@chelsio.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Nouveau] [PATCH 3/3] drm: Convert open yes/no strings to yesno()
Date: Wed, 26 Jan 2022 01:05:27 -0800	[thread overview]
Message-ID: <20220126090527.ksuah5m6xctx7jjo@ldmartin-desk2> (raw)
In-Reply-To: <Yehm5/DJ5Ljo1EWs@smile.fi.intel.com>

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
>
>

  reply	other threads:[~2022-01-26  9:05 UTC|newest]

Thread overview: 160+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19  7:24 [PATCH 0/3] lib/string_helpers: Add a few string helpers Lucas De Marchi
2022-01-19  7:24 ` [Nouveau] " Lucas De Marchi
2022-01-19  7:24 ` Lucas De Marchi
2022-01-19  7:24 ` [Intel-gfx] " Lucas De Marchi
2022-01-19  7:24 ` Lucas De Marchi
2022-01-19  7:24 ` [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation Lucas De Marchi
2022-01-19  7:24   ` [Nouveau] " Lucas De Marchi
2022-01-19  7:24   ` Lucas De Marchi
2022-01-19  7:24   ` [Intel-gfx] " Lucas De Marchi
2022-01-19  7:24   ` Lucas De Marchi
2022-01-19  9:15   ` [Nouveau] " Andy Shevchenko
2022-01-19  9:15     ` Andy Shevchenko
2022-01-19  9:15     ` [Intel-gfx] " Andy Shevchenko
2022-01-19  9:15     ` Andy Shevchenko
2022-01-19 15:01     ` Steven Rostedt
2022-01-19 15:01       ` Steven Rostedt
2022-01-19 15:01       ` [Intel-gfx] " Steven Rostedt
2022-01-19 15:01       ` Steven Rostedt
2022-01-19 15:01       ` [Nouveau] " Steven Rostedt
2022-01-19 16:37       ` David Laight
2022-01-19 16:37         ` David Laight
2022-01-19 16:37         ` [Intel-gfx] " David Laight
2022-01-19 16:37         ` David Laight
2022-01-19 16:37         ` [Nouveau] " David Laight
2022-01-19 16:38         ` David Laight
2022-01-19 16:38           ` [Nouveau] " David Laight
2022-01-19 16:38           ` David Laight
2022-01-19 16:38           ` [Intel-gfx] " David Laight
2022-01-19 16:38           ` David Laight
2022-01-19 19:22           ` Andy Shevchenko
2022-01-19 19:22             ` Andy Shevchenko
2022-01-19 19:22             ` [Intel-gfx] " Andy Shevchenko
2022-01-19 19:22             ` Andy Shevchenko
2022-01-19 19:22             ` [Nouveau] " Andy Shevchenko
2022-01-19 20:58             ` Steven Rostedt
2022-01-19 20:58               ` Steven Rostedt
2022-01-19 20:58               ` [Intel-gfx] " Steven Rostedt
2022-01-19 20:58               ` Steven Rostedt
2022-01-19 20:58               ` [Nouveau] " Steven Rostedt
2022-01-19 22:25             ` David Laight
2022-01-19 22:25               ` David Laight
2022-01-19 22:25               ` [Intel-gfx] " David Laight
2022-01-19 22:25               ` David Laight
2022-01-19 22:25               ` [Nouveau] " David Laight
2022-01-19  9:18   ` Sakari Ailus
2022-01-19  9:18     ` [Nouveau] " Sakari Ailus
2022-01-19  9:18     ` Sakari Ailus
2022-01-19  9:18     ` [Intel-gfx] " Sakari Ailus
2022-01-19  9:18     ` Sakari Ailus
2022-01-19 15:06     ` Steven Rostedt
2022-01-19 15:06       ` Steven Rostedt
2022-01-19 15:06       ` [Intel-gfx] " Steven Rostedt
2022-01-19 15:06       ` Steven Rostedt
2022-01-19 15:06       ` [Nouveau] " Steven Rostedt
2022-01-19 19:25       ` Andy Shevchenko
2022-01-19 19:25         ` Andy Shevchenko
2022-01-19 19:25         ` Andy Shevchenko
2022-01-19 19:25         ` [Intel-gfx] " Andy Shevchenko
2022-01-19 19:25         ` Andy Shevchenko
2022-01-19 21:00         ` Steven Rostedt
2022-01-19 21:00           ` Steven Rostedt
2022-01-19 21:00           ` [Intel-gfx] " Steven Rostedt
2022-01-19 21:00           ` Steven Rostedt
2022-01-19 21:00           ` [Nouveau] " Steven Rostedt
2022-01-19 21:04           ` Andy Shevchenko
2022-01-19 21:04             ` Andy Shevchenko
2022-01-19 21:04             ` [Intel-gfx] " Andy Shevchenko
2022-01-19 21:04             ` Andy Shevchenko
2022-01-19 21:04             ` [Nouveau] " Andy Shevchenko
2022-01-21  1:37           ` Joe Perches
2022-01-21  1:37             ` Joe Perches
2022-01-21  1:37             ` [Intel-gfx] " Joe Perches
2022-01-21  1:37             ` [Nouveau] " Joe Perches
2022-01-21  1:37             ` Joe Perches
2022-01-19 20:43       ` [Intel-gfx] " Lucas De Marchi
2022-01-19 20:43         ` [Nouveau] " Lucas De Marchi
2022-01-19 20:43         ` Lucas De Marchi
2022-01-19 20:43         ` Lucas De Marchi
2022-01-19  7:24 ` [PATCH 2/3] lib/string_helpers: Add helpers for enable[d]/disable[d] Lucas De Marchi
2022-01-19  7:24   ` [Nouveau] " Lucas De Marchi
2022-01-19  7:24   ` Lucas De Marchi
2022-01-19  7:24   ` [Intel-gfx] " Lucas De Marchi
2022-01-19  7:24   ` Lucas De Marchi
2022-01-19  9:20   ` [Nouveau] " Andy Shevchenko
2022-01-19  9:20     ` Andy Shevchenko
2022-01-19  9:20     ` [Intel-gfx] " Andy Shevchenko
2022-01-19  9:20     ` Andy Shevchenko
2022-01-19  9:42     ` Lucas De Marchi
2022-01-19  9:42       ` [Nouveau] " Lucas De Marchi
2022-01-19  9:42       ` [Intel-gfx] " Lucas De Marchi
2022-01-19  9:42       ` Lucas De Marchi
2022-01-19  7:24 ` [PATCH 3/3] drm: Convert open yes/no strings to yesno() Lucas De Marchi
2022-01-19  7:24   ` [Nouveau] " Lucas De Marchi
2022-01-19  7:24   ` Lucas De Marchi
2022-01-19  7:24   ` [Intel-gfx] " Lucas De Marchi
2022-01-19  7:24   ` Lucas De Marchi
2022-01-19 19:30   ` Andy Shevchenko
2022-01-19 19:30     ` Andy Shevchenko
2022-01-19 19:30     ` [Intel-gfx] " Andy Shevchenko
2022-01-19 19:30     ` Andy Shevchenko
2022-01-19 19:30     ` [Nouveau] " Andy Shevchenko
2022-01-26  9:05     ` Lucas De Marchi [this message]
2022-01-26  9:05       ` Lucas De Marchi
2022-01-26  9:05       ` [Intel-gfx] " Lucas De Marchi
2022-01-26  9:05       ` Lucas De Marchi
2022-01-19  7:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for lib/string_helpers: Add a few string helpers Patchwork
2022-01-19  7:37 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-19  8:02 ` [Nouveau] [PATCH 0/3] " Jani Nikula
2022-01-19  8:02   ` Jani Nikula
2022-01-19  8:02   ` [Intel-gfx] " Jani Nikula
2022-01-19  8:02   ` Jani Nikula
2022-01-19  8:02   ` Jani Nikula
2022-01-19  8:05 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-01-19  9:28 ` [Nouveau] [PATCH 0/3] " Andy Shevchenko
2022-01-19  9:28   ` Andy Shevchenko
2022-01-19  9:28   ` [Intel-gfx] " Andy Shevchenko
2022-01-19  9:28   ` Andy Shevchenko
2022-01-19  9:39 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork
2022-01-19 13:18 ` [PATCH 0/3] " Petr Mladek
2022-01-19 13:18   ` [Nouveau] " Petr Mladek
2022-01-19 13:18   ` Petr Mladek
2022-01-19 13:18   ` [Intel-gfx] " Petr Mladek
2022-01-19 13:18   ` Petr Mladek
2022-01-19 14:16   ` Jani Nikula
2022-01-19 14:16     ` Jani Nikula
2022-01-19 14:16     ` [Intel-gfx] " Jani Nikula
2022-01-19 14:16     ` Jani Nikula
2022-01-19 14:16     ` [Nouveau] " Jani Nikula
2022-01-19 16:15     ` Daniel Vetter
2022-01-19 16:15       ` Daniel Vetter
2022-01-19 16:15       ` [Intel-gfx] " Daniel Vetter
2022-01-19 16:15       ` Daniel Vetter
2022-01-19 16:15       ` [Nouveau] " Daniel Vetter
2022-01-19 20:53       ` [Intel-gfx] " Lucas De Marchi
2022-01-19 20:53         ` [Nouveau] " Lucas De Marchi
2022-01-19 21:07         ` Andy Shevchenko
2022-01-19 21:07           ` Andy Shevchenko
2022-01-19 21:07           ` Andy Shevchenko
2022-01-19 21:07           ` Andy Shevchenko
2022-01-19 21:07           ` [Nouveau] " Andy Shevchenko
2022-01-20  8:38     ` Petr Mladek
2022-01-20  8:38       ` [Nouveau] " Petr Mladek
2022-01-20  8:38       ` Petr Mladek
2022-01-20  8:38       ` [Intel-gfx] " Petr Mladek
2022-01-20  8:38       ` Petr Mladek
2022-01-20  9:12       ` David Laight
2022-01-20  9:12         ` David Laight
2022-01-20  9:12         ` [Intel-gfx] " David Laight
2022-01-20  9:12         ` David Laight
2022-01-20  9:12         ` [Nouveau] " David Laight
2022-01-20  9:12       ` Jani Nikula
2022-01-20  9:12         ` Jani Nikula
2022-01-20  9:12         ` [Intel-gfx] " Jani Nikula
2022-01-20  9:12         ` Jani Nikula
2022-01-20  9:12         ` [Nouveau] " Jani Nikula
2022-01-20 10:45         ` Petr Mladek
2022-01-20 10:45           ` Petr Mladek
2022-01-20 10:45           ` [Nouveau] " Petr Mladek
2022-01-20 10:45           ` [Intel-gfx] " Petr Mladek
2022-01-20 10:45           ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220126090527.ksuah5m6xctx7jjo@ldmartin-desk2 \
    --to=lucas.demarchi@intel.com \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bskeggs@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=christian.koenig@amd.com \
    --cc=davem@davemloft.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=julia.lawall@lip6.fr \
    --cc=kuba@kernel.org \
    --cc=laniel_francis@privacyrequired.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=netdev@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=pmladek@suse.com \
    --cc=rahul.lakkireddy@chelsio.com \
    --cc=rajur@chelsio.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sunpeng.li@amd.com \
    --cc=takedakn@nttdata.co.jp \
    --cc=vishal@chelsio.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.