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

[Josh Boyer]

On Tue, Nov 5, 2013 at 11:16 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
> 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.

Informed wasn't how I took that conversation.

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

Untrue.  It's targeted at anyone that wants to get a patch into the
kernel that doesn't have a bug attached to it, or wants to bring in
something not clearly headed into mainline.  For example, Daniel Stone
asked for an evdev patch to get in and I told him to post it here or
file a bug and I'd grab it if it looked good.  Neither happened, no
patch has been pulled in.

We aren't making special rules just for you.

> 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

Nobody said it was huge.

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

It's not that simple any more.  For 2 years we could do that because
ARM was a secondary arch and things proceeded regardless of what
happened there.  Now, because of the good efforts of the ARM team,
it's primary.  Which means we wait, and we should arguably care a hell
of a lot more about it.  We can't just drop patches in f20 and rawhide
and potentially break ARM because that isn't how a primary arch should
be treated.

Also, for the past several years we've been less than transparent
about what patches we take and why we take them.  Not just for ARM,
but overall.  I think we need to fix that.  I think having a bug
attached to it is fairly clear.  If there's no bug, post to the list.
This isn't extremely difficult to do and it applies to everyone.

As I said before, config changes are probably fine without posting.
Patches, particularly out-of-tree patches, should get some simple
review.

> 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

See above.  Also, the meeting wasn't a random unrelated meeting, it
was the bi-weekly ARM meeting.  It is unfortunate you weren't there
and I wasn't aware of that fact, but it wasn't intentional.

> approaching me directly whether it be email or other ways to discuss

Because it isn't about and doesn't apply to just you.

> 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

Because it took you 2 years to get ARM primary?

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

And that is extremely appreciated.  I'm not asking you or anyone else
to stop.  I'm asking you and everyone else to help us get things a bit
tighter and consistent.

>>> +# 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

That commit was already in an upstream tree when it was done.  This
patch had been sent to the list for review and committed almost as
quickly as it was posted.  The upstream review wasn't anywhere near
complete.

In simple view, you are correct.  It doesn't break anything else.  In
the larger view, I really want to start backing away from random patch
grabs.  Upstream has a review process for a reason, and I'd like to
leverage that for patches we carry.  Otherwise we wind up carrying
patches that are "getting in RSN" which aren't actually getting in any
time soon.

I'm not trying to limit your functionality.  I'm trying to limit our
liability and learn from past mistakes.  This isn't even specific to
ARM.  The secure boot patches we're carrying?  I really dislike those
and now we're stuck with them until something happens upstream.  They
were necessary at the time and we had justification for grabbing them,
but they broke things in F18 and F19 and we still don't have great
solutions pending in trees.

josh