Running `./tools/checkpatch.sh -g` on this file reported seven pre-existing
style errors. Fix them so that the file passes nxstyle cleanly:
- Add the missing blank line after the declarations in sensor_lock(),
sensor_unlock(), sensor_update_interval() and sensor_generate_timing().
- Indent the SNIOC_GET_EVENTS and SNIOC_FLUSH case labels with six spaces
like the other twelve case labels of the same switch.
- Drop the two extra spaces in front of the poll_notify() call in
sensor_poll().
Whitespace only, no functional change: the file is byte identical once all
whitespace is stripped.
Signed-off-by: likun17 <likun17@xiaomi.com>
Cover the remaining electrical quantities so that they do not have to fork
into driver private namespaces later. Add SENSOR_TYPE_RESISTANCE (Ohm),
SENSOR_TYPE_CONDUCTIVITY (S/m), SENSOR_TYPE_ENERGY (J) and
SENSOR_TYPE_CHARGE (C), the last two matching the native unit of the
accumulator registers in power and energy monitors.
Signed-off-by: likun17 <likun17@xiaomi.com>
uORB has no type for electrical quantities, so power monitors can only use
the legacy character drivers, which are deprecated and report their values
in three incompatible unit systems. Add SENSOR_TYPE_VOLTAGE,
SENSOR_TYPE_CURRENT and SENSOR_TYPE_POWER with their message structs in SI
units (V, A, W).
Signed-off-by: likun17 <likun17@xiaomi.com>
Adds a section covering CONFIG_SENSORS_LSM6DS3TRC_FIFO: what it changes
(one interrupt/I2C read per watermark instead of per sample) and its
three limitations while it's on -- both sub-sensors forced to the same
ODR, temperature no longer per-sample (one read per drain applied to
the whole batch), and both sub-sensors must stay physically enabled
regardless of subscription, since the chip's FIFO write trigger needs
both running -- plus the watermark/ORB-buffer-size relationship callers
need to respect.
Also documents a related chip quirk found during bench testing:
diff_words reads 0 at the exact moment a real FIFO overrun occurs, even
though the FIFO is still completely full of valid, retained data (a
forced read past that point recovers real samples, not garbage). This
isn't a bug in this driver: ST's own engineers confirm the same
behavior for this chip family on their community forum (thread
"LSM6DS3 FIFO status clarification", td-p/184022), and the mainline
Linux st_lsm6dsx driver doesn't attempt to recover from it either -- it
only special-cases an empty FIFO, not an overrun one. Documenting this
in a comment rather than adding recovery logic: with the small
watermark this driver uses, reaching a real overrun at all means the
drain has already fallen many seconds behind, and ST's own guidance for
this condition is to avoid it via watermark sizing rather than recover
from it.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Hardware testing (single-topic FIFO subscriptions, register dumps via
manual i2c commands) turned up two independent bugs that together
made the FIFO silently never accumulate data for a single-topic (e.g.
accel-only) subscription, while showing FIFO_STATUS2 stuck reporting
OVER_RUN and FIFO_FULL_SMART with a simultaneous zero DIFF_FIFO count:
- The LSM6DS3TR-C's FIFO write trigger (data-ready-based, the only mode
this driver uses) only fires while BOTH the accelerometer and the
gyroscope are physically running, regardless of which one(s) are
actually decimated into the FIFO pattern -- confirmed in the
datasheet's FIFO section ("the ODR must be lower than or equal to
both the accelerometer and gyroscope ODRs") and reproduced by
register-level testing with the unsubscribed sensor powered down vs.
powered up. lsm6ds3trc_fifo_configure() now forces whichever
sub-sensor isn't subscribed to run at the shared rate anyway (still
excluded from the pattern, so this costs no extra I2C bandwidth on
drain, just that sensor's own unavoidable power draw), and brings it
back down once neither sub-sensor is subscribed.
- Separately, lsm6ds3trc_fifo_configure() reconfigured decimation,
watermark and ODR while the FIFO was still running in Continuous
mode from a previous configuration. Reproduced manually: reconfiguring
live leaves FIFO_STATUS1/2 stuck reporting a stale diff count even
once the trigger fix above is in place; resetting through Bypass mode
first (which also empties the FIFO) before writing the new settings,
the same procedure the datasheet documents for changing FIFO
settings, and only re-entering Continuous mode last, is what actually
gets the diff counter to track correctly.
Also fixes two bit-definition bugs found while cross-referencing the
real ST datasheet instead of the in-tree lsm6dsl.h header used as a
starting point: MASK_FIFO_DIFF_HI was 4 bits (0x0f) instead of the
documented 3 (0x07), and MASK_DEC_FIFO_XL/SHIFT_DEC_FIFO_GY assumed
2-bit decimation fields instead of the documented 3-bit ones.
Verified on hardware: accel-only, gyro-only, and both-topics
subscriptions all now drain cleanly at the configured watermark with
no overrun, sustained over tens of seconds of continuous streaming.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Previously, activate() always fell back to a hardcoded ODR_52HZ (or the
other sub-sensor's rate, in FIFO mode) whenever a sub-sensor went from
disabled to enabled, discarding whatever rate the application had
explicitly requested via set_interval() before disabling it. An
application that only ever wants, say, 25Hz would see the sensor
restart at 52Hz on every re-activation, and in FIFO mode this fills the
FIFO faster than intended, defeating the point of choosing a lower ODR
for power savings.
Add last_odr, which -- unlike odr -- survives being disabled. activate()
now restores it on the next enable, only falling back to ODR_52HZ on a
sub-sensor's genuine first-ever activation.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Interrupt-driven mode so far pushes one uORB event per physical sample:
one I2C burst read and one interrupt per sample, at whatever ODR the
topic is running. That's the dominant power cost for a
battery-constrained use case sampling continuously -- draining the
chip's FIFO in batches cuts both by roughly the watermark size.
The LSM6DS3TR-C's FIFO is the older ST "pattern" style (no per-sample
tag byte, unlike LSM6DSO/ISM330): FIFO_CTRL3's per-sub-sensor decimation
bits choose which of gyro/accel feed the FIFO (0 = excluded, 1 = no
decimation -- only 0/1 are used here), FIFO_CTRL5 sets one shared
FIFO-only ODR, and FIFO_STATUS1/2's DIFF_FIFO reports how many 16-bit
words are waiting. Reused the existing INT1 wiring, but switched from
DRDY (per-sample) to FTH (threshold reached) when
CONFIG_SENSORS_LSM6DS3TRC_FIFO is on -- new bool that's a whole-driver
mode switch, not a per-instance choice, so a board doesn't change; only
its Kconfig does.
lsm6ds3trc_fifo_configure() re-derives and writes the decimation bits,
FIFO ODR, and watermark threshold (in words = watermark-in-samples *
words-per-pattern, 3 with one sub-sensor active or 6 with both) from
current dev->gyro/accel enabled+odr state; called from activate() and
set_interval(). Both sub-sensors are forced to the same ODR while FIFO
is on -- decimation factors > 1 for independent per-topic rates is real
complexity (matching ODR ratios to decimation values) left for later.
lsm6ds3trc_fifo_worker() replaces lsm6ds3trc_worker() under the Kconfig
guard: reads DIFF_FIFO, bursts that many words (rounded down to a whole
pattern chunk, capped at 2x the configured watermark so a late drain
doesn't overflow the read buffer -- whatever's left over just waits in
the chip's own FIFO for the next drain), then walks the buffer decoding
each chunk into a push_event() same as before. FIFO entries don't carry
their own timestamp, so each one is interpolated backwards from the
ISR's timestamp by the configured ODR interval. Temperature isn't part
of the FIFO pattern (FIFO_TEMP_EN stays off to keep the pattern width
simple); one direct OUT_TEMP_L read per drain is applied to the whole
batch instead.
Validated on the bench, both pattern widths: with both topics
subscribed (6-word pattern) and with only the accelerometer (3-word),
samples arrive in watermark-sized bursts with interpolated timestamps
spaced by the exact configured ODR interval (52Hz -> 19230us between
every consecutive sample, matched exactly), sane accel/gyro values, no
I2C errors, no overruns, sustained for 15+ seconds continuous.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
No driver exists for this exact chip. lsm6dsl.c is the closest
register-compatible match but is the deprecated legacy char-device
style; lsm6dso32_uorb.c is the closest uORB-style match but is for a
different chip variant. The new driver borrows lsm6dso32_uorb.c's
structure (dual sensor_lowerhalf_s, raw I2C_TRANSFER helpers) and
lsm6dsl.h's register map -- fixing a bug in the header it was ported
from along the way: LSM6DSL_FIFO_CTRL2_SHIFT is defined as 255 instead
of 0.
Delivery mode is chosen the same way mpu6050 does: kthread polling by
default, or interrupt-driven if the board supplies attach(). Unlike
the earlier lsm6dso32-style design this went through first -- one INT
pin and one activate()/interrupt path per sub-sensor -- the shipped
version uses a single shared INT pin for both, mirroring mpu6050's own
one-handler-one-worker design (#19601) instead. The two-independent-
paths version worked for accel alone but was intermittently broken for
gyro: activate() sometimes never actually turned CTRL2_G on even
though the interrupt-enable bit was written correctly, and other times
the whole console hung -- a real race, never conclusively root-caused
on a serial console with no JTAG available. The LSM6DS3TR-C supports
OR'ing both DRDY_XL and DRDY_G onto one pin via independent enable
bits in that pin's INTn_CTRL register, so there was no need for two
paths in the first place: one ISR times the burst, one HPWORK worker
reads OUT_TEMP_L..OUTZ_H_A (14 contiguous bytes covering temp, gyro
and accel in one I2C transaction) and pushes whichever topic(s) are
currently subscribed. activate() now just flips each sub-sensor's own
bit in the shared register instead of running its own attach.
On the XIAO ESP32-S3 with Seeed's IMU Breakout Board, INT1/INT2 route
to GPIO3/GPIO4 (confirmed from the breakout board's schematic, not
guessed). Only INT1/GPIO3 is wired up, since one pin is now enough;
GPIO4/INT2 is documented as available but unused.
Also: CTRL1_XL's FS_XL bits were never actually written to match the
driver's own software default (4g) -- registration set the in-memory
value but the chip stayed at its 2g reset default until a caller
issued an explicit SNIOC_SETFULLSCALE. register() now writes it.
Validated on the bench, both modes, reproduced across multiple fresh
reboots: WHO_AM_I reads 0x6a, sensor_accel0/sensor_gyro0 stream
continuously. Interrupt mode delivers ~300 samples of each per 6s
window with shared timestamps down to the microsecond between the two
topics per event, confirming both come from the same burst read.
Assisted-by: Claude <noreply@anthropic.com>
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The TMP112 driver was character mode only, and carried the warning that
says so: a read returns a bare float, at a size the driver chose, and
nothing but code written for this one part can make sense of it.
Add the sensor framework version beside it, in the shape the tree
already uses for a part that has both. The old driver is untouched and
still builds by default; the new one replaces it when
SENSORS_TMP112_UORB is set, and the part then appears as a temperature
topic that the common sensor tools can read without knowing what a
TMP112 is.
It reads on the low priority work queue at whatever interval the caller
asks for. The part converts continuously out of reset, so nothing is
configured and the temperature register always holds the last completed
conversion: a reading is one bus transaction with nothing to wait for.
Reading faster than the part converts repeats a value, which costs bus
traffic and nothing else, so the interval is taken as given: the upper
half treats a lower half that hands back a longer interval than it was
given as a failed request, so clamping here would refuse a fast caller
rather than serve it slowly.
get_info reports what the part is and what its readings mean, so a
consumer need not know it is talking to a TMP112 to know the range and
the resolution.
It also sign extends the reading. The register holds twelve bits, and
the character mode driver treats them as unsigned, so anything below
freezing comes back as a large positive temperature; the part is
specified down to -40C. Fixing that in the old driver would change what
existing callers see, so it is fixed here, where there are no callers
yet to surprise.
This driver also covers the TMP102, which differs in accuracy rather
than in its registers: only the two both parts have are touched.
Documented under the sensors section, beside the other parts with a page
of their own, and listed among the uORB drivers.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A fetch() only lower half is always ready, so a subscriber that asked for
a rate with SNIOC_SET_INTERVAL got no pacing from poll(): the descriptor
reported POLLIN on every pass and the application had to sleep out the
period itself. That does not compose. An application polling several
topics reads them sequentially from one thread, so per read sleeps
serialize: three topics at 10 Hz sleeping 100 ms each yield 3.3 Hz per
topic rather than 10.
Pace it where poll() can act on it instead. A subscriber that never
requested a rate stays always ready, and one that did becomes ready once
per its own interval, driven by a watchdog armed in sensor_poll(). This
is the fetch() side of what sensor_is_updated() already does for a
pushing lower half, so both models now honor a requested rate the same
way.
The wdog_s lives in sensor_user_s rather than in the device, so each
subscriber is paced at its own interval instead of at the minimum across
all of them, and the timer only runs while somebody is polling. The
expiry runs in timer context and takes no lock: poll_notify() is safe
from an interrupt handler, and a teardown that raced it has already
cleared fds, which makes both the notify and the re-arm no-ops. Teardown
therefore just cancels the watchdog where it clears fds, and a watchdog
keeps this off the work queue entirely, which a fetch() only sensor
exists to avoid.
sensor_close() needs nothing of its own: poll_setup() holds a reference
on the file for the duration of the poll, so file_close() cannot run
until poll_teardown() has called sensor_poll() with setup false, and that
already cancelled the watchdog.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
A fetch() only lower half reads the device on demand, so its data is
always available and there is never anything to wait for. The upper half
did not reflect that: poll() only reported POLLIN when the descriptor was
opened O_NONBLOCK, and a blocking read() waited on buffersem, which is
only posted when the lower half drives notify_event from an interrupt of
its own.
A fetch() only sensor with no interrupt therefore never satisfied
poll()/read() at all. This is not hypothetical: in the in tree
nucleo-h563zi:dts configuration CONFIG_STM32_DTS_TRIGGER defaults to 0,
which selects stm32_dts_fetch(), and no CONFIG_STM32_DTS_ITEN_* option is
enabled, so the DTS interrupt never fires. A blocking read() on that
sensor waits forever, even though stm32_dts_fetch() performs a complete
software triggered measurement on its own and needs no interrupt at all.
Applications had to work around this by forcing O_NONBLOCK on the
descriptor themselves, see apache/nuttx-apps#3686.
Drop the O_NONBLOCK special case in both paths: sensor_poll() now always
reports POLLIN for a fetch only sensor and sensor_read() calls fetch()
directly instead of waiting. Update the sensor_ops_s::fetch
documentation, which described the old contract.
With the wait gone, buffersem has no waiters left. Its only two readers
were the ones removed here, both in the fetch path: the wait in
sensor_read() and the nxsem_get_value() in sensor_poll(). The remaining
nxsem_post() calls in sensor_push_event() and sensor_notify_event() had
nothing left to wake, so drop the semaphore and those posts as well.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The driver had two modes selected by CONFIG_SENSORS_L3GD20_BUFFER_SIZE:
with a buffer it pushed samples from a work queue, and without one it
exposed fetch() while still using the data ready interrupt to signal
readiness through notify_event.
That second mode misuses the fetch interface. fetch() means the data is
read from the device on demand and is therefore always available, while
an interrupt driven sensor is exactly what push_event is for. Mixing the
two forces the upper half to guess whether a fetch() only lower half
will ever notify, and it makes poll() unusable in a multi descriptor
loop, because the descriptor reports ready while the read still has to
wait for the next interrupt.
Drop the fetch path and always use the work queue and push_event, which
is what the driver already did by default since BUFFER_SIZE defaults to
1. CONFIG_SENSORS_L3GD20_BUFFER_SIZE gains a range of 1 to 32, as a zero
sized buffer no longer has a meaning, and SCHED_HPWORK is now selected
unconditionally because the work queue is always used.
No in tree configuration enables this driver and the previous default
already took the push path, so no defconfig changes are needed.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
fetch() timestamps a sample when the application asks for it, not when
the device measured it, and reads accel and gyro separately so the two
topics never share an instant. Add an optional push mode behind
CONFIG_SENSORS_MPU6050_INT: the board supplies mpu6050_config_s::attach,
the handler timestamps and defers to HPWORK, and the worker reads once
and pushes both topics. The I2C read cannot run in the interrupt.
The mode is chosen at build time, so fetch() is simply left out of the
ops table and out of the build when the option is set: an instance uses
one model or the other, never the mixture that made poll() unusable on
l3gd20. A board that enables it without attach fails with -EINVAL.
Also set CONFIG so the DLPF is on. Left at reset the gyroscope output is
8 kHz, not 1 kHz, so SMPLRT_DIV 9 gave 800 Hz rather than the documented
100 Hz; measured 833 Hz before and 101 Hz after. fetch() hid this since
the application set the pace.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
Summary
Permissions (Part 3)
Description:
In kernel builds, any unprivileged process running on the NuttX device can
open /dev/efuse and attempt to read/write fuse content. Reading the fuses
may provide valuable information to an attacker controlling the user process.
The write operation, in extreme cases where the fuse blocks are not locked,
may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
Impact
See https://github.com/apache/nuttx/issues/19410
Testing
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Permissions (Part 2)
Description:
In kernel builds, any unprivileged process running on the NuttX
device can open /dev/efuse and attempt to read/write fuse content.
Reading the fuses may provide valuable information to an attacker
controlling the user process. The write operation, in extreme cases
where the fuse blocks are not locked, may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
See https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Add lower-half uORB sensor driver for the InvenSense MPU6050 over I2C. Supports accelerometer and gyroscope sensor types, register read/write, fetch, and control operations.
All internal register definitions and full-scale range constants are placed in the private driver C file (drivers/sensors/mpu6050_uorb.c) for clean encapsulation. The device struct uses explicit named members ('accel' and 'gyro') for high readability.
Add Kconfig option CONFIG_SENSORS_MPU6050 under Sensor Drivers, and add build integration to drivers/sensors/Make.defs and CMakeLists.txt.
Signed-off-by: Shriyans S Sahoo <shriyans.s.sahoo@gmail.com>
Align the NuttX open(2) flag constants with the Linux asm-generic
values so that the FUSE wire protocol and other cross-platform
interfaces work without conversion.
All code that used '(flags & O_RDONLY)' as a bitmask check (always 0
now that O_RDONLY=0) has been updated to use '(flags & O_ACCMODE)'
comparisons.
The NUTTX_O_* constants in include/nuttx/fs/hostfs.h are updated to
match, and the sim hostfs open flag mapping is fixed.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
O_RDOK and O_WROK are non-standard aliases for O_RDONLY and O_WRONLY
respectively. Having two names for the same flag creates confusion,
especially when aligning the flag values with Linux. Remove the
aliases and replace all uses with the standard O_RDONLY/O_WRONLY.
No functional change — O_RDOK was defined as O_RDONLY and O_WROK as
O_WRONLY, so the replacement is a pure text substitution.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Previously bme680 dont register temperature topic when pressure measurement
was enabled. Temperature data is present in barometer data, but sometimes
we need clear separation between these topics.
The old behavior is still achievable by setting CONFIG_BME680_DISABLE_TEMP_MEAS=y
Signed-off-by: raiden00pl <raiden00@railab.me>
BREAKING CHANGE: bme680_register() takes an additional "*config" argument.
When config is NULL - driver behavior is the same as before.
With this change bme680 can be configured during registration in board logic.
This way we don't have to callibrate sensor from user-space but sensor is ready
to use after registration.
This change makes the registration the same as for bme688, which is a similar
sensor.
Signed-off-by: raiden00pl <raiden00@railab.me>
Now that time_t is unconditionally 64-bit (signed int64_t) and the
struct timespec fields tv_sec / tv_nsec are wide enough on their own,
the explicit (uint64_t)/(int64_t)/(int) casts that used to guard the
multiplications and subtractions in *_us / *_ms / *_ns helpers are no
longer needed. Drop them to keep the timekeeping math readable and
consistent with the previous sclock_t/time_t cleanup.
In the same spirit, this commit also:
* Normalises the printf-style format specifiers and casts used to
print tv_sec / tv_nsec / tv_usec values across arch/, drivers/,
fs/, sched/ and libs/. The prior code was a mix of
"%d"/"%u"/"%ld"/"%lu"/"%lld"/PRIu32/PRIu64 with matching
(int)/(unsigned long)/(long long)/PRIu* casts; some formats
truncated time_t on 32-bit hosts, others mismatched signedness or
width. Replace all such cases with the portable POSIX-recommended
forms:
- tv_sec (time_t, signed, impl-defined width) -> %jd + (intmax_t)
- tv_nsec (long, signed) -> %ld (no cast)
- tv_usec (suseconds_t / long) -> %ld (no cast)
Add #include <stdint.h> where required.
* Drops a few stale `(FAR const time_t *)&ts.tv_sec` casts and
related `(FAR struct tm *)` / `(const time_t *)` casts in
gmtime_r() / localtime_r() / gmtime() callers; ts.tv_sec is plain
time_t now and the casts only obscured the type.
* Fixes one overflow in fs/procfs/fs_procfscritmon.c where
all_time.tv_sec * 1000000 could overflow on 32-bit time_t before
being multiplied again; cast to uint64_t at the start.
No behavioural change.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
This sensor was not present in the Make.defs file
AMG88xx Infrared Array Sensor
https://github.com/apache/nuttx/pull/12829
Moved:
These drivers can be used with sensor connected over SPI or I2C bus
Bosch Sensortec BMI160
Bosch Sensortec BMI088
Signed-off-by: simbit18 <simbit18@gmail.com>
Move the #endif preprocessor guard to after bmi160_transferspi()
so that both bmi160_configspi() and bmi160_transferspi() are
properly enclosed within the SPI conditional compilation block.
Signed-off-by: likun17 <likun17@xiaomi.com>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
This commit implements a compile-time warning and in-code comment
warning for legacy sensor drivers. This is intended to:
- Warn users that legacy drivers may eventually be removed
- Warn developers that they should not use a legacy driver as a
reference for their new driver contributions
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
When all signals are disabled, nxsig_notification is not available and
should not be invoked. Remove the call to avoid build and runtime issues
in no-signal configurations.
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
Add sensor monitor logs to analyze issues related to driver activation.
This commit adds comprehensive sensor monitoring logs to the GNSS uORB driver
to facilitate debugging and analysis of driver activation issues.
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
The dhtxx driver previously returned 0 on success, which violates standard
character device behavior where the number of bytes read should be returned.
It also used non-standard error codes like -1 or -ENOSYS for operational
errors.
This commit fixes the following behavior to comply with POSIX standards:
* Return sizeof(struct dhtxx_sensor_data_s) on success instead of 0.
* Return -EINVAL instead of -ENOSYS/-1 for invalid buffer arguments.
* Return -ETIMEDOUT instead of -1 for sensor timeouts.
* Return -EIO instead of -1 for checksum or parsing errors.
Signed-off-by: jklincn <jklincn@foxmail.com>
when remote core connect.
using worker instead of rptun thread to broadcast advertisement
message because the rptun thread can't process rx message when it
calls the ns_bound function.
And the advertisement message to remote core will generate many
the advertisement ack message from remote core, these advertisement
ack messages can't be processed at times by rptun thread.
This can cause rptun thread to block when the number of advertisement
message exceeds the number of ipc buffers between local core and
remote core.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
support set_nonwakeup ops for sensor driver to save power
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Signed-off-by: likun17 <likun17@xiaomi.com>
