Hi Jean,
On Tue, Jul 26, 2016 at 12:41 AM, Jean Delvare wrote:
> Hi Viresh,
>
> On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote:
>> On 25-07-16, 11:39, Jean Delvare wrote:
>> > The problem is that the patch proposed by Viresh has nothing to do with
>> > this. It's not
Hi Jean,
On Tue, Jul 26, 2016 at 12:41 AM, Jean Delvare wrote:
> Hi Viresh,
>
> On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote:
>> On 25-07-16, 11:39, Jean Delvare wrote:
>> > The problem is that the patch proposed by Viresh has nothing to do with
>> > this. It's not adding
Hi Viresh,
On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote:
> On 25-07-16, 11:39, Jean Delvare wrote:
> > The problem is that the patch proposed by Viresh has nothing to do with
> > this. It's not adding notifications, just changing the time frame during
> > which user-space holds a
Hi Viresh,
On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote:
> On 25-07-16, 11:39, Jean Delvare wrote:
> > The problem is that the patch proposed by Viresh has nothing to do with
> > this. It's not adding notifications, just changing the time frame during
> > which user-space holds a
Hi Jean,
On 25-07-16, 11:39, Jean Delvare wrote:
> The problem is that the patch proposed by Viresh has nothing to do with
> this. It's not adding notifications, just changing the time frame during
> which user-space holds a reference to the i2c (bus) device. The goal as
> I understand it is to
Hi Jean,
On 25-07-16, 11:39, Jean Delvare wrote:
> The problem is that the patch proposed by Viresh has nothing to do with
> this. It's not adding notifications, just changing the time frame during
> which user-space holds a reference to the i2c (bus) device. The goal as
> I understand it is to
Hi Greg, Viresh,
On Mon, 11 Jul 2016 14:50:58 -0700, Greg KH wrote:
> On Mon, Jul 11, 2016 at 02:22:09PM +0200, Jean Delvare wrote:
> > So you are basically building a test case to cause the problem. It's
> > artificial. The adapter reference being held while the device node is
> > open isn't a
Hi Greg, Viresh,
On Mon, 11 Jul 2016 14:50:58 -0700, Greg KH wrote:
> On Mon, Jul 11, 2016 at 02:22:09PM +0200, Jean Delvare wrote:
> > So you are basically building a test case to cause the problem. It's
> > artificial. The adapter reference being held while the device node is
> > open isn't a
On 11-07-16, 14:50, Greg KH wrote:
> Ideally, yes, userspace will have closed that device node. But again,
> hardware isn't kind and sometimes decides to be yanked out by users
> before they tell the kernel about it. We handle this for almost all
> other device subsystems, i2c is one of the last
On 11-07-16, 14:50, Greg KH wrote:
> Ideally, yes, userspace will have closed that device node. But again,
> hardware isn't kind and sometimes decides to be yanked out by users
> before they tell the kernel about it. We handle this for almost all
> other device subsystems, i2c is one of the last
On Mon, Jul 11, 2016 at 02:22:09PM +0200, Jean Delvare wrote:
> Hi Viresh,
>
> On Wed, 6 Jul 2016 13:55:40 -0700, Viresh Kumar wrote:
> > On 06-07-16, 19:12, Jean Delvare wrote:
> > > Well well... I don't like this patch at all to be honest.
> >
> > Sure, I didn't like it much as well. I just
On Mon, Jul 11, 2016 at 02:22:09PM +0200, Jean Delvare wrote:
> Hi Viresh,
>
> On Wed, 6 Jul 2016 13:55:40 -0700, Viresh Kumar wrote:
> > On 06-07-16, 19:12, Jean Delvare wrote:
> > > Well well... I don't like this patch at all to be honest.
> >
> > Sure, I didn't like it much as well. I just
Hi Viresh,
On Wed, 6 Jul 2016 13:55:40 -0700, Viresh Kumar wrote:
> On 06-07-16, 19:12, Jean Delvare wrote:
> > Well well... I don't like this patch at all to be honest.
>
> Sure, I didn't like it much as well. I just wanted people to comment on what
> else we can do here. We don't really want
Hi Viresh,
On Wed, 6 Jul 2016 13:55:40 -0700, Viresh Kumar wrote:
> On 06-07-16, 19:12, Jean Delvare wrote:
> > Well well... I don't like this patch at all to be honest.
>
> Sure, I didn't like it much as well. I just wanted people to comment on what
> else we can do here. We don't really want
On 06-07-16, 19:12, Jean Delvare wrote:
> Well well... I don't like this patch at all to be honest.
Sure, I didn't like it much as well. I just wanted people to comment on what
else we can do here. We don't really want to add out-of-mainline stuff here.
> My first question would be: what is
On 06-07-16, 19:12, Jean Delvare wrote:
> Well well... I don't like this patch at all to be honest.
Sure, I didn't like it much as well. I just wanted people to comment on what
else we can do here. We don't really want to add out-of-mainline stuff here.
> My first question would be: what is
On Wed, 6 Jul 2016 15:55:24 +0900, Wolfram Sang wrote:
> On Tue, Jul 05, 2016 at 07:57:07PM -0700, Viresh Kumar wrote:
> > The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> > doesn't let the adapter device unregister unless the .close() callback
> > is called.
> >
> > On some
On Wed, 6 Jul 2016 15:55:24 +0900, Wolfram Sang wrote:
> On Tue, Jul 05, 2016 at 07:57:07PM -0700, Viresh Kumar wrote:
> > The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> > doesn't let the adapter device unregister unless the .close() callback
> > is called.
> >
> > On some
On 06-07-16, 17:04, Peter Rosin wrote:
> Exactly, so the stored address had better be correct, and in
No.
> that case there is no need for the new adapter_nr in every
> client, you could just go with client->adapter->nr instead.
client->adapter may be a dangling pointer at this point if the
On 06-07-16, 17:04, Peter Rosin wrote:
> Exactly, so the stored address had better be correct, and in
No.
> that case there is no need for the new adapter_nr in every
> client, you could just go with client->adapter->nr instead.
client->adapter may be a dangling pointer at this point if the
On 06-07-16, 16:43, Lars-Peter Clausen wrote:
> There is no guarantee that the address will be different. While it is
> unlikely the memory allocated might give out the same address for the second
> adapter if the first one has been freed.
Oh yeah, thanks for correcting me :)
--
viresh
On 06-07-16, 16:43, Lars-Peter Clausen wrote:
> There is no guarantee that the address will be different. While it is
> unlikely the memory allocated might give out the same address for the second
> adapter if the first one has been freed.
Oh yeah, thanks for correcting me :)
--
viresh
On 2016-07-06 16:43, Lars-Peter Clausen wrote:
> On 07/06/2016 04:33 PM, Viresh Kumar wrote:
>> On 06-07-16, 10:22, Peter Rosin wrote:
>>> On 2016-07-06 04:57, Viresh Kumar wrote:
The i2c-dev calls i2c_get_adapter() from the .open() callback, which
doesn't let the adapter device
On 2016-07-06 16:43, Lars-Peter Clausen wrote:
> On 07/06/2016 04:33 PM, Viresh Kumar wrote:
>> On 06-07-16, 10:22, Peter Rosin wrote:
>>> On 2016-07-06 04:57, Viresh Kumar wrote:
The i2c-dev calls i2c_get_adapter() from the .open() callback, which
doesn't let the adapter device
On 07/06/2016 04:33 PM, Viresh Kumar wrote:
> On 06-07-16, 10:22, Peter Rosin wrote:
>> On 2016-07-06 04:57, Viresh Kumar wrote:
>>> The i2c-dev calls i2c_get_adapter() from the .open() callback, which
>>> doesn't let the adapter device unregister unless the .close() callback
>>> is called.
>>>
On 07/06/2016 04:33 PM, Viresh Kumar wrote:
> On 06-07-16, 10:22, Peter Rosin wrote:
>> On 2016-07-06 04:57, Viresh Kumar wrote:
>>> The i2c-dev calls i2c_get_adapter() from the .open() callback, which
>>> doesn't let the adapter device unregister unless the .close() callback
>>> is called.
>>>
On 06-07-16, 10:22, Peter Rosin wrote:
> On 2016-07-06 04:57, Viresh Kumar wrote:
> > The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> > doesn't let the adapter device unregister unless the .close() callback
> > is called.
> >
> > On some platforms (like Google ARA), this
On 06-07-16, 10:22, Peter Rosin wrote:
> On 2016-07-06 04:57, Viresh Kumar wrote:
> > The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> > doesn't let the adapter device unregister unless the .close() callback
> > is called.
> >
> > On some platforms (like Google ARA), this
On 06-07-16, 15:55, Wolfram Sang wrote:
> Adding something to *every* i2c_client for this corner case sounds
> pretty expensive to me.
I agree with you on that. I wanted to avoid it, but I couldn't :(
Lets see how Jean suggests to handle it.
--
viresh
On 06-07-16, 15:55, Wolfram Sang wrote:
> Adding something to *every* i2c_client for this corner case sounds
> pretty expensive to me.
I agree with you on that. I wanted to avoid it, but I couldn't :(
Lets see how Jean suggests to handle it.
--
viresh
On 2016-07-06 04:57, Viresh Kumar wrote:
> The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> doesn't let the adapter device unregister unless the .close() callback
> is called.
>
> On some platforms (like Google ARA), this doesn't let the modules
> (hardware attached to the
On 2016-07-06 04:57, Viresh Kumar wrote:
> The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> doesn't let the adapter device unregister unless the .close() callback
> is called.
>
> On some platforms (like Google ARA), this doesn't let the modules
> (hardware attached to the
On Tue, Jul 05, 2016 at 07:57:07PM -0700, Viresh Kumar wrote:
> The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> doesn't let the adapter device unregister unless the .close() callback
> is called.
>
> On some platforms (like Google ARA), this doesn't let the modules
>
On Tue, Jul 05, 2016 at 07:57:07PM -0700, Viresh Kumar wrote:
> The i2c-dev calls i2c_get_adapter() from the .open() callback, which
> doesn't let the adapter device unregister unless the .close() callback
> is called.
>
> On some platforms (like Google ARA), this doesn't let the modules
>
Hi,
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.7-rc6 next-20160705]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi,
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.7-rc6 next-20160705]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
The i2c-dev calls i2c_get_adapter() from the .open() callback, which
doesn't let the adapter device unregister unless the .close() callback
is called.
On some platforms (like Google ARA), this doesn't let the modules
(hardware attached to the phone) eject from the phone as the cleanup
path for
The i2c-dev calls i2c_get_adapter() from the .open() callback, which
doesn't let the adapter device unregister unless the .close() callback
is called.
On some platforms (like Google ARA), this doesn't let the modules
(hardware attached to the phone) eject from the phone as the cleanup
path for
38 matches
Mail list logo