On Sun, Oct 24, 2010 at 19:35, Jonathan Cameron wrote: > On 10/24/10 22:22, Mike Frysinger wrote: >> I've rebased all the drivers onto staging-next. ÂI've only fixed the API >> breakage due to the changes made after 2.6.36 (and fixed a few warnings). >> I've also run checkpatch across these. >> >> I have not however addressed any real feedback Jonathan has provided with >> regards to driver correctness or direction. ÂThat stuff I'm leaving up to >> Michael Hennerich since it's his job and he actually understands this. >> >> Where possible, I'd like to have drivers merged so as to avoid another >> round of "new API just broke all your drivers". ÂWe will still look into >> feedback given, but we'd like to focus on that rather than random `sed` >> changes as API names change. >> >> This patchset supersedes all other "new driver" patches I've posted in the >> last 48 hours. > > As we are still in staging, I'm happy to see these merge into IIO with some provisos > (this wouldn't be acceptable anywhere else in the kernel tree). > > * We will be breaking abi's and probably even config symbol names cleaning these up. > ÂSo if your customers start complaining you get to explain why to them :) it wont be an issue. we make it clear to people who use the IIO stuff that this is in heavy development and people have been OK with that. > * We sought out some test coverage for these. I want someone I can poke if we > Âget a bug report, happy to use a generic address as long as someone is able > Âto respond in reasonable time! (no complaints so far with Analog, but this is > Âa lot of new devices for someone to have wired up somewhere) i can add a MAINTAINERS entry for all ADI IIO drivers if that's sufficient. any question about using Linux and an ADI part we are happy to answer. > * If Randy or any one else reports build issues with weird combinations, someone > Âother than me quickly fixes them. i think the MAINTAINERS would cover this too > * I want some proper proposals of abi's for the new classes of device. Lets debate > Âthese on list. I would probably get round to doing this myself eventually, but > Âif someone who knows the device class does it, things will proceed much faster. > ÂI've never used a resolver and had to google what they were ;) > ÂHaving poorly defined abi's has bitten us a few times in the past and tends to > Âput others off using the subsystem. ÂSo lets at least bash out what they should > Âbe even if it takes a little while to bring the drivers up to date. that'd be for Michael Hennerich > * As per standard staging rules, I will ask Greg to drop any driver that no one is > Âwilling to support. ÂI will give plenty of warning of course! np > * Some of the temp chips might want to be in hwmon. I would like to see an open > Âdiscussion across both lists of whether then should be in IIO or there (or both). there has been discussion in the past in this regard. but i dont recall where it occurred. > The negatives of merging this set as is are that people might copy code with issues > we haven't fixed yet. ÂSuch is life I guess. We could put a big note in the TODO > file, but then, who reads that? we have a tracker where we log all device driver feedback and assign to developers: https://blackfin.uclinux.org/gf/project/device-drivers/tracker/ -mike -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
