RE: [PATCH] iio: dac: ad5593r: Dynamically set AD5593R channel modes

[Hennerich, Michael]

> -----Original Message-----
> From: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
> Sent: Montag, 31. August 2020 14:46
> To: AceLan Kao <acelan.kao@xxxxxxxxxxxxx>; Ardelean, Alexandru
> <alexandru.Ardelean@xxxxxxxxxx>
> Cc: William Sung <william.sung@xxxxxxxxxxxxxxxx>; Lars-Peter Clausen
> <lars@xxxxxxxxxx>; Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>;
> Jonathan Cameron <jic23@xxxxxxxxxx>; Hartmut Knaack <knaack.h@xxxxxx>;
> Peter Meerwald-Stadler <pmeerw@xxxxxxxxxx>; linux-iio <linux-
> iio@xxxxxxxxxxxxxxx>; Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>;
> Campion Kang <Campion.Kang@xxxxxxxxxxxxxxxx>
> Subject: Re: [PATCH] iio: dac: ad5593r: Dynamically set AD5593R channel
> modes
> 
> On Mon, Aug 31, 2020 at 2:28 PM AceLan Kao <acelan.kao@xxxxxxxxxxxxx>
> 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.
> 
> [1]:
> https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/firmwar
> e-guide/acpi/enumeration.html*device-tree-namespace-link-device-
> id__;Iw!!A3Ni8CS0y2Y!oe0bVwE-
> D8Y6QiWYU06pwxclGSgFpFQ10Rdozy5pCKZYmQ3SvTvEn8OyjaL1efojRqroyg$
> [2]: https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.9-
> rc3/source/Documentation/devicetree/bindings/iio/dac/ad5592r.txt__;!!A3Ni8
> CS0y2Y!oe0bVwE-
> D8Y6QiWYU06pwxclGSgFpFQ10Rdozy5pCKZYmQ3SvTvEn8OyjaL1efr_TTE4CQ
> $
> [3]: https://urldefense.com/v3/__https://github.com/westeri/meta-
> acpi__;!!A3Ni8CS0y2Y!oe0bVwE-
> D8Y6QiWYU06pwxclGSgFpFQ10Rdozy5pCKZYmQ3SvTvEn8OyjaL1efpZnQjgBg
> $
> [4]: https://urldefense.com/v3/__https://github.com/westeri/meta-
> acpi/tree/master/recipes-bsp/acpi-tables/samples__;!!A3Ni8CS0y2Y!oe0bVwE-
> D8Y6QiWYU06pwxclGSgFpFQ10Rdozy5pCKZYmQ3SvTvEn8OyjaL1efqpzDeR7A
> $
> 
> 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.

Agreed, this ID was chosen under the PNP ID Vendor Space for Analog Devices Inc.
Days back, I did a quick kernel grep, and there are many drivers which use the 3-letter
PNP ID as acpi_device_id. So, I thought this being not an issue.
I'm against removing it since I know people shipping this in their ACPI tables already.

Regarding ACPI DSD customization, one way to do this is to move this into the BIOS.
This way the particular piece of HW can be customized rather than manage HW 
connections in software.

Sorry for the misformatted email reply.

> 
> > 1.
> >
> https://urldefense.com/v3/__https://www.advantech.com/products/9a0cc56
> > 1-8fc2-4e22-969c-9df90a3952b5/uno-420/mod_2d6a546b-39e3-4bc4-
> bbf4-ac89
> > e6b7667c__;!!A3Ni8CS0y2Y!oe0bVwE-
> D8Y6QiWYU06pwxclGSgFpFQ10Rdozy5pCKZYm
> > Q3SvTvEn8OyjaL1efp-eZqbcQ$
> 
> 
> --
> With Best Regards,
> Andy Shevchenko

Best Regards,
Michael

Analog Devices GmbH
Michael Hennerich                       
Otl-Aicher Strasse 60-64
D-80807 Muenchen; Germany
mail: michael.hennerich@xxxxxxxxxx
http://www.analog.com

Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Stefan Steyerl, Thomas Edward Cribben, Michael Paul Sondel