Sending an SR_DF_META packet at the start of every stream is not
mandatory; the frontend should ask for what it needs, and any extra
information the driver wants to send will come in due time.
commit 378abfeac6 tried to solve a bug where
the fx2lafw driver would print "Device came back" even if a timeout had occured.
It solved that issue, but inadvertently introduced a new bug:
"Device came back" would be printed even if no firmware upload was performed.
This is counterintuitive, as the device is only reset when a firmware upload is
performed.
There are three cases:
i) Firmware upload was successful
ii) Firmware upload failed
iii) Firmware upload was NOT needed
Each case warrants a separate message from the driver. Print the
following messages depending on the outcome:
i) "Device came back"
ii) "Device failed to renumerate"
iii) "Firmware upload was not needed."
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the new DRIVER_LOG_DOMAIN mechanism, where explicitly writing
the driver name in the message string is no longer required.
Thus:
- sr_err("fx2lafw: Something bad happened.");
becomes:
+ sr_err("Something bad happened.");
In either case, the log output is the same.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In the case of USB drivers, a driver's dev_acquisition_stop() cannot
simply remove its fd sources from the session and close its devices:
a USB transfer might still be underway, and it needs to be finished
(and its memory freed) properly.
An sr_dev_inst->status value is added: SR_ST_STOPPING, which should
be set when the driver's dev_acquisition_stop() is called, and acts
as a marker for the USB event handler to wind up its operations.
In order for dev_acquisition_stop() to be able to set the sdi status,
however, it needs to be unconstified.
These are used to list the device instances currently known to the driver,
and clear that list.
Drivers that don't necessarily clear their list of instances on every scan,
such as genericdmm, need to provide these to the frontend to keep instance
management sane.
Since probes now live in a struct sr_dev_inst owned by the driver, it
already knows about them. Instead of a frontend telling the driver to
configure probes, all driver now do this just before starting acquisition.
It's obsolete: no frontend ever used it, and neither did libsigrok.
The sdi->status field is only used internally by some drivers, and
should probably be moved to the driver-specific context structs.
This changes the semantics of the init() call as well. That now only
initializes the driver -- an administrative affair, no hardware gets
touched during this call. It returns a standard SR_OK or SR_ERR* code.
The scan() call does a discovery run for devices it knows, and returns
the number found. It can be called at any time.
It was actually used in one way: the session file loaded abused it for
passing in the filename -- something it definitely wasn't intended for.
This now uses the proper way to pass arguments to a driver: the new
SR_HWCAP_SESSIONFILE.
The OLS driver could also use it as an indication of the serial port to
use instead of actively probing all serial ports on the system, but there
wasn't any frontend code that passed in such a parameter, making it
entirely useless. That will soon be handled differently with the new
scan() API call, regardless.
Bert Vermeulen
Alexandru Gagniuc
Uwe Hermann
Joel Holdsworth
Peter Stuge
Ivan Fedorov