From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Kent Gibson <warthog618@gmail.com>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v4] gpio: sim: don't fiddle with GPIOLIB private members
Date: Mon, 11 Sep 2023 13:00:30 +0300 [thread overview]
Message-ID: <ZP7lPn5BfAJj+soP@smile.fi.intel.com> (raw)
In-Reply-To: <CAMRc=MfDOaRbgCH4OH8roLorRNYEscg1WhNFN_nDGyz9xRVWiQ@mail.gmail.com>
On Fri, Sep 08, 2023 at 02:39:28PM +0200, Bartosz Golaszewski wrote:
> On Thu, Sep 7, 2023 at 4:13 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Sep 07, 2023 at 10:27:51AM +0200, Bartosz Golaszewski wrote:
...
> > > #include <linux/completion.h>
> > > #include <linux/configfs.h>
> > > #include <linux/device.h>
> >
> > > +#include <linux/device/bus.h>
> >
> > No need, the device.h guarantees that.
>
> Wait, wasn't you the one who always suggests including headers
> directly if we're using any symbols defined in them? Like when I said
> that we don't need to include linux/notifier.h because it's already
> included in gpiolib.h and you argued the opposite? :)
>
> device_match_fwnode() is defined in linux/device/bus.h so I thought
> it's in order to include it.
Yes, but I am not radical with it, I am for a compromise when some headers
guarantee to include some others. That is the case I believe, I don't think
device.h ever will be broken to the parts that are not include each other
(too many things to change right now, if it happens, not in the feasible
future).
...
> > > +static int gpio_sim_dev_match_fwnode(struct device *dev, void *data)
> > > +{
> > > + /*
> > > + * We can't pass this directly to device_find_child() due to pointer
> > > + * type mismatch.
> > > + */
> >
> > Not sure if this comment adds any value.
>
> I disagree - I would have used device_match_fwnode() as argument
> passed directly to device_find_child() but I cannot due to pointer
> type mismatch error so we need this wrapper and it's useful to say
> why.
Yes, and we have dozen(s ?) of the similar wrappers without a comment.
So, I'm still for removing it.
> > > + return device_match_fwnode(dev, data);
> > > +}
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-09-11 22:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 8:27 [PATCH v4] gpio: sim: don't fiddle with GPIOLIB private members Bartosz Golaszewski
2023-09-07 14:13 ` Andy Shevchenko
2023-09-08 12:39 ` Bartosz Golaszewski
2023-09-11 10:00 ` Andy Shevchenko [this message]
2023-09-11 10:48 ` Bartosz Golaszewski
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=ZP7lPn5BfAJj+soP@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=warthog618@gmail.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