RE: [PATCH 0/3] ASoC/soundwire: remove ghost peripherals from the mach table

[Liao, Bard]

> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxx>
> Sent: Friday, October 9, 2026 1:09 AM
> To: Liao, Bard <bard.liao@xxxxxxxxx>; Bard Liao <yung-
> chuan.liao@xxxxxxxxxxxxxxx>; linux-sound@xxxxxxxxxxxxxxx; vkoul@xxxxxxxxxx;
> broonie@xxxxxxxxxx; tiwai@xxxxxxx
> Cc: vinod.koul@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> peter.ujfalusi@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 0/3] ASoC/soundwire: remove ghost peripherals from the
> mach table
> 
> 
> >>
> >> The main objection I have is this piece of code:
> >>
> >> if (ret == -ENODATA) { /* end of device id reads */
> >>  			dev_dbg(bus->dev, "No more devices to
> >> enumerate\n");
> >>  			ret = 0;
> >> +			complete_all(&bus->enumeration_complete);
> >>  			break;
> >>  		}
> >>
> >> This assumes that ALL peripherals report as ATTACHED at the same time.
> >> If for some reason a peripheral attaches later, then the entire logic
> >> would be broken - or you will have to add a large-enough wait time
> >> before trying to enumerate devices. That's different to the timeout for
> >> the wait_for_completion, what I am referring to is a delay to let all
> >> devices show-up as ATTACHED after the bus start.
> >
> > Not exactly the same time, but when the bus starts and do the enumeration
> > process, aren't all peripherals enumerated at that time? In other words,
> > doesn't it mean all existing peripherals are enumerated when there is no
> > peripheral with device numver 0?
> > If for some reason a peripheral will not show up at the first bus start,
> > we can add a quirk to skip the peripheral and assume it is always existent.
> 
> Well, you've got two problems here.
> 
> a) there's a difference between generations. Starting with ACE2.0, the
> SoundWire bus is started much earlier than in previous generations,
> where the SoundWire bus was started after firmware download.
> 
> In other words, the timing to sync and report as attached differs by
> orders of magnitude. I am worried that this code might break stuff on
> older platforms.

The commits will not check the existence of the peripherals for the
ACE2.0- platforms. So it should be fine.

> 
> b) there's nothing in the MIPI spec that says how much time a device
> should take to report as ATTACHED. A well-intended implementation
> following Recommendation {2121} would e.g. try to find the sync word
> with a default frame shape of 48x2, which isn't used at all by Intel.

Can't we rely on reading device 0 to know whether all peripherals are
enumerated? Is it possible that a peripheral can be attached after some
time when all other peripherals on the same bus are attached?
Will it trigger another interrupt in that case? My assumption is that
a bus will only get one attached interrupt when it starts. And we will
keep reading the device 0 and programing the device number nutil there
is no device 0.

> 
> If you want to keep the code above, you absolutely need to record the
> time at which the bus started and wait TBD ms before signaling
> enumeration_complete(). You would also need to deal with a case where
> another device shows up with a delay, would you throw another
> complete_all() then?
> 

Can we add a peripheral property to indicate a waiting time and wait the
largest waiting time of the peripherals?