linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Hugo Villeneuve <hugo@hugovil.com>
Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	conor+dt@kernel.org, jirislaby@kernel.org, jringle@gridpoint.com,
	tomasz.mon@camlingroup.com, l.perczak@camlintechnologies.com,
	linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	Hugo Villeneuve <hvilleneuve@dimonoff.com>,
	stable@vger.kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH v7 5/9] serial: sc16is7xx: fix regression with GPIO configuration
Date: Sun, 4 Jun 2023 20:29:58 +0200	[thread overview]
Message-ID: <2023060406-scarcity-clear-cc56@gregkh> (raw)
In-Reply-To: <20230604134344.73dc3cbb57d335d4a0b4b33a@hugovil.com>

On Sun, Jun 04, 2023 at 01:43:44PM -0400, Hugo Villeneuve wrote:
> Here is what I suggest to silence the warning:
> 
> 	mctrl_mask = sc16is7xx_setup_mctrl_ports(dev);
> 
> #ifdef CONFIG_GPIOLIB
> 	ret = sc16is7xx_setup_gpio_chip(dev, mctrl_mask);
> 	if (ret)
> 		goto out_thread;
> #else
> 	(void) mctrl_mask;
> #endif

Eeek,  no, please no...

First off, please don't put #ifdef in .c files if at all possible.
Secondly, that (void) craziness is just that.  Rework this to not be an
issue some other way please.

> I could also store (define new variable) mctrl_mask directly inside struct sc16is7xx_port...

Sure, that sounds best.

> > And you have a real port here, no need to pass in a "raw" struct device,
> > right?
> 
> The function operates globally on both ports (or nr_uart), not just a single port. That is why I pass the "raw" struct device, in order to extract the 
> struct sc16is7xx_port from it:
> 
>     struct sc16is7xx_port *s = dev_get_drvdata(dev);
> 
> Inside the function, I also need the "raw" struc device. If we pass a struct sc16is7xx_port to the function, then I can get the "raw" struc device with this:
> 
> static u8 sc16is7xx_setup_mctrl_ports(struct sc16is7xx_port *s)
> {
> 	struct device *dev = &s->p[0].port.dev;
> 
> But I find this more obfuscated and hard to understand than to simply pass a "raw" struct device...

You should never need a "raw" struct device for stuff (if so, something
is really odd).  Except for error messages, but that's not really a big
deal, right?

Don't pass around struct device in a driver, use the real types as you
know you have it and it saves odd casting around and it just doesn't
look safe at all to do so.

And if you have that crazy s->p.... stuff in multiple places, then
perhaps you might want to rethink the structure somehow?  Or at the very
least, write an inline function to get it when needed.

Also, meta comment, you might want to use some \n characters in your
emails, your lines are really long :)

thanks,

greg k-h

  reply	other threads:[~2023-06-04 18:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-02 15:26 [PATCH v7 0/9] serial: sc16is7xx: fix GPIO regression and rs485 improvements Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 1/9] serial: sc16is7xx: fix broken port 0 uart init Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 2/9] serial: sc16is7xx: mark IOCONTROL register as volatile Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 3/9] serial: sc16is7xx: refactor GPIO controller registration Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 4/9] dt-bindings: sc16is7xx: Add property to change GPIO function Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 5/9] serial: sc16is7xx: fix regression with GPIO configuration Hugo Villeneuve
2023-06-02 21:46   ` kernel test robot
2023-06-04  7:47   ` Greg KH
2023-06-04 11:57     ` Andy Shevchenko
2023-06-04 17:44       ` Hugo Villeneuve
2023-06-04 19:31         ` Andy Shevchenko
2023-06-05 17:53           ` Hugo Villeneuve
2023-06-20 14:08           ` Hugo Villeneuve
2023-06-20 15:18             ` Andy Shevchenko
2023-06-20 15:33               ` Hugo Villeneuve
2023-06-20 15:35                 ` Andy Shevchenko
2023-06-20 15:42                   ` Hugo Villeneuve
2023-06-20 15:45                     ` Andy Shevchenko
2023-06-20 16:16                       ` Hugo Villeneuve
2023-07-19 18:40                         ` Hugo Villeneuve
2023-07-19 19:14                           ` Greg KH
2023-07-20 19:38                             ` Greg KH
2023-07-21 15:25                               ` Hugo Villeneuve
2023-07-21 15:40                                 ` Greg KH
2023-07-21 15:46                                   ` Hugo Villeneuve
2023-06-04 17:43     ` Hugo Villeneuve
2023-06-04 18:29       ` Greg KH [this message]
2023-06-04 23:16         ` Hugo Villeneuve
2023-06-05 17:57           ` Hugo Villeneuve
2023-06-07 14:07           ` Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 6/9] serial: sc16is7xx: fix bug when first setting GPIO direction Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 7/9] serial: sc16is7xx: add call to get rs485 DT flags and properties Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 8/9] serial: sc16is7xx: add post reset delay Hugo Villeneuve
2023-06-02 15:26 ` [PATCH v7 9/9] serial: sc16is7xx: improve comments about variants Hugo Villeneuve

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=2023060406-scarcity-clear-cc56@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hugo@hugovil.com \
    --cc=hvilleneuve@dimonoff.com \
    --cc=jirislaby@kernel.org \
    --cc=jringle@gridpoint.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=l.perczak@camlintechnologies.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tomasz.mon@camlingroup.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).