On Thu, May 19, 2016 at 1:25 AM, Daniel Baluta <daniel.baluta@xxxxxxxxx> wrote: > On Thu, May 19, 2016 at 8:58 AM, Jonathan Cameron > <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >> >> On 19 May 2016 04:38:09 BST, Matt Ranostay <mranostay@xxxxxxxxx> wrote: >>>Jonathan et al, >>> >>>Shortly going to be doing a project that requires an iio_map mapping >>>for using an iio channel input from an ADC. I've notice all seem to >>>be platform_data or hardcoded due to it being a SoC or statically >>>known MFD mapping. >>> >>>For my application it isn't correct to create an hardcoded iio_map >>>mapping with the ADC driver (ti-ads1015) since nobody else would care >>>about it, and wouldn't help in the case of multiple instances of the >>>same ADC. >>> >>>But I would rather avoid the technical debt and uglyness of using a >>>board file. >>> >>>What would be the best way via ACPI and DT to define channel mappings >>>between name, consumers, and consumer channel names? Thought I request >>>input here before I make any core iio subsystem changes. >>> >>>Thanks, >>> >>>Matt >> >> Whilst we have gotten a fair bit of grief over the Linux specific nature of the >> binding, iio-hwmon does have bindings for this sort of case. >> >> Mid term I have been wondering about taking it as far as having a configfs >> interface to create such soft hardware mappings at runtime.... > > +1 for configfs, would be the most flexible way for users. Then I suppose the consumer driver would need to return -EIO or similar until the user has setup the mapping with configfs? Also I suppose we could add configfs setup for the gpio interrupt trigger that uses platform data currently. Although not sure it would be sane to be touching interrupt-controllers from userspace. -- 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
