[PATCH 2/3] devicetree: bindings: use input-event-codes.h for evdev codes

[Hans de Goede]

Hi,

On 09/17/2015 04:00 PM, Rob Herring wrote:
> On 09/17/2015 02:35 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 09/17/2015 07:00 AM, Ian Campbell wrote:
>>> On Wed, 2015-09-16 at 15:40 +0100, Ian Campbell wrote:
>>>>> The intend of the symlink was that the conversion script would copy
>>>>> the target,
>>>>> rather then follow the symlink. This sorta assumes that there are
>>>>> will be not
>>>>> symlinks under dt-bindings which link to files inside dt-bindings
>>>>> and thus
>>>>> should be preserved as symlinks.
>>>>>
>>>>> If the copy done in the script will follow the symlink then nothing
>>>>> should
>>>>> really change for the split DT repo.
>>>>
>>>> Interesting idea. I'll see if I can make the conversion routine do that.
>>>>
>>>> TBH I have a horrid feeling that this is going to be beyond git rewrite
>>>> -branch, at least in the mode it is used in today.
>>>
>>> It seems that it is possible, after a fashion.
>>>
>>> The downside is that either _all_ symlinks (which end up in the
>>> output) get
>>> flattened or some sort of black/whitelisting is needed in the conversion
>>> scripts themselves (potentially leading to issues or discontinuities) as
>>> new stuff arrives).
>>>
>>> It isn't possible AFAICT tell if a symlink points to something outside of
>>> the converted set of paths and adjust, at least not without an
>>> unreasonable
>>> amount of overhead on each commit during the rewrite.
>>>
>>> Since this new file would be the first symlink in the converted repo I
>>> took
>>> the former approach in my lash up to try it out
>>
>> Ack, sounds good.
>>
>>> which was essentially to
>>> insert the below script into the middle of the "git ls-files | rewrite
>>> -paths.sed" pipeline which is called by git filter-branch --index-filter.
>>> Not pretty but it does seem to work.
>>>
>>> I want to avoid switching to --tree-filter if at all possible because it
>>> checks out the tree and is therefore a _little_ I/O intensive ;-)
>>
>> Thanks for your work on this, so what does this mean for moving forward
>> with the patch-set I posted. Can this be merged now ? And if not what
>> are we waiting for ?
>
> I thought you were sending another version using "linux-event-codes.h."

Yes I can do that if people want me to, I am / was waiting for things
to settle down first. So if you want a v2 series with linux-event-codes.h
and everything else unchanged, let me know and I'll do so.

> Anyway, for the series for DT:
>
> Acked-by: Rob Herring <robh at kernel.org>

Thanks,

Hans