[kernel] Add patch for i.MX6 Utilite device dtb, drop old exynos patch

[Peter Robinson]

Sorry for the delayed response, $dayjob has had me so busy I've not
had time to look at kernel stuff since nor associated list mail.

>>
>>     Add patch for i.MX6 Utilite device dtb, drop old exynos patch
>
> I thought we discussed on IRC that patches were going to get sent to
> the list first?

Well it was discussed and agreed upon in a meeting that I wasn't
present at and then I was basically informed on IRC what was expected.
IMO this is stupid because it appears that I'm the only one it's
targetted at as I'm the only one that regularly commits to the ARM
section of the kernel and it doesn't appear to apply to anyone else.

What I don't also get is why it's suddenly a problem after nearly two
years (my first commit was Jan 26th, 2012) of working in the way I
have why it's suddenly become a huge problem. The way I've worked up
to now was any issue that might affect non ARM was sent to the list
[1] for approval and for anything ARM related you always made it
abundantly clear that it was the ARM teams problem to deal with
whether it be a bug or a patch, any time there's been a patch that
hasn't applied you've just commented it out and pinged me to deal with
it and I always have whether it be to rebase or drop. Any time there
was a bug report you reassigned it to ARM people.

So what I would like to know is why after nearly two years it is now a
problem, why was it taken to a meeting I wasn't present at rather than
approaching me directly whether it be email or other ways to discuss
the issue that was causing so much trouble and why it took nearly two
years to have a problem with the way I was doing it? The way I see it
all I've tried to do is make the ARM side of the maintenance as easy
on the mainline kernel team as possible, support the ARM devices as
best as possible for the ARM users while keeping the workload and
process for me as simple as possible.

[1] https://lists.fedoraproject.org/pipermail/kernel/2013-August/004389.html

>> diff --git a/config-arm-generic b/config-arm-generic
>> index 96a95e5..aaa88ee 100644
>> --- a/config-arm-generic
>> +++ b/config-arm-generic
>> @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m
>>  CONFIG_SMC91X=m
>>  CONFIG_SMC911X=m
>>
>> -CONFIG_VIRTIO_CONSOLE=m
>> -
>
> Why did this get dropped?  The commit message doesn't say.

It should have been cleaned up as part of commit 1db1471 I had it
locally for a few days but I must have missed the line when reviewing
the diff for the commit message. Nothing more than an oversight.

>>  # CONFIG_CRYPTO_TEST is not set
>>  # CONFIG_TRANSPARENT_HUGEPAGE is not set
>>  # CONFIG_XEN is not set

<snip>

>> +# ARM i.MX6
>> +# http://www.spinics.net/lists/devicetree/msg08276.html
>> +Patch21030: arm-imx6-utilite.patch
>
> The link to the discussion is nice and I appreciate it.  Though it
> shows that changes have been requested, the patch isn't queued, and it
> isn't really fully reviewed.
>
> I don't understand the urgency in adding something that doesn't appear
> to be ready according to upstream.  Can you elaborate?

Because there's HW available and it would be really useful to be able
to support it. It's a self contained changed that has no means of
breaking anything else because it adds one more dtb file to the kernel
build that adds support for just that HW without having any other
impact to any other platform or device. I don't see how this has any
more impact than commit 87fb89b for Dell TouchPad support

Peter