Mike Frysinger wrote on 2010-10-25: > 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. We will actively support these drivers. I'm currently in progress building up a team, which will ensure that these drivers are tested and maintained over time. >> * 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 We can start debating and refining on the exact API, to use. However I like to do so once these drivers have merged. The ones likely subject to change we can mark as EXPERIMENTAL. Or even print a warning using dev_warn() on probe. >> * 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 Greetings, Michael Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif ÿô.nÇ·®+%˱é¥wÿº{.nÇ·¥{±þ(¨þ)íèjg¬±¨¶Ýjÿ¾«þG«é¸¢·¦j:+v¨wèm¶ÿþø®w¥þ࣢·hâÿÙ