On Thu, Sep 10, 2015 at 3:48 PM, Rob Herring <robh@xxxxxxxxxx> wrote:
> +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.
But the data in the kernel is the "source of truth" for now since the
other tree is simply generated.
> 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.
Umm, not sure if I like symlink, it makes hard to see what includes
what. The individual DTSes will continue including
dt-bindings/input/input.h and only input.h will include uapi header
(so use of uapi is internal detail). Would that still be a problem?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
