On Tue, Feb 03, 2009 at 11:02:31AM +0000, Steve.Glendinning@xxxxxxxx wrote: > Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote on 03/02/2009 > 08:10:42: > > On Mon, Feb 02, 2009 at 03:57:45PM -0800, Tony Lindgren wrote: > > > * David Miller <davem@xxxxxxxxxxxxx> [090202 13:45]: > > > > Well, the SMSC driver is there already in the tree. > > > > > > > > The only thing not currently being scheduled to hit > > > > 2.6.29-rcX are the recent changes to support platform > > > > specified interrupt flags and all of that stuff. > > > > > > > > If you want, we can look into pushing that work into > > > > 2.6.29-rcX > > > > > > That would be great, more platforms to test it on. > > > > Mainline during the -rc series is not for pushing stuff to get > additional > > testing. It's for resolving regressions and fixing bugs, not > introducing > > changes which could cause regressions and bugs. > > Does it help that the smsc911x driver is new this cycle? No. > Without these patches the driver fails to register its interrupt on many > arm platforms, so it could be said that these patches do fix regressions > against the smc911x driver it's intended to replace. As far as I'm aware, the smc911x driver works as is on the majority of ARM platforms. The fact that it works is enough justification to leave well alone during the -rc series. Changing it involves risk that something will break, which will cause a regression. This is not a risk that we want, and we certainly don't want any new regressions in the -rc series. The proper time to take that risk is during the merge window. > On a related note, if these go in during the next merge window, is there a > mechanism for ensuring the platform support patches in the set are merged > after these? No, and that's the problem with splitting it across two separate trees, which is a point I was trying to make when these patches first came to my attention. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
