ASoC/soundwire: peripheral: make device name unique system-wide #4165
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In existing hardware topologies exposed with ACPI information, there is a single SoundWire Controller with up to 4 managers/links. Each SoundWire peripheral is uniquely defined with an ACPI _ADR made of a link_id followed by the MIPI 48-bit ID. If two controllers are declared in the ACPI DSDT, it's possible that name collisions occur. This would be the case for identical devices identified with exactly the same _ADR. While the _ADR is local to each controller scope, the Linux device name is the same, as a result the device_register() call in sdw_slave_add() fails due to name duplication. This patch adds the bus->id as a way to uniquify the peripheral device name at the system level. The bus->id is allocated with an IDA and already used in the device name for the Manager parent device, so that also adds consistency in the naming. This patch also adds a matching change for the Intel sof-sdw machine driver. This is intentionally added in the same patch to avoid breaking git bisect. In the Intel case, the component device name is created with ACPI information only, so the bus->id is not known. However since there is a single Controller, the bus->id and link_id are equivalent so the components can be identified by duplicating the link_id. Reported-by: Mukunda,Vijendar <vijendar.mukunda@amd.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
|
It appears that there's no strong need for this capability, thread documented here: https://lore.kernel.org/alsa-devel/cfc86e00-18c4-6971-78f8-2afb8cb28e56@amd.com/T/#u so rather than add code that no one uses I'll close this PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In existing hardware topologies exposed with ACPI information, there is a single SoundWire Controller with up to 4 managers/links. Each SoundWire peripheral is uniquely defined with an ACPI _ADR made of a link_id followed by the MIPI 48-bit ID.
If two controllers are declared in the ACPI DSDT, it's possible that name collisions occur. This would be the case for identical devices identified with exactly the same _ADR. While the _ADR is local to each controller scope, the Linux device name is the same, as a result the device_register() call in sdw_slave_add() fails due to name duplication.
This patch adds the bus->id as a way to uniquify the peripheral device name at the system level. The bus->id is allocated with an IDA and already used in the device name for the Manager parent device, so that also adds consistency in the naming.
This patch also adds a matching change for the Intel sof-sdw machine driver. This is intentionally added in the same patch to avoid breaking git bisect. In the Intel case, the component device name is created with ACPI information only, so the bus->id is not known. However since there is a single Controller, the bus->id and link_id are equivalent so the components can be identified by duplicating the link_id.
Reported-by: Mukunda,Vijendar vijendar.mukunda@amd.com
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com