All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	Alexandru Tachici <alexandru.tachici@analog.com>
Subject: Re: [PATCH 2/2] iio:adc:ad7124: Convert to fwnode handling of child node parsing.
Date: Tue, 27 Jul 2021 14:51:41 +0100	[thread overview]
Message-ID: <20210727145141.0000230d@Huawei.com> (raw)
In-Reply-To: <CAHp75VcgMkPw8BudKkF9MN2ijjDuT=VRo3FivVcjEYsEY4L-0w@mail.gmail.com>

On Sun, 25 Jul 2021 23:33:12 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Sun, Jul 25, 2021 at 8:22 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > Also use device_get_match_data() rather than of specific variant.
> > These changes enable use of this binding on ACPI platforms via PRP0001.
> > Whilst it's possible no one will ever do so, this is part of a general
> > effort to clear out examples from IIO that might be copied into new
> > drivers.
> >
> > It may appear that this change drops the check for status = disabled,
> > but in reality it does not because the of property code uses
> > of_get_next_available_child().  This driver may well fail to probe
> > if disabled is ever actually set though due to the need for
> > complete concurrent child nodes.  A future series might resolve
> > that restriction.  
> 
> Perhaps we need to have
> 
> ...
> 
> > +       device_for_each_child_node(dev, child)
> > +               st->num_channels++;
> > +  
> 
> device_get_child_node_count() ?
> 

Gah. Not sure how I missed that one when looking for it...

> ...
> 
> > -       for_each_available_child_of_node(np, child) {
> > +       device_for_each_child_node(dev, child) {  
> 
> Isn't this
>   fwnode_for_each_available_child_node()
> better to use?

Given we would be extracting the fwnode just to call this
loop, I'd say no, device version makes more sense..

> 
> ...
> 
> So the gaps I see are
>   device_get_available_child_node_count()
> and
>   device_for_each_available_child_node()

Do we then fix the fact that
device_for_each_child_node() will call the _available() form
for device tree?  That seems inconsistent currently and
I was assuming that was deliberate...

Jonathan


> 
> Both of them I think are easy to add and avoid possible breakage.
> 


  reply	other threads:[~2021-07-27 13:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-25 17:24 [PATCH 0/2] iio:adc:ad7124: Convert to generic firmware handling Jonathan Cameron
2021-07-25 17:24 ` [PATCH 1/2] iio:adc:ad7124: Parse configuration into correct local config structure Jonathan Cameron
2021-07-25 17:24 ` [PATCH 2/2] iio:adc:ad7124: Convert to fwnode handling of child node parsing Jonathan Cameron
2021-07-25 20:33   ` Andy Shevchenko
2021-07-27 13:51     ` Jonathan Cameron [this message]
2021-07-27 14:16       ` Andy Shevchenko
2021-07-27 18:20         ` Jonathan Cameron
2021-08-15 16:09           ` Jonathan Cameron
2021-10-03 15:45             ` Jonathan Cameron
2021-11-28 18:15               ` 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=20210727145141.0000230d@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=alexandru.tachici@analog.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --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.