[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4bbe2fca-0479-7249-9598-c603fb3247e8@kernel.org>
Date: Sat, 11 Jun 2016 17:55:00 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Lars-Peter Clausen <lars@...afoo.de>,
Crestez Dan Leonard <leonard.crestez@...el.com>,
linux-iio@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Hartmut Knaack <knaack.h@....de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
Daniel Baluta <daniel.baluta@...el.com>
Subject: Re: [RFC 6/7] iio: Refuse to register triggers with duplicate names
On 31/05/16 15:03, Lars-Peter Clausen wrote:
> On 05/30/2016 02:49 PM, Crestez Dan Leonard wrote:
>> On 05/29/2016 10:48 PM, Jonathan Cameron wrote:
>>> On 23/05/16 19:40, Crestez Dan Leonard wrote:
>>>> The trigger name is documented as unique but drivers are currently
>>>> allowed to register triggers with duplicate names. This should be
>>>> considered a bug since it makes the 'current_trigger' interface
>>>> unusable.
>>>>
>>>> Signed-off-by: Crestez Dan Leonard <leonard.crestez@...el.com>
>>> This feels like the right approach to my mind (and should have been there
>>> all along - oops).
>>>
>>> However, we do need to avoid breaking userspace. It's ugly but for those 3 drivers
>>> can we assume that using more than one on a board was impossible before this series
>>> and as such play a slight game in which we don't change the trigger name they
>>> are exporting, unless that name is already in use?
>>>
>>> It's ugly but it gets us the nicest solution for all drivers for a bit of ugly in
>>> 3 of them...
>>
>> How would that look like? I guess I could handle -EEXIST from
>> iio_trigger_register and try again with another name? Unfortunately the
>> name is initialized at alloc time while uniqueness can only be checked
>> at register time. This would require some refactoring in drivers for
>> devices I don't have.
>>
>> An alternative would be to just submit patches 4/5 and only give a
>> warning when non-unique trigger names are used. After all, iio device
>> names are not unique, the easy way would be to give up on this guarantee
>> for trigger names as well.
>>
>
> I'd say apply this patch keep things as they are in the drivers and if
> somebody creates a board with more than one of those devices let them come
> up with a fix.
Fair call. Lets do that.
Applied this patch to the togreg branch of iio.git (usual testing blah blah)
Let's see who (hopefully no one) screams.
Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Powered by blists - more mailing lists