On Wed, Apr 15, 2020 at 03:22:50PM -0500, Pierre-Louis Bossart wrote:

> > In the case of this driver could you look at registering the link from
> > the device for the clocks?  Have it say "I supply SCK on device X" as it
> > registers.  That should be fairly straightforward I think, we do that
> > for one of the regulators.

> When you wrote 'in the case of this driver', were you referring to the clock
> provider, saying 'I support SCK on device i2c-104C5122:00' ?

Yes.

> If you have a pointer on the regulator example, I'd appreciate it, I am
> really way beyond my comfort zone.

The arizona driver is what I was thinking of, that's more complex than
you proabably need as it's a MFD.

> Maybe an alternate suggestion if you want to avoid hard-coded strings in the
> kernel: what if we added optional properties for the clock lookup name in
> both the codec and clock driver, and set the name in a _DSD blob. That would
> move the platform-specific names to platform firmware, and avoid the links
> described above that are probably ACPI-only.

If you read the lookup information from firmware somehow that's probably
fine I think.  It's not nice but if it's baked into firmware...

> > I think by now there's ample evidence that it's worth investing in
> > better firmware descriptions :(

> Indeed, and tools to check they are correct! Most of the stuff we defined
> for SoundWire ends-up wrong or undefined, still an uphill battle...

The audio-graph-card appears to be working really well FWIW,
Morimoto-san did an excellent job there.