All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>
To: "jic23@kernel.org" <jic23@kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Cc: "Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH 0/7] iio: light: clean out of_match_ptr and tidy headers
Date: Mon, 20 Apr 2020 06:22:09 +0000	[thread overview]
Message-ID: <03f6eb6e7cf61c6dfd8bcd9aeaaf6977cb095191.camel@analog.com> (raw)
In-Reply-To: <beff54a412caddaaa7facbc2df2ddf939668fc44.camel@analog.com>

On Mon, 2020-04-20 at 06:04 +0000, Ardelean, Alexandru wrote:
> [External]
> 
> On Sun, 2020-04-19 at 16:01 +0100, jic23@kernel.org wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > 
> > Hi All,
> > 
> > Given we keep having to explain to people that of_match_ptr is less
> > than ideal now we have the option of ACPI DSDT using PRP0001 and
> > the compatible, it seems sensible to reduce the number of instances
> > that people might copy for a new driver.
> > 
> > Added theoretical benefit is that we can probe all these drivers from
> > appropriate DSDT (though I doubt anyone will).
> > 
> > I'm sending this first set out to see if anyone has strong views against
> > doing this for at least the simple drivers that have no other device
> > tree dependence.  Obviously more work would be needed to remove
> > use of of_match_ptr from IIO completely.
> > 
> > Light sensors picked as a starting point as they tend to be simple.
> > 
> > I may do follow ups in larger blocks to avoid so many small patches
> > (or indeed flatten these into one when applying)
> 
> fwiw: i was also planning to do a sweep of these;
> well, tbh, the main intent was to target ADI drivers first and do a bigger
> conversion for them to make the slightly friendlier with ACPI; 
> 
> aside from this, i'm also noticing some bad patterns being copied from older
> drivers, when asking new people to write Linux drivers;
> i did not make a list, probably should have;
> one is 'mlock' [still] being copied; and accessing other internal fields;
> but the internal fields accessing requires a bit of a cleanup in the form of
> privatizing the fields somehow;
> 

One thing I noticed in the series.
No idea if it is needed or not; a build would tell:
   Is '#include <linux/mod_devicetable.h>' required for this change?
Most patches add it, but I don't feel it is needed; I could be wrong though.

What I noticed is that all 'linux/of.h' , 'linux/of_device.h' &
'linux/of_platform.h' include it.

> 
> > Thanks
> > 
> > Jonathan
> > 
> > Jonathan Cameron (7):
> >   iio: light: bh1780: use mod_devicetable.h and drop of_match_ptr macro
> >   iio: light: cm32181: Add mod_devicetable.h and remove of_match_ptr
> >   iio: light: cm3232: Add mod_devicetable.h include and drop
> >     of_match_ptr
> >   iio: light: gp2ap020a00f: Swap of.h for mod_devicetable.h + drop
> >     of_match_ptr
> >   iio: light: opt3001: Add mod_devicetable.h and drop use of
> >     of_match_ptr
> >   iio: light: st_uvis25: Add mod_devicetable.h and drop of_match_ptr
> >   iio: light: vl6180: swap of.h for mod_devicetable.h and drop
> >     of_match_ptr
> > 
> >  drivers/iio/light/bh1780.c        | 6 ++----
> >  drivers/iio/light/cm32181.c       | 3 ++-
> >  drivers/iio/light/cm3232.c        | 3 ++-
> >  drivers/iio/light/gp2ap020a00f.c  | 6 ++----
> >  drivers/iio/light/opt3001.c       | 3 ++-
> >  drivers/iio/light/st_uvis25_i2c.c | 3 ++-
> >  drivers/iio/light/st_uvis25_spi.c | 3 ++-
> >  drivers/iio/light/vl6180.c        | 2 +-
> >  8 files changed, 15 insertions(+), 14 deletions(-)
> > 

  reply	other threads:[~2020-04-20  6:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-19 15:01 [PATCH 0/7] iio: light: clean out of_match_ptr and tidy headers jic23
2020-04-19 15:02 ` [PATCH 1/7] iio: light: bh1780: use mod_devicetable.h and drop of_match_ptr macro jic23
2020-04-20  6:05   ` Ardelean, Alexandru
2020-04-19 15:02 ` [PATCH 2/7] iio: light: cm32181: Add mod_devicetable.h and remove of_match_ptr jic23
2020-04-20  6:05   ` Ardelean, Alexandru
2020-04-19 15:02 ` [PATCH 3/7] iio: light: cm3232: Add mod_devicetable.h include and drop of_match_ptr jic23
2020-04-20  6:05   ` Ardelean, Alexandru
2020-04-19 15:02 ` [PATCH 4/7] iio: light: gp2ap020a00f: Swap of.h for mod_devicetable.h + " jic23
2020-04-20  6:06   ` Ardelean, Alexandru
2020-04-19 15:02 ` [PATCH 5/7] iio: light: opt3001: Add mod_devicetable.h and drop use of of_match_ptr jic23
2020-04-20  6:06   ` Ardelean, Alexandru
2020-04-19 15:02 ` [PATCH 6/7] iio: light: st_uvis25: Add mod_devicetable.h and drop of_match_ptr jic23
2020-04-20  6:08   ` Ardelean, Alexandru
2020-04-19 15:02 ` [PATCH 7/7] iio: light: vl6180: swap of.h for " jic23
2020-04-20  6:19   ` Ardelean, Alexandru
2020-04-20 15:45     ` Jonathan Cameron
2020-04-21  6:58       ` Ardelean, Alexandru
2020-04-20  6:04 ` [PATCH 0/7] iio: light: clean out of_match_ptr and tidy headers Ardelean, Alexandru
2020-04-20  6:22   ` Ardelean, Alexandru [this message]
2020-04-20 15:48     ` Jonathan Cameron
2020-04-21  0:50       ` Andy Shevchenko
2020-04-25 14:49         ` Jonathan Cameron

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=03f6eb6e7cf61c6dfd8bcd9aeaaf6977cb095191.camel@analog.com \
    --to=alexandru.ardelean@analog.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@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.