Set this new parameter to 0 (no timeout) at every call site. This is
consistent with previous behaviour, so cannot cause any regressions.
Waiting forever for a serial operation is clearly always wrong. Without
specific knowledge of each device and driver however, I can't choose
appropriate timeouts for each call. The maintainers of these drivers
will need to do so, and also add appropriate handling of timeouts.
When this commit is merged, a bug should be entered for each driver
that is touched by it.
Every driver now publishes its device option config keys, i.e. the
list fetched with sr_config_list(SR_CONF_DEVICE_OPTIONS), with a
set of flags indicating which methods are implemented by the driver
for that key.
The config keys are OR'ed with any combination of SR_CONF_GET,
SR_CONF_SET and SR_CONF_LIST. These are defined as the high bits
of the uint32_t config key. Clients can OR config keys with
SR_CONF_MASK to strip out these bits. This mask will be kept up to
date if other bits are added to the capabilities list; clients MUST
therefore use SR_CONF_MASK for this.
Some keys don't have capability bits added, such as the informative
device type keys (SR_CONF_MULTIMETER, SR_CONF_OSCILLOSCOPE, ...) and
SR_CONF_CONTINUOUS.
Scan options do not have capabilities bits.
Martin Ling
Soeren Apel
Bert Vermeulen