linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alison Schofield <amsfield22@gmail.com>
To: "Andrew F. Davis" <afd@ti.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
	kgene@kernel.org, k.kozlowski@samsung.com,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/5] iio: health: afe4404: use regmap to retrieve struct device
Date: Sun, 17 Apr 2016 21:56:22 -0700	[thread overview]
Message-ID: <20160418045621.GA2835@d830.WORKGROUP> (raw)
In-Reply-To: <5713D0F8.20303@ti.com>

On Sun, Apr 17, 2016 at 01:07:52PM -0500, Andrew F. Davis wrote:
> On 04/16/2016 02:22 PM, Jonathan Cameron wrote:
> > On 10/04/16 20:07, Alison Schofield wrote:
> >> Driver includes struct regmap and struct device in its global data.
> >> Remove the struct device and use regmap API to retrieve device info.
> >>
> 
> Why? This adds nothing but more code to get dev through some
> container_of trickery when we could just keep a dev pointer in the data
> structure.
> 
> Andrew

Thanks for the review and response.  The why would be for
simplification and uniformity across IIO.

I think I see your point in general, but not sure I get your
specific concerns with these afe4403/04 drivers.

The drivers only use the device struct in probe and then
again at device remove time.  At probe, the change no
longer stores it in the global data. At remove the
regmap_get_device() func is a simple dereference to retrieve
the device struct. That's the simplification: we don't carry
that ptr in global data waiting for the opportunity to use it
at device remove.  We just find it when we need it at device
remove.  (Perhaps these devices are getting removed frequently?)

Regards,
alisons

  reply	other threads:[~2016-04-18  4:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06  5:15 [PATCH 0/9] iio: use regmap to retrieve struct device Alison Schofield
2016-04-06  5:15 ` [PATCH 1/9] iio: adc: exynos_adc: " Alison Schofield
2016-04-06  7:03   ` Marek Szyprowski
2016-04-06 20:33     ` Alison Schofield
2016-04-07  5:33       ` Marek Szyprowski
2016-04-10 13:45         ` Jonathan Cameron
2016-04-06  5:16 ` [PATCH 2/9] iio: adc: qcom-spmi-iadc: " Alison Schofield
2016-04-10 13:54   ` Jonathan Cameron
2016-04-06  5:17 ` [PATCH 3/9] iio: adc: qcom-spmi-vadc: " Alison Schofield
2016-04-10 13:55   ` Jonathan Cameron
2016-04-06  5:18 ` [PATCH 4/9] iio: accel: bmc150: " Alison Schofield
2016-04-06  5:18 ` [PATCH 5/9] iio: accel: mma7455: " Alison Schofield
2016-04-06  7:35   ` Joachim Eastwood
2016-04-10 13:51     ` Jonathan Cameron
2016-04-06  5:19 ` [PATCH 6/9] iio: accel: mxc4005: " Alison Schofield
2016-04-06  5:20 ` [PATCH 7/9] iio: health: afe4403: " Alison Schofield
2016-04-06  5:20 ` [PATCH 8/9] iio: health: afe4404: " Alison Schofield
2016-04-06  5:21 ` [PATCH 9/9] iio: gyro: bmg160_core: " Alison Schofield
2016-04-10 19:03 ` [PATCH v2 0/5] iio: " Alison Schofield
2016-04-10 19:05   ` [PATCH v2 1/5] iio: accel: bmc150: " Alison Schofield
2016-04-16 19:20     ` Jonathan Cameron
2016-04-18 12:18       ` Tirdea, Irina
2016-04-18 14:59       ` Srinivas Pandruvada
2016-04-18 19:16         ` Jonathan Cameron
2016-04-10 19:06   ` [PATCH v2 2/5] iio: accel: mxc4005: " Alison Schofield
2016-04-16 19:21     ` Jonathan Cameron
2016-04-10 19:07   ` [PATCH v2 3/5] iio: health: afe4403: " Alison Schofield
2016-04-16 19:22     ` Jonathan Cameron
2016-04-10 19:07   ` [PATCH v2 4/5] iio: health: afe4404: " Alison Schofield
2016-04-16 19:22     ` Jonathan Cameron
2016-04-17 18:07       ` Andrew F. Davis
2016-04-18  4:56         ` Alison Schofield [this message]
2016-04-18 15:53           ` Andrew F. Davis
2016-04-18 19:25             ` Jonathan Cameron
2016-04-10 19:08   ` [PATCH v2 5/5] iio: gyro: bmg160: " Alison Schofield
2016-04-16 19:24     ` Jonathan Cameron
2016-04-18 15:03       ` Srinivas Pandruvada

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=20160418045621.GA2835@d830.WORKGROUP \
    --to=amsfield22@gmail.com \
    --cc=afd@ti.com \
    --cc=jic23@kernel.org \
    --cc=k.kozlowski@samsung.com \
    --cc=kgene@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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).