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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> > > > > > > > > > > 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@xxxxxxxxxxxxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
