From: "Nuno Sá" <noname.nuno@gmail.com>
To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
Jonathan Cameron <jic23@kernel.org>,
Cosmin Tanislav <cosmin.tanislav@analog.com>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Lars-Peter Clausen <lars@metafoo.de>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: run-time change of configuration of ad74412
Date: Fri, 02 Dec 2022 15:39:32 +0100 [thread overview]
Message-ID: <0833ed443220263ce068f5faec33fdef4435226a.camel@gmail.com> (raw)
In-Reply-To: <b9e4c447-6bd0-9450-7410-6fb0b872dd36@prevas.dk>
On Fri, 2022-12-02 at 12:16 +0100, Rasmus Villemoes wrote:
> Hi,
>
> My customer wants to be able to change the configuration of the four
> channels of the ad74412 at run-time; their board can be used in
> various
> scenarios, and having to specify the functions in device tree is too
> inflexible.
>
> Is there any precedent in other iio drivers for such a configuration
> change, and/or is it feasible to implement this in the ad74413r.c
> driver?
>
> I do not need to be able to change it continuously, just once after
> userspace has come up and before anything actually starts making use
> of
> the device, but it is not possible for me to know the correct
> configuration in the bootloader, so having U-Boot patch the dtb is
> not
> an option. A somewhat hacky way would be to build the driver as a
> module, and allow module parameter(s) to overrule whatever is in
> devicetree, but that doesn't really work if there was more than one
> ad74412/ad74413 present, unless one invents and parses some weird
> syntax
> to have certain settings apply to $this-chipselect on $that-bus.
>
> Rasmus
Hi Rasmus,
I did not looked too deep into this but from what you described it
sounds like a nasty hack that I'm not sure if it's feasable... Would
devicetree overlays be an option for you? Some userspace daemon could
decide which one to load depending on the usecase?
- Nuno Sá
next prev parent reply other threads:[~2022-12-02 14:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 11:16 run-time change of configuration of ad74412 Rasmus Villemoes
2022-12-02 14:39 ` Nuno Sá [this message]
2022-12-08 13:33 ` [POC] iio: ad74413: allow channel configuration to be given via module parameters Rasmus Villemoes
2022-12-09 8:46 ` Tanislav, Cosmin
2022-12-11 12:00 ` 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=0833ed443220263ce068f5faec33fdef4435226a.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=cosmin.tanislav@analog.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=rasmus.villemoes@prevas.dk \
/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).