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@xxxxxxxxxxxxxxx> 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.
