+Ian
On 09/10/2015 01:50 PM, Hans de Goede wrote:
> Hi,
>
> On 10-09-15 20:42, Dmitry Torokhov wrote:
>> On Thu, Sep 10, 2015 at 11:40 AM, Hans de Goede <hdegoede@xxxxxxxxxx>
>> wrote:
>>> Hi,
>>>
>>>
>>> On 10-09-15 20:34, Dmitry Torokhov wrote:
>>>>
>>>> On Thu, Sep 10, 2015 at 10:25 AM, Rob Herring <robh@xxxxxxxxxx> wrote:
>>>>>
>>>>> On 09/09/2015 04:11 AM, Hans de Goede wrote:
>>>>>>
>>>>>> This header provides evdev constants for linux,code, and
>>>>>> linux,input-*
>>>>>> properties.
>>>>>>
>>>>>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
>>>>>> ---
>>>>>> include/dt-bindings/input/evdev.h | 76
>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>>
>>>>> This looks fine, but please just add to input/input.h.
[...]
>>>> Actually I'd rather we removed include/dt-bindings/input/input.h and
>>>> instead used the header file from uapi. As it is now we already
>>>> duplicating definitions and the copy in dt-bindings is missing several
>>>> key codes. Until we split DT bindings form the kernel code I'd rather
>>>> have definitions in one place.
We do already have split binding tree. It is generated from the kernel
tree ATM. Adding Ian for any comments.
>>> AFAIK we cannot do that as the uapi header also contains things like:
>>>
>>> struct input_event {
>>> struct timeval time;
>>> __u16 type;
>>> __u16 code;
>>> __s32 value;
>>> };
>>>
>>> Which is not valid device tree syntax.
>>>
>>> If you want this we need to split the uapi headers in one with only
>>> defines and one with all the rest.
>>
>> That would be fine by me. event-codes.h?
>
> Since this will live in the generic include/linux namespace (for userspace)
> maybe input-event-codes ?
>
> Rob are you ok with including uapi headers from dts files if those uapi
> headers are guaranteed to have only #define-s in them?
No. If you can do it as a symlink or some limited way, I'd be fine with
that. I don't want to see wholesale addition of uapi headers though.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
