linux-kernel - Re: [PATCH 2/2] soundwire: bus: Add internal slave ID and use for IRQs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b286bbf3-0da9-4e84-8d21-7720970833c3@linux.dev>
Date: Tue, 22 Apr 2025 13:50:13 +0200
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>, vkoul@...nel.org
Cc: yung-chuan.liao@...ux.intel.com, sanyog.r.kale@...el.com,
 linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
 patches@...nsource.cirrus.com
Subject: Re: [PATCH 2/2] soundwire: bus: Add internal slave ID and use for
 IRQs

On 4/22/25 12:42, Charles Keepax wrote:
> Currently the SoundWire IRQ code uses the dev_num to create an IRQ
> mapping for each slave. However, there is an issue there, the dev_num
> is only allocated when the slave enumerates on the bus and enumeration
> may happen before or after probe of the slave driver. In the case
> enumeration happens after probe of the slave driver then the IRQ
> mapping will use dev_num before it is set. This could cause multiple
> slaves to use zero as their IRQ mapping.
> 
> It is very desirable to have the IRQ mapped before the slave probe
> is called, so drivers can do resource allocation in probe as normal. To
> solve these issues add an internal ID created for each slave when it is
> probed and use that for mapping the IRQ. In the case that
> get_device_num() is not implemented this ID can also be reused for the
> dev_num.

Humm, I am missing something. Does this work in the case of spurious 'ghost' ACPI devices, which is quite common for Intel DSDT?

In this case, each 'ghost' device would be assigned a dev_num during the driver probe, but that dev_num would never be used for enumeration, would it?

Let's assume for the sake of the argument there are 16 ghost devices and only one real device that gets enumerated. How can we guarantee that the real device is enumerated with a dev_num <= 11 (the max number of devices supported on the bus)?

I see the patch add a limit during probe, so now that means the number of ACPI devices MUST be lower than 11. That doesn't sound right to me and could cause some configurations to fail. It's perfectly ok to have ghost devices and no limits on how many our BIOS colleagues decide to list.

Using a dedicated IDA for IRQ mapping looks like a good idea to me, but I don't think you can really use the same IDA for dev_num