On 02/20/2013 07:24 PM, Guenter Roeck wrote: > On Wed, Feb 20, 2013 at 06:51:08PM +0000, Jonathan Cameron wrote: >> >> >> Guenter Roeck <linux@xxxxxxxxxxxx> wrote: >> >>> On Wed, Feb 20, 2013 at 11:38:22AM -0600, Rob Herring wrote: >>>> On 02/07/2013 11:09 AM, Guenter Roeck wrote: >>>>> Provide bindings and parse OF data during initialization. >>>>> >>>>> Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx> >>>>> --- >>>>> v5: >>>>> - Updated examples in bindings. >>>>> v4: >>>>> - Fixed wrong parameter to dummy of_iio_channel_get_by_name if >>> CONFIG_OF is >>>>> undefined, and wrong return value. >>>>> - Initialize indio_dev->of_node in iio_device_register if the >>> calling driver >>>>> neglected to do it. >>>>> v3: >>>>> - Cleaned up documentation (formatting, left-over clock references) >>>>> - Updated bindings description to permit sub-devices >>>>> - When searching for iio devices, use the pointer to the iio device >>> type instead >>>>> of strcmp. Rename iio_dev_type to iio_device_type (to match other >>> device >>>>> types) and make it global for that purpose. Check the OF node >>> first, then the >>>>> device type, as the node is less likely to match. >>>>> - Move the common code in of_iio_channel_get and >>> of_iio_channel_get_all to >>>>> __of_iio_channel_get. >>>>> - Return NULL from of_iio_channel_get_by_name if nothing is found, >>> or >>>>> an error if there is a problem with consistency or if the >>> provider device is >>>>> not yet available. >>>>> - In iio_channel_get, return if of_iio_channel_get_by_name() >>> returns a channel >>>>> or an error, and continue otherwise. >>>>> v2: >>>>> - Rebased to iio/togreg >>>>> - Documentation update per feedback >>>>> - Dropped io-channel-output-names from the bindings document. The >>> property is >>>>> not used in the code, and it is not entirely clear what it would >>> be used for. >>>>> If there is a need for it, we can add it back in later on. >>>>> - Don't export OF specific API calls >>>>> - For OF support, no longer depend on iio_map >>>>> - Add #ifdef CONFIG_OF where appropriate, and ensure that the code >>> still builds >>>>> if it is not selected. >>>>> - Change iio_channel_get to take device pointer as argument instead >>> of device >>>>> name. Retain old API as of_iio_channel_get_sys. >>>>> - iio_channel_get now works for both OF and non-OF configurations >>>>> - Use regulator to get vref for max1363 driver. >>>>> >>>>> .../devicetree/bindings/iio/iio-bindings.txt | 97 >>> +++++++++++ >>>>> drivers/iio/iio_core.h | 1 + >>>>> drivers/iio/industrialio-core.c | 8 +- >>>>> drivers/iio/inkern.c | 171 >>> ++++++++++++++++++++ >>>>> 4 files changed, 275 insertions(+), 2 deletions(-) >>>>> create mode 100644 >>> Documentation/devicetree/bindings/iio/iio-bindings.txt >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt >>> b/Documentation/devicetree/bindings/iio/iio-bindings.txt >>>>> new file mode 100644 >>>>> index 0000000..1182845 >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt >>>>> @@ -0,0 +1,97 @@ >>>>> +This binding is a work-in-progress. It is derived from clock >>> bindings, >>>>> +and based on suggestions from Lars-Peter Clausen [1]. >>>> >>>> Bindings are an ABI. It should not be a WIP. What part is a WIP? >>>> >>> The text is copied from clock bindings. I do not claim to be better >>> than the clock subsystem is doing in respect to its bindings. >>> >>> I'll be more than happy to take this text out if it is a source of >>> contention, >>> even more so if that is what is holding up the patch. Jonathan ? >> I don't really care about the wording though can see why Rob asked! >> We will probably have other stuff to add anyway. >> > > Quite likely - for example, I did not add io-output-names since I did not > know what to do with it. > > What do you want me to do ? Submit another version with the sentence deleted, > or keep it as-is ? Keep as is. Thanks, Jonathan -- 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
