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

[Peter Robinson]

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

It would be useful for you to advertise this intention and send things
like details out to the kernel mailing list. I'll need to re-read my
IRC logs but I don't remember you mentioning any of the above, which
does sound reasonable, to me in the conversation we had. I'm not sure
the conversation that was outlined in the ARM mailing list but it
sounds like something that should be broadcast more to the Fedora
kernel list.

> We aren't making special rules just for you.

We maybe it's just the way it seems as until now I've not seen anyone
else be targeted prior to this.... maybe it's just me doing work!

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

Sorry, must have been my interpretation of your reaction.

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

Is that round about terms meaning that the Fedora kernel team are
going to start to assist in the ARM issues :-D

I try to help and keep the impact of ARM down for you guys but kernel
isn't a core skill I ever thought I wanted to learn (I often say about
ARM that I now know more about the Fedora Core OS and kernel than I
ever thought I wanted to know!) and if the process becomes too arduous
I stop enjoying it and I'll go and find some other project to get my
teeth into as there's no shortage. I'm not saying here that the
process doesn't need to change and improve but just be aware I think
it needs balance and it needs to be measured so that you don't scare
off the people that are trying to help you.

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

Well I don't think targeting me (at least that's what it appears to
me) is the way to fix that. I don't see any wider announcement to the
list or even updated on the Kernel wiki page. In fact to quote from
the wiki "If you are sending lots of changes to the Fedora kernel,
then it may make more sense for you to get commit access. (Note, for
most things, sending them upstream is far more preferable)."

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

Probably fine? If they're more widely impacting I will most certainly
post them just like I've done them in the past. Personally I think I
have a pretty good overview of the impact of config changes in the ARM
sphere and I think it then becomes arduous for all involved.

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

Yet you haven't seen fit to send the changes to your own list, update
your own wiki or circulate it to any wider audience that I've seen.

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

That's reasonable.... but please communicate your intentions more
widely and consistently!

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

It's a device tree file that impacts a single piece of HW, this isn't
a core scheduler change we're talking about here! I think there needs
to be perspective to keep us all sane and so we don't go from a
relaxed straight forward process to one that is painful for us all.

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

Believe me I don't like patch grabs either! But similar to secureboot
there are some that are useful such as the BeagleBone Black support
and some other devices that are key to getting people engaging and
using Fedora on ARM and I believe in those cases, like secure boot,
the patches are justifiable to open Fedora on ARM and Fedora in
general up to a wider audience.

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

Well I'm not even going to comment on SecureBoot, I believe enough has
already been said there to last a lifetime.

I'm very aware of limiting of liability and of patch impact even if
it's just so that I don't have to feel I'm walking on egg shells when
dealing with the kernel team. Precisely the reason I dropped and
didn't rebase the exynos patch set. When it was added it was useful as
it was the only widely available A15 chipset and we wanted something.
In hindsight it was a waste of time because there was wider issues
with the HW. Like the SecureBoot patch sets you live and learn and
ultimately it was low impact and contained.

Peter