On Fri, 24 Oct 2008 00:38:12 -0700 "ext David Brownell" <david-b@xxxxxxxxxxx> wrote: > > My set was basically doing all gpiolib conversions in one patch and the > > set was grouped so that one patch for all OMAP1 boards (all of them are > > in mainline), separate patches for couple OMAP2 boards and some random > > patches for different drivers. > > I've found that splitting such API changes into blatantly obvious > chunks that make the same repetitive change is a big win in terms > of reviewability and buglessness. The first two patches (get/set, > direction_in) show that well. The other two followed naturally from > that start, but weren't as brainless. The request/free stuff needed > some actual thought, so I deferred it... > > Did you find anything wrong with these patches? > Nope. My way was just bit more lazy by doing all changes into one file at once and by separating patches so that it's easier for Tony to get them forward. > I'd split that work in two phases: > > - First a set of gpio_chip.request() and gpio_chip.free() hooks > to make the standard calls *exactly* like the legacy ones, > and replacing the legacy calls with inlined wrappers; > > - Then then lots of syntactic changes to use the new calls, > providing labels and then removing those wrappers. > > If you'd like to do those parts, OK by me. Splitting things > out into different gpio_chip flavors can be done in parallel > with the second set of patches. > Yeah, I'll try to look next week. Jarkko -- 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
