Pull gpio fixes from Bartosz Golaszewski:

 - fix a NULL-pointer dereference at driver unbind and a potential
   resource leak in error path in gpio-mockup

 - make the irqchip immutable in gpio-ftgpio010

 - fix dereferencing a potentially uninitialized variable in gpio-tqmx86

 - fix interrupt registering in gpiolib's character device code

* tag 'gpio-fixes-for-v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
  gpio: tqmx86: fix uninitialized variable girq
  gpio: ftgpio010: Make irqchip immutable
  gpio: mockup: Fix potential resource leakage when register a chip
  gpio: mockup: fix NULL pointer dereference when removing debugfs

Merge tag 'perf-tools-fixes-for-v6.0-2022-09-21' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

Pull perf tools fixes from Arnaldo Carvalho de Melo:

 - Fix polling of system-wide events related to mixing per-cpu and
   per-thread events.

 - Do not check if /proc/modules is unchanged when copying /proc/kcore,
   that doesn't get in the way of post processing analysis.

 - Include program header in ELF files generated for JIT files, so that
   they can be opened by tools using elfutils libraries.

 - Enter namespaces when synthesizing build-ids.

 - Fix some bugs related to a recent cpu_map overhaul where we should be
   using an index and not the cpu number.

 - Fix BPF program ELF section name, using the naming expected by libbpf
   when using BPF counters in 'perf stat'.

 - Add a new test for perf stat cgroup BPF counter.

 - Adjust check on 'perf test wp' for older kernels, where the
   PERF_EVENT_IOC_MODIFY_ATTRIBUTES ioctl isn't supported.

 - Sync x86 cpufeatures with the kernel sources, no changes in tooling.

* tag 'perf-tools-fixes-for-v6.0-2022-09-21' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
  perf tools: Honor namespace when synthesizing build-ids
  tools headers cpufeatures: Sync with the kernel sources
  perf kcore_copy: Do not check /proc/modules is unchanged
  libperf evlist: Fix polling of system-wide events
  perf record: Fix cpu mask bit setting for mixed mmaps
  perf test: Skip wp modify test on old kernels
  perf jit: Include program header in ELF files
  perf test: Add a new test for perf stat cgroup BPF counter
  perf stat: Use evsel->core.cpus to iterate cpus in BPF cgroup counters
  perf stat: Fix cpu map index in bperf cgroup code
  perf stat: Fix BPF program section name

It needs to enter the namespace before reading a file.

Fixes: 4183a8d7 ("perf tools: Allow synthesizing the build id for kernel/modules/tasks in PERF_RECORD_MMAP2")
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20220920222822.2171056-1-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

To pick the changes from:

  7df54884 ("x86/bugs: Add "unknown" reporting for MMIO Stale Data")

This only causes these perf files to be rebuilt:

  CC       /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
  CC       /tmp/build/perf/bench/mem-memset-x86-64-asm.o

And addresses this perf build warning:

  Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h'
  diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Link: https://lore.kernel.org/lkml/YysTRji90sNn2p5f@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

/proc/kallsyms and /proc/modules are compared before and after the copy
in order to ensure no changes during the copy.

However /proc/modules also might change due to reference counts changing
even though that does not make any difference.

Any modules loaded or unloaded should be visible in changes to kallsyms,
so it is not necessary to check /proc/modules also anyway.

Remove the comparison checking that /proc/modules is unchanged.

Fixes: fc1b691d ("perf buildid-cache: Add ability to add kcore to the cache")
Reported-by: NDaniel Dao <dqminh@cloudflare.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NDaniel Dao <dqminh@cloudflare.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/r/20220914122429.8770-1-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Originally, (refer commit f90d194a ("perf evlist: Do not poll
events that use the system_wide flag") there wasn't much reason to poll
system-wide events because:

 1. The mmaps get "merged" via set-output anyway (the per-cpu case)
 2. perf reads all mmaps when any event is woken
 3. system-wide mmaps do not fill up as fast as the mmaps for user
    selected events

But there was 1 reason not to poll which was that it prevented correct
termination due to POLLHUP on all user selected events.  That issue is
now easily resolved by using fdarray_flag__nonfilterable.

With the advent of commit ae4f8ae1 ("libperf evlist: Allow
mixing per-thread and per-cpu mmaps"), system-wide mmaps can be used
also in the per-thread case where reason 1 does not apply.

Fix the omission of system-wide events from polling by using the
fdarray_flag__nonfilterable flag.

Example:

 Before:

    $ perf record --no-bpf-event -vvv -e intel_pt// --per-thread uname 2>err.txt
    Linux
    $ grep 'sys_perf_event_open.*=\|pollfd' err.txt
    sys_perf_event_open: pid 155076  cpu -1  group_fd -1  flags 0x8 = 5
    sys_perf_event_open: pid 155076  cpu -1  group_fd -1  flags 0x8 = 6
    sys_perf_event_open: pid -1  cpu 0  group_fd -1  flags 0x8 = 7
    sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8 = 9
    sys_perf_event_open: pid -1  cpu 2  group_fd -1  flags 0x8 = 10
    sys_perf_event_open: pid -1  cpu 3  group_fd -1  flags 0x8 = 11
    sys_perf_event_open: pid -1  cpu 4  group_fd -1  flags 0x8 = 12
    sys_perf_event_open: pid -1  cpu 5  group_fd -1  flags 0x8 = 13
    sys_perf_event_open: pid -1  cpu 6  group_fd -1  flags 0x8 = 14
    sys_perf_event_open: pid -1  cpu 7  group_fd -1  flags 0x8 = 15
    thread_data[0x55fb43c29e80]: pollfd[0] <- event_fd=5
    thread_data[0x55fb43c29e80]: pollfd[1] <- event_fd=6
    thread_data[0x55fb43c29e80]: pollfd[2] <- non_perf_event fd=4

 After:

    $ perf record --no-bpf-event -vvv -e intel_pt// --per-thread uname 2>err.txt
    Linux
    $ grep 'sys_perf_event_open.*=\|pollfd' err.txt
    sys_perf_event_open: pid 156316  cpu -1  group_fd -1  flags 0x8 = 5
    sys_perf_event_open: pid 156316  cpu -1  group_fd -1  flags 0x8 = 6
    sys_perf_event_open: pid -1  cpu 0  group_fd -1  flags 0x8 = 7
    sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8 = 9
    sys_perf_event_open: pid -1  cpu 2  group_fd -1  flags 0x8 = 10
    sys_perf_event_open: pid -1  cpu 3  group_fd -1  flags 0x8 = 11
    sys_perf_event_open: pid -1  cpu 4  group_fd -1  flags 0x8 = 12
    sys_perf_event_open: pid -1  cpu 5  group_fd -1  flags 0x8 = 13
    sys_perf_event_open: pid -1  cpu 6  group_fd -1  flags 0x8 = 14
    sys_perf_event_open: pid -1  cpu 7  group_fd -1  flags 0x8 = 15
    thread_data[0x55cc19e58e80]: pollfd[0] <- event_fd=5
    thread_data[0x55cc19e58e80]: pollfd[1] <- event_fd=6
    thread_data[0x55cc19e58e80]: pollfd[2] <- event_fd=7
    thread_data[0x55cc19e58e80]: pollfd[3] <- event_fd=9
    thread_data[0x55cc19e58e80]: pollfd[4] <- event_fd=10
    thread_data[0x55cc19e58e80]: pollfd[5] <- event_fd=11
    thread_data[0x55cc19e58e80]: pollfd[6] <- event_fd=12
    thread_data[0x55cc19e58e80]: pollfd[7] <- event_fd=13
    thread_data[0x55cc19e58e80]: pollfd[8] <- event_fd=14
    thread_data[0x55cc19e58e80]: pollfd[9] <- event_fd=15
    thread_data[0x55cc19e58e80]: pollfd[10] <- non_perf_event fd=4

Fixes: ae4f8ae1 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220915122612.81738-3-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

With mixed per-thread and (system-wide) per-cpu maps, the "any cpu" value
 -1 must be skipped when setting CPU mask bits.

Prior to commit cbd7bfc7 ("tools/perf: Fix out of bound access
to cpu mask array") the invalid setting went unnoticed, but since then
it causes perf record to fail with an error.

Example:

 Before:

   $ perf record -e intel_pt// --per-thread uname
   Failed to initialize parallel data streaming masks

 After:

   $ perf record -e intel_pt// --per-thread uname
   Linux
   [ perf record: Woken up 1 times to write data ]
   [ perf record: Captured and wrote 0.068 MB perf.data ]

Fixes: ae4f8ae1 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220915122612.81738-2-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It uses PERF_EVENT_IOC_MODIFY_ATTRIBUTES ioctl.	 The kernel would return
ENOTTY if it's not supported.  Update the skip reason in that case.

Committer notes:

On s/390 the args aren't used, so need to be marked __maybe_unused.
Reviewed-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Link: https://lore.kernel.org/r/20220914183338.546357-1-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Pull UML fixes from Richard Weinberger:

 - Various fixes for build warnings

 - Fix default kernel command line

* tag 'for-linus-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux:
  arch: um: Mark the stack non-executable to fix a binutils warning
  um: Prevent KASAN splats in dump_stack()
  um: fix default console kernel parameter
  um: Cleanup compiler warning in arch/x86/um/tls_32.c
  um: Cleanup syscall_handler_t cast in syscalls_32.h

Pull MIPS fixes from Thomas Bogendoerfer:

 - fix missing export for Lantiq watchdog driver

 - fix ethernet phy interface setup for Loongson32

* tag 'mips-fixes_6.0_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  MIPS: Loongson32: Fix PHY-mode being left unspecified
  MIPS: lantiq: export clk_get_io() for lantiq_wdt.ko

Pull dmaengine fixes from Vinod Koul:
 "A couple of small driver fixes:

   - xilinx_dma: devm_platform_ioremap_resource error handling,
     dma_set_mask_and_coherent failure handling, dt property read
     cleanup

   - refcount leak fix for of_xudma_dev_get()

   - zynqmp_dma: coverity fix for enum typecast"

* tag 'dmaengine-fix-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine:
  dmaengine: zynqmp_dma: Typecast with enum to fix the coverity warning
  dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()
  dmaengine: xilinx_dma: Report error in case of dma_set_mask_and_coherent API failure
  dmaengine: xilinx_dma: cleanup for fetching xlnx,num-fstores property
  dmaengine: xilinx_dma: Fix devm_platform_ioremap_resource error handling

Pull iommu fixes from Joerg Roedel:
 "Two fixes for Intel VT-d:

   - Check the right capability bit for 5-level page table support.

   - Revert a previous fix which caused a regression with Thunderbolt
     devices"

* tag 'iommu-fixes-v6.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/vt-d: Check correct capability for sagaw determination
  Revert "iommu/vt-d: Fix possible recursive locking in intel_iommu_init()"

Pull sound fixes from Takashi Iwai:
 "A bit more changes than wished, but still manageable amount.

  Most of commits are HD-audio specific device fixes / quirks, while
  there is a revert for the previous fix due to regressions and a
  double-free fix in ALSA core code"

* tag 'sound-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  Revert "ALSA: usb-audio: Split endpoint setups for hw_params and prepare"
  ALSA: core: Fix double-free at snd_card_new()
  ALSA: hda/realtek: Add a quirk for HP OMEN 16 (8902) mute LED
  ALSA: hda/hdmi: Fix the converter reuse for the silent stream
  ALSA: hda/realtek: Add quirk for ASUS GA503R laptop
  ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack
  ALSA: hda/realtek: Add pincfg for ASUS G513 HP jack
  ALSA: hda/realtek: Re-arrange quirk table entries
  ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptop
  ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5570 laptop
  ALSA: hda: Fix Nvidia dp infoframe
  ALSA: hda/realtek: Add quirk for Huawei WRT-WX9
  ALSA: hda/tegra: set depop delay for tegra
  ALSA: hda: add Intel 5 Series / 3400 PCI DID
  ALSA: hda: Fix hang at HD-audio codec unbinding due to refcount saturation

Pull exfat fix from Namjae Jeon:

 - fix integer overflow on large partitions

* tag 'exfat-for-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat:
  exfat: fix overflow for large capacity partition

The missing header makes it hard for programs like elfutils to open
these files.

Fixes: 2d86612a ("perf symbol: Correct address for bss symbols")
Reviewed-by: NLeo Yan <leo.yan@linaro.org>
Signed-off-by: NLieven Hey <lieven.hey@kdab.com>
Tested-by: NLeo Yan <leo.yan@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Link: https://lore.kernel.org/r/20220915092910.711036-1-lieven.hey@kdab.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

  $ sudo ./perf test -v each-cgroup
   96: perf stat --bpf-counters --for-each-cgroup test                 :
  --- start ---
  test child forked, pid 79600
  test child finished with 0
  ---- end ----
  perf stat --bpf-counters --for-each-cgroup test: Ok
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: bpf@vger.kernel.org
Link: https://lore.kernel.org/r/20220916184132.1161506-5-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

If it mixes core and uncore events, each evsel would have different cpu map.
But it assumed they are same with evlist's all_cpus and accessed by the same
index.  This resulted in a crash like below.

  $ perf stat -a --bpf-counters --for-each_cgroup ^. -e cycles,imc/cas_count_read/ sleep 1
  Segmentation fault

While it's not recommended to use uncore events for cgroup aggregation, it
should not crash.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: bpf@vger.kernel.org
Link: https://lore.kernel.org/r/20220916184132.1161506-4-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The previous cpu map introduced a bug in the bperf cgroup counter.  This
results in a failure when user gives a partial cpu map starting from
non-zero.

  $ sudo ./perf stat -C 1-2 --bpf-counters --for-each-cgroup ^. sleep 1
  libbpf: prog 'on_cgrp_switch': failed to create BPF link for perf_event FD 0:
                                 -9 (Bad file descriptor)
  Failed to attach cgroup program

To get the FD of an evsel, it should use a map index not the CPU number.

Fixes: 0255571a ("perf cpumap: Switch to using perf_cpu_map API")
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: bpf@vger.kernel.org
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/r/20220916184132.1161506-3-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It seems the recent libbpf got more strict about the section name.
I'm seeing a failure like this:

  $ sudo ./perf stat -a --bpf-counters --for-each-cgroup ^. sleep 1
  libbpf: prog 'on_cgrp_switch': missing BPF prog type, check ELF section name 'perf_events'
  libbpf: prog 'on_cgrp_switch': failed to load: -22
  libbpf: failed to load object 'bperf_cgroup_bpf'
  libbpf: failed to load BPF skeleton 'bperf_cgroup_bpf': -22
  Failed to load cgroup skeleton

The section name should be 'perf_event' (without the trailing 's').
Although it's related to the libbpf change, it'd be better fix the
section name in the first place.

Fixes: 944138f0 ("perf stat: Enable BPF counter with --for-each-cgroup")
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: bpf@vger.kernel.org
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/r/20220916184132.1161506-2-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Check 5-level paging capability for 57 bits address width instead of
checking 1GB large page capability.

Fixes: 53fc7ad6 ("iommu/vt-d: Correctly calculate sagaw value of IOMMU")
Cc: stable@vger.kernel.org
Reported-by: NRaghunathan Srinivasan <raghunathan.srinivasan@intel.com>
Signed-off-by: NYi Liu <yi.l.liu@intel.com>
Reviewed-by: NJerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: NKevin Tian <kevin.tian@intel.com>
Reviewed-by: NRaghunathan Srinivasan <raghunathan.srinivasan@intel.com>
Link: https://lore.kernel.org/r/20220916071212.2223869-2-yi.l.liu@intel.comSigned-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

This reverts commit 9cd4f143.

Some issues were reported on the original commit. Some thunderbolt devices
don't work anymore due to the following DMA fault.

DMAR: DRHD: handling fault status reg 2
DMAR: [INTR-REMAP] Request device [09:00.0] fault index 0x8080
      [fault reason 0x25]
      Blocked a compatibility format interrupt request

Bring it back for now to avoid functional regression.

Fixes: 9cd4f143 ("iommu/vt-d: Fix possible recursive locking in intel_iommu_init()")
Link: https://lore.kernel.org/linux-iommu/485A6EA5-6D58-42EA-B298-8571E97422DE@getmailspring.com/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216497
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: <stable@vger.kernel.org> # 5.19.x
Reported-and-tested-by: NGeorge Hilliard <thirtythreeforty@gmail.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20220920081701.3453504-1-baolu.lu@linux.intel.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>

When running gpio test on nxp-ls1028 platform with below command
gpiomon --num-events=3 --rising-edge gpiochip1 25
There will be a warning trace as below:
Call trace:
free_irq+0x204/0x360
lineevent_free+0x64/0x70
gpio_ioctl+0x598/0x6a0
__arm64_sys_ioctl+0xb4/0x100
invoke_syscall+0x5c/0x130
......
el0t_64_sync+0x1a0/0x1a4
The reason of this issue is that calling request_threaded_irq()
function failed, and then lineevent_free() is invoked to release
the resource. Since the lineevent_state::irq was already set, so
the subsequent invocation of free_irq() would trigger the above
warning call trace. To fix this issue, set the lineevent_state::irq
after the IRQ register successfully.

Fixes: 46824272 ("gpiolib: cdev: refactor lineevent cleanup into lineevent_free")
Cc: stable@vger.kernel.org
Signed-off-by: NMeng Li <Meng.Li@windriver.com>
Reviewed-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

The commit 92461060 ("gpio: tpmx86: Move PM device over to
irq domain") adds a dereference of girq that may be uninitialized.

Fix this by moving irq_domain_set_pm_device into if true branch
as suggested by Marc Zyngier.

Fixes: 92461060 ("gpio: tpmx86: Move PM device over to irq domain")
Suggested-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NDongliang Mu <mudongliangabcd@gmail.com>
Acked-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Since binutils 2.39, ld will print a warning if any stack section is
executable, which is the default for stack sections on files without a
.note.GNU-stack section.

This was fixed for x86 in commit ffcf9c57 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"),
but remained broken for UML, resulting in several warnings:

/usr/bin/ld: warning: arch/x86/um/vdso/vdso.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/usr/bin/ld: warning: .tmp_vmlinux.kallsyms1 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: .tmp_vmlinux.kallsyms1.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/usr/bin/ld: warning: .tmp_vmlinux.kallsyms2 has a LOAD segment with RWX permissions
/usr/bin/ld: warning: .tmp_vmlinux.kallsyms2.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/usr/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions

Link both the VDSO and vmlinux with -z noexecstack, fixing the warnings
about .note.GNU-stack sections. In addition, pass --no-warn-rwx-segments
to dodge the remaining warnings about LOAD segments with RWX permissions
in the kallsyms objects. (Note that this flag is apparently not
available on lld, so hide it behind a test for BFD, which is what the
x86 patch does.)

Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107Signed-off-by: NDavid Gow <davidgow@google.com>
Reviewed-by: NLukas Straub <lukasstraub2@web.de>
Tested-by: NLukas Straub <lukasstraub2@web.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: NRichard Weinberger <richard@nod.at>

Pull btrfs fixes from David Sterba:

 - two fixes for hangs in the umount sequence where threads depend on
   each other and the work must be finished in the right order

 - in zoned mode, wait for flushing all block group metadata IO before
   finishing the zone

* tag 'for-6.0-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: zoned: wait for extent buffer IOs before finishing a zone
  btrfs: fix hang during unmount when stopping a space reclaim worker
  btrfs: fix hang during unmount when stopping block group reclaim worker

Pull vfs fix from Christian Brauner:
 "Beginning of the merge window we introduced the vfs{g,u}id_t types in
  b27c82e1 ("attr: port attribute changes to new types") and changed
  various codepaths over including chown_common().

  When userspace passes -1 for an ownership change the ownership fields
  in struct iattr stay uninitialized. Usually this is fine because any
  code making use of any fields in struct iattr must check the
  ->ia_valid field whether the value of interest has been initialized.
  That's true for all struct iattr passing code.

  However, over the course of the last year with more heavy use of KMSAN
  we found quite a few places that got this wrong. A recent one I fixed
  was 3cb6ee99 ("9p: only copy valid iattrs in 9P2000.L setattr
  implementation").

  But we also have LSM hooks. Actually we have two. The first one is
  security_inode_setattr() in notify_change() which does the right thing
  and passes the full struct iattr down to LSMs and thus LSMs can check
  whether it is initialized.

  But then we also have security_path_chown() which passes down a path
  argument and the target ownership as the filesystem would see it. For
  the latter we now generate the target values based on struct iattr and
  pass it down. However, when userspace passes -1 then struct iattr
  isn't initialized.

  This patch simply initializes ->ia_vfs{g,u}id with INVALID_VFS{G,U}ID
  so the hook continue to see invalid ownership when -1 is passed from
  userspace. The only LSM that cares about the actual values is Tomoyo.

  The vfs codepaths don't look at these fields without ->ia_valid being
  set so there's no harm in initializing ->ia_vfs{g,u}id. Arguably this
  is also safer since we can't end up copying valid ownership values
  when invalid ownership values should be passed.

  This only affects mainline. No kernel has been released with this and
  thus no backport is needed. The commit is thus marked with a Fixes:
  tag but annotated with "# mainline only" (I didn't quite remember what
  Greg said about how to tell stable autoselect to not bother with fixes
  for mainline only)"

* tag 'fs.fixes.v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping:
  open: always initialize ownership fields

Pull execve reverts from Kees Cook:
 "The recent work to support time namespace unsharing turns out to have
  some undesirable corner cases, so rather than allowing the API to stay
  exposed for another release, it'd be best to remove it ASAP, with the
  replacement getting another cycle of testing. Nothing is known to use
  this yet, so no userspace breakage is expected.

  For more details, see:

    https://lore.kernel.org/lkml/ed418e43ad28b8688cfea2b7c90fce1c@ispras.ru

  Summary:

   - Remove the recent 'unshare time namespace on vfork+exec' feature
     (Andrei Vagin)"

* tag 'execve-v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  Revert "fs/exec: allow to unshare a time namespace on vfork+exec"
  Revert "selftests/timens: add a test for vfork+exit"

This turns the FTGPIO010 irqchip immutable.

Tested on the D-Link DIR-685.

Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

If creation of software node fails, the locally allocated string
array is left unfreed. Free it on error path.

Fixes: 6fda593f ("gpio: mockup: Convert to use software nodes")
Cc: stable@vger.kernel.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

We now remove the device's debugfs entries when unbinding the driver.
This now causes a NULL-pointer dereference on module exit because the
platform devices are unregistered *after* the global debugfs directory
has been recursively removed. Fix it by unregistering the devices first.

Fixes: 303e6da9 ("gpio: mockup: remove gpio debugfs when remove device")
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

This reverts commit ff878b40.

Unfortunately the recent fix seems bringing another regressions with
PulseAudio / pipewire, at least for Steinberg and MOTU devices.

As a temporary solution, do a straight revert.  The issue for Android
will be revisited again later by another different fix (if any).

Fixes: ff878b40 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920113929.25162-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Beginning of the merge window we introduced the vfs{g,u}id_t types in
b27c82e1 ("attr: port attribute changes to new types") and changed
various codepaths over including chown_common().

During that change we forgot to account for the case were the passed
ownership value is -1. In this case the ownership fields in struct iattr
aren't initialized but we rely on them being initialized by the time we
generate the ownership to pass down to the LSMs. All the major LSMs
don't care about the ownership values at all. Only Tomoyo uses them and
so it took a while for syzbot to unearth this issue.

Fix this by initializing the ownership fields and do it within the
retry_deleg block. While notify_change() doesn't alter the ownership
fields currently we shouldn't rely on it.

Since no kernel has been released with these changes this does not
needed to be backported to any stable kernels.

[Christian Brauner (Microsoft) <brauner@kernel.org>]
* rewrote commit message
* use INVALID_VFS{G,U}ID macros

Fixes: b27c82e1 ("attr: port attribute changes to new types") # mainline only
Reported-and-tested-by: syzbot+541e21dcc32c4046cba9@syzkaller.appspotmail.com
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: NSeth Forshee (DigitalOcean) <sforshee@kernel.org>
Signed-off-by: NChristian Brauner (Microsoft) <brauner@kernel.org>

Use READ_ONCE_NOCHECK() when reading the stack to prevent KASAN splats
when dump_stack() is used.

Fixes: 5b301409 ("UML: add support for KASAN under x86_64")
Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
Reviewed-by: NDmitry Vyukov <dvyukov@google.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

OpenWrt's UML with 5.15 was producing odd errors/warnings during preinit
part of the early userspace portion:

|[    0.000000] Kernel command line: ubd0=root.img root=98:0 console=tty
|[...]
|[    0.440000] random: jshn: uninitialized urandom read (4 bytes read)
|[    0.460000] random: jshn: uninitialized urandom read (4 bytes read)
|/etc/preinit: line 47: can't create /dev/tty: No such device or address
|/etc/preinit: line 48: can't create /dev/tty: No such device or address
|/etc/preinit: line 58: can't open /dev/tty: No such device or address
|[...] repeated many times

That "/dev/tty" came from the command line (which is automatically
added if no console= parameter was specified for the uml binary).

The TLDP project tells the following about the /dev/tty:
<https://tldp.org/HOWTO/Text-Terminal-HOWTO-7.html#ss7.3>
| /dev/tty stands for the controlling terminal (if any) for the current
| process.[...]
| /dev/tty is something like a link to the actually terminal device[..]

The "(if any)" is important here, since it's possible for processes to
not have a controlling terminal.

I think this was a simple typo and the author wanted tty0 there.

CC: Thomas Meyer <thomas@m3y3r.de>
Fixes: d7ffac33 ("um: stdio_console: Make preferred console")
Signed-off-by: NChristian Lamparter <chunkeey@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

arch.tls_array is statically allocated so checking for NULL doesn't
make sense. This causes the compiler warning below.

Remove the checks to silence these warnings.

../arch/x86/um/tls_32.c: In function 'get_free_idx':
../arch/x86/um/tls_32.c:68:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress]
   68 |         if (!t->arch.tls_array)
      |             ^
In file included from ../arch/x86/um/asm/processor.h:10,
                 from ../include/linux/rcupdate.h:30,
                 from ../include/linux/rculist.h:11,
                 from ../include/linux/pid.h:5,
                 from ../include/linux/sched.h:14,
                 from ../arch/x86/um/tls_32.c:7:
../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here
   22 |         struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES];
      |                               ^~~~~~~~~
../arch/x86/um/tls_32.c: In function 'get_tls_entry':
../arch/x86/um/tls_32.c:243:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress]
  243 |         if (!t->arch.tls_array)
      |             ^
../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here
   22 |         struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES];
      |                               ^~~~~~~~~
Signed-off-by: NLukas Straub <lukasstraub2@web.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: NRichard Weinberger <richard@nod.at>

Like in f4f03f29
"um: Cleanup syscall_handler_t definition/cast, fix warning",
remove the cast to to fix the compiler warning.
Signed-off-by: NLukas Straub <lukasstraub2@web.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: NRichard Weinberger <richard@nod.at>

commit 0060c878 ("net: stmmac: implement support for passive mode
converters via dt") has changed the plat->interface field semantics from
containing the PHY-mode to specifying the MAC-PCS interface mode. Due to
that the loongson32 platform code will leave the phylink interface
uninitialized with the PHY-mode intended by the means of the actual
platform setup. The commit-author most likely has just missed the
arch-specific code to fix. Let's mend the Loongson32 platform code then by
assigning the PHY-mode to the phy_interface field of the STMMAC platform
data.

Fixes: 0060c878 ("net: stmmac: implement support for passive mode converters via dt")
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: NKeguang Zhang <keguang.zhang@gmail.com>
Tested-by: NKeguang Zhang <keguang.zhang@gmail.com>
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>

The lantiq WDT driver uses clk_get_io(), which is not exported,
so export it to fix a build error:

ERROR: modpost: "clk_get_io" [drivers/watchdog/lantiq_wdt.ko] undefined!

Fixes: 287e3f3f ("MIPS: lantiq: implement support for clkdev api")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: John Crispin <john@phrozen.org>
Cc: linux-mips@vger.kernel.org
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>

During the code change to add the support for devres-managed card
instance, we put an explicit kfree(card) call at the error path in
snd_card_new().  This is needed for the early error path before the
card is initialized with the device, but is rather superfluous and
causes a double-free at the error path after the card instance is
initialized, as the destructor of the card object already contains a
kfree() call.

This patch fixes the double-free situation by removing the superfluous
kfree().  Meanwhile we need to call kfree() explicitly for the early
error path, so it's added there instead.

Fixes: e8ad415b ("ALSA: core: Add managed card creation")
Reported-by: NRondreis <linhaoguo86@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAB7eexL1zBnB636hwS27d-LdPYZ_R1-5fJS_h=ZbCWYU=UPWJg@mail.gmail.com
Link: https://lore.kernel.org/r/20220919123516.28222-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>

Similair to the HP OMEN 15, the HP OMEN 16 also needs
ALC285_FIXUP_HP_MUTE_LED for the mute LED to work.

[ Rearranged the entry in PCI SSID order by tiwai ]
Signed-off-by: NDaniel Houldsworth <dhould3@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220918171300.24693-1-dhould3@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>