kernel/git/next/linux-next.git/Documentation/driver-api, branch master

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git

2026-09-07T13:48:21+00:00

Merge branch 'pwm/for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git

2026-09-07T13:48:05+00:00

Merge branch 'gpio/for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git

2026-09-07T13:47:57+00:00

Documentation: gpio: Fix bracket

2026-09-07T08:37:15+00:00

Balance parentheses. Signed-off-by: Manuel Ebner Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260903155345.733244-2-manuelebnerli@mailbox.org Signed-off-by: Bartosz Golaszewski

mtd: spi-nor: Refactor Read Status/Write Status support

2026-09-07T07:45:20+00:00

SPI NOR has a lot of history. Additions over additions, the subtleties of the JESD216 specification, their implementations by the manufacturers and the hardware mistakes have generated a gigantic maze, let's try to understand what is really needed. The specification explains the QE (Quad Enable) bitfield as describing where the bit to enable the Quad capability is, but also how to set it. Unfortunately, the specification is not precise about what opcodes are supported exactly in all the cases. There is an introduction that basically states: - Opcode 0x05 reads SR1 - Opcode 0x35 reads SR2 - Opcode 0x01 writes SR1, and then SR2 if another byte is written Then the bitfield, among indicating the location of the QE bit, may indicate: - Reading SR1 and SR2 in one operation is not possible (loops over the content of SR1) - Reading SR2 directly is possible - Only writing SR1 zeroes SR2. One problem with the current implementation, is that it only focuses on the QE bit. A quad_enable function was created for each case, even though in practice, the logic was always the same: read, modify, write, read back and verify. One problem comes when other features need to play with the status registers, like software block protection or OTP: you never know how to properly handle the QE bit, nor where it is, nor how to read/write the Status registers. This lead to approximations/guessing (in swp.c, otp.c and obviously in legacy controller drivers like atmel.c) but also to the implementation of a gazillon of helpers for reading/writing/checking the status registers. In addition, I believe some design decisions had a negative impact over the years. - All possible situations had to be flagged by the core. This is likely wrong, because we no longer know why we need specific quirks. It was ineherent to the state of the SPI NOR core before the great cleanup that had happened the past few years. I believe this creates confusion in the core today, and we should push this to vendor fixups instead. As an example, in 2023 Hsin-Yi was facing an issue because his chip was setting the wrong QER value, leading to RDCR being prevented, thus falling into a condition blindly setting a random QE bit (I strongy believe it is done like that for wrong reasons). His chip actually had RDCR support! The correct fix should have been to mark the capability in a device fixup instead of handling this in the core. Link: https://lore.kernel.org/lkml/CAJMQK-hR0eaO0b4Vd0U8_KAndLyZapqdHjVLAoe42rWi9rdLkA@mail.gmail.com/ - SFDP parsing is over cautious. I believe BFPT_DWORD15_QER_SR2_BIT1_NO_RD is abusive (nothing states that RDCR is not supported), and BFPT_DWORD15_QER_SR2_BIT1 is also out of specification when forcing 16-bit Status writes. - SNOR_F_HAS_16BIT_SR is only imposing 16bit Status writes, whereas reads can still be 8-bit wide. - The usage of helpers verifying the writes was also spread for IMHO no really good reason. Why shouldn't we trust spi operations when it comes to Status Registers? We do not read back our page reads, so why status registers should be treated with so much care, if it's not because we are unsure of what is being done? My proposal includes a check when it comes to the QE bit (done once) but we don't need these checks otherwise. If the QE bit was written properly, there are high chances that the other register accesses will just be fine, no? Asde from my main quest, I also observed no good reason to ask the read/write status register callers to use nor->bouncebuf while the low-level helpers could do it themselves (we are talking about one or two bytes being copied). So after these observations, my proposal is the following: - Create private low level helpers that just read or write a status register. They are flexible, we can give the opcode (which varies based on the SFDP QER field) and the length (1 or 2). - Create public generic accessors which will be used to read/write sr1 and/or sr2. This is where all the cleverness shall be. The helpers use the available opcodes for a given chip in order to fullfill the request. - Provide a single generic ->quad_enable() hook which generically does all the steps mentioned above (read, modify, write, read back and verify). - Create a list of opcodes for all 6 possible situations: {read, write} {sr1, sr2, sr1 and sr2}. These opcodes are filled/cleared based on the QER field. An opcode set to 0 indicates the absence of support (there is no 0x00 opcode in SPI NOR). I tried my best to analyze the current behavior and to mimic it as much as possible, but this is a risky cleanup. However, if we go for this, it will be *much* easier in the future to handle all kind of chip variations. We won't be limited to a couple of flags anymore, but rather we'll be able to just disable a read or write capability using a single line. Known deviations: - The Atmel manufacturer driver drives non SFDP chips which by default were receiving the HAS_16B_WR flag, forcing SR2 writes all the times, but it was deliberately making single bytes writes to SR1 for its locking operations. The flag is likely wrong for them, so I removed it. - I am proposing on purpose a single quad_enable helper. It should match all the cases, with 1 identified difference which I believe is harmless: in the SR2_BIT7 case, the helper would make an extra SR1 read/write which was not done before. This entry explicitly supports reading and writing the two registers. Note: no manufacturer has been identified to actually use that entry yet. Signed-off-by: Miquel Raynal Signed-off-by: Michael Walle

docs: pwm: Fix bracket and punctuation

2026-09-05T08:13:29+00:00

Remove needless '(' and fix comma splice. Signed-off-by: Manuel Ebner Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260904122005.760299-2-manuelebnerli@mailbox.org Signed-off-by: Uwe Kleine-König

cxl: docs/platform/acpi: Fix brackets

2026-09-03T16:52:06+00:00

Add '}' and fix indentation. Signed-off-by: Manuel Ebner Reviewed-by: Randy Dunlap Link: https://patch.msgid.link/20260903095445.729419-2-manuelebnerli@mailbox.org Signed-off-by: Dave Jiang

Merge tag 'acpi-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2026-08-26T21:06:08+00:00

Pull more ACPI support updates from Rafael Wysocki: "These update documentation to reflect recent changes in the upstream ACPICA project, fix issues in the core ACPI device enumeration code (one of which has been introduced recently), improve the primary "physical" device lookup for ACPI device objects in that code, and update ACPI device drivers: - Update MAINTAINERS, CREDITS and ACPI subsystem documentation to reflect recent changes in the upstream ACPICA project (Rafael Wysocki) - Prevent the core ACPI enumeration code from combining device resources that overlap completely in order to avoid resource conflicts during platform device registration because there are drivers that expect such resources to be present (Rafael Wysocki) - Defer device power initialization during ACPI-based device enumeration to the point when the given device is known to be present and functional and all of its dependencies have been met (Peixin Xie) - Fix bus ID cleanup on device_add() failures during ACPI device object registration (Hongyan Xu) - Introduce a new helper function for looking up the primary "physical" device for a given ACPI device object and update the core ACPI device enumeration code to use that function (Rafael Wysocki) - Protect all battery properties with a separated mutex in the ACPI battery driver to prevent race conditions from occurring and avoid evaluating the _BST ACPI control method multiple times in parallel for the same battery device (Rong Zhang) - Add DMI quirk for the Razer Blade Pro 17 early 2020 lid switch to the ACPI button driver (Robin Everaars) - Convert fixed clock rates in the ACPI driver for AMD SoCs (APD) to use HZ_PER_MHZ and add a clock frequency for the HJMC01 I2C controller to it (Hongnan Li and Xiangyang Yu) - Fix a stack buffer overflow in query_capability() in the ACPI platform firmware runtime update driver (Anirudh Prasad)" * tag 'acpi-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch ACPI: scan: Do not combine resources that overlap completely ACPI: Update upstream ACPICA repository URL in documentation ACPI: Update MAINTAINERS entry for ACPICA ACPI: Add Bob Moore to CREDITS ACPI: pfr_update: fix stack buffer overflow in query_capability() ACPI: scan: Defer device power initialization ACPI: APD: Add clock frequency for HJMC01 I2C controller ACPI: APD: Convert fixed clock rates to use HZ_PER_MHZ ACPI: scan: Use acpi_bus_get_primary_device() ACPI: platform: Use acpi_bus_get_primary_device() ACPI: bus: Introduce acpi_bus_get_primary_device() ACPI: scan: fix bus ID cleanup on device_add() failures ACPI: battery: Protect all properties with a separated mutex

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

2026-08-26T18:14:30+00:00

Pull clk updates from Stephen Boyd: "Mostly the usual clk driver updates and new SoC additions plus non-critical data fixes for things that weren't used yet. One thing that's new here in the core is SSC spread spectrum support (SSC) in the clk provider API. The idea is that DT authors will configure SSC for certain clks and they'll be configured at clk provider registration time or when a consumer device is probed, similar to how we handle assigned clk rates or parents. On the clk driver side we have Qualcomm adding almost half the diff because they add support for 4 different SoCs and then a long tail of other SoCs like Mediatek, Renesas, Rockchip, SpaceMiT, etc. add more SoC support this time around. Luckily it's mostly clk data for these new SoCs because the actual clk_ops are already there. Beyond the new drivers we get all the little fixups for more compilation coverage or usage of more modern APIs. That all looks normal. Finally, I kinda buried the lede, I'm bringing on Brian and Jerome to help out with maintaining the clk subsystem. The current working model is already semi-distributed in that silicon vendors typically take care of their drivers and send me pull requests but I'm becoming a bottleneck for new drivers and core framework review because this has become a 100% volunteer effort on my part. Mike is stepping down after all these years (thanks Mike!) and that jump started the conversation around finding co-maintainers. Brian and Jerome have graciously offered to help me with the work load, meaning in the future they'll be sending pull requests and committing directly to the clk.git tree. They've both been around on the list for a while, I've met them both in person, and they've been making changes to the core clk framework along with helping review patches so I'm pretty confident this will work well. Core: - devm_clk_bulk_get_enable() consumer API - devm_clk_hw_register_composite_pdata() provider API - Spread Spectrum Clock (SSC) support via DT bindings and provider APIs - Divider clk rounding improved (and tested) New Drivers: - Cix Sky1 audio subsystem (AUDSS) - UltraRISC DP1000 - MediaTek MT8173 MFG_TOP - Si549 - Aspeed AST2700 PECI - Airoha EN7523 PCIe - Rockchip RV1106 - Mobileye EyeQ7H - Qualcomm Maili GCC, TCSR, RPMh, and video clks - Qualcomm Shikra GCC, RPM, GPU, display, and audio clks - Qualcomm Nord display and graphics clks - Qualcomm Glymur camera and EVA clks - Qualcomm Hawi video clks - Amlogic A9 AO and peripheral clks - Renesas R-Car X5H (R8A78000) CPG" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (269 commits) clk: microchip: mpfs: fix regmap_update_bits() mask/val order clk: visconti: Make sure clk_init_data is fully initialized clk: ti: Make sure clk_init_data is fully initialized MAINTAINERS: Add Brian Masney and Jerome Brunet as co-maintainers for clk subsystem Drop Michael Turquette's clk maintainer entry clk: ti: composite: resolve parent clocks by DT index, not by name clk: ti: mux: resolve parent clocks by DT index, not by name clk: devres: fix cleanup in devm_clk_get_optional_enabled_with_rate() dt-bindings: clock: ti,keystone-gate: Convert to DT schema dt-bindings: clock: ti: Convert APLL clock to DT schema clk: zynq: pll: Fix kernel-doc after determine_rate() conversion dt-bindings: clock: ti,clockdomain: Convert to DT schema dt-bindings: clock: Correct white-space style clk: samsung: Don't include clk: at91: Read "reg" with helper clk: renesas: Add R-Car X5H CPG driver clk: rockchip: rk3576: fix source muxes for SPI0..SPI4 clk: rockchip: Add clock controller for the RV1106 dt-bindings: clock: rockchip: Add RV1106 CRU support dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator ...

Merge tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

2026-08-26T15:45:09+00:00

Pull another power sequencing update from Bartosz Golaszewski: "A single tree-wide rename of two of the public functions to better reflect their actual semantics: - rename pwrseq_power_on/off() to pwrseq_enable/disable() tree-wide" * tag 'pwrseq-updates-for-v7.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: rename pwrseq_power_on/off() to pwrseq_enable/disable()