* [RFC PATCH net-next 2/7] dt-bindings: net: airoha: add EN7581 SOE
From: Jihong Min @ 2026-06-14 4:00 UTC (permalink / raw)
To: netdev, Lorenzo Bianconi
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Simon Horman, Herbert Xu, Steffen Klassert,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-mediatek, Christian Marangi, Felix Fietkau, linux-kernel,
Jihong Min
In-Reply-To: <20260614040032.1567994-1-hurryman2212@gmail.com>
Document the EN7581 Secure Offload Engine register window used by the Ethernet driver for ESP packet offload, and add the new binding to the Airoha Ethernet MAINTAINERS entry.
Signed-off-by: Jihong Min <hurryman2212@gmail.com>
---
.../bindings/net/airoha,en7581-soe.yaml | 48 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/airoha,en7581-soe.yaml
diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-soe.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-soe.yaml
new file mode 100644
index 000000000000..24aecafecc70
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/airoha,en7581-soe.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/airoha,en7581-soe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 Secure Offload Engine
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ The Secure Offload Engine provides inline ESP packet offload resources used
+ by the Airoha Ethernet controller.
+
+properties:
+ compatible:
+ const: airoha,en7581-soe
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ soe@1fbfa000 {
+ compatible = "airoha,en7581-soe";
+ reg = <0 0x1fbfa000 0 0x268>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index cc1dde0c9067..7c338e670572 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -757,6 +757,7 @@ L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
+F: Documentation/devicetree/bindings/net/airoha,en7581-soe.yaml
F: drivers/net/ethernet/airoha/
AIROHA PCIE PHY DRIVER
--
2.53.0
^ permalink raw reply related
* [RFC PATCH net-next 1/7] xfrm: allow packet offload drivers to own transmit
From: Jihong Min @ 2026-06-14 4:00 UTC (permalink / raw)
To: netdev, Lorenzo Bianconi
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Simon Horman, Herbert Xu, Steffen Klassert,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-mediatek, Christian Marangi, Felix Fietkau, linux-kernel,
Jihong Min
In-Reply-To: <20260614040032.1567994-1-hurryman2212@gmail.com>
Packet offload drivers can currently program state and validate whether an skb can be offloaded, but they cannot take ownership of a packet that needs driver-specific TX preparation before the regular XFRM output path continues.
Add an optional xdo_dev_packet_xmit() callback. Drivers that implement it consume the skb and return the final TX status; all other drivers keep the existing XFRM output path.
Signed-off-by: Jihong Min <hurryman2212@gmail.com>
---
include/linux/netdevice.h | 8 ++++++++
net/xfrm/xfrm_output.c | 11 +++++++++++
2 files changed, 19 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 7f4f0837c09f..1552eb81ddf0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1048,6 +1048,14 @@ struct xfrmdev_ops {
int (*xdo_dev_policy_add) (struct xfrm_policy *x, struct netlink_ext_ack *extack);
void (*xdo_dev_policy_delete) (struct xfrm_policy *x);
void (*xdo_dev_policy_free) (struct xfrm_policy *x);
+ /* Optional packet-offload TX path for devices that need
+ * driver-specific transmit preparation instead of continuing through
+ * the regular XFRM output path, such as adding offload metadata or
+ * steering the packet to a private transmit queue. The driver consumes
+ * skb and returns the final transmit status.
+ */
+ int (*xdo_dev_packet_xmit)(struct sk_buff *skb,
+ struct xfrm_state *x);
};
#endif
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index cc35c2fcbbe0..9f11559b0221 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -770,6 +770,17 @@ int xfrm_output(struct sock *sk, struct sk_buff *skb)
}
if (x->xso.type == XFRM_DEV_OFFLOAD_PACKET) {
+#ifdef CONFIG_XFRM_OFFLOAD
+ const struct xfrmdev_ops *ops;
+#endif
+
+#ifdef CONFIG_XFRM_OFFLOAD
+ ops = x->xso.dev->xfrmdev_ops;
+ /* Callback validates, consumes skb and returns final TX status. */
+ if (ops && ops->xdo_dev_packet_xmit)
+ return ops->xdo_dev_packet_xmit(skb, x);
+#endif
+
if (!xfrm_dev_offload_ok(skb, x)) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTERROR);
kfree_skb(skb);
--
2.53.0
^ permalink raw reply related
* [RFC PATCH net-next 0/7] net: airoha: add EN7581 SOE ESP packet offload
From: Jihong Min @ 2026-06-14 4:00 UTC (permalink / raw)
To: netdev, Lorenzo Bianconi
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Simon Horman, Herbert Xu, Steffen Klassert,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-mediatek, Christian Marangi, Felix Fietkau, linux-kernel,
Jihong Min
Add Secure Offload Engine (SOE) support for the Airoha EN7581 Ethernet
driver. SOE provides inline ESP packet offload for native ESP and NAT-T
traffic, with the Ethernet/QDMA path used to submit packets to the SOE
block and the PPE path used to bind eligible ESP flows. NETIF_F_GSO_ESP
and NETIF_F_HW_ESP_TX_CSUM are intentionally left out for now and will be
revisited separately for feasibility.
This is posted as RFC because the code was originally developed and tested
against an OpenWrt 6.18 Airoha tree, not against the current upstream
net-next driver. The original OpenWrt commit used as the source for this
RFC is available at:
https://github.com/hurryman2212/OpenW1700k-test/commit/7c1b5e662f7790b3d23ed143beadc1dcbf6d15f7
The SOE part is intentionally linked into the airoha Ethernet module
instead of being exposed as an independent crypto or platform driver. The
user-visible ESP offload control is a netdev capability: xfrmdev_ops and
NETIF_F_HW_ESP live on the target netdev, and the feature can be controlled
through the usual netdev feature path. SOE also shares the FE/QDMA/PPE
datapath, private queues, DSA conduit handling and netdev lifetime owned by
airoha_eth.
Patch 1 adds xdo_dev_packet_xmit() because the existing XFRM packet
offload transmit path does not provide a hook for hardware whose ESP engine
is reached through device-specific packet forwarding. SOE needs to consume
the skb, add a hardware hop descriptor, steer it to a private QDMA path and
return the final transmit status. Drivers that do not implement the
optional callback keep the existing XFRM output behavior.
Jihong Min (7):
xfrm: allow packet offload drivers to own transmit
dt-bindings: net: airoha: add EN7581 SOE
arm64: dts: airoha: add EN7581 SOE node
net: airoha: add SOE registers and driver state
net: airoha: add QDMA support for SOE packets
net: airoha: add PPE support for SOE flows
net: airoha: add SOE XFRM packet offload support
.../bindings/net/airoha,en7581-soe.yaml | 48 +
MAINTAINERS | 1 +
arch/arm64/boot/dts/airoha/en7581.dtsi | 6 +
drivers/net/ethernet/airoha/Kconfig | 13 +
drivers/net/ethernet/airoha/Makefile | 1 +
drivers/net/ethernet/airoha/airoha_eth.c | 668 +++++-
drivers/net/ethernet/airoha/airoha_eth.h | 40 +
drivers/net/ethernet/airoha/airoha_ppe.c | 606 +++++-
drivers/net/ethernet/airoha/airoha_regs.h | 16 +
drivers/net/ethernet/airoha/airoha_soe.c | 1896 +++++++++++++++++
drivers/net/ethernet/airoha/airoha_soe.h | 126 ++
include/linux/netdevice.h | 8 +
include/linux/soc/airoha/airoha_offload.h | 5 +
net/xfrm/xfrm_output.c | 11 +
14 files changed, 3342 insertions(+), 103 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/airoha,en7581-soe.yaml
create mode 100644 drivers/net/ethernet/airoha/airoha_soe.c
create mode 100644 drivers/net/ethernet/airoha/airoha_soe.h
--
2.53.0
^ permalink raw reply
* Re: [PATCH v6 5/6] remoteproc: qcom: pas: Add late attach support for subsystems
From: Aiqun(Maria) Yu @ 2026-06-14 3:38 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Jingyi Wang, Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Konrad Dybcio, shengchao.guo,
tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <aip7feoTn0ncwzL7@linaro.org>
On 6/11/2026 5:10 PM, Stephan Gerhold wrote:
> On Thu, Jun 11, 2026 at 11:10:25AM +0800, Aiqun(Maria) Yu wrote:
>> On 5/22/2026 8:07 PM, Stephan Gerhold wrote:
>>> On Tue, May 19, 2026 at 12:24:23AM -0700, Jingyi Wang wrote:
>>>> Subsystems can be brought out of reset by entities such as bootloaders.
>>>> As the irq enablement could be later than subsystem bring up, the state
>>>> of subsystem should be checked by reading SMP2P bits.
>>>>
>>>> A new qcom_pas_attach() function is introduced. if a crash state is
>>>> detected for the subsystem, rproc_report_crash() is called. If the ready
>>>> state is detected, it will be marked as "attached", otherwise it could
>>>> be the early boot feature is not supported by other entities. In this
>>>> case, the state will be marked as RPROC_OFFLINE so that the PAS driver
>>>> can load the firmware and start the remoteproc.
>>>>
>>>> Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
>>>> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>
>>> Unfortunately, removing the ping-pong functionality that was present in
>>> previous patch versions makes the whole mechanism a lot more fragile.
>>> I'm not entirely sure if this has changed in SMP2P v2 or more recent
>>> firmware versions, but in my experience the SMP2P "ready" bit does not
>>> tell you if the remoteproc is actually running. The problem is that the
>>> "ready" bit is asserted by the remoteproc when the firmware is ready,
>>> but it is not cleared when you shutdown or forcibly stop the remoteproc.
>>>
>>> If this is still the case, you can easily reproduce that with the
>>> following test:
>>>
>>> 1. Start the system as usual and let it attach the remoteproc
>>> 2. Manually stop the remoteproc in sysfs (echo stop > state)
>>> 3. modprobe -r qcom_q6v5_pas
>>> 4. modprobe qcom_q6v5_pas
>>> 5. If the "ready" bit is still set, the driver will try attaching the
>>> remoteproc, but it's actually not running. No recovery will happen.
>>>
>>> In this situation, it is very difficult to detect the correct remoteproc
>>> state without relying on an additional query mechanism like the
>>> ping-pong feature.
>>
>> This a valid use case and concern. We had a discussion with Bjorn, and
>> want to take this scenario into consideration of the separate robustness
>> improvement series[1].
>> Stephan could you agree to have the basic function in this series can be
>> go in firstly.
>>
>> [1]
>> https://lore.kernel.org/all/20260519-rproc-attach-issue-v2-0-caa1eaf75081@oss.qualcomm.com/
>>
>>>
>>> You can make it a bit more reliable if you also check the status of the
>>> "stop-ack" bit. This would tell you if the remoteproc was cleanly
>>> stopped with the SMP2P "stop" mechanism. However, that will typically
>>> still not fix the case above since nowadays remoteprocs are typically
>>> stopped via the QMI qcom_sysmon and the "stop-ack" is not set in that
>>> case. I believe this might set the separate "shutdown-ack" bit though
>>> that is described for some SoCs, I never finished testing that.
>>>
>>> And even if you check both "stop-ack" and "shutdown-ack", that doesn't
>>> tell you if the remoteproc was forcibly killed using
>>> qcom_scm_pas_shutdown() without gracefully stopping it first. The ideal
>>> solution would be querying the PAS API to tell us if the remoteproc is
>>> actively running, but the last time I checked I was unfortunately not
>>> able to find a documented call that would tell us that.
>>
>> It is a state currently kernel don't know whether the remoteproc is
>> offline or crashed when ready==1 && error==0 && ping-pong==0 scenario.
>> If it is re-modprob, the software don't have any data and only the
>> firmware can tell us whether if it is active or not per my understanding.
>>
>> Maybe let's have this scenario and solution discussion in the other
>> series I mentioned before.
>>
>
> If you add a new feature upstream, you must make sure that it is
> reasonably robust and reliable. The other series is about generic
> limitations in the remoteproc subsystem, so I don't think you should
> move QC-specific parts over there as well (personally, I would have
> probably kept all of it in one series to make it easier to understand,
> but that's subjective).
>
> With the current firmware design, it's hard - probably impossible - to
> make the status detection perfectably reliable. I would therefore choose
> some reasonable compromise to start with. Given that Shawn (and actually
> me as well) would like to have attach working without firmware support
> for the ping-pong functionality, I think it would be reasonable to start
> with the basic detection scheme discussed above, i.e.
>
> ready==1 && handover==1 && fatal==0 && stop-ack==0 && shutdown-ack==0
Ready==1 and fatal==0 is already checked in current patchset.
I am not sure about handover state, may need double check.
stop-ack/shutdown-ack can be added per my understanding.
>
> The ping-pong functionality could be added later for platforms that
> support it. It would be good to have the interrupts already defined in
> the device tree, so you can tweak the driver without making DT changes
> later.
>
> Thanks,
> Stephan
--
Thx and BRs,
Aiqun(Maria) Yu
^ permalink raw reply
* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Bryan O'Donoghue @ 2026-06-14 1:13 UTC (permalink / raw)
To: Atanas Filipov, linux-media
Cc: mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <9fab1877-976b-4495-86de-a8c853b9ba24@oss.qualcomm.com>
On 13/06/2026 12:16, Atanas Filipov wrote:
> Thank you for the detailed explanation. Let me share my understanding of
> the shared upper-level blocks. They are exactly the reason we have
> frameworks like ICC with aggregate bandwidth voting, reference counting
> in the clock framework, and so on — the same applies to power domains. I
> do not think using shared resources is a problem when the drivers are
> correctly designed.
>
> We have actually validated this: we got CAMSS working alongside the
> Qualcomm downstream camera stack after fixing the shared resource
> management — something everyone considered nearly impossible at the time.
>
> On the CAMNOC and CPAS concern: if that coordination becomes necessary,
> the right fix is to address the resource management in both drivers
> independently, using the aggregate capabilities of the existing
> frameworks — not to introduce a
> hierarchical dependency between them. Moving JPEG under CAMSS does not
> solve the CAMNOC, clock and power domain coordination problems, it just
> papers over them.
>
> IMO the problem you are pointing at is more general than just CAMNOC — I
> would add priorities, QoS and other shared resources to the list as
> well. The answer to all of them is the same: correct use of the existing
> frameworks, not driver
> merging.
>
> On the idea of putting JPEG inside CAMSS with an external API:
I haven't remotely suggested that.
> no engine or pipeline that produces YUV output, which is what the JPEG
> encoder needs as input. If JPEG moves into CAMSS without an external
> API, it becomes
> inaccessible to userspace. If it does expose one, we end up with a
> standalone interface anyway, just with an extra layer of indirection on top.
This is a very long winded way of saying no without acknowledging the
core point that the DT should scribe the hardware the way it really is,
as opposed to following software architecture preference.
It is the case JPEG lives inside of CAMSS. This is a fact of the
hardware, the DT should express those facts not software preferences.
> afilipov
>
> On 6/13/2026 12:52 PM, Bryan O'Donoghue wrote:
>> On 13/06/2026 10:24, Atanas Filipov wrote:
Honestly - please quit top-posting. I'll be ignoring further top-posted
email.
> And please no top posting !
>
> ---
> bod
>
^ permalink raw reply
* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Bryan O'Donoghue @ 2026-06-14 0:53 UTC (permalink / raw)
To: Atanas Filipov, linux-media
Cc: mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <2a0fc1ce-2f19-4268-8117-cd90b512312a@oss.qualcomm.com>
On 13/06/2026 17:05, Atanas Filipov wrote:
> Checked. The MMCX/MXC dependency is covered transitively — camcc
> itself declares:
>
> power-domains = <&rpmhpd RPMHPD_MMCX>, <&rpmhpd RPMHPD_MXC>;
>
> CAM_CC_TITAN_TOP_GDSC is a subdomain of camcc, so the RPMh votes are
> enforced before any consumer is powered on.
Powered on yes, scaling the voltage correctly no.
> This matches the pattern used by every other single-GDSC camera node
> in the upstream tree (cci0/1/2 on sm8250, sm8550, sm8650) — none of
> them list MMCX/MXC directly. No change needed.
CCI doesn't have any operating points. Please check the clock frequency
plans.
> afilipov
>
> On 6/13/2026 2:52 AM, Bryan O'Donoghue wrote:
Honestly. Stop top posting !
Documentation/process/submitting-patches.rst:.. _interleaved_replies:
sm8650 which you have cited, has operating points for the JPEG encoder
and votes, must vote, on MXC. I believe the same as Hamoa for the JPEG
core clock.
This is melting my head a bit now TBH.
---
bod
^ permalink raw reply
* Re: [PATCH] dt-bindings: sound: nvidia,tegra30-ahub: Convert to DT schema
From: Mark Brown @ 2026-06-14 0:04 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, linux-sound, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260613-nvidia-ahub-v1-1-5b7e85301736@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On Sat, Jun 13, 2026 at 08:24:47AM +0000, Charan Pedumuru wrote:
> Convert NVIDIA Tegra Audio Hub (AHUB) binding to DT schema.
>
> The per-SoC differences in reset-names, dma-names, and reg entry
> counts described in the text binding are now enforced via allOf
> conditionals, making previously prose-only constraints machine
> validatable.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/7] clk: qcom: Add generic clkref_en support
From: Stephen Boyd @ 2026-06-13 22:46 UTC (permalink / raw)
To: Bjorn Andersson, Brian Masney, Conor Dooley, Konrad Dybcio,
Krzysztof Kozlowski, Michael Turquette, Qiang Yu, Rob Herring,
Taniya Das
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, Qiang Yu,
krishna.chundru
In-Reply-To: <20260602-tcsr_qref_0527-v5-2-8ea174a59d7e@oss.qualcomm.com>
Quoting Qiang Yu (2026-06-02 01:02:18)
> Before XO refclk is distributed to PCIe/USB/eDP PHYs, it passes through
> a QREF block. QREF is powered by dedicated LDO rails, and the clkref_en
> register controls whether refclk is gated through to the PHY side.
>
> These clkref controls are different from typical GCC branch clocks:
> - only a single enable bit is present, without branch-style config bits
> - regulators must be voted before enable and unvoted after disable
>
> Model this as a dedicated clk_ref clock type with custom clk_ops instead
> of reusing struct clk_branch semantics.
>
> Also provide a common registration/probe API so the same clkref model
> can be reused regardless of where clkref_en registers are placed, e.g.
> TCSR on glymur and TLMM on SM8750.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
[...]
> diff --git a/include/linux/clk/qcom.h b/include/linux/clk/qcom.h
> new file mode 100644
> index 000000000000..09e2e3178cfb
> --- /dev/null
> +++ b/include/linux/clk/qcom.h
Why are we making this file in linux/clk when only drivers/clk/qcom/ is
going to use it? We can have some qref.h header in the qcom clk driver
area.
^ permalink raw reply
* Re: [PATCH v3 net-next 1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
From: patchwork-bot+netdevbpf @ 2026-06-13 22:10 UTC (permalink / raw)
To: Frank Li
Cc: andrew, olteanv, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, horms, corbet, skhan, Frank.Li, netdev, devicetree,
linux-kernel, linux-doc, imx
In-Reply-To: <20260610150533.515914-1-Frank.Li@oss.nxp.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 10 Jun 2026 11:05:30 -0400 you wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Convert lan9303.txt to yaml format to fix below CHECK_DTBS warnings:
> arch/arm/boot/dts/nxp/imx/imx53-kp-hsc.dtb: /soc/bus@50000000/i2c@53fec000/switch@a: failed to match any schema with compatible: ['smsc,lan9303-i2c']
>
> Additional changes:
> - rename switch-phy to switch in example.
>
> [...]
Here is the summary with links:
- [v3,net-next,1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
https://git.kernel.org/netdev/net-next/c/b693b51e0829
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v6 3/5] net: dsa: tag_ks8995: Add the KS8995 tag handling
From: Jakub Kicinski @ 2026-06-13 20:38 UTC (permalink / raw)
To: Linus Walleij
Cc: woojung.huh, UNGLinuxDriver, andrew, olteanv, davem, edumazet,
pabeni, robh, krzk+dt, conor+dt, marex, horms, linux, netdev,
devicetree, nb
In-Reply-To: <CAD++jLnuBv97nUW-EdZXiLmgsUSiVLgkB0R=gKB0zYtr8JN7xg@mail.gmail.com>
On Sat, 13 Jun 2026 18:56:03 +0200 Linus Walleij wrote:
> Which is what I do.
>
> So yeah. skb_free() will be free:ed twice. The code in tag_8021q.c will
> also do that. But what do you expect ->xmit() to return on error if
> not NULL?
>
> When user.c does this:
>
> /* Transmit function may have to reallocate the original SKB,
> * in which case it must have freed it. Only free it here on error.
> */
> nskb = p->xmit(skb, dev);
> if (!nskb) {
> kfree_skb(skb);
> return NETDEV_TX_OK;
> }
>
> return dsa_enqueue_skb(nskb, dev);
>
> The only way to get clean out of this branch if you run
> into an error in ->xmit() is to return NULL!
Yes, maybe DSA experts remember the background here, and can guide us
But from a fresh look this and ->rcv have very odd semantics.
nskb = func(skb);
should assume skb is either freed or returned. Freeing the input param
on failure of func() is a rather strange pattern.
I vote we drop these kfree_skb()s (both xmit and rcv) and fix up any
driver that depended on them (if any)?
^ permalink raw reply
* Re: [PATCH v3 2/3] iio: adc: Add ti-ads1110 support to ti-ads1100 driver
From: sashiko-bot @ 2026-06-13 19:25 UTC (permalink / raw)
To: Jakub Szczudlo; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260613190957.654798-3-jakubszczudlo40@gmail.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
New issues:
- [High] Improper casting of negative error codes to boolean causes an aggressive infinite loop during I2C read failures.
- [High] Integer overflow in `ads1100_get_voltage_microvolts` on 32-bit platforms due to missing parentheses.
- [Medium] I2C negative error codes are incorrectly discarded and squashed into a generic -EIO.
- [Low] The driver hardcodes `ARRAY_SIZE(ads1100_data_rate)` to determine the length of dynamically selected data rate arrays.
- [Low] Dropping the `const` qualifier when assigning the firmware device match data pointer.
Pre-existing issues:
- [High] Missing wait for ADC conversion completion after device power-on causes reads of invalid data.
--
commit 05622ebdba67f2ec5ab414bed153865ba64b4705
Author: Jakub Szczudlo <jakubszczudlo40@gmail.com>
Subject: iio: adc: Add ti-ads1110 support to ti-ads1100 driver
Add ADS1110 support that have faster datarate than ADS1100, it also uses
internal voltage reference of 2.048V for measurement.
[ ... ]
> diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
> index aa8946063c7d6..76de2466dc53b 100644
> --- a/drivers/iio/adc/ti-ads1100.c
> +++ b/drivers/iio/adc/ti-ads1100.c
> @@ -39,17 +40,41 @@
> #define ADS1100_SINGLESHOT ADS1100_CFG_SC
>
> #define ADS1100_SLEEP_DELAY_MS 2000
> +#define ADS1110_REFERENCE_VOLTAGE_MILIVOLTS 2048
> +
> +/* Timeout based on the minimum sample rate of 8 SPS (7500000us) */
> +#define ADS1100_MAX_DRDY_TIMEOUT 7500000
[Severity: High]
Does an I2C read failure cause an aggressive infinite loop when polling for
data readiness?
Looking at ads1100_new_data_ready(), it casts the negative error code
returned from i2c_master_recv() to a boolean:
static bool ads1100_new_data_ready(struct ads1100_data *data)
{
...
ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
if (ret < 3) {
dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
return ret;
}
...
}
Because a negative value evaluates to true, ads1100_poll_data_ready()
receives true, which indicates the device is still busy. This causes
read_poll_timeout() to continue looping rather than breaking.
Consequently, any I2C communication error triggers a rapid polling storm
that hammers the bus repeatedly, blocking the thread and spamming the
kernel log until the 7.5-second timeout expires.
[ ... ]
> @@ -85,6 +110,19 @@ static int ads1100_set_config_bits(struct ads1100_data *data, u8 mask, u8 value)
> return 0;
> };
>
> +static int ads1100_get_voltage_milivolts(struct ads1100_data *data)
> +{
> + if (data->ads_config->has_reference_voltage)
> + return ADS1110_REFERENCE_VOLTAGE_MILIVOLTS;
> + else
> + return regulator_get_voltage(data->reg_vdd) / MILLI;
> +}
> +
> +static int ads1100_get_voltage_microvolts(struct ads1100_data *data)
> +{
> + return ads1100_get_voltage_milivolts(data) * MICRO / MILLI;
> +}
[Severity: High]
Can this calculation overflow on 32-bit platforms?
Because MICRO is defined as 1000000UL in linux/units.h, evaluating this
left-to-right multiplies the millivolts by 1,000,000 first. For a typical
5V supply, this evaluates to 5,000,000,000UL.
On architectures where unsigned long is 32 bits, this overflows the
maximum limit and wraps around to 705,032,704. After division by MILLI,
the function incorrectly returns 705,032 microvolts instead of 5,000,000.
This completely breaks the IIO scale and gain math calculations. Would it
be better to add parentheses to divide MICRO by MILLI first?
[ ... ]
> @@ -107,9 +145,9 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
>
> pm_runtime_put_autosuspend(&data->client->dev);
[Severity: High]
This isn't a bug introduced by this patch, but does the I2C read happen
immediately after waking the device, entirely missing the ADC's hardware
conversion delay?
When the device is woken from runtime suspend via
pm_runtime_resume_and_get(), the ADC powers up and begins a new continuous
conversion. However, ads1100_get_adc_result() immediately reads from the
I2C data register without waiting for the conversion to complete (which
takes up to 125ms at 8 SPS).
If userspace periodically polls the ADC at intervals longer than the
2-second autosuspend delay, the device will suspend between every read.
According to the ADS1100 datasheet, reading before the first conversion
is complete returns 0, making the device completely unusable for periodic
polling.
>
> - if (ret < 0) {
> + if (ret < 2) {
> dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
> - return ret;
> + return -EIO;
> }
[Severity: Medium]
Is it intentional to discard negative I2C error codes and replace them
with -EIO?
When i2c_master_recv() fails with a negative error code (e.g., -EAGAIN,
-ENXIO), replacing it with a generic -EIO breaks proper error propagation
up the IIO stack. This prevents upper layers from correctly handling
recoverable errors like arbitration loss or restarts.
This is a regression introduced by the patch to fix unhandled short reads.
[ ... ]
> @@ -159,22 +197,17 @@ static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
>
> size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
> for (i = 0; i < size; i++) {
> - if (ads1100_data_rate[i] == rate)
> + if (data->ads_config->data_rate[i] == rate)
> return ads1100_set_config_bits(data, ADS1100_DR_MASK,
> - FIELD_PREP(ADS1100_DR_MASK, i));
> + FIELD_PREP(ADS1100_DR_MASK, i));
[Severity: Low]
Is it safe to hardcode the loop iteration count to the size of the
ads1100_data_rate array?
While both ads1100_data_rate and ads1110_data_rate currently have 4
elements, bounding iteration over a pointer that can point to different
arrays using the compile-time size of a specific static array is fragile.
If a new chip variant with a different number of rates is added, this
could cause silent out-of-bounds reads or truncation.
[ ... ]
> @@ -196,7 +229,7 @@ static int ads1100_read_avail(struct iio_dev *indio_dev,
> switch (mask) {
> case IIO_CHAN_INFO_SAMP_FREQ:
> *type = IIO_VAL_INT;
> - *vals = ads1100_data_rate;
> + *vals = data->ads_config->data_rate;
> if (data->supports_data_rate)
> *length = ARRAY_SIZE(ads1100_data_rate);
[Severity: Low]
Similarly, does this hardcode the array length exposed to userspace to
the size of ads1100_data_rate regardless of the active hardware
configuration?
[ ... ]
> @@ -338,6 +371,12 @@ static int ads1100_probe(struct i2c_client *client)
> if (ret)
> return ret;
>
> + model = device_get_match_data(dev);
> + if (!model)
> + return dev_err_probe(dev, -EINVAL,
> + "Can't get device data from firmware\n");
> +
> + data->ads_config = (struct ads1100_config *)model;
[Severity: Low]
Does this explicit cast drop the const qualifier from the static match
data?
The firmware match data returned by device_get_match_data() is a
const void * pointing to a static read-only .rodata structure
(ads1100_config or ads1110_config). Explicitly casting this to a mutable
struct ads1100_config * violates const correctness and risks undefined
behavior if the struct is ever modified by a future patch.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613190957.654798-1-jakubszczudlo40@gmail.com?part=2
^ permalink raw reply
* [PATCH v2] spi: dt-bindings: octeon: Convert to DT schema
From: Ninad Naik @ 2026-06-13 19:22 UTC (permalink / raw)
To: broonie, robh, krzk+dt, conor+dt, david.daney
Cc: linux-spi, devicetree, linux-kernel, me, linux-kernel-mentees,
skhan, Ninad Naik
Convert octeon-3010 to DT schema
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Changes in v2:
- Change the maintainer from Mark Brown to David Daney.
- Use soc node wrapper instead of root node in the example to handle
address-cells and size-cells requirements.
- Remove interrupt controller provider from the example.
.../bindings/spi/cavium,octeon-3010-spi.yaml | 61 +++++++++++++++++++
.../devicetree/bindings/spi/spi-octeon.txt | 33 ----------
2 files changed, 61 insertions(+), 33 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/cavium,octeon-3010-spi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-octeon.txt
diff --git a/Documentation/devicetree/bindings/spi/cavium,octeon-3010-spi.yaml b/Documentation/devicetree/bindings/spi/cavium,octeon-3010-spi.yaml
new file mode 100644
index 000000000000..e35e661d0a58
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cavium,octeon-3010-spi.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/cavium,octeon-3010-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cavium, Inc. OCTEON SoC SPI master controller
+
+description:
+ The Cavium OCTEON SPI controller is an SPI master controller found in
+ OCTEON SoCs.
+
+maintainers:
+ - David Daney <david.daney@cavium.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: cavium,octeon-3010-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ spi@1070000001000 {
+ compatible = "cavium,octeon-3010-spi";
+ reg = <0x10700 0x00001000 0x0 0x100>;
+ interrupts = <0 58>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ compatible = "st,m95256", "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ spi-cpha;
+ spi-cpol;
+ pagesize = <64>;
+ size = <32768>;
+ address-width = <16>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/spi/spi-octeon.txt b/Documentation/devicetree/bindings/spi/spi-octeon.txt
deleted file mode 100644
index 431add192342..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-octeon.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Cavium, Inc. OCTEON SOC SPI master controller.
-
-Required properties:
-- compatible : "cavium,octeon-3010-spi"
-- reg : The register base for the controller.
-- interrupts : One interrupt, used by the controller.
-- #address-cells : <1>, as required by generic SPI binding.
-- #size-cells : <0>, also as required by generic SPI binding.
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
- spi@1070000001000 {
- compatible = "cavium,octeon-3010-spi";
- reg = <0x10700 0x00001000 0x0 0x100>;
- interrupts = <0 58>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- compatible = "st,m95256", "atmel,at25";
- reg = <0>;
- spi-max-frequency = <5000000>;
- spi-cpha;
- spi-cpol;
-
- pagesize = <64>;
- size = <32768>;
- address-width = <16>;
- };
- };
-
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 3/3] iio: adc: Fix incorrect reading when datarate changed in single mode
From: sashiko-bot @ 2026-06-13 19:22 UTC (permalink / raw)
To: Jakub Szczudlo; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260613190957.654798-4-jakubszczudlo40@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] Incorrect boolean cast of I2C read errors causes infinite polling loop and log spam.
- [High] The return value of `ads1100_set_config_bits()` is ignored, masking I2C write failures.
- [High] Polling the ST/BSY bit will always time out because the device is placed in continuous conversion mode.
- [Medium] The initial dummy `i2c_master_recv()` ignores its return value.
Pre-existing issues:
- [High] The read path returns stale data after waking from autosuspend.
--
commit 4b2f1aca65a15af2d7f4a7cbbd2f3fc74aa691ce
Author: Jakub Szczudlo <jakubszczudlo40@gmail.com>
iio: adc: Fix incorrect reading when datarate changed in single mode
When device is suspended and it is in single mode then changing
datarate doesn't make it actual wait for new measurement, so to
be sure that read after change is correct functions that changes
datarate and gain will wait for new data.
> diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
> index 76de2466dc53b..2ec5c104afcf9 100644
> --- a/drivers/iio/adc/ti-ads1100.c
> +++ b/drivers/iio/adc/ti-ads1100.c
> @@ -123,6 +123,36 @@ static int ads1100_get_voltage_microvolts(struct ads1100_data *data)
> return ads1100_get_voltage_milivolts(data) * MICRO / MILLI;
> }
>
> +static bool ads1100_new_data_ready(struct ads1100_data *data)
> +{
> + int ret;
> + u8 buffer[3];
> +
> + ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
> + if (ret < 3) {
> + dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
> + return ret;
[Severity: High]
Since this function returns a bool, doesn't returning a negative error
code implicitly cast it to true? If i2c_master_recv() fails, this will
cause the caller to interpret the error as data being ready.
> + }
> +
> + return FIELD_GET(ADS1100_CFG_ST_BSY, buffer[2]);
> +}
> +
> +static int ads1100_poll_data_ready(struct ads1100_data *data)
> +{
> + u8 buffer[3];
> + bool data_ready;
> + int datarate = data->ads_config->data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
> + // To be sure we wait 5 times more than datarate
> + unsigned long wait_time = DIV_ROUND_CLOSEST(MICRO, 5 * datarate);
> +
> + /* To be sure that polled value will have value after config change */
> + i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
[Severity: Medium]
Is it safe to ignore the return value of this initial dummy read?
If the bus is inaccessible or the device is disconnected, the error is
silently masked before entering the polling loop.
> +
> + return read_poll_timeout(ads1100_new_data_ready, data_ready,
> + !data_ready, wait_time,
> + ADS1100_MAX_DRDY_TIMEOUT, false, data);
[Severity: High]
If ads1100_new_data_ready() returns true due to the implicit error casting
mentioned above, !data_ready evaluates to false. Won't this cause the
read_poll_timeout() loop to never break, resulting in a full 7.5-second
timeout while flooding the kernel log with dev_err messages?
Also, the ST/BSY bit seems to permanently read as 1 (busy) when the device
is in continuous mode. Since pm_runtime_resume_and_get() places the device
in continuous mode via ads1100_runtime_resume(), won't this polling loop
always hit the timeout anyway?
> +}
> +
[ ... ]
> @@ -185,21 +216,40 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
> if (gain < BIT(0) || gain > BIT(3))
> return -EINVAL;
>
> + ret = pm_runtime_resume_and_get(&data->client->dev);
> + if (ret < 0)
> + return ret;
> +
> ads1100_set_config_bits(data, ADS1100_PGA_MASK, ffs(gain) - 1);
[Severity: High]
Should we check the return value of ads1100_set_config_bits() here?
If the I2C configuration write fails, the hardware configuration and the
internal state remain unmodified, but the code will still proceed to poll
for data using the old configuration. We should probably propagate the
error and ensure pm_runtime_put_autosuspend() is still called on the error
path.
>
> - return 0;
> + ret = ads1100_poll_data_ready(data);
> +
> + pm_runtime_put_autosuspend(&data->client->dev);
> +
> + return ret;
> }
>
> static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
> {
> unsigned int i;
> unsigned int size;
> + int ret;
>
> size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
> for (i = 0; i < size; i++) {
> - if (data->ads_config->data_rate[i] == rate)
> - return ads1100_set_config_bits(data, ADS1100_DR_MASK,
> + if (data->ads_config->data_rate[i] != rate)
> + continue;
> +
> + ret = pm_runtime_resume_and_get(&data->client->dev);
> + if (ret < 0)
> + return ret;
> +
> + ads1100_set_config_bits(data, ADS1100_DR_MASK,
> FIELD_PREP(ADS1100_DR_MASK, i));
[Severity: High]
Similar to ads1100_set_scale(), does ignoring the return value of
ads1100_set_config_bits() mask I2C write failures here?
> + ret = ads1100_poll_data_ready(data);
> +
> + pm_runtime_put_autosuspend(&data->client->dev);
> + return ret;
> }
>
> return -EINVAL;
[Severity: High]
This isn't a bug introduced by this patch, but there appears to be a
pre-existing issue in ads1100_get_adc_result().
When ads1100_get_adc_result() is called, it wakes the device with
pm_runtime_resume_and_get(), which places the device into continuous
conversion mode. However, the driver immediately issues an I2C read
without waiting for the first continuous conversion to complete:
ads1100_get_adc_result() {
ret = pm_runtime_resume_and_get(&data->client->dev);
if (ret < 0)
return ret;
ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
...
}
Doesn't this cause the read path to return stale data from the previous
active session when waking from autosuspend?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613190957.654798-1-jakubszczudlo40@gmail.com?part=3
^ permalink raw reply
* [PATCH v3 3/3] iio: adc: Fix incorrect reading when datarate changed in single mode
From: Jakub Szczudlo @ 2026-06-13 19:09 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, krzk+dt, linusw,
linux-kernel, marcelo.schmitt, mazziesaccount, mike.looijmans,
nuno.sa, robh, sakari.ailus, wens, joshua.crofts1, Jakub Szczudlo
In-Reply-To: <20260613190957.654798-1-jakubszczudlo40@gmail.com>
When device is suspended and it is in single mode then changing
datarate doesn't make it actual wait for new measurement, so to
be sure that read after change is correct functions that changes
datarate and gain will wait for new data.
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
drivers/iio/adc/ti-ads1100.c | 55 ++++++++++++++++++++++++++++++++++--
1 file changed, 52 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
index 76de2466dc53..195394665cd1 100644
--- a/drivers/iio/adc/ti-ads1100.c
+++ b/drivers/iio/adc/ti-ads1100.c
@@ -123,6 +123,36 @@ static int ads1100_get_voltage_microvolts(struct ads1100_data *data)
return ads1100_get_voltage_milivolts(data) * MICRO / MILLI;
}
+static bool ads1100_new_data_ready(struct ads1100_data *data)
+{
+ int ret;
+ u8 buffer[3];
+
+ ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
+ if (ret < 3) {
+ dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
+ return ret;
+ }
+
+ return FIELD_GET(ADS1100_CFG_ST_BSY, buffer[2]);
+}
+
+static int ads1100_poll_data_ready(struct ads1100_data *data)
+{
+ u8 buffer[3];
+ bool data_ready;
+ int datarate = data->ads_config->data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
+ // To be sure we wait 5 times more than datarate
+ unsigned long wait_time = DIV_ROUND_CLOSEST(MICRO, 5 * datarate);
+
+ /* To be sure that polled value will have value after config change */
+ i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
+
+ return read_poll_timeout(ads1100_new_data_ready, data_ready,
+ !data_ready, wait_time,
+ ADS1100_MAX_DRDY_TIMEOUT, false, data);
+}
+
static int ads1100_data_bits(struct ads1100_data *data)
{
return ads1100_data_rate_bits[FIELD_GET(ADS1100_DR_MASK, data->config)];
@@ -165,6 +194,7 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
{
int microvolts;
int gain;
+ int ret;
/* With Vdd between 2.7 and 5V, the scale is always below 1 */
if (val)
@@ -185,21 +215,40 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
if (gain < BIT(0) || gain > BIT(3))
return -EINVAL;
+ ret = pm_runtime_resume_and_get(&data->client->dev);
+ if (ret < 0)
+ return ret;
+
ads1100_set_config_bits(data, ADS1100_PGA_MASK, ffs(gain) - 1);
- return 0;
+ ret = ads1100_poll_data_ready(data);
+
+ pm_runtime_put_autosuspend(&data->client->dev);
+
+ return ret;
}
static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
{
unsigned int i;
unsigned int size;
+ int ret;
size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
for (i = 0; i < size; i++) {
- if (data->ads_config->data_rate[i] == rate)
- return ads1100_set_config_bits(data, ADS1100_DR_MASK,
+ if (data->ads_config->data_rate[i] != rate)
+ continue;
+
+ ret = pm_runtime_resume_and_get(&data->client->dev);
+ if (ret < 0)
+ return ret;
+
+ ads1100_set_config_bits(data, ADS1100_DR_MASK,
FIELD_PREP(ADS1100_DR_MASK, i));
+ ret = ads1100_poll_data_ready(data);
+
+ pm_runtime_put_autosuspend(&data->client->dev);
+ return ret;
}
return -EINVAL;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/3] iio: adc: Add ti-ads1110 support to ti-ads1100 driver
From: Jakub Szczudlo @ 2026-06-13 19:09 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, krzk+dt, linusw,
linux-kernel, marcelo.schmitt, mazziesaccount, mike.looijmans,
nuno.sa, robh, sakari.ailus, wens, joshua.crofts1, Jakub Szczudlo
In-Reply-To: <20260613190957.654798-1-jakubszczudlo40@gmail.com>
Add ADS1110 support that have faster datarate than ADS1100, it also uses
internal voltage reference of 2.048V for measurement.
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
drivers/iio/adc/Kconfig | 6 +--
drivers/iio/adc/ti-ads1100.c | 83 +++++++++++++++++++++++++++---------
2 files changed, 65 insertions(+), 24 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a9dedbb8eb46..54a0149a3838 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1747,11 +1747,11 @@ config TI_ADS1018
called ti-ads1018.
config TI_ADS1100
- tristate "Texas Instruments ADS1100 and ADS1000 ADC"
+ tristate "Texas Instruments ADS1100 and similar single channel I2C ADC"
depends on I2C
help
- If you say yes here you get support for Texas Instruments ADS1100 and
- ADS1000 ADC chips.
+ If you say yes here you get support TI ADS1100 and similar single
+ channel I2C Analog to Digital Converters
This driver can also be built as a module. If so, the module will be
called ti-ads1100.
diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
index aa8946063c7d..76de2466dc53 100644
--- a/drivers/iio/adc/ti-ads1100.c
+++ b/drivers/iio/adc/ti-ads1100.c
@@ -5,7 +5,7 @@
* Copyright (c) 2023, Topic Embedded Products
*
* Datasheet: https://www.ti.com/lit/gpn/ads1100
- * IIO driver for ADS1100 and ADS1000 ADC 16-bit I2C
+ * IIO driver for ADS1100 and similar single channel ADC 16-bit I2C
*/
#include <linux/bitfield.h>
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/i2c.h>
+#include <linux/iopoll.h>
#include <linux/mutex.h>
#include <linux/property.h>
#include <linux/pm_runtime.h>
@@ -39,17 +40,41 @@
#define ADS1100_SINGLESHOT ADS1100_CFG_SC
#define ADS1100_SLEEP_DELAY_MS 2000
+#define ADS1110_REFERENCE_VOLTAGE_MILIVOLTS 2048
+
+/* Timeout based on the minimum sample rate of 8 SPS (7500000us) */
+#define ADS1100_MAX_DRDY_TIMEOUT 7500000
static const int ads1100_data_rate[] = { 128, 32, 16, 8 };
+static const int ads1110_data_rate[] = { 240, 60, 30, 15 };
static const int ads1100_data_rate_bits[] = { 12, 14, 15, 16 };
+struct ads1100_config {
+ const char *name;
+ const int *data_rate;
+ bool has_reference_voltage;
+};
+
+static const struct ads1100_config ads1100_config = {
+ .name = "ads1100",
+ .data_rate = ads1100_data_rate,
+ .has_reference_voltage = false,
+};
+
+static const struct ads1100_config ads1110_config = {
+ .name = "ads1110",
+ .data_rate = ads1110_data_rate,
+ .has_reference_voltage = true,
+};
+
struct ads1100_data {
struct i2c_client *client;
struct regulator *reg_vdd;
struct mutex lock;
int scale_avail[2 * 4]; /* 4 gain settings */
+ struct ads1100_config *ads_config;
u8 config;
- bool supports_data_rate; /* Only the ADS1100 can select the rate */
+ bool supports_data_rate; /* Only the ADS1100/ADS1110 can select the rate */
};
static const struct iio_chan_spec ads1100_channel = {
@@ -85,6 +110,19 @@ static int ads1100_set_config_bits(struct ads1100_data *data, u8 mask, u8 value)
return 0;
};
+static int ads1100_get_voltage_milivolts(struct ads1100_data *data)
+{
+ if (data->ads_config->has_reference_voltage)
+ return ADS1110_REFERENCE_VOLTAGE_MILIVOLTS;
+ else
+ return regulator_get_voltage(data->reg_vdd) / MILLI;
+}
+
+static int ads1100_get_voltage_microvolts(struct ads1100_data *data)
+{
+ return ads1100_get_voltage_milivolts(data) * MICRO / MILLI;
+}
+
static int ads1100_data_bits(struct ads1100_data *data)
{
return ads1100_data_rate_bits[FIELD_GET(ADS1100_DR_MASK, data->config)];
@@ -107,9 +145,9 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
pm_runtime_put_autosuspend(&data->client->dev);
- if (ret < 0) {
+ if (ret < 2) {
dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
- return ret;
+ return -EIO;
}
/* Value is always 16-bit 2's complement */
@@ -135,7 +173,7 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
if (!val2)
return -EINVAL;
- microvolts = regulator_get_voltage(data->reg_vdd);
+ microvolts = ads1100_get_voltage_microvolts(data);
/*
* val2 is in 'micro' units, n = val2 / 1000000
* result must be millivolts, d = microvolts / 1000
@@ -159,22 +197,17 @@ static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
for (i = 0; i < size; i++) {
- if (ads1100_data_rate[i] == rate)
+ if (data->ads_config->data_rate[i] == rate)
return ads1100_set_config_bits(data, ADS1100_DR_MASK,
- FIELD_PREP(ADS1100_DR_MASK, i));
+ FIELD_PREP(ADS1100_DR_MASK, i));
}
return -EINVAL;
}
-static int ads1100_get_vdd_millivolts(struct ads1100_data *data)
-{
- return regulator_get_voltage(data->reg_vdd) / (MICRO / MILLI);
-}
-
static void ads1100_calc_scale_avail(struct ads1100_data *data)
{
- int millivolts = ads1100_get_vdd_millivolts(data);
+ int millivolts = ads1100_get_voltage_milivolts(data);
unsigned int i;
for (i = 0; i < ARRAY_SIZE(data->scale_avail) / 2; i++) {
@@ -196,7 +229,7 @@ static int ads1100_read_avail(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_SAMP_FREQ:
*type = IIO_VAL_INT;
- *vals = ads1100_data_rate;
+ *vals = data->ads_config->data_rate;
if (data->supports_data_rate)
*length = ARRAY_SIZE(ads1100_data_rate);
else
@@ -233,12 +266,11 @@ static int ads1100_read_raw(struct iio_dev *indio_dev,
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
/* full-scale is the supply voltage in millivolts */
- *val = ads1100_get_vdd_millivolts(data);
+ *val = ads1100_get_voltage_milivolts(data);
*val2 = 15 + FIELD_GET(ADS1100_PGA_MASK, data->config);
return IIO_VAL_FRACTIONAL_LOG2;
case IIO_CHAN_INFO_SAMP_FREQ:
- *val = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK,
- data->config)];
+ *val = data->ads_config->data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
return IIO_VAL_INT;
default:
return -EINVAL;
@@ -307,6 +339,7 @@ static int ads1100_probe(struct i2c_client *client)
struct iio_dev *indio_dev;
struct ads1100_data *data;
struct device *dev = &client->dev;
+ const struct ads1100_config *model;
int ret;
indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
@@ -338,6 +371,12 @@ static int ads1100_probe(struct i2c_client *client)
if (ret)
return ret;
+ model = device_get_match_data(dev);
+ if (!model)
+ return dev_err_probe(dev, -EINVAL,
+ "Can't get device data from firmware\n");
+
+ data->ads_config = (struct ads1100_config *)model;
ret = ads1100_setup(data);
if (ret)
return dev_err_probe(dev, ret,
@@ -400,16 +439,18 @@ static DEFINE_RUNTIME_DEV_PM_OPS(ads1100_pm_ops,
NULL);
static const struct i2c_device_id ads1100_id[] = {
- { "ads1100" },
- { "ads1000" },
+ { .name = "ads1000", .driver_data = (kernel_ulong_t)&ads1100_config },
+ { .name = "ads1100", .driver_data = (kernel_ulong_t)&ads1100_config },
+ { .name = "ads1110", .driver_data = (kernel_ulong_t)&ads1110_config },
{ }
};
MODULE_DEVICE_TABLE(i2c, ads1100_id);
static const struct of_device_id ads1100_of_match[] = {
- {.compatible = "ti,ads1100" },
- {.compatible = "ti,ads1000" },
+ { .compatible = "ti,ads1000", .data = &ads1100_config },
+ { .compatible = "ti,ads1100", .data = &ads1100_config },
+ { .compatible = "ti,ads1110", .data = &ads1110_config },
{ }
};
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: iio: adc: ti,ads1100: add support for ADS1110
From: Jakub Szczudlo @ 2026-06-13 19:09 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, krzk+dt, linusw,
linux-kernel, marcelo.schmitt, mazziesaccount, mike.looijmans,
nuno.sa, robh, sakari.ailus, wens, joshua.crofts1, Jakub Szczudlo
In-Reply-To: <20260613190957.654798-1-jakubszczudlo40@gmail.com>
Register layouts are the same as for ADS1100 but ADS1110 have different
datarates and have internal voltage reference that is always 2.048V
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
.../devicetree/bindings/iio/adc/ti,ads1100.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
index 970ccab15e1e..28c5e2dd0ad6 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
@@ -4,19 +4,23 @@
$id: http://devicetree.org/schemas/iio/adc/ti,ads1100.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI ADS1100/ADS1000 single channel I2C analog to digital converter
+title: TI ADS1100 and similar single channel I2C Analog to Digital Converters
maintainers:
- Mike Looijmans <mike.looijmans@topic.nl>
description: |
- Datasheet at: https://www.ti.com/lit/gpn/ads1100
+ Datasheets:
+ - https://www.ti.com/lit/gpn/ads1000
+ - https://www.ti.com/lit/gpn/ads1100
+ - https://www.ti.com/lit/gpn/ads1110
properties:
compatible:
enum:
- - ti,ads1100
- ti,ads1000
+ - ti,ads1100
+ - ti,ads1110
reg:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/3] iio: adc: Add support for TI ADS1110 to ti-ads1100 driver
From: Jakub Szczudlo @ 2026-06-13 19:09 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, krzk+dt, linusw,
linux-kernel, marcelo.schmitt, mazziesaccount, mike.looijmans,
nuno.sa, robh, sakari.ailus, wens, joshua.crofts1, Jakub Szczudlo
Add support for the TI ADS1110 to the existing ADS1100 ADC IIO driver.
The ADS1110 is pin-to-pin compatible with the ADS1100 while providing
higher resolution and an internal voltage reference. This patch series
extends driver support for ADS1110, updates device tree bindings and
Kconfig text, and improves the overall hardware description for the
TI ADS1100 family.
Tested on: Raspberry pi 3b+ with 7.0 stable kernel
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
V2 -> V3:
- clean patch from unreleated changes
- divide adding support for ads1110 into separate patch
- add missing changelog
- Link to v2: https://lore.kernel.org/linux-iio/20260607183542.368184-1-jakubszczudlo40@gmail.com/
V1 -> V2:
- go from creating new driver to extending ADS1100 driver to support ADS1110
- Link to v1: https://lore.kernel.org/linux-iio/20260527164312.355729-1-jakubszczudlo40@gmail.com/
Jakub Szczudlo (3):
dt-bindings: iio: adc: ti,ads1100: add support for ADS1110
iio: adc: Add ti-ads1110 support to ti-ads1100 driver
iio: adc: Fix incorrect reading when datarate changed in single mode
.../bindings/iio/adc/ti,ads1100.yaml | 10 +-
drivers/iio/adc/Kconfig | 6 +-
drivers/iio/adc/ti-ads1100.c | 136 +++++++++++++++---
3 files changed, 123 insertions(+), 29 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH] dt-bindings: usb: ti,tps6598x: add TPS6699x compatible
From: Krzysztof Kozlowski @ 2026-06-13 19:10 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, bryan.odonoghue, linux-usb,
devicetree, linux-kernel
In-Reply-To: <20260613-adorable-sticky-skua-6eec43@quoll>
On 13/06/2026 21:08, Krzysztof Kozlowski wrote:
> On Sat, Jun 13, 2026 at 09:53:35PM +0530, Radhey Shyam Pandey wrote:
> + switch and Power Delivery controller.
>>
>> A variant of this controller known as Apple CD321x or Apple ACE is also
>> present on hardware with Apple SoCs such as the M1.
>> @@ -19,6 +20,7 @@ properties:
>> compatible:
>> enum:
>> - ti,tps6598x
>> + - ti,tps6699x
>
> Family compatibles are not allowed. Please use specific models,
> expressing compatibility (my slides of DTS101 talkmight help you if
> something is unclear).
And where is any user of this? Why do we want this binding in the first
place?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: usb: ti,tps6598x: add TPS6699x compatible
From: Krzysztof Kozlowski @ 2026-06-13 19:08 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, bryan.odonoghue, linux-usb,
devicetree, linux-kernel
In-Reply-To: <20260613162335.1490514-1-radhey.shyam.pandey@amd.com>
On Sat, Jun 13, 2026 at 09:53:35PM +0530, Radhey Shyam Pandey wrote:
+ switch and Power Delivery controller.
>
> A variant of this controller known as Apple CD321x or Apple ACE is also
> present on hardware with Apple SoCs such as the M1.
> @@ -19,6 +20,7 @@ properties:
> compatible:
> enum:
> - ti,tps6598x
> + - ti,tps6699x
Family compatibles are not allowed. Please use specific models,
expressing compatibility (my slides of DTS101 talkmight help you if
something is unclear).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next 1/8] dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series
From: Krzysztof Kozlowski @ 2026-06-13 19:07 UTC (permalink / raw)
To: Markus Stockhausen
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel, robh, krzk+dt, conor+dt, devicetree
In-Reply-To: <20260613112946.1071411-2-markus.stockhausen@gmx.de>
On Sat, Jun 13, 2026 at 01:29:39PM +0200, Markus Stockhausen wrote:
- realtek,rtl9302b-mdio
> @@ -24,6 +34,8 @@ properties:
> - realtek,rtl9313-mdio
> - const: realtek,rtl9311-mdio
> - enum:
> + - realtek,rtl8380-mdio
> + - realtek,rtl8391-mdio
> - realtek,rtl9301-mdio
I don't have that context in my recent next, but anyway looks correct.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: arm: sunxi: add Radxa Cubie A7S
From: Krzysztof Kozlowski @ 2026-06-13 19:04 UTC (permalink / raw)
To: Enzo Adriano
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-1-7787c94681db@gmail.com>
On Sat, Jun 13, 2026 at 05:42:13AM -0400, Enzo Adriano wrote:
> Document the Radxa Cubie A7S board compatible for the Allwinner A733 SoC.
>
> Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: mmc: add Allwinner A733 compatible
From: Krzysztof Kozlowski @ 2026-06-13 19:03 UTC (permalink / raw)
To: Enzo Adriano
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-2-7787c94681db@gmail.com>
On Sat, Jun 13, 2026 at 05:42:14AM -0400, Enzo Adriano wrote:
> Document the A733 MMC controller compatible with the existing D1-style
> fallback.
>
> Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
> ---
> Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
> index 9f3b1edacaa0..9e9590521210 100644
> --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
> @@ -58,6 +58,9 @@ properties:
> - items:
> - const: allwinner,sun55i-a523-mmc
> - const: allwinner,sun20i-d1-mmc
> + - items:
> + - const: allwinner,sun60i-a733-mmc
So that's enum with previous entry... What's with Allwinner patches
recently that they do not use that syntax?
items:
- enum:
- ...
- const:
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: pwm: st,pwm: convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-13 19:02 UTC (permalink / raw)
To: Charan Pedumuru; +Cc: sashiko-reviews, conor+dt, devicetree, robh
In-Reply-To: <84be047f-350f-470c-9680-179805152e1a@gmail.com>
On Sat, Jun 13, 2026 at 12:50:54PM +0530, Charan Pedumuru wrote:
>
>
> On 13-06-2026 12:43, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] The `interrupts` property is unconditionally required by the driver but omitted from the YAML schema's required list.
interrupts were required by old binding and you should document in
commit msg all changes done to the binding with a reason.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] iio: adc: Add ti-ads1262 driver
From: Krzysztof Kozlowski @ 2026-06-13 19:00 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Kurt Borja, robh, conor+dt, devicetree
In-Reply-To: <20260612230132.E04DB1F000E9@smtp.kernel.org>
On Fri, Jun 12, 2026 at 11:01:32PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 15 potential issue(s) to consider:
> - [High] Architecture Compatibility / Undefined Behavior due to direct bitfield mapping.
> - [High] Out-of-Bounds Memory Access / Hardware Misconfiguration during active channel iteration.
> - [High] Infinite Loop / Denial of Service in IDAC microamp parsing.
> - [High] Logic Error: Inverted bounds check rejects valid pin numbers.
> - [High] Race Condition / Lost Wakeup due to reinitializing completion after hardware trigger.
> - [High] Missing Error Handling / Type Mismatch: Unsigned check of negative error code.
> - [High] DMA Memory Corruption: Unaligned DMA buffer in union.
> - [High] Uninitialized Memory Read (KMSAN) on stack variable.
> - [High] Illegal DMA from Stack in regmap bus implementation.
> - [High] Logic Error: GPIO get_multiple returns pin states incorrectly.
> - [High] Hardware State / Timing violation during device reset.
> - [High] Logic Error / Performance: Unconditional stall without IRQ.
> - [Medium] Memory Leak of fwnode_handle reference on the error path.
> - [Medium] Resource Leak of runtime PM usage counter on the error path.
> - [Medium] API Contract Violation: Buffer mode lock released with direct mode API.
Amount of findings is horrifying. You should probably involve some
internal review before posting next version.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] iio: adc: Add ti-ads1262 driver
From: Krzysztof Kozlowski @ 2026-06-13 18:59 UTC (permalink / raw)
To: Kurt Borja
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, David Lechner, Nuno Sá,
Andy Shevchenko, linux-iio, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260612-ads126x-v1-2-894c788d03ed@gmail.com>
On Fri, Jun 12, 2026 at 05:46:20PM -0500, Kurt Borja wrote:
> +
> + val = FIELD_PREP(ADS1262_IDACMAG_MAG1_MASK, idac_mags[0]);
> + val |= FIELD_PREP(ADS1262_IDACMAG_MAG2_MASK, idac_mags[1]);
> +
> + return regmap_update_bits(st->regmap, ADS1262_IDACMAG_REG,
> + ADS1262_IDACMAG_MAG1_MASK |
> + ADS1262_IDACMAG_MAG2_MASK, val);
> +}
> +
> +static int ads1262_gpio_setup(struct ads1262 *st)
> +{
> + struct device *dev = &st->spi->dev;
> + struct gpio_desc *gpiod;
> + const char *con_id;
> +
> + con_id = "start";
Nope, see further
> + gpiod = devm_gpiod_get_optional(dev, con_id, GPIOD_OUT_LOW);
> + if (IS_ERR(gpiod))
> + return dev_err_probe(dev, PTR_ERR(gpiod),
> + "Failed to get %s GPIO\n", con_id);
> + st->start_gpiod = gpiod;
> +
> + con_id = "reset";
Nope
> + gpiod = devm_gpiod_get_optional(dev, con_id, GPIOD_OUT_HIGH);
> + if (IS_ERR(gpiod))
> + return dev_err_probe(dev, PTR_ERR(gpiod),
> + "Failed to get %s GPIO\n", con_id);
> + st->reset_gpiod = gpiod;
> +
> + return 0;
> +}
> +
> +static int ads1262_clk_setup(struct ads1262 *st)
> +{
> + struct device *dev = &st->spi->dev;
> + struct clk *clk;
> + int ret;
> +
> + clk = devm_clk_get_optional_enabled(dev, NULL);
> + if (IS_ERR(clk))
> + return dev_err_probe(dev, PTR_ERR(clk),
> + "Failed to get external clock\n");
> +
> + /*
> + * The nominal clock frequency as indicated by the datasheet is
> + * 7372800.
> + */
> + ret = clk_set_rate(clk, 7372800);
> + if (ret)
> + return dev_err_probe(dev, PTR_ERR(clk),
> + "Failed to set the nominal clock frequency.\n");
> +
> + return 0;
> +}
> +
> +static int ads1262_regulator_setup(struct ads1262 *st)
> +{
> + struct device *dev = &st->spi->dev;
> + const char *reg_id, *prop;
> + u32 mux[2] = {};
> + int val, ret;
> +
> + reg_id = "dvdd";
> + ret = devm_regulator_get_enable(dev, reg_id);
> + if (ret)
> + goto err_regulator_get;
> +
> + reg_id = "avdd";
Nope.
> + ret = devm_regulator_get_enable(dev, reg_id);
> + if (ret)
> + goto err_regulator_get;
> +
> + prop = "ti,neg-refmux";
> + device_property_read_u32(dev, prop, &mux[0]);
> + if (mux[0] >= ADS1262_RMUX_COUNT)
> + return dev_err_probe(dev, -ENXIO, " %s out of range\n", prop);
> +
> + prop = "ti,pos-refmux";
Don't do such syntax. You make git grep unnecesssary difficult.
> + device_property_read_u32(dev, prop, &mux[1]);
And this shows in `git grep` as completely pointless code.
> + if (mux[1] >= ADS1262_RMUX_COUNT)
> + return dev_err_probe(dev, -ENXIO, " %s out of range\n", prop);
> +
> + if (mux[0] == ADS1262_RMUX_INTER && mux[1] == ADS1262_RMUX_INTER) {
> + /* The internal voltage reference is 2.5 V */
> + st->vref_uV = 2500000;
> + return 0;
> + }
> +
> + val = FIELD_PREP(ADS1262_REFMUX_RMUXN_MASK, mux[0]);
> + val |= FIELD_PREP(ADS1262_REFMUX_RMUXP_MASK, mux[1]);
> + ret = regmap_update_bits(st->regmap, ADS1262_REFMUX_REG,
> + ADS1262_REFMUX_RMUXN_MASK |
> + ADS1262_REFMUX_RMUXP_MASK, val);
> + if (ret)
> + return ret;
> +
> + reg_id = "vref";
Nope.
> + st->vref_uV = devm_regulator_get_enable_read_voltage(dev, reg_id);
> + if (st->vref_uV < 0)
> + goto err_regulator_get;
> +
> + return 0;
> +
> +err_regulator_get:
> + return dev_err_probe(dev, ret, "Failed to get regulator %s\n", reg_id);
> +}
> +
Functions used by probe() should be before probe(), not somewhere in the
middle of the code. IOW, entire probe is together.
...
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static int ads1262_runtime_suspend(struct device *dev)
> +{
> + struct ads1262 *st = dev_get_drvdata(dev);
> +
> + if (!st->reset_gpiod)
> + return 0;
> +
> + regcache_cache_only(st->regmap, true);
> +
> + return ads1262_dev_power_off(st);
> +}
> +
> +static int ads1262_runtime_resume(struct device *dev)
> +{
> + struct ads1262 *st = dev_get_drvdata(dev);
> + int ret;
> +
> + if (!st->reset_gpiod)
> + return 0;
> +
> + ret = ads1262_dev_power_on(st);
> + if (ret)
> + return ret;
> +
> + regcache_cache_only(st->regmap, false);
> + regcache_mark_dirty(st->regmap);
> +
> + return regcache_sync(st->regmap);
> +}
> +
> +DEFINE_RUNTIME_DEV_PM_OPS(ads1262_runtime_pm, ads1262_runtime_suspend,
> + ads1262_runtime_resume, NULL);
> +
> +static const struct of_device_id ads1262_of_match[] = {
> + { .compatible = "ti,ads1262" },
> + { .compatible = "ti,ads1263" },
So devices are fully compatible? Then it should be expressed in the
binding and drop one entry here.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox