Re: [PATCH 3/4] soundwire: bus_type: Create IRQ mapping before calling driver probe()

On 11-08-26, 09:37, Richard Fitzgerald wrote:
> On 11/8/26 06:16, Vinod Koul wrote:
> > On 10-08-26, 11:40, Richard Fitzgerald wrote:
> > > Call sdw_irq_create_mapping() before calling the peripheral driver
> > > probe() so that it is possible to request the IRQ during probe().
> > > 
> > > Previously creation of the mapping was conditional on the use_domain_irq
> > > flag in the driver properties. But these are filled in after probe(),
> > > which meant it wasn't possible to request the IRQ during probe(). This
> > > was ok for MFD drivers where only children requested the IRQ. But for
> > > normal drivers it led to the non-standard behavior of having to defer
> > > requesting the IRQ until after probe().
> > 
> > Shouldnt that still be the case (conditionally creating mapping). Does
> > every need this mapping?
> 
> Other interrupt providers create all their IRQs even if nothing uses
> them, so why worry about one IRQ mapping per SoundWire peripheral?
> 
> Currently it's just another way that the SoundWire subsystem doesn't
> follow normal Linux conventions and requires the codec drivers to
> work around the strangeness.

Hmm okay lets go with this, so

Acked-by: Vinod Koul <[email protected]>


> 
> We could unmap it after ops->read_prop() if we see use_domain_irq is
> false.
> 
> If we want to skip ever creating it, we'd need to move use_domain_irq
> to somewhere that is valid _before_ calling the codec driver probe().
> 
> Or call ops->read_prop() before calling probe(). There's no explanation
> why read_prop() was placed after probe() so I'm reluctant to move it.
> But I assume it's expected that probe() will always be the first
> function called in a driver.

The intent was that drivers can override the properties, so after the
probe is recommended.

-- 
~Vinod