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.