On 05/12/14 14:33, Ezequiel Garcia wrote: > > > On 12/05/2014 10:25 AM, Jonathan Cameron wrote: >> On 05/12/14 13:12, Jonathan Cameron wrote: >>> >>> >>> On December 5, 2014 11:55:40 AM GMT+00:00, Ezequiel Garcia <ezequiel.garcia@xxxxxxxxxx> wrote: >>>> Hi Jonathan, >>>> >>>> On 11/27/2014 12:39 PM, Ezequiel Garcia wrote: >>>>> Changes from v4: >>>>> >>>>> * Added a compile-time dependency on REGULATOR and HAVE_CLK. >>>>> >>>>> * Replaced the silly XOR operation for a proper mask out of the >>>>> available channels. >>>>> >>>>> Changes from v3: >>>>> >>>>> * Fixed a few style nitpicks as per Hartmut's feedback. >>>>> >>>>> * Used GENMASK() to build the channel mask, which fixes a very >>>> nasty >>>>> bug. Also found by Hartmut. >>>>> >>>>> Changes from v2: >>>>> >>>>> * Changed a devicetree property from adc-available-channels to >>>>> adc-reserved-channels, so it can be made optional. >>>>> >>>>> * Renamed the driver from cc_10001_xxx to cc10001_xxx so it's >>>> consistent >>>>> with the rest of the kernel style. >>>>> >>>>> * Some more minor cosmetic fixes. >>>>> >>>>> Changes from v1: >>>>> >>>>> * Removed unneeded header includes. >>>>> >>>>> * Changed all the names and macros prefix: s/CC_10001_/CC10001_. >>>>> >>>>> * Used .update_scan_mode callback to preallocate the buffer. >>>>> >>>>> * Used indio_dev for the struct iio_dev. >>>>> >>>>> * Only read the regulator voltage when needed. >>>>> >>>>> * Fixed probe() error handling. >>>>> >>>>> * Used for_each_set_bit() instead of open-coding it. >>>>> >>>>> * Name the power-down register as _POWER_UP, to make the code >>>>> less silly. >>>>> >>>>> * Error out when no valid sample can be read (i.e. when >>>> end-of-conversion >>>>> poll times out). >>>>> >>>>> * ... plus some assorted code cleaning based on the feedback. >>>>> >>>>> >>>>> Ezequiel Garcia (1): >>>>> DT: Add a vendor prefix for Cosmic Circuits >>>>> >>>>> Phani Movva (2): >>>>> iio: adc: Cosmic Circuits 10001 ADC driver >>>>> DT: iio: adc: Add CC_10001 binding documentation >>>>> >>>> >>>> Unless there are any outstanding issues with this series, it'd be great >>>> to merge it for v3.19. >>>> >>>> Thanks! >>> Sorry too late unfortunately. Merge window opens on Sunday and stuff needs to have >>> been in Greg KH's tree for a week before that. Going to be 3.20 now. >>> > > Oh, shoot. I was hoping to be in time for the merge. Being a new driver > there wasn't much harm in taking it earlier. > >> Also, the DT patch could really do with an Ack from Rob. If Hartmut/Lars >> want to give a reviewed-by that would be good given they done the legwork >> on reviewing your driver. >> >> Looks good to me btw. Just taken a quick look, but little gets past those >> guys anyway :) >> > > If at all possible, do you think you area able to pick the patches now > (but you don't include them in your pull request to Linus) so they are > linux-next? It'd be good to know they start getting build-test coverage > soon. Sorry no can do until 3 weeks have passed for the device tree bindings or a dt maintainer acks. So might be about 2 more weeks I'm afraid. Also it's heavily frowned upon to put stuff in linux next at this point in the cycle. Best to wait until merge window closes. Note I only feed linux-next via Greg KH's tree anyway (stuff doesn't stay in mine normally for more than a week or so, hence little gain in a direct pull). Jonathan > > Thanks! > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
