[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190725133850.GB11115@kroah.com>
Date: Thu, 25 Jul 2019 15:38:50 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: junxiao.chang@...el.com
Cc: linux-kernel@...r.kernel.org, rafael@...nel.org, lili.li@...el.com
Subject: Re: [PATCH] platform: release resource itself instead of resource
tree
On Thu, Apr 25, 2019 at 02:24:18PM +0800, junxiao.chang@...el.com wrote:
> From: Junxiao Chang <junxiao.chang@...el.com>
>
> When platform device is deleted or there is error in adding
> device, platform device resources should be released. Currently
> API release_resource is used to release platform device resources.
> However, this API releases not only platform resource itself but
> also its child resources. It might release resources which are
> still in use. Calling remove_resource only releases current
> resource itself, not resource tree, it moves its child resources
> to up level.
But shouldn't the parent device not get removed until all of the
children are removed? What is causing this "inversion" to happen?
>
> For example, platform device 1 and device 2 are registered, then only
> device 1 is unregistered in below code:
>
> ...
> // Register platform test device 1, resource 0xfed1a000 ~ 0xfed1afff
> pdev1 = platform_device_register_full(&pdevinfo1);
>
> // Register platform test device 2, resource 0xfed1a200 ~ 0xfed1a2ff
> pdev2 = platform_device_register_full(&pdevinfo2);
>
> // Now platform device 2 resource should be device 1 resource's child
>
> // Unregister device 1 only
> platform_device_unregister(pdev1);
> ...
Don't do that. :)
You created this mess of platform devices, so you need to keep track of
them.
> Platform device 2 resource will be released as well because its
> parent resource(device 1's resource) is released, this is not expected.
> If using API remove_resource, device 2 resource will not be released.
>
> This change fixed an intel pmc platform device resource issue when
> intel pmc ipc kernel module is inserted/removed for twice.
Why not fix that kernel module instead? It seems like that is the real
problem here, not a driver core issue.
thanks,
greg k-h
Powered by blists - more mailing lists