Re: [PATCH 15/21] soundwire: amd: Avoid static port offset leak in amd_sdw_compute_params()

[Lee Jones <lee@kernel.org>]

On Fri, 30 Oct 2026, Mukunda,Vijendar wrote:

> On 10/30/26 16:16, Lee Jones wrote:
> > [You don't often get email from lee@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > amd_sdw_compute_params() tracks the next dynamic port block offset in a
> > static next_offset[] array initialised with {1} (which also leaves
> > instance 1 initialised to 0).  Because next_offset[] is static and
> > never reset when streams are freed or when the driver is unbound and
> > rebound, the offset grows monotonically across stream lifecycles until
> > it exceeds max_slots - 1 and permanently fails with -ENOMEM.
> > 
> > Compute next_offset locally in amd_sdw_compute_params() from the active
> > ports on the bus and clear port_offset_map[dai->id] in
> > amd_sdw_hw_free().
> 
> This is not a bug for ACP6.3/7.0/7.1/7.2 platforms. These variants
> do not have banked registers for data port programming. Instead, a
> fixed port mapping per DAI ID is used by design: each use case (e.g.
> headset playback, headphone capture) always maps to the same DAI ID
> and port number across stream lifecycles.
> 
> The guard at line 402:
> 
>     if (!amd_manager->port_offset_map[p_rt->num])
> 
> ensures that port_offset_map[] is populated exactly once per port
> at first use and never reassigned. Since the DAI-to-port mapping is
> fixed, next_offset[] advancing after initial assignment has no effect
> on subsequent stream open/close cycles.
> 
> Furthermore, the hw_free change introduced by this patch:
> 
>     amd_manager->port_offset_map[dai->id] = 0;
> 
> would be a regression. Clearing the map entry on stream teardown
> causes the port to be reassigned a new block offset on the next
> stream open, at which point next_offset[] has already advanced past
> the original value. This breaks the fixed mapping invariant that the
> driver relies on.
> 
> The number of concurrent streams per instance is known and bounded,
> so -ENOMEM from slot exhaustion cannot occur in practice.
> Please drop this patch.

Done.

-- 
Lee Jones