From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
"Rob Herring" <robh+dt@kernel.org>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>
Subject: Re: [PATCH v3 1/3] iio: dac: add support for ltc2688
Date: Sat, 5 Feb 2022 18:44:59 +0000 [thread overview]
Message-ID: <20220205184459.7aa8e5d5@jic23-huawei> (raw)
In-Reply-To: <Yf60A1UkbBtQ68qv@smile.fi.intel.com>
On Sat, 5 Feb 2022 19:29:39 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
A few comments from me, mostly because I couldn't resist jumping in ;)
Note this is only some of the things Andy raised....
Jonathan
>
> > + if (private == LTC2688_INPUT_B_AVAIL)
> > + return sysfs_emit(buf, "[%u %u %u]\n", ltc2688_raw_range[0],
> > + ltc2688_raw_range[1],
> > + ltc2688_raw_range[2] / 4);
>
> Is it standard form "[A B C]" for ranges in IIO? I haven't looked into the code
> deeply (and datasheet at all) to understand meaning. To me range is usually out
> of two numbers.
https://elixir.bootlin.com/linux/latest/source/Documentation/ABI/testing/sysfs-bus-iio#L105
Yes, [Min Step Max]
>
> > + if (private == LTC2688_DITHER_OFF)
> > + return sysfs_emit(buf, "0\n");
>
> > + ret = ltc2688_dac_code_read(st, chan->channel, private, &val);
> > + if (ret)
> > + return ret;
> > +
> > + return sysfs_emit(buf, "%u\n", val);
>
> These three types of output for one sysfs node? Seems it's not align with the
> idea behind sysfs. It maybe that I missed something.
Different sysfs nodes. Though it's a fair question on whether this would be
better done as a bunch of separate callbacks, rather than one with a lookup
on the private parameter.
>
> > +static int ltc2688_tgp_clk_setup(struct ltc2688_state *st,
> > + struct ltc2688_chan *chan,
> > + struct device_node *np, int tgp)
> > +{
> > + unsigned long rate;
> > + struct clk *clk;
> > + int ret, f;
> > +
> > + clk = devm_get_clk_from_child(&st->spi->dev, np, NULL);
> > + if (IS_ERR(clk))
>
> Make it optional for non-OF, can be done as easy as
>
> if (IS_ERR(clk)) {
> if (PTR_ERR(clk) == -ENOENT)
> clk = NULL;
> else
> return dev_err_probe(...);
> }
Interesting. We should probably look at where else this
is appropriate.
>
> > + return dev_err_probe(&st->spi->dev, PTR_ERR(clk),
> > + "failed to get tgp clk.\n");
> > +
> > + ret = clk_prepare_enable(clk);
> > + if (ret)
> > + return dev_err_probe(&st->spi->dev, ret,
> > + "failed to enable tgp clk.\n");
> > +
> > + ret = devm_add_action_or_reset(&st->spi->dev, ltc2688_clk_disable, clk);
> > + if (ret)
> > + return ret;
> > +
> > + if (chan->toggle_chan)
> > + return 0;
> > +
> > + /* calculate available dither frequencies */
> > + rate = clk_get_rate(clk);
> > + for (f = 0; f < ARRAY_SIZE(chan->dither_frequency); f++)
> > + chan->dither_frequency[f] = DIV_ROUND_CLOSEST(rate, ltc2688_period[f]);
> > +
> > + return 0;
> > +}
>
> ...
>
> > +static int ltc2688_channel_config(struct ltc2688_state *st)
> > +{
> > + struct device *dev = &st->spi->dev;
> > + struct device_node *child;
> > + u32 reg, clk_input, val, tmp[2];
> > + int ret, span;
> > +
> > + for_each_available_child_of_node(dev->of_node, child) {
>
> device_for_each_child_node()
This is the old issue with missing
device_for_each_available_child_node()
though can just add a check on whether it's available inside the loop.
>
> > + struct ltc2688_chan *chan;
> > +
...
next prev parent reply other threads:[~2022-02-05 18:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-21 14:24 [PATCH v3 0/3] Add support for LTC2688 Nuno Sá
2022-01-21 14:24 ` [PATCH v3 1/3] iio: dac: add support for ltc2688 Nuno Sá
2022-02-05 17:29 ` Andy Shevchenko
2022-02-05 18:44 ` Jonathan Cameron [this message]
2022-02-05 18:50 ` Andy Shevchenko
2022-02-05 18:58 ` Andy Shevchenko
2022-02-06 15:16 ` Jonathan Cameron
2022-02-07 10:52 ` Andy Shevchenko
2022-02-06 13:19 ` Sa, Nuno
2022-02-07 11:09 ` Andy Shevchenko
2022-02-07 20:19 ` Nuno Sá
2022-02-14 13:23 ` Nuno Sá
2022-02-14 13:50 ` Andy Shevchenko
2022-02-18 13:40 ` Nuno Sá
2022-02-14 13:49 ` Andy Shevchenko
2022-02-18 13:51 ` Nuno Sá
2022-02-18 16:03 ` Jonathan Cameron
2022-02-20 11:32 ` Andy Shevchenko
2022-02-21 12:48 ` Nuno Sá
2022-02-21 17:04 ` Andy Shevchenko
2022-02-21 17:30 ` Jonathan Cameron
2022-02-21 18:49 ` Andy Shevchenko
2022-02-22 16:21 ` Jonathan Cameron
2022-02-19 12:57 ` Nuno Sá
2022-01-21 14:25 ` [PATCH v3 2/3] iio: ABI: add ABI file for the LTC2688 DAC Nuno Sá
2022-02-05 16:25 ` Andy Shevchenko
2022-01-21 14:25 ` [PATCH v3 3/3] dt-bindings: iio: Add ltc2688 documentation Nuno Sá
2022-02-05 2:28 ` Rob Herring
2022-01-22 17:27 ` [PATCH v3 0/3] Add support for LTC2688 Jonathan Cameron
2022-02-05 16:24 ` Andy Shevchenko
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=20220205184459.7aa8e5d5@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=andriy.shevchenko@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh+dt@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 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).