On 3/5/20 11:43 AM, Mark Brown wrote:
On Thu, Mar 05, 2020 at 08:51:03AM -0600, Pierre-Louis Bossart wrote:
This doesn't answer the question: why is the machine driver not
requesting the GPIO on device model probe?
I *think* it's due to the need to use the codec component->dev, which is
only available with the dailink callbacks - not on platform device probe
which ends with the card registration.
Why do you have this need? This is sounding a lot like the CODEC ought
to be requesting it...
it's been that way since 2016 and the initial contribution. The Chrome
folks might know more, I don't think anyone at Intel has worked on this
code.
So you've removed the driver which will have unbound the device but devm
actions don't seem to have fired? That seems worrying...
Well, the devm uses the component device, not the card device, so when
removing the machine driver nothing should happen. The problem seems to be
in the removal of the codec and component drivers.
Right, it's always a bad idea to do allocations with devm_ on a device
other than the one that you're currently working with - that clearly
leads to lifetime issues.
that's precisely what I tried to correct.
We tried to use the card device instead but then the gpiod_get fails.
I think you need to take a step back and work out what you're actually
doing here. It doesn't sound like the problem has been fully understood
so there's no clear articulation of what you're trying to do.
Can we split this RFC in two:
a) do you have any objections to adding an .exit() callback? That's what
the main goal was
b) do you have any objections if we remove this devm_ use without trying
to dig further into the gpio management. This is a 2015 product that we
use to verify the SOF driver on Broadwell, not an Intel-owned device.
