Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4aae458b-6919-2999-9293-028737c9a6e1@linux.intel.com>
Date:   Wed, 17 May 2023 09:11:16 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.10.0
Subject: Re: [PATCH 08/10] pinctrl: cs42l43: Add support for the cs42l43
Content-Language: en-US
To:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Charles Keepax <ckeepax@opensource.cirrus.com>
Cc:     broonie@kernel.org, lee@kernel.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
        tglx@linutronix.de, maz@kernel.org, linus.walleij@linaro.org,
        vkoul@kernel.org, lgirdwood@gmail.com,
        yung-chuan.liao@linux.intel.com, sanyog.r.kale@intel.com,
        alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
        devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
        linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230512122838.243002-1-ckeepax@opensource.cirrus.com>
 <20230512122838.243002-9-ckeepax@opensource.cirrus.com>
 <ZF6RMqElYZVMpWRt@surfacebook>
 <20230515101350.GS68926@ediswmail.ad.cirrus.com>
 <CAHp75Vcizrucc-2KFdFNeHNrxCzz4GwX1OzZYyjPH7P9RgnKYQ@mail.gmail.com>
 <20230517101301.GV68926@ediswmail.ad.cirrus.com>
 <CAHp75VchpbiYcd2yaP1WTjX17P0hg3qON5JGAXu08aDVw6Ydkw@mail.gmail.com>
From:   Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <CAHp75VchpbiYcd2yaP1WTjX17P0hg3qON5JGAXu08aDVw6Ydkw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 5/17/23 08:59, Andy Shevchenko wrote:
> On Wed, May 17, 2023 at 1:13 PM Charles Keepax
> <ckeepax@opensource.cirrus.com> wrote:
>> On Tue, May 16, 2023 at 10:03:45PM +0300, Andy Shevchenko wrote:
>>> On Mon, May 15, 2023 at 1:13 PM Charles Keepax
>>> <ckeepax@opensource.cirrus.com> wrote:
>>>> On Fri, May 12, 2023 at 10:19:14PM +0300, andy.shevchenko@gmail.com wrote:
>>>>> Fri, May 12, 2023 at 01:28:36PM +0100, Charles Keepax kirjoitti:
>>>>>> +   if (!of_property_read_bool(dev_of_node(cs42l43->dev), "gpio-ranges")) {
>>>>>> +           ret = gpiochip_add_pin_range(&priv->gpio_chip, priv->gpio_chip.label,
>>>>>> +                                        0, 0, CS42L43_NUM_GPIOS);
>>>>>> +           if (ret) {
>>>>>> +                   dev_err(priv->dev, "Failed to add GPIO pin range: %d\n", ret);
>>>>>> +                   goto err_pm;
>>>>>> +           }
>>>>>> +   }
>>>>>
>>>>> Besides the fact that we have a callback for this, why GPIO library can't
>>>>> handle this for you already?
>>>>
>>>> Apologies but I am not quite sure I follow you, in the device
>>>> tree case this will be handled by the GPIO library. But for ACPI
>>>> this information does not exist so has to be called manually, the
>>>> library does not necessarily know which values to call with,
>>>> although admittedly our case is trivial but not all are.
>>>
>>> Why can't the firmware provide this information? _DSD() is a part of
>>> ACPI v5.1 IIRC.
>>
>> I am very very far from confident we can guarantee that will be
>> present in the ACPI. The ACPI is typically made for and by the
>> Windows side.
> 
> Why? You may insist firmware vendors / OEMs to use that as a
> requirement to the platforms that would like to use your chip. The
> _DSD() is part of the specification, I don't see how the above can be
> an argument.
> 
> The times when ACPI == Windows are quite behind.

This is one of those Yogi Berra-isms: In theory, there is no difference
between theory and practice. In practice there is.

DSD is not really used indeed for audio devices. Even for SoundWire
where we inked the requirement to use DSD in a MIPI standardization
document, the only _DSD properties are for the manager side, the
peripheral side information is not populated or mostly
useless/incorrect. Most codec drivers hard-code the properties that were
intended to be set in the DSDT.

Unless there is firm evidence that the firmware does provide the
required DSD properties we can assume it does not. We can't force the
ecosystem to use DSD, even if it makes sense. it's frustrating but it is
what it is.