Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-27 Thread Alexander Duyck
On Mon, 2018-11-26 at 18:35 -0800, Dan Williams wrote: > On Mon, Nov 5, 2018 at 1:12 PM Alexander Duyck > wrote: > > > > This patch adds an additional bit to the device struct named async_probe. > > This additional bit allows us to guarantee ordering between probe and > > remove operations. > >

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-26 Thread Dan Williams
On Mon, Nov 5, 2018 at 1:12 PM Alexander Duyck wrote: > > This patch adds an additional bit to the device struct named async_probe. > This additional bit allows us to guarantee ordering between probe and > remove operations. > > This allows us to guarantee that if we execute a remove operation or

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-23 Thread Bart Van Assche
On 11/22/18 5:23 PM, Rong Chen wrote: Kbuild robot printed all warnings and the below warning was found in patch 5/9. "include/linux/device.h:1056: warning: Function parameter or member 'async_probe' not described in 'device'" Hi Rong, Thanks for having taken a look. That's indeed

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-22 Thread Rong Chen
On 11/07/2018 07:51 AM, Bart Van Assche wrote: On Tue, 2018-11-06 at 12:10 +0800, kbuild test robot wrote: Hi Alexander, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on driver-core/master] url:

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-08 Thread Bart Van Assche
On Tue, 2018-11-06 at 17:34 -0800, Joe Perches wrote: > On Tue, 2018-11-06 at 15:48 -0800, Bart Van Assche wrote: > > On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote: > > > One change I made in addition is I replaced the use of "bool X:1" to > > > define > > > the bitfield to a "u8 X:1"

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-06 Thread Alexander Duyck
On Tue, Nov 6, 2018 at 3:51 PM Bart Van Assche wrote: > > On Tue, 2018-11-06 at 12:10 +0800, kbuild test robot wrote: > > Hi Alexander, > > > > Thank you for the patch! Perhaps something to improve: > > > > [auto build test WARNING on driver-core/master] > > > > url: > >

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-06 Thread Bart Van Assche
On Tue, 2018-11-06 at 12:10 +0800, kbuild test robot wrote: > Hi Alexander, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on driver-core/master] > > url: >

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-06 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote: > One change I made in addition is I replaced the use of "bool X:1" to define > the bitfield to a "u8 X:1" setup in order to resolve some checkpatch > warnings. Please use "bool X:1" instead of "u8 X:1". I think it was a bad idea to make

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-05 Thread kbuild test robot
Hi Alexander, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on driver-core/master] url: https://github.com/0day-ci/linux/commits/Alexander-Duyck/Add-NUMA-aware-async_schedule-calls/20181106-093800 reproduce: make htmldocs All warnings (new ones prefixed by

[driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-05 Thread Alexander Duyck
This patch adds an additional bit to the device struct named async_probe. This additional bit allows us to guarantee ordering between probe and remove operations. This allows us to guarantee that if we execute a remove operation or a driver load attempt on a given interface it will not attempt to