[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YL3grTQ00lFCXyCp@smile.fi.intel.com>
Date: Mon, 7 Jun 2021 12:02:37 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Cc: Flavio Suligoi <f.suligoi@...m.it>,
Thierry Reding <thierry.reding@...il.com>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pwm@...r.kernel.org, linux-acpi@...r.kernel.org,
Jonathan Corbet <corbet@....net>,
Lee Jones <lee.jones@...aro.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>
Subject: Re: [PATCH v2 2/7] pwm: core: Always require PWM flags to be provided
On Sun, Jun 06, 2021 at 11:30:54PM +0200, Uwe Kleine-König wrote:
> Hello Andy,
>
> On Mon, May 31, 2021 at 10:49:42PM +0300, Andy Shevchenko wrote:
> > It makes little sense to make PWM flags optional since in case
> > of multi-channel consumer the flags can be optional only for
> > the last listed channel.
>
> I think the same holds true for dt references.
Can you elaborate this? I haven't got what you are talking about, not a DT
expert here.
> > Thus always require PWM flags to be provided.
>
> I'm not sure I want to follow that conclusion. Most consumers only need
> a single PWM and then not providing flags is fine, isn't it? Or does
> this change fix an error?
The current ACPI DSD implementation in the Linux kernel doesn't allow to use
variadic arguments in the list of tuples.
So, the current code states that we may use (x, y, z) or (x, y, z, t).
That's true as long as that is the last tuple in the array (*). However,
the case (x1, y1, z1, x2, y2, z2, t2) is not supported. It can be either
(x1, y1, z1, t1, x2, y2, z2) or (x1, y1, z1, t1, x2, y2, z2, t2).
But this makes a little sense and Linux APIs in use and first ABI that uses
that API (GPIO) has never been designed for a such. What is allowed is to skip
tuple in a form of NULL:ifying, like (0, x2, y2, z2, t2).
*) Yes, the comments said that PWM supports only a single reference, but this
may be expanded in the future and this patch allows to do that (it's not a fix
per se, but rather a good clarification to the APIs/ABIs).
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists