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.