Carve out space in the @shape passed to the various VM creation helpers to
allow using the shape to control the subtype of VM, e.g. to identify x86's
SEV VMs (which are "regular" VMs as far as KVM is concerned).
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Vishal Annapurve <vannapurve@google.com>
Cc: Ackerley Tng <ackerleytng@google.com>
Cc: Andrew Jones <andrew.jones@linux.dev>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Tested-by: Carlos Bilbao <carlos.bilbao@amd.com>
Link: https://lore.kernel.org/r/20240223004258.3104051-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-9-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the kvm_test_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-8-thuth@redhat.com
[sean: make host_cap static]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Use the kvm_test_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-7-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
The sync_regs test currently does not have any output (unless one
of the TEST_ASSERT statement fails), so it's hard to say for a user
whether a certain new sub-test has been included in the binary or
not. Let's make this a little bit more user-friendly and include
some TAP output via the kselftest_harness.h / kvm_test_harness.h
interface.
To be able to use the interface, we have to break up the huge main()
function here in more fine grained parts - then we can use the new
KVM_ONE_VCPU_TEST() macro to define the individual tests. Since these
are run with a separate VM now, we have also to make sure to create
the expected state at the beginning of each test, so some parts grow
a little bit - which should be OK considering that the individual
tests are more self-contained now.
Suggested-by: David Matlack <dmatlack@google.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-6-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Most tests are currently not giving any proper output for the user
to see how much sub-tests have already been run, or whether new
sub-tests are part of a binary or not. So it would be good to
support TAP output in the KVM selftests. There is already a nice
framework for this in the kselftest_harness.h header which we can
use. But since we also need a vcpu in most KVM selftests, it also
makes sense to introduce our own wrapper around this which takes
care of creating a VM with one vcpu, so we don't have to repeat
this boilerplate in each and every test. Thus let's introduce
a KVM_ONE_VCPU_TEST() macro here which takes care of this.
Suggested-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/all/Y2v+B3xxYKJSM%2FfH@google.com/
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-5-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Extract the code to set a vCPU's entry point out of vm_arch_vcpu_add() and
into a new API, vcpu_arch_set_entry_point(). Providing a separate API
will allow creating a KVM selftests hardness that can handle tests that
use different entry points for sub-tests, whereas *requiring* the entry
point to be specified at vCPU creation makes it difficult to create a
generic harness, e.g. the boilerplate setup/teardown can't easily create
and destroy the VM and vCPUs.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lore.kernel.org/r/20240208204844.119326-4-thuth@redhat.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
If an eDP panel is not powered on then any attempts to talk to it over
the DP AUX channel will timeout. Unfortunately these attempts may be
quite slow. Userspace can initiate these attempts either via a
/dev/drm_dp_auxN device or via the created i2c device.
Making the DP AUX drivers timeout faster is a difficult proposition.
In theory we could just poll the panel's HPD line in the AUX transfer
function and immediately return an error there. However, this is
easier said than done. For one thing, there's no hard requirement to
hook the HPD line up for eDP panels and it's OK to just delay a fixed
amount. For another thing, the HPD line may not be fast to probe. On
parade-ps8640 we need to wait for the bridge chip's firmware to boot
before we can get the HPD line and this is a slow process.
The fact that the transfers are taking so long to timeout is causing
real problems. The open source fwupd daemon sometimes scans DP busses
looking for devices whose firmware need updating. If it happens to
scan while a panel is turned off this scan can take a long time. The
fwupd daemon could try to be smarter and only scan when eDP panels are
turned on, but we can also improve the behavior in the kernel.
Let's let eDP panels drivers specify that a panel is turned off and
then modify the common AUX transfer code not to attempt a transfer in
this case.
Tested-by: Steev Klimaszewski <steev@kali.org>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Tested-by: Eizan Miyamoto <eizan@chromium.org>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202141109.1.I24277520ac754ea538c9b14578edc94e1df11b48@changeid
Revert a recent EC driver change that introduced an unexpected and
undesirable user-visible difference in behavior (Rafael J. Wysocki).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmXfh9MSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxE1sP/RuDelNCmPOVplzhGohKcm0pGhOrp0KU
HrRNxt8ZYn0WeBx8YvURKobTEU2/n3GdpTC/8XJV5y5Q9OCWXqAwpmLCB8qcC5bj
JJmAw2gpXupaa2GSuDj9KA8HkjwXmLz67lXQqeb8em34CQewF+ZFwaVriY9idfpF
cP9on5TL+vU5ZHbAelknAdP/Wmw2hQgeHV5NPsqwMqV03I7oZQaxq5G4q3AOzFa3
eYK7ZIYQkhRRI+b5MxpNQDLHBP1dbr1xE0korh2O4tynav4oXYhNADtMEMZpHdA4
NNT3ffQ2fimjtDm3gIWIVKgv+2beN+rB7lpfiQKADxgN6KCkIz9iwPM5R2636x/d
gr5kWxQjUl8eJn2zOQ83Pc79htqGqIaZRzTIWacB3jhdKW4ZoeVZlyKRvWayMzXG
YICpoTMrdbQmFOWXS8hRx8MZ7P/axyoqazMMEV26OQauJD0AHuM+u9uj5zDR7lKQ
hR33as6/HwfP3CuxwrtGZSkqi56AdtVwFBEXGyO612qEsAgSjF1J2mGlqumlViQ1
8q+yonmVRy7c8aYsITXg9x6KrliBPnMqGb1SohcHtGC1NlvtHypywBC2gFrVbOIf
QuctvhEyLVDHdCY7N800nT0l/kKqorODUc8UCNXKlbIbaQ5kr9QEZz8MNQefR0iU
RpvH8bqK1weS
=vyUq
-----END PGP SIGNATURE-----
Merge tag 'acpi-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Revert a recent EC driver change that introduced an unexpected and
undesirable user-visible difference in behavior (Rafael Wysocki)"
* tag 'acpi-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPI: EC: Use a spin lock without disabing interrupts"
Fix a latent bug in the intel-pstate cpufreq driver that has been
exposed by the recent schedutil governor changes (Doug Smythies).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmXfiG4SHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRx+MAP/jPyZb4g9fIrkZ6++7+PDfB4F/dwM8+a
yNTAkaIJ4H5bMenTkgTvDKETgogFo+tRraPiwk0a0oRZ6rF4HhNHMUOuXkynh9q8
rDxsIq8DtUURrtd8VAEtJ+lof3v9DO8Xpl6tvCksrJWJQXEldiOx1JNcavUnDb3H
tf0MNps9gZMFqSLNFlID4vFsaOYIq5PGpw73A91MBKTuVNB9VD4/camKIJPHr5WL
rZk3fzO2MqaI1WxPD1RL87r8Bj+a/1c5PGMJMCwJkeBqhAw+sfuP9GHoA21P2O+k
9N3gz1dqCWGs/hVp4vldnp3X+B7HcBUTOUoSctr0pxEaqTXqlTZ4IzprDEnzqU64
vR5OjKOGTkUhXvcQYEBNIgr9OsHr6mdjXmBZhHbnC7cSb4Mvn+xur6vV/qSXQtS+
J+xazNcMAoCyomChrWKljzRVkLBJ7bYSPDpGyiFPztdEtSUEhtopW9wgwUZ6/Ou4
JlgVZ6/hbfFTgH1BAqIwttWEoXZmNoTx8r416P1vr71YgZGwYDh+lh4mXUkGiwxb
cpHR3lEIMNfD9lOkhi+KcfDhyfi8fiok1pE6EvbdS6fKhyMbrkPYvONMuLfniMlX
4acobj7Xg5M3TQgvDo4aojEBIsWNOMuaLzth/tja6p//34ll07rqXcwTKD6KVXZ8
rSKyupjUWLuZ
=UaYX
-----END PGP SIGNATURE-----
Merge tag 'pm-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Fix a latent bug in the intel-pstate cpufreq driver that has been
exposed by the recent schedutil governor changes (Doug Smythies)"
* tag 'pm-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: intel_pstate: fix pstate limits enforcement for adjust_perf call back
KUnit's assertion macros have variants which accept a printf format
string, to allow tests to specify a more detailed message on failure.
These (and the related KUNIT_FAIL() macro) ultimately wrap the
__kunit_do_failed_assertion() function, which accepted a printf format
specifier, but did not have the __printf attribute, so gcc couldn't warn
on incorrect agruments.
It turns out there were quite a few tests with such incorrect arguments.
Add the __printf() specifier now that we've fixed these errors, to
prevent them from recurring.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David Gow <davidgow@google.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The drm_buddy_test's alloc_contiguous test used a u64 for the page size,
which was then updated to be an 'unsigned long' to avoid 64-bit
multiplication division helpers.
However, the variable is logged by some KUNIT_ASSERT_EQ_MSG() using the
'%d' or '%llu' format specifiers, the former of which is always wrong,
and the latter is no longer correct now that ps is no longer a u64. Fix
these to all use '%lu'.
Also, drm_mm_test calls KUNIT_FAIL() with an empty string as the
message. gcc and clang warns if a printf format string is empty, so
give these some more detailed error messages, which should be more
useful anyway.
Fixes: a64056bb5a ("drm/tests/drm_buddy: add alloc_contiguous test")
Fixes: fca7526b7d ("drm/tests/drm_buddy: fix build failure on 32-bit targets")
Fixes: fc8d29e298 ("drm: selftest: convert drm_mm selftest to KUnit")
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Signed-off-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Add a transport level callback to allow it to handle the consequences of
dequeuing the request that was in the process of being transmitted.
For something like a TCP connection, we may need to disconnect if the
request was partially transmitted.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
If the connection has been scheduled to shut down, we must assume that
the socket is not in a state to accept further transmissions until the
connection has been re-established.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
If the TCP connection attempt fails without ever establishing a
connection, then assume the problem may be the server is rejecting us
due to port reuse.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Add Lunar Lake-M PCI ID for processor thermal device.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make use of the common spi-peripheral-props.yaml to pull in the common
spi device properties and limit the spi-max-frequency to 10 MHz as this
is the max. frequency if VDDIO >= 1.62V.
Note all listed devices can either operate in I2C or in SPI mode.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240221174305.3423039-1-m.felsch@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Per i.MX93 Reference Mannual Rev.4, 12/2013, there is no interrupt 268,
so drop it.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240226130826.3824251-1-peng.fan@oss.nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reference the of_device_id table in the driver structure, so it will be
used for module autoloading and device matching. This fixes clang W=1
warning:
isl29501.c:999:34: error: unused variable 'isl29501_i2c_matches' [-Werror,-Wunused-const-variable]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240225201654.49450-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Drop description of non-existing 'struct pm8xxx_chan_info' member:
qcom-pm8xxx-xoadc.c:386: warning: Excess struct member 'scale_fn_type' description in 'pm8xxx_chan_info'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240225202744.60500-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the support to provide an optional label like we do for ADC
channels to identify the device more easily.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240226121234.545662-1-m.felsch@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As I am submitting the driver and have the device to test. I'll maintain
the driver.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20240222011341.3232645-5-megi@xff.cz
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Voltafield AF8133J is a simple magnetometer sensor produced by Voltafield
Technology Corp, with dual power supplies (one for core and one for I/O)
and active-low reset pin.
The sensor has configurable range 1.2 - 2.2 mT and a software controlled
standby mode.
Add a device tree binding for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondřej Jirman <megi@xff.cz>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240222011341.3232645-3-megi@xff.cz
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Voltafile Technology Corp. is a company that produces MEMS sensors.
Add a DT vendor prefix for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Ondřej Jirman <megi@xff.cz>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240222011341.3232645-2-megi@xff.cz
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
devm_reset_control_get_optional_exclusive does what this driver is
trying to do in its probe function, therefore let's switch over to that
subsystem function.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240223-saradcv2-chan-mask-v1-3-84b06a0f623a@theobroma-systems.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some of the registers on the SARADCv2 have bits write protected except
if another bit is set. This is usually done by having the lowest 16 bits
store the data to write and the highest 16 bits specify which of the 16
lowest bits should have their value written to the hardware block.
The write_enable mask for the channel selection was incorrect because it
was just the value shifted by 16 bits, which means it would only ever
write bits and never clear them. So e.g. if someone starts a conversion
on channel 5, the lowest 4 bits would be 0x5, then starts a conversion
on channel 0, it would still be 5.
Instead of shifting the value by 16 as the mask, let's use the OR'ing of
the appropriate masks shifted by 16.
Note that this is not an issue currently because the only SARADCv2
currently supported has a reset defined in its Device Tree, that reset
resets the SARADC controller before starting a conversion on a channel.
However, this reset is handled as optional by the probe function and
thus proper masking should be used in the event an SARADCv2 without a
reset ever makes it upstream.
Fixes: 757953f8ec ("iio: adc: rockchip_saradc: Add support for RK3588")
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240223-saradcv2-chan-mask-v1-2-84b06a0f623a@theobroma-systems.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The SARADCv2 on RK3588 (the only SoC currently supported that has an
SARADCv2) selects the channel through the channel_sel bitfield which is
the 4 lowest bits, therefore the mask should be GENMASK(3, 0) and not
GENMASK(15, 0).
Fixes: 757953f8ec ("iio: adc: rockchip_saradc: Add support for RK3588")
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20240223-saradcv2-chan-mask-v1-1-84b06a0f623a@theobroma-systems.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The VEML6075 requires a single supply to operate. The property already
exists in the bindings and it is used in the example, but it is still
not on the list of required properties.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240223-veml6075_vdd-v1-1-ac76509b1998@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is the device tree schema for iio driver for
Microchip PAC193X series of Power Monitors with Accumulator.
Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240222164206.65700-2-marius.cristea@microchip.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Getting the part name with 'spi_get_device_id(spi)->name' is not a very
good pattern. Hence, explicitly add the name in the struct chip_info and
use that instead.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240222-ltc2983-misc-improv-v1-4-cf7d4457e98c@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The "val" variable comes from the user so we need to ensure that it's not
zero. In fact, all negative values are invalid as well. Add a check for
that.
Fixes: 00ef7708fa ("iio: adc: ti-ads1298: Add driver")
Acked-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/c32c9087-86de-423b-8101-67b4a7f9d728@moroto.mountain
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a copy and paste bug here, it should be "reg_vref" instead of
"reg_avdd". The "priv->reg_avdd" variable is zero so it ends up
returning success.
Fixes: 00ef7708fa ("iio: adc: ti-ads1298: Add driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Mike Looijmans <mike.looijmans@topic.nl>
Link: https://lore.kernel.org/r/5f393a87-ca8b-4e68-a6f4-a79f75a91ccb@moroto.mountain
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add documentation for adis16475 driver which describes
the driver device files and shows how the user may use the
ABI for various scenarios (configuration, measurement, etc.).
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Link: https://lore.kernel.org/r/20240221085848.991413-4-ramona.gradinariu@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add documentation for IIO device buffers describing buffer
attributes and how data is structured in buffers using
scan elements.
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Link: https://lore.kernel.org/r/20240221085848.991413-3-ramona.gradinariu@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Refactor index.rst such that it contains a section for generic
documentation and a section for Kernel Drivers documentation.
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Link: https://lore.kernel.org/r/20240221085848.991413-2-ramona.gradinariu@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This adds support for LTC6373 36 V Fully-Differential Programmable-Gain
Instrumentation Amplifier with 25 pA Input Bias Current.
The user can program the gain to one of seven available settings through
a 3-bit parallel interface (A2 to A0).
Signed-off-by: Dumitru Ceclan <mitrutzceclan@gmail.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240220153553.2432-6-mitrutzceclan@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Change the match table to use pointers instead of device ids.
Remove type from state as it is not used anymore.
Also make the chip_info structures const.
Signed-off-by: Dumitru Ceclan <mitrutzceclan@gmail.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240220153553.2432-4-mitrutzceclan@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Move gain-dB<->code conversion logic from read_raw and write_raw to
chip_info callbacks.
Signed-off-by: Dumitru Ceclan <mitrutzceclan@gmail.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240220153553.2432-2-mitrutzceclan@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The LTC6373 is a silicon, 3-bit Fully-Differential digital instrumentation
amplifier that supports the following programmable gains (Vout/Vin):
G = 0.25, 0.5, 1, 2, 4, 8, 16 + Shutdown.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Dumitru Ceclan <mitrutzceclan@gmail.com>
Link: https://lore.kernel.org/r/20240220153553.2432-5-mitrutzceclan@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
ADRF5740 and HMC540S have a 4 bit parallel interface.
Update ctrl-gpios description and min/maxItems values depending on the
matched compatible to correctly reflect the hardware properties.
Fixes: 79f2ff6461 ("dt-bindings: iio: hmc425a: add entry for ADRF5740 Attenuator")
Fixes: 20f87a9a26 ("dt-bindings: iio: hmc425a: add entry for HMC540S")
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Dumitru Ceclan <mitrutzceclan@gmail.com>
Link: https://lore.kernel.org/r/20240220153553.2432-3-mitrutzceclan@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
HDC2010 and HDC2080 humidity sensors both have an interrupt / data-ready
signal which can be used for signaling to the host.
Add binding for "interrupts" property so that boards wiring this signal
may describe the connection.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Josua Mayer <josua@solid-run.com>
Link: https://lore.kernel.org/r/20240219-iio-hdc20x0-interrupt-binding-v7-1-c8ffb39c3768@solid-run.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support to specify the VCC supply which is required to power the
device. According the datasheet 7.3.1 Power Up, the device needs 1.5ms
after the supply voltage reaches the operating range before the
communcation can begin.
Signed-off-by: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20240219131114.134607-2-m.felsch@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the binding to specify the vcc supply. We can't make it required
since this would break the backward compatibility.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20240219131114.134607-1-m.felsch@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
