Linux 5.17-rc8

Linux 5.17-rc8

[Linus Torvalds]

So last weekend, I thought I'd be releasing the final 5.17 today.

That was then, this is now. Last week was somewhat messy, mostly
because of embargoed patches we had pending with another variation of
spectre attacks.  And while the patches were mostly fine, we had the
usual "because it was hidden, all our normal testing automation didn't
see it either".

And once the automation sees things, it tests all the insane
combinations that people don't tend to actually use or test in any
normal case, and so there was a (small) flurry of fixes for the fixes.

None of this was really surprising, but I naïvely thought I'd be able
to do the final release this weekend anyway.

And honestly, I considered it. I don't think we really have any
pending issues that would hold up a release, but on the other hand we
also really don't have any reason _not_ to give it another week with
all the proper automated testing.  So that's what I'm doing, and as a
result we have an -rc8 release today instead of doing a final 5.17.

There's a number of non-spectre things in here too, of course. Among
other things, people finally chased down a couple of mislaid patches
that had been on the regression list, so hopefully we have those all
nailed down now too.

And obviously there's all the usual random fixes in here too. But
because of the spectre thing, about half of the -rc8 patch is
architecture updates.

That said, it's still a fairly _small_ half of the patch. It was not
one of the "big disaster" hw speculation things, it was mostly
extending existing mitigations and reporting.

Anyway, let's not keep the testing _just_ to automation - the more the
merrier, and real-life loads are always more interesting than what the
automation farms do. So please do give this last rc a quick try,

                    Linus

---

Akhil R (1):
      gpio: tegra186: Add IRQ per bank for Tegra241

Aleksander Jan Bajkowski (1):
      net: lantiq_xrx200: fix use after free bug

Alexey Khoroshilov (1):
      mISDN: Fix memory leak in dsp_pipeline_build()

Andy Shevchenko (2):
      gpiolib: acpi: Convert ACPI value of debounce to microseconds
      gpio: sim: Declare gpio_sim_hog_config_item_ops static

AngeloGioacchino Del Regno (1):
      soc: mediatek: mt8192-mmsys: Fix dither to dsi0 path's input sel

Anirudh Rayabharam (1):
      vhost: fix hung thread due to erroneous iotlb entries

Arnaldo Carvalho de Melo (2):
      tools kvm headers arm64: Update KVM headers from the kernel sources
      tools headers cpufeatures: Sync with the kernel sources

Aswath Govindraju (1):
      dt-bindings: phy: ti,tcan104x-can: Document mux-states property

Bartosz Golaszewski (1):
      gpio: sim: fix a typo

Ben Ben-Ishay (1):
      net/mlx5e: SHAMPO, reduce TIR indication

Biju Das (1):
      spi: Fix invalid sgs value

Bjorn Andersson (1):
      arm64: dts: qcom: sm8350: Correct UFS symbol clocks

Catalin Marinas (1):
      arm64: Ensure execute-only permissions are not allowed without EPAN

Christophe JAILLET (2):
      ice: Don't use GFP_KERNEL in atomic context
      watch_queue: Use the bitmap API when applicable

Clément Léger (1):
      net: phy: DP83822: clear MISR2 register to disable interrupts

Colin Foster (1):
      net: phy: correct spelling error of media in documentation

Dan Carpenter (1):
      staging: gdm724x: fix use after free in gdm_lte_rx()

Daniel Bristot de Oliveira (1):
      tracing/osnoise: Do not unregister events twice

Daniel Palmer (1):
      ARM: mstar: Select HAVE_ARM_ARCH_TIMER

Dave Ertman (1):
      ice: Fix error with handling of bonding MTU

David Howells (10):
      watch_queue: Fix filter limit check
      watch_queue, pipe: Free watchqueue state after clearing pipe ring
      watch_queue: Fix to release page in ->release()
      watch_queue: Fix to always request a pow-of-2 pipe ring size
      watch_queue: Fix the alloc bitmap size to reflect notes allocated
      watch_queue: Free the alloc bitmap when the watch_queue is torn down
      watch_queue: Fix lack of barrier/sync/lock between post and read
      watch_queue: Make comment about setting ->defunct more accurate
      afs: Fix potential thrashing in afs writeback
      cachefiles: Fix volume coherency attribute

Dima Chumak (1):
      net/mlx5: Fix offloading with ESWITCH_IPV4_TTL_MODIFY_ENABLE

Dmitry Torokhov (1):
      HID: vivaldi: fix sysfs attributes leak

Duoming Zhou (1):
      ax25: Fix NULL pointer dereference in ax25_kill_by_device

Emil Renner Berthing (1):
      riscv: Fix auipc+jalr relocation range checks

Emmanuel Gil Peyrot (1):
      ARM: fix build error when BPF_SYSCALL is disabled

Eric Dumazet (1):
      sctp: fix kernel-infoleak for SCTP sockets

Fabio Estevam (1):
      smsc95xx: Ignore -ENODEV errors when device is unplugged

Guillaume Nault (2):
      selftests: pmtu.sh: Kill tcpdump processes launched by subshell.
      selftests: pmtu.sh: Kill nettest processes launched in subshell.

Halil Pasic (1):
      swiotlb: rework "fix info leak with DMA_FROM_DEVICE"

Hans de Goede (3):
      staging: rtl8723bs: Fix access-point mode deadlock
      staging: rtl8723bs: Improve the comment explaining the locking rules
      Bluetooth: hci_core: Fix unbalanced unlock in set_device_flags()

Heiner Kallweit (2):
      net: phy: meson-gxl: fix interrupt handling in forced mode
      net: phy: meson-gxl: improve link-up behavior

Horatiu Vultur (1):
      clk: lan966x: Fix linking error

Ivan Vecera (1):
      ice: Fix race condition during interface enslave

Jacob Keller (2):
      i40e: stop disabling VFs due to PF error responses
      ice: stop disabling VFs due to PF error responses

James Morse (20):
      arm64: entry.S: Add ventry overflow sanity checks
      arm64: spectre: Rename spectre_v4_patch_fw_mitigation_conduit
      KVM: arm64: Allow indirect vectors to be used without SPECTRE_V3A
      arm64: entry: Make the trampoline cleanup optional
      arm64: entry: Free up another register on kpti's tramp_exit path
      arm64: entry: Move the trampoline data page before the text page
      arm64: entry: Allow tramp_alias to access symbols after the 4K boundary
      arm64: entry: Don't assume tramp_vectors is the start of the vectors
      arm64: entry: Move trampoline macros out of ifdef'd section
      arm64: entry: Make the kpti trampoline's kpti sequence optional
      arm64: entry: Allow the trampoline text to occupy multiple pages
      arm64: entry: Add non-kpti __bp_harden_el1_vectors for mitigations
      arm64: entry: Add vectors that have the bhb mitigation sequences
      arm64: entry: Add macro for reading symbol addresses from the trampoline
      arm64: Add percpu vectors for EL1
      arm64: proton-pack: Report Spectre-BHB vulnerabilities as part
of Spectre-v2
      arm64: Mitigate spectre style branch history side channels
      KVM: arm64: Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated
      arm64: Use the clearbhb instruction in mitigations
      arm64: proton-pack: Include unprivileged eBPF status in Spectre
v2 mitigation reporting

Jarkko Sakkinen (1):
      x86/sgx: Free backing memory after faulting the enclave page

Jedrzej Jagielski (1):
      ice: Fix curr_link_speed advertised speed

Jeff Layton (1):
      fuse: move FUSE_SUPER_MAGIC definition to magic.h

Jeremy Linton (1):
      net: bcmgenet: Don't claim WOL when its not available

Jernej Skrabec (1):
      drm/sun4i: mixer: Fix P010 and P210 format numbers

Jia-Ju Bai (3):
      HID: nintendo: check the return value of alloc_workqueue()
      isdn: hfcpci: check the return value of dma_set_mask() in setup_hw()
      net: qlogic: check the return value of dma_alloc_coherent() in
qed_vf_hw_prepare()

Jianglei Nie (1):
      net: arc_emac: Fix use after free in arc_mdio_probe()

Jiapeng Chong (1):
      ftrace: Fix some W=1 warnings in kernel doc comments

Jiasheng Jiang (2):
      net: ethernet: ti: cpts: Handle error for clk_enable
      net: ethernet: lpc_eth: Handle error for clk_enable

Jiri Kosina (1):
      HID: elo: Revert USB reference counting

Jisheng Zhang (2):
      MAINTAINERS: Update Jisheng's email address
      riscv: alternative only works on !XIP_KERNEL

Joel Stanley (1):
      ARM: dts: aspeed: Fix AST2600 quad spi group

Jon Hunter (1):
      arm64: tegra: Disable ISO SMMU for Tegra194

Jonathan Marek (2):
      arm64: dts: qcom: sm8450: enable GCC_USB3_0_CLKREF_EN for usb
      arm64: dts: qcom: sm8450: fix apps_smmu interrupts

Josh Poimboeuf (3):
      x86/speculation: Include unprivileged eBPF status in Spectre v2
mitigation reporting
      x86/speculation: Warn about Spectre v2 LFENCE mitigation
      x86/speculation: Warn about eIBRS + LFENCE + Unprivileged eBPF + SMT

Jouni Högander (1):
      drm/i915/psr: Set "SF Partial Frame Enable" also on full update

Juergen Gross (12):
      xen/xenbus: don't let xenbus_grant_ring() remove grants in error case
      xen/grant-table: add gnttab_try_end_foreign_access()
      xen/blkfront: don't use gnttab_query_foreign_access() for mapped status
      xen/netfront: don't use gnttab_query_foreign_access() for mapped status
      xen/scsifront: don't use gnttab_query_foreign_access() for mapped status
      xen/gntalloc: don't use gnttab_query_foreign_access()
      xen: remove gnttab_query_foreign_access()
      xen/usb: don't use gnttab_end_foreign_access() in xenhcd_gnttab_done()
      xen/9p: use alloc/free_pages_exact()
      xen/pvcalls: use alloc/free_pages_exact()
      xen/gnttab: fix gnttab_end_foreign_access() without page specified
      xen/netfront: react properly to failing gnttab_end_foreign_access_ref()

Kai Lueke (1):
      Revert "xfrm: state and policy should fail if XFRMA_IF_ID 0"

Kim Phillips (2):
      x86/speculation: Use generic retpoline by default on AMD
      x86/speculation: Update link to AMD speculation whitepaper

Krzysztof Kozlowski (1):
      MAINTAINERS: update Krzysztof Kozlowski's email

Kuldeep Singh (1):
      MAINTAINERS: Update git tree for Broadcom iProc SoCs

Li Huafei (1):
      x86/traps: Mark do_int3() NOKPROBE_SYMBOL

Lina Wang (1):
      xfrm: fix tunnel model fragmentation behavior

Linus Torvalds (2):
      mm: gup: make fault_in_safe_writeable() use fixup_user_fault()
      Linux 5.17-rc8

Lucas Zampieri (1):
      HID: logitech-dj: add new lightspeed receiver id

Luiz Augusto von Dentz (1):
      Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work

Marcelo Roberto Jimenez (1):
      gpio: Revert regression in sysfs-gpio (gpiolib.c)

Mark Featherston (1):
      gpio: ts4900: Do not set DAT and OE together

Maxime Ripard (1):
      ARM: boot: dts: bcm2711: Fix HVS register range

Miaoqian Lin (3):
      ethernet: Fix error handling in xemaclite_of_probe
      net: marvell: prestera: Add missing of_node_put() in
prestera_switch_set_base_mac_addr
      gianfar: ethtool: Fix refcount leak in gfar_get_ts_info

Michael Ellerman (1):
      powerpc: Fix STACKTRACE=n build

Michael Hübner (1):
      HID: Add support for open wheel and no attachment to T300

Michael S. Tsirkin (6):
      virtio: unexport virtio_finalize_features
      virtio: acknowledge all features before access
      virtio: document virtio_reset_device
      virtio_console: break out of buf poll on remove
      virtio: drop default for virtio-mem
      tools/virtio: handle fallout from folio work

Michal Maloszewski (2):
      iavf: Fix handling of vlan strip virtual channel messages
      iavf: Fix adopting new combined setting

Miklos Szeredi (2):
      fuse: fix fileattr op failure
      fuse: fix pipe buffer lifetime for direct_io

Minghao Chi (CGEL ZTE) (1):
      net:mcf8390: Use platform_get_irq() to get the interrupt

Mohammad Kabat (1):
      net/mlx5: Fix size field in bufferx_reg struct

Moshe Shemesh (1):
      net/mlx5: Fix a race on command flush flow

Nathan Chancellor (2):
      arm64: Do not include __READ_ONCE() block in assembly files
      ARM: Do not use NOCROSSREFS directive with ld.lld

Nicolas Saenz Julienne (1):
      tracing/osnoise: Force quiescent states while tracing

Nícolas F. R. A. Prado (1):
      arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint

Pali Rohár (2):
      arm64: dts: armada-3720-turris-mox: Add missing ethernet0 alias
      arm64: dts: marvell: armada-37xx: Remap IO space to bus address 0x0

Paul Semel (1):
      arm64: kasan: fix include error in MTE functions

Pavel Skripkin (2):
      HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts
      NFC: port100: fix use-after-free in port100_send_complete

Peter Zijlstra (3):
      x86/speculation: Add eIBRS + Retpoline options
      Documentation/hw-vuln: Update spectre doc
      x86/module: Fix the paravirt vs alternative order

Peter Zijlstra (Intel) (1):
      x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE

Randy Dunlap (1):
      ARM: Spectre-BHB: provide empty stub for non-config

Rob Herring (1):
      dt-bindings: mfd: Fix pinctrl node name warnings

Robert Foss (2):
      dt-bindings: drm/bridge: anx7625: Revert DPI support
      Revert "arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's
DSI endpoint"

Robert Hancock (1):
      net: macb: Fix lost RX packet wakeup race in NAPI receive

Roger Quadros (1):
      mtd: rawnand: omap2: Actually prevent invalid configuration and
build error

Roi Dayan (1):
      net/mlx5e: Lag, Only handle events from highest priority multipath entry

Rong Chen (1):
      mmc: meson: Fix usage of meson_mmc_post_req()

Ross Philipson (2):
      x86/boot: Fix memremap of setup_indirect structures
      x86/boot: Add setup_indirect support in early_memremap_is_setup_data()

Russell King (Oracle) (9):
      ARM: report Spectre v2 status through sysfs
      ARM: early traps initialisation
      ARM: use LOADADDR() to get load address of sections
      ARM: Spectre-BHB workaround
      net: dsa: mt7530: fix incorrect test in mt753x_phylink_validate()
      ARM: include unprivileged BPF status in Spectre V2 reporting
      ARM: fix co-processor register typo
      ARM: fix build warning in proc-v7-bugs.c
      ARM: fix Thumb2 regression with Spectre BHB

Sebastian Andrzej Siewior (1):
      xdp: xdp_mem_allocator can be NULL in trace_mem_connect().

Shin'ichiro Kawasaki (1):
      block: fix blk_mq_attempt_bio_merge and rq_qos_throttle protection

Si-Wei Liu (3):
      vdpa: factor out vdpa_set_features_unlocked for vdpa internal use
      vdpa/mlx5: should verify CTRL_VQ feature exists for MQ
      vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command

Stanislav Jakubek (1):
      Revert "dt-bindings: arm: qcom: Document SDX65 platform and boards"

Steev Klimaszewski (1):
      arm64: dts: qcom: c630: disable crypto due to serror

Stefano Garzarella (2):
      vhost: remove avail_event arg from vhost_update_avail_event()
      tools/virtio: fix virtio_test execution

Steffen Klassert (3):
      esp: Fix possible buffer overflow in ESP transformation
      esp: Fix BEET mode inter address family tunneling on GSO
      net: Fix esp GSO on inter address family tunnels.

Taniya Das (2):
      clk: qcom: gdsc: Add support to update GDSC transition delay
      clk: qcom: dispcc: Update the transition delay for MDSS GDSC

Thierry Reding (1):
      ARM: tegra: Move Nyan FHD panels to AUX bus

Thomas Zimmermann (1):
      drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP

Tom Rix (1):
      qed: return status of qed_iov_get_link

Tung Nguyen (2):
      tipc: fix kernel panic when enabling bearer
      tipc: fix incorrect order of state message data sanity check

Ulf Hansson (1):
      mmc: core: Restore (almost) the busy polling for MMC_SEND_OP_COND

Vladimir Oltean (1):
      net: dsa: unlock the rtnl_mutex when dsa_master_setup() fails

Weiguo Li (2):
      perf parse-events: Fix NULL check against wrong variable
      perf bench: Fix NULL check against wrong variable

Xie Yongji (3):
      vduse: Fix returning wrong type in vduse_domain_alloc_iova()
      virtio-blk: Don't use MAX_DISCARD_SEGMENTS if max_discard_seg is zero
      virtio-blk: Remove BUG_ON() in virtio_queue_rq()

Zhang Min (1):
      vdpa: fix use-after-free on vp_vdpa_remove

Zhengjun Xing (1):
      perf parse: Fix event parser error for hybrid systems

Zheyu Ma (1):
      ethernet: sun: Free the coherent when failing in probing

Build regressions/improvements in v5.17-rc8

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v5.17-rc8[1] compared to v5.16[2].

Summarized:
  - build errors: +8/-3
  - build warnings: +23/-27

JFYI, when comparing v5.17-rc8[1] to v5.17-rc7[3], the summaries are:
  - build errors: +0/-9
  - build warnings: +0/-3

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/09688c0166e76ce2fb85e86b9d99be8b0084cdf9/ (96 out of 100 configs)
[2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/df0cc57e057f18e44dac8e6c18aba47ab53202f9/ (98 out of 100 configs)
[3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/ffb217a13a2eaf6d5bd974fc83036a53ca69f1e2/ (all 100 configs)


*** ERRORS ***

8 error regressions:
  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(long unsigned int)' to 'void (*)(long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int)' [-Werror=cast-function-type]:  => 1639:13, 1756:13
  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *)' to 'void (*)(long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int)' [-Werror=cast-function-type]:  => 1674:29, 1662:29
  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *, long unsigned int)' to 'void (*)(long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int)' [-Werror=cast-function-type]:  => 1767:21
  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int)' to 'void (*)(long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int)' [-Werror=cast-function-type]:  => 1726:29, 1741:29
  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int,  long unsigned int)' to 'void (*)(long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int,  long unsigned int)' [-Werror=cast-function-type]:  => 1711:29, 1694:29
  + /kisskb/src/arch/um/include/asm/processor-generic.h: error: called object is not a function or function pointer:  => 103:18
  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: error: control reaches end of non-void function [-Werror=return-type]:  => 1560:1
  + error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `system_reset_common' defined in .text section in arch/powerpc/kernel/head_64.o:  => (.text+0x3ec)

3 error improvements:
  - /kisskb/src/crypto/blake2b_generic.c: error: the frame size of 2288 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: 109:1 => 
  - /kisskb/src/drivers/mtd/nand/raw/mpc5121_nfc.c: error: unused variable 'mtd' [-Werror=unused-variable]: 294:19 => 
  - /kisskb/src/drivers/video/fbdev/riva/fbdev.c: error: passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type [-Werror=discarded-qualifiers]: 2095:11, 2062:11 => 


*** WARNINGS ***

23 warning regressions:
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14410): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14428): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14440): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14458): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14470): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14488): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144a0): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144f0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14508): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14520): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14538): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14550): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14568): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14580): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14598): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4790): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47a8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47c0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47d8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47f0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4808): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000:  => N/A
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4820): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000:  => N/A
  + modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x4530): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names:  => N/A

27 warning improvements:
  - arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for MCTP: 322 => 
  - arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for MCTP: 295 => 
  - modpost: WARNING: modpost: EXPORT symbol "clear_page" [vmlinux] version ...: N/A => 
  - modpost: WARNING: modpost: EXPORT symbol "copy_page" [vmlinux] version ...: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x136d0): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x136e8): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13700): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13718): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13730): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13748): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13760): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137b0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137c8): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137e0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x137f8): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13810): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13828): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13840): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x13858): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4610): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4628): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4640): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4658): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4670): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4688): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => 
  - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x46a0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => 
  - modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x45e4): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: N/A => 

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux 5.17-rc8

[Guenter Roeck]

On Sun, Mar 13, 2022 at 01:43:59PM -0700, Linus Torvalds wrote:
> So last weekend, I thought I'd be releasing the final 5.17 today.
> 
[ ... ]

> Anyway, let's not keep the testing _just_ to automation - the more the
> merrier, and real-life loads are always more interesting than what the
> automation farms do. So please do give this last rc a quick try,
> 

Build results:
	total: 155 pass: 155 fail: 0
Qemu test results:
	total: 488 pass: 484 fail: 4
Failed tests:
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:mem128:net,default:imx25-pdk:initrd
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:sd:mem128:net,default:imx25-pdk:rootfs
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb0:mem128:net,default:imx25-pdk:rootfs
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb1:mem128:net,default:imx25-pdk:rootfs

This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
regression in sysfs-gpio (gpiolib.c)"). The network connection fails
in the affected tests. Reverting the offending commit (ie reverting the
revert) fixes the problem.

Guenter


---
# bad: [09688c0166e76ce2fb85e86b9d99be8b0084cdf9] Linux 5.17-rc8
# good: [ea4424be16887a37735d6550cfd0611528dbe5d9] Merge tag 'mtd/fixes-for-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
git bisect start 'HEAD' 'ea4424be1688'
# bad: [55b4083b44361d833c93216a619d3b4e6d03a0c9] Merge tag 'soc-fixes-5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect bad 55b4083b44361d833c93216a619d3b4e6d03a0c9
# good: [36168e387fa7d0f1fe0cd5cf76c8cea7aee714fa] ARM: Do not use NOCROSSREFS directive with ld.lld
git bisect good 36168e387fa7d0f1fe0cd5cf76c8cea7aee714fa
# bad: [1db333d9a51f3459fba1bcaa564d95befe79f0b3] Merge tag 'spi-fix-v5.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
git bisect bad 1db333d9a51f3459fba1bcaa564d95befe79f0b3
# good: [b5521fe9a9336caa1caa2db126f1d3ba1bc8303e] Merge tag 'xsa396-5.17-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
git bisect good b5521fe9a9336caa1caa2db126f1d3ba1bc8303e
# bad: [55d01c98a88b346e217eaa931b32e7baea905c9a] gpio: sim: fix a typo
git bisect bad 55d01c98a88b346e217eaa931b32e7baea905c9a
# bad: [660c619b9d7ccd28648ee3766cdbe94ec7b27402] gpiolib: acpi: Convert ACPI value of debounce to microseconds
git bisect bad 660c619b9d7ccd28648ee3766cdbe94ec7b27402
# bad: [fc328a7d1fcce263db0b046917a66f3aa6e68719] gpio: Revert regression in sysfs-gpio (gpiolib.c)
git bisect bad fc328a7d1fcce263db0b046917a66f3aa6e68719
# good: [5f84e73f9a8f14b95115b0eb2080da6d9fa7a82e] gpio: tegra186: Add IRQ per bank for Tegra241
git bisect good 5f84e73f9a8f14b95115b0eb2080da6d9fa7a82e
# first bad commit: [fc328a7d1fcce263db0b046917a66f3aa6e68719] gpio: Revert regression in sysfs-gpio (gpiolib.c)

Re: Linux 5.17-rc8

[Linus Torvalds]

[ Adding more people to the cc, since this last change was triggered
by earlier changes.

On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Build results:
>         total: 155 pass: 155 fail: 0
> Qemu test results:
>         total: 488 pass: 484 fail: 4

Uhhuh. We got all the previous problems sorted out, but a new one instead.

> This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
> regression in sysfs-gpio (gpiolib.c)"). The network connection fails
> in the affected tests. Reverting the offending commit (ie reverting the
> revert) fixes the problem.

Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
somewhat suspicious.

It claims to "revert" things, but the behavior it reverts goes
basically all the way back to v5.7 (with one of the patches going into
5.10).

And it clearly breaks things that used to work much more recently (ie
this worked in rc7, but it was also the state in every release since
5.10).

So unless somebody can find the _real_ issue here, I suspect very
strongly that that "fix" that came in last week was just wrong.

It is also very non-specific "Some GPIO lines have stopped working"
with no pointer to actual reports.

LinusW? Thierry? Bartoz? Anybody?

Yes, there;s something bad going on here, but we can't randomly "fix"
things in an rc8 that have worked for several releases by now.

               Linus

Re: Linux 5.17-rc8

[Marcelo Roberto Jimenez]

Hi Linus,

I am the author of the "gpio: Revert regression..." patch.

On Mon, Mar 14, 2022 at 5:14 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> [ Adding more people to the cc, since this last change was triggered
> by earlier changes.
>
> On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Build results:
> >         total: 155 pass: 155 fail: 0
> > Qemu test results:
> >         total: 488 pass: 484 fail: 4
>
> Uhhuh. We got all the previous problems sorted out, but a new one instead.
>
> > This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
> > regression in sysfs-gpio (gpiolib.c)"). The network connection fails
> > in the affected tests. Reverting the offending commit (ie reverting the
> > revert) fixes the problem.
>
> Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
> somewhat suspicious.
>
> It claims to "revert" things, but the behavior it reverts goes
> basically all the way back to v5.7 (with one of the patches going into
> 5.10).
>
> And it clearly breaks things that used to work much more recently (ie
> this worked in rc7, but it was also the state in every release since
> 5.10).
>
> So unless somebody can find the _real_ issue here, I suspect very
> strongly that that "fix" that came in last week was just wrong.
>
> It is also very non-specific "Some GPIO lines have stopped working"
> with no pointer to actual reports.

The original message in which I posted the patch also had a small
report. I listed the board in which the problem appeared and a small
test script to show the error, which I have used to bisect the issue.

The whole thread is here, the test is in the first message:
https://lore.kernel.org/all/a7fbb773-eb85-ccc7-8bfb-0bfab062ffe1@leemhuis.info/t/

> LinusW? Thierry? Bartoz? Anybody?
>
> Yes, there;s something bad going on here, but we can't randomly "fix"
> things in an rc8 that have worked for several releases by now.

The original patch just reverted the patch that introduced the problem
I found. But if the reversion introduces problems at this point, then
the sane thing to do is to revert the reversion.

At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
property in a way similar to another patch, but the kernel went into
an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
in the sequence.

Following Linus Walleij's suggestion, we are moving the code from the
sysfs interface to the character device. But in the meantime, we are
using this "revert patch" in a 5.10.80 kernel, so maybe someone could
point me to details of the network misbehaviour so that I can also
check it?

>
>                Linus

Regards,
Marcelo.

Re: Linux 5.17-rc8

[Guenter Roeck]

On 3/14/22 17:45, Marcelo Roberto Jimenez wrote:
> Hi Linus,
> 
> I am the author of the "gpio: Revert regression..." patch.
> 
> On Mon, Mar 14, 2022 at 5:14 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> [ Adding more people to the cc, since this last change was triggered
>> by earlier changes.
>>
>> On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>
>>> Build results:
>>>          total: 155 pass: 155 fail: 0
>>> Qemu test results:
>>>          total: 488 pass: 484 fail: 4
>>
>> Uhhuh. We got all the previous problems sorted out, but a new one instead.
>>
>>> This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
>>> regression in sysfs-gpio (gpiolib.c)"). The network connection fails
>>> in the affected tests. Reverting the offending commit (ie reverting the
>>> revert) fixes the problem.
>>
>> Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
>> somewhat suspicious.
>>
>> It claims to "revert" things, but the behavior it reverts goes
>> basically all the way back to v5.7 (with one of the patches going into
>> 5.10).
>>
>> And it clearly breaks things that used to work much more recently (ie
>> this worked in rc7, but it was also the state in every release since
>> 5.10).
>>
>> So unless somebody can find the _real_ issue here, I suspect very
>> strongly that that "fix" that came in last week was just wrong.
>>
>> It is also very non-specific "Some GPIO lines have stopped working"
>> with no pointer to actual reports.
> 
> The original message in which I posted the patch also had a small
> report. I listed the board in which the problem appeared and a small
> test script to show the error, which I have used to bisect the issue.
> 
> The whole thread is here, the test is in the first message:
> https://lore.kernel.org/all/a7fbb773-eb85-ccc7-8bfb-0bfab062ffe1@leemhuis.info/t/
> 
>> LinusW? Thierry? Bartoz? Anybody?
>>
>> Yes, there;s something bad going on here, but we can't randomly "fix"
>> things in an rc8 that have worked for several releases by now.
> 
> The original patch just reverted the patch that introduced the problem
> I found. But if the reversion introduces problems at this point, then
> the sane thing to do is to revert the reversion.
> 
> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> property in a way similar to another patch, but the kernel went into
> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> in the sequence.
> 
> Following Linus Walleij's suggestion, we are moving the code from the
> sysfs interface to the character device. But in the meantime, we are
> using this "revert patch" in a 5.10.80 kernel, so maybe someone could
> point me to details of the network misbehaviour so that I can also
> check it?
> 

See https://kerneltests.org/builders/qemu-arm-master/builds/2030/steps/qemubuildcommand/logs/stdio
for logs.

There are two problem with your patch:
- The Ethernet interface on imx25's qemu emulation does not come online.
- The mmc does not come online (I just noticed this one)

Looking into the devicetree file, my guess is that the gpio
lines attached to the Ethernet PHY and the sdhci controller
don't report pin status changes. I did not try to confirm this,
though.

Your patch may work for you on top of v5.10.y, but it doesn't
work there for imx25 either.

Guenter

Re: Linux 5.17-rc8

[Linus Torvalds]

On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
<marcelo.jimenez@gmail.com> wrote:
>
> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> property in a way similar to another patch, but the kernel went into
> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> in the sequence.

Hmm. The problem does sound like that particular driver doesn't use
the pin_ranges thing, so then the tests for an empty pin_ranges will
always be true.

The EPROBE_DEFER deadlock then sounds like something went wrong in the
gpio-ranges patch when you tried to fix it - but I don't actually find
that patch or that attempt, so I can't even guess at it.

This whole code pin_ranges code looks very odd:
gpiochip_add_pin{group}_range() seems to add the pin ranges properly,
but that actual gpiochip_add_pin_ranges() function does *not*.

It just expects that that the 'add_pin_ranges()' callback exists, and
if it doesn't, does nothing at all.

Which then makes those

        if (list_empty(&gc->gpiodev->pin_ranges))
                return 0;

tests very suspicious - because if some doesn't implement that
add_pin_ranges() callback, it looks like nothing at all ever gets
done, because nothing calls the function to actually add the pinrange.
And then that "list_empty()" test very much will trigger.

IOW, it looks like either a gpio controller has to implement that
'add_pin_ranges()' function (only tegra), or it needs to always add
the pin ranges at probe time.

Am I guessing right that the driver that you use does neither?

LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
misreading the situation entirely. Should there be some sanity-test
that any gpio/pinctrl driver that uses gpiochip_generic_request()
would either have to have that add_pin_ranges() callback, or a
successful probe needs to always populate that 'gpiodev->pin_ranges'
list?

Or maybe I'm misreading the situation entirely. I don't know the code
- I'm just grepping for things and trying to make sense of how that
'->pin_ranges' list is supposed to work.

But for now, I think that patch has to be reverted.

               Linus

Re: Linux 5.17-rc8

[Thorsten Leemhuis]

[CCing regressions list and Michael Walle]

FWIW, I was a bit surprised to see this, I had assumed the revert that
causing trouble (fc328a7d1fcc) would go in the next merge window. Seems
my regression tracking work did more harm then good here. :-/ Whatever:

On 15.03.22 02:47, Linus Torvalds wrote:
> On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
> <marcelo.jimenez@gmail.com> wrote:
>>
>> At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
>> property in a way similar to another patch, but the kernel went into
>> an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
>> in the sequence.
> 
> Hmm. The problem does sound like that particular driver doesn't use
> the pin_ranges thing, so then the tests for an empty pin_ranges will
> always be true.
>
> [...]
>
> IOW, it looks like either a gpio controller has to implement that
> 'add_pin_ranges()' function (only tegra), or it needs to always add
> the pin ranges at probe time.
> 
> Am I guessing right that the driver that you use does neither?
> 
> LinusW/Bartoz - this all really sounds strange to me. Maybe I'm
> misreading the situation entirely. Should there be some sanity-test
> that any gpio/pinctrl driver that uses gpiochip_generic_request()
> would either have to have that add_pin_ranges() callback, or a
> successful probe needs to always populate that 'gpiodev->pin_ranges'
> list?
> 
> Or maybe I'm misreading the situation entirely. I don't know the code
> - I'm just grepping for things and trying to make sense of how that
> '->pin_ranges' list is supposed to work.
> 
> But for now, I think that patch has to be reverted.

There is a another reason to do so: Michael Walle reported that the
revert is causing a regression for him:
https://lore.kernel.org/stable/20220314155509.552218-1-michael@walle.cc/

To quote:

```
> This breaks the pinctrl-microchip-sgpio driver as far as I can see.
> 
> I tried to debug it and this is what I have discovered so far:
>  (1) the sgpio driver will use the gpio_stub_drv for its child nodes.
>      Looks like a workaround, see [1].
>  (2) these will have an empty gpio range
>  (3) with the changes of this patch, pinctrl_gpio_request() will now
>      be called and will fail with -EPROBE_DEFER.
> 
> I'm not exactly sure what to do here. Saravana Kannan once suggested
> to use devm_of_platform_populate() to probe the child nodes [2]. But
> I haven't found any other driver doing that.
> 
> Also, I'm not sure if there are any other other driver which get
> broken by this. I.e. ones falling into the gpio_stub_drv category.
> 
> [1] https://lore.kernel.org/lkml/20210122193600.1415639-1-saravanak@google.com/
> [2] https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com/
> 
> -michael
> 
> NB. this patch doesn't contain a Fixes tag. Was this on purpose?
```

Ciao, Thorsten

Re: Linux 5.17-rc8

[Geert Uytterhoeven]

On Tue, Mar 15, 2022 at 9:43 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> [ Adding more people to the cc, since this last change was triggered
> by earlier changes.
>
> On Mon, Mar 14, 2022 at 12:25 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Build results:
> >         total: 155 pass: 155 fail: 0
> > Qemu test results:
> >         total: 488 pass: 484 fail: 4
>
> Uhhuh. We got all the previous problems sorted out, but a new one instead.
>
> > This is a new problem. It bisects to commit fc328a7d1fcc ("gpio: Revert
> > regression in sysfs-gpio (gpiolib.c)"). The network connection fails
> > in the affected tests. Reverting the offending commit (ie reverting the
> > revert) fixes the problem.
>
> Hmm. Looking at the changes since 5.16, that commit fc328a7d1fcc looks
> somewhat suspicious.
>
> It claims to "revert" things, but the behavior it reverts goes
> basically all the way back to v5.7 (with one of the patches going into
> 5.10).
>
> And it clearly breaks things that used to work much more recently (ie
> this worked in rc7, but it was also the state in every release since
> 5.10).
>
> So unless somebody can find the _real_ issue here, I suspect very
> strongly that that "fix" that came in last week was just wrong.
>
> It is also very non-specific "Some GPIO lines have stopped working"
> with no pointer to actual reports.
>
> LinusW? Thierry? Bartoz? Anybody?
>
> Yes, there;s something bad going on here, but we can't randomly "fix"
> things in an rc8 that have worked for several releases by now.

People really need to learn[1] to add proper Link tags to each and every
commit:
https://lore.kernel.org/all/20211217153555.9413-1-marcelo.jimenez@gmail.com
The last mail in that thread is a regression report for the fix.
Note that this "fix" has only been in next-20220308 and later, so
more breakage may show up soon...

[1] https://www.kernel.org/doc/html/v5.6/maintainer/configure-git.html#creating-commit-links-to-lore-kernel-org

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Linux 5.17-rc8

[Bartosz Golaszewski]

On Tue, Mar 15, 2022 at 2:47 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Mar 14, 2022 at 5:45 PM Marcelo Roberto Jimenez
> <marcelo.jimenez@gmail.com> wrote:
> >
> > At a certain point, I tried Thorsten's suggestion to add a gpio-ranges
> > property in a way similar to another patch, but the kernel went into
> > an EPROBE_DEFER deadlock. Thierry Reding made some comments about this
> > in the sequence.
>
> Hmm. The problem does sound like that particular driver doesn't use
> the pin_ranges thing, so then the tests for an empty pin_ranges will
> always be true.
>
> The EPROBE_DEFER deadlock then sounds like something went wrong in the
> gpio-ranges patch when you tried to fix it - but I don't actually find
> that patch or that attempt, so I can't even guess at it.
>
> This whole code pin_ranges code looks very odd:
> gpiochip_add_pin{group}_range() seems to add the pin ranges properly,
> but that actual gpiochip_add_pin_ranges() function does *not*.
>
> It just expects that that the 'add_pin_ranges()' callback exists, and
> if it doesn't, does nothing at all.
>
> Which then makes those
>
>         if (list_empty(&gc->gpiodev->pin_ranges))
>                 return 0;
>
> tests very suspicious - because if some doesn't implement that
> add_pin_ranges() callback, it looks like nothing at all ever gets
> done, because nothing calls the function to actually add the pinrange.
> And then that "list_empty()" test very much will trigger.
>
> IOW, it looks like either a gpio controller has to implement that
> 'add_pin_ranges()' function (only tegra), or it needs to always add
> the pin ranges at probe time.
>
> Am I guessing right that the driver that you use does neither?
>

There are more drivers than just tegra that implement add_pin_ranges()
but you're right, pinctrl-at91.c used by Marcelo does not.

> LinusW/Bartoz - this all really sounds strange to me. Maybe I'm

It's BartoSz actually. :)

> misreading the situation entirely. Should there be some sanity-test
> that any gpio/pinctrl driver that uses gpiochip_generic_request()
> would either have to have that add_pin_ranges() callback, or a
> successful probe needs to always populate that 'gpiodev->pin_ranges'
> list?
>

This sounds right to me but I need to spend some more time on this, I
didn't author the code in question.

> Or maybe I'm misreading the situation entirely. I don't know the code
> - I'm just grepping for things and trying to make sense of how that
> '->pin_ranges' list is supposed to work.
>
> But for now, I think that patch has to be reverted.
>

Sounds good, I'll send a revert and make another PR with fixes before v5.17.

Bartosz

>                Linus