Add a wrapper around `struct cred` called `Credential`, and provide
functionality to get the `Credential` associated with a `File`.
Rust Binder must check the credentials of processes when they attempt to
perform various operations, and these checks usually take a
`&Credential` as parameter. The security_binder_set_context_mgr function
would be one example. This patch is necessary to access these security_*
methods from Rust.
This Rust abstraction makes the following assumptions about the C side:
* `struct cred` is refcounted with `get_cred`/`put_cred`.
* It's okay to transfer a `struct cred` across threads, that is, you do
not need to call `put_cred` on the same thread as where you called
`get_cred`.
* The `euid` field of a `struct cred` never changes after
initialization.
* The `f_cred` field of a `struct file` never changes after
initialization.
Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
Co-developed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240915-alice-file-v10-4-88484f7a3dcf@google.com
Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
This abstraction makes it possible to manipulate the open files for a
process. The new `File` struct wraps the C `struct file`. When accessing
it using the smart pointer `ARef<File>`, the pointer will own a
reference count to the file. When accessing it as `&File`, then the
reference does not own a refcount, but the borrow checker will ensure
that the reference count does not hit zero while the `&File` is live.
Since this is intended to manipulate the open files of a process, we
introduce an `fget` constructor that corresponds to the C `fget`
method. In future patches, it will become possible to create a new fd in
a process and bind it to a `File`. Rust Binder will use these to send
fds from one process to another.
We also provide a method for accessing the file's flags. Rust Binder
will use this to access the flags of the Binder fd to check whether the
non-blocking flag is set, which affects what the Binder ioctl does.
This introduces a struct for the EBADF error type, rather than just
using the Error type directly. This has two advantages:
* `File::fget` returns a `Result<ARef<File>, BadFdError>`, which the
compiler will represent as a single pointer, with null being an error.
This is possible because the compiler understands that `BadFdError`
has only one possible value, and it also understands that the
`ARef<File>` smart pointer is guaranteed non-null.
* Additionally, we promise to users of the method that the method can
only fail with EBADF, which means that they can rely on this promise
without having to inspect its implementation.
That said, there are also two disadvantages:
* Defining additional error types involves boilerplate.
* The question mark operator will only utilize the `From` trait once,
which prevents you from using the question mark operator on
`BadFdError` in methods that return some third error type that the
kernel `Error` is convertible into. (However, it works fine in methods
that return `Error`.)
Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
Co-developed-by: Daniel Xu <dxu@dxuuu.xyz>
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Co-developed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240915-alice-file-v10-3-88484f7a3dcf@google.com
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Introduces a safe function for getting a raw pointer to the current
task.
When writing bindings that need to access the current task, it is often
more convenient to call a method that directly returns a raw pointer
than to use the existing `Task::current` method. However, the only way
to do that is `bindings::get_current()` which is unsafe since it calls
into C. By introducing `Task::current_raw()`, it becomes possible to
obtain a pointer to the current task without using unsafe.
Link: https://lore.kernel.org/all/CAH5fLgjT48X-zYtidv31mox3C4_Ogoo_2cBOCmX0Ang3tAgGHA@mail.gmail.com/
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240915-alice-file-v10-2-88484f7a3dcf@google.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
This introduces a new marker type for types that shouldn't be thread
safe. By adding a field of this type to a struct, it becomes non-Send
and non-Sync, which means that it cannot be accessed in any way from
threads other than the one it was created on.
This is useful for APIs that require globals such as `current` to remain
constant while the value exists.
We update two existing users in the Kernel to use this helper:
* `Task::current()` - moving the return type of this value to a
different thread would not be safe as you can no longer be guaranteed
that the `current` pointer remains valid.
* Lock guards. Mutexes and spinlocks should be unlocked on the same
thread as where they were locked, so we enforce this using the Send
trait.
There are also additional users in later patches of this patchset. See
[1] and [2] for the discussion that led to the introduction of this
patch.
Link: https://lore.kernel.org/all/nFDPJFnzE9Q5cqY7FwSMByRH2OAn_BpI4H53NQfWIlN6I2qfmAqnkp2wRqn0XjMO65OyZY4h6P4K2nAGKJpAOSzksYXaiAK_FoH_8QbgBI4=@proton.me/ [1]
Link: https://lore.kernel.org/all/nFDPJFnzE9Q5cqY7FwSMByRH2OAn_BpI4H53NQfWIlN6I2qfmAqnkp2wRqn0XjMO65OyZY4h6P4K2nAGKJpAOSzksYXaiAK_FoH_8QbgBI4=@proton.me/ [2]
Suggested-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240915-alice-file-v10-1-88484f7a3dcf@google.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Remove it entirely from the bindings, once Linux drivers stopped using
them.
Signed-off-by: Inbaraj E <inbaraj.e@samsung.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240917094355.37887-3-inbaraj.e@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Signed-off-by: Inbaraj E <inbaraj.e@samsung.com>
Link: https://lore.kernel.org/r/20240917094355.37887-2-inbaraj.e@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The s3c64xx_ac97_setup_gpio() have been removed since
commit 0d297df038 ("ARM: s3c: simplify platform code"), and now
it is useless, so remove it.
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Link: https://lore.kernel.org/r/20240826033118.4021727-1-cuigaosheng1@huawei.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The s3c_hwmon_set_platdata() have been removed since
commit 0d297df038 ("ARM: s3c: simplify platform code"), and now
it is useless, so remove it.
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Link: https://lore.kernel.org/r/20240826033411.4022822-1-cuigaosheng1@huawei.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
ifc can connect nor, nand and fpag. Split "^.*@..." into "nand@..." and
"(flash|fpga|board-control|cpld)@..." to better describe the child's node
binding requirements.
Fix below warning:
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dtb: /soc/memory-controller@1530000/nand@1,0:
failed to match any schema with compatible: ['fsl,ifc-nand']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240909165358.2384975-1-Frank.Li@nxp.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Fix checkpatch errors from clock drivers.
ERROR: space prohibited before that ','
ERROR: space required after that ','
Signed-off-by: Varada Pavani <v.pavani@samsung.com>
Link: https://lore.kernel.org/r/20240926145132.1763-3-v.pavani@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Fix checkpatch giving warnings on driver files related to comment style.
WARNING: Block comments should align the * on each line which is
Signed-off-by: Varada Pavani <v.pavani@samsung.com>
Link: https://lore.kernel.org/r/20240926145132.1763-2-v.pavani@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The package cooling maps for the Radxa ROCK 5B were mistakenly named map1
and map2. Their numbering should start from zero instead, because there are
no package cooling maps defined in the parent RK3588 SoC dtsi file, so let's
rename these cooling maps to map0 and map1.
Fixes: 4a152231b0 ("arm64: dts: rockchip: enable automatic fan control on Rock 5B")
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/335ecd5841ab55f333e17bb391d0e1264fac257b.1726954592.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Move the "l3_cache" node outside the "cpus" node in the base dtsi file for
Rockchip RK3588(S) SoCs. The A55 and A76 CPU cores in these SoCs belong to
the ARM DynamIQ IP core lineup, which places the L3 cache outside the CPUs
and into the DynamIQ Shared Unit (DSU). [1] Thus, moving the L3 cache DT
node one level higher in the DT improves the way the physical topology of
the RK3588(S) SoCs is represented in the SoC dtsi files.
While there, add a comment that explains it briefly, to save curious readers
from the need to reference the repository log for a clarification.
[1] ARM DynamIQ Shared Unit revision r4p0 TRM, version 0400-02
Fixes: c9211fa260 ("arm64: dts: rockchip: Add base DT for rk3588 SoC")
Helped-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/84264d0713fb51ae2b9b731e28fc14681beea853.1727345965.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
There are no DT bindings and driver support for a "rockchip,rt5651"
codec. Replace "rockchip,rt5651" by "realtek,rt5651", which matches the
"simple-audio-card,name" property in the "rt5651-sound" node.
Fixes: 0a3c78e251 ("arm64: dts: rockchip: Add support for rk3399 excavator main board")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/abc6c89811b3911785601d6d590483eacb145102.1727358193.git.geert+renesas@glider.be
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
There are no DT bindings and driver support for a "rockchip,rt5651"
codec. Replace "rockchip,rt5651" by "realtek,rt5651", which matches the
"simple-audio-card,name" property in the "rt5651-sound" node.
Fixes: 904f983256 ("arm64: dts: rockchip: Add dts for a rk3399 based board EAIDK-610")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/a9877b8b1bd0de279d2ec8294d5be14587203a82.1727358193.git.geert+renesas@glider.be
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
These pinctrls manage the low-speed PCIe signals:
- CLKREQ#: An output on the RK3588 (both RC or EP modes), used to
request that external clock-generation circuitry provide a clock.
- PERST#: An input on the RK3588 in EP mode, used to detect a reset
signal from the RC. In RC mode, the hardware does not use this signal:
Linux itself generates it by putting the pin in GPIO mode.
- WAKE#: In EP mode, this is an output; in RC mode, this is an input.
Each of these signals serves a distinct purpose, and more importantly,
PERST# should not be muxed when the RK3588 is in the RC role. Bundling
them together in pinctrl groups prevents proper use: indeed, almost none
of the current board-specific .dts files make any use of them.
(Exception: Rock 5A recently had a patch land that misuses _pins; this
patch corrects that.)
However, on some RK3588 boards, the PCIe 3 controller will indefinitely
stall the boot if CLKREQ# is not muxed (details in the next patch).
This patch unbundles the signals to allow them to be used.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Link: https://lore.kernel.org/r/20240912025034.180233-2-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
W3 is the carrier board for LM7 System on Module.
W3 features:
- 1x 2.5GbE Realtek RTL8125 Ethernet
- 2x HDMI Type A out
- 1x HDMI Type A in
- 1x USB 3.1 Type C
- 2x USB 2.0 Type A
- 2x USB 3.0 Type A
- 1x PCIE 2.0 M.2 E Key (1 lane)
- 1x PCIE 3.0 PCIe (4 lanes)
- 1x TF scard slot
- 1x MIPI CSI
- 1x MIPI DSI
- 1x ES8316 audio jack
- 1x FAN connector
- 1x RTC
- 40-pin expansion header
Add support for ArmSoM LM7 board.
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Link: https://lore.kernel.org/r/20240918165008.169917-4-liujianfeng1994@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
LM7 is an System on Module made by ArmSoM based on Rockchip RK3588.
This SoM is used by W3 Board.
LM7 features:
- Rockchip RK3588
- LPDDR4x 4/8/16/32 GB
- eMMC 16/32/64/128 GB
Add support for ArmSoM LM7 SoM.
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Link: https://lore.kernel.org/r/20240918165008.169917-3-liujianfeng1994@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
LM7 is an System on Module made by ArmSoM based on Rockchip RK3588.
This SoM is used by W3 Board.
LM7 features:
- Rockchip RK3588
- LPDDR4x 4/8/16/32 GB
- eMMC 16/32/64/128 GB
Add devicetree binding for ArmSoM LM7 SoM.
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240918165008.169917-2-liujianfeng1994@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The spinlock in meson8b clock controller is now only protecting a call to
regmap_update_bits().
The regmap API already has its own locking system so this spinlock
is redundant. Remove it.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20240925-clk-meson8b-spinlock-v1-1-50b7f2d02d7d@baylibre.com
[jbrunet: amended to remove unused variable as reported by lkp]
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
The register corresponding to MPLL does not share the same register
with other module drivers, so there is no concurrent access to the
register with other modules drivers. The spinlock defined in struct
meson_clk_mpll_data is no longer useful.
Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
Link: https://lore.kernel.org/r/20240925-mpll_spinlock-v2-1-8f9b73588ec1@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
The fractional denominator of C3's hifi_pll fractional multiplier is
fixed to 100000.
Fixes: 8a9a129dc5 ("clk: meson: c3: add support for the C3 SoC PLL clock")
Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
Link: https://lore.kernel.org/r/20240909-fix_clk-v3-2-a6d8f6333c04@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Some PLLS with fractional multipliers have fractional denominators with
fixed values, instead of the previous "(1 << pll-> frc.width)".
Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
Link: https://lore.kernel.org/r/20240909-fix_clk-v3-1-a6d8f6333c04@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
The s4's hifi_pll supports a fractional frequency multiplier, but frac
parameters are not configured in the driver.
Signed-off-by: Chuan Liu <chuan.liu@amlogic.com>
Link: https://lore.kernel.org/r/20240906-fix_clk-v1-3-2977ef0d72e7@amlogic.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
For gettimeofday, -ffixed-r30 was passed to work around a bug in Go
code, where the vDSO trampoline forgot to save and restore this register
across function calls. But Go requires a different trampoline for every
call, and there's no reason that new Go code needs to be broken and add
more bugs. So remove -ffixed-r30 for getrandom.
Fixes: 8072b39c3a ("powerpc/vdso: Wire up getrandom() vDSO implementation on VDSO64")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240925175021.1526936-2-Jason@zx2c4.com
Fix:
sh4-linux-ld: drivers/iio/pressure/sdp500.o: in function `sdp500_probe':
>> drivers/iio/pressure/sdp500.c:130:(.text+0xe8): undefined reference to `crc8_populate_msb'
sh4-linux-ld: drivers/iio/pressure/sdp500.o: in function `sdp500_read_raw':
>> drivers/iio/pressure/sdp500.c:74:(.text+0x200): undefined reference to `crc8'
by adding missing select.
Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202409271341.0dhpXk7G-lkp@intel.com/
Link: https://patch.msgid.link/20240929172105.1819259-1-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This links the PWM fan on Orange Pi 5+ as an active cooling device
managed automatically by the thermal subsystem, with a target SoC
temperature of 65C and a minimum-spin interval from 55C to 65C to
ensure airflow when the system gets warm.
This is pretty much the same as '4a152231b0 ("arm64: dts: rockchip:
enable automatic fan control on Rock 5B")', except for the Orange Pi
5+ board.
Signed-off-by: Florian Klink <flokli@flokli.de>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20240922145538.256235-2-flokli@flokli.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Ringneck v1.4 can contain (placement option) an on-board ATtiny
microcontroller instead of an STM32. In normal operation, this
is transparent to the software, as both microcontrollers emulate
the same ICs (amc6821 and isl1208).
For flashing the ATtiny, the SWITCH_REG1 regulator of the board's PMIC is
used to enable the ATtiny UPDI debug interface. If the STM32 is placed, or if
we are running on an older Ringneck revision, SWITCH_REG1 is not connected
and has no effect.
Add attiny-updi-gate-regulator so userspace can control it via sysfs
(needs CONFIG_REGULATOR_USERSPACE_CONSUMER):
echo enabled > /sys/devices/platform/attiny-updi-gate-regulator/state
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20240926132028.21910-1-jakob.unterwurzacher@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The driver will support the AD7606C-16 and AD7606C-18.
This change adds the compatible strings for these devices.
The AD7606C-16,18 channels also support these (individually configurable)
types of channels:
- bipolar single-ended
- unipolar single-ended
- bipolar differential
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
Link: https://patch.msgid.link/20240919130444.2100447-8-aardelean@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some ADCs have channels with negative and positive inputs, which can be
used to measure differential voltage levels. These inputs/pins are
dedicated (to the given channel) and cannot be muxed as with other ADCs.
For those types of setups, the 'diff-channels' property can be specified to
be used with the channel number (or reg property) for both negative and
positive inputs/pins.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
Link: https://patch.msgid.link/20240919130444.2100447-7-aardelean@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
For SW mode, the oversampling and scales attributes are always present.
So, they can be implemented via a 'read_avail' hook in iio_info.
For HW mode, it's a bit tricky, as these attributes get assigned based on
GPIO definitions.
So, for SW mode, we define a separate AD7606_SW_CHANNEL() macro, and use
that for the SW channels.
And 'ad7606_info_os_range_and_debug' can be renamed to
'ad7606_info_sw_mode' as it is only used for SW mode.
For the 'read_avail' hook, we'll need to allocate the SW scales, so that
they are just returned userspace without any extra processing.
The allocation will happen when then ad7606_state struct is allocated.
The oversampling available parameters don't need any extra processing; they
can just be passed back to userspace (as they are).
Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
Link: https://patch.msgid.link/20240919130444.2100447-6-aardelean@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
With the addition of AD7606C-16,18 which have differential & bipolar
channels (and ranges), which can vary from channel to channel, we'll need
to keep more information about each channel range.
To do that, we'll add a 'struct ad7606_chan_scale' type to hold just
configuration for each channel.
This includes the scales per channel (which can be different with
AD7606C-16,18), as well as the range for each channel.
This driver was already keeping the range value for each channel before,
and since this is couple with the scales, it also makes sense to put them
in the same struct.
Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
Link: https://patch.msgid.link/20240919130444.2100447-5-aardelean@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up until now, all ADCs were 16-bit precision.
With the addition of the AD7606C some things will change. For one thing,
we'll need to setup available-scales for each channel. Also for the 18-bit
precision variants, the scales will be different.
This change adds a function-pointer to the chip-info struct to be able to
set this up (differently) for the new parts. For the current parts, the
scales are the same (for all parts) between HW and SW modes.
Also creating a 'ad7606_sw_mode_setup()' function that must be called
before the scale_setup callback. This is needed in case SW mode is enabled
for some ADCs.
Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
Link: https://patch.msgid.link/20240919130444.2100447-4-aardelean@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ad7606_scan_direct() function returns 'int', which is fine for 16-bit
samples.
But when going to 18-bit samples, these need to be implemented as 32-bit
(or int) type.
In that case when getting samples (which can be negative), we'd get random
error codes.
So, the easiest thing is to just move the 'val' pointer to
'ad7606_scan_direct()'. This doesn't qualify as a fix, it's just a
preparation for 18-bit ADCs (of the AD7606 family).
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
Link: https://patch.msgid.link/20240919130444.2100447-3-aardelean@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There are some newer additions to the AD7606 family, which support 18 bit
precision. Up until now, all chips were 16 bit.
This change adds a 'bits' parameter to the AD760X_CHANNEL macro and renames
'ad7606_channels' -> 'ad7606_channels_16bit' for the current devices.
The AD7606_SW_CHANNEL() macro is also introduced, as a short-hand for IIO
channels in SW mode.
Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240919130444.2100447-2-aardelean@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The SARADC on the Amlogic Meson8 SoC also requires the amlogic,hhi-sysctrl,
property, document it by adding the amlogic,meson8-saradc compatible in the
adequate allOf:if:compatible:contains:enums along meson8b and meson8m2.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20240911-topic-amlogic-arm32-upstream-bindings-fixes-amlogic-hhi-sysctrl-v1-1-b8c3180b2fba@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The AD8460 is a “bits in, power out” high voltage, high-power,
high-speed driver optimized for large output current (up to ±1 A)
and high slew rate (up to ±1800 V/μs) at high voltage (up to ±40 V)
into capacitive loads.
A digital engine implements user-configurable features: modes for
digital input, programmable supply current, and fault monitoring
and programmable protection settings for output current,
output voltage, and junction temperature. The AD8460 operates on
high voltage dual supplies up to ±55 V and a single low voltage
supply of 5 V.
Signed-off-by: Mariel Tinaco <Mariel.Tinaco@analog.com>
Link: https://patch.msgid.link/20240912095435.18639-3-Mariel.Tinaco@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This adds the bindings documentation for the 14-bit
High Voltage, High Current, Waveform Generator
Digital-to-Analog converter.
Signed-off-by: Mariel Tinaco <Mariel.Tinaco@analog.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://patch.msgid.link/20240912095435.18639-2-Mariel.Tinaco@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
