On Tue, Nov 5, 2013 at 11:16 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
Sorry for the delayed response, $dayjob has had me so busy I've
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
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
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
 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
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
So what I would like to know is why after nearly two years it is now
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
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
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
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
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.