Re: [RFC 1/1] driver core: re-order dpm_list after a succussful probe

2014-12-24 Thread Bill Huang
On 12/23/2014 10:26 PM, Bibek Basu wrote: sorry for the delay in responding. On Thu, Dec 18, 2014 at 1:35 PM, Bill Huang mailto:bilhu...@nvidia.com>> wrote: On 12/17/2014 10:47 PM, Bibek Basu wrote: Hi Bill, Though I like your solution, I have a usecase where the drive

Re: [RFC 1/1] driver core: re-order dpm_list after a succussful probe

2014-12-18 Thread Bill Huang
On 12/17/2014 10:47 PM, Bibek Basu wrote: Hi Bill, Though I like your solution, I have a usecase where the driver probe sequence itself is not right. Both the driver are module_init but one depends on another during suspend sequence. In such a situation, my system hangs. What do you suggest to

Re: [RFC 1/1] driver core: re-order dpm_list after a succussful probe

2014-12-12 Thread Greg KH
On Fri, Dec 12, 2014 at 03:50:15AM -0800, Bill Huang wrote: > The dpm_list was added in the call "device_add" and when we do defer > probe we'll explicitly move the probed device to be the last in the > dpm_list, we should do the same for the normal probe since there are > cases that we won't have

[RFC 1/1] driver core: re-order dpm_list after a succussful probe

2014-12-12 Thread Bill Huang
The dpm_list was added in the call "device_add" and when we do defer probe we'll explicitly move the probed device to be the last in the dpm_list, we should do the same for the normal probe since there are cases that we won't have chance to do defer probe to change the PM order as the below example