[PATCH 1/2] tty: amba-pl011: fix earlycon register offsets

[Peter Hurley]

On 01/06/2016 09:17 PM, Greg Kroah-Hartman wrote:
> On Wed, Jan 06, 2016 at 10:07:00AM +0000, Russell King - ARM Linux wrote:
>> On Tue, Jan 05, 2016 at 06:43:02PM -0800, Greg Kroah-Hartman wrote:
>>> On Tue, Jan 05, 2016 at 12:30:19PM +0000, Russell King - ARM Linux wrote:
>>>> On Tue, Jan 05, 2016 at 12:12:31PM +0000, Sudeep Holla wrote:
>>>>> Hi Russell,
>>>>>
>>>>> On Thu, Dec 24, 2015 at 4:47 PM, Russell King - ARM Linux
>>>>> <linux at arm.linux.org.uk> wrote:
>>>>>> On Thu, Dec 24, 2015 at 09:49:48AM -0600, Timur Tabi wrote:
>>>>>>> The REG_x macros are indices into a table, not register offsets.  Since
>>>>>>> earlycon does not have access to the vendor data, we can currently only
>>>>>>> support standard ARM PL011 devices.
>>>>>>>
>>>>>>> Signed-off-by: Timur Tabi <timur at codeaurora.org>
>>>>>>
>>>>>> Please credit me with the change; this was obviously a change I made
>>>>>> when I posted the updated patches, which Greg had failed to take
>>>>>> instead of the original set.  Thanks.
>>>>>>
>>>>>
>>>>> I don't see this patch in linux-next. Without this it fails to boot(panics) on
>>>>> ARM64 when earlycon is enabled.
>>>>
>>>> I guess that's the way 4.4 is going to be then, because GregKH has not
>>>> been anywhere near "responsive" during the last cycle, but he did say
>>>> yesterday (in response to questions about driver model stuff) that he's
>>>> closed his trees for the merge window last week.
>>>>
>>>> All in all, this situation is entirely GregKH's making, as he took the
>>>> wrong set of patches, and has yet to respond to _any_ of the resulting
>>>> mails about it... I guess GregKH knows what he's doing as he's one of
>>>> the top (and vocal) kernel developers far more than I do, so I guess he
>>>> has his reasons for crapping up the AMBA PL011 driver...
>>>
>>> "plenty of time"?  I see Timur's patches to fix this were sent on
>>> December 24th.  Then fixed up and resent on January 4th. I see nothing
>>> in my todo queue that were sent earlier to resolve any of this horrid
>>> mess.
>>>
>>> So yes, I haven't done anything with the Jan 04 patch, given that it's
>>> been 24 hours since it was sent, that's totally reasonable.
>>
>> The first series of 11 patches was sent on November 3rd.  The problem at
>> the root of this issue was discovered on the very same day, and is a part
>> of the thread.  People reviewed and tested it, and other comments were
>> made.
>>
>> These were addressed, and the next series of 12 patches were sent on the
>> 16th November.
>>
>> On the 12th November, you decided it was time to pick up the first series
>> of patches and ignore the second series, despite the comments against the
>> first series indicating that there were problems.
>>
>> It was only realised on the 24th that you'd picked up the wrong set of
>> patches.
>>
>>> You all were throwing huge numbers of patches here for this tiny driver
>>> and digging through the mess was a major pain.
>>
>> That statement is doing nothing but trying to deflect the blame for
>> this mistake on to other people.
>>
>> 11 or 12 patches is not "huge numbers of patches" and a driver of 2600
>> lines is not "tiny".  In total, it's _only_ 11 + 12 patches.  That is
>> not "huge" by any sense of the word.
>>
>> What would you prefer?  One patch making multiple changes?  Aren't we
>> always telling people to split up their changes?  I guess you're
>> different because of your patch load...
> 
> There were more than just these two series of patches for this driver
> floating around in my todo queue, there were competing sets of patches
> from Timur and you and I thought I had applied the correct one.  I get
> things wrong sometimes, but after I did it took a long time for a fix to
> show up.  Yes, due to the hollidays, I get it, I've been very busy with
> non-kernel-stuff for the past months and I'm way behind as well.
> 
> And don't be snarky about splitting up patches, that wasn't the issue
> here.
> 
>>> Turned out I guessed
>>> wrong, and asked for a patch to fix up the mess once that was
>>> determined.
>>
>> I don't see why there should've been any guessing.  One series of 11
>> patches posted on 3rd November vs a second series of 12 patches posted
>> on the 16th November.  Later date, one more patch.  How could there
>> have been any guessing?
> 
> I don't remember, sorry, but something confused me, I got it wrong,
> sorry.  First time for 2015, not too bad :)
> 
>>> If you all think you could do better with the patch load you all were
>>> throwing at me, well, good for you.  It's mighty easy to complain when
>>> it isn't your inbox...  And I really don't care at all about this little
>>> driver, you all do, and yet you all can't agree what to do about it, so
>>> to somehow claim that I know better is a joke.
>>
>> Right, so what you're saying is that you're overloaded, and can't cope
>> with the amount of work that you've chosen to take on.
> 
> Again, I had real-world things keeping me from doing a lot of kernel
> patch review for the past few months, so I got behind, sorry.
> 
>> The one thing that's missing from your message is to ask whether
>> someone is willing to take on maintanence of the driver.  Well, that's
>> an interesting subject, because in theory, I _never_ delegated
>> maintanence and patch handling to anyone else:
>>
>> ARM PRIMECELL UART PL010 AND PL011 DRIVERS
>> M:      Russell King <linux at arm.linux.org.uk>
>> S:      Maintained
>> F:      drivers/tty/serial/amba-pl01*.c
>> F:      include/linux/amba/serial.h
>>
>> but someone decided "I own drivers/tty..., so all patches _must_
>> come through me" which is a frequent pattern I've seen forming over
>> the years that we've had the kernel in SCMs.
> 
> "decided"?  Hah, as if, that happened many years ago, that's nothing new
> at all, you didn't suddenly realize this, again, stop it with the snark.
> 
>> So, I guess the answer is for me to take back responsibility for
>> merging patches for this driver and send pull requests for it
>> directly to Linus.
> 
> That's not how kernel development works, sorry, you know this.  I'll
> gladly just ignore all amba-pl01* patches except when you bundle them up
> and forward them on to me.  In fact, I'll take pull requests as well,
> just send them on to me please whenever you feel they are ready for
> inclusion.
> 
> And good luck trying to get Linus to take pull requests for a single
> driver, that sure doesn't scale :)
> 
>> Please merge what you have, and when it's merged, I'll resolve the
>> differences between what you have merged and what _should_ have been
>> merged.  I'll send fixes directly to Linus, and from then on I'll be
>> looking after this driver.
> 
> I've merged the fixes now, and only have one old patch from Timur about
> adding cpu_relax to the driver, and there's some random AMBA bus patches
> that touch it as well, which comments from the "ARM developers" have
> been asked for, but don't seem to be happening for some odd reason...
> 
> greg k-h


The sad part about this whole mess is that it simply recapitulates
(in the biological sense) the state of this driver this summer requiring the
same earlycon fix which I wrote and sent Aug 10 [1]
*except that ZTE support still isn't working*.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363369.html