All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
	"Joel Becker" <jlbec@evilplan.org>,
	"Christoph Hellwig" <hch@lst.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Kent Gibson" <warthog618@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linux-doc <linux-doc@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Bartosz Golaszewski" <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 8/8] gpio: sim: new testing module
Date: Mon, 1 Feb 2021 15:30:55 +0200	[thread overview]
Message-ID: <YBgCj3SK5J7KIOnC@smile.fi.intel.com> (raw)
In-Reply-To: <CAMRc=MfzxmE-+SSOp6HoV1i7hZ3dNgGgrQCeDjUUkbeXJFOhzw@mail.gmail.com>

On Mon, Feb 01, 2021 at 01:53:16PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 1, 2021 at 1:49 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Feb 01, 2021 at 11:59:31AM +0100, Bartosz Golaszewski wrote:
> > > On Mon, Feb 1, 2021 at 11:28 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Sat, Jan 30, 2021 at 09:37:55PM +0100, Bartosz Golaszewski wrote:
> > > > > On Fri, Jan 29, 2021 at 4:57 PM Andy Shevchenko
> > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > > On Fri, Jan 29, 2021 at 02:46:24PM +0100, Bartosz Golaszewski wrote:

...

> > > > > > > +struct gpio_sim_chip_config {
> > > > > > > +     struct config_item item;
> > > > > > > +
> > > > > > > +     /*
> > > > > > > +      * If pdev is NULL, the item is 'pending' (waiting for configuration).
> > > > > > > +      * Once the pointer is assigned, the device has been created and the
> > > > > > > +      * item is 'live'.
> > > > > > > +      */
> > > > > > > +     struct platform_device *pdev;
> > > > > >
> > > > > > Are you sure
> > > > > >
> > > > > >         struct device *dev;
> > > > > >
> > > > > > is not sufficient?
> > > > > >
> > > > >
> > > > > It may be but I really prefer those simulated devices to be on the platform bus.
> > > >
> > > > My point here is that there is no need to keep specific bus devices type,
> > > > because you may easily derive it from the struct device pointer. Basically if
> > > > you are almost using struct device in your code (seems to me the case), you
> > > > won't need to carry bus specific one and dereference it each time.
> > >
> > > But don't we need a bus to even register a device? I haven't checked
> > > in a long time but IIRC it's mandatory.
> > >
> > > Let me give you a different argument - the platform device offers a
> > > very simple API for registering devices with properties being
> > > duplicated behind the scenes etc. It seems to me that registering a
> > > bare struct device * would take more boiler-plate code for not much
> > > gain.
> >
> > Yes, I'm not objecting the platform bus choice. I'm objecting the keeping of
> > the pointer to the bus specific structure.
> >
> > There are helpers like to_platform_device() which make the bus specific
> > pointers go away from the structures and easier code when you use exactly
> > pointer to struct device rather than bus specific one.
> >
> 
> Ok I get it. We almost never dereference it though. We do it in probe,
> but there's no way around it. In sysfs callbacks we already get a
> pointer to struct device. And when unregistering the platform device,
> we need to pass it as struct platform_device anyway. I don't see any
> gain from that and would prefer to keep it as is.

It's purely trade off, if you have more *dev in use, better to use *dev, if
*pdev, then use it, although my practice shows that in most cases keeping bus
specific pointer is an overkill.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-02-01 13:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210129134624.9247-1-brgl@bgdev.pl>
     [not found] ` <20210129134624.9247-6-brgl@bgdev.pl>
     [not found]   ` <YBQw3+K/6GDPK5xa@smile.fi.intel.com>
2021-01-30 20:25     ` [PATCH 5/8] lib: bitmap: remove the 'extern' keyword from function declarations Bartosz Golaszewski
2021-02-01 10:19       ` Andy Shevchenko
     [not found] ` <20210129134624.9247-9-brgl@bgdev.pl>
     [not found]   ` <YBQwUkQz3LrG5G4i@smile.fi.intel.com>
2021-01-30 20:37     ` [PATCH 8/8] gpio: sim: new testing module Bartosz Golaszewski
2021-01-31  0:43       ` Kent Gibson
2021-02-01  8:37         ` Bartosz Golaszewski
2021-02-01 10:28       ` Andy Shevchenko
2021-02-01 10:59         ` Bartosz Golaszewski
2021-02-01 12:49           ` Andy Shevchenko
2021-02-01 12:53             ` Bartosz Golaszewski
2021-02-01 13:30               ` Andy Shevchenko [this message]
2021-01-30 21:20 ` [PATCH 0/8] gpio: implement the configfs " Uwe Kleine-König
2021-02-01  8:37   ` Bartosz Golaszewski
2021-02-01  9:24     ` Uwe Kleine-König
2021-02-01 12:50       ` 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=YBgCj3SK5J7KIOnC@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=brgl@bgdev.pl \
    --cc=corbet@lwn.net \
    --cc=geert@linux-m68k.org \
    --cc=hch@lst.de \
    --cc=jlbec@evilplan.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --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 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.