[PATCH v1 1/1] auxdisplay: charlcd: Drop unneeded terminator entry

[PATCH v1 1/1] auxdisplay: charlcd: Drop unneeded terminator entry

[Andy Shevchenko]

Besides 0 not being, strictly speaking, a pointer it's redundant after
the actual terminator NULL entry. Drop the former for good.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/auxdisplay/charlcd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c
index 24fd6f369ebe..e9bc5fb4da28 100644
--- a/drivers/auxdisplay/charlcd.c
+++ b/drivers/auxdisplay/charlcd.c
@@ -638,8 +638,7 @@ static int panel_notify_sys(struct notifier_block *this, unsigned long code,
 
 static struct notifier_block panel_notifier = {
 	panel_notify_sys,
-	NULL,
-	0
+	NULL
 };
 
 int charlcd_register(struct charlcd *lcd)
-- 
2.30.2

Re: [PATCH v1 1/1] auxdisplay: charlcd: Drop unneeded terminator entry

[Willy Tarreau]

Hi Andy,

On Thu, Jul 15, 2021 at 04:23:10PM +0300, Andy Shevchenko wrote:
> Besides 0 not being, strictly speaking, a pointer it's redundant after
> the actual terminator NULL entry. Drop the former for good.

It seems to me that there is confusion caused by the absence of
the field names:

>  static struct notifier_block panel_notifier = {
>  	panel_notify_sys,
=> this is notifier_fn_t notifier_call

> -	NULL,
=> this is struct notifier_block __rcu *next

> -	0
=> this is int priority

> +	NULL

So all values look OK, however they're terribly confusing. wouldn't you
prefer to propose a patch to name them instead ? This would be safer,
especially if the structure evolves in the future.

Thanks!
Willy

Re: [PATCH v1 1/1] auxdisplay: charlcd: Drop unneeded terminator entry

[Andy Shevchenko]

On Thu, Jul 15, 2021 at 5:27 PM Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Jul 15, 2021 at 04:23:10PM +0300, Andy Shevchenko wrote:
> > Besides 0 not being, strictly speaking, a pointer it's redundant after
> > the actual terminator NULL entry. Drop the former for good.
>
> It seems to me that there is confusion caused by the absence of
> the field names

My gosh, you are right!
v2 on its way, thanks for review!

-- 
With Best Regards,
Andy Shevchenko