On Thu, Mar 05, 2020 at 12:08:57PM -0600, Pierre-Louis Bossart wrote:
On 3/5/20 11:43 AM, Mark Brown wrote:
On Thu, Mar 05, 2020 at 08:51:03AM -0600, Pierre-Louis Bossart wrote:
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.
I'd have thought someone would've reviewed it on the way in?
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.
In general the best (clearest, most robust) way to correct something like this would be to continue to use devm_ but clean up the allocation so that it's done by the device that is used.
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.
The main thing I'm missing with this is a coherent explanation of the problem and how the changes proposed fix it.