Linux 5.19-rc6

Linux 5.19-rc6

[Linus Torvalds]

Things looking fairly normal for rc6, nothing here really stands out.
A number of small fixes all over, with the bulk being a collection of
sound and network driver fixes, along with some arm64 dts file
updates.

The rest is some selftest updates, and various (mostly) one-liners all
over the place. The shortlog below gives a good overview, and is short
enough to just scroll through to get a flavor of it all.

Perhaps somewhat unusually, I picked up a few fixes that were pending
in trees that haven't actually hit upstream yet.  It's already rc6,
and I wanted to close out a few of the regression reports and not have
to wait for another (possibly last, knock wood) rc to have them in the
tree.

             Linus

---

Alexei Starovoitov (1):
      bpf, docs: Better scale maintenance of BPF subsystem

Alison Schofield (1):
      cxl/mbox: Use __le32 in get,set_lsa mailbox structures

Amadeusz Sławiński (2):
      ASoC: Intel: avs: Fix parsing UUIDs in topology
      ASoC: Remove unused hw_write_t type

Andrei Lalaev (1):
      pinctrl: sunxi: sunxi_pconf_set: use correct offset

Andy Shevchenko (1):
      MAINTAINERS: Update Intel pin control to Supported

Ben Widawsky (2):
      MAINTAINERS: Update Ben's email address
      cxl/core: Use is_endpoint_decoder

Bill Wendling (1):
      soc: qcom: smem: use correct format characters

Bo Liu (1):
      firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API

Borislav Petkov (1):
      x86/boot: Fix the setup data types max limit

Caleb Connolly (1):
      dmaengine: qcom: bam_dma: fix runtime PM underflow

Charles Keepax (8):
      ASoC: wm_adsp: Fix event for preloader
      ASoC: wm5110: Fix DRE control
      ASoC: cs35l41: Correct some control names
      ASoC: dapm: Initialise kcontrol data for mux/demux controls
      ASoC: cs35l41: Add ASP TX3/4 source to register patch
      ASoC: cs47l15: Fix event generation for low power mux control
      ASoC: madera: Fix event generation for OUT1 demux
      ASoC: madera: Fix event generation for rate controls

Christian Marangi (1):
      PM / devfreq: exynos-bus: Fix NULL pointer dereference

Christophe JAILLET (1):
      dmaengine: lgm: Fix an error handling path in intel_ldma_probe()

Claudiu Beznea (3):
      ARM: at91: pm: use proper compatible for sama5d2's rtc
      ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
      ARM: at91: pm: use proper compatibles for sama7g5's rtc and rtt

Cristian Marussi (1):
      firmware: arm_scmi: Relax CLOCK_DESCRIBE_RATES out-of-spec checks

Dan Carpenter (1):
      ASoC: SOF: mediatek: Fix error code in probe

Dan Williams (1):
      memregion: Fix memregion_free() fallback definition

Daniel Borkmann (4):
      bpf: Fix incorrect verifier simulation around jmp32's jeq/jne
      bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals
      bpf, selftests: Add verifier test case for imm=0,umin=0,umax=1 scalar
      bpf, selftests: Add verifier test case for jmp32's jeq/jne

Dave Jiang (1):
      dmaengine: idxd: force wq context cleanup on device disable path

David Howells (1):
      fscache: Fix invalidation/lookup race

Davidlohr Bueso (1):
      staging/wlan-ng: get the correct struct hfa384x in work callback

Dmitry Baryshkov (2):
      arm64: dts: qcom: sm8450 add ITS device tree node
      arm64: dts: qcom: sdm845: use dispcc AHB clock for mdss node

Dmitry Osipenko (1):
      dmaengine: pl330: Fix lockdep warning about non-static key

Duoming Zhou (1):
      net: rose: fix UAF bug caused by rose_t0timer_expiry

Duy Nguyen (1):
      can: rcar_canfd: Fix data transmission failed on R-Car V3U

Egor Vorontsov (2):
      ALSA: usb-audio: Add quirk for Fiero SC-01
      ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)

Emil Renner Berthing (1):
      dmaengine: dw-axi-dmac: Fix RMW on channel suspend register

Etienne Carriere (1):
      ARM: dts: stm32: fix pwr regulators references to use scmi

Eugen Hristev (2):
      ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
      ARM: dts: at91: sama5d2_icp: fix eeprom compatibles

Fabien Dessenne (1):
      pinctrl: stm32: fix optional IRQ support to gpios

Fabio Estevam (3):
      ARM: dts: imx7d-smegw01: Fix the SDIO description
      ARM: mxs_defconfig: Enable the framebuffer
      ARM: at91: pm: Mark at91_pm_secure_init as __init

Fabrice Gasnier (1):
      ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15

Gabriel Fernandez (3):
      ARM: dts: stm32: use the correct clock source for CEC on stm32mp151
      ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board
      ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI

Gal Pressman (1):
      Revert "tls: rx: move counting TlsDecryptErrors for sync"

Geert Uytterhoeven (1):
      eeprom: at25: Rework buggy read splitting

Geliang Tang (1):
      mptcp: update MIB_RMSUBFLOW in cmd_sf_destroy

Guiling Deng (1):
      fbdev: fbmem: Fix logo center image dx issue

Hangbin Liu (1):
      selftests/net: fix section name when using xdp_dummy.o

Hans de Goede (1):
      ASoC: Intel: bytcr_wm5102: Fix GPIO related probe-ordering problem

Haowen Bai (1):
      pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux()

Heiner Kallweit (1):
      r8169: fix accessing unset transport header

Helge Deller (4):
      fbcon: Disallow setting font bigger than screen size
      fbcon: Prevent that screen size is smaller than font size
      fbmem: Check virtual screen sizes in fb_set_var()
      fbcon: Use fbcon_info_from_console() in fbcon_modechange_possible()

Hsin-Yi Wang (1):
      video: of_display_timing.h: include errno.h

Huacai Chen (1):
      LoongArch: Fix build errors for tinyconfig

Ivan Malov (1):
      xsk: Clear page contiguity bit when unmapping pool

Jacky Bai (1):
      pinctrl: imx: Add the zero base flag for imx93

Jakub Kicinski (3):
      docs: netdev: document that patch series length limit
      docs: netdev: document reverse xmas tree
      docs: netdev: add a cheat sheet for the rules

Jamie Iles (1):
      irqchip/xilinx: Add explicit dependency on OF_ADDRESS

Jan Beulich (1):
      xen-netfront: restore __skb_queue_tail() positioning in
xennet_get_responses()

Jason A. Donenfeld (6):
      powerpc/powernv: delay rng platform device creation until later in boot
      wireguard: selftests: set fake real time in init
      wireguard: selftests: use virt machine on m68k
      wireguard: selftests: always call kernel makefile
      wireguard: selftests: use microvm on x86
      crypto: s390 - do not depend on CRYPTO_HW for SIMD implementations

Jean Delvare (1):
      i2c: piix4: Fix a memory leak in the EFCH MMIO support

Jens Axboe (1):
      io_uring: check that we have a file table when allocating update slots

Jerry Snitselaar (1):
      dmaengine: idxd: Only call idxd_enable_system_pasid() if
succeeded in enabling SVA feature

Jia Zhu (1):
      cachefiles: narrow the scope of flushed requests when releasing fd

Jimmy Assarsson (3):
      can: kvaser_usb: replace run-time checks with struct
kvaser_usb_driver_info
      can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression
      can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits

Joerg Roedel (1):
      MAINTAINERS: Remove iommu@lists.linux-foundation.org

John Hubbard (1):
      gen_compile_commands: handle multiple lines per .mod file

John Veness (1):
      ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices

Jonathan Cameron (1):
      cxl: Fix cleanup of port devices on failure to probe driver.

Judy Hsiao (1):
      ASoC: rockchip: i2s: switch BCLK to GPIO

Juergen Gross (3):
      x86/xen: Use clear_bss() for Xen PV guests
      x86: Clear .brk area at early boot
      x86: Fix .brk attribute in linker script

Karsten Graul (1):
      MAINTAINERS: add Wenjia as SMC maintainer

Keith Busch (2):
      nvme-pci: phison e16 has bogus namespace ids
      nvme: use struct group for generic command dwords

Kent Gibson (1):
      gpiolib: cdev: fix null pointer dereference in linereq_free()

Kishen Maloor (2):
      mptcp: netlink: issue MP_PRIO signals from userspace PMs
      selftests: mptcp: userspace PM support for MP_PRIO signals

Konrad Dybcio (2):
      arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
      MAINTAINERS: Add myself as a reviewer for Qualcomm ARM/64 support

Kuninori Morimoto (1):
      ASoC: ak4613: cares Simple-Audio-Card case for TDM

Leon Romanovsky (1):
      gpio: vf610: fix compilation error

Li kunyu (1):
      net: usb: Fix typo in code

Liang He (1):
      can: grcan: grcan_probe(): remove extra of_node_get()

Linus Torvalds (3):
      signal handling: don't use BUG_ON() for debugging
      ida: don't use BUG_ON() for debugging
      Linux 5.19-rc6

Linus Walleij (1):
      soc: ixp4xx/npe: Fix unused match warning

Lu Baolu (1):
      iommu/vt-d: Fix RID2PASID setup/teardown failure

Lukas Bulwahn (1):
      LoongArch: Drop these obsolete selects in Kconfig

Lukasz Cieplicki (1):
      i40e: Fix dropped jumbo frames statistics

Marc Kleine-Budde (5):
      can: m_can: m_can_chip_config(): actually enable internal timestamping
      can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp
to full 32 bits
      can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel()
      can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct
length to read dev_id
      can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversion

Mario Limonciello (2):
      ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
      ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported

Mark Brown (3):
      ASoC: ops: Fix off by one in range control validation
      ASoC: wcd9335: Fix spurious event generation
      ASoC: wcd938x: Fix event generation for some controls

Masahiro Yamada (1):
      kbuild: remove unused cmd_none in scripts/Makefile.modinst

Masami Hiramatsu (Google) (1):
      fprobe, samples: Add module parameter descriptions

Mat Martineau (2):
      mptcp: Avoid acquiring PM lock for subflow priority changes
      mptcp: Acquire the subflow socket lock before modifying MP_PRIO flags

Miaoqian Lin (3):
      dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
      dmaengine: ti: Add missing put_device in ti_dra7_xbar_route_allocate
      ARM: meson: Fix refcount leak in meson_smp_prepare_cpus

Michael Roth (1):
      x86/compressed/64: Add identity mappings for setup_data entries

Michael Walle (2):
      dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() correctly
      net: lan966x: hardcode the number of external ports

Mihai Sain (1):
      ARM: at91: fix soc detection for SAM9X60 SiPs

Norbert Zulinski (1):
      i40e: Fix VF's MAC Address change on VM

Oleksandr Tyshchenko (1):
      xen/arm: Fix race in RB-tree based P2M accounting

Oliver Hartkopp (1):
      can: bcm: use call_rcu() instead of costly synchronize_rcu()

Oliver Neukum (1):
      usbnet: fix memory leak in error case

Pablo Neira Ayuso (2):
      netfilter: nf_tables: stricter validation of element data
      netfilter: nft_set_pipapo: release elements in clone from abort path

Paolo Abeni (2):
      mptcp: fix locking in mptcp_nl_cmd_sf_destroy()
      mptcp: fix local endpoint accounting

Pavel Begunkov (1):
      io_uring: explicit sqe padding for ioctl commands

Peng Fan (14):
      arm64: dts: imx8mp: correct clock of pgc_ispdwp
      arm64: dts: imx8mp-evk: correct mmc pad settings
      arm64: dts: imx8mp-evk: correct gpio-led pad settings
      arm64: dts: imx8mp-evk: correct vbus pad settings
      arm64: dts: imx8mp-evk: correct eqos pad settings
      arm64: dts: imx8mp-evk: correct vbus pad settings
      arm64: dts: imx8mp-evk: correct I2C5 pad settings
      arm64: dts: imx8mp-evk: correct I2C1 pad settings
      arm64: dts: imx8mp-evk: correct I2C3 pad settings
      arm64: dts: imx8mp-venice-gw74xx: correct pad settings
      arm64: dts: imx8mp-phyboard-pollux-rdk: correct uart pad settings
      arm64: dts: imx8mp-phyboard-pollux-rdk: correct eqos pad settings
      arm64: dts: imx8mp-phyboard-pollux-rdk: correct i2c2 & mmc settings
      arm64: dts: imx8mp-icore-mx8mp-edim2.2: correct pad settings

Peter Robinson (1):
      dmaengine: imx-sdma: Allow imx8m for imx7 FW revs

Peter Ujfalusi (5):
      ASoC: SOF: Intel: hda-dsp: Expose hda_dsp_core_power_up()
      ASoC: SOF: Intel: hda-loader: Make sure that the fw load
sequence is followed
      ASoC: SOF: Intel: hda-loader: Clarify the cl_dsp_init() flow
      ASoC: SOF: ipc3-topology: Move and correct size checks in
sof_ipc3_control_load_bytes()
      ASoC: SOF: Intel: hda: Fix compressed stream position tracking

Peter Zijlstra (1):
      x86/ibt, objtool: Don't discard text references from tracepoint section

Pierre-Louis Bossart (11):
      ASoC: Realtek/Maxim SoundWire codecs: disable pm_runtime on remove
      ASoC: rt711-sdca-sdw: fix calibrate mutex initialization
      ASoC: Intel: sof_sdw: handle errors on card registration
      ASoC: rt711: fix calibrate mutex initialization
      ASoC: rt7*-sdw: harden jack_detect_handler
      ASoC: codecs: rt700/rt711/rt711-sdca: initialize workqueues in probe
      ASoC: codecs: rt700/rt711/rt711-sdca: resume bus/codec in .set_jack_detect
      MAINTAINERS: update ASoC/Intel/SOF maintainers
      ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2
      ASoC: SOF: pm: add definitions for S4 and S5 states
      ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4
and S5 states

Qi Hu (1):
      LoongArch: Remove obsolete mentions of vcsr

Rafael J. Wysocki (2):
      PM: runtime: Redefine pm_runtime_release_supplier()
      PM: runtime: Fix supplier device management during consumer probe

Rhett Aultman (1):
      can: gs_usb: gs_usb_open/close(): fix memory leak

Rick Lindsley (1):
      ibmvnic: Properly dispose of all skbs during a failover.

Robin Murphy (1):
      irqchip/gicv3: Handle resource request failure consistently

Roger Pau Monne (4):
      xen/blkfront: fix leaking data in shared pages
      xen/netfront: fix leaking data in shared pages
      xen/netfront: force data bouncing when backend is untrusted
      xen/blkfront: force data bouncing when backend is untrusted

Samuel Holland (2):
      pinctrl: sunxi: a83t: Fix NAND function name for some pins
      dt-bindings: dma: allwinner,sun50i-a64-dma: Fix min/max typo

Sascha Hauer (1):
      dmaengine: imx-sdma: only restart cyclic channel when enabled

Satish Nagireddy (1):
      i2c: cadence: Unregister the clk notifier in error path

Sherry Sun (1):
      arm64: dts: imx8mp-evk: correct the uart2 pinctl value

Shuah Khan (3):
      misc: rtsx_usb: fix use of dma mapped buffer for usb bulk transfer
      misc: rtsx_usb: use separate command and response buffers
      misc: rtsx_usb: set return value in rsp_buf alloc err path

Shuming Fan (1):
      ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error

Srinivas Kandagatla (2):
      ASoC: qdsp6: q6apm-dai: unprepare stream if its already prepared
      MAINTAINERS: update ASoC Qualcomm maintainer email-id

Srinivas Neeli (1):
      Revert "can: xilinx_can: Limit CANFD brp to 2"

Stafford Horne (1):
      irqchip: or1k-pic: Undefine mask_ack for level triggered hardware

Stephan Gerhold (1):
      arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo

Stephen Boyd (1):
      arm64: dts: qcom: Remove duplicate sc7180-trogdor include on
lazor/homestar

Sven Schnelle (1):
      ptrace: fix clearing of JOBCTL_TRACED in ptrace_unfreeze_traced()

Takashi Iwai (2):
      ALSA: usb-audio: Workarounds for Behringer UMC 204/404 HD
      ALSA: cs46xx: Fix missing snd_card_free() call at probe error

Thomas Kopp (2):
      can: mcp251xfd: mcp251xfd_regmap_crc_read(): improve workaround
handling for mcp2517fd
      can: mcp251xfd: mcp251xfd_regmap_crc_read(): update workaround
broken CRC on TBC register

Thomas Zimmermann (1):
      drm/aperture: Run fbdev removal before internal helpers

Tiezhu Yang (1):
      LoongArch: Fix section mismatch warning

Tim Crawford (1):
      ALSA: hda/realtek: Add quirk for Clevo L140PU

Vasyl Vavrychuk (1):
      Bluetooth: core: Fix deadlock on hci_power_on_sync.

Vincent Guittot (1):
      firmware: arm_scmi: Fix response size warning for OPTEE transport

Vinod Koul (1):
      dmaengine: Revert "dmaengine: add verification of DMA_INTERRUPT
capability for dmatest"

Vishal Verma (1):
      cxl/mbox: Fix missing variable payload checks in cmd size validation

Vlad Buslov (2):
      net/sched: act_police: allow 'continue' action offload
      net/mlx5e: Fix matchall police parameters validation

Vladimir Oltean (3):
      selftests: forwarding: fix flood_unicast_test when h2 supports
IFF_UNICAST_FLT
      selftests: forwarding: fix learning_test when h1 supports IFF_UNICAST_FLT
      selftests: forwarding: fix error message in learning_test

Vladimir Zapolskiy (1):
      arm64: dts: qcom: sm8450: fix interconnects property of UFS node

Vladis Dronov (1):
      wireguard: Kconfig: select CRYPTO_CHACHA_S390

Wei Yongjun (1):
      irqchip/apple-aic: Make symbol 'use_fast_ipi' static

Xiang wangx (1):
      openrisc: unwinder: Fix grammar issue in comment

Yassine Oudjana (1):
      ASoC: wcd9335: Remove RX channel from old list before adding it
to a new one

Yian Chen (1):
      iommu/vt-d: Fix PCI bus rescan device hot add

Yue Hu (2):
      fscache: Fix if condition in fscache_wait_on_volume_collision()
      fscache: Introduce fscache_cookie_is_dropped()

Build regressions/improvements in v5.19-rc6

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v5.19-rc6[1] compared to v5.18[2].

Summarized:
  - build errors: +8/-10
  - build warnings: +11/-10

JFYI, when comparing v5.19-rc6[1] to v5.19-rc5[3], the summaries are:
  - build errors: +0/-0
  - build warnings: +0/-0

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/32346491ddf24599decca06190ebca03ff9de7f8/ (all 135 configs)
[2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/4b0986a3613c92f4ec1bdc7f60ec66fea135991f/ (131 out of 135 configs)
[3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/88084a3df1672e131ddc1b4e39eeacfd39864acf/ (all 135 configs)


*** ERRORS ***

8 error regressions:
  + /kisskb/src/arch/um/include/asm/page.h: error: too few arguments to function 'to_phys':  => 105:20
  + /kisskb/src/drivers/mfd/asic3.c: error: unused variable 'asic' [-Werror=unused-variable]:  => 941:23
  + /kisskb/src/drivers/nvdimm/pmem.c: error: conflicting types for 'to_phys':  => 48:20
  + /kisskb/src/drivers/nvdimm/pmem.c: error: control reaches end of non-void function [-Werror=return-type]:  => 324:1
  + /kisskb/src/drivers/tty/serial/sh-sci.c: error: unused variable 'sport' [-Werror=unused-variable]:  => 2655:26
  + /kisskb/src/include/ufs/ufshci.h: error: initializer element is not constant:  => 245:36
  + error: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text':  => (.head.text+0x5040), (.head.text+0x5100)
  + error: relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section in arch/sparc/kernel/trampoline_32.o:  => (.init.text+0xa4)

10 error improvements:
  - /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): 149:37 => 
  - /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': 149:22 => 
  - /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: 150:1 => 
  - /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': 88:22 => 
  - /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: 89:1 => 
  - /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: 100:2 => 
  - /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: 4917:4 => 
  - /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: 1983:2 => 
  - error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text': (.head.text+0x5100), (.head.text+0x5040) => 
  - error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section in arch/sparc/kernel/trampoline_32.o: (.init.text+0xa4) => 


*** WARNINGS ***

11 warning regressions:
  + .config: warning: override: ARCH_RV32I changes choice state:  => 3864
  + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for ZPOOL:  => 61
  + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for ZPOOL:  => 37
  + modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47b0): 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+0x47c8): 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+0x47e0): 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+0x47f8): 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+0x4810): 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+0x4828): 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+0x4840): 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+0x52bc): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names:  => N/A

10 warning improvements:
  - .config: warning: override: reassigning to symbol GCC_PLUGIN_RANDSTRUCT: 12253, 12475 => 
  - /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: 5396:40, 5400:40, 5403:43 => 
  - 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+0x45d4): 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.19-rc6

[Guenter Roeck]

On Sun, Jul 10, 2022 at 02:54:10PM -0700, Linus Torvalds wrote:
> Things looking fairly normal for rc6, nothing here really stands out.
> A number of small fixes all over, with the bulk being a collection of
> sound and network driver fixes, along with some arm64 dts file
> updates.
> 
> The rest is some selftest updates, and various (mostly) one-liners all
> over the place. The shortlog below gives a good overview, and is short
> enough to just scroll through to get a flavor of it all.
> 
> Perhaps somewhat unusually, I picked up a few fixes that were pending
> in trees that haven't actually hit upstream yet.  It's already rc6,
> and I wanted to close out a few of the regression reports and not have
> to wait for another (possibly last, knock wood) rc to have them in the
> tree.
> 

Build results:
	total: 150 pass: 149 fail: 1
Failed builds:
	powerpc:allmodconfig
Qemu test results:
	total: 489 pass: 489 fail: 0

Same problems as every week.

Building powerpc:allmodconfig ... failed
--------------
Error log:
powerpc64-linux-ld: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard float, drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o uses soft float
powerpc64-linux-ld: failed to merge target specific data of file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
powerpc64-linux-ld: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard float, drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o uses soft float
powerpc64-linux-ld: failed to merge target specific data of file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
powerpc64-linux-ld: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard float, drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o uses soft float
powerpc64-linux-ld: failed to merge target specific data of file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o

My attempt to fix the problem was rejected, but I don't see an alternate
solution either (or at least I was not copied on it, and the problem still
persists in linux-next).

plus

OF: amba_device_add() failed (-19) for /amba/smc@10100000
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at lib/refcount.c:28 of_platform_bus_create+0x33c/0x3dc
refcount_t: underflow; use-after-free.

I won't report again unless there are new problems or any of the known
issues are fixed.

Guenter

Re: Linux 5.19-rc6

[Linus Torvalds]

On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Same problems as every week.
>
> Building powerpc:allmodconfig ... failed

Ok, this has been going on since -rc1, which is much too long.

From your patch submission that that was rejected:

> The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> 64-bit outline-only KASAN support") which adds support for KASAN. This
> commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> compiled which lack the selection of hard-float.

And considering that neither the ppc people nor the drm people seem
interested in fixing this, and it doesn't revert cleanly I think the
sane solution seems to be to just remove PPC64 support for DRM_AMD_DC
entirely.

IOW, does something like this (obviously nor a proper patch, but you
get the idea) fix the ppc build for you?

  @@ -6,7 +6,7 @@ config DRM_AMD_DC
          bool "AMD DC - Enable new display engine"
          default y
          select SND_HDA_COMPONENT if SND_HDA_CORE
  -       select DRM_AMD_DC_DCN if (X86 || PPC64) &&
!(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
  +       select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL &&
KCOV_ENABLE_COMPARISONS)
          help
            Choose this option if you want to use the new display engine
            support for AMDGPU. This adds required support for Vega and

> OF: amba_device_add() failed (-19) for /amba/smc@10100000
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at lib/refcount.c:28 of_platform_bus_create+0x33c/0x3dc
> refcount_t: underflow; use-after-free.

This too has been going on since -rc1, but it's not obvious what caused it.

At a guess, looking around the amba changes, I'm assuming it's

  7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")

Does reverting that commit make it go away?

                    Linus

Re: Linux 5.19-rc6

[Russell King (Oracle)]

On Wed, Jul 13, 2022 at 12:36:50PM -0700, Linus Torvalds wrote:
> On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > OF: amba_device_add() failed (-19) for /amba/smc@10100000
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 1 at lib/refcount.c:28 of_platform_bus_create+0x33c/0x3dc
> > refcount_t: underflow; use-after-free.
> 
> This too has been going on since -rc1, but it's not obvious what caused it.
> 
> At a guess, looking around the amba changes, I'm assuming it's
> 
>   7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")
> 
> Does reverting that commit make it go away?

There may be a patch that solves that, but it's never been submitted to
my patch system:

https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/

I'm sorry, but I'm utterly crap at picking up patches off mailing lists,
so if stuff doesn't end up inthe patch system, it gets missed.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: Linux 5.19-rc6

[Alex Deucher]

On Wed, Jul 13, 2022 at 3:42 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Same problems as every week.
> >
> > Building powerpc:allmodconfig ... failed
>
> Ok, this has been going on since -rc1, which is much too long.
>
> From your patch submission that that was rejected:
>
> > The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> > 64-bit outline-only KASAN support") which adds support for KASAN. This
> > commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> > KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> > compiled which lack the selection of hard-float.
>
> And considering that neither the ppc people nor the drm people seem
> interested in fixing this, and it doesn't revert cleanly I think the
> sane solution seems to be to just remove PPC64 support for DRM_AMD_DC
> entirely.

Does this patch fix it?
https://patchwork.freedesktop.org/patch/493799/

Alex

>
> IOW, does something like this (obviously nor a proper patch, but you
> get the idea) fix the ppc build for you?
>
>   @@ -6,7 +6,7 @@ config DRM_AMD_DC
>           bool "AMD DC - Enable new display engine"
>           default y
>           select SND_HDA_COMPONENT if SND_HDA_CORE
>   -       select DRM_AMD_DC_DCN if (X86 || PPC64) &&
> !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
>   +       select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL &&
> KCOV_ENABLE_COMPARISONS)
>           help
>             Choose this option if you want to use the new display engine
>             support for AMDGPU. This adds required support for Vega and
>
> > OF: amba_device_add() failed (-19) for /amba/smc@10100000
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 1 at lib/refcount.c:28 of_platform_bus_create+0x33c/0x3dc
> > refcount_t: underflow; use-after-free.
>
> This too has been going on since -rc1, but it's not obvious what caused it.
>
> At a guess, looking around the amba changes, I'm assuming it's
>
>   7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")
>
> Does reverting that commit make it go away?
>
>                     Linus

Re: Linux 5.19-rc6

[Linus Torvalds]

On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> There may be a patch that solves that, but it's never been submitted to
> my patch system:
>
> https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/

That patch looks sane to me, but I guess Guenter would need to check
... Guenter?

             Linus

Re: Linux 5.19-rc6

[Linus Torvalds]

On Wed, Jul 13, 2022 at 12:53 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> Does this patch fix it?
> https://patchwork.freedesktop.org/patch/493799/

Guenter? Willing to check this one too for your setup, and we can
hopefully close down both issues?

                 Linus

Re: Linux 5.19-rc6

[Guenter Roeck]

On 7/13/22 13:21, Linus Torvalds wrote:
> On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
>>
>> There may be a patch that solves that, but it's never been submitted to
>> my patch system:
>>
>> https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> 
> That patch looks sane to me, but I guess Guenter would need to check
> ... Guenter?
> 

That patch is (and has been) in linux-next for a long time,
as commit d2ca1fd2bc70, and with the following tags.

     Fixes: 7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")
     Reported-by: Guenter Roeck <linux@roeck-us.net>
     Tested-by: Guenter Roeck <linux@roeck-us.net>
     Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
     Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

So, yes, it fixes the problem. I don't know where it is pulled from, though.
I thought that it is from Russell's tree, given his Signed-off-by:,
but I never really checked.

Guenter

Re: Linux 5.19-rc6

[Linus Torvalds]

On Wed, Jul 13, 2022 at 1:40 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> That patch is (and has been) in linux-next for a long time,
> as commit d2ca1fd2bc70, and with the following tags.
>
>      Fixes: 7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")
>      Reported-by: Guenter Roeck <linux@roeck-us.net>
>      Tested-by: Guenter Roeck <linux@roeck-us.net>
>      Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>      Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
>
> So, yes, it fixes the problem. I don't know where it is pulled from, though.
> I thought that it is from Russell's tree, given his Signed-off-by:,
> but I never really checked.

Heh. Yeah, with that sign-off, I bet it's in Russell's queue, bit it
just ended up in the "for next release" branch. Russell?

                 Linus

Re: Linux 5.19-rc6

[Guenter Roeck]

On 7/13/22 13:22, Linus Torvalds wrote:
> On Wed, Jul 13, 2022 at 12:53 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>>
>> Does this patch fix it?
>> https://patchwork.freedesktop.org/patch/493799/
> 
> Guenter? Willing to check this one too for your setup, and we can
> hopefully close down both issues?
> 

No, that fixes a different problem (I tried). We (Google) are trying to run
tests with KCOV enabled images on AMD hardware which requires the new display
engine, and we need that patch to enable it. That is unrelated to the PPC
build problem.

Guenter

Re: Linux 5.19-rc6

[Guenter Roeck]

On 7/13/22 12:36, Linus Torvalds wrote:
> On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> Same problems as every week.
>>
>> Building powerpc:allmodconfig ... failed
> 
> Ok, this has been going on since -rc1, which is much too long.
> 
>>From your patch submission that that was rejected:
> 
>> The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
>> 64-bit outline-only KASAN support") which adds support for KASAN. This
>> commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
>> KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
>> compiled which lack the selection of hard-float.
> 
> And considering that neither the ppc people nor the drm people seem
> interested in fixing this, and it doesn't revert cleanly I think the
> sane solution seems to be to just remove PPC64 support for DRM_AMD_DC
> entirely.
> 
> IOW, does something like this (obviously nor a proper patch, but you
> get the idea) fix the ppc build for you?
> 
>    @@ -6,7 +6,7 @@ config DRM_AMD_DC
>            bool "AMD DC - Enable new display engine"
>            default y
>            select SND_HDA_COMPONENT if SND_HDA_CORE
>    -       select DRM_AMD_DC_DCN if (X86 || PPC64) &&
> !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
>    +       select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL &&
> KCOV_ENABLE_COMPARISONS)
>            help
>              Choose this option if you want to use the new display engine
>              support for AMDGPU. This adds required support for Vega and
> 

It does, but I can't imagine that the drm or ppc people would be happy
about it.

Guenter

Re: Linux 5.19-rc6

[Linus Torvalds]

On Wed, Jul 13, 2022 at 1:46 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> It does, but I can't imagine that the drm or ppc people would be happy
> about it.

When something has been reported as not building for five weeks?

I have zero f's to give at that point about their "happiness".

             Linus

Re: Linux 5.19-rc6

[Alex Deucher]

On Wed, Jul 13, 2022 at 4:46 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 7/13/22 12:36, Linus Torvalds wrote:
> > On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> Same problems as every week.
> >>
> >> Building powerpc:allmodconfig ... failed
> >
> > Ok, this has been going on since -rc1, which is much too long.
> >
> >>From your patch submission that that was rejected:
> >
> >> The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> >> 64-bit outline-only KASAN support") which adds support for KASAN. This
> >> commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> >> KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> >> compiled which lack the selection of hard-float.
> >
> > And considering that neither the ppc people nor the drm people seem
> > interested in fixing this, and it doesn't revert cleanly I think the
> > sane solution seems to be to just remove PPC64 support for DRM_AMD_DC
> > entirely.
> >
> > IOW, does something like this (obviously nor a proper patch, but you
> > get the idea) fix the ppc build for you?
> >
> >    @@ -6,7 +6,7 @@ config DRM_AMD_DC
> >            bool "AMD DC - Enable new display engine"
> >            default y
> >            select SND_HDA_COMPONENT if SND_HDA_CORE
> >    -       select DRM_AMD_DC_DCN if (X86 || PPC64) &&
> > !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
> >    +       select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL &&
> > KCOV_ENABLE_COMPARISONS)
> >            help
> >              Choose this option if you want to use the new display engine
> >              support for AMDGPU. This adds required support for Vega and
> >
>
> It does, but I can't imagine that the drm or ppc people would be happy
> about it.

If you want to apply Guenter's patch original patch:
https://patchwork.freedesktop.org/patch/490184/
That's fine with me.  It just kind of slipped off my radar.  We can
dig deeper on a better fix next cycle.
Acked-by: Alex Deucher <alexander.deucher@amd.com>

>
> Guenter

Re: Linux 5.19-rc6

[Linus Torvalds]

On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> If you want to apply Guenter's patch original patch:
> https://patchwork.freedesktop.org/patch/490184/
> That's fine with me.

Honestly, by this time I feel that it's too little, too late.

The ppc people apparently didn't care at all about the fact that this
driver didn't compile.

At least Michael Ellerman and Daniel Axtens were cc'd on that thread
with the proposed fix originally.

I don't see any replies from ppc people as to why it happened, even
though apparently a bog-standard "make allmodconfig" just doesn't
build.

I'd try it myself, since I do have a cross-build environment for some
earlier cross-build verification I did.

But since my upgrade to F36 it now uses gcc-12, and possibly due to
that I get hundreds of errors long before I get to any drm drivers:

  Cannot find symbol for section 19: .text.create_section_mapping.
  arch/powerpc/mm/mem.o: failed
  ...
  Cannot find symbol for section 19: .text.cpu_show_meltdown.
  drivers/base/cpu.o: failed
  Error: External symbol 'memset' referenced from prom_init.c

this cross environment used to work for me, but something changed (I
mention gcc-12, but honestly, that's based on nothing at all, except
for the few problems it caused on x86-64. It could be something
entirely unrelated, but it does look like some bad interaction with
-ffunction-sections).

So considering that the ppc people ignored this whole issue since the
merge window, I think it's entirely unreasonable to then apply a
ppc-specific patch for this at this time, when people literally asked
"why is this needed", and there was no reply from the powerpc side.

Does any of that sound like "we should support this driver on powerpc" to you?

                 Linus

Re: Linux 5.19-rc6

[Sudip Mukherjee]

On Wed, Jul 13, 2022 at 9:42 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > There may be a patch that solves that, but it's never been submitted to
> > my patch system:
> >
> > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
>
> That patch looks sane to me, but I guess Guenter would need to check

I still see the failure in my builds with this patch. But surprisingly
I dont see the build failure (with or without this patch) with gcc-12,
only with gcc-11.


-- 
Regards
Sudip

Re: Linux 5.19-rc6

[Linus Torvalds]

On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
>
> > >
> > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> >
> > That patch looks sane to me, but I guess Guenter would need to check
>
> I still see the failure in my builds with this patch. But surprisingly
> I dont see the build failure (with or without this patch) with gcc-12,
> only with gcc-11.

Arrghs. "build failure"?

So is there another problem than the runtime issue that Guenter reports:

  OF: amba_device_add() failed (-19) for /amba/smc@10100000

in this area? That patch looks harmless from a build standpoint, but
that's not saying much, so can you please quote the actual build
failure here?

                  Linus

Re: Linux 5.19-rc6

[Sudip Mukherjee]

On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> <sudipm.mukherjee@gmail.com> wrote:
> >
> > > >
> > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > >
> > > That patch looks sane to me, but I guess Guenter would need to check
> >
> > I still see the failure in my builds with this patch. But surprisingly
> > I dont see the build failure (with or without this patch) with gcc-12,
> > only with gcc-11.
>
> Arrghs. "build failure"?

Uhh.. no, sorry.. I meant the same problem which Guenter reported with
powerpc64-linux-ld, hard float and soft float.
But I dont see this problem with gcc-12, only with gcc-11.


-- 
Regards
Sudip

Re: Linux 5.19-rc6

[Guenter Roeck]

On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > <sudipm.mukherjee@gmail.com> wrote:
> > >
> > > > >
> > > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > > >
> > > > That patch looks sane to me, but I guess Guenter would need to check
> > >
> > > I still see the failure in my builds with this patch. But surprisingly
> > > I dont see the build failure (with or without this patch) with gcc-12,
> > > only with gcc-11.
> >
> > Arrghs. "build failure"?
> 
> Uhh.. no, sorry.. I meant the same problem which Guenter reported with
> powerpc64-linux-ld, hard float and soft float.
> But I dont see this problem with gcc-12, only with gcc-11.
> 

Weird. It works for me with gcc 11.3.0 / binutils 2.38 as well as with
gcc 11.2.0 / binutils 2.36.1.

Guenter

Re: Linux 5.19-rc6

[Guenter Roeck]

On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > <sudipm.mukherjee@gmail.com> wrote:
> > >
> > > > >
> > > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > > >
> > > > That patch looks sane to me, but I guess Guenter would need to check
> > >
> > > I still see the failure in my builds with this patch. But surprisingly
> > > I dont see the build failure (with or without this patch) with gcc-12,
> > > only with gcc-11.
> >
> > Arrghs. "build failure"?
> 
> Uhh.. no, sorry.. I meant the same problem which Guenter reported with
> powerpc64-linux-ld, hard float and soft float.
> But I dont see this problem with gcc-12, only with gcc-11.

I am wondering ... you say "my builds". Is this possibly not
allmodconfig ? It may well be that there are other configurations
which still have a problem after my patch has been applied.

Guenter

Re: Linux 5.19-rc6

[Sudip Mukherjee]

On Wed, Jul 13, 2022 at 11:56 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> > On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > <sudipm.mukherjee@gmail.com> wrote:
> > > >
> > > > > >
> > > > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > > > >
> > > > > That patch looks sane to me, but I guess Guenter would need to check
> > > >
> > > > I still see the failure in my builds with this patch. But surprisingly
> > > > I dont see the build failure (with or without this patch) with gcc-12,
> > > > only with gcc-11.
> > >
> > > Arrghs. "build failure"?
> >
> > Uhh.. no, sorry.. I meant the same problem which Guenter reported with
> > powerpc64-linux-ld, hard float and soft float.
> > But I dont see this problem with gcc-12, only with gcc-11.
> >
>
> Weird. It works for me with gcc 11.3.0 / binutils 2.38 as well as with
> gcc 11.2.0 / binutils 2.36.1.

Its entirely possible that I have messed up, there are references to
many patches in this thread. :)
Can you please paste the link of the patch that you say is working for
you. I will try a clean build with that.


-- 
Regards
Sudip

Re: Linux 5.19-rc6

[Guenter Roeck]

On Thu, Jul 14, 2022 at 12:09:24AM +0100, Sudip Mukherjee wrote:
> On Wed, Jul 13, 2022 at 11:56 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> > > On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > >
> > > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > > <sudipm.mukherjee@gmail.com> wrote:
> > > > >
> > > > > > >
> > > > > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > > > > >
> > > > > > That patch looks sane to me, but I guess Guenter would need to check
> > > > >
> > > > > I still see the failure in my builds with this patch. But surprisingly
> > > > > I dont see the build failure (with or without this patch) with gcc-12,
> > > > > only with gcc-11.
> > > >
> > > > Arrghs. "build failure"?
> > >
> > > Uhh.. no, sorry.. I meant the same problem which Guenter reported with
> > > powerpc64-linux-ld, hard float and soft float.
> > > But I dont see this problem with gcc-12, only with gcc-11.
> > >
> >
> > Weird. It works for me with gcc 11.3.0 / binutils 2.38 as well as with
> > gcc 11.2.0 / binutils 2.36.1.
> 
> Its entirely possible that I have messed up, there are references to
> many patches in this thread. :)
> Can you please paste the link of the patch that you say is working for
> you. I will try a clean build with that.
> 

The patch is at:

https://lore.kernel.org/lkml/20220618232737.2036722-1-linux@roeck-us.net/raw

Guenter

Re: Linux 5.19-rc6

[Sudip Mukherjee]

On Thu, Jul 14, 2022 at 12:12 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Thu, Jul 14, 2022 at 12:09:24AM +0100, Sudip Mukherjee wrote:
> > On Wed, Jul 13, 2022 at 11:56 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> > > > On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > > >
> > > > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > > > <sudipm.mukherjee@gmail.com> wrote:
> > > > > >
> > > > > > > >
> > > > > > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > > > > > >
> > > > > > > That patch looks sane to me, but I guess Guenter would need to check
> > > > > >
> > > > > > I still see the failure in my builds with this patch. But surprisingly
> > > > > > I dont see the build failure (with or without this patch) with gcc-12,
> > > > > > only with gcc-11.
> > > > >
> > > > > Arrghs. "build failure"?
> > > >
> > > > Uhh.. no, sorry.. I meant the same problem which Guenter reported with
> > > > powerpc64-linux-ld, hard float and soft float.
> > > > But I dont see this problem with gcc-12, only with gcc-11.
> > > >
> > >
> > > Weird. It works for me with gcc 11.3.0 / binutils 2.38 as well as with
> > > gcc 11.2.0 / binutils 2.36.1.
> >
> > Its entirely possible that I have messed up, there are references to
> > many patches in this thread. :)
> > Can you please paste the link of the patch that you say is working for
> > you. I will try a clean build with that.
> >
>
> The patch is at:
>
> https://lore.kernel.org/lkml/20220618232737.2036722-1-linux@roeck-us.net/raw

Thanks, that works. tested with gcc-11.3.1, and binutils 2.38 on top
of latest mainline (4a57a8400075bc5287c5c877702c68aeae2a033d)

When I said I still had the problem, I tested with
https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/


-- 
Regards
Sudip

Re: Linux 5.19-rc6

[Guenter Roeck]

On Thu, Jul 14, 2022 at 12:26:27AM +0100, Sudip Mukherjee wrote:
> On Thu, Jul 14, 2022 at 12:12 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Thu, Jul 14, 2022 at 12:09:24AM +0100, Sudip Mukherjee wrote:
> > > On Wed, Jul 13, 2022 at 11:56 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> > > > > On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> > > > > <torvalds@linux-foundation.org> wrote:
> > > > > >
> > > > > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > > > > <sudipm.mukherjee@gmail.com> wrote:
> > > > > > >
> > > > > > > > >
> > > > > > > > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > > > > > > >
> > > > > > > > That patch looks sane to me, but I guess Guenter would need to check
> > > > > > >
> > > > > > > I still see the failure in my builds with this patch. But surprisingly
> > > > > > > I dont see the build failure (with or without this patch) with gcc-12,
> > > > > > > only with gcc-11.
> > > > > >
> > > > > > Arrghs. "build failure"?
> > > > >
> > > > > Uhh.. no, sorry.. I meant the same problem which Guenter reported with
> > > > > powerpc64-linux-ld, hard float and soft float.
> > > > > But I dont see this problem with gcc-12, only with gcc-11.
> > > > >
> > > >
> > > > Weird. It works for me with gcc 11.3.0 / binutils 2.38 as well as with
> > > > gcc 11.2.0 / binutils 2.36.1.
> > >
> > > Its entirely possible that I have messed up, there are references to
> > > many patches in this thread. :)
> > > Can you please paste the link of the patch that you say is working for
> > > you. I will try a clean build with that.
> > >
> >
> > The patch is at:
> >
> > https://lore.kernel.org/lkml/20220618232737.2036722-1-linux@roeck-us.net/raw
> 
> Thanks, that works. tested with gcc-11.3.1, and binutils 2.38 on top
> of latest mainline (4a57a8400075bc5287c5c877702c68aeae2a033d)
> 
> When I said I still had the problem, I tested with
> https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/

Makes sense. That was the patch fixing the runtime problem.

Guenter

Re: Linux 5.19-rc6

[Kefeng Wang]

On 2022/7/14 3:48, Russell King (Oracle) wrote:
> On Wed, Jul 13, 2022 at 12:36:50PM -0700, Linus Torvalds wrote:
>> On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>> OF: amba_device_add() failed (-19) for /amba/smc@10100000
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 1 at lib/refcount.c:28 of_platform_bus_create+0x33c/0x3dc
>>> refcount_t: underflow; use-after-free.
Sorry to lead to this issue,
>> This too has been going on since -rc1, but it's not obvious what caused it.
>>
>> At a guess, looking around the amba changes, I'm assuming it's
>>
>>    7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")
>>
>> Does reverting that commit make it go away?
> There may be a patch that solves that, but it's never been submitted to
> my patch system:
>
> https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
This patch is to fix the above issue reported-by Guenter, and it merged 
into linux-next
for a while, which Applied in 
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9207/1
>
> I'm sorry, but I'm utterly crap at picking up patches off mailing lists,
> so if stuff doesn't end up inthe patch system, it gets missed.
Is there some special for bugfix patch when send to arm patch system, please
let me know if I missed.

Re: Linux 5.19-rc6

[Geert Uytterhoeven]

Hi Linus,

On Wed, Jul 13, 2022 at 11:51 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <alexdeucher@gmail.com> wrote:
> > If you want to apply Guenter's patch original patch:
> > https://patchwork.freedesktop.org/patch/490184/
> > That's fine with me.
>
> Honestly, by this time I feel that it's too little, too late.

[...]

> So considering that the ppc people ignored this whole issue since the
> merge window, I think it's entirely unreasonable to then apply a
> ppc-specific patch for this at this time, when people literally asked
> "why is this needed", and there was no reply from the powerpc side.

Oh, it's not just this one. The lists of build regressions between v5.18
and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-(

[1] https://lore.kernel.org/all/20220606082201.2792145-1-geert@linux-m68k.org
[2] https://lore.kernel.org/all/20220711064425.3084093-1-geert@linux-m68k.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.19-rc6

[Russell King (Oracle)]

On Wed, Jul 13, 2022 at 01:40:41PM -0700, Guenter Roeck wrote:
> On 7/13/22 13:21, Linus Torvalds wrote:
> > On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > > 
> > > There may be a patch that solves that, but it's never been submitted to
> > > my patch system:
> > > 
> > > https://lore.kernel.org/all/20220524025139.40212-1-wangkefeng.wang@huawei.com/
> > 
> > That patch looks sane to me, but I guess Guenter would need to check
> > ... Guenter?
> > 
> 
> That patch is (and has been) in linux-next for a long time,
> as commit d2ca1fd2bc70, and with the following tags.
> 
>     Fixes: 7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")
>     Reported-by: Guenter Roeck <linux@roeck-us.net>
>     Tested-by: Guenter Roeck <linux@roeck-us.net>
>     Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>     Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> So, yes, it fixes the problem. I don't know where it is pulled from, though.
> I thought that it is from Russell's tree, given his Signed-off-by:,
> but I never really checked.

Ah, yes, it's in the same bracnh as 9192/1. So if Linus is reporting
that 9192/1 is still a problem in linux-next, then this patch does
_not_ fix it.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: Linux 5.19-rc6

[Russell King (Oracle)]

On Wed, Jul 13, 2022 at 01:42:15PM -0700, Linus Torvalds wrote:
> On Wed, Jul 13, 2022 at 1:40 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > That patch is (and has been) in linux-next for a long time,
> > as commit d2ca1fd2bc70, and with the following tags.
> >
> >      Fixes: 7719a68b2fa4 ("ARM: 9192/1: amba: fix memory leak in amba_device_try_add()")
> >      Reported-by: Guenter Roeck <linux@roeck-us.net>
> >      Tested-by: Guenter Roeck <linux@roeck-us.net>
> >      Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> >      Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> >
> > So, yes, it fixes the problem. I don't know where it is pulled from, though.
> > I thought that it is from Russell's tree, given his Signed-off-by:,
> > but I never really checked.
> 
> Heh. Yeah, with that sign-off, I bet it's in Russell's queue, bit it
> just ended up in the "for next release" branch. Russell?

Oh, I see, I never rebased my "misc" branch from the last cycle, so it
looks to me like 9192/1 was due for _this_ merge window - so I merged
the fix for it into that same branch, rather than the "fixes" branch.
I've moved it over to the correct branch now.

Looks like there's another fix that's in that very same state as well.

Expect a pull request shortly.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: Linux 5.19-rc6

[Guenter Roeck]

On 7/14/22 00:23, Geert Uytterhoeven wrote:
> Hi Linus,
> 
> On Wed, Jul 13, 2022 at 11:51 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>>> If you want to apply Guenter's patch original patch:
>>> https://patchwork.freedesktop.org/patch/490184/
>>> That's fine with me.
>>
>> Honestly, by this time I feel that it's too little, too late.
> 
> [...]
> 
>> So considering that the ppc people ignored this whole issue since the
>> merge window, I think it's entirely unreasonable to then apply a
>> ppc-specific patch for this at this time, when people literally asked
>> "why is this needed", and there was no reply from the powerpc side.
> 
> Oh, it's not just this one. The lists of build regressions between v5.18
> and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-(
> 
> [1] https://lore.kernel.org/all/20220606082201.2792145-1-geert@linux-m68k.org
> [2] https://lore.kernel.org/all/20220711064425.3084093-1-geert@linux-m68k.org
> 

How do you build your images ? I don't see many of the problems you report,
even if I build the files with W=1. It is odd, since reports such as

drivers/mfd/asic3.c:941:23: error: unused variable 'asic'

are real, but I just don't see that. If I build that file, I see that
it builds with -Wno-unused-but-set-variable, due to

Makefile:KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)

The override in scripts/Makefile.extrawarn doesn't seem to work even though
it adds "-Wunused-but-set-variable" to the compile flags. And if I remove
"-Wno-unused-but-set-variable" from Makefile I still don't get the error/warning.
Confused. I must be missing something, but what ?

Thanks,
Guenter

Re: Linux 5.19-rc6

[Geert Uytterhoeven]

Hi Günter,

On Thu, Jul 14, 2022 at 3:20 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 7/14/22 00:23, Geert Uytterhoeven wrote:
> > On Wed, Jul 13, 2022 at 11:51 PM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> >> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <alexdeucher@gmail.com> wrote:
> >>> If you want to apply Guenter's patch original patch:
> >>> https://patchwork.freedesktop.org/patch/490184/
> >>> That's fine with me.
> >>
> >> Honestly, by this time I feel that it's too little, too late.
> >
> > [...]
> >
> >> So considering that the ppc people ignored this whole issue since the
> >> merge window, I think it's entirely unreasonable to then apply a
> >> ppc-specific patch for this at this time, when people literally asked
> >> "why is this needed", and there was no reply from the powerpc side.
> >
> > Oh, it's not just this one. The lists of build regressions between v5.18
> > and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-(
> >
> > [1] https://lore.kernel.org/all/20220606082201.2792145-1-geert@linux-m68k.org
> > [2] https://lore.kernel.org/all/20220711064425.3084093-1-geert@linux-m68k.org
> >
>
> How do you build your images ? I don't see many of the problems you report,
> even if I build the files with W=1. It is odd, since reports such as

I rely on the kisskb build service, and just parse their build logs.

> drivers/mfd/asic3.c:941:23: error: unused variable 'asic'
>
> are real, but I just don't see that. If I build that file, I see that
> it builds with -Wno-unused-but-set-variable, due to
>
> Makefile:KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
>
> The override in scripts/Makefile.extrawarn doesn't seem to work even though
> it adds "-Wunused-but-set-variable" to the compile flags. And if I remove
> "-Wno-unused-but-set-variable" from Makefile I still don't get the error/warning.
> Confused. I must be missing something, but what ?

That particular error is seen in the sh4-gcc11/sh-allmodconfig
build[3].  I assume it is fixed by now (see commit d684e0a52d36f893
("sh: convert nommu io{re,un}map() to static inline functions")).

[3] http://kisskb.ellerman.id.au/kisskb/buildresult/14767627/

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.19-rc6

[Linus Torvalds]

On Thu, Jul 14, 2022 at 12:23 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Oh, it's not just this one. The lists of build regressions between v5.18
> and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-(
>
> [1] https://lore.kernel.org/all/20220606082201.2792145-1-geert@linux-m68k.org
> [2] https://lore.kernel.org/all/20220711064425.3084093-1-geert@linux-m68k.org

Hmm.

Some of them are because UM ends up defining and exposing helper
functions like "to_phys()", which it just shouldn't do. Very generic
name - so when some driver ends up using the same name, you get those
errors.

And some look positively strange. Like that

  drivers/mfd/asic3.c: error: unused variable 'asic'
[-Werror=unused-variable]:  => 941:23

which is clearly used three lines later by

        iounmap(asic->tmio_cnf);

and I can't find any case of 'iounmap()' having been defined to an
empty macro or anything like that to explain it. The error in
drivers/tty/serial/sh-sci.c looks to be exactly the same issue, just
with ioremap() instead of iounmap().

It would be good to have some way to find which build/architecture it
is, because right now it just looks bogus.

Do you perhaps use some broken compiler that complains when the empty
inline functions don't use their arguments? Because that's what those
ioremap/iounmap() ones look like to me, but there might be some
magical architecture / config that has issues that aren't obvious.

IOW, I'd love to get those fixed, but I would also want a little bit more info.

            Linus

Re: Linux 5.19-rc6

[Alex Deucher]

On Wed, Jul 13, 2022 at 5:32 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <alexdeucher@gmail.com> wrote:
> >
> > If you want to apply Guenter's patch original patch:
> > https://patchwork.freedesktop.org/patch/490184/
> > That's fine with me.
>
> Honestly, by this time I feel that it's too little, too late.
>
> The ppc people apparently didn't care at all about the fact that this
> driver didn't compile.
>
> At least Michael Ellerman and Daniel Axtens were cc'd on that thread
> with the proposed fix originally.
>
> I don't see any replies from ppc people as to why it happened, even
> though apparently a bog-standard "make allmodconfig" just doesn't
> build.
>
> I'd try it myself, since I do have a cross-build environment for some
> earlier cross-build verification I did.
>
> But since my upgrade to F36 it now uses gcc-12, and possibly due to
> that I get hundreds of errors long before I get to any drm drivers:
>
>   Cannot find symbol for section 19: .text.create_section_mapping.
>   arch/powerpc/mm/mem.o: failed
>   ...
>   Cannot find symbol for section 19: .text.cpu_show_meltdown.
>   drivers/base/cpu.o: failed
>   Error: External symbol 'memset' referenced from prom_init.c
>
> this cross environment used to work for me, but something changed (I
> mention gcc-12, but honestly, that's based on nothing at all, except
> for the few problems it caused on x86-64. It could be something
> entirely unrelated, but it does look like some bad interaction with
> -ffunction-sections).
>
> So considering that the ppc people ignored this whole issue since the
> merge window, I think it's entirely unreasonable to then apply a
> ppc-specific patch for this at this time, when people literally asked
> "why is this needed", and there was no reply from the powerpc side.
>
> Does any of that sound like "we should support this driver on powerpc" to you?

Fair enough.  I don't have a strong opinion on the matter.  Users will
hopefully likely notice the failure after release because most people
don't test until after a release and then we'll apply the fix and
re-enable it for 5.20 so that would leave 5.19 broken for PPC64 users
which would not be ideal.  But as you said, no one has cared up to
this point.

Alex

>
>                  Linus

Re: Linux 5.19-rc6

[Guenter Roeck]

On 7/14/22 09:48, Linus Torvalds wrote:
> On Thu, Jul 14, 2022 at 12:23 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>>
>> Oh, it's not just this one. The lists of build regressions between v5.18
>> and v5.19-rc1 [1] resp. v5.19-rc6 [2] look surprisingly similar :-(
>>
>> [1] https://lore.kernel.org/all/20220606082201.2792145-1-geert@linux-m68k.org
>> [2] https://lore.kernel.org/all/20220711064425.3084093-1-geert@linux-m68k.org
> 
> Hmm.
> 
> Some of them are because UM ends up defining and exposing helper
> functions like "to_phys()", which it just shouldn't do. Very generic
> name - so when some driver ends up using the same name, you get those
> errors.

We can't use virt_to_phys() and phys_to_virt() because they are defined for
the underlying architecture. Would uml_to_phys() and uml_to_virt() be
acceptable ? If so, I'll submit a patch.

> 
> And some look positively strange. Like that
> 
>    drivers/mfd/asic3.c: error: unused variable 'asic'
> [-Werror=unused-variable]:  => 941:23
> 
> which is clearly used three lines later by
> 
>          iounmap(asic->tmio_cnf);
> 
> and I can't find any case of 'iounmap()' having been defined to an
> empty macro or anything like that to explain it. The error in
> drivers/tty/serial/sh-sci.c looks to be exactly the same issue, just
> with ioremap() instead of iounmap().
> 
> It would be good to have some way to find which build/architecture it
> is, because right now it just looks bogus.
> 
> Do you perhaps use some broken compiler that complains when the empty
> inline functions don't use their arguments? Because that's what those
> ioremap/iounmap() ones look like to me, but there might be some
> magical architecture / config that has issues that aren't obvious.
> 
> IOW, I'd love to get those fixed, but I would also want a little bit more info.
> 
Geert gave the necessary hint - it looks like sh-nommu used defines
for iomap() and iounmap(), which made the variable unused. According
to Geert that was fixed a couple of days ago.

Guenter

Re: Linux 5.19-rc6

[Linus Torvalds]

On Thu, Jul 14, 2022 at 10:24 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> We can't use virt_to_phys() and phys_to_virt() because they are defined for
> the underlying architecture. Would uml_to_phys() and uml_to_virt() be
> acceptable ? If so, I'll submit a patch.

Sure, that would be good, and make th uml helpers clearly be in the
uml namespace.

Another more traditional approach is to use underscored versions, but
exactly because that's the normal thing, things like that may then
clash with the "native architecture" version, so for uml using an
explicit uml namespace might be the better option.

               Linus

Re: Linux 5.19-rc6

[Russell Currey]

Hi Linus,

On Wed, 2022-07-13 at 14:32 -0700, Linus Torvalds wrote:
> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <alexdeucher@gmail.com>
> wrote:
> > 
> > If you want to apply Guenter's patch original patch:
> > https://patchwork.freedesktop.org/patch/490184/
> > That's fine with me.
> 
> Honestly, by this time I feel that it's too little, too late.
> 
> The ppc people apparently didn't care at all about the fact that this
> driver didn't compile.
> 
> At least Michael Ellerman and Daniel Axtens were cc'd on that thread
> with the proposed fix originally.
> 
> I don't see any replies from ppc people as to why it happened, even
> though apparently a bog-standard "make allmodconfig" just doesn't
> build.

I believe Michael Ellerman has been on holiday for some time, and
Daniel Axtens no longer works on powerpc (and wasn't the one that
submitted the patch, it was submitted by Paul Mackerras, who wasn't on
CC).

The proposed fix didn't get sent to linuxppc-dev either, so it's
unlikely many ppc people knew about it.

We certainly should have noticed allmodconfig was broken, and should
have more than just Michael keeping an eye on all his automated builds.

I would count this case as ignorance rather than apathy.

- ruscur

Re: Linux 5.19-rc6

[Geert Uytterhoeven]

On Thu, Jul 14, 2022 at 7:24 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 7/14/22 09:48, Linus Torvalds wrote:
> > And some look positively strange. Like that
> >
> >    drivers/mfd/asic3.c: error: unused variable 'asic'
> > [-Werror=unused-variable]:  => 941:23
> >
> > which is clearly used three lines later by
> >
> >          iounmap(asic->tmio_cnf);
> >
> > and I can't find any case of 'iounmap()' having been defined to an
> > empty macro or anything like that to explain it. The error in
> > drivers/tty/serial/sh-sci.c looks to be exactly the same issue, just
> > with ioremap() instead of iounmap().
> >
> > It would be good to have some way to find which build/architecture it
> > is, because right now it just looks bogus.
> >
> > Do you perhaps use some broken compiler that complains when the empty
> > inline functions don't use their arguments? Because that's what those
> > ioremap/iounmap() ones look like to me, but there might be some
> > magical architecture / config that has issues that aren't obvious.
> >
> > IOW, I'd love to get those fixed, but I would also want a little bit more info.
> >
> Geert gave the necessary hint - it looks like sh-nommu used defines
> for iomap() and iounmap(), which made the variable unused. According
> to Geert that was fixed a couple of days ago.

Yes, post-rc6 should be fine, as the fix went in... for the third time.
Combine people that keep on switching back to macros without reading
a file's history with unresponsive maintainers...

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.19-rc6

[Sudip Mukherjee]

Hi Russell,

On Fri, Jul 15, 2022 at 12:34 AM Russell Currey <ruscur@russell.cc> wrote:
>
> Hi Linus,
>
> On Wed, 2022-07-13 at 14:32 -0700, Linus Torvalds wrote:
> > On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <alexdeucher@gmail.com>
> > wrote:
> > >
> > > If you want to apply Guenter's patch original patch:
> > > https://patchwork.freedesktop.org/patch/490184/
> > > That's fine with me.
> >
> > Honestly, by this time I feel that it's too little, too late.
> >
> > The ppc people apparently didn't care at all about the fact that this
> > driver didn't compile.
> >
> > At least Michael Ellerman and Daniel Axtens were cc'd on that thread
> > with the proposed fix originally.
> >
> > I don't see any replies from ppc people as to why it happened, even
> > though apparently a bog-standard "make allmodconfig" just doesn't
> > build.
>
> I believe Michael Ellerman has been on holiday for some time, and
> Daniel Axtens no longer works on powerpc (and wasn't the one that
> submitted the patch, it was submitted by Paul Mackerras, who wasn't on
> CC).
>
> The proposed fix didn't get sent to linuxppc-dev either, so it's
> unlikely many ppc people knew about it.
>
> We certainly should have noticed allmodconfig was broken, and should
> have more than just Michael keeping an eye on all his automated builds.

Not sure if I have added the correct people in my another mail, but
thats also ppc allmodconfig with gcc-12.
https://lore.kernel.org/lkml/Ys%2FaDKZNhhsENH9S@debian/



-- 
Regards
Sudip