Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200824054347.3805-1-william.sung@advantech.com.tw>
 <CAHp75VeZLPR02xB2XRzec5mSBvq93XYZg56OOODxpFTPva6cXw@mail.gmail.com>
 <CAFv23QmDwcrdxEndH=mKMAomzt9kxG_f1Z6=Fd8iuuvCoY92SA@mail.gmail.com> <CAHp75Vcup9LUk0fgjW9T2FK-K5GD3=3ycPHi74Oykc8rq_tJqA@mail.gmail.com>
In-Reply-To: <CAHp75Vcup9LUk0fgjW9T2FK-K5GD3=3ycPHi74Oykc8rq_tJqA@mail.gmail.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon, 31 Aug 2020 15:47:42 +0300
Message-ID: <CAHp75VeyFTSc3AY07rFnjvXOcHt79tpRHzs_GZGALQcdqoANjA@mail.gmail.com>
Subject: Re: [PATCH] iio: dac: ad5593r: Dynamically set AD5593R channel modes
To:     AceLan Kao <acelan.kao@canonical.com>,
        Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc:     William Sung <william.sung@advantech.com.tw>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Michael Hennerich <Michael.Hennerich@analog.com>,
        Jonathan Cameron <jic23@kernel.org>,
        Hartmut Knaack <knaack.h@gmx.de>,
        Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
        linux-iio <linux-iio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Campion Kang <Campion.Kang@advantech.com.tw>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 31, 2020 at 3:45 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Aug 31, 2020 at 2:28 PM AceLan Kao <acelan.kao@canonical.com> wrote:
> > This patch is mainly for Advantech's UNO-420[1] which is a x86-based platform.
> > This platform is more like a development platform for customers to
> > customize their products,
> > so, specify the channel modes in ACPI table is not generic enough,
> > that's why William submit this patch.
> >
> > Are there other ways to specify or pass values to the module without
> > using module parameters?
> > It's good if we can leverage sysfs, but I don't know if there is one
> > for this scenario.
>
> Can we provide DT bindings for that and use then in ACPI? ACPI has a
> possibility to reuse DT properties and compatible strings [1]. As far
> as I can see the driver uses fwnode API, so it supports ACPI case
> already [2]. So, what prevents you to utilize 'adi,mode' property?
>
> Also, we accept examples of ASL excerpt in meta-acpi project [3]. It
> has already plenty of examples [4] how to use PRP0001 for DIY /
> development boards.
>
> So, take all together I think this patch is simple redundant.

One more useful link is SO answers on the topic:
https://stackoverflow.com/search?tab=newest&q=prp0001

> [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> [2]: https://elixir.bootlin.com/linux/v5.9-rc3/source/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
> [3]: https://github.com/westeri/meta-acpi
> [4]: https://github.com/westeri/meta-acpi/tree/master/recipes-bsp/acpi-tables/samples
>
> P.S. Jonathan, it seems this driver has artificial ACPI HID. We
> probably have to remove it. However, ADS is indeed reserved for Analog
> Devices in PNP registry. Can we have AD's official answer on this?
> Cc'ing additional AD people.
>
> > 1. https://www.advantech.com/products/9a0cc561-8fc2-4e22-969c-9df90a3952b5/uno-420/mod_2d6a546b-39e3-4bc4-bbf4-ac89e6b7667c

-- 
With Best Regards,
Andy Shevchenko