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 [email protected]
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()
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 -- [email protected]
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
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
On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <[email protected]> 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
On Wed, Jul 13, 2022 at 3:42 PM Linus Torvalds
<[email protected]> wrote:
>
> On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <[email protected]> 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
On Wed, Jul 13, 2022 at 12:36:50PM -0700, Linus Torvalds wrote:
> On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <[email protected]> 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/[email protected]/
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!
On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle)
<[email protected]> wrote:
>
> There may be a patch that solves that, but it's never been submitted to
> my patch system:
>
> https://lore.kernel.org/all/[email protected]/
That patch looks sane to me, but I guess Guenter would need to check
... Guenter?
Linus
On 7/13/22 13:22, Linus Torvalds wrote:
> On Wed, Jul 13, 2022 at 12:53 PM Alex Deucher <[email protected]> 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
On 7/13/22 13:21, Linus Torvalds wrote:
> On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle)
> <[email protected]> wrote:
>>
>> There may be a patch that solves that, but it's never been submitted to
>> my patch system:
>>
>> https://lore.kernel.org/all/[email protected]/
>
> 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 <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
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
On Wed, Jul 13, 2022 at 12:53 PM Alex Deucher <[email protected]> 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
On Wed, Jul 13, 2022 at 4:46 PM Guenter Roeck <[email protected]> wrote:
>
> On 7/13/22 12:36, Linus Torvalds wrote:
> > On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <[email protected]> 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 <[email protected]>
>
> Guenter
On Wed, Jul 13, 2022 at 1:40 PM Guenter Roeck <[email protected]> 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 <[email protected]>
> Tested-by: Guenter Roeck <[email protected]>
> Signed-off-by: Kefeng Wang <[email protected]>
> Signed-off-by: Russell King (Oracle) <[email protected]>
>
> 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
On 7/13/22 12:36, Linus Torvalds wrote:
> On Tue, Jul 12, 2022 at 10:07 PM Guenter Roeck <[email protected]> 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
On Wed, Jul 13, 2022 at 1:46 PM Guenter Roeck <[email protected]> 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
On Wed, Jul 13, 2022 at 9:42 PM Linus Torvalds
<[email protected]> wrote:
>
> On Wed, Jul 13, 2022 at 12:49 PM Russell King (Oracle)
> <[email protected]> wrote:
> >
> > There may be a patch that solves that, but it's never been submitted to
> > my patch system:
> >
> > https://lore.kernel.org/all/[email protected]/
>
> 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
On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
<[email protected]> wrote:
>
> On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> <[email protected]> wrote:
> >
> > > >
> > > > https://lore.kernel.org/all/[email protected]/
> > >
> > > 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
On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <[email protected]> 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
On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
<[email protected]> wrote:
>
> > >
> > > https://lore.kernel.org/all/[email protected]/
> >
> > 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
On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> <[email protected]> wrote:
> >
> > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > <[email protected]> wrote:
> > >
> > > > >
> > > > > https://lore.kernel.org/all/[email protected]/
> > > >
> > > > 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
On Wed, Jul 13, 2022 at 11:56 PM Guenter Roeck <[email protected]> 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
> > <[email protected]> wrote:
> > >
> > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > <[email protected]> wrote:
> > > >
> > > > > >
> > > > > > https://lore.kernel.org/all/[email protected]/
> > > > >
> > > > > 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
On Wed, Jul 13, 2022 at 10:50:06PM +0100, Sudip Mukherjee wrote:
> On Wed, Jul 13, 2022 at 10:45 PM Linus Torvalds
> <[email protected]> wrote:
> >
> > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > <[email protected]> wrote:
> > >
> > > > >
> > > > > https://lore.kernel.org/all/[email protected]/
> > > >
> > > > 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
On Thu, Jul 14, 2022 at 12:12 AM Guenter Roeck <[email protected]> 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 <[email protected]> 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
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > > >
> > > > > > > > https://lore.kernel.org/all/[email protected]/
> > > > > > >
> > > > > > > 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/[email protected]/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/[email protected]/
--
Regards
Sudip
On Thu, Jul 14, 2022 at 12:09:24AM +0100, Sudip Mukherjee wrote:
> On Wed, Jul 13, 2022 at 11:56 PM Guenter Roeck <[email protected]> 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
> > > <[email protected]> wrote:
> > > >
> > > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > > <[email protected]> wrote:
> > > > >
> > > > > > >
> > > > > > > https://lore.kernel.org/all/[email protected]/
> > > > > >
> > > > > > 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/[email protected]/raw
Guenter
On Thu, Jul 14, 2022 at 12:26:27AM +0100, Sudip Mukherjee wrote:
> On Thu, Jul 14, 2022 at 12:12 AM Guenter Roeck <[email protected]> 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 <[email protected]> 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
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Wed, Jul 13, 2022 at 2:36 PM Sudip Mukherjee
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > > >
> > > > > > > > > https://lore.kernel.org/all/[email protected]/
> > > > > > > >
> > > > > > > > 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/[email protected]/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/[email protected]/
Makes sense. That was the patch fixing the runtime problem.
Guenter
Hi Linus,
On Wed, Jul 13, 2022 at 11:51 PM Linus Torvalds
<[email protected]> wrote:
> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <[email protected]> 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/[email protected]
[2] https://lore.kernel.org/all/[email protected]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
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)
> > <[email protected]> wrote:
> > >
> > > There may be a patch that solves that, but it's never been submitted to
> > > my patch system:
> > >
> > > https://lore.kernel.org/all/[email protected]/
> >
> > 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 <[email protected]>
> Tested-by: Guenter Roeck <[email protected]>
> Signed-off-by: Kefeng Wang <[email protected]>
> Signed-off-by: Russell King (Oracle) <[email protected]>
>
> 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!
On Wed, Jul 13, 2022 at 01:42:15PM -0700, Linus Torvalds wrote:
> On Wed, Jul 13, 2022 at 1:40 PM Guenter Roeck <[email protected]> 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 <[email protected]>
> > Tested-by: Guenter Roeck <[email protected]>
> > Signed-off-by: Kefeng Wang <[email protected]>
> > Signed-off-by: Russell King (Oracle) <[email protected]>
> >
> > 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!
On 7/14/22 00:23, Geert Uytterhoeven wrote:
> Hi Linus,
>
> On Wed, Jul 13, 2022 at 11:51 PM Linus Torvalds
> <[email protected]> wrote:
>> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <[email protected]> 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/[email protected]
> [2] https://lore.kernel.org/all/[email protected]
>
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
Hi Günter,
On Thu, Jul 14, 2022 at 3:20 PM Guenter Roeck <[email protected]> wrote:
> On 7/14/22 00:23, Geert Uytterhoeven wrote:
> > On Wed, Jul 13, 2022 at 11:51 PM Linus Torvalds
> > <[email protected]> wrote:
> >> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <[email protected]> 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/[email protected]
> > [2] https://lore.kernel.org/all/[email protected]
> >
>
> 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 -- [email protected]
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
On Wed, Jul 13, 2022 at 5:32 PM Linus Torvalds
<[email protected]> wrote:
>
> On Wed, Jul 13, 2022 at 2:01 PM Alex Deucher <[email protected]> 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
On Thu, Jul 14, 2022 at 12:23 AM Geert Uytterhoeven
<[email protected]> 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/[email protected]
> [2] https://lore.kernel.org/all/[email protected]
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
On 7/14/22 09:48, Linus Torvalds wrote:
> On Thu, Jul 14, 2022 at 12:23 AM Geert Uytterhoeven
> <[email protected]> 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/[email protected]
>> [2] https://lore.kernel.org/all/[email protected]
>
> 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
On Thu, Jul 14, 2022 at 10:24 AM Guenter Roeck <[email protected]> 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
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 <[email protected]>
> 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
On Thu, Jul 14, 2022 at 7:24 PM Guenter Roeck <[email protected]> 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 -- [email protected]
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
Hi Russell,
On Fri, Jul 15, 2022 at 12:34 AM Russell Currey <[email protected]> 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 <[email protected]>
> > 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