user/sven/linux.git/include/soc, branch v6.10.7

net: mscc: ocelot: serialize access to the injection/extraction groups

2024-08-29T15:35:56Z

[ Upstream commit c5e12ac3beb0dd3a718296b2d8af5528e9ab728e ] As explained by Horatiu Vultur in commit 603ead96582d ("net: sparx5: Add spinlock for frame transmission from CPU") which is for a similar hardware design, multiple CPUs can simultaneously perform injection or extraction. There are only 2 register groups for injection and 2 for extraction, and the driver only uses one of each. So we'd better serialize access using spin locks, otherwise frame corruption is possible. Note that unlike in sparx5, FDMA in ocelot does not have this issue because struct ocelot_fdma_tx_ring already contains an xmit_lock. I guess this is mostly a problem for NXP LS1028A, as that is dual core. I don't think VSC7514 is. So I'm blaming the commit where LS1028A (aka the felix DSA driver) started using register-based packet injection and extraction. Fixes: 0a6f17c6ae21 ("net: dsa: tag_ocelot_8021q: add support for PTP timestamping") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: mscc: ocelot: use ocelot_xmit_get_vlan_info() also for FDMA and register injection

2024-08-29T15:35:56Z

[ Upstream commit 67c3ca2c5cfe6a50772514e3349b5e7b3b0fac03 ] Problem description ------------------- On an NXP LS1028A (felix DSA driver) with the following configuration: - ocelot-8021q tagging protocol - VLAN-aware bridge (with STP) spanning at least swp0 and swp1 - 8021q VLAN upper interfaces on swp0 and swp1: swp0.700, swp1.700 - ptp4l on swp0.700 and swp1.700 we see that the ptp4l instances do not see each other's traffic, and they all go to the grand master state due to the ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES condition. Jumping to the conclusion for the impatient ------------------------------------------- There is a zero-day bug in the ocelot switchdev driver in the way it handles VLAN-tagged packet injection. The correct logic already exists in the source code, in function ocelot_xmit_get_vlan_info() added by commit 5ca721c54d86 ("net: dsa: tag_ocelot: set the classified VLAN during xmit"). But it is used only for normal NPI-based injection with the DSA "ocelot" tagging protocol. The other injection code paths (register-based and FDMA-based) roll their own wrong logic. This affects and was noticed on the DSA "ocelot-8021q" protocol because it uses register-based injection. By moving ocelot_xmit_get_vlan_info() to a place that's common for both the DSA tagger and the ocelot switch library, it can also be called from ocelot_port_inject_frame() in ocelot.c. We need to touch the lines with ocelot_ifh_port_set()'s prototype anyway, so let's rename it to something clearer regarding what it does, and add a kernel-doc. ocelot_ifh_set_basic() should do. Investigation notes ------------------- Debugging reveals that PTP event (aka those carrying timestamps, like Sync) frames injected into swp0.700 (but also swp1.700) hit the wire with two VLAN tags: 00000000: 01 1b 19 00 00 00 00 01 02 03 04 05 81 00 02 bc ~~~~~~~~~~~ 00000010: 81 00 02 bc 88 f7 00 12 00 2c 00 00 02 00 00 00 ~~~~~~~~~~~ 00000020: 00 00 00 00 00 00 00 00 00 00 00 01 02 ff fe 03 00000030: 04 05 00 01 00 04 00 00 00 00 00 00 00 00 00 00 00000040: 00 00 The second (unexpected) VLAN tag makes felix_check_xtr_pkt() -> ptp_classify_raw() fail to see these as PTP packets at the link partner's receiving end, and return PTP_CLASS_NONE (because the BPF classifier is not written to expect 2 VLAN tags). The reason why packets have 2 VLAN tags is because the transmission code treats VLAN incorrectly. Neither ocelot switchdev, nor felix DSA, declare the NETIF_F_HW_VLAN_CTAG_TX feature. Therefore, at xmit time, all VLANs should be in the skb head, and none should be in the hwaccel area. This is done by: static struct sk_buff *validate_xmit_vlan(struct sk_buff *skb, netdev_features_t features) { if (skb_vlan_tag_present(skb) && !vlan_hw_offload_capable(features, skb->vlan_proto)) skb = __vlan_hwaccel_push_inside(skb); return skb; } But ocelot_port_inject_frame() handles things incorrectly: ocelot_ifh_port_set(ifh, port, rew_op, skb_vlan_tag_get(skb)); void ocelot_ifh_port_set(struct sk_buff *skb, void *ifh, int port, u32 rew_op) { (...) if (vlan_tag) ocelot_ifh_set_vlan_tci(ifh, vlan_tag); (...) } The way __vlan_hwaccel_push_inside() pushes the tag inside the skb head is by calling: static inline void __vlan_hwaccel_clear_tag(struct sk_buff *skb) { skb->vlan_present = 0; } which does _not_ zero out skb->vlan_tci as seen by skb_vlan_tag_get(). This means that ocelot, when it calls skb_vlan_tag_get(), sees (and uses) a residual skb->vlan_tci, while the same VLAN tag is _already_ in the skb head. The trivial fix for double VLAN headers is to replace the content of ocelot_ifh_port_set() with: if (skb_vlan_tag_present(skb)) ocelot_ifh_set_vlan_tci(ifh, skb_vlan_tag_get(skb)); but this would not be correct either, because, as mentioned, vlan_hw_offload_capable() is false for us, so we'd be inserting dead code and we'd always transmit packets with VID=0 in the injection frame header. I can't actually test the ocelot switchdev driver and rely exclusively on code inspection, but I don't think traffic from 8021q uppers has ever been injected properly, and not double-tagged. Thus I'm blaming the introduction of VLAN fields in the injection header - early driver code. As hinted at in the early conclusion, what we _want_ to happen for VLAN transmission was already described once in commit 5ca721c54d86 ("net: dsa: tag_ocelot: set the classified VLAN during xmit"). ocelot_xmit_get_vlan_info() intends to ensure that if the port through which we're transmitting is under a VLAN-aware bridge, the outer VLAN tag from the skb head is stripped from there and inserted into the injection frame header (so that the packet is processed in hardware through that actual VLAN). And in all other cases, the packet is sent with VID=0 in the injection frame header, since the port is VLAN-unaware and has logic to strip this VID on egress (making it invisible to the wire). Fixes: 08d02364b12f ("net: mscc: fix the injection header") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux

2024-05-18T19:48:37Z

Pull clk updates from Stephen Boyd: "I'm actually surprised this time. There aren't any new Qualcomm SoC clk drivers. And there's zero diff in the core clk framework. Instead we have new clk drivers for STM and Sophgo, with Samsung^WGoogle in third for the diffstat because they introduced HSI0 and HSI2 clk drivers for Google's GS101 SoC (high speed interface things like PCIe, UFS, and MMC). Beyond those big diffs there's the usual updates to various clk drivers for incorrect parent descriptions or mising MODULE_DEVICE_TABLE()s, etc. Nothing in particular stands out as super interesting here. New Drivers: - STM32MP257 SoC clk driver - Airoha EN7581 SoC clk driver - Sophgo CV1800B, CV1812H and SG2000 SoC clk driver - Loongson-2k0500 and Loongson-2k2000 SoC clk driver - Add HSI0 and HSI2 clock controllers for Google GS101 - Add i.MX95 BLK CTL clock driver Updates: - Allocate clk_ops dynamically for SCMI clk driver - Add support in qcom RCG and RCG2 for multiple configurations for the same frequency - Use above support for IPQ8074 NSS port 5 and 6 clocks to resolve issues - Fix the Qualcomm APSS IPQ5018 PLL to fix boot failures of some boards - Cleanups and fixes for Qualcomm Stromer PLLs - Reduce max CPU frequency on Qualcomm APSS IPQ5018 - Fix Kconfig dependencies of Qualcomm SM8650 GPU and SC8280XP camera clk drivers - Make Qualcomm MSM8998 Venus clocks functional - Cleanup downstream remnants related to DisplayPort across Qualcomm SM8450, SM6350, SM8550, and SM8650 - Reuse the Huayra APSS register map on Qualcomm MSM8996 CBF PLL - Use a specific Qualcomm QCS404 compatible for the otherwise generic HFPLL - Remove Qualcomm SM8150 CPUSS AHB clk as it is unused - Remove an unused field in the Qualcomm RPM clk driver - Add missing MODULE_DEVICE_TABLE to Qualcomm MSM8917 and MSM8953 global clock controller drivers - Allow choice of manual or firmware-driven control over PLLs, needed to fully implement CPU clock controllers on Exynos850 - Correct PLL clock IDs on ExynosAutov9 - Propagate certain clock rates to allow setting proper SPI clock rates on Google GS101 - Mark certain Google GS101 clocks critical - Convert old S3C64xx clock controller bindings to DT schema - Add new PLL rate and missing mux on Rockchip rk3568 - Add missing reset line on Rockchip rk3588 - Removal of an unused field in struct rockchip_mmc_clock - Amlogic s4/a1: add regmap maximum register for proper debugfs dump - Amlogic s4: add MODULE_DEVICE_TABLE() on pll and periph controllers - Amlogic pll driver: print clock name on lock error to help debug - Amlogic vclk: finish dsi clock path support - Amlogic license: fix occurence "GPL v2" as reported by checkpatch - Add PM runtime support to i.MX8MP Audiomix - Add DT schema for i.MX95 Display Master Block Control - Convert to platform remove callback returning void for i.MX8MP Audiomix - Add SPI (MSIOF) and external interrupt (INTC-EX) clocks on Renesas R-Car V4M - Add interrupt controller (PLIC) clock and reset on Renesas RZ/Five - Prepare power domain support for Renesas RZ/G2L family members, and add actual support on Renesas RZ/G3S SoC - Add thermal, serial (SCIF), and timer (CMT/TMU) clocks on Renesas R-Car V4M - Add additional constraints to Allwinner A64 PLL MIPI clock - Fix autoloading sunxi-ng clocks when build as a module" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (118 commits) clk: samsung: Don't register clkdev lookup for the fixed rate clocks clk, reset: microchip: mpfs: fix incorrect preprocessor conditions clk: qcom: clk-alpha-pll: fix rate setting for Stromer PLLs clk: qcom: apss-ipq-pll: fix PLL rate for IPQ5018 clk: qcom: Fix SM_GPUCC_8650 dependencies clk: qcom: Fix SC_CAMCC_8280XP dependencies dt-bindings: clocks: stm32mp25: add access-controllers description clock, reset: microchip: move all mpfs reset code to the reset subsystem clk: samsung: gs101: drop unused HSI2 clock parent data clk: rockchip: rk3568: Add PLL rate for 724 MHz clk: rockchip: Remove an unused field in struct rockchip_mmc_clock dt-bindings: clock: fixed: Define a preferred node name clk: meson: s4: fix module autoloading clk: samsung: gs101: mark some apm UASC and XIU clocks critical clk: imx: imx8mp: Convert to platform remove callback returning void clk: imx: imx8mp: Switch to RUNTIME_PM_OPS() clk: bcm: rpi: Assign ->num before accessing ->hws clk: bcm: dvp: Assign ->num before accessing ->hws clk: samsung: gs101: add support for cmu_hsi2 clk: samsung: gs101: add support for cmu_hsi0 ...

Merge tag 'keys-trusted-next-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd

2024-05-13T17:38:13Z

Pull trusted keys updates from Jarkko Sakkinen: "This contains a new key type for the Data Co-Processor (DCP), which is an IP core built into many NXP SoCs such as i.mx6ull" * tag 'keys-trusted-next-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: docs: trusted-encrypted: add DCP as new trust source docs: document DCP-backed trusted keys kernel params MAINTAINERS: add entry for DCP-based trusted keys KEYS: trusted: Introduce NXP DCP-backed trusted keys KEYS: trusted: improve scalability of trust source config crypto: mxs-dcp: Add support for hardware-bound keys

crypto: mxs-dcp: Add support for hardware-bound keys

2024-05-09T15:29:03Z

DCP (Data Co-Processor) is able to derive private keys for a fused random seed, which can be referenced by handle but not accessed by the CPU. Similarly, DCP is able to store arbitrary keys in four dedicated key slots located in its secure memory area (internal SRAM). These keys can be used to perform AES encryption. Expose these derived keys and key slots through the crypto API via their handle. The main purpose is to add DCP-backed trusted keys. Other use cases are possible too (see similar existing paes implementations), but these should carefully be evaluated as e.g. enabling AF_ALG will give userspace full access to use keys. In scenarios with untrustworthy userspace, this will enable en-/decryption oracles. Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir Acked-by: Herbert Xu Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

clk, reset: microchip: mpfs: fix incorrect preprocessor conditions

2024-05-09T01:38:12Z

While moving all the reset code in the PolarFire SoC clock driver to the reset subsystem, I removed an `#if IS_ENABLED(RESET_CONTROLLER)` from the driver and moved it to the header, however this was not the correct thing to do. In the driver such a condition over-eagerly provided a complete implementation for mpfs_reset_{read,write}() when the reset subsystem was enabled without the PolarFire SoC reset driver, but in the header it meant that when the subsystem was enabled and the driver was not, no implementation for mpfs_reset_controller_register() was provided. Fix the condition so that the stub implementation of mpfs_reset_controller_register() is used when the reset driver is disabled. Fixes: 098c290a490d ("clock, reset: microchip: move all mpfs reset code to the reset subsystem") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202405082259.44DzHvaN-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405082200.tBrEs5CZ-lkp@intel.com/ Signed-off-by: Conor Dooley Link: https://lore.kernel.org/r/20240508-unabashed-cheese-8f645b4f69ba@spud Signed-off-by: Stephen Boyd

clock, reset: microchip: move all mpfs reset code to the reset subsystem

2024-05-07T21:57:46Z

Stephen and Philipp, while reviewing patches, said that all of the aux device creation and the register read/write code could be moved to the reset subsystem, leaving the clock driver with no implementations of reset_* functions at all. Move them. Suggested-by: Philipp Zabel Suggested-by: Stephen Boyd Signed-off-by: Conor Dooley Link: https://lore.kernel.org/r/20240424-strangle-sharpener-34755c5e6e3e@spud Signed-off-by: Stephen Boyd

soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request

2024-04-21T17:11:40Z

Each RPMh VRM accelerator resource has 3 or 4 contiguous 4-byte aligned addresses associated with it. These control voltage, enable state, mode, and in legacy targets, voltage headroom. The current in-flight request checking logic looks for exact address matches. Requests for different addresses of the same RPMh resource as thus not detected as in-flight. Add new cmd-db API cmd_db_match_resource_addr() to enhance the in-flight request check for VRM requests by ignoring the address offset. This ensures that only one request is allowed to be in-flight for a given VRM resource. This is needed to avoid scenarios where request commands are carried out by RPMh hardware out-of-order leading to LDO regulator over-current protection triggering. Fixes: 658628e7ef78 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs") Cc: stable@vger.kernel.org Reviewed-by: Konrad Dybcio Tested-by: Elliot Berman # sm8650-qrd Signed-off-by: Maulik Shah Link: https://lore.kernel.org/r/20240215-rpmh-rsc-fixes-v4-1-9cbddfcba05b@quicinc.com Signed-off-by: Bjorn Andersson

Merge tag 'char-misc-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2024-03-21T20:21:31Z

Pull char/misc and other driver subsystem updates from Greg KH: "Here is the big set of char/misc and a number of other driver subsystem updates for 6.9-rc1. Included in here are: - IIO driver updates, loads of new ones and evolution of existing ones - coresight driver updates - const cleanups for many driver subsystems - speakup driver additions - platform remove callback void cleanups - mei driver updates - mhi driver updates - cdx driver updates for MSI interrupt handling - nvmem driver updates - other smaller driver updates and cleanups, full details in the shortlog All of these have been in linux-next for a long time with no reported issue, other than a build warning for the speakup driver" The build warning hits clang and is a gcc (and C23) extension, and is fixed up in the merge. Link: https://lore.kernel.org/all/20240321134831.GA2762840@dev-arch.thelio-3990X/ * tag 'char-misc-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (279 commits) binder: remove redundant variable page_addr uio_dmem_genirq: UIO_MEM_DMA_COHERENT conversion uio_pruss: UIO_MEM_DMA_COHERENT conversion cnic,bnx2,bnx2x: use UIO_MEM_DMA_COHERENT uio: introduce UIO_MEM_DMA_COHERENT type cdx: add MSI support for CDX bus pps: use cflags-y instead of EXTRA_CFLAGS speakup: Add /dev/synthu device speakup: Fix 8bit characters from direct synth parport: sunbpp: Convert to platform remove callback returning void parport: amiga: Convert to platform remove callback returning void char: xillybus: Convert to platform remove callback returning void vmw_balloon: change maintainership MAINTAINERS: change the maintainer for hpilo driver char: xilinx_hwicap: Fix NULL vs IS_ERR() bug hpet: remove hpets::hp_clocksource platform: goldfish: move the separate 'default' propery for CONFIG_GOLDFISH char: xilinx_hwicap: drop casting to void in dev_set_drvdata greybus: move is_gb_* functions out of greybus.h greybus: Remove usage of the deprecated ida_simple_xx() API ...

Merge tag 'qcom-drivers-for-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers

2024-03-04T15:52:37Z

Qualcomm driver updates for v6.9 This introduces the Qualcomm Programmable Boot Sequencer (PBS) driver. The Qualcomm SMEM no longer acquires the hwspinlock during the "get" operation, to improve the system behavior during the recovery of a remoteproc that crashed with the hwspinlock held. The Qualcomm Always On Subsystem (AOSS) message protocol driver gains tracepoints, printf annotation, and a debugfs interface is introduced for tweaking system properties during development and debugging. The Qualcomm socinfo driver gains data for SM8475, QCM8550 and QCS8550 platforms, and the PM2250 is renamed to PM4125. Support for controlling the voltage regulator in SPM/SAW2 is introduced. The gfx.lvl power-domain is dropped for SA8540P, as this resource was incorrectly inherited from SC8280XP. Additionally some code cleanup improvements is introduced across APR, LLCC, SMP2P and SPM. * tag 'qcom-drivers-for-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (23 commits) dt-bindings: soc: qcom: qcom,saw2: add msm8226 l2 compatible soc: qcom: spm: add support for voltage regulator soc: qcom: spm: remove driver-internal structures from the driver API dt-bindings: soc: qcom: qcom,saw2: define optional regulator node dt-bindings: soc: qcom: qcom,saw2: add missing compatible strings dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml soc: qcom: llcc: Check return value on Broadcast_OR reg read soc: qcom: socinfo: Add Soc IDs for SM8475 family dt-bindings: arm: qcom,ids: Add IDs for SM8475 family soc: qcom: apr: make aprbus const dt-bindings: soc: qcom: qcom,pmic-glink: document X1E80100 compatible soc: qcom: add QCOM PBS driver dt-bindings: soc: qcom: Add qcom,pbs bindings pmdomain: qcom: rpmhpd: Drop SA8540P gfx.lvl soc: qcom: socinfo: rename PM2250 to PM4125 soc: qcom: aoss: Add tracepoints in qmp_send() soc: qcom: socinfo: add SoC Info support for QCM8550 and QCS8550 platform dt-bindings: arm: qcom,ids: add SoC ID for QCM8550 and QCS8550 soc: qcom: aoss: Add debugfs interface for sending messages soc: qcom: smem: remove hwspinlock from item get routine ... Link: https://lore.kernel.org/r/20240225030612.480241-1-andersson@kernel.org Signed-off-by: Arnd Bergmann