On Mon, Jun 27, 2016 at 4:30 AM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: > On 06/26/2016 05:13 PM, Jonathan Cameron wrote: >> On 22/06/16 09:02, Lars-Peter Clausen wrote: >>> On 06/11/2016 06:48 PM, Jonathan Cameron wrote: >>>> On 03/06/16 13:33, Jonathan Cameron wrote: >>>>> On 30/05/16 02:37, Matt Ranostay wrote: >>>>>> Add initial driver support for MAX6675, and MAX31885 thermocouple chips. >>>>>> >>>>>> Cc: Marek Vasut <marex@xxxxxxx> >>>>>> Cc: Matt Porter <mporter@xxxxxxxxxxxx> >>>>>> Signed-off-by: Matt Ranostay <mranostay@xxxxxxxxx> >>>>> I'm going to let this sit for a sort while as I'd like some discussion >>>>> of the invalidate buffer bit. >>>>> >>>>> Cc'd a few more people for views. >>>> Hmm. Deadly silence. >>>> >>>> Daniel, Lars, Peter - this is a fairly fundamental abi question. >>>> >>>> What do we do to signify an 'invalid reading' in the buffer. >>>> >>>> Here the part is driven by a software trigger - and if we skip >>>> a reading we are obviously out of sync. >>>> >>>> Old and nasty trick we used in some (possibly only one) >>>> early driver was to set an invalid state for these cases. >>>> >>>> Anyone have a better idea? >>> >>> Ideally the driver would leave the data including the status bit intact and >>> not replace it with a magic constant that way an application that is aware >>> of the way the chip behaves could handle that. >> >> In response to what I'd misunderstood this as: >> >> It's tricky as the status bit is not in general in the same register as the >> value. We would need to add a meta data element to the buffer to handle this. >> >> I'm inclined to go with the magic value as the best 'general purpose' option >> we have right now... I don't like it, but adding meta data is also somewhat >> hideous as most usecases and devices wouldn't use it. > > The thing is the application needs to be aware of the magic value and its > meaning for this particular driver anyway. So we might as well just expose > the raw value without doing any processing. From an applications point of > view there is no difference and application that is aware of it can handle > it, an application that is not can't. So Jonathan should I resubmit with the original functionality of passing the raw buffer, and along with the bugfixes? > -- 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
