For Android requirment, virtio-scmi axis descriptor should
support extended attributes. This patch does this things.
We get axis's resolution during reading "scale" and store.
When agent wants to get axis descriptions,
device will add resolution value to extend attribute field.
At the same time, max and min range also have been configured.
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
In order to support extended attributes, in flow of
handle command SENSOR_AXIS_DESCRIPTION_GET, it should
report frontend the axis info one by one instead of together,
for reason that it will exceed the size of descriptor buffer size.
And this patch also fixs the wrong value number of
remaining sensor axis descriptors.
The remaining value should excludes reported axis.
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
The new version of clippy in the CI suggested several improvements.
Some fixed with `clippy --fix`, some by hand.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
eventqueue notification for sensor device is not implemented before.
It adds a initial version to implement this feature.
Now input event can be captured and dealt.
At the beginning, we open all scmidevices which can do notification.
For example:
open /dev/iio:deviceX during VuScmiBackend initializtion.
And in function register_device, we create "device_identify" for each devices.
If this device can do notificaiton,
insert this identify into ScmiHandler event_fds hashmap.
After that, register all those devices with an increasing device_event.
For this reason, we need to change SensorT trait.
And add Option<File> which is used for those notifiable Sensor in trait SensorT.
For instance, iio devices support notification if "/dev/iio:devixeX" exist,
which should implement them.
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
In function read_axis, there are two steps.
The first is reading number for sysfs file.
The second is reading offset and scales.
And the second step can be reused in notification,
therefore we separate it into two functions.
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
According to the document of "System Control and Management Interface",
The sensor_value_low and sensor_value_high in
SENSOR_READING structure shoud be int32 instead of uint32.
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
There is an error spell for gyroscope sensors
which provides attribute named "anglvel"
instead of "anglevel".
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
If vhost-device-scmi running with name argument,
do not set name again.
If not, use value from fs, otherwise use default name.
It can avoid that program exit unexpectedly
when the length of native sensor name is too long.
Correspondingly, modify related unit test function.
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
SensorT methods invalid_property and process_property are unused and
the compiler complains about the fact.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Fix the following clippy warning:
warning: accessing first element with `configs.get(0)`
--> vhost-device-vsock/src/main.rs:410:22
|
410 | let config = configs.get(0).unwrap();
| ^^^^^^^^^^^^^^ help: try: `configs.first()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#get_first
= note: `#[warn(clippy::get_first)]` on by default
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Commit b37e7e5709 changed how
the --help-deices text output was used inadvertently by including it by
default in the help output. Restore the --help-devices argument and make
it exclusive: you cannot combine it with other arguments. This way,
socket_path does not have to be an Option<PathBuf>.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Use clap's derive attributes to print device help instead of doing it
manually with the parsed arguments.
Previous output
===============
```text
Usage: vhost-device-scmi [OPTIONS]
Options:
-s, --socket-path <SOCKET_PATH> vhost-user socket to use (required)
-d, --device <DEVICE>... Devices to expose
--help-devices Print help on available devices
-h, --help Print help
```
New output
==========
```text
vhost-user SCMI backend device
Usage: vhost-device-scmi [OPTIONS] --socket-path <SOCKET_PATH>
Options:
-s, --socket-path <SOCKET_PATH> vhost-user socket to use
-d, --device <DEVICE>... Devices to expose
-h, --help Print help
-V, --version Print version
Available devices:
- iio: industrial I/O sensor
Parameters:
- path: path to the device directory (e.g. /sys/bus/iio/devices/iio:device0)
- channel: prefix of the device type (e.g. in_accel)
- name: an optional name of the sensor, max. 15 characters
- fake: fake accelerometer
A simple 3-axes sensor providing fake pre-defined values.
Parameters:
- name: an optional name of the sensor, max. 15 characters
Device specification example:
--device iio,path=/sys/bus/iio/devices/iio:device0,channel=in_accel
```
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
clap can parse a PathBuf directly from the command line arguments, and
paths are not always UTF-8. Use PathBuf instead of a String to allow for
all valid filesystem paths.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Since everyone copied the first bits of code from the I2C crate, the
same issue is present almost everywhere. The returned value isn't
checked at all by the callers. Stop returning bool unnecessarily.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
This become available with the recent vhost-user-backend [1] updates and
allows to get rid of some boilerplate code.
[1] https://github.com/rust-vmm/vhost/pull/173
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
- Features were renamed from slave -> backend
- Generics got simplified
- Some write and read functions on Volatile slice got turned into
standalone traits: ReadVolatile, WriteVolatile
- handle_event no longer returns a bool
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Having all the workspace crates under the crates/ directory is
unnecessary. Rust documentation itself recommends all crates to be in
the root directory:
https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html#creating-the-second-package-in-the-workspace
I paste the text content here, in case the online page ever changes or
becomes unavailable:
## Creating the Second Package in the Workspace
Next, let’s create another member package in the workspace and call it add_one. Change the top-level Cargo.toml to specify the add_one path in the members list:
Filename: Cargo.toml
[workspace]
members = [
"adder",
"add_one",
]
Then generate a new library crate named add_one:
$ cargo new add_one --lib
Created library `add_one` package
Your add directory should now have these directories and files:
├── Cargo.lock
├── Cargo.toml
├── add_one
│ ├── Cargo.toml
│ └── src
│ └── lib.rs
├── adder
│ ├── Cargo.toml
│ └── src
│ └── main.rs
└── target
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>