public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: dmitry.torokhov@gmail.com (Dmitry Torokhov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 20/61] input: keyboard: simplify getting .drvdata
Date: Thu, 26 Apr 2018 14:23:27 -0700	[thread overview]
Message-ID: <20180426212327.GB210716@dtor-ws> (raw)
In-Reply-To: <20180426200401.lvqiy4gnchkwr4qw@ninjato>

On Thu, Apr 26, 2018 at 10:04:01PM +0200, Wolfram Sang wrote:
> Hi Dmitry,
> 
> > > We should get drvdata from struct device directly. Going via
> > > platform_device is an unneeded step back and forth.
> > 
> > I consider the fact that platform device's driver data is accessible via
> > device driver data being implementation detail that may or may not change
> 
> Isn't it actually the other way around? platform_get_drvdata() is a
> convenience function to access driver_data which is embedded in struct
> device?

I guess it depends on how you read it. I always considered it separate
because none (?) of the bus implementation assert this in comments to
XXX_get_drvdata().

> 
> > in the future, so I'd prefer keep using the proper accessors for the
> > objects we are dealing with.
> 
> Exactly. I'd just argue, the object we are dealing with, declared in the
> PM functions, is a struct device.

No, the driver does not create a generic device, it actually creates a
platform device, or i2c client, or spi, or something else. The fact that
suspend and resume routines have generic device as their argument has
more to do with the language limitation rather than reflection of true
type of the objects we are dealing with.

Thanks.

-- 
Dmitry

  reply	other threads:[~2018-04-26 21:23 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 14:05 [PATCH 00/61] tree-wide: simplify getting .drvdata Wolfram Sang
2018-04-19 14:05 ` [PATCH 01/61] ARM: plat-samsung: " Wolfram Sang
2018-04-21 17:05   ` Krzysztof Kozlowski
2018-04-19 14:05 ` [PATCH 04/61] bus: " Wolfram Sang
2018-04-26 23:29   ` Florian Fainelli
2018-04-19 14:05 ` [PATCH 05/61] clk: samsung: " Wolfram Sang
2018-04-24  7:30   ` Chanwoo Choi
2018-04-25 12:49   ` Sylwester Nawrocki
2018-05-15  9:32   ` Sylwester Nawrocki
2018-05-15 21:04     ` Stephen Boyd
2018-05-15 21:05   ` Stephen Boyd
2018-04-19 14:05 ` [PATCH 06/61] crypto: " Wolfram Sang
2018-04-20  6:07   ` Krzysztof Kozlowski
2018-04-28  8:24   ` Herbert Xu
2018-04-19 14:05 ` [PATCH 07/61] dma: " Wolfram Sang
2018-04-22  6:17   ` Vinod Koul
2018-04-22  9:14     ` Wolfram Sang
2018-04-19 14:05 ` [PATCH 10/61] gpio: " Wolfram Sang
2018-04-19 15:14   ` Grygorii Strashko
2018-04-30  9:03     ` Linus Walleij
2018-04-30  9:12       ` Wolfram Sang
2018-04-30  9:29       ` Thierry Reding
2019-03-07 20:13         ` Adam Ford
2019-03-07 20:18           ` Wolfram Sang
2019-03-07 20:53             ` Enrico Weigelt, metux IT consult
2019-03-07 20:58               ` Wolfram Sang
2019-03-19 14:31                 ` Wolfram Sang
2018-04-20  7:20   ` Michal Simek
2018-04-21 16:23     ` Wolfram Sang
2018-04-23  6:04       ` Michal Simek
2018-04-19 14:05 ` [PATCH 20/61] input: keyboard: " Wolfram Sang
2018-04-26 19:19   ` Dmitry Torokhov
2018-04-26 20:04     ` Wolfram Sang
2018-04-26 21:23       ` Dmitry Torokhov [this message]
2018-04-27 10:20         ` Wolfram Sang
2018-04-19 14:05 ` [PATCH 26/61] media: platform: exynos4-is: " Wolfram Sang
2018-05-15  9:47   ` Sylwester Nawrocki
2018-04-19 14:05 ` [PATCH 27/61] media: platform: s5p-mfc: " Wolfram Sang
2018-05-15  9:46   ` Sylwester Nawrocki
2018-04-19 14:05 ` [PATCH 28/61] mmc: host: " Wolfram Sang
2018-04-20  7:10   ` Ulf Hansson
2018-04-19 14:06 ` [PATCH 37/61] perf: " Wolfram Sang
2018-04-24 16:08   ` Will Deacon
2018-04-19 14:06 ` [PATCH 38/61] pinctrl: " Wolfram Sang
2018-04-19 14:06 ` [PATCH 43/61] pwm: " Wolfram Sang
2018-04-20  8:17   ` Nicolas Ferre
2018-04-30  9:28   ` Thierry Reding
2018-04-19 14:06 ` [PATCH 44/61] rtc: " Wolfram Sang
2018-04-20  7:24   ` Michal Simek
2018-05-03 20:09   ` Alexandre Belloni
2018-04-19 14:06 ` [PATCH 46/61] spi: " Wolfram Sang
2018-04-20  7:24   ` Michal Simek
2018-04-20 17:05   ` Applied "spi: simplify getting .drvdata" to the spi tree Mark Brown
2018-04-19 14:06 ` [PATCH 50/61] thermal: simplify getting .drvdata Wolfram Sang
2018-05-02  8:52   ` Shawn Guo
2018-05-03 12:23   ` Heiko Stuebner
2018-04-19 14:06 ` [PATCH 53/61] tty: serial: " Wolfram Sang
2018-04-19 16:23   ` Uwe Kleine-König
2018-04-20  7:23   ` Michal Simek
2018-04-20  8:46   ` Patrice CHOTARD
2018-04-19 14:06 ` [PATCH 55/61] usb: mtu3: " Wolfram Sang
2018-04-20  7:46   ` Chunfeng Yun
2018-04-19 14:06 ` [PATCH 59/61] watchdog: " Wolfram Sang
2018-04-19 20:06   ` Guenter Roeck
2018-04-20  7:23   ` Michal Simek
2018-04-19 14:06 ` [PATCH 61/61] ASoC: atmel: " Wolfram Sang
2018-04-20  8:06   ` Nicolas Ferre
2018-04-20 17:04   ` Applied "ASoC: atmel: simplify getting .drvdata" to the asoc tree Mark Brown

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=20180426212327.GB210716@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox