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

Rob Herring robh at kernel.org
Thu Sep 17 13:00:47 PDT 2015


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."

Anyway, for the series for DT:

Acked-by: Rob Herring <robh at kernel.org>

Rob




More information about the linux-arm-kernel mailing list