On Mon, Mar 14, 2016 at 10:28:10AM +0100, Wolfram Sang wrote:
>
> > This doesn't work. I see a number of these WARN_ON()s trigger and I
> > think the reason is that i2c_init() always fails now. The cause seems to
> > be that i2c_init() calls i2c_add_driver(_driver), which will now
> > always
On Mon, Mar 14, 2016 at 10:28:10AM +0100, Wolfram Sang wrote:
>
> > This doesn't work. I see a number of these WARN_ON()s trigger and I
> > think the reason is that i2c_init() always fails now. The cause seems to
> > be that i2c_init() calls i2c_add_driver(_driver), which will now
> > always
On Mon, Mar 14, 2016 at 9:27 AM, Thierry Reding
wrote:
> On Mon, Mar 14, 2016 at 10:18:19AM +0100, Thierry Reding wrote:
>> On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
>> > The variable p is a data structure which is used by the driver core
>> >
On Mon, Mar 14, 2016 at 9:27 AM, Thierry Reding
wrote:
> On Mon, Mar 14, 2016 at 10:18:19AM +0100, Thierry Reding wrote:
>> On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
>> > The variable p is a data structure which is used by the driver core
>> > internally and it is not
On Mon, Mar 14, 2016 at 10:28:10AM +0100, Wolfram Sang wrote:
>
> > This doesn't work. I see a number of these WARN_ON()s trigger and I
> > think the reason is that i2c_init() always fails now. The cause seems to
> > be that i2c_init() calls i2c_add_driver(_driver), which will now
> > always
On Mon, Mar 14, 2016 at 10:28:10AM +0100, Wolfram Sang wrote:
>
> > This doesn't work. I see a number of these WARN_ON()s trigger and I
> > think the reason is that i2c_init() always fails now. The cause seems to
> > be that i2c_init() calls i2c_add_driver(_driver), which will now
> > always
> This doesn't work. I see a number of these WARN_ON()s trigger and I
> think the reason is that i2c_init() always fails now. The cause seems to
> be that i2c_init() calls i2c_add_driver(_driver), which will now
> always fail, because is_register is set to true *after* that call. There
> is no
> This doesn't work. I see a number of these WARN_ON()s trigger and I
> think the reason is that i2c_init() always fails now. The cause seems to
> be that i2c_init() calls i2c_add_driver(_driver), which will now
> always fail, because is_register is set to true *after* that call. There
> is no
On Mon, Mar 14, 2016 at 10:18:19AM +0100, Thierry Reding wrote:
> On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> > The variable p is a data structure which is used by the driver core
> > internally and it is not expected that busses will be directly accessing
> > these driver
On Mon, Mar 14, 2016 at 10:18:19AM +0100, Thierry Reding wrote:
> On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> > The variable p is a data structure which is used by the driver core
> > internally and it is not expected that busses will be directly accessing
> > these driver
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> The variable p is a data structure which is used by the driver core
> internally and it is not expected that busses will be directly accessing
> these driver core internal only data.
>
> Signed-off-by: Sudip Mukherjee
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> The variable p is a data structure which is used by the driver core
> internally and it is not expected that busses will be directly accessing
> these driver core internal only data.
>
> Signed-off-by: Sudip Mukherjee
> ---
>
>
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> The variable p is a data structure which is used by the driver core
> internally and it is not expected that busses will be directly accessing
> these driver core internal only data.
>
> Signed-off-by: Sudip Mukherjee
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> The variable p is a data structure which is used by the driver core
> internally and it is not expected that busses will be directly accessing
> these driver core internal only data.
>
> Signed-off-by: Sudip Mukherjee
Removed
On Monday 07 March 2016 10:27 PM, Greg KH wrote:
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
The variable p is a data structure which is used by the driver core
internally and it is not expected that busses will be directly accessing
these driver core internal only data.
On Monday 07 March 2016 10:27 PM, Greg KH wrote:
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
The variable p is a data structure which is used by the driver core
internally and it is not expected that busses will be directly accessing
these driver core internal only data.
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> The variable p is a data structure which is used by the driver core
> internally and it is not expected that busses will be directly accessing
> these driver core internal only data.
>
> Signed-off-by: Sudip Mukherjee
On Mon, Mar 07, 2016 at 05:19:17PM +0530, Sudip Mukherjee wrote:
> The variable p is a data structure which is used by the driver core
> internally and it is not expected that busses will be directly accessing
> these driver core internal only data.
>
> Signed-off-by: Sudip Mukherjee
> ---
>
>
The variable p is a data structure which is used by the driver core
internally and it is not expected that busses will be directly accessing
these driver core internal only data.
Signed-off-by: Sudip Mukherjee
---
Reference of Greg's comment about it at:
The variable p is a data structure which is used by the driver core
internally and it is not expected that busses will be directly accessing
these driver core internal only data.
Signed-off-by: Sudip Mukherjee
---
Reference of Greg's comment about it at:
https://lkml.org/lkml/2016/3/5/171
20 matches
Mail list logo