Hello Jonathan, Thx for the very long explanation.
Anyhow, the philosophy was: preenable -> stuff related to getting ready for buffered operation. This might be as simple as turning off something else that prevents buffered operation. Often this is simply not provided as there is nothing useful to be done. update_scan_mode -> get the scan mode set up right for all the buffers being feed by the iio_push_to_buffers calls. postenable -> Actually start the flow of data now all the flags are lined up to say we are enabled. So in a typical triggered-buffer case call iio_trigger_attach_poll_func
Usually our drivers use prenable() for starting the data flow and postdisable() to stop it. Do you think it is a mistake? Or acceptable?
For the disable side: predisable unwinds postenable and postdisable typically unwinds preenable.
Yes, that's clear. Regards, Arm -- 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
