From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f68.google.com ([74.125.83.68]:35702 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128AbdAPSgt (ORCPT ); Mon, 16 Jan 2017 13:36:49 -0500 Date: Mon, 16 Jan 2017 10:36:42 -0800 From: Alison Schofield To: "Andrew F. Davis" Cc: jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iio: health: afe4403: retrieve a valid iio_dev in suspend/resume Message-ID: <20170116183639.GA2907@d830.WORKGROUP> References: <20170115035141.GA19547@d830.WORKGROUP> <9fc37bb7-0a0c-cf68-51e5-c91d096262d7@ti.com> <20170116181036.GA2739@d830.WORKGROUP> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org On Mon, Jan 16, 2017 at 12:22:03PM -0600, Andrew F. Davis wrote: > On 01/16/2017 12:10 PM, Alison Schofield wrote: > > On Mon, Jan 16, 2017 at 10:38:27AM -0600, Andrew F. Davis wrote: > >> On 01/14/2017 09:51 PM, Alison Schofield wrote: > >>> The suspend/resume functions were using dev_to_iio_dev() to get > >>> the iio_dev. That only works on IIO dev's. Replace it with spi > >>> functions to get the correct iio_dev. > >>> > >>> Signed-off-by: Alison Schofield > >> > >> Was this found with an automated tool? If not, it might be nice to have > >> a Coccinelle style check for this. Anyway for this and the afe4404 > >> version patch: > >> > >> Acked-by: Andrew F. Davis > >> > > Hi Andrew, > > > > Just caught my eye while looking at these drivers for another reason: > > they popped up in a cocci scan looking for drivers with regmap and dev > > struct in global data. The dev struct may be redundant since it > > can be retrieved from regmap. I'm going to look at that a bit further > > and send a patch if appropriate. > > > > I have seen these patches before, and I always NACK them when I can. My > stance is that just because we can find creative ways to recover > information doesn't mean we should. It doesn't and anything and it is > much more clear to me to just keep a copy of *dev to reference when > needed, rather than some round-about method of fetching it through other > entities. Thanks for the heads up...removed from queue. alisons > > > Back to dev_to_iio_dev...it's a case of history repeating itself, but > > not so often anymore. I grep'd one more that I'll patch. So, although > > it appears close to extinction, a cocci check would be great. It would > > be even more valuble if worked with a more general check of the IIO > > conversion/naming functions that are ripe for misuse. > > > > I'm not a huge fan of all these macro tricks to fetch types for this > reason here, we lose visibility into the containing types. Like here we > have a function (dev_to_iio_dev) that goes from dev to iio_dev with no > real compile time way to know if it is the *right* dev type... > > > I'll propose this as an intern task. > > > > If anyone has read this far and wants to chime in with their favorite > > misused funcs to add to the todo list...please do. > > > > thanks, > > alisons > > > >>> --- > >>> drivers/iio/health/afe4403.c | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c > >>> index 9a08146..6bb23a4 100644 > >>> --- a/drivers/iio/health/afe4403.c > >>> +++ b/drivers/iio/health/afe4403.c > >>> @@ -422,7 +422,7 @@ MODULE_DEVICE_TABLE(of, afe4403_of_match); > >>> > >>> static int __maybe_unused afe4403_suspend(struct device *dev) > >>> { > >>> - struct iio_dev *indio_dev = dev_to_iio_dev(dev); > >>> + struct iio_dev *indio_dev = spi_get_drvdata(to_spi_device(dev)); > >>> struct afe4403_data *afe = iio_priv(indio_dev); > >>> int ret; > >>> > >>> @@ -443,7 +443,7 @@ static int __maybe_unused afe4403_suspend(struct device *dev) > >>> > >>> static int __maybe_unused afe4403_resume(struct device *dev) > >>> { > >>> - struct iio_dev *indio_dev = dev_to_iio_dev(dev); > >>> + struct iio_dev *indio_dev = spi_get_drvdata(to_spi_device(dev)); > >>> struct afe4403_data *afe = iio_priv(indio_dev); > >>> int ret; > >>> > >>>