From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: David Rhodes <drhodes@opensource.cirrus.com>,
broonie@kernel.org, robh@kernel.org,
ckeepax@opensource.cirrus.com, brian.austin@cirrus.com,
patches@opensource.cirrus.com, alsa-devel@alsa-project.org,
david.rhodes@cirrus.com
Subject: Re: [PATCH v5 1/2] ASoC: cs35l41: CS35L41 Boosted Smart Amplifier
Date: Fri, 3 Sep 2021 08:58:17 -0500 [thread overview]
Message-ID: <7c38ddb4-9ccc-130d-e977-4f39b01e2c9e@linux.intel.com> (raw)
In-Reply-To: <cdabe1e9-5411-d2b6-d629-8ec87aa4c764@opensource.cirrus.com>
>> Is the ACPI probe smart enough to deal with two different drivers
>> registering for the *same* HID?
>>
>> I haven't seen any precedent, e.g. the RT6777 uses a different ACPI HID
>> for its I2C and SPI modes.
>>
>>
>
> I2C and SPI buses, when they are looking for a driver with an ID that
> matches a device declared in ACPI, will iterate over drivers that belong
> to the bus only (bus_for_each_drv()). It is not possible for an I2C
> driver to be matched during SPI device enumeration or vice versa.
That's good but that use of the same HID for two different solutions is
still be problematic. On ACPI solutions, we use the HID as a key to
identify what machine driver to load, see e.g. snd_soc_acpi_find_machine().
By using the *same* HID, you will prevent that machine detection from
uniquely identifying what mode is used, and force the machine detection
to be expanded with e.g. DMI-based quirks. It's really far from ideal
for integrators. The only case where this would work with impacts on the
machine selection would be if the choice of the SPI and I2C modes had no
impact on the functionality of the device, but is this really the case?
next prev parent reply other threads:[~2021-09-03 13:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-16 22:43 [PATCH v5 0/2] Cirrus Logic CS35L41 Amplifier David Rhodes
2021-08-16 22:43 ` [PATCH v5 1/2] ASoC: cs35l41: CS35L41 Boosted Smart Amplifier David Rhodes
2021-08-16 23:41 ` Pierre-Louis Bossart
2021-09-02 23:40 ` David Rhodes
2021-09-03 13:58 ` Pierre-Louis Bossart [this message]
2021-09-03 15:02 ` Richard Fitzgerald
2021-09-03 15:09 ` Mark Brown
2021-09-03 16:02 ` Pierre-Louis Bossart
2021-08-17 9:31 ` Charles Keepax
2021-09-03 21:10 ` David Rhodes
2021-08-16 22:43 ` [PATCH v5 2/2] ASoC: cs35l41: Add bindings for CS35L41 David Rhodes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c38ddb4-9ccc-130d-e977-4f39b01e2c9e@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=brian.austin@cirrus.com \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=david.rhodes@cirrus.com \
--cc=drhodes@opensource.cirrus.com \
--cc=patches@opensource.cirrus.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.