All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: David Jander <david.jander@protonic.nl>
Cc: David Jander <david@protonic.nl>,
	Grant Likely <grant.likely@secretlab.ca>,
	linux-input@vger.kernel.org
Subject: Re: [PATCH v4 1/3] Input: gpio_keys.c: Simplify platform_device -> device casting
Date: Mon, 20 Jun 2011 01:32:06 -0700	[thread overview]
Message-ID: <20110620083205.GA23113@core.coreip.homeip.net> (raw)
In-Reply-To: <20110620085213.1e506cdd@archvile>

Hi David,

On Mon, Jun 20, 2011 at 08:52:13AM +0200, David Jander wrote:
> 
> Hi Dmitry,
> 
> On Sat, 18 Jun 2011 03:19:25 -0700
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On Tue, Jun 14, 2011 at 11:08:09AM +0200, David Jander wrote:
> > > This patch factors out the use of struct platform_device *pdev in most
> > > places.
> > > 
> > 
> > Why? We are dealing with a platform device so why would we switch to
> > generic device?
> 
> Actually, when I wrote this patch there still was a difference between
> the platform bus and the of_platform bus, and this change was necessary. There
> also were ifdefs around platform_driver_register and
> of_platform_driver_register. Now it seems this has been merged, and I am
> not sure it is necessary anymore, but I still think it simplifies the code
> quite a bit. Also, why should the driver be bus-dependent, when it doesn't
> even need a real "bus" (it talks to an abstract device through another driver,
> potentially connected to any bus), besides due to how linux views devices and
> drivers.

While there isn't real hardware bus the driver is fitted into platform
device framework and so we should use platform device API unless there
is compelling reason for using another API.

> 
> > I also think that we should not be mixing dev_get/set_drvdata() and
> > <bus>_get/set_drvdata() calls
> 
> AFAICS, we are not mixing.... it is dev_*_drvdata() only.

"Mixing" was probably not the best word. "Using API from a different
layer" would probably be better.

> 
> > but rather use appropriate bus-specific version to access data on given
> > layer.
> 
> Doesn't that make the driver much too complex? And why would that be
> necessary? The driver isn't bus-specific anymore... except for the binding and
> probing part.

Why would it make the driver more complex? Aside from a couple of
PM methods coming from the driver core and therefore operating on
"struct device *" the rest is using platform device directly.

Thanks.

-- 
Dmitry

  reply	other threads:[~2011-06-20  8:32 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14  9:08 [PATCH v4 0/3] Input: gpio_keys.c: Add support for OF and I2C GPIO chips David Jander
2011-06-14  9:08 ` [PATCH v4 1/3] Input: gpio_keys.c: Simplify platform_device -> device casting David Jander
2011-06-16 19:28   ` Grant Likely
2011-06-18 10:19   ` Dmitry Torokhov
2011-06-20  6:52     ` David Jander
2011-06-20  8:32       ` Dmitry Torokhov [this message]
2011-06-14  9:08 ` [PATCH v4 2/3] Input: gpio_keys.c: Added support for device-tree platform data David Jander
2011-06-16 19:25   ` Grant Likely
2011-06-17  8:58     ` David Jander
2011-06-17 12:54       ` Grant Likely
2011-06-23  8:24         ` Dmitry Torokhov
2011-06-23  8:55           ` David Jander
2011-06-14  9:08 ` [PATCH v4 3/3] Input: gpio_keys.c: Enable use with non-local GPIO chips David Jander
2011-06-16 19:27   ` Grant Likely
2011-06-18 10:17     ` Dmitry Torokhov
2011-06-18 13:18       ` Grant Likely
2011-06-18 14:51         ` Dmitry Torokhov
2011-06-18 15:16           ` Grant Likely
2011-06-20  7:48             ` David Jander
2011-06-20  8:45               ` Dmitry Torokhov
2011-06-20  9:33                 ` David Jander
2011-06-20 18:49                   ` Grant Likely
2011-06-20 18:13                 ` Grant Likely
2011-06-21 11:46                 ` Mark Brown
     [not found]                   ` <BANLkTikjUR_9wq_tGfomLZNdurvmEH1Jxw@mail.gmail.com>
2011-06-21 14:36                     ` David Jander
2011-06-21 17:27                     ` Mark Brown
2011-06-21 20:48                       ` Dmitry Torokhov
2011-06-21 23:02                         ` Mark Brown
2011-06-22  6:11                           ` David Jander
2011-06-22  7:00                           ` Dmitry Torokhov
2011-06-22 11:38                             ` Mark Brown
2011-06-22 14:58                               ` Grant Likely
2011-06-22 21:43                                 ` Dmitry Torokhov
2011-06-20 17:03         ` H Hartley Sweeten
2011-06-20 18:20           ` Grant Likely
2011-06-21  6:55             ` David Jander
2011-06-21  7:04               ` Grant Likely
2012-03-16  7:20   ` Dmitry Torokhov
2012-03-16  8:17     ` David Jander
2012-03-16  8:32       ` Dmitry Torokhov
2012-03-16  8:48         ` David Jander
2012-03-16 10:19           ` Ben Dooks
2012-03-16 10:18     ` Ben Dooks
2012-03-16 11:08       ` David Jander

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=20110620083205.GA23113@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=david.jander@protonic.nl \
    --cc=david@protonic.nl \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-input@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.