If function dbg_check_idx_size() failed by loading znode in mounting
process, there are two problems:
1. Allocated znodes won't be freed, which causes kmemleak in kernel:
ubifs_mount
dbg_check_idx_size
dbg_walk_index
c->zroot.znode = ubifs_load_znode
child = ubifs_load_znode // failed
// Loaded znodes won't be freed in error handling path.
2. Global variable ubifs_clean_zn_cnt is not decreased, because
ubifs_tnc_close() is not invoked in error handling path, which
triggers a warning in ubifs_exit():
WARNING: CPU: 1 PID: 1576 at fs/ubifs/super.c:2486 ubifs_exit
Modules linked in: zstd ubifs(-) ubi nandsim
CPU: 1 PID: 1576 Comm: rmmod Not tainted 6.7.0-rc6
Call Trace:
ubifs_exit+0xca/0xc70 [ubifs]
__do_sys_delete_module+0x29a/0x4a0
do_syscall_64+0x6f/0x140
Fix it by adding error handling path in dbg_check_idx_size() to release
tnc tree.
Fixes: 1e51764a3c ("UBIFS: add new flash file system")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Suggested-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
In the error handling path `out_acc` of `ubi_resize_volume()`,
when `pebs < 0`, it indicates that the volume table record failed to
update when the volume was shrunk. In this case, the number of `ubi->avail_pebs`
and `ubi->rsvd_pebs` should be restored to their previous values to prevent
the UBI layer from reporting an incorrect number of available PEBs.
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
When using the ioctl interface to resize a UBI volume, `ubi_resize_volume`
resizes the EBA table first but does not change `vol->reserved_pebs` in
the same atomic context, which may cause concurrent access to the EBA table.
For example, when a user shrinks UBI volume A by calling `ubi_resize_volume`,
while another thread is writing to volume B and triggering wear-leveling,
which may call `ubi_write_fastmap`, under these circumstances, KASAN may
report a slab-out-of-bounds error in `ubi_eba_get_ldesc+0xfb/0x130`.
This patch fixes race conditions in `ubi_resize_volume` and
`ubi_update_fastmap` to avoid out-of-bounds reads of `eba_tbl`. First,
it ensures that updates to `eba_tbl` and `reserved_pebs` are protected
by `vol->volumes_lock`. Second, it implements a rollback mechanism in case
of resize failure. It is also worth mentioning that for volume shrinkage
failures, since part of the volume has already been shrunk and unmapped,
there is no need to recover `{rsvd/avail}_pebs`.
==================================================================
BUG: KASAN: slab-out-of-bounds in ubi_eba_get_ldesc+0xfb/0x130 [ubi]
Read of size 4 at addr ffff88800f43f570 by task kworker/u16:0/7
CPU: 0 PID: 7 Comm: kworker/u16:0 Not tainted 5.16.0-rc7 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: writeback wb_workfn (flush-ubifs_0_0)
Call Trace:
<TASK>
dump_stack_lvl+0x4d/0x66
print_address_description.constprop.0+0x41/0x60
kasan_report.cold+0x83/0xdf
ubi_eba_get_ldesc+0xfb/0x130 [ubi]
ubi_update_fastmap.cold+0x60f/0xc7d [ubi]
ubi_wl_get_peb+0x25b/0x4f0 [ubi]
try_write_vid_and_data+0x9a/0x4d0 [ubi]
ubi_eba_write_leb+0x7e4/0x17d0 [ubi]
ubi_leb_map+0x1a0/0x2c0 [ubi]
ubifs_leb_map+0x139/0x270 [ubifs]
ubifs_add_bud_to_log+0xb40/0xf30 [ubifs]
make_reservation+0x86e/0xb00 [ubifs]
ubifs_jnl_write_data+0x430/0x9d0 [ubifs]
do_writepage+0x1d1/0x550 [ubifs]
ubifs_writepage+0x37c/0x670 [ubifs]
__writepage+0x67/0x170
write_cache_pages+0x259/0xa90
do_writepages+0x277/0x5d0
__writeback_single_inode+0xb8/0x850
writeback_sb_inodes+0x4b3/0xb20
__writeback_inodes_wb+0xc1/0x220
wb_writeback+0x59f/0x740
wb_workfn+0x6d0/0xca0
process_one_work+0x711/0xfc0
worker_thread+0x95/0xd00
kthread+0x3a6/0x490
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 711:
kasan_save_stack+0x1e/0x50
__kasan_kmalloc+0x81/0xa0
ubi_eba_create_table+0x88/0x1a0 [ubi]
ubi_resize_volume.cold+0x175/0xae7 [ubi]
ubi_cdev_ioctl+0x57f/0x1a60 [ubi]
__x64_sys_ioctl+0x13a/0x1c0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Last potentially related work creation:
kasan_save_stack+0x1e/0x50
__kasan_record_aux_stack+0xb7/0xc0
call_rcu+0xd6/0x1000
blk_stat_free_callback+0x28/0x30
blk_release_queue+0x8a/0x2e0
kobject_put+0x186/0x4c0
scsi_device_dev_release_usercontext+0x620/0xbd0
execute_in_process_context+0x2f/0x120
device_release+0xa4/0x240
kobject_put+0x186/0x4c0
put_device+0x20/0x30
__scsi_remove_device+0x1c3/0x300
scsi_probe_and_add_lun+0x2140/0x2eb0
__scsi_scan_target+0x1f2/0xbb0
scsi_scan_channel+0x11b/0x1a0
scsi_scan_host_selected+0x24c/0x310
do_scsi_scan_host+0x1e0/0x250
do_scan_async+0x45/0x490
async_run_entry_fn+0xa2/0x530
process_one_work+0x711/0xfc0
worker_thread+0x95/0xd00
kthread+0x3a6/0x490
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff88800f43f500
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 112 bytes inside of
128-byte region [ffff88800f43f500, ffff88800f43f580)
The buggy address belongs to the page:
page:ffffea00003d0f00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xf43c
head:ffffea00003d0f00 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 001fffff80010200 ffffea000046ba08 ffffea0000457208 ffff88810004d1c0
raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88800f43f400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800f43f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88800f43f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc
^
ffff88800f43f580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800f43f600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
The following steps can used to reproduce:
Process 1: write and trigger ubi wear-leveling
ubimkvol /dev/ubi0 -s 5000MiB -N v1
ubimkvol /dev/ubi0 -s 2000MiB -N v2
ubimkvol /dev/ubi0 -s 10MiB -N v3
mount -t ubifs /dev/ubi0_0 /mnt/ubifs
while true;
do
filename=/mnt/ubifs/$((RANDOM))
dd if=/dev/random of=${filename} bs=1M count=$((RANDOM % 1000))
rm -rf ${filename}
sync /mnt/ubifs/
done
Process 2: do random resize
struct ubi_rsvol_req req;
req.vol_id = 1;
req.bytes = (rand() % 50) * 512KB;
ioctl(fd, UBI_IOCRSVOL, &req);
V3:
- Fix the commit message error.
V2:
- Add volumes_lock in ubi_eba_copy_leb() to avoid race caused by
updating eba_tbl.
V1:
- Rebase the patch on the latest mainline.
Signed-off-by: Guo Xuenan <guoxuenan@huawei.com>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
'DIV_TO_REG' function is not used:
sis5595.c:159:18: error: unused function 'DIV_TO_REG' [-Werror,-Wunused-function]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240225202841.60740-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reference common hwmon schema in the bindings which have and customize
the "shunt-resistor-micro-ohms" property. While this does not make the
binding smaller, it brings common definition of that property and also
allows generic "label" (parsed by Linux hwmon core code).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240224-dt-bindings-hwmon-common-v2-5-b446eecf5480@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reference common hwmon schema which allows to drop the "label" property.
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240224-dt-bindings-hwmon-common-v2-2-b446eecf5480@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a common hwmon schema for two properties:
1. "label", because Linux hwmon core code parses it.
2. "shunt-resistor-micro-ohms", because several devices already use it.
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240224-dt-bindings-hwmon-common-v2-1-b446eecf5480@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If a chip only provides a single regulator, it should be named 'vout'
and not 'vout0'. Declare regulator using PMBUS_REGULATOR_ONE() to make
that happen.
Cc: Conor Dooley <conor@kernel.org>
Cc: Naresh Solanki <naresh.solanki@9elements.com>
Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240223-harmless-covenant-9cd3d4f1cfd2@spud
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If a chip only provides a single regulator, it should be named 'vout'
and not 'vout0'. Declare regulator using PMBUS_REGULATOR_ONE() to make
that happen.
Cc: Conor Dooley <conor@kernel.org>
Cc: Naresh Solanki <naresh.solanki@9elements.com>
Cc: Zev Weiss <zev@bewilderbeest.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240223-player-buckskin-01405c5889c4@spud
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If a chip only provides a single regulator, it should be named 'vout'
and not 'vout0'. Declare regulator using PMBUS_REGULATOR_ONE() to make
that happen.
Cc: Conor Dooley <conor@kernel.org>
Cc: Naresh Solanki <naresh.solanki@9elements.com>
Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240223-catnap-companion-c42fdd8ad110@spud
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
These devices are regulators may need to make use of the common
regulator properties, but these are not permitted while only documented
in trivial-devices.yaml
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240223-blabber-obnoxious-353e519541a6@spud
[groeck: Dropped empty line at end of patch]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
All devices documented in the lm25066 binding are intended for use with
a regulator, be that for purely monitoring purposes (lm25056) or, for
the other devices, as the controller of that regulator. The binding does
not currently allow regulator child nodes, so add one.
Each of these devices interacts with only a single regulator and
documentation refers to it as "Vout", hence the choice of child node
name.
Acked-by: Zev Weiss <zev@bewilderbeest.net>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240223-tingling-mutt-dd55dd87ff5e@spud
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
While NCT6799 is mostly compatible to NCT6798, it needs a separate
compatible entry because it is not completely compatible and does
require chip specific code in the driver.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20240221155158.2234898-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
I am listed as maintainer of several individual hardware monitoring drivers
and for the hardware monitoring subsystem itself. That is redundant and
just bloats the MAINTAINERS file. Drop all the redundant entries.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The URL for the MAX6620 datasheet has changed. Update it to reflect the
current location.
Signed-off-by: Okan Akyuz <okanakyuz@okanakyuz.com>
Link: https://lore.kernel.org/r/20240216075212.69118-1-okanakyuz@okanakyuz.com
[groeck: Updated subject and patch description]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Don't directly use OF and use device property APIs. In addition, this
makes the probe() code neater and also allow us to move the
of_device_id table to it's natural place.
While at it, make sure to explicitly include mod_devicetable.h for the
of_device_id table.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240214-axi-fan-control-no-of-v1-1-43ca656fe2e3@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for handheld AYANEO AIR Plus with the same EC registers
to add proper fan control.
Functionality was tested successfully.
Signed-off-by: Sebastian Kranz <tklightforce@googlemail.com>
Link: https://lore.kernel.org/r/20240209090157.3232-1-tklightforce@googlemail.com
[groeck: Fixed up commit message]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The return path can be improved by returning upon first failure. The
current implementation would try to register the second interrupt even
if the first one failed, which is unnecessary.
Moreover, if no irqs are available, the return value should be zero
(the driver supports the use case with no interrupts). Currently the
initial value is unassigned and that may lead to returning an unknown
value if stack variables are not automatically set to zero and no irqs
were provided.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-hwmon/294e4634-89d4-415e-a723-b208d8770d7c@gmail.com/T/#t
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240207-chipcap2_init_vars-v1-2-08cafe43e20e@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The reg_val variable in cc2_get_reg_val() might be used without a known
value if cc2_read_reg() fails. That leads to a useless data conversion
because the returned error means the read operation failed and the data is
not relevant.
That makes its initial value irrelevant as well, so skip the data
conversion instead. If no error happens, a value is assigned to reg_val
and the data conversion is required.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-hwmon/294e4634-89d4-415e-a723-b208d8770d7c@gmail.com/T/#t
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240207-chipcap2_init_vars-v1-1-08cafe43e20e@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The total memory needed for saving per core temperature data depends on
the number of cores in a package. Using static allocated memory wastes
memories on systems with low per package core count.
Improve the code to use dynamic allocated memory so that it can be
improved further when per package core count information becomes
available.
No functional change intended.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-12-rui.zhang@intel.com
[groeck: Fixed continuation line alignment]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
temp_data->index saves the index in pdata->core_data[]. It is not used
by package temp_data.
Use temp_data->index as the indicator of package temp_data and remove
redundant temp_data->is_pkg_data.
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-11-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Saving package temp_data and core temp_data in one array with different
offsets is fragile.
Split them and clean up crabbed maths and macros. This also fixes a
problem that pdata->core_data[0] was never used.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-10-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
coretemp driver has an obscure and fragile logic for handling package
and core temperature data.
Place the logic in newly introduced helpers for further optimizations.
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-9-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
pdata->cpu_map[] saves the mapping between cpu core id and the index in
pdata->core_data[]. This is used to find the temp_data structure using
cpu_core_id, by traversing the pdata->cpu_map[] array. But the same goal
can be achieved by traversing the pdata->core_temp[] array directly.
Remove redundant pdata->cpu_map[].
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-8-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace sensor_device_attribute with device_attribute because
sensor_device_attribute->index is no longer used.
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-7-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When sensor_device_attribute pointer is available, use container_of() to
get the temp_data address.
This removes the unnecessary dependency of cached index in
pdata->core_data[].
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-6-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Introduce enum coretemp_attr_index to better describe the index of each
sensor attribute.
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Link: https://lore.kernel.org/r/20240202092144.71180-5-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This driver exposes hardware sensors of the ASUS ROG RYUJIN II 360
all-in-one CPU liquid cooler, which communicates through a proprietary
USB HID protocol. Report offsets were initially discovered in [1] by
Florian Freudiger.
Available sensors are pump, internal and external
(controller) fan speed in RPM, their duties in PWM, as well as
coolant temperature.
Attaching external fans to the controller is optional and allows them
to be controlled from the device. If not connected, the fan-related
sensors will report zeroes. The controller is a separate hardware unit
that comes bundled with the AIO and connects to it to allow fan control.
The addressable LCD screen is not supported in this
driver and should be controlled through userspace tools.
[1]: https://github.com/liquidctl/liquidctl/pull/653
Tested-by: Florian Freudiger <florian.freudiger@proton.me>
Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20240108094453.22986-1-savicaleksa83@gmail.com
[groeck: Add HID dependency]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This driver enables hardware monitoring support for NZXT Kraken
X53/X63/X73 and Z53/Z63/Z73 all-in-one CPU liquid coolers.
All models expose liquid temperature and pump speed (in RPM), as well as
PWM control (natively only through a temp-PWM curve, but the driver also
emulates fixed PWM control on top of that). The Z-series models
additionally expose the speed and duty of an optionally connected fan,
with the same PWM control capabilities.
Pump and fan duty control mode can be set through pwm[1-2]_enable,
where 1 is for the manual control mode and 2 is for the liquid temp
to PWM curve mode. Writing a 0 disables control of the channel through
the driver after setting its duty to 100%. As it is not possible to query
the device for the active mode, the driver keeps track of it.
The temperature of the curves relates to the fixed [20-59] C range, per
device limitations, and correlating to the detected liquid temperature.
Only PWM values (ranging from 0-255) can be set.
The addressable RGB LEDs and LCD screen, included only on Z-series models,
are not supported in this driver.
Co-developed-by: Jonas Malaco <jonas@protocubo.io>
Signed-off-by: Jonas Malaco <jonas@protocubo.io>
Co-developed-by: Yury Zhuravlev <stalkerg@gmail.com>
Signed-off-by: Yury Zhuravlev <stalkerg@gmail.com>
Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20240129111932.368232-1-savicaleksa83@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The Amphenol ChipCap 2 is a capacitive polymer humidity and temperature
sensor with an integrated EEPROM and minimum/maximum humidity alarms.
All device variants offer an I2C interface and depending on the part
number, two different output modes:
- CC2D: digital output
- CC2A: analog (PDM) output
This driver adds support for the digital variant (CC2D part numbers),
which includes the following part numbers:
- non-sleep measurement mode (CC2D23, CC2D25, CC2D33, CC2D35)
- sleep measurement mode (CC2D23S, CC2D25S, CC2D33S, CC2D35S)
The Chipcap 2 EEPROM can be accessed to configure a series of parameters
like the minimum/maximum humidity alarm threshold and hysteresis. The
EEPROM is only accessible in the command window after a power-on reset.
The default window lasts 10 ms if no Start_CM command is sent. After the
command window is finished (either after the mentioned timeout of after
a Start_NOM command is sent), the device enters the normal operation
mode and makes a first measurement automatically.
Unfortunately, the device does not provide any hardware or software
reset and therefore the driver must trigger power cycles to enter the
command mode. A dedicated, external regulator is required for that.
This driver keeps the device off until a measurement or access to the
EEPROM is required, making use of the first automatic measurement to
avoid different code paths for sleep and non-sleep devices.
The minimum and maximum humidity alarms are configured with two
registers per alarm: one stores the alarm threshold and the other one
keeps the value that turns off the alarm. The alarm signals are only
updated when a measurement is carried out.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240130-topic-chipcap2-v6-5-260bea05cf9b@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add device tree bindings and an example for the ChipCap 2 humidity
and temperature sensor.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240130-topic-chipcap2-v6-4-260bea05cf9b@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add min_alarm and max_alarm attributes for humidityX to support devices
that can generate these alarms.
Such attributes already exist for other magnitudes such as tempX.
Tested with a ChipCap 2 temperature-humidity sensor.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240130-topic-chipcap2-v6-2-260bea05cf9b@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202072235.41614-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202072039.41419-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202072007.41316-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202071927.41213-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202071800.41113-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202071628.40990-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202071538.40877-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202071452.40778-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://lore.kernel.org/r/20240202071355.40666-1-liubo03@inspur.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
