From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E333C4743F for ; Mon, 7 Jun 2021 11:49:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ED2CD611AD for ; Mon, 7 Jun 2021 11:49:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230237AbhFGLu6 (ORCPT ); Mon, 7 Jun 2021 07:50:58 -0400 Received: from mga06.intel.com ([134.134.136.31]:47165 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231283AbhFGLu6 (ORCPT ); Mon, 7 Jun 2021 07:50:58 -0400 IronPort-SDR: wZgmnU9c3Jj/iwFIBNdjyA+3lOM3UpCHFqxlCpz1zYn9eGyXqJ8azfV6rzO1FA+xKYrPZ3jihU 9T+V2xp9Lrow== X-IronPort-AV: E=McAfee;i="6200,9189,10007"; a="265761217" X-IronPort-AV: E=Sophos;i="5.83,255,1616482800"; d="scan'208";a="265761217" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2021 04:49:06 -0700 IronPort-SDR: u17BKXvx/hUR46TzWYEH1/SrBnug8cLVNtgUOpARTkwSnngROQ/OLo6pqeQujI435LdHyJ1dTj ScM475RMOI1A== X-IronPort-AV: E=Sophos;i="5.83,255,1616482800"; d="scan'208";a="484747647" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2021 04:49:03 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lqDkb-000FDV-3n; Mon, 07 Jun 2021 14:49:01 +0300 Date: Mon, 7 Jun 2021 14:49:01 +0300 From: Andy Shevchenko To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: Flavio Suligoi , Thierry Reding , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, linux-acpi@vger.kernel.org, Jonathan Corbet , Lee Jones , "Rafael J. Wysocki" , Len Brown Subject: Re: [PATCH v2 2/7] pwm: core: Always require PWM flags to be provided Message-ID: References: <20210531194947.10770-1-andriy.shevchenko@linux.intel.com> <20210531194947.10770-2-andriy.shevchenko@linux.intel.com> <20210606213054.bmqgs5hehbowa62d@pengutronix.de> <20210607095324.yaiu5lzb5zgoejpa@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Jun 07, 2021 at 01:21:01PM +0300, Andy Shevchenko wrote: > On Mon, Jun 07, 2021 at 01:15:20PM +0300, Andy Shevchenko wrote: > > On Mon, Jun 07, 2021 at 11:53:24AM +0200, Uwe Kleine-König wrote: > > > On Mon, Jun 07, 2021 at 12:02:37PM +0300, Andy Shevchenko wrote: > > > > On Sun, Jun 06, 2021 at 11:30:54PM +0200, Uwe Kleine-König wrote: > > > > > 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. > > > > > > Ah no, I mixed that up. While the function that parses the phandle is > > > flexible, for each pwm controller the number of arguments is fixed, so > > > > > > pwms = <&pwm1 100000 &pwm2 100000 &pwm3 1000000>; > > > > > > cannot be interpreted as 3-argument references to two PWMs. This is > > > different to ACPI (I guess, not an ACPI expert here :-) because &pwm1 > > > "knows" if it needs 1 or 2 additional parameters (#pwm-cells). > > > > It's not about ACPI, it's about "the ACPI glue layer in Linux kernel". > > Used API is a part of it and it does allow only two cases, either NULL entry > > (by having 0 as an argument) or full-length supplied tuple (in case of PWM it's > > 3, so, means 4 parameters. > > > > Let's consider examples: > > > > (0, 0, x3, y3, z3, t3) // NULL, NULL, PWM3 > > (x1, y1, z1, t1, 0, x3, y3, z3, t3) // PWM1, NULL, PWM3 > > > > So, making last parameter "flexible" will work only for the last tuple in the > > array. > > > > Read this [1] for further information. > > > > [1]: https://elixir.bootlin.com/linux/latest/source/drivers/acpi/property.c#L629 > > Hmm... I have read the actual implementation and it seems it's possible to have > flexible array, so this patch needs to be reconsidered. I was thinking more about it and what we have here is positional-dependent arguments. Either way we might end up in the same situation (when we need to parse arguments based on their positions, rather than always have them being present). So, while I won't change documentation example (to be more stricter there), I will drop this change. Also, the PWM initial state doesn't include duty cycle. Any explanations why is that? -- With Best Regards, Andy Shevchenko