These are indeed "should not happen" situations, but it turns out recent
changes made the 'task_is_stopped_or_trace()' case trigger (fix for that
exists, is pending more testing), and the BUG_ON() makes it
unnecessarily hard to actually debug for no good reason.

It's been that way for a long time, but let's make it clear: BUG_ON() is
not good for debugging, and should never be used in situations where you
could just say "this shouldn't happen, but we can continue".

Use WARN_ON_ONCE() instead to make sure it gets logged, and then just
continue running.  Instead of making the system basically unusuable
because you crashed the machine while potentially holding some very core
locks (eg this function is commonly called while holding 'tasklist_lock'
for writing).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull OpenRISC fixes from Stafford Horne:
 "Fixups for OpenRISC found during recent testing:

   - An OpenRISC irqchip fix to stop acking level interrupts which was
     causing issues on SMP platforms

   - A comment typo fix in our unwinder code"

* tag 'for-linus' of https://github.com/openrisc/linux:
  openrisc: unwinder: Fix grammar issue in comment
  irqchip: or1k-pic: Undefine mask_ack for level triggered hardware

Pull sound fixes from Takashi Iwai:
 "This became largish as it includes the pending ASoC fixes.

  Almost all changes are device-specific small fixes, while many of them
  are coverage for mixer issues that were detected by selftest. In
  addition, usual suspects for HD/USB-audio are there"

* tag 'sound-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (43 commits)
  ALSA: cs46xx: Fix missing snd_card_free() call at probe error
  ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)
  ALSA: usb-audio: Add quirk for Fiero SC-01
  ALSA: hda/realtek: Add quirk for Clevo L140PU
  ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices
  ASoC: madera: Fix event generation for rate controls
  ASoC: madera: Fix event generation for OUT1 demux
  ASoC: cs47l15: Fix event generation for low power mux control
  ASoC: cs35l41: Add ASP TX3/4 source to register patch
  ASoC: dapm: Initialise kcontrol data for mux/demux controls
  ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error
  ASoC: cs35l41: Correct some control names
  ASoC: wm5110: Fix DRE control
  ASoC: wm_adsp: Fix event for preloader
  MAINTAINERS: update ASoC Qualcomm maintainer email-id
  ASoC: rockchip: i2s: switch BCLK to GPIO
  ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states
  ASoC: SOF: pm: add definitions for S4 and S5 states
  ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2
  ASoC: SOF: Intel: hda: Fix compressed stream position tracking
  ...

Pull xen security fixes from Juergen Gross:

 - XSA-403 (4 patches for blkfront and netfront drivers):

   Linux Block and Network PV device frontends don't zero memory regions
   before sharing them with the backend (CVE-2022-26365,
   CVE-2022-33740). Additionally the granularity of the grant table
   doesn't allow sharing less than a 4K page, leading to unrelated data
   residing in the same 4K page as data shared with a backend being
   accessible by such backend (CVE-2022-33741, CVE-2022-33742).

 - XSA-405 (1 patch for netfront driver, only 5.10 and newer):

   While adding logic to support XDP (eXpress Data Path), a code label
   was moved in a way allowing for SKBs having references (pointers)
   retained for further processing to nevertheless be freed.

 - XSA-406 (1 patch for Arm specific dom0 code):

   When mapping pages of guests on Arm, dom0 is using an rbtree to keep
   track of the foreign mappings.

   Updating of that rbtree is not always done completely with the
   related lock held, resulting in a small race window, which can be
   used by unprivileged guests via PV devices to cause inconsistencies
   of the rbtree. These inconsistencies can lead to Denial of Service
   (DoS) of dom0, e.g. by causing crashes or the inability to perform
   further mappings of other guests' memory pages.

* tag 'xsa-5.19-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/arm: Fix race in RB-tree based P2M accounting
  xen-netfront: restore __skb_queue_tail() positioning in xennet_get_responses()
  xen/blkfront: force data bouncing when backend is untrusted
  xen/netfront: force data bouncing when backend is untrusted
  xen/netfront: fix leaking data in shared pages
  xen/blkfront: fix leaking data in shared pages

The previous cleanup with devres may lead to the incorrect release
orders at the probe error handling due to the devres's nature.  Until
we register the card, snd_card_free() has to be called at first for
releasing the stuff properly when the driver tries to manage and
release the stuff via card->private_free().

This patch fixes it by calling snd_card_free() manually on the error
from the probe callback.

Fixes: 5bff69b3

 ("ALSA: cs46xx: Allocate resources with device-managed APIs")
Cc: <stable@vger.kernel.org>
Reported-and-tested-by: Jan Engelhardt <jengelh@inai.de>
Link: https://lore.kernel.org/r/p2p1s96o-746-74p4-s95-61qo1p7782pn@vanv.qr
Link: https://lore.kernel.org/r/20220705152336.350-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Pull ARM SoC fixes from Arnd Bergmann:
 "Another set of minor patches for Arm DTS files and soc specific
  drivers:

   - More reference counting bug fixes for DT nodes, and other trivial
     code fixes

   - Multiple code fixes for the Arm SCMI firmware driver to improve
     compatibility with firmware implementations.

   - A patch series for at91 to address power management issues from
     using the wrong DT compatible properties.

   - A series of patches to fix pad settings for NXP imx8mp to leave the
     configuration untouched from the boot loader

   - Additional DT fixes for qualcomm and NXP platforms

   - A boot time fix for stm32mp15 DT

   - Konrad Dybcio becomes an additional reviewer for the Qualcomm
     platforms"

* tag 'soc-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (42 commits)
  soc: qcom: smem: use correct format characters
  ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15
  ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI
  ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board
  ARM: dts: stm32: use the correct clock source for CEC on stm32mp151
  ARM: dts: stm32: fix pwr regulators references to use scmi
  soc: ixp4xx/npe: Fix unused match warning
  ARM: at91: pm: Mark at91_pm_secure_init as __init
  ARM: at91: fix soc detection for SAM9X60 SiPs
  ARM: dts: at91: sama5d2_icp: fix eeprom compatibles
  ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
  ARM: at91: pm: use proper compatibles for sama7g5's rtc and rtt
  ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
  ARM: at91: pm: use proper compatible for sama5d2's rtc
  arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
  firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API
  firmware: arm_scmi: Fix response size warning for OPTEE transport
  arm64: dts: imx8mp-icore-mx8mp-edim2.2: correct pad settings
  arm64: dts: imx8mp-phyboard-pollux-rdk: correct i2c2 & mmc settings
  arm64: dts: imx8mp-phyboard-pollux-rdk: correct eqos pad settings
  ...

Merge tag 'stm32-dt-for-v5.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/fixes

STM32 DT fixes for v5.19, round 2

Highlights:
-----------

 -Fixes STM32MP15:
  - Add missing usbh clock and fix clk order for usbh to avoid PLL
    issue.
  - Fix SCMI version: use scmi regulator and update missing SCMI
    clocks to be able to correcly boot.

* tag 'stm32-dt-for-v5.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32:
  ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15
  ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI
  ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board
  ARM: dts: stm32: use the correct clock source for CEC on stm32mp151
  ARM: dts: stm32: fix pwr regulators references to use scmi

Link: https://lore.kernel.org/r/1259e082-a3a4-96a5-ec9c-05dbb893a746@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

When compiling with -Wformat, clang emits the following warnings:

drivers/soc/qcom/smem.c:847:41: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
                        dev_err(smem->dev, "bad host %hu\n", remote_host);
                                                     ~~~     ^~~~~~~~~~~
                                                     %u
./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err'
        dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
                                                               ~~~     ^~~~~~~~~~~
./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
                _p_func(dev, fmt, ##__VA_ARGS__);                       \
                             ~~~    ^~~~~~~~~~~
drivers/soc/qcom/smem.c:852:47: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
                        dev_err(smem->dev, "duplicate host %hu\n", remote_host);
                                                           ~~~     ^~~~~~~~~~~
                                                           %u
./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err'
        dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
                                                               ~~~     ^~~~~~~~~~~
./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
                _p_func(dev, fmt, ##__VA_ARGS__);                       \
                             ~~~    ^~~~~~~~~~~

The types of these arguments are unconditionally defined, so this patch
updates the format character to the correct one and change type of
remote_host to "u16" to match with other types.

Signed-off-by: Bill Wendling <morbo@google.com>
Tested-by: Justin Stitt <jstitt007@gmail.com>
Reviewed-by: Justin Stitt <jstitt007@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'asoc-fix-v5.19-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v5.19

A collection of fixes for v5.19, quite large but nothing major - a good
chunk of it is more stuff that was identified by mixer-test regarding
event generation.

The patch applies the same quirks used for SC-01 at firmware v1.1.0 to
the ones running v1.0.0, with respect to hard-coded sample rates.

I got two more units and successfully tested the patch series with both
firmwares.

The support is now complete (not accounting ASIO).

Signed-off-by: Egor Vorontsov <sdoregor@sdore.me>
Link: https://lore.kernel.org/r/20220627100041.2861494-2-sdoregor@sdore.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fiero SC-01 is a USB sound card with two mono inputs and a single
stereo output. The inputs are composed into a single stereo stream.

The device uses a vendor-provided driver on Windows and does not work
at all without it. The driver mostly provides ASIO functionality, but
also alters the way the sound card is queried for sample rates and
clocks.

ALSA queries those failing with an EPIPE (same as Windows 10 does).
Presumably, the vendor-provided driver does not query it at all, simply
matching by VID:PID. Thus, I consider this a buggy firmware and adhere
to a set of fixed endpoint quirks instead.

The soundcard has an internal clock. Implicit feedback mode is required
for the playback.

I have updated my device to v1.1.0 from a Windows 10 VM using a vendor-
provided binary prior to the development, hoping for it to just begin
working. The device provides no obvious way to downgrade the firmware,
and regardless, there's no binary available for v1.0.0 anyway.

Thus, I will be getting another unit to extend the patch with support
for that. Expected to be a simple copy-paste of the existing one,
though.

There were no previous reports of that device in context of Linux
anywhere. Other issues have been reported though, but that's out of the
scope.

Signed-off-by: Egor Vorontsov <sdoregor@sdore.me>
Link: https://lore.kernel.org/r/20220627100041.2861494-1-sdoregor@sdore.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Fixes headset detection on Clevo L140PU.

Signed-off-by: Tim Crawford <tcrawford@system76.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220624144109.3957-1-tcrawford@system76.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Treat the claimed 96kHz 1ch in the descriptors as 48kHz 2ch, so that
the audio stream doesn't sound mono. Also fix initial stream
alignment, so that left and right channels are in the correct order.

Signed-off-by: John Veness <john-linux@pelago.org.uk>
Link: https://lore.kernel.org/r/20220624140757.28758-1-john-linux@pelago.org.uk
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The USBH composed of EHCI and OHCI controllers needs the PHY clock to be
initialized first, before enabling (gating) them. The reverse is also
required when going to suspend.
So, add USBPHY clock as 1st entry in both controllers, so the USBPHY PLL
gets enabled 1st upon controller init. Upon suspend/resume, this also makes
the clock to be disabled/re-enabled in the correct order.
This fixes some IRQ storm conditions seen when going to low-power, due to
PHY PLL being disabled before all clocks are cleanly gated.

Fixes: 949a0c0d ("ARM: dts: stm32: add USB Host (USBH) support to stm32mp157c")
Fixes: db7be2cb

 ("ARM: dts: stm32: use usbphyc ck_usbo_48m as USBH OHCI clock on stm32mp151")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>

Delete the node fixed clock managed by secure world with SCMI.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>

LSE clock is provided by SCMI.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>

The peripheral clock of CEC is not LSE but CEC.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>

Fixes stm32mp15*-scmi DTS files introduced in [1] to also access PWR
regulators through SCMI service. This is needed since enabling secure
only access to RCC clock and reset controllers also enables secure
access only on PWR voltage regulators reg11, reg18 and usb33 hence
these must also be accessed through SCMI Voltage Domain protocol.
This change applies on commit [2] that already corrects issues from
commit [1].

Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Link: [1] https://lore.kernel.org/linux-arm-kernel/20220422150952.20587-7-alexandre.torgue@foss.st.com
Link: [2] https://lore.kernel.org/linux-arm-kernel/20220613071920.5463-1-alexandre.torgue@foss.st.com
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>

Looking at the conditional lock acquire functions in the kernel due to
the new sparse support (see commit 4a557a5d "sparse: introduce
conditional lock acquire function attribute"), it became obvious that
the lockref code has a couple of them, but they don't match the usual
naming convention for the other ones, and their return value logic is
also reversed.

In the other very similar places, the naming pattern is '*_and_lock()'
(eg 'atomic_put_and_lock()' and 'refcount_dec_and_lock()'), and the
function returns true when the lock is taken.

The lockref code is superficially very similar to the refcount code,
only with the special "atomic wrt the embedded lock" semantics.  But
instead of the '*_and_lock()' naming it uses '*_or_lock()'.

And instead of returning true in case it took the lock, it returns true
if it *didn't* take the lock.

Now, arguably the reflock code is quite logical: it really is a "either
decrement _or_ lock" kind of situation - and the return value is about
whether the operation succeeded without any special care needed.

So despite the similarities, the differences do make some sense, and
maybe it's not worth trying to unify the different conditional locking
primitives in this area.

But while looking at this all, it did become obvious that the
'lockref_get_or_lock()' function hasn't actually had any users for
almost a decade.

The only user it ever had was the shortlived 'd_rcu_to_refcount()'
function, and it got removed and replaced with 'lockref_get_not_dead()'
back in 2013 in commits 0d98439e ("vfs: use lockred 'dead' flag to
mark unrecoverably dead dentries") and e5c832d5 ("vfs: fix dentry
RCU to refcounting possibly sleeping dput()")

In fact, that single use was removed less than a week after the whole
function was introduced in commit b3abd802

 ("lockref: add
'lockref_get_or_lock() helper") so this function has been around for a
decade, but only had a user for six days.

Let's just put this mis-designed and unused function out of its misery.

We can think about the naming and semantic oddities of the remaining
'lockref_put_or_lock()' later, but at least that function has users.

And while the naming is different and the return value doesn't match,
that function matches the whole '{atomic,refcount}_dec_and_test()'
pattern much better (ie the magic happens when the count goes down to
zero, not when it is incremented from zero).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'qcom-arm64-fixes-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes

Qualcomm ARM64 DT fixes for v5.19

This removes duplicate includes in the sc7180-trogdor files, which
accidentally ended up disabling nodes intended to be enabled.

It corrects identifiers for CPU6/7 on MSM8994. On SM8450 the UFS node's
interconnects property is updated to match the #interconnect-cells,
avoiding sync_state issues and the GIC ITS is defined, to correct the
references from the PCIe nodes. On SDM845 the display subsystem's AHB
clock is corrected and on msm8992 devices, the supplies for lvs 1 and 2
are correctly specified.

Lastly, a welcome addition of Konrad as reviewer for the Qualcomm SoC.

* tag 'qcom-arm64-fixes-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
  MAINTAINERS: Add myself as a reviewer for Qualcomm ARM/64 support
  arm64: dts: qcom: sdm845: use dispcc AHB clock for mdss node
  arm64: dts: qcom: sm8450 add ITS device tree node
  arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
  arm64: dts: qcom: sm8450: fix interconnects property of UFS node
  arm64: dts: qcom: Remove duplicate sc7180-trogdor include on lazor/homestar

Link: https://lore.kernel.org/r/20220703030208.408109-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The kernel tends to try to avoid conditional locking semantics because
it makes it harder to think about and statically check locking rules,
but we do have a few fundamental locking primitives that take locks
conditionally - most obviously the 'trylock' functions.

That has always been a problem for 'sparse' checking for locking
imbalance, and we've had a special '__cond_lock()' macro that we've used
to let sparse know how the locking works:

    # define __cond_lock(x,c)        ((c) ? ({ __acquire(x); 1; }) : 0)

so that you can then use this to tell sparse that (for example) the
spinlock trylock macro ends up acquiring the lock when it succeeds, but
not when it fails:

    #define raw_spin_trylock(lock)  __cond_lock(lock, _raw_spin_trylock(lock))

and then sparse can follow along the locking rules when you have code like

        if (!spin_trylock(&dentry->d_lock))
                return LRU_SKIP;
	.. sparse sees that the lock is held here..
        spin_unlock(&dentry->d_lock);

and sparse ends up happy about the lock contexts.

However, this '__cond_lock()' use does result in very ugly header files,
and requires you to basically wrap the real function with that macro
that uses '__cond_lock'.  Which has made PeterZ NAK things that try to
fix sparse warnings over the years [1].

To solve this, there is now a very experimental patch to sparse that
basically does the exact same thing as '__cond_lock()' did, but using a
function attribute instead.  That seems to make PeterZ happy [2].

Note that this does not replace existing use of '__cond_lock()', but
only exposes the new proposed attribute and uses it for the previously
unannotated 'refcount_dec_and_lock()' family of functions.

For existing sparse installations, this will make no difference (a
negative output context was ignored), but if you have the experimental
sparse patch it will make sparse now understand code that uses those
functions, the same way '__cond_lock()' makes sparse understand the very
similar 'atomic_dec_and_lock()' uses that have the old '__cond_lock()'
annotations.

Note that in some cases this will silence existing context imbalance
warnings.  But in other cases it may end up exposing new sparse warnings
for code that sparse just didn't see the locking for at all before.

This is a trial, in other words.  I'd expect that if it ends up being
successful, and new sparse releases end up having this new attribute,
we'll migrate the old-style '__cond_lock()' users to use the new-style
'__cond_acquires' function attribute.

The actual experimental sparse patch was posted in [3].

Link: https://lore.kernel.org/all/20130930134434.GC12926@twins.programming.kicks-ass.net/ [1]
Link: https://lore.kernel.org/all/Yr60tWxN4P568x3W@worktop.programming.kicks-ass.net/ [2]
Link: https://lore.kernel.org/all/CAHk-=wjZfO9hGqJ2_hGQG3U_XzSh9_XaXze=HgPdvJbgrvASfA@mail.gmail.com/ [3]
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Alexander Aring <aahringo@redhat.com>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull xfs fixes from Darrick Wong:
 "This fixes some stalling problems and corrects the last of the
  problems (I hope) observed during testing of the new atomic xattr
  update feature.

   - Fix statfs blocking on background inode gc workers

   - Fix some broken inode lock assertion code

   - Fix xattr leaf buffer leaks when cancelling a deferred xattr update
     operation

   - Clean up xattr recovery to make it easier to understand.

   - Fix xattr leaf block verifiers tripping over empty blocks.

   - Remove complicated and error prone xattr leaf block bholding mess.

   - Fix a bug where an rt extent crossing EOF was treated as "posteof"
     blocks and cleaned unnecessarily.

   - Fix a UAF when log shutdown races with unmount"

* tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: prevent a UAF when log IO errors race with unmount
  xfs: dont treat rt extents beyond EOF as eofblocks to be cleared
  xfs: don't hold xattr leaf buffers across transaction rolls
  xfs: empty xattr leaf header blocks are not corruption
  xfs: clean up the end of xfs_attri_item_recover
  xfs: always free xattri_leaf_bp when cancelling a deferred op
  xfs: use invalidate_lock to check the state of mmap_lock
  xfs: factor out the common lock flags assert
  xfs: introduce xfs_inodegc_push()
  xfs: bound maximum wait time for inodegc work

Pull nfsd fixes from Chuck Lever:
 "Notable regression fixes:

   - Fix NFSD crash during NFSv4.2 READ_PLUS operation

   - Fix incorrect status code returned by COMMIT operation"

* tag 'nfsd-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
  SUNRPC: Fix READ_PLUS crasher
  NFSD: restore EINVAL error translation in nfsd_commit()

Pull parisc architecture fixes from Helge Deller:
 "Two important fixes for bugs in code which was added in 5.18:

   - Fix userspace signal failures on 32-bit kernel due to a bug in vDSO

   - Fix 32-bit load-word unalignment exception handler which returned
     wrong values"

* tag 'for-5.19/parisc-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Fix vDSO signal breakage on 32-bit kernel
  parisc/unaligned: Fix emulate_ldw() breakage

Addition of vDSO support for parisc in kernel v5.18 suddenly broke glibc
signal testcases on a 32-bit kernel.

The trampoline code (sigtramp.S) which is mapped into userspace includes
an offset to the context data on the stack, which is used by gdb and
glibc to get access to registers.

In a 32-bit kernel we used by mistake the offset into the compat context
(which is valid on a 64-bit kernel only) instead of the offset into the
"native" 32-bit context.

Reported-by: John David Anglin <dave.anglin@bell.net>
Tested-by: John David Anglin <dave.anglin@bell.net>
Fixes: 	df24e178

 ("parisc: Add vDSO support")
CC: stable@vger.kernel.org # 5.18
Signed-off-by: Helge Deller <deller@gmx.de>

Merge tag 'perf-tools-fixes-for-v5.19-2022-07-02' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

Pull perf tools fixes from Arnaldo Carvalho de Melo:

 - BPF program info linear (BPIL) data is accessed assuming 64-bit
   alignment resulting in undefined behavior as the data is just byte
   aligned. Fix it, Found using -fsanitize=undefined.

 - Fix 'perf offcpu' build on old kernels wrt task_struct's
   state/__state field.

 - Fix perf_event_attr.sample_type setting on the 'offcpu-time' event
   synthesized by the 'perf offcpu' tool.

 - Don't bail out when synthesizing PERF_RECORD_ events for pre-existing
   threads when one goes away while parsing its procfs entries.

 - Don't sort the task scan result from /proc, its not needed and
   introduces bugs when the main thread isn't the first one to be
   processed.

 - Fix uninitialized 'offset' variable on aarch64 in the unwind code.

 - Sync KVM headers with the kernel sources.

* tag 'perf-tools-fixes-for-v5.19-2022-07-02' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
  perf synthetic-events: Ignore dead threads during event synthesis
  perf synthetic-events: Don't sort the task scan result from /proc
  perf unwind: Fix unitialized 'offset' variable on aarch64
  tools headers UAPI: Sync linux/kvm.h with the kernel sources
  perf bpf: 8 byte align bpil data
  tools kvm headers arm64: Update KVM headers from the kernel sources
  perf offcpu: Accept allowed sample types only
  perf offcpu: Fix build failure on old kernels

Pull powerpc fixes from Michael Ellerman:

 - Fix BPF uapi confusion about the correct type of bpf_user_pt_regs_t.

 - Fix virt_addr_valid() when memory is hotplugged above the boot-time
   high_memory value.

 - Fix a bug in 64-bit Book3E map_kernel_page() which would incorrectly
   allocate a PMD page at PUD level.

 - Fix a couple of minor issues found since we enabled KASAN for 64-bit
   Book3S.

Thanks to Aneesh Kumar K.V, Cédric Le Goater, Christophe Leroy, Kefeng
Wang, Liam Howlett, Nathan Lynch, and Naveen N. Rao.

* tag 'powerpc-5.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/memhotplug: Add add_pages override for PPC
  powerpc/bpf: Fix use of user_pt_regs in uapi
  powerpc/prom_init: Fix kernel config grep
  powerpc/book3e: Fix PUD allocation size in map_kernel_page()
  powerpc/xive/spapr: correct bitmap allocation size

When it synthesize various task events, it scans the list of task
first and then accesses later.  There's a window threads can die
between the two and proc entries may not be available.

Instead of bailing out, we can ignore that thread and move on.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20220701205458.985106-2-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

It should not sort the result as procfs already returns a proper
ordering of tasks.  Actually sorting the order caused problems that it
doesn't guararantee to process the main thread first.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20220701205458.985106-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Commit dc2cf4ca ("perf unwind: Fix segbase for ld.lld linked
objects") uncovered the following issue on aarch64:

    util/unwind-libunwind-local.c: In function 'find_proc_info':
    util/unwind-libunwind-local.c:386:28: error: 'offset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    386 |                         if (ofs > 0) {
        |                            ^
    util/unwind-libunwind-local.c:199:22: note: 'offset' was declared here
    199 |         u64 address, offset;
        |                      ^~~~~~
    util/unwind-libunwind-local.c:371:20: error: 'offset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    371 |                 if (ofs <= 0) {
        |                    ^
    util/unwind-libunwind-local.c:199:22: note: 'offset' was declared here
    199 |         u64 address, offset;
        |                      ^~~~~~
    util/unwind-libunwind-local.c:363:20: error: 'offset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    363 |                 if (ofs <= 0) {
        |                    ^
    util/unwind-libunwind-local.c:199:22: note: 'offset' was declared here
    199 |         u64 address, offset;
        |                      ^~~~~~
    In file included from util/libunwind/arm64.c:37:

Fixes: dc2cf4ca

 ("perf unwind: Fix segbase for ld.lld linked objects")
Signed-off-by: Ivan Babrou <ivan@cloudflare.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: James Clark <james.clark@arm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: kernel-team@cloudflare.com
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20220701182046.12589-1-ivan@cloudflare.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Pull libnvdimm fix from Vishal Verma:

 - Fix a bug in the libnvdimm 'BTT' (Block Translation Table) driver
   where accounting for poison blocks to be cleared was off by one,
   causing a failure to clear the the last badblock in an nvdimm region.

* tag 'libnvdimm-fixes-5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  nvdimm: Fix badblocks clear off-by-one error

Merge tag 'amlogic-arm-for-v5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into arm/fixes

Amlogic ARM mach-meson changes for v5.20:
- Fix refcount leak in meson_smp_prepare_cpus

* tag 'amlogic-arm-for-v5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux:
  ARM: meson: Fix refcount leak in meson_smp_prepare_cpus

Link: https://lore.kernel.org/r/cbf6bcb5-c7be-40fe-4436-4578c9d6c532@baylibre.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'scmi-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes

Arm SCMI firmware driver fixes for v5.19

Few more fixes to address:
1. Issue reported on Juno with HDLCD clock which turned out to be yet
   another firmware issue. The firmware is not conformant to the spec and
   we now have to workaround as this may be copied to other platforms as
   well. The spec expects to return size of 3 for a range clock rate
   description while the firmware returns 1. We have other ways to validate
   all the 3 entries the driver reads are polpulated and we use the same
   to workaround this firmware bug.

2. Optee transport not setting the correct reponse length which is similar
   to the one reported earlier on Rockchip platform.

3. Drop the usage of the deprecated ida_simple_{get,remove} and migrate to the
   ida_{alloc,free}

* tag 'scmi-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API
  firmware: arm_scmi: Fix response size warning for OPTEE transport
  firmware: arm_scmi: Relax CLOCK_DESCRIBE_RATES out-of-spec checks

Link: https://lore.kernel.org/r/20220628133315.699803-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Pull thermal control fix from Rafael Wysocki:
 "Add a new CPU ID to the list of supported processors in the
  intel_tcc_cooling driver (Sumeet Pawnikar)"

* tag 'thermal-5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  thermal: intel_tcc_cooling: Add TCC cooling support for RaptorLake

Pull power management fixes from Rafael Wysocki:
 "These fix some issues in cpufreq drivers and some issues in devfreq:

   - Fix error code path issues related PROBE_DEFER handling in devfreq
     (Christian Marangi)

   - Revert an editing accident in SPDX-License line in the devfreq
     passive governor (Lukas Bulwahn)

   - Fix refcount leak in of_get_devfreq_events() in the exynos-ppmu
     devfreq driver (Miaoqian Lin)

   - Use HZ_PER_KHZ macro in the passive devfreq governor (Yicong Yang)

   - Fix missing of_node_put for qoriq and pmac32 driver (Liang He)

   - Fix issues around throttle interrupt for qcom driver (Stephen Boyd)

   - Add MT8186 to cpufreq-dt-platdev blocklist (AngeloGioacchino Del
     Regno)

   - Make amd-pstate enable CPPC on resume from S3 (Jinzhou Su)"

* tag 'pm-5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM / devfreq: passive: revert an editing accident in SPDX-License line
  PM / devfreq: Fix kernel warning with cpufreq passive register fail
  PM / devfreq: Rework freq_table to be local to devfreq struct
  PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events
  PM / devfreq: passive: Use HZ_PER_KHZ macro in units.h
  PM / devfreq: Fix cpufreq passive unregister erroring on PROBE_DEFER
  PM / devfreq: Mute warning on governor PROBE_DEFER
  PM / devfreq: Fix kernel panic with cpu based scaling to passive gov
  cpufreq: Add MT8186 to cpufreq-dt-platdev blocklist
  cpufreq: pmac32-cpufreq: Fix refcount leak bug
  cpufreq: qcom-hw: Don't do lmh things without a throttle interrupt
  drivers: cpufreq: Add missing of_node_put() in qoriq-cpufreq.c
  cpufreq: amd-pstate: Add resume and suspend callbacks

Merge cpufreq fixes for 5.19-rc5, including ARM cpufreq fixes and the
following one:

 - Make amd-pstate enable CPPC on resume from S3 (Jinzhou Su).

* pm-cpufreq:
  cpufreq: Add MT8186 to cpufreq-dt-platdev blocklist
  cpufreq: pmac32-cpufreq: Fix refcount leak bug
  cpufreq: qcom-hw: Don't do lmh things without a throttle interrupt
  drivers: cpufreq: Add missing of_node_put() in qoriq-cpufreq.c
  cpufreq: amd-pstate: Add resume and suspend callbacks

Merge tag 'hwmon-for-v5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

Pull hwmon fixes from Guenter Roeck:

 - Fix error handling in ibmaem driver initialization

 - Fix bad data reported by occ driver after setting power cap

 - Fix typos in pmbus/ucd9200 driver comments

* tag 'hwmon-for-v5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (ibmaem) don't call platform_device_del() if platform_device_add() fails
  hwmon: (pmbus/ucd9200) fix typos in comments
  hwmon: (occ) Prevent power cap command overwriting poll response

If platform_device_add() fails, it no need to call platform_device_del(), split
platform_device_unregister() into platform_device_del/put(), so platform_device_put()
can be called separately.

Fixes: 8808a793

 ("ibmaem: new driver for power/energy/temp meters in IBM System X hardware")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220701074153.4021556-1-yangyingliang@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Pull arm64 fix from Catalin Marinas:
 "Restore TLB invalidation for the 'break-before-make' rule on
  contiguous ptes (missed in a recent clean-up)"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: hugetlb: Restore TLB invalidation for BBM on contiguous ptes