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

[Josh Boyer]

On Wed, Nov 6, 2013 at 6:07 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>>> 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.

You aren't wrong, and I'll be sure to do that with some of the stuff
we're thinking about that came up last night.  However, there are
literally 4 people that commit.  I thought I had spoken to each of
them individually.  Seems my memory is going.

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

See the thread with Kyle from last night.  Seriously, stop thinking
we're targeting you.

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

Not exactly.  It's more "hey, primary arches aren't supposed to be
broken willy-nilly, so we should probably pay attention to ARM more
now and not break it at random."  That's not so much "assist" as it is
"do no harm".

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

Please review the thread with Kyle last night.  That's kind of where
we're headed and feedback on that would be good.

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

I'm beginning to believe that there is nothing I can say that will
convince you that we aren't targeting you.  Do you have some kind of
persecution complex :)?

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

The wiki is a horribly out of date thing.  To be honest, I haven't
read the wiki in months.  Point taken, we'll update it, possibly by
just deleting a lot of things.  Then probably adding whatever we come
up with here.

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

Sure.  Wide ranging things can get posted as you have done.  I was
mostly referring to the "toggle 3 ARM drivers in the ARM configs" kind
of things.  To be honest, I'm good with posting everything, but I was
trying to avoid additional burden.

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

Sure.  Post them, we'll get them in.

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

Absolutely.  That doesn't mean they shouldn't get posted (and tracked
in patchwork if we go that way).  It's arguable we want them reviewed
even more closely because they're going to impact a wider audience
with the explicit goal of attracting people.

Really, it's about knowing where things are coming from and where
they're headed, and making sure we aren't grabbing incomplete stuff
from upstream.  The conversation with Kyle from last night on this
list go towards that too, so please weigh in.

josh