All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jingoo Han <jingoohan1@gmail.com>,
	Lee Jones <lee@kernel.org>, Helge Deller <deller@gmx.de>
Subject: Re: [PATCH v1 1/4] backlight: hx8357: Make use of device properties
Date: Mon, 22 Jan 2024 10:35:30 +0000	[thread overview]
Message-ID: <20240122103530.GC8596@aspen.lan> (raw)
In-Reply-To: <Za0glbPfzeTjdZjn@smile.fi.intel.com>

On Sun, Jan 21, 2024 at 03:48:05PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 15, 2024 at 09:20:46AM +0100, Javier Martinez Canillas wrote:
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>
> ...
>
> > > +typedef int (*hx8357_init)(struct lcd_device *);
> >
> > This kind of typedef usage is frowned upon in the Linux coding style [0]
> > (per my understanding at least) and indeed in my opinion it makes harder
> > to grep.
> >
> > [0] https://www.kernel.org/doc/Documentation/process/coding-style.rst
>
> Thanks for pointing this out. However, this piece does _not_ clarify typedef:s
> for function pointers which I personally find a good to have.
>
> ...
>
> > > -	ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
> >
> > This is what I mean, before it was clear what was stored in match->data.
> > But after you changes, what is returned by the device_get_match_data()
> > function is opaque and you need to look at the typedef hx8357_init to
> > figure that out.
>
> The above is so ugly in my opinion, that justifies using typedef:s even
> if you are quite skeptical about them.

FWIW I was pretty skeptical about it to. Largely because the three
touchs (typedef, variable initialization, use) spread things
around a bit too much.

Can we at least name the type to make it obvious that it is a function
pointer? Something like hx8357_init_fn .


Daniel.

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-fbdev@vger.kernel.org, Jingoo Han <jingoohan1@gmail.com>,
	Helge Deller <deller@gmx.de>, Lee Jones <lee@kernel.org>,
	Javier Martinez Canillas <javierm@redhat.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/4] backlight: hx8357: Make use of device properties
Date: Mon, 22 Jan 2024 10:35:30 +0000	[thread overview]
Message-ID: <20240122103530.GC8596@aspen.lan> (raw)
In-Reply-To: <Za0glbPfzeTjdZjn@smile.fi.intel.com>

On Sun, Jan 21, 2024 at 03:48:05PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 15, 2024 at 09:20:46AM +0100, Javier Martinez Canillas wrote:
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>
> ...
>
> > > +typedef int (*hx8357_init)(struct lcd_device *);
> >
> > This kind of typedef usage is frowned upon in the Linux coding style [0]
> > (per my understanding at least) and indeed in my opinion it makes harder
> > to grep.
> >
> > [0] https://www.kernel.org/doc/Documentation/process/coding-style.rst
>
> Thanks for pointing this out. However, this piece does _not_ clarify typedef:s
> for function pointers which I personally find a good to have.
>
> ...
>
> > > -	ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
> >
> > This is what I mean, before it was clear what was stored in match->data.
> > But after you changes, what is returned by the device_get_match_data()
> > function is opaque and you need to look at the typedef hx8357_init to
> > figure that out.
>
> The above is so ugly in my opinion, that justifies using typedef:s even
> if you are quite skeptical about them.

FWIW I was pretty skeptical about it to. Largely because the three
touchs (typedef, variable initialization, use) spread things
around a bit too much.

Can we at least name the type to make it obvious that it is a function
pointer? Something like hx8357_init_fn .


Daniel.

  reply	other threads:[~2024-01-22 10:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-14 15:25 [PATCH v1 0/4] backlight: hx8357: Clean up and make OF-independent Andy Shevchenko
2024-01-14 15:25 ` Andy Shevchenko
2024-01-14 15:25 ` [PATCH v1 1/4] backlight: hx8357: Make use of device properties Andy Shevchenko
2024-01-14 15:25   ` Andy Shevchenko
2024-01-15  8:20   ` Javier Martinez Canillas
2024-01-21 13:48     ` Andy Shevchenko
2024-01-21 13:48       ` Andy Shevchenko
2024-01-22 10:35       ` Daniel Thompson [this message]
2024-01-22 10:35         ` Daniel Thompson
2024-01-24 17:19   ` Daniel Thompson
2024-01-24 17:19     ` Daniel Thompson
2024-01-28 14:38     ` Andy Shevchenko
2024-01-28 14:38       ` Andy Shevchenko
2024-01-14 15:25 ` [PATCH v1 2/4] backlight: hx8357: Move OF table closer to its consumer Andy Shevchenko
2024-01-14 15:25   ` Andy Shevchenko
2024-01-15  8:22   ` Javier Martinez Canillas
2024-01-21 13:49     ` Andy Shevchenko
2024-01-21 13:49       ` Andy Shevchenko
2024-01-22 10:43       ` Daniel Thompson
2024-01-22 10:43         ` Daniel Thompson
2024-01-24 17:21   ` Daniel Thompson
2024-01-24 17:21     ` Daniel Thompson
2024-01-14 15:25 ` [PATCH v1 3/4] backlight: hx8357: Make use of dev_err_probe() Andy Shevchenko
2024-01-14 15:25   ` Andy Shevchenko
2024-01-15  8:24   ` Javier Martinez Canillas
2024-01-24 17:24   ` Daniel Thompson
2024-01-24 17:24     ` Daniel Thompson
2024-01-14 15:25 ` [PATCH v1 4/4] backlight: hx8357: Utilise temporary variable for struct device Andy Shevchenko
2024-01-14 15:25   ` Andy Shevchenko
2024-01-15  8:27   ` Javier Martinez Canillas
2024-01-24 17:25   ` Daniel Thompson
2024-01-24 17:25     ` Daniel Thompson
2024-01-28 14:39     ` Andy Shevchenko
2024-01-28 14:39       ` Andy Shevchenko

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=20240122103530.GC8596@aspen.lan \
    --to=daniel.thompson@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=jingoohan1@gmail.com \
    --cc=lee@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.