On Wednesday, March 25, 2015 11:24:11 AM Will Deacon wrote: > On Tue, Mar 24, 2015 at 10:02:53PM +0000, Grant Likely wrote: > > On Thu, 19 Mar 2015 19:39:27 +0000 , Will Deacon <will.deacon@xxxxxxx> > > wrote: > > > On Thu, Mar 19, 2015 at 10:17:27AM +0000, Lorenzo Pieralisi wrote: > > > > Not only that, Sudeep has a patch to consolidate DT and ACPI SMP code, > > > > I am working on it, I do not think it should be a blocking point, patch > > > > coming asap on top of your series. > > > > > > Well, I don't really want to merge the series without those patches so I > > > do think it blocks the code from getting into mainline. > > > > Really? It's a pretty minor duplication problem and it's been identified > > as something requiring refactoring to both the ACPI and DT code. It > > isn't at all dangerous. Why is this a blocking point? > > Because I don't really see a valid excuse not to get this right first time > around. Lorenzo already has patches on top, so we just need a co-ordinated > review effort. > > I wouldn't accept another patch series that needed minor rework (which by > its very nature is easily addressed), so why should ACPI be treated any > differently? Not ACPI, but this particular patchset I think. The problem is that it has already been reviewed and ACKed by multiple people and it would be a shame to require all of those people to do their reviews once again because of that minor rework (which arguably can be done on top of the patchset just fine). Of course, if the minor rework in question would not involve the need to review things once again, then I agree that it'd be better to do it upfront, but otherwise there's a good reason not to. And, as a maintainer, you can always say "Well, I'm taking this conditional on doing this-and-that on top of it and I won't be taking any more patches from you in the future if that doesn't happen." -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
