óÐÉÓÏË ÉÚÍÅÎÅÎÉÊ × Linux 6.4.16

 
9p: virtio: fix unlikely null pointer deref in handle_rerror [+ + +]
Author: Dominique Martinet <asmadeus@codewreck.org>
Date:   Wed May 3 16:49:26 2023 +0900

    9p: virtio: fix unlikely null pointer deref in handle_rerror
    
    [ Upstream commit 13ade4ac5c28e8a014fa85278f5a4270b215f906 ]
    
    handle_rerror can dereference the pages pointer, but it is not
    necessarily set for small payloads.
    In practice these should be filtered out by the size check, but
    might as well double-check explicitly.
    
    This fixes the following scan-build warnings:
    net/9p/trans_virtio.c:401:24: warning: Dereference of null pointer [core.NullDereference]
                    memcpy_from_page(to, *pages++, offs, n);
                                         ^~~~~~~~
    net/9p/trans_virtio.c:406:23: warning: Dereference of null pointer (loaded from variable 'pages') [core.NullDereference]
            memcpy_from_page(to, *pages, offs, size);
                                 ^~~~~~
    
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

9p: virtio: make sure 'offs' is initialized in zc_request [+ + +]
Author: Dominique Martinet <asmadeus@codewreck.org>
Date:   Wed May 3 16:49:27 2023 +0900

    9p: virtio: make sure 'offs' is initialized in zc_request
    
    [ Upstream commit 4a73edab69d3a6623f03817fe950a2d9585f80e4 ]
    
    Similarly to the previous patch: offs can be used in handle_rerrors
    without initializing on small payloads; in this case handle_rerrors will
    not use it because of the size check, but it doesn't hurt to make sure
    it is zero to please scan-build.
    
    This fixes the following warning:
    net/9p/trans_virtio.c:539:3: warning: 3rd function call argument is an uninitialized value [core.CallAndMessage]
                    handle_rerror(req, in_hdr_len, offs, in_pages);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPI: x86: s2idle: Fix a logic error parsing AMD constraints table [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Fri Aug 18 14:40:04 2023 -0500

    ACPI: x86: s2idle: Fix a logic error parsing AMD constraints table
    
    [ Upstream commit 9cc8cd086f05d9a01026c65c98da88561e9c619e ]
    
    The constraints table should be resetting the `list` object
    after running through all of `info_obj` iterations.
    
    This adjusts whitespace as well as less code will now be included
    with each loop. This fixes a functional problem is fixed where a
    badly formed package in the inner loop may have incorrect data.
    
    Fixes: 146f1ed852a8 ("ACPI: PM: s2idle: Add AMD support to handle _DSM")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: x86: s2idle: Post-increment variables when getting constraints [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Fri Aug 18 14:40:02 2023 -0500

    ACPI: x86: s2idle: Post-increment variables when getting constraints
    
    [ Upstream commit 3c6b1212d20bbbffcad5709ab0f2d5ed9b5859a8 ]
    
    When code uses a pre-increment it makes the reader question "why".
    In the constraint fetching code there is no reason for the variables
    to be pre-incremented so adjust to post-increment.
    No intended functional changes.
    
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 9cc8cd086f05 ("ACPI: x86: s2idle: Fix a logic error parsing AMD constraints table")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: ac97: Fix possible error value of *rac97 [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Wed Aug 23 10:52:13 2023 +0800

    ALSA: ac97: Fix possible error value of *rac97
    
    [ Upstream commit 67de40c9df94037769967ba28c7d951afb45b7fb ]
    
    Before committing 79597c8bf64c, *rac97 always be NULL if there is
    an error. When error happens, make sure *rac97 is NULL is safer.
    
    For examble, in snd_vortex_mixer():
            err = snd_ac97_mixer(pbus, &ac97, &vortex->codec);
            vortex->isquad = ((vortex->codec == NULL) ?
                    0 : (vortex->codec->ext_id&0x80));
    If error happened but vortex->codec isn't NULL, this may cause some
    problems.
    
    Move the judgement order to be clearer and better.
    
    Fixes: 79597c8bf64c ("ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer")
    Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Link: https://lore.kernel.org/r/20230823025212.1000961-1-suhui@nfschina.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/cirrus: Fix broken audio on hardware with two CS42L42 codecs. [+ + +]
Author: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Date:   Mon Sep 4 17:00:33 2023 +0100

    ALSA: hda/cirrus: Fix broken audio on hardware with two CS42L42 codecs.
    
    commit 99bf5b0baac941176a6a3d5cef7705b29808de34 upstream.
    
    Recently in v6.3-rc1 there was a change affecting behaviour of hrtimers
    (commit 0c52310f260014d95c1310364379772cb74cf82d) and causing
    few issues on platforms with two CS42L42 codecs. Canonical/Dell
    has reported an issue with Vostro-3910.
    We need to increase this value by 15ms.
    
    Link: https://bugs.launchpad.net/somerville/+bug/2031060
    Fixes: 9fb9fa18fb50 ("ALSA: hda/cirrus: Add extra 10 ms delay to allow PLL settle and lock.")
    Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20230904160033.908135-1-vitalyr@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/cs8409: Support new Dell Dolphin Variants [+ + +]
Author: Stefan Binding <sbinding@opensource.cirrus.com>
Date:   Fri Aug 11 13:30:44 2023 +0100

    ALSA: hda/cs8409: Support new Dell Dolphin Variants
    
    [ Upstream commit 7c761166399bedfc89c928bef8015546d85a9099 ]
    
    Add 4 new Dell Dolphin Systems, same configuration as older systems.
    
    Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20230811123044.1045651-1-sbinding@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: pcm: Fix missing fixup call in compat hw_refine ioctl [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 29 15:43:44 2023 +0200

    ALSA: pcm: Fix missing fixup call in compat hw_refine ioctl
    
    commit 358040e3807754944dbddf948a23c6d914297ed7 upstream.
    
    The update of rate_num/den and msbits were factored out to
    fixup_unreferenced_params() function to be called explicitly after the
    hw_refine or hw_params procedure.  It's called from
    snd_pcm_hw_refine_user(), but it's forgotten in the PCM compat ioctl.
    This ended up with the incomplete rate_num/den and msbits parameters
    when 32bit compat ioctl is used.
    
    This patch adds the missing call in snd_pcm_ioctl_hw_params_compat().
    
    Reported-by: Meng_Cai@novatek.com.cn
    Fixes: f9a076bff053 ("ALSA: pcm: calculate non-mask/non-interval parameters always when possible")
    Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230829134344.31588-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add quirk for Microsoft Modern Wireless Headset [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jul 25 11:20:57 2023 +0200

    ALSA: usb-audio: Add quirk for Microsoft Modern Wireless Headset
    
    [ Upstream commit 3da435063777f8d861ba5a165344e3f75f839357 ]
    
    Microsoft Modern Wireless Headset (appearing on the host as "Microsoft
    USB Link") has a playback and a capture mixer volume/switch, but they
    are fairly broken.  The descriptor reports wrong dB ranges for
    playback, and the capture volume/switch don't influence on the actual
    recording at all.  Moreover, there seem instabilities in the
    connection, and at best, we should disable the runtime PM.
    
    So this ended up with a quirk entry for:
    - Correct the playback dB range;
      I picked up some reasonable values but it's a guess work
    - Disable the capture mixer;
      it's completely useless and confuses PA/PW
    - Suppress get-sample-rate, apply the delay for message handling,
      and suppress the auto-suspend
    
    The behavior of the wheel control on the headset is somehow flaky,
    too, but it's an issue of HID.
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1207129
    Link: https://lore.kernel.org/r/20230725092057.15115-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Update for native DSD support quirks [+ + +]
Author: Jussi Laako <jussi@sonarnerd.net>
Date:   Wed Jul 26 19:56:45 2023 +0300

    ALSA: usb-audio: Update for native DSD support quirks
    
    [ Upstream commit f7fea075edfa085c25eb34c44ceacf3602537f98 ]
    
    Maintenance patch for native DSD support.
    
    Remove incorrect T+A device quirks. Move set of device quirks to vendor
    quirks. Add set of missing device and vendor quirks.
    
    Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
    Link: https://lore.kernel.org/r/20230726165645.404311-1-jussi@sonarnerd.net
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
amba: bus: fix refcount leak [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Mon Aug 21 10:39:27 2023 +0800

    amba: bus: fix refcount leak
    
    [ Upstream commit e312cbdc11305568554a9e18a2ea5c2492c183f3 ]
    
    commit 5de1540b7bc4 ("drivers/amba: create devices from device tree")
    increases the refcount of of_node, but not releases it in
    amba_device_release, so there is refcount leak. By using of_node_put
    to avoid refcount leak.
    
    Fixes: 5de1540b7bc4 ("drivers/amba: create devices from device tree")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20230821023928.3324283-1-peng.fan@oss.nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64/fpsimd: Only provide the length to cpufeature for xCR registers [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Jul 31 14:58:48 2023 +0100

    arm64/fpsimd: Only provide the length to cpufeature for xCR registers
    
    [ Upstream commit 01948b09edc3fecf8486c57c2d2fb8b80886f3d0 ]
    
    For both SVE and SME we abuse the generic register field comparison
    support in the cpufeature code as part of our detection of unsupported
    variations in the vector lengths available to PEs, reporting the maximum
    vector lengths via ZCR_EL1.LEN and SMCR_EL1.LEN.  Since these are
    configuration registers rather than identification registers the
    assumptions the cpufeature code makes about how unknown bitfields behave
    are invalid, leading to warnings when SME features like FA64 are enabled
    and we hotplug a CPU:
    
      CPU features: SANITY CHECK: Unexpected variation in SYS_SMCR_EL1. Boot CPU: 0x0000000000000f, CPU3: 0x0000008000000f
      CPU features: Unsupported CPU feature variation detected.
    
    SVE has no controls other than the vector length so is not yet impacted
    but the same issue will apply there if any are defined.
    
    Since the only field we are interested in having the cpufeature code
    handle is the length field and we use a custom read function to obtain
    the value we can avoid these warnings by filtering out all other bits
    when we return the register value, if we're doing that we don't need to
    bother reading the register at all and can simply use the RDVL/RDSVL
    value we were filling in instead.
    
    Fixes: 2e0f2478ea37 ("arm64/sve: Probe SVE capabilities and usable vector lengths")
    FixeS: b42990d3bf77 ("arm64/sme: Identify supported SME vector lengths at boot")
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Link: https://lore.kernel.org/r/20230731-arm64-sme-fa64-hotplug-v2-1-7714c00dd902@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64/ptrace: Clean up error handling path in sve_set_common() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Jul 17 19:55:05 2023 +0200

    arm64/ptrace: Clean up error handling path in sve_set_common()
    
    [ Upstream commit 5f69ca4229c7d8e23f238174827ee7aa49b0bcb2 ]
    
    All error handling paths go to 'out', except this one. Be consistent and
    also branch to 'out' here.
    
    Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Link: https://lore.kernel.org/r/aa61301ed2dfd079b74b37f7fede5f179ac3087a.1689616473.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: csum: Fix OoB access in IP checksum code for negative lengths [+ + +]
Author: Will Deacon <will@kernel.org>
Date:   Thu Sep 7 09:54:11 2023 +0100

    arm64: csum: Fix OoB access in IP checksum code for negative lengths
    
    commit 8bd795fedb8450ecbef18eeadbd23ed8fc7630f5 upstream.
    
    Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length
    calls") added an early return for zero-length input, syzkaller has
    popped up with an example of a _negative_ length which causes an
    undefined shift and an out-of-bounds read:
    
     | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
     | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975
     |
     | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0
     | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
     | Call trace:
     |  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
     |  show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
     |  __dump_stack lib/dump_stack.c:88 [inline]
     |  dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
     |  print_address_description mm/kasan/report.c:351 [inline]
     |  print_report+0x174/0x514 mm/kasan/report.c:462
     |  kasan_report+0xd4/0x130 mm/kasan/report.c:572
     |  kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187
     |  __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31
     |  do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
     |  csum_partial+0x30/0x58 lib/checksum.c:128
     |  gso_make_checksum include/linux/skbuff.h:4928 [inline]
     |  __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332
     |  udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47
     |  ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119
     |  skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141
     |  __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401
     |  skb_gso_segment include/linux/netdevice.h:4859 [inline]
     |  validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659
     |  validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709
     |  sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327
     |  __dev_xmit_skb net/core/dev.c:3805 [inline]
     |  __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210
     |  dev_queue_xmit include/linux/netdevice.h:3085 [inline]
     |  packet_xmit+0x6c/0x318 net/packet/af_packet.c:276
     |  packet_snd net/packet/af_packet.c:3081 [inline]
     |  packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113
     |  sock_sendmsg_nosec net/socket.c:724 [inline]
     |  sock_sendmsg net/socket.c:747 [inline]
     |  __sys_sendto+0x3b4/0x538 net/socket.c:2144
    
    Extend the early return to reject negative lengths as well, aligning our
    implementation with the generic code in lib/checksum.c
    
    Cc: Robin Murphy <robin.murphy@arm.com>
    Fixes: 5777eaed566a ("arm64: Implement optimised checksum routine")
    Reported-by: syzbot+4a9f9820bd8d302e22f7@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/000000000000e0e94c0603f8d213@google.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: defconfig: Drop CONFIG_VIDEO_IMX_MEDIA [+ + +]
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Mon Apr 24 12:51:24 2023 +0300

    arm64: defconfig: Drop CONFIG_VIDEO_IMX_MEDIA
    
    [ Upstream commit 0ca2fbab99b12bb81fceaafe5495c00d76789a37 ]
    
    CONFIG_VIDEO_IMX_MEDIA isn't needed on arm64 platforms since commit
    9f257f502c2e ("media: imx: Unstage the imx7-media-csi driver") which
    moved the last arm64 driver depending on that Kconfig symbol out of
    staging. Drop it from the arm64 defconfig.
    
    Fixes: 9f257f502c2e ("media: imx: Unstage the imx7-media-csi driver")
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: defconfig: enable Qualcomm MSM8996 Global Clock Controller as built-in [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Jun 19 15:54:04 2023 +0300

    arm64: defconfig: enable Qualcomm MSM8996 Global Clock Controller as built-in
    
    [ Upstream commit dc015a3a6d6986c41a7bd12fb205a282f685e328 ]
    
    The commit 8f680c287445 ("arm64: defconfig: Switch msm8996 clk drivers
    to module") switched CONFIG_MSM_MMCC_8996 to module, which also resulted
    in CONFIG_MSM_GCC_8996 being switched to module. This breaks useful
    bootflow for Qualcomm MSM8996 / APQ8096 platforms, because the serial is
    not enabled anymore until the GCC module is loaded.
    
    Reported-by: Rob Clark <robdclark@gmail.com>
    Fixes: 8f680c287445 ("arm64: defconfig: Switch msm8996 clk drivers to module")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230619125404.562137-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mp-debix: remove unused fec pinctrl node [+ + +]
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Wed Aug 9 09:10:23 2023 +0200

    arm64: dts: imx8mp-debix: remove unused fec pinctrl node
    
    [ Upstream commit 574e4099d787c2eb41a43f14c453e422515bf658 ]
    
    The SoM A uses the EQOS ethernet interface and not the FEC, so drop the
    interface pinctrl node from the device tree.
    
    Fixes: c86d350aae68 ("arm64: dts: Add device tree for the Debix Model A Board")
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: apq8016-sbc: Fix ov5640 regulator supply names [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Sat Aug 12 00:47:33 2023 +0100

    arm64: dts: qcom: apq8016-sbc: Fix ov5640 regulator supply names
    
    [ Upstream commit 43a684580819e7f35b6cb38236be63c4cba26ef4 ]
    
    The ov5640 driver expects DOVDD, AVDD and DVDD as regulator supply names.
    
    The ov5640 has depended on these names since the driver was committed
    upstream in 2017. Similarly apq8016-sbc.dtsi has had completely different
    regulator names since its own initial commit in 2020.
    
    Perhaps the regulators were left on in previous 410c bootloaders. In any
    case today on 6.5 we won't switch on the ov5640 without correctly naming
    the regulators.
    
    Fixes: 39e0ce6cd1bf ("arm64: dts: qcom: apq8016-sbc: Add CCI/Sensor nodes")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811234738.2859417-3-bryan.odonoghue@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios [+ + +]
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Sat Aug 12 00:47:36 2023 +0100

    arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios
    
    [ Upstream commit 4facccb44a82129195878750eed8f9890091c1b8 ]
    
    There are two control lines controlled by GPIO going into ov5640
    
    - Reset
    - Powerdown
    
    The driver and yaml expect "reset-gpios" and "powerdown-gpios" there has
    never been an "enable-gpios".
    
    Fixes: 39e0ce6cd1bf ("arm64: dts: qcom: apq8016-sbc: Add CCI/Sensor nodes")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811234738.2859417-6-bryan.odonoghue@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916-l8150: correct light sensor VDDIO supply [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sat Jun 17 19:15:28 2023 +0200

    arm64: dts: qcom: msm8916-l8150: correct light sensor VDDIO supply
    
    [ Upstream commit 6a541eaa6e8e5283efb993ae7a947bede8d01fa5 ]
    
    liteon,ltr559 light sensor takes VDDIO, not VIO, supply:
    
      msm8916-longcheer-l8150.dtb: light-sensor@23: 'vio-supply' does not match any of the regexes: 'pinctrl-[0-9]+'
    
    Fixes: 3016af34ef8d ("arm64: dts: qcom: msm8916-longcheer-l8150: Add light and proximity sensor")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Nikita Travkin <nikita@trvn.ru>
    Link: https://lore.kernel.org/r/20230617171541.286957-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916-longcheer-l8910: Add front flash LED [+ + +]
Author: André Apitzsch <git@apitzsch.eu>
Date:   Wed May 17 08:32:31 2023 +0200

    arm64: dts: qcom: msm8916-longcheer-l8910: Add front flash LED
    
    [ Upstream commit 5d8d9330921770fb953e8e749bbd049ac0fae988 ]
    
    l8910 uses OCP8110 flash LED driver. Add it to the device tree.
    
    Tested-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: André Apitzsch <git@apitzsch.eu>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230514-x5_front_flash-v2-1-845a8bb0483b@apitzsch.eu
    Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916: Define regulator constraints next to usage [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Wed May 17 20:48:46 2023 +0200

    arm64: dts: qcom: msm8916: Define regulator constraints next to usage
    
    [ Upstream commit b0a8f16ae4a0eb423122256691849b3ebc64efc2 ]
    
    Right now each MSM8916 device has a huge block of regulator constraints
    with allowed voltages for each regulator. For lack of better
    documentation these voltages are often copied as-is from the vendor
    device tree, without much extra thought.
    
    Unfortunately, the voltages in the vendor device trees are often
    misleading or even wrong, e.g. because:
    
     - There is a large voltage range allowed and the actual voltage is
       only set somewhere hidden in some messy vendor driver. This is often
       the case for pm8916_{l14,l15,l16} because they have a broad range of
       1.8-3.3V by default.
    
     - The voltage is actually wrong but thanks to the voltage constraints
       in the RPM firmware it still ends up applying the correct voltage.
    
    To have proper regulator constraints it is important to review them in
    context of the usage. The current setup in the MSM8916 device trees
    makes this quite hard because each device duplicates the standard
    voltages for components of the SoC and mixes those with minor
    device-specific additions and dummy voltages for completely unused
    regulators.
    
    The actual usage of the regulators for the SoC components is in
    msm8916-pm8916.dtsi, so it can and should also define the related
    voltage constraints. These are not board-specific but defined in the
    APQ8016E/PM8916 Device Specification. The board DT can then focus on
    describing the actual board-specific regulators, which makes it much
    easier to review and spot potential mistakes there.
    
    Note that this commit does not make any functional change. All used
    regulators still have the same regulator constraints as before. Unused
    regulators do not have regulator constraints anymore because most of
    these were too broad or even entirely wrong. They should be added back
    with proper voltage constraints when there is an actual usage.
    
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-7-54d4960a05fc@gerhold.net
    Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916: Disable audio codecs by default [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Wed May 17 20:48:43 2023 +0200

    arm64: dts: qcom: msm8916: Disable audio codecs by default
    
    [ Upstream commit a5cf21b14666c42912327c7bece38711f6e0d708 ]
    
    Not every device has something connected to the digital audio codec
    in MSM8916 and/or the analog audio codec in PM8916. Disable those by
    default so the hardware is only powered up when necessary.
    
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-4-54d4960a05fc@gerhold.net
    Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916: Fix regulator constraints [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Wed May 17 20:48:42 2023 +0200

    arm64: dts: qcom: msm8916: Fix regulator constraints
    
    [ Upstream commit 355750828c5519c88de6ac0d09202d2a7e5892c5 ]
    
    The regulator constraints for most MSM8916 devices (except DB410c) were
    originally taken from Qualcomm's msm-3.10 vendor device tree (for lack
    of better documentation). Unfortunately it turns out that Qualcomm's
    voltages are slightly off as well and do not match the voltage
    constraints applied by the RPM firmware.
    
    This means that we sometimes request a specific voltage but the RPM
    firmware actually applies a much lower or higher voltage. This is
    particularly critical for pm8916_l11 which is used as SD card VMMC
    regulator: The SD card can choose a voltage from the current range of
    1.8 - 2.95V. If it chooses to run at 1.8V we pretend that this is fine
    but the RPM firmware will still silently end up configuring 2.95V.
    This can be easily reproduced with a multimeter or by checking the
    SPMI hardware registers of the regulator.
    
    Fix this by making the voltages match the actual "specified range" in
    the PM8916 Device Specification which is enforced by the RPM firmware.
    
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-3-54d4960a05fc@gerhold.net
    Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8916: Rename &msmgpio -> &tlmm [+ + +]
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Mon May 29 14:46:58 2023 +0200

    arm64: dts: qcom: msm8916: Rename &msmgpio -> &tlmm
    
    [ Upstream commit 41e22c2ff38eaea777f1158071539e659aa7980d ]
    
    MSM8916 is the only ARM64 Qualcomm SoC that is still using the old
    &msmgpio name. Change this to &tlmm to avoid confusion.
    
    Note that the node ordering does not change because the MSM8916 device
    trees have pinctrl separated at the bottom (similar to sc7180).
    
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230525-msm8916-labels-v1-1-bec0f5fb46fb@gerhold.net
    Stable-dep-of: 4facccb44a82 ("arm64: dts: qcom: apq8016-sbc: Rename ov5640 enable-gpios to powerdown-gpios")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8996-gemini: fix touchscreen VIO supply [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Jul 20 13:53:31 2023 +0200

    arm64: dts: qcom: msm8996-gemini: fix touchscreen VIO supply
    
    [ Upstream commit 21fc24ee9c5943732c9ae538766c9be93d70d936 ]
    
    According to bindings and Linux driver, there is no VDDA but VIO supply.
    
    Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230720115335.137354-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8996: Add missing interrupt to the USB2 controller [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jun 27 18:24:27 2023 +0200

    arm64: dts: qcom: msm8996: Add missing interrupt to the USB2 controller
    
    [ Upstream commit 36541089c4733355ed844c67eebd0c3936953454 ]
    
    The interrupt line was previously not described. Take care of that.
    
    Fixes: 1e39255ed29d ("arm64: dts: msm8996: Add device node for qcom,dwc3")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230627-topic-more_bindings-v1-11-6b4b6cd081e5@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8996: Fix dsi1 interrupts [+ + +]
Author: David Wronek <davidwronek@gmail.com>
Date:   Sat Aug 5 15:09:37 2023 +0200

    arm64: dts: qcom: msm8996: Fix dsi1 interrupts
    
    [ Upstream commit bd3b4ac11845b428996cfd2c7b8302ba6a07340d ]
    
    Fix IRQ flags mismatch which was keeping dsi1 from probing by changing
    interrupts = <4> to interrupts = <5>.
    
    Fixes: 2752bb7d9b58 ("arm64: dts: qcom: msm8996: add second DSI interface")
    Signed-off-by: David Wronek <davidwronek@gmail.com>
    Acked-by: Yassine Oudjana <y.oudjana@protonmail.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230805130936.359860-2-davidwronek@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8998: Add missing power domain to MMSS SMMU [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Aug 9 21:20:25 2023 +0200

    arm64: dts: qcom: msm8998: Add missing power domain to MMSS SMMU
    
    [ Upstream commit 7f828f3207142351750e9545527341425187de7b ]
    
    The MMSS SMMU has its own power domain. Attach it so that we can drop
    the "keep it always-on" hack.
    
    Fixes: 05ce21b54423 ("arm64: dts: qcom: msm8998: Configure the multimedia subsystem iommu")
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230531-topic-8998_mmssclk-v3-2-ba1b1fd9ee75@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8998: Drop bus clock reference from MMSS SMMU [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Aug 9 21:20:24 2023 +0200

    arm64: dts: qcom: msm8998: Drop bus clock reference from MMSS SMMU
    
    [ Upstream commit a3ce236364b82688ca4c7605f63c4efd68e9589c ]
    
    The MMSS SMMU has been abusingly consuming the exposed RPM interconnect
    clock. Drop it.
    
    Fixes: 05ce21b54423 ("arm64: dts: qcom: msm8998: Configure the multimedia subsystem iommu")
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230531-topic-8998_mmssclk-v3-1-ba1b1fd9ee75@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pm6150l: Add missing short interrupt [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jun 26 22:00:25 2023 +0200

    arm64: dts: qcom: pm6150l: Add missing short interrupt
    
    [ Upstream commit 7e1f024ef0d1da456f61d00f01dc3287ede915b3 ]
    
    Add the missing short interrupt. This fixes the schema warning:
    
    wled@d800: interrupt-names: ['ovp'] is too short
    
    Fixes: fe508ced49dd ("arm64: dts: qcom: pm6150l: Add wled node")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
    Link: https://lore.kernel.org/r/20230626-topic-bindingsfixups-v1-3-254ae8642e69@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pm660l: Add missing short interrupt [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jun 26 22:00:26 2023 +0200

    arm64: dts: qcom: pm660l: Add missing short interrupt
    
    [ Upstream commit 9a4ac09db3c7413e334b4abd6b2f6de8930dd781 ]
    
    Add the missing short interrupt. This fixes the schema warning:
    
    wled@d800: interrupt-names: ['ovp'] is too short
    
    Fixes: 7b56a804e58b ("arm64: dts: qcom: pm660l: Add WLED support")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230626-topic-bindingsfixups-v1-4-254ae8642e69@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pm8350: fix thermal zone name [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Jul 7 15:30:21 2023 +0300

    arm64: dts: qcom: pm8350: fix thermal zone name
    
    [ Upstream commit 64f19c06f704846db5e4885ca63c689d9bef5723 ]
    
    The name of the thermal zone in pm8350.dtsi (pm8350c-thermal) conflicts
    with the thermal zone in pm8350c.dtsi. Rename the thermal zone according
    to the chip name.
    
    Fixes: 7a79b95f4288 ("arm64: dts: qcom: pm8350: add temp sensor and thermal zone config")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230707123027.1510723-3-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pm8350b: fix thermal zone name [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Jul 7 15:30:22 2023 +0300

    arm64: dts: qcom: pm8350b: fix thermal zone name
    
    [ Upstream commit aad41d9e6c44dfe299cddab97528a5333f17bdfe ]
    
    The name of the thermal zone in pm8350b.dtsi (pm8350c-thermal) conflicts
    with the thermal zone in pm8350c.dtsi. Rename the thermal zone according
    to the chip name.
    
    Fixes: 5c1399299d9d ("arm64: dts: qcom: pm8350b: add temp sensor and thermal zone config")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230707123027.1510723-4-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pmi8950: Add missing OVP interrupt [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jun 26 22:00:27 2023 +0200

    arm64: dts: qcom: pmi8950: Add missing OVP interrupt
    
    [ Upstream commit 4d77b639531fd85b84a7079c3369908dfaddf8b2 ]
    
    Add the missing OVP interrupt. This fixes the schema warning:
    
    wled@d800: interrupt-names: ['short'] is too short
    
    Fixes: 0d97fdf380b4 ("arm64: dts: qcom: Add configuration for PMI8950 peripheral")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230626-topic-bindingsfixups-v1-5-254ae8642e69@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pmi8994: Add missing OVP interrupt [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jun 26 22:00:28 2023 +0200

    arm64: dts: qcom: pmi8994: Add missing OVP interrupt
    
    [ Upstream commit 8db94432690371b1736e9a2566a9b3d8a73d5a97 ]
    
    Add the missing OVP interrupt. This fixes the schema warning:
    
    wled@d800: interrupt-names: ['short'] is too short
    
    Fixes: 37aa540cbd30 ("arm64: dts: qcom: pmi8994: Add WLED node")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230626-topic-bindingsfixups-v1-6-254ae8642e69@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pmk8350: fix ADC-TM compatible string [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Jul 7 15:30:24 2023 +0300

    arm64: dts: qcom: pmk8350: fix ADC-TM compatible string
    
    [ Upstream commit 435a73d7377ceb29c1a22d2711dd85c831b40c45 ]
    
    The commit b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for
    pmk8350") for the ADC TM (thermal monitoring device) have used the
    compatible string from the vendor kernel ("qcom,adc-tm7"). Use the
    proper compatible string that is defined in the upstream kernel
    ("qcom,spmi-adc-tm5-gen2").
    
    Fixes: b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for pmk8350")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230707123027.1510723-6-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: pmr735b: fix thermal zone name [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Jul 7 15:30:23 2023 +0300

    arm64: dts: qcom: pmr735b: fix thermal zone name
    
    [ Upstream commit 99f8cf491d546cd668236f573c7d846d3e94f2d6 ]
    
    The name of the thermal zone in pmr735b.dtsi (pmr735a-thermal) conflicts
    with the thermal zone in pmr735a.dtsi. Rename the thermal zone according
    to the chip name.
    
    Fixes: 6f3426b3dea4 ("arm64: dts: qcom: pmr735b: add temp sensor and thermal zone config")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230707123027.1510723-5-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc8280xp-crd: Correct vreg_misc_3p3 GPIO [+ + +]
Author: Bjorn Andersson <quic_bjorande@quicinc.com>
Date:   Tue Jun 20 13:39:14 2023 -0700

    arm64: dts: qcom: sc8280xp-crd: Correct vreg_misc_3p3 GPIO
    
    [ Upstream commit 9566b5271f68bdf6e69b7c511850e3fb75cd18be ]
    
    The vreg_misc_3p3 regulator is controlled by PMC8280_1 GPIO 2, not 1, on
    the CRD.
    
    Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device")
    Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Tested-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230620203915.141337-1-quic_bjorande@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc8280xp-x13s: Unreserve NC pins [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Thu Aug 3 15:05:26 2023 +0200

    arm64: dts: qcom: sc8280xp-x13s: Unreserve NC pins
    
    [ Upstream commit 7868ed0144b33903e16a50485775f669c109e41a ]
    
    Pins 83-86 and 158-160 are NC, so there's no point in keeping them
    reserved. Take care of that.
    
    Fixes: 32c231385ed4 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230803-topic-x13s_pin-v1-1-fae792274e89@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc8280xp: Add missing SCM interconnect [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Thu Jun 22 17:56:16 2023 +0200

    arm64: dts: qcom: sc8280xp: Add missing SCM interconnect
    
    [ Upstream commit 0a69ccf20b0837db857abfc94d7e3bacf1cb771b ]
    
    The SCM interconnect path was missing. Add it.
    
    Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Tested-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20230622-topic-8280scmicc-v1-2-6ef318919ea5@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845-tama: Set serial indices and stdout-path [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jun 27 19:27:50 2023 +0200

    arm64: dts: qcom: sdm845-tama: Set serial indices and stdout-path
    
    [ Upstream commit 9acc60c3e2d449243e4c2126e3b56f1c4f7fd3bc ]
    
    UART6 is used for debug (routed via uSD pins) and UART9 is connected
    to the bluetooth chip.
    
    Set indexed aliases to make the GENI UART driver happy and route serial
    traffic through the debug uart by default.
    
    Fixes: 30a7f99befc6 ("arm64: dts: qcom: Add support for SONY Xperia XZ2 / XZ2C / XZ3 (Tama platform)")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Link: https://lore.kernel.org/r/20230627-topic-tama_uart-v1-1-0fa790248db8@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845: Add missing RPMh power domain to GCC [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Thu Jul 20 11:10:48 2023 +0530

    arm64: dts: qcom: sdm845: Add missing RPMh power domain to GCC
    
    [ Upstream commit 4b6ea15c0a1122422b44bf6c47a3c22fc8d46777 ]
    
    GCC and it's GDSCs are under the RPMh CX power domain. So let's add the
    missing RPMh power domain to the GCC node.
    
    Fixes: 6d4cf750d03a ("arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20230720054100.9940-4-manivannan.sadhasivam@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845: Fix the min frequency of "ice_core_clk" [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Thu Jul 20 11:10:49 2023 +0530

    arm64: dts: qcom: sdm845: Fix the min frequency of "ice_core_clk"
    
    [ Upstream commit bbbef6e24bc4493602df68b052f6f48d48e3184a ]
    
    Minimum frequency of the "ice_core_clk" should be 75MHz as specified in the
    downstream vendor devicetree. So fix it!
    
    https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/blob/LA.UM.7.3.r1-09300-sdm845.0/arch/arm64/boot/dts/qcom/sdm845.dtsi
    
    Fixes: 433f9a57298f ("arm64: dts: sdm845: add Inline Crypto Engine registers and clock")
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20230720054100.9940-5-manivannan.sadhasivam@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm6350: Fix ZAP region [+ + +]
Author: Konrad Dybcio <konrad.dybcio@somainline.org>
Date:   Wed Jun 14 13:35:37 2023 +0200

    arm64: dts: qcom: sm6350: Fix ZAP region
    
    [ Upstream commit 44bcded2be4fe9b9d0b6e48075c9947b75c0af63 ]
    
    The previous ZAP region definition was wrong. Fix it.
    Note this is not a device-specific fixup, but a fixup to the generic
    PIL load address.
    
    Fixes: 5f82b9cda61e ("arm64: dts: qcom: Add SM6350 device tree")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Reviewed-by: Luca Weiss <luca.weiss@fairphone.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230315-topic-lagoon_gpu-v2-6-afcdfb18bb13@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8150: Fix the I2C7 interrupt [+ + +]
Author: Zeyan Li <qaz6750@outlook.com>
Date:   Thu Jul 27 10:53:21 2023 +0800

    arm64: dts: qcom: sm8150: Fix the I2C7 interrupt
    
    [ Upstream commit f9568d22ce06192a7e14bda3a29dc216659554ff ]
    
    I2C6 and I2C7 use the same interrupts, which is incorrect.
    In the downstream kernel, I2C7 has interrupts of 608 instead of 607.
    
    Fixes: 81bee6953b58 ("arm64: dts: qcom: sm8150: add i2c nodes")
    Signed-off-by: Zeyan Li <qaz6750@outlook.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/SY7P282MB378712225CBCEA95FE71554DB201A@SY7P282MB3787.AUSP282.PROD.OUTLOOK.COM
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8150: use proper DSI PHY compatible [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Jun 12 06:16:23 2023 +0300

    arm64: dts: qcom: sm8150: use proper DSI PHY compatible
    
    [ Upstream commit 3091e5820a367f3368132f57e0a9ba6d545da15d ]
    
    The DSI PHY on the Qualcomm SM8150 platform requires platform-specific
    handling. Use the proper SoC-specific compatible string for the DSI
    PHYs.
    
    Reported-by: Degdag Mohamed <degdagmohamed@gmail.com>
    Fixes: 2ef3bb17c45c ("arm64: dts: qcom: sm8150: Add DISPCC node")
    Cc: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230612031623.3620155-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8250-edo: Add GPIO line names for PMIC GPIOs [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jun 20 13:05:35 2023 +0200

    arm64: dts: qcom: sm8250-edo: Add GPIO line names for PMIC GPIOs
    
    [ Upstream commit 6b8a63350752c6a5e4b54f2de6174084652cd3cd ]
    
    Sony ever so graciously provides GPIO line names in their downstream
    kernel (though sometimes they are not 100% accurate and you can judge
    that by simply looking at them and with what drivers they are used).
    
    Add these to the PDX203&206 DTSIs to better document the hardware.
    
    Diff between 203 and 206:
    pm8009_gpios
    <                         "CAM_PWR_LD_EN",
    >                         "NC",
    
    pm8150_gpios
    <                         "NC",
    >                         "G_ASSIST_N",
    <                         "WLC_EN_N", /* GPIO_10 */
    >                         "NC", /* GPIO_10 */
    Which is due to 5 II having an additional Google Assistant hardware
    button and 1 II having a wireless charger & different camera wiring
    to accommodate the additional 3D iToF sensor.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230614-topic-edo_pinsgpiopmic-v2-2-6f90bba54c53@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8250-edo: Add gpio line names for TLMM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jun 20 13:05:34 2023 +0200

    arm64: dts: qcom: sm8250-edo: Add gpio line names for TLMM
    
    [ Upstream commit 40b398beabdfe0e9088b13976e56b1dc706fe851 ]
    
    Sony ever so graciously provides GPIO line names in their downstream
    kernel (though sometimes they are not 100% accurate and you can judge
    that by simply looking at them and with what drivers they are used).
    
    Add these to the PDX203&206 DTSIs to better document the hardware.
    
    Diff between 203 and 206:
    <                         "CAM_PWR_A_CS",
    >                         "FRONTC_PWR_EN",
    <                         "CAM4_MCLK",
    <                         "TOF_RST_N",
    >                         "NC",
    >                         "NC",
    <                         "WLC_I2C_SDA",
    <                         "WLC_I2C_SCL", /* GPIO_120 */
    >                         "NC",
    >                         "NC",
    <                         "WLC_INT_N",
    >                         "NC",
    
    Which makes sense, as 203 has a 3D iToF, slightly different camera
    power wiring and WLC (WireLess Charging).
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230614-topic-edo_pinsgpiopmic-v2-1-6f90bba54c53@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8250-edo: Rectify gpio-keys [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jun 20 13:05:37 2023 +0200

    arm64: dts: qcom: sm8250-edo: Rectify gpio-keys
    
    [ Upstream commit a422c6a91a667b309ca1a6c08b30dbfcf7d4e866 ]
    
    Set up the corresponding GPIOs properly and add the leftover hardware
    buttons to mark this piece of the puzzle complete.
    
    Fixes: 46e14907c716 ("arm64: dts: qcom: sm8250-edo: Add hardware keys")
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230614-topic-edo_pinsgpiopmic-v2-4-6f90bba54c53@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8250-sony-xperia: correct GPIO keys wakeup again [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Jul 11 08:30:11 2023 +0200

    arm64: dts: qcom: sm8250-sony-xperia: correct GPIO keys wakeup again
    
    [ Upstream commit b8fbeea0253211d97c579eae787274633d3eaf0d ]
    
    gpio-keys,wakeup is a deprecated property:
    
      m8250-sony-xperia-edo-pdx206.dtb: gpio-keys: key-camera-focus: Unevaluated properties are not allowed ('gpio-key,wakeup' was unexpected)
    
    Fixes: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230711063011.16222-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8250: correct dynamic power coefficients [+ + +]
Author: Vincent Guittot <vincent.guittot@linaro.org>
Date:   Thu Jun 15 17:48:52 2023 +0200

    arm64: dts: qcom: sm8250: correct dynamic power coefficients
    
    [ Upstream commit 775a5283c25d160b2a1359018c447bc518096547 ]
    
    sm8250 faces the same problem with its Energy Model as sdm845. The energy
    cost of LITTLE cores is reported to be higher than medium or big cores
    
    EM computes the energy with formula:
    
    energy = OPP's cost / maximum cpu capacity * utilization
    
    On v6.4-rc6 we have:
    max capacity of CPU0 = 284
    capacity of CPU0's OPP(1612800 Hz) = 253
    cost of CPU0's OPP(1612800 Hz) = 191704
    
    max capacity of CPU4 = 871
    capacity of CPU4's OPP(710400 Hz) = 255
    cost of CPU4's OPP(710400 Hz) = 343217
    
    Both OPPs have almost the same compute capacity but the estimated energy
    per unit of utilization will be estimated to:
    
    energy CPU0 = 191704 / 284 * 1 = 675
    energy CPU4 = 343217 / 871 * 1 = 394
    
    EM estimates that little CPU0 will consume 71% more than medium CPU4 for
    the same compute capacity. According to [1], little consumes 25% less than
    medium core for Coremark benchmark at those OPPs for the same duration.
    
    Set the dynamic-power-coefficient of CPU0-3 to 105 to fix the energy model
    for little CPUs.
    
    [1] https://github.com/kdrag0n/freqbench/tree/master/results/sm8250/k30s
    
    Fixes: 6aabed5526ee ("arm64: dts: qcom: sm8250: Add CPU capacities and energy model")
    Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20230615154852.130076-1-vincent.guittot@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8250: Mark PCIe hosts as DMA coherent [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jul 4 14:23:17 2023 +0200

    arm64: dts: qcom: sm8250: Mark PCIe hosts as DMA coherent
    
    [ Upstream commit 339d38a436f30d0f874815eafc7de2257346bf26 ]
    
    The PCIe hosts on SM8250 are cache-coherent. Mark them as such.
    
    Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230704-topic-8250_pcie_dmac-v1-1-799603a980b0@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8350: Add missing LMH interrupts to cpufreq [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Jul 5 15:36:23 2023 +0200

    arm64: dts: qcom: sm8350: Add missing LMH interrupts to cpufreq
    
    [ Upstream commit 951151c2bb548e0f6b2c40ab4c48675f5342c914 ]
    
    Add the missing interrupts that communicate the hardware-managed
    throttling to Linux.
    
    Fixes: ccbb3abb23a5 ("arm64: dts: qcom: sm8350: Add cpufreq node")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230705-topic-sm8350_fixes-v1-3-0f69f70ccb6a@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8350: Fix CPU idle state residency times [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Jul 5 15:36:22 2023 +0200

    arm64: dts: qcom: sm8350: Fix CPU idle state residency times
    
    [ Upstream commit 91ce3693e2fb685f31d39605a5ad1fbd940804da ]
    
    The present values look to have been copypasted from 8150 or 8180.
    Fix that.
    
    Fixes: 07ddb302811e ("arm64: dts: qcom: sm8350: Add CPU topology and idle-states")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230705-topic-sm8350_fixes-v1-2-0f69f70ccb6a@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8350: Use proper CPU compatibles [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Thu Jul 6 18:35:37 2023 +0200

    arm64: dts: qcom: sm8350: Use proper CPU compatibles
    
    [ Upstream commit 4390730cc12af25f7c997f477795f5f4200149c0 ]
    
    The Kryo names (once again) turned out to be fake. The CPUs report:
    
    0x412fd050 (CA55 r2p0) (0 - 3)
    0x411fd410 (CA78 r1p1) (4 - 6)
    0x411fd440 (CX1  r1p1) (7)
    
    Use the compatibles that reflect that.
    
    Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230706-topic-sm8350-cpu-compat-v1-1-f8d6a1869781@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8450-hdk: remove pmr735b PMIC inclusion [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Jul 7 15:30:25 2023 +0300

    arm64: dts: qcom: sm8450-hdk: remove pmr735b PMIC inclusion
    
    [ Upstream commit 701b59db773730a914f1778cf2dd05e3a05c2c69 ]
    
    The 8450-HDK doesn't use PMR735B PMIC. Drop its inclusion to remove the
    warning during the HDK bootup.
    
    Fixes: 30464456a1ea ("arm64: dts: qcom: sm8450-hdk: add pmic files")
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230707123027.1510723-7-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sm8550-mtp: Add missing supply for L1B regulator [+ + +]
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Tue Aug 1 12:52:46 2023 +0300

    arm64: dts: qcom: sm8550-mtp: Add missing supply for L1B regulator
    
    [ Upstream commit 2c9e45dfeed126488aa73e7b82b3576c4c6f1036 ]
    
    Even though currently there is no consumer for L1B, add the supply
    for it anyway.
    
    Fixes: 71342fb91eae ("arm64: dts: qcom: Add base SM8550 MTP dts")
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20230801095246.2884770-1-abel.vesa@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: correct wifi interrupt flag in Box Demo [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Jul 7 08:33:35 2023 +0200

    arm64: dts: rockchip: correct wifi interrupt flag in Box Demo
    
    [ Upstream commit 2d6f7e3938a7aba154c8e8afaddc8b7f1e0a1b56 ]
    
    GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
    These are simple defines so they could be used in DTS but they will not
    have the same meaning: GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE.
    
    Correct the interrupt flags, assuming the author of the code wanted same
    logical behavior behind the name "ACTIVE_xxx", this is:
      ACTIVE_HIGH  => IRQ_TYPE_LEVEL_HIGH
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230707063335.13317-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: correct wifi interrupt flag in eaidk-610 [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Jul 7 08:33:33 2023 +0200

    arm64: dts: rockchip: correct wifi interrupt flag in eaidk-610
    
    [ Upstream commit 8183bb7e291b7818f49ea39687c2fafa01a46e27 ]
    
    GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
    These are simple defines so they could be used in DTS but they will not
    have the same meaning: GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE.
    
    Correct the interrupt flags, assuming the author of the code wanted same
    logical behavior behind the name "ACTIVE_xxx", this is:
      ACTIVE_HIGH  => IRQ_TYPE_LEVEL_HIGH
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230707063335.13317-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: correct wifi interrupt flag in Rock Pi 4B [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Jul 7 08:33:34 2023 +0200

    arm64: dts: rockchip: correct wifi interrupt flag in Rock Pi 4B
    
    [ Upstream commit cfa12c32b96fd5b12f77d880d6a1ddd2a502756e ]
    
    GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
    These are simple defines so they could be used in DTS but they will not
    have the same meaning: GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE.
    
    Correct the interrupt flags, assuming the author of the code wanted same
    logical behavior behind the name "ACTIVE_xxx", this is:
      ACTIVE_HIGH  => IRQ_TYPE_LEVEL_HIGH
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Tested-by: Christopher Obbard <chris.obbard@collabora.com>
    Link: https://lore.kernel.org/r/20230707063335.13317-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: Enable SATA on Radxa E25 [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Mon Jul 24 14:52:16 2023 +0000

    arm64: dts: rockchip: Enable SATA on Radxa E25
    
    [ Upstream commit 2bdfe84fbd57a4ed9fd65a67210442559ce078f0 ]
    
    The M.2 KEY B port can be used for WWAN USB2 modules or SATA drives.
    
    Enable sata1 node to fix use of SATA drives on the M.2 slot.
    
    Fixes: 2bf2f4d9f673 ("arm64: dts: rockchip: Add Radxa CM3I E25")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Link: https://lore.kernel.org/r/20230724145213.3833099-1-jonas@kwiboo.se
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: Fix PCIe regulators on Radxa E25 [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Mon Jul 24 14:52:16 2023 +0000

    arm64: dts: rockchip: Fix PCIe regulators on Radxa E25
    
    [ Upstream commit a87852e37f782257ebc57cc44a0d3fbf806471f6 ]
    
    Despite its name, the regulator vcc3v3_pcie30x1 has nothing to do with
    pcie30x1. Instead, it supply power to VBAT1-5 on the M.2 KEY B port as
    seen on page 8 of the schematic [1].
    
    pcie30x1 is used for the mini PCIe slot, and as seen on page 9 the
    vcc3v3_minipcie regulator is instead related to pcie30x1.
    
    The M.2 KEY B port can be used for WWAN USB2 modules or SATA drives.
    
    Use correct regulator vcc3v3_minipcie for pcie30x1.
    
    [1] https://dl.radxa.com/cm3p/e25/radxa-e25-v1.4-sch.pdf
    
    Fixes: 2bf2f4d9f673 ("arm64: dts: rockchip: Add Radxa CM3I E25")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Link: https://lore.kernel.org/r/20230724145213.3833099-1-jonas@kwiboo.se
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: ti: k3-am62x-sk-common: Update main-i2c1 frequency [+ + +]
Author: Aradhya Bhatia <a-bhatia1@ti.com>
Date:   Wed Aug 9 14:15:54 2023 +0530

    arm64: dts: ti: k3-am62x-sk-common: Update main-i2c1 frequency
    
    [ Upstream commit 73387da70f9c26b6fba4f62371d013cce14663d9 ]
    
    The Display Data Channel (DDC) transactions between an HDMI transmitter
    (SIL9022A in this case) and an HDMI monitor, occur at a maximum of
    100KHz. That's the maximum supported frequency within DDC standards.
    
    While the SIL9022A can transact with the core at 400KHz, it needs to
    drop the frequency to 100KHz when communicating with the monitor,
    otherwise, the i2c controller times out and shows warning like this.
    
    [  985.773431] omap_i2c 20010000.i2c: controller timed out
    
    That feature, however, has not been enabled in the SIL9022 driver.
    
    Since, dropping the frequency doesn't affect any other devices on the
    bus, drop the main-i2c1 frequency from 400KHz to 100KHz.
    
    Fixes: a841581451af ("arm64: dts: ti: Refractor AM625 SK dts")
    Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
    Link: https://lore.kernel.org/r/20230809084559.17322-2-a-bhatia1@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: ti: k3-j784s4: Fix interrupt ranges for wkup & main gpio [+ + +]
Author: Apelete Seketeli <aseketeli@baylibre.com>
Date:   Thu Aug 10 01:16:22 2023 +0530

    arm64: dts: ti: k3-j784s4: Fix interrupt ranges for wkup & main gpio
    
    [ Upstream commit 05a1f130101e7a49ff1e8734939facd43596ea26 ]
    
    This patch fixes the interrupt range for wakeup and main domain gpio
    interrupt routers. They were wrongly subtracted by 32 instead of
    following what is defined in the interrupt map in the TRM (Table 9-35).
    
    Link:  http://www.ti.com/lit/pdf/spruj52
    Fixes: 4664ebd8346a ("arm64: dts: ti: Add initial support for J784S4 SoC")
    Signed-off-by: Apelete Seketeli <aseketeli@baylibre.com>
    Signed-off-by: Esteban Blanc <eblanc@baylibre.com>
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Link: https://lore.kernel.org/r/20230810-tps6594-v6-4-2b2e2399e2ef@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: mm: use ptep_clear() instead of pte_clear() in clear_flush() [+ + +]
Author: Qi Zheng <zhengqi.arch@bytedance.com>
Date:   Thu Aug 10 09:32:41 2023 +0000

    arm64: mm: use ptep_clear() instead of pte_clear() in clear_flush()
    
    [ Upstream commit 00de2c9f26b15f1a6f2af516dd8ec5f8d28189b7 ]
    
    In clear_flush(), the original pte may be a present entry, so we should
    use ptep_clear() to let page_table_check track the pte clearing operation,
    otherwise it may cause false positive in subsequent set_pte_at().
    
    Link: https://lkml.kernel.org/r/20230810093241.1181142-1-qi.zheng@linux.dev
    Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK")
    Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
    Acked-by: Will Deacon <will@kernel.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
    Cc: Qi Zheng <zhengqi.arch@bytedance.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: sdei: abort running SDEI handlers during crash [+ + +]
Author: D Scott Phillips <scott@os.amperecomputing.com>
Date:   Mon Jun 26 17:29:39 2023 -0700

    arm64: sdei: abort running SDEI handlers during crash
    
    commit 5cd474e57368f0957c343bb21e309cf82826b1ef upstream.
    
    Interrupts are blocked in SDEI context, per the SDEI spec: "The client
    interrupts cannot preempt the event handler." If we crashed in the SDEI
    handler-running context (as with ACPI's AGDI) then we need to clean up the
    SDEI state before proceeding to the crash kernel so that the crash kernel
    can have working interrupts.
    
    Track the active SDEI handler per-cpu so that we can COMPLETE_AND_RESUME
    the handler, discarding the interrupted context.
    
    Fixes: f5df26961853 ("arm64: kernel: Add arch-specific SDEI entry code and CPU masking")
    Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: James Morse <james.morse@arm.com>
    Tested-by: Mihai Carabas <mihai.carabas@oracle.com>
    Link: https://lore.kernel.org/r/20230627002939.2758-1-scott@os.amperecomputing.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: tegra: Fix HSUART for Jetson AGX Orin [+ + +]
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Mon Jul 3 12:36:17 2023 +0100

    arm64: tegra: Fix HSUART for Jetson AGX Orin
    
    [ Upstream commit 861dbb2b15b1049113887fb95e856f7123eea0cc ]
    
    After commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and
    reset-names") was applied, the HSUART failed to probe and the following
    error is seen:
    
     serial-tegra 3100000.serial: Couldn't get the reset
     serial-tegra: probe of 3100000.serial failed with error -2
    
    Commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and
    reset-names") is correct because the "reset-names" property is not
    needed for 8250 UARTs. However, the "reset-names" is required for the
    HSUART and should have been populated as part of commit ff578db7b693
    ("arm64: tegra: Enable UART instance on 40-pin header") that
    enabled the HSUART for Jetson AGX Orin. Fix this by populating the
    "reset-names" property for the HSUART on Jetson AGX Orin.
    
    Fixes: ff578db7b693 ("arm64: tegra: Enable UART instance on 40-pin header")
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: tegra: Fix HSUART for Smaug [+ + +]
Author: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Date:   Fri Jul 14 11:10:17 2023 +0100

    arm64: tegra: Fix HSUART for Smaug
    
    [ Upstream commit 590bfe51838f6345a6a3288507661dc9b7208464 ]
    
    After commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and
    reset-names") was applied, the HSUART failed to probe and the following
    error is seen:
    
     serial-tegra 70006300.serial: Couldn't get the reset
     serial-tegra: probe of 70006300.serial failed with error -2
    
    Commit 71de0a054d0e ("arm64: tegra: Drop serial clock-names and
    reset-names") is correct because the "reset-names" property is not
    needed for 8250 UARTs. However, the "reset-names" is required for the
    HSUART and should have been populated as part of commit a63c0cd83720c
    ("arm64: dts: tegra: smaug: Add Bluetooth node") that enabled the HSUART
    for the Pixel C. Fix this by populating the "reset-names" property for
    the HSUART on the Pixel C.
    
    Fixes: a63c0cd83720 ("arm64: dts: tegra: smaug: Add Bluetooth node")
    Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: Add .dts files missing from the build [+ + +]
Author: Rob Herring <robh@kernel.org>
Date:   Tue May 2 12:25:29 2023 -0500

    ARM: dts: Add .dts files missing from the build
    
    [ Upstream commit 86684c2481b6e6a46c2282acee13554e34e66071 ]
    
    Comparing .dts files to built .dtb files yielded a few .dts files which
    are never built. Add them to the build.
    
    Signed-off-by: Rob Herring <robh@kernel.org>
    Stable-dep-of: 92632115fb57 ("samples/bpf: fix bio latency check with tracepoint")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Add cells sizes to PCIe node [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Jul 7 13:40:03 2023 +0200

    ARM: dts: BCM53573: Add cells sizes to PCIe node
    
    [ Upstream commit 3392ef368d9b04622fe758b1079b512664b6110a ]
    
    This fixes:
    arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: pcie@2000: '#address-cells' is a required property
            From schema: /lib/python3.10/site-packages/dtschema/schemas/pci/pci-bus.yaml
    arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: pcie@2000: '#size-cells' is a required property
            From schema: /lib/python3.10/site-packages/dtschema/schemas/pci/pci-bus.yaml
    
    Two properties that need to be added later are "device_type" and
    "ranges". Adding "device_type" on its own causes a new warning and the
    value of "ranges" needs to be determined yet.
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230707114004.2740-3-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Drop nonexistent "default-off" LED trigger [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Jul 7 13:40:01 2023 +0200

    ARM: dts: BCM53573: Drop nonexistent "default-off" LED trigger
    
    [ Upstream commit be7e1e5b0f67c58ec4be0a54db23b6a4fa6e2116 ]
    
    There is no such trigger documented or implemented in Linux. It was a
    copy & paste mistake.
    
    This fixes:
    arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: leds: led-wlan:linux,default-trigger: 'oneOf' conditional failed, one must be fixed:
            'default-off' is not one of ['backlight', 'default-on', 'heartbeat', 'disk-activity', 'disk-read', 'disk-write', 'timer', 'pattern', 'audio-micmute', 'audio-mute', 'bluetooth-power', 'flash', 'kbd-capslock', 'mtd', 'nand-disk', 'none', 'torch', 'usb-gadget', 'usb-host', 'usbport']
            'default-off' does not match '^cpu[0-9]*$'
            'default-off' does not match '^hci[0-9]+-power$'
            'default-off' does not match '^mmc[0-9]+$'
            'default-off' does not match '^phy[0-9]+tx$'
            From schema: Documentation/devicetree/bindings/leds/leds-gpio.yaml
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230707114004.2740-1-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Drop nonexistent #usb-cells [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Jul 7 13:40:02 2023 +0200

    ARM: dts: BCM53573: Drop nonexistent #usb-cells
    
    [ Upstream commit 05d2c3d552b8c92fc397377d9d1112fc58e2cd59 ]
    
    Such property simply doesn't exist (is not documented or used anywhere).
    
    This fixes:
    arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: usb@d000: Unevaluated properties are not allowed ('#usb-cells' was unexpected)
            From schema: Documentation/devicetree/bindings/usb/generic-ohci.yaml
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230707114004.2740-2-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Fix Ethernet info for Luxul devices [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Thu Jul 13 13:11:45 2023 +0200

    ARM: dts: BCM53573: Fix Ethernet info for Luxul devices
    
    [ Upstream commit 44ad8207806973f4e4f7d870fff36cc01f494250 ]
    
    Both Luxul's XAP devices (XAP-810 and XAP-1440) are access points that
    use a non-default design. They don't include switch but have a single
    Ethernet port and BCM54210E PHY connected to the Ethernet controller's
    MDIO bus.
    
    Support for those devices regressed due to two changes:
    
    1. Describing MDIO bus with switch
    After commit 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125
    rev 4 switch") Linux stopped probing for MDIO devices.
    
    2. Dropping hardcoded BCM54210E delays
    In commit fea7fda7f50a ("net: phy: broadcom: Fix RGMII delays
    configuration for BCM54210E") support for other PHY modes was added but
    that requires a proper "phy-mode" value in DT.
    
    Both above changes are correct (they don't need to be reverted or
    anything) but they need this fix for DT data to be correct and for Linux
    to work properly.
    
    Fixes: 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230713111145.14864-1-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Fix Tenda AC9 switch CPU port [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Jul 23 21:54:14 2023 +0200

    ARM: dts: BCM53573: Fix Tenda AC9 switch CPU port
    
    [ Upstream commit 7141209db9c335ab261a17933809a3e660ebdc12 ]
    
    Primary Ethernet interface is connected to the port 8 (not 5).
    
    Fixes: 64612828628c ("ARM: dts: BCM53573: Add Tenda AC9 switch ports")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230723195416.7831-1-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: BCM53573: Use updated "spi-gpio" binding properties [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Jul 7 13:40:04 2023 +0200

    ARM: dts: BCM53573: Use updated "spi-gpio" binding properties
    
    [ Upstream commit 2c0fd6b3d0778ceab40205315ccef74568490f17 ]
    
    Switch away from deprecated properties.
    
    This fixes:
    arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-sck: False schema does not allow [[3, 21, 0]]
            From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml
    arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-miso: False schema does not allow [[3, 22, 0]]
            From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml
    arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-mosi: False schema does not allow [[3, 23, 0]]
            From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml
    arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: 'sck-gpios' is a required property
            From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml
    arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: Unevaluated properties are not allowed ('gpio-miso', 'gpio-mosi', 'gpio-sck' were unexpected)
            From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20230707114004.2740-4-zajec5@gmail.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: integrator: fix PCI bus dtc warnings [+ + +]
Author: Lin Yujun <linyujun809@huawei.com>
Date:   Fri Aug 11 09:00:06 2023 +0200

    ARM: dts: integrator: fix PCI bus dtc warnings
    
    [ Upstream commit 42ff49a1967af71772b264009659ce181f7d2d2a ]
    
    An warning is reported when allmodconfig is used to compile the kernel of the ARM architecture:
    
    arch/arm/boot/dts/arm/integratorap.dts:161.22-206.4: Warning (pci_bridge): /pciv3@62000000: node name is not "pci" or "pcie"
    
    Change the node name to pci to clear the build warning.
    
    Signed-off-by: Lin Yujun <linyujun809@huawei.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20230811-versatile-dts-v6-6-v1-1-d8cb9d1947ed@linaro.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: ipq4019: correct SDHCI XO clock [+ + +]
Author: Robert Marko <robert.marko@sartura.hr>
Date:   Fri Aug 11 13:01:16 2023 +0200

    ARM: dts: qcom: ipq4019: correct SDHCI XO clock
    
    [ Upstream commit b5ed7a5c1fdb3981713f7b637b72aa390c3db036 ]
    
    Using GCC_DCD_XO_CLK as the XO clock for SDHCI controller is not correct,
    it seems that I somehow made a mistake of passing it instead of the fixed
    XO clock.
    
    Fixes: 04b3b72b5b8f ("ARM: dts: qcom: ipq4019: Add SDHCI controller node")
    Signed-off-by: Robert Marko <robert.marko@sartura.hr>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811110150.229966-1-robert.marko@sartura.hr
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: sdx65-mtp: Update the pmic used in sdx65 [+ + +]
Author: Rohit Agarwal <quic_rohiagar@quicinc.com>
Date:   Mon Aug 7 19:08:51 2023 +0530

    ARM: dts: qcom: sdx65-mtp: Update the pmic used in sdx65
    
    [ Upstream commit f636d6c356b339b0d29eed025f8bf9efcb6eb274 ]
    
    Update the pmic used in sdx65 platform to pm7250b.
    
    Fixes: 26380f298b2b (ARM: dts: qcom: sdx65-mtp: Add pmk8350b and pm8150b pmic)
    Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/1691415534-31820-7-git-send-email-quic_rohiagar@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: s5pv210: add dummy 5V regulator for backlight on SMDKv210 [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Apr 21 11:57:21 2023 +0200

    ARM: dts: s5pv210: add dummy 5V regulator for backlight on SMDKv210
    
    [ Upstream commit b77904ba177a9c67b6dbc3637fdf1faa22df6e5c ]
    
    Backlight is supplied by DC5V regulator.  The DTS has no PMIC node, so
    just add a regulator-fixed to solve it and fix dtbs_check warning:
    
      s5pv210-smdkv210.dtb: backlight: 'power-supply' is a required property
    
    Link: https://lore.kernel.org/r/20230421095721.31857-4-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Stable-dep-of: 982655cb0e7f ("ARM: dts: samsung: s5pv210-smdkv210: correct ethernet reg addresses (split)")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: samsung: s3c6410-mini6410: correct ethernet reg addresses (split) [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Jul 13 17:29:25 2023 +0200

    ARM: dts: samsung: s3c6410-mini6410: correct ethernet reg addresses (split)
    
    [ Upstream commit cf0cb2af6a18f28b84f9f1416bff50ca60d6e98a ]
    
    The davicom,dm9000 Ethernet Controller accepts two reg addresses.
    
    Fixes: a43736deb47d ("ARM: dts: Add dts file for S3C6410-based Mini6410 board")
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Link: https://lore.kernel.org/r/20230713152926.82884-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: samsung: s5pv210-smdkv210: correct ethernet reg addresses (split) [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Jul 13 17:29:26 2023 +0200

    ARM: dts: samsung: s5pv210-smdkv210: correct ethernet reg addresses (split)
    
    [ Upstream commit 982655cb0e7f18934d7532c32366e574ad61dbd7 ]
    
    The davicom,dm9000 Ethernet Controller accepts two reg addresses.
    
    Fixes: b672b27d232e ("ARM: dts: Add Device tree for s5pc110/s5pv210 boards")
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Link: https://lore.kernel.org/r/20230713152926.82884-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Add missing detach mailbox for DHCOM SoM [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Tue Jul 11 15:09:07 2023 +0200

    ARM: dts: stm32: Add missing detach mailbox for DHCOM SoM
    
    [ Upstream commit deb7edbc27a6ec4d8f5edfd8519b7ed13cbd2a52 ]
    
    Add missing "detach" mailbox to this board to permit the CPU to inform
    the remote processor on a detach. This signal allows the remote processor
    firmware to stop IPC communication and to reinitialize the resources for
    a re-attach.
    
    Without this mailbox, detach is not possible and kernel log contains the
    following warning to, so make sure all the STM32MP15xx platform DTs are
    in sync regarding the mailboxes to fix the detach issue and the warning:
    "
    stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach"
    "
    
    Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Add missing detach mailbox for DHCOR SoM [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Tue Jul 11 15:11:21 2023 +0200

    ARM: dts: stm32: Add missing detach mailbox for DHCOR SoM
    
    [ Upstream commit 2f38de940f072db369edd3e6e8d82bb8f42c5c9b ]
    
    Add missing "detach" mailbox to this board to permit the CPU to inform
    the remote processor on a detach. This signal allows the remote processor
    firmware to stop IPC communication and to reinitialize the resources for
    a re-attach.
    
    Without this mailbox, detach is not possible and kernel log contains the
    following warning to, so make sure all the STM32MP15xx platform DTs are
    in sync regarding the mailboxes to fix the detach issue and the warning:
    "
    stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach"
    "
    
    Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Add missing detach mailbox for emtrion emSBC-Argon [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu May 18 03:12:42 2023 +0200

    ARM: dts: stm32: Add missing detach mailbox for emtrion emSBC-Argon
    
    [ Upstream commit 0ee0ef38aa9f75f21b51f729dd42b2e932515188 ]
    
    Add missing "detach" mailbox to this board to permit the CPU to inform
    the remote processor on a detach. This signal allows the remote processor
    firmware to stop IPC communication and to reinitialize the resources for
    a re-attach.
    
    Without this mailbox, detach is not possible and kernel log contains the
    following warning to, so make sure all the STM32MP15xx platform DTs are
    in sync regarding the mailboxes to fix the detach issue and the warning:
    "
    stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach"
    "
    
    Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Add missing detach mailbox for Odyssey SoM [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu May 18 03:12:43 2023 +0200

    ARM: dts: stm32: Add missing detach mailbox for Odyssey SoM
    
    [ Upstream commit 966f04a89d77548e673de2c400abe0b2cf5c15db ]
    
    Add missing "detach" mailbox to this board to permit the CPU to inform
    the remote processor on a detach. This signal allows the remote processor
    firmware to stop IPC communication and to reinitialize the resources for
    a re-attach.
    
    Without this mailbox, detach is not possible and kernel log contains the
    following warning to, so make sure all the STM32MP15xx platform DTs are
    in sync regarding the mailboxes to fix the detach issue and the warning:
    "
    stm32-rproc 10000000.m4: mbox_request_channel_byname() could not locate channel named "detach"
    "
    
    Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on stm32mp15x-dkx boards")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: adopt generic iio bindings for adc channels on emstamp-argon [+ + +]
Author: Olivier Moysan <olivier.moysan@foss.st.com>
Date:   Tue May 30 14:45:34 2023 +0200

    ARM: dts: stm32: adopt generic iio bindings for adc channels on emstamp-argon
    
    [ Upstream commit c46e9b6cc98245f7264a8d15394d1f95d433abec ]
    
    Use STM32 ADC generic bindings instead of legacy bindings on
    emtrion GmbH Argon boards.
    
    The STM32 ADC specific binding to declare channels has been deprecated,
    hence adopt the generic IIO channels bindings, instead.
    The STM32MP151 device tree now exposes internal channels using the
    generic binding. This makes the change mandatory here to avoid a mixed
    use of legacy and generic binding, which is not supported by the driver.
    
    Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Stable-dep-of: 0ee0ef38aa9f ("ARM: dts: stm32: Add missing detach mailbox for emtrion emSBC-Argon")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Update to generic ADC channel binding on DHSOM systems [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Tue May 30 14:45:37 2023 +0200

    ARM: dts: stm32: Update to generic ADC channel binding on DHSOM systems
    
    [ Upstream commit 9bcfc3cdc903485a52c6f471f4ae96a41fa51803 ]
    
    The generic ADC channel binding is recommended over legacy one, update the
    DT to the modern binding. No functional change. For further details, see
    commit which adds the generic binding to STM32 ADC binding document:
    '664b9879f56e ("dt-bindings: iio: stm32-adc: add generic channel binding")'
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Stable-dep-of: deb7edbc27a6 ("ARM: dts: stm32: Add missing detach mailbox for DHCOM SoM")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: OMAP2+: Fix -Warray-bounds warning in _pwrdm_state_switch() [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Wed Jun 7 22:12:11 2023 -0600

    ARM: OMAP2+: Fix -Warray-bounds warning in _pwrdm_state_switch()
    
    commit 847fb80cc01a54bc827b02547bb8743bdb59ddab upstream.
    
    If function pwrdm_read_prev_pwrst() returns -EINVAL, we will end
    up accessing array pwrdm->state_counter through negative index
    -22. This is wrong and the compiler is legitimately warning us
    about this potential problem.
    
    Fix this by sanity checking the value stored in variable _prev_
    before accessing array pwrdm->state_counter.
    
    Address the following -Warray-bounds warning:
    arch/arm/mach-omap2/powerdomain.c:178:45: warning: array subscript -22 is below array bounds of 'unsigned int[4]' [-Warray-bounds]
    
    Link: https://github.com/KSPP/linux/issues/307
    Fixes: ba20bb126940 ("OMAP: PM counter infrastructure.")
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/lkml/20230607050639.LzbPn%25lkp@intel.com/
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Message-ID: <ZIFVGwImU3kpaGeH@work>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: ptrace: Restore syscall restart tracing [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Aug 10 12:54:18 2023 -0700

    ARM: ptrace: Restore syscall restart tracing
    
    [ Upstream commit cf007647475b5090819c5fe8da771073145c7334 ]
    
    Since commit 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store
    thread_info->abi_syscall"), the seccomp selftests "syscall_restart" has
    been broken. This was caused by the restart syscall not being stored to
    "abi_syscall" during restart setup before branching to the "local_restart"
    label. Tracers would see the wrong syscall, and scno would get overwritten
    while returning from the TIF_WORK path. Add the missing store.
    
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Arnd Bergmann <arnd@kernel.org>
    Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Fixes: 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall")
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20230810195422.2304827-1-keescook@chromium.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: ptrace: Restore syscall skipping for tracers [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Aug 10 12:54:19 2023 -0700

    ARM: ptrace: Restore syscall skipping for tracers
    
    [ Upstream commit 4697b5848bd933f68ebd04836362c8de0cacaf71 ]
    
    Since commit 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store
    thread_info->abi_syscall"), the seccomp selftests "syscall_errno"
    and "syscall_faked" have been broken. Both seccomp and PTRACE depend
    on using the special value of "-1" for skipping syscalls. This value
    wasn't working because it was getting masked by __NR_SYSCALL_MASK in
    both PTRACE_SET_SYSCALL and get_syscall_nr().
    
    Explicitly test for -1 in PTRACE_SET_SYSCALL and get_syscall_nr(),
    leaving it exposed when present, allowing tracers to skip syscalls
    again.
    
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Arnd Bergmann <arnd@kernel.org>
    Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Fixes: 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall")
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20230810195422.2304827-2-keescook@chromium.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: atmel: Fix the 8K sample parameter in I2SC master [+ + +]
Author: Guiting Shen <aarongt.shen@gmail.com>
Date:   Sat Jul 15 11:06:20 2023 +0800

    ASoC: atmel: Fix the 8K sample parameter in I2SC master
    
    [ Upstream commit f85739c0b2b0d98a32f5ca4fcc5501d2b76df4f6 ]
    
    The 8K sample parameter of 12.288Mhz main system bus clock doesn't work
    because the I2SC_MR.IMCKDIV must not be 0 according to the sama5d2
    series datasheet(I2SC Mode Register of Register Summary).
    
    So use the 6.144Mhz instead of 12.288Mhz to support 8K sample.
    
    Signed-off-by: Guiting Shen <aarongt.shen@gmail.com>
    Link: https://lore.kernel.org/r/20230715030620.62328-1-aarongt.shen@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoc: codecs: ES8316: Fix DMIC config [+ + +]
Author: Edgar <ljijcj@163.com>
Date:   Wed Jul 19 13:47:22 2023 +0800

    ASoc: codecs: ES8316: Fix DMIC config
    
    [ Upstream commit d20d35d1ad62c6cca36368c1e8f29335a068659e ]
    
    According to the datasheet, the DMIC config should
    be changed to { 0, 2 ,3 }
    
    Signed-off-by: Edgar <ljijcj@163.com>
    Link: https://lore.kernel.org/r/20230719054722.401954-1-ljijcj@163.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: cs35l56: Add an ACPI match table [+ + +]
Author: Simon Trimmer <simont@opensource.cirrus.com>
Date:   Thu Aug 17 12:27:12 2023 +0100

    ASoC: cs35l56: Add an ACPI match table
    
    [ Upstream commit e8500a70270334b9abad72fea504ef38a2952274 ]
    
    An ACPI ID has been allocated for CS35L56 ASoC devices so that they can
    be instantiated from ACPI Device entries.
    
    Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20230817112712.16637-3-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs43130: Fix numerator/denominator mixup [+ + +]
Author: Phil Elwell <phil@raspberrypi.com>
Date:   Wed Jun 21 16:32:29 2023 +0100

    ASoC: cs43130: Fix numerator/denominator mixup
    
    [ Upstream commit a9e7c964cea4fb1541cc81a11d1b2fd135f4cf38 ]
    
    In converting to using the standard u16_fract type, commit [1] made the
    obvious mistake and failed to take account of the difference in
    numerator and denominator ordering, breaking all uses of the cs43130
    codec.
    
    Fix it.
    
    [1] commit e14bd35ef446 ("ASoC: cs43130: Re-use generic struct u16_fract")
    
    Fixes: e14bd35ef446 ("ASoC: cs43130: Re-use generic struct u16_fract")
    Signed-off-by: Phil Elwell <phil@raspberrypi.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20230621153229.1944132-1-phil@raspberrypi.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: da7219: Check for failure reading AAD IRQ events [+ + +]
Author: Dmytro Maluka <dmy@semihalf.com>
Date:   Mon Jul 17 21:37:37 2023 +0200

    ASoC: da7219: Check for failure reading AAD IRQ events
    
    [ Upstream commit f0691dc16206f21b13c464434366e2cd632b8ed7 ]
    
    When handling an AAD interrupt, if IRQ events read failed (for example,
    due to i2c "Transfer while suspended" failure, i.e. when attempting to
    read it while DA7219 is suspended, which may happen due to a spurious
    AAD interrupt), the events array contains garbage uninitialized values.
    So instead of trying to interprete those values and doing any actions
    based on them (potentially resulting in misbehavior, e.g. reporting
    bogus events), refuse to handle the interrupt.
    
    Signed-off-by: Dmytro Maluka <dmy@semihalf.com>
    Link: https://lore.kernel.org/r/20230717193737.161784-3-dmy@semihalf.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: da7219: Flush pending AAD IRQ when suspending [+ + +]
Author: Dmytro Maluka <dmy@semihalf.com>
Date:   Mon Jul 17 21:37:36 2023 +0200

    ASoC: da7219: Flush pending AAD IRQ when suspending
    
    [ Upstream commit 91e292917dad64ab8d1d5ca2ab3069ad9dac6f72 ]
    
    da7219_aad_suspend() disables jack detection, which should prevent
    generating new interrupts by DA7219 while suspended. However, there is a
    theoretical possibility that there is a pending interrupt generated just
    before suspending DA7219 and not handled yet, so the IRQ handler may
    still run after DA7219 is suspended. To prevent that, wait until the
    pending IRQ handling is done.
    
    This patch arose as an attempt to fix the following I2C failure
    occurring sometimes during system suspend or resume:
    
    [  355.876211] i2c_designware i2c_designware.3: Transfer while suspended
    [  355.876245] WARNING: CPU: 2 PID: 3576 at drivers/i2c/busses/i2c-designware-master.c:570 i2c_dw_xfer+0x411/0x440
    ...
    [  355.876462] Call Trace:
    [  355.876468]  <TASK>
    [  355.876475]  ? update_load_avg+0x1b3/0x615
    [  355.876484]  __i2c_transfer+0x101/0x1d8
    [  355.876494]  i2c_transfer+0x74/0x10d
    [  355.876504]  regmap_i2c_read+0x6a/0x9c
    [  355.876513]  _regmap_raw_read+0x179/0x223
    [  355.876521]  regmap_raw_read+0x1e1/0x28e
    [  355.876527]  regmap_bulk_read+0x17d/0x1ba
    [  355.876532]  ? __wake_up+0xed/0x1bb
    [  355.876542]  da7219_aad_irq_thread+0x54/0x2c9 [snd_soc_da7219 5fb8ebb2179cf2fea29af090f3145d68ed8e2184]
    [  355.876556]  irq_thread+0x13c/0x231
    [  355.876563]  ? irq_forced_thread_fn+0x5f/0x5f
    [  355.876570]  ? irq_thread_fn+0x4d/0x4d
    [  355.876576]  kthread+0x13a/0x152
    [  355.876581]  ? synchronize_irq+0xc3/0xc3
    [  355.876587]  ? kthread_blkcg+0x31/0x31
    [  355.876592]  ret_from_fork+0x1f/0x30
    [  355.876601]  </TASK>
    
    which indicates that the AAD IRQ handler is unexpectedly running when
    DA7219 is suspended, and as a result, is trying to read data from DA7219
    over I2C and is hitting the I2C driver "Transfer while suspended"
    failure.
    
    However, with this patch the above failure is still reproducible. So
    this patch does not fix any real observed issue so far, but at least is
    useful for confirming that the above issue is not caused by a pending
    IRQ but rather looks like a DA7219 hardware issue with an IRQ
    unexpectedly generated after jack detection is already disabled.
    
    Signed-off-by: Dmytro Maluka <dmy@semihalf.com>
    Link: https://lore.kernel.org/r/20230717193737.161784-2-dmy@semihalf.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl: fsl_qmc_audio: Fix snd_pcm_format_t values handling [+ + +]
Author: Herve Codina <herve.codina@bootlin.com>
Date:   Wed Jul 26 18:16:20 2023 +0200

    ASoC: fsl: fsl_qmc_audio: Fix snd_pcm_format_t values handling
    
    [ Upstream commit 5befe22b3eebd07b334b2917f6d14ce7ee4c8404 ]
    
    Running sparse on fsl_qmc_audio (make C=1) raises the following warnings:
     fsl_qmc_audio.c:387:26: warning: restricted snd_pcm_format_t degrades to integer
     fsl_qmc_audio.c:389:59: warning: incorrect type in argument 1 (different base types)
     fsl_qmc_audio.c:389:59:    expected restricted snd_pcm_format_t [usertype] format
     fsl_qmc_audio.c:389:59:    got unsigned int [assigned] i
     fsl_qmc_audio.c:564:26: warning: restricted snd_pcm_format_t degrades to integer
     fsl_qmc_audio.c:569:50: warning: incorrect type in argument 1 (different base types)
     fsl_qmc_audio.c:569:50:    expected restricted snd_pcm_format_t [usertype] format
     fsl_qmc_audio.c:569:50:    got int [assigned] i
     fsl_qmc_audio.c:573:62: warning: incorrect type in argument 1 (different base types)
     fsl_qmc_audio.c:573:62:    expected restricted snd_pcm_format_t [usertype] format
     fsl_qmc_audio.c:573:62:    got int [assigned] i
    
    These warnings are due to snd_pcm_format_t values handling done in the
    driver. Some macros and functions exist to handle safely these values.
    
    Use dedicated macros and functions to remove these warnings.
    
    Fixes: 075c7125b11c ("ASoC: fsl: Add support for QMC audio")
    Signed-off-by: Herve Codina <herve.codina@bootlin.com>
    Link: https://lore.kernel.org/r/20230726161620.495298-1-herve.codina@bootlin.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: nau8821: Add DMI quirk mechanism for active-high jack-detect [+ + +]
Author: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Date:   Wed Jul 19 17:02:41 2023 -0300

    ASoC: nau8821: Add DMI quirk mechanism for active-high jack-detect
    
    [ Upstream commit 1bc40efdaf4a0ccfdb10a1c8e4b458f4764e8e5f ]
    
    Add a quirk mechanism to allow specifying that active-high jack-detection
    should be used on platforms where this info is not available in devicetree.
    
    And add an entry for the Positivo CW14Q01P-V2 to the DMI table, so that
    jack-detection will work properly on this laptop.
    
    Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
    Link: https://lore.kernel.org/r/20230719200241.4865-1-edson.drosdeck@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt1308-sdw: fix random louder sound [+ + +]
Author: Shuming Fan <shumingf@realtek.com>
Date:   Fri Aug 11 17:38:22 2023 +0800

    ASoC: rt1308-sdw: fix random louder sound
    
    [ Upstream commit 37aba3190891d4de189bd5192ee95220e295f34d ]
    
    This patch uses a vendor register to check whether the system hibernated ever.
    The driver will only set the preset when the driver brings up or the system hibernated.
    It will avoid the unknown issue that makes the speaker output louder and can't control the volume.
    
    Signed-off-by: Shuming Fan <shumingf@realtek.com
    Link: https://lore.kernel.org/r/20230811093822.37573-1-shumingf@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt5682-sdw: fix for JD event handling in ClockStop Mode0 [+ + +]
Author: Shuming Fan <shumingf@realtek.com>
Date:   Fri Jul 21 17:06:43 2023 +0800

    ASoC: rt5682-sdw: fix for JD event handling in ClockStop Mode0
    
    [ Upstream commit 02fb23d72720df2b6be3f29fc5787ca018eb92c3 ]
    
    When the system suspends, peripheral Imp-defined interrupt is disabled.
    When system level resume is invoked, the peripheral Imp-defined interrupts
    should be enabled to handle JD events.
    
    Signed-off-by: Shuming Fan <shumingf@realtek.com>
    Reported-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://lore.kernel.org/r/20230721090643.128213-1-shumingf@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt711-sdca: fix for JD event handling in ClockStop Mode0 [+ + +]
Author: Shuming Fan <shumingf@realtek.com>
Date:   Fri Jul 21 17:07:11 2023 +0800

    ASoC: rt711-sdca: fix for JD event handling in ClockStop Mode0
    
    [ Upstream commit 23adeb7056acd4fd866969f4afb91441776cc4f5 ]
    
    When the system suspends, peripheral SDCA interrupts are disabled.
    When system level resume is invoked, the peripheral SDCA interrupts
    should be enabled to handle JD events.
    Enable SDCA interrupts in resume sequence when ClockStop Mode0 is applied.
    
    Signed-off-by: Shuming Fan <shumingf@realtek.com>
    Reported-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://lore.kernel.org/r/20230721090711.128247-1-shumingf@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt711: fix for JD event handling in ClockStop Mode0 [+ + +]
Author: Shuming Fan <shumingf@realtek.com>
Date:   Fri Jul 21 17:06:54 2023 +0800

    ASoC: rt711: fix for JD event handling in ClockStop Mode0
    
    [ Upstream commit b69de265bd0e877015a00fbba453ef72af162e0f ]
    
    When the system suspends, peripheral Imp-defined interrupt is disabled.
    When system level resume is invoked, the peripheral Imp-defined interrupts
    should be enabled to handle JD events.
    
    Signed-off-by: Shuming Fan <shumingf@realtek.com>
    Reported-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://lore.kernel.org/r/20230721090654.128230-1-shumingf@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt712-sdca: fix for JD event handling in ClockStop Mode0 [+ + +]
Author: Shuming Fan <shumingf@realtek.com>
Date:   Fri Jul 21 17:07:21 2023 +0800

    ASoC: rt712-sdca: fix for JD event handling in ClockStop Mode0
    
    [ Upstream commit 7a8735c1551e489351172d0da96128f6f8b52b2d ]
    
    When the system suspends, peripheral SDCA interrupts are disabled.
    When system level resume is invoked, the peripheral SDCA interrupts
    should be enabled to handle JD events.
    Enable SDCA interrupts in resume sequence when ClockStop Mode0 is applied.
    
    Signed-off-by: Shuming Fan <shumingf@realtek.com>
    Reported-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://lore.kernel.org/r/20230721090721.128264-1-shumingf@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: soc-compress: Fix deadlock in soc_compr_open_fe [+ + +]
Author: yixuanjiang <yixuanjiang@google.com>
Date:   Mon Jun 19 11:31:27 2023 +0800

    ASoC: soc-compress: Fix deadlock in soc_compr_open_fe
    
    [ Upstream commit 2222214749a9969e09454b9ba7febfdfb09c1c8d ]
    
    Modify the error handling flow by release lock.
    The require mutex will keep holding if open fail.
    
    Fixes: aa9ff6a4955f ("ASoC: soc-compress: Reposition and add pcm_mutex")
    Signed-off-by: yixuanjiang <yixuanjiang@google.com>
    Link: https://lore.kernel.org/r/20230619033127.2522477-1-yixuanjiang@google.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: amd: clear dsp to host interrupt status [+ + +]
Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Date:   Wed Aug 23 13:03:39 2023 +0530

    ASoC: SOF: amd: clear dsp to host interrupt status
    
    [ Upstream commit 38592ae6dc9f84b7a994c43de2136b8115ca30f6 ]
    
    DSP_SW_INTR_STAT_OFFSET is a common interrupt register which will be
    accessed by both ACP firmware and driver. This register contains register
    bits corresponds to host to dsp interrupts and vice versa.
    
    when dsp to host interrupt is reported, only clear dsp to host
    interrupt bit in DSP_SW_INTR_STAT_OFFSET.
    
    Fixes: 2e7c6652f9b8 ("ASoC: SOF: amd: Fix for handling spurious interrupts from DSP")
    
    Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://lore.kernel.org/r/20230823073340.2829821-7-Vijendar.Mukunda@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: fix u16/32 confusion in LSDIID [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Aug 7 16:09:41 2023 -0500

    ASoC: SOF: Intel: fix u16/32 confusion in LSDIID
    
    [ Upstream commit 7a52d7062e02af4a479da24b40cfd76b54c0cd6c ]
    
    Likely a combination of copy-paste and test coverage problem. Oops.
    
    Fixes: 87a6ddc0cf1c ("ASoC: SOF: Intel: hda-mlink: program SoundWire LSDIID registers")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Link: https://lore.kernel.org/r/20230807210959.506849-3-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: hda-mlink: fix off-by-one error [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Aug 7 16:09:40 2023 -0500

    ASoC: SOF: Intel: hda-mlink: fix off-by-one error
    
    [ Upstream commit 7075b0c91b3cd5d32b4ac7403f771a3253d3fbf6 ]
    
    The HCHAN parameter should be the highest channel number, not the
    channel count.
    
    While we're at it, handle LCHAN with the dual __ffs helper.
    
    Fixes: ccc2f0c1b6b6 ("ASoC: SOF: Intel: hda-mlink: add helper to program SoundWire PCMSyCM registers")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Link: https://lore.kernel.org/r/20230807210959.506849-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: stac9766: fix build errors with REGMAP_AC97 [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Jun 30 21:48:36 2023 -0700

    ASoC: stac9766: fix build errors with REGMAP_AC97
    
    [ Upstream commit c70064b96f509daa78f57992aeabcf274fb2fed4 ]
    
    Select REGMAP_AC97 to fix these build errors:
    
    ERROR: modpost: "regmap_ac97_default_volatile" [sound/soc/codecs/snd-soc-stac9766.ko] undefined!
    ERROR: modpost: "__regmap_init_ac97" [sound/soc/codecs/snd-soc-stac9766.ko] undefined!
    
    Fixes: 6bbf787bb70c ("ASoC: stac9766: Convert to regmap")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Liam Girdwood <lgirdwood@gmail.com>
    Cc: alsa-devel@alsa-project.org
    Link: https://lore.kernel.org/r/20230701044836.18789-1-rdunlap@infradead.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: pata_arasan_cf: Use dev_err_probe() instead dev_err() in data_xfer() [+ + +]
Author: Minjie Du <duminjie@vivo.com>
Date:   Tue Jul 25 11:06:25 2023 +0800

    ata: pata_arasan_cf: Use dev_err_probe() instead dev_err() in data_xfer()
    
    [ Upstream commit 4139f992c49356391fb086c0c8ce51f66c26d623 ]
    
    It is possible for dma_request_chan() to return EPROBE_DEFER, which
    means acdev->host->dev is not ready yet. At this point dev_err() will
    have no output. Use dev_err_probe() instead.
    
    Signed-off-by: Minjie Du <duminjie@vivo.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
audit: fix possible soft lockup in __audit_inode_child() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Tue Aug 8 20:14:35 2023 +0800

    audit: fix possible soft lockup in __audit_inode_child()
    
    [ Upstream commit b59bc6e37237e37eadf50cd5de369e913f524463 ]
    
    Tracefs or debugfs maybe cause hundreds to thousands of PATH records,
    too many PATH records maybe cause soft lockup.
    
    For example:
      1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n
      2. auditctl -a exit,always -S open -k key
      3. sysctl -w kernel.watchdog_thresh=5
      4. mkdir /sys/kernel/debug/tracing/instances/test
    
    There may be a soft lockup as follows:
      watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498]
      Kernel panic - not syncing: softlockup: hung tasks
      Call trace:
       dump_backtrace+0x0/0x30c
       show_stack+0x20/0x30
       dump_stack+0x11c/0x174
       panic+0x27c/0x494
       watchdog_timer_fn+0x2bc/0x390
       __run_hrtimer+0x148/0x4fc
       __hrtimer_run_queues+0x154/0x210
       hrtimer_interrupt+0x2c4/0x760
       arch_timer_handler_phys+0x48/0x60
       handle_percpu_devid_irq+0xe0/0x340
       __handle_domain_irq+0xbc/0x130
       gic_handle_irq+0x78/0x460
       el1_irq+0xb8/0x140
       __audit_inode_child+0x240/0x7bc
       tracefs_create_file+0x1b8/0x2a0
       trace_create_file+0x18/0x50
       event_create_dir+0x204/0x30c
       __trace_add_new_event+0xac/0x100
       event_trace_add_tracer+0xa0/0x130
       trace_array_create_dir+0x60/0x140
       trace_array_create+0x1e0/0x370
       instance_mkdir+0x90/0xd0
       tracefs_syscall_mkdir+0x68/0xa0
       vfs_mkdir+0x21c/0x34c
       do_mkdirat+0x1b4/0x1d4
       __arm64_sys_mkdirat+0x4c/0x60
       el0_svc_common.constprop.0+0xa8/0x240
       do_el0_svc+0x8c/0xc0
       el0_svc+0x20/0x30
       el0_sync_handler+0xb0/0xb4
       el0_sync+0x160/0x180
    
    Therefore, we add cond_resched() to __audit_inode_child() to fix it.
    
    Fixes: 5195d8e217a7 ("audit: dynamically allocate audit_names when not enough space is in the names array")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
backlight/bd6107: Compare against struct fb_info.device [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Tue Jun 13 13:06:36 2023 +0200

    backlight/bd6107: Compare against struct fb_info.device
    
    commit 992bdddaabfba19bdc77c1c7a4977b2aa41ec891 upstream.
    
    Struct bd6107_platform_data refers to a platform device within
    the Linux device hierarchy. The test in bd6107_backlight_check_fb()
    compares it against the fbdev device in struct fb_info.dev, which
    is different. Fix the test by comparing to struct fb_info.device.
    
    Fixes a bug in the backlight driver and prepares fbdev for making
    struct fb_info.dev optional.
    
    v2:
            * move renames into separate patch (Javier, Sam, Michael)
    
    Fixes: 67b43e590415 ("backlight: Add ROHM BD6107 backlight driver")
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Cc: Lee Jones <lee@kernel.org>
    Cc: Daniel Thompson <daniel.thompson@linaro.org>
    Cc: Jingoo Han <jingoohan1@gmail.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v3.12+
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-2-tzimmermann@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
backlight/gpio_backlight: Compare against struct fb_info.device [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Tue Jun 13 13:06:38 2023 +0200

    backlight/gpio_backlight: Compare against struct fb_info.device
    
    commit 7b91d017f77c1bda56f27c2f4bbb70de7c6eca08 upstream.
    
    Struct gpio_backlight_platform_data refers to a platform device within
    the Linux device hierarchy. The test in gpio_backlight_check_fb()
    compares it against the fbdev device in struct fb_info.dev, which
    is different. Fix the test by comparing to struct fb_info.device.
    
    Fixes a bug in the backlight driver and prepares fbdev for making
    struct fb_info.dev optional.
    
    v2:
            * move renames into separate patch (Javier, Sam, Michael)
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
    Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Cc: Rich Felker <dalias@libc.org>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Lee Jones <lee@kernel.org>
    Cc: Daniel Thompson <daniel.thompson@linaro.org>
    Cc: Jingoo Han <jingoohan1@gmail.com>
    Cc: linux-sh@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v3.12+
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-4-tzimmermann@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
backlight/lv5207lp: Compare against struct fb_info.device [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Tue Jun 13 13:06:40 2023 +0200

    backlight/lv5207lp: Compare against struct fb_info.device
    
    commit 1ca8819320fd84e7d95b04e7668efc5f9fe9fa5c upstream.
    
    Struct lv5207lp_platform_data refers to a platform device within
    the Linux device hierarchy. The test in lv5207lp_backlight_check_fb()
    compares it against the fbdev device in struct fb_info.dev, which
    is different. Fix the test by comparing to struct fb_info.device.
    
    Fixes a bug in the backlight driver and prepares fbdev for making
    struct fb_info.dev optional.
    
    v2:
            * move renames into separate patch (Javier, Sam, Michael)
    
    Fixes: 82e5c40d88f9 ("backlight: Add Sanyo LV5207LP backlight driver")
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Lee Jones <lee@kernel.org>
    Cc: Daniel Thompson <daniel.thompson@linaro.org>
    Cc: Jingoo Han <jingoohan1@gmail.com>
    Cc: linux-sh@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v3.12+
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-6-tzimmermann@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Aug 16 09:56:23 2023 -1000

    blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init
    
    [ Upstream commit ec14a87ee1999b19d8b7ed0fa95fea80644624ae ]
    
    blk-iocost sometimes causes the following crash:
    
      BUG: kernel NULL pointer dereference, address: 00000000000000e0
      ...
      RIP: 0010:_raw_spin_lock+0x17/0x30
      Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 <f0> 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00
      RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046
      RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001
      RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0
      RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003
      R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000
      R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600
      FS:  00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0
      Call Trace:
       <TASK>
       ioc_weight_write+0x13d/0x410
       cgroup_file_write+0x7a/0x130
       kernfs_fop_write_iter+0xf5/0x170
       vfs_write+0x298/0x370
       ksys_write+0x5f/0xb0
       __x64_sys_write+0x1b/0x20
       do_syscall_64+0x3d/0x80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    This happens because iocg->ioc is NULL. The field is initialized by
    ioc_pd_init() and never cleared. The NULL deref is caused by
    blkcg_activate_policy() installing blkg_policy_data before initializing it.
    
    blkcg_activate_policy() was doing the following:
    
    1. Allocate pd's for all existing blkg's and install them in blkg->pd[].
    2. Initialize all pd's.
    3. Online all pd's.
    
    blkcg_activate_policy() only grabs the queue_lock and may release and
    re-acquire the lock as allocation may need to sleep. ioc_weight_write()
    grabs blkcg->lock and iterates all its blkg's. The two can race and if
    ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a
    pd which is not initialized yet, leading to crash.
    
    The crash can be reproduced with the following script:
    
      #!/bin/bash
    
      echo +io > /sys/fs/cgroup/cgroup.subtree_control
      systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct
      echo 100 > /sys/fs/cgroup/system.slice/io.weight
      bash -c "echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos" &
      sleep .2
      echo 100 > /sys/fs/cgroup/system.slice/io.weight
    
    with the following patch applied:
    
    > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
    > index fc49be622e05..38d671d5e10c 100644
    > --- a/block/blk-cgroup.c
    > +++ b/block/blk-cgroup.c
    > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol)
    >               pd->online = false;
    >       }
    >
    > +       if (system_state == SYSTEM_RUNNING) {
    > +               spin_unlock_irq(&q->queue_lock);
    > +               ssleep(1);
    > +               spin_lock_irq(&q->queue_lock);
    > +       }
    > +
    >       /* all allocated, init in the same order */
    >       if (pol->pd_init_fn)
    >               list_for_each_entry_reverse(blkg, &q->blkg_list, q_node)
    
    I don't see a reason why all pd's should be allocated, initialized and
    onlined together. The only ordering requirement is that parent blkgs to be
    initialized and onlined before children, which is guaranteed from the
    walking order. Let's fix the bug by allocating, initializing and onlining pd
    for each blkg and holding blkcg->lock over initialization and onlining. This
    ensures that an installed blkg is always fully initialized and onlined
    removing the the race window.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Breno Leitao <leitao@debian.org>
    Fixes: 9d179b865449 ("blkcg: Fix multiple bugs in blkcg_activate_policy()")
    Link: https://lore.kernel.org/r/ZN0p5_W-Q9mAHBVY@slm.duckdns.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block/mq-deadline: use correct way to throttling write requests [+ + +]
Author: Zhiguo Niu <zhiguo.niu@unisoc.com>
Date:   Thu Aug 3 19:12:42 2023 +0800

    block/mq-deadline: use correct way to throttling write requests
    
    [ Upstream commit d47f9717e5cfd0dd8c0ba2ecfa47c38d140f1bb6 ]
    
    The original formula was inaccurate:
    dd->async_depth = max(1UL, 3 * q->nr_requests / 4);
    
    For write requests, when we assign a tags from sched_tags,
    data->shallow_depth will be passed to sbitmap_find_bit,
    see the following code:
    
    nr = sbitmap_find_bit_in_word(&sb->map[index],
                            min_t (unsigned int,
                            __map_depth(sb, index),
                            depth),
                            alloc_hint, wrap);
    
    The smaller of data->shallow_depth and __map_depth(sb, index)
    will be used as the maximum range when allocating bits.
    
    For a mmc device (one hw queue, deadline I/O scheduler):
    q->nr_requests = sched_tags = 128, so according to the previous
    calculation method, dd->async_depth = data->shallow_depth = 96,
    and the platform is 64bits with 8 cpus, sched_tags.bitmap_tags.sb.shift=5,
    sb.maps[]=32/32/32/32, 32 is smaller than 96, whether it is a read or
    a write I/O, tags can be allocated to the maximum range each time,
    which has not throttling effect.
    
    In addition, refer to the methods of bfg/kyber I/O scheduler,
    limit ratiois are calculated base on sched_tags.bitmap_tags.sb.shift.
    
    This patch can throttle write requests really.
    
    Fixes: 07757588e507 ("block/mq-deadline: Reserve 25% of scheduler tags for synchronous requests")
    
    Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/1691061162-22898-1-git-send-email-zhiguo.niu@unisoc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: cleanup queue_wc_store [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jul 7 11:42:38 2023 +0200

    block: cleanup queue_wc_store
    
    [ Upstream commit c4e21bcd0f9d01f9c5d6c52007f5541871a5b1de ]
    
    Get rid of the local queue_wc_store variable and handling setting and
    clearing the QUEUE_FLAG_WC flag diretly instead the if / else if.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230707094239.107968-2-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: 43c9835b144c ("block: don't allow enabling a cache on devices that don't support it")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: don't add or resize partition on the disk with GENHD_FL_NO_PART [+ + +]
Author: Li Lingfeng <lilingfeng3@huawei.com>
Date:   Thu Aug 31 15:59:00 2023 +0800

    block: don't add or resize partition on the disk with GENHD_FL_NO_PART
    
    commit 1a721de8489fa559ff4471f73c58bb74ac5580d3 upstream.
    
    Commit a33df75c6328 ("block: use an xarray for disk->part_tbl") remove
    disk_expand_part_tbl() in add_partition(), which means all kinds of
    devices will support extended dynamic `dev_t`.
    However, some devices with GENHD_FL_NO_PART are not expected to add or
    resize partition.
    Fix this by adding check of GENHD_FL_NO_PART before add or resize
    partition.
    
    Fixes: a33df75c6328 ("block: use an xarray for disk->part_tbl")
    Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230831075900.1725842-1-lilingfeng@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

block: don't allow enabling a cache on devices that don't support it [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jul 7 11:42:39 2023 +0200

    block: don't allow enabling a cache on devices that don't support it
    
    [ Upstream commit 43c9835b144c7ce29efe142d662529662a9eb376 ]
    
    Currently the write_cache attribute allows enabling the QUEUE_FLAG_WC
    flag on devices that never claimed the capability.
    
    Fix that by adding a QUEUE_FLAG_HW_WC flag that is set by
    blk_queue_write_cache and guards re-enabling the cache through sysfs.
    
    Note that any rescan that calls blk_queue_write_cache will still
    re-enable the write cache as in the current code.
    
    Fixes: 93e9d8e836cb ("block: add ability to flag write back caching on a device")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230707094239.107968-3-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: btrtl: Load FW v2 otherwise FW v1 for RTL8852C [+ + +]
Author: Max Chou <max.chou@realtek.com>
Date:   Mon Aug 7 19:42:59 2023 +0800

    Bluetooth: btrtl: Load FW v2 otherwise FW v1 for RTL8852C
    
    commit bd003fb338afee97c76f13c3e9144a7e4ad37179 upstream.
    
    In this commit, prefer to load FW v2 if available. Fallback to FW v1
    otherwise. This behavior is only for RTL8852C.
    
    Fixes: 9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support")
    Cc: stable@vger.kernel.org
    Suggested-by: Juerg Haefliger <juerg.haefliger@canonical.com>
    Tested-by: Hilda Wu <hildawu@realtek.com>
    Signed-off-by: Max Chou <max.chou@realtek.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    [juergh: Adjusted context due to missing .hw_info struct element]
    Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: btusb: Do not call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Aug 23 11:46:37 2023 +0800

    Bluetooth: btusb: Do not call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 2a05334d7f91ff189692089c05fc48cc1d8204de ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with hardware interrupts being disabled.
    So replace kfree_skb() with dev_kfree_skb_irq() under
    spin_lock_irqsave(). Compile tested only.
    
    Fixes: baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Fix potential use-after-free when clear keys [+ + +]
Author: Min Li <lm0963hack@gmail.com>
Date:   Mon Aug 7 19:07:41 2023 +0800

    Bluetooth: Fix potential use-after-free when clear keys
    
    [ Upstream commit 3673952cf0c6cf81b06c66a0b788abeeb02ff3ae ]
    
    Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in
    hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu()
    call.
    
    Fixes: d7d41682efc2 ("Bluetooth: Fix Suspicious RCU usage warnings")
    Signed-off-by: Min Li <lm0963hack@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Aug 22 12:02:03 2023 -0700

    Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED
    
    [ Upstream commit 253f3399f4c09ce6f4e67350f839be0361b4d5ff ]
    
    This introduces HCI_QUIRK_BROKEN_LE_CODED which is used to indicate
    that LE Coded PHY shall not be used, it is then set for some Intel
    models that claim to support it but when used causes many problems.
    
    Cc: stable@vger.kernel.org # 6.4.y+
    Link: https://github.com/bluez/bluez/issues/577
    Link: https://github.com/bluez/bluez/issues/582
    Link: https://lore.kernel.org/linux-bluetooth/CABBYNZKco-v7wkjHHexxQbgwwSz-S=GZ=dZKbRE1qxT1h4fFbQ@mail.gmail.com/T/#
    Fixes: 288c90224eec ("Bluetooth: Enable all supported LE PHY by default")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Always allocate unique handles [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Jun 28 12:15:53 2023 -0700

    Bluetooth: hci_conn: Always allocate unique handles
    
    [ Upstream commit 9f78191cc9f1b34c2e2afd7b554a83bf034092dd ]
    
    This attempts to always allocate a unique handle for connections so they
    can be properly aborted by the likes of hci_abort_conn, so this uses the
    invalid range as a pool of unset handles that way if userspace is trying
    to create multiple connections at once each will be given a unique
    handle which will be considered unset.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 66dee21524d9 ("Bluetooth: hci_event: drop only unbound CIS if Set CIG Parameters fails")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Consolidate code for aborting connections [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Jun 26 17:25:06 2023 -0700

    Bluetooth: hci_conn: Consolidate code for aborting connections
    
    [ Upstream commit a13f316e90fdb1fb6df6582e845aa9b3270f3581 ]
    
    This consolidates code for aborting connections using
    hci_cmd_sync_queue so it is synchronized with other threads, but
    because of the fact that some commands may block the cmd_sync_queue
    while waiting specific events this attempt to cancel those requests by
    using hci_cmd_sync_cancel.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early [+ + +]
Author: Pauli Virtanen <pav@iki.fi>
Date:   Sat Aug 19 16:33:36 2023 +0300

    Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early
    
    [ Upstream commit 3344d318337d9dca928fd448e966557ec5063f85 ]
    
    Not calling hci_(dis)connect_cfm before deleting conn referred to by a
    socket generally results to use-after-free.
    
    When cleaning up SCO connections when the parent ACL is deleted too
    early, use hci_conn_failed to do the connection cleanup properly.
    
    We also need to clean up ISO connections in a similar situation when
    connecting has started but LE Create CIS is not yet sent, so do it too
    here.
    
    Fixes: ca1fd42e7dbf ("Bluetooth: Fix potential double free caused by hci_conn_unlink")
    Reported-by: syzbot+cf54c1da6574b6c1b049@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-bluetooth/00000000000013b93805fbbadc50@google.com/
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Fix hci_le_set_cig_params [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Aug 4 14:54:09 2023 -0700

    Bluetooth: hci_conn: Fix hci_le_set_cig_params
    
    [ Upstream commit a091289218202bc09d9b9caa8afcde1018584aec ]
    
    When running with concurrent task only one CIS was being assigned so
    this attempts to rework the way the PDU is constructed so it is handled
    later at the callback instead of in place.
    
    Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Fix not allowing valid CIS ID [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Aug 3 16:41:34 2023 -0700

    Bluetooth: hci_conn: Fix not allowing valid CIS ID
    
    [ Upstream commit f2f84a70f9d0c9a3263194ca9d82e7bc6027d356 ]
    
    Only the number of CIS shall be limited to 0x1f, the CIS ID in the
    other hand is up to 0xef.
    
    Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Use kmemdup() to replace kzalloc + memcpy [+ + +]
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Sun Jun 25 16:45:13 2023 +0800

    Bluetooth: hci_conn: Use kmemdup() to replace kzalloc + memcpy
    
    [ Upstream commit 5b6d345d1b65d67624349e5de22227492c637576 ]
    
    Use kmemdup rather than duplicating its implementation.
    
    ./net/bluetooth/hci_conn.c:1880:7-14: WARNING opportunity for kmemdup.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5597
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a09128921820 ("Bluetooth: hci_conn: Fix hci_le_set_cig_params")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_event: drop only unbound CIS if Set CIG Parameters fails [+ + +]
Author: Pauli Virtanen <pav@iki.fi>
Date:   Sat Aug 5 19:08:41 2023 +0300

    Bluetooth: hci_event: drop only unbound CIS if Set CIG Parameters fails
    
    [ Upstream commit 66dee21524d9ac6461ec3052652b7bc0603ee0c5 ]
    
    When user tries to connect a new CIS when its CIG is not configurable,
    that connection shall fail, but pre-existing connections shall not be
    affected.  However, currently hci_cc_le_set_cig_params deletes all CIS
    of the CIG on error so it doesn't work, even though controller shall not
    change CIG/CIS configuration if the command fails.
    
    Fix by failing on command error only the connections that are not yet
    bound, so that we keep the previous CIS configuration like the
    controller does.
    
    Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections")
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_event: Fix parsing of CIS Established Event [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Jun 20 15:41:11 2023 -0700

    Bluetooth: hci_event: Fix parsing of CIS Established Event
    
    [ Upstream commit 2be22f1941d5f661aa8043261d1bae5b6696c749 ]
    
    The ISO Interval on CIS Established Event uses 1.25 ms slots:
    
        BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E
        page 2304:
    
          Time = N * 1.25 ms
    
    In addition to that this always update the QoS settings based on CIS
    Established Event.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 7f74563e6140 ("Bluetooth: ISO: do not emit new LE Create CIS if previous is pending")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor() [+ + +]
Author: Manish Mandlik <mmandlik@google.com>
Date:   Fri Aug 4 11:14:45 2023 -0700

    Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()
    
    [ Upstream commit a2bcd2b63271a93a695fabbfbf459c603d956d48 ]
    
    KSAN reports use-after-free in hci_add_adv_monitor().
    
    While adding an adv monitor,
        hci_add_adv_monitor() calls ->
        msft_add_monitor_pattern() calls ->
        msft_add_monitor_sync() calls ->
        msft_le_monitor_advertisement_cb() calls in an error case ->
        hci_free_adv_monitor() which frees the *moniter.
    
    This is referenced by bt_dev_dbg() in hci_add_adv_monitor().
    
    Fix the bt_dev_dbg() by using handle instead of monitor->handle.
    
    Fixes: b747a83690c8 ("Bluetooth: hci_sync: Refactor add Adv Monitor")
    Signed-off-by: Manish Mandlik <mmandlik@google.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Don't double print name in add/remove adv_monitor [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri Jun 30 15:33:15 2023 -0700

    Bluetooth: hci_sync: Don't double print name in add/remove adv_monitor
    
    [ Upstream commit 6f55eea116ba3646fb5fbb31de703f8cf79d8214 ]
    
    The hci_add_adv_monitor() hci_remove_adv_monitor() functions call
    bt_dev_dbg() to print some debug statements. The bt_dev_dbg() macro
    automatically adds in the device's name. That means that we shouldn't
    include the name in the bt_dev_dbg() calls.
    
    Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: a2bcd2b63271 ("Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Aug 9 16:49:33 2023 -0700

    Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync
    
    [ Upstream commit 94d9ba9f9888b748d4abd2aa1547af56ae85f772 ]
    
    Use-after-free can occur in hci_disconnect_all_sync if a connection is
    deleted by concurrent processing of a controller event.
    
    To prevent this the code now tries to iterate over the list backwards
    to ensure the links are cleanup before its parents, also it no longer
    relies on a cursor, instead it always uses the last element since
    hci_abort_conn_sync is guaranteed to call hci_conn_del.
    
    UAF crash log:
    ==================================================================
    BUG: KASAN: slab-use-after-free in hci_set_powered_sync
    (net/bluetooth/hci_sync.c:5424) [bluetooth]
    Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124
    
    CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G        W
    6.5.0-rc1+ #10
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
    1.16.2-1.fc38 04/01/2014
    Workqueue: hci0 hci_cmd_sync_work [bluetooth]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x5b/0x90
     print_report+0xcf/0x670
     ? __virt_addr_valid+0xdd/0x160
     ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]
     kasan_report+0xa6/0xe0
     ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]
     ? __pfx_set_powered_sync+0x10/0x10 [bluetooth]
     hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]
     ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth]
     ? __pfx_lock_release+0x10/0x10
     ? __pfx_set_powered_sync+0x10/0x10 [bluetooth]
     hci_cmd_sync_work+0x137/0x220 [bluetooth]
     process_one_work+0x526/0x9d0
     ? __pfx_process_one_work+0x10/0x10
     ? __pfx_do_raw_spin_lock+0x10/0x10
     ? mark_held_locks+0x1a/0x90
     worker_thread+0x92/0x630
     ? __pfx_worker_thread+0x10/0x10
     kthread+0x196/0x1e0
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2c/0x50
     </TASK>
    
    Allocated by task 1782:
     kasan_save_stack+0x33/0x60
     kasan_set_track+0x25/0x30
     __kasan_kmalloc+0x8f/0xa0
     hci_conn_add+0xa5/0xa80 [bluetooth]
     hci_bind_cis+0x881/0x9b0 [bluetooth]
     iso_connect_cis+0x121/0x520 [bluetooth]
     iso_sock_connect+0x3f6/0x790 [bluetooth]
     __sys_connect+0x109/0x130
     __x64_sys_connect+0x40/0x50
     do_syscall_64+0x60/0x90
     entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
    Freed by task 695:
     kasan_save_stack+0x33/0x60
     kasan_set_track+0x25/0x30
     kasan_save_free_info+0x2b/0x50
     __kasan_slab_free+0x10a/0x180
     __kmem_cache_free+0x14d/0x2e0
     device_release+0x5d/0xf0
     kobject_put+0xdf/0x270
     hci_disconn_complete_evt+0x274/0x3a0 [bluetooth]
     hci_event_packet+0x579/0x7e0 [bluetooth]
     hci_rx_work+0x287/0xaa0 [bluetooth]
     process_one_work+0x526/0x9d0
     worker_thread+0x92/0x630
     kthread+0x196/0x1e0
     ret_from_fork+0x2c/0x50
    ==================================================================
    
    Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier")
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Aug 3 11:04:51 2023 -0700

    Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync
    
    [ Upstream commit 5af1f84ed13a416297ab9ced7537f4d5ae7f329a ]
    
    Connections may be cleanup while waiting for the commands to complete so
    this attempts to check if the connection handle remains valid in case of
    errors that would lead to call hci_conn_failed:
    
    BUG: KASAN: slab-use-after-free in hci_conn_failed+0x1f/0x160
    Read of size 8 at addr ffff888001376958 by task kworker/u3:0/52
    
    CPU: 0 PID: 52 Comm: kworker/u3:0 Not tainted
    6.5.0-rc1-00527-g2dfe76d58d3a #5615
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
    1.16.2-1.fc38 04/01/2014
    Workqueue: hci0 hci_cmd_sync_work
    Call Trace:
     <TASK>
     dump_stack_lvl+0x1d/0x70
     print_report+0xce/0x620
     ? __virt_addr_valid+0xd4/0x150
     ? hci_conn_failed+0x1f/0x160
     kasan_report+0xd1/0x100
     ? hci_conn_failed+0x1f/0x160
     hci_conn_failed+0x1f/0x160
     hci_abort_conn_sync+0x237/0x360
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Add support for connecting multiple BISes [+ + +]
Author: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Date:   Tue May 30 17:21:59 2023 +0300

    Bluetooth: ISO: Add support for connecting multiple BISes
    
    [ Upstream commit a0bfde167b506423111ddb8cd71930497a40fc54 ]
    
    It is required for some configurations to have multiple BISes as part
    of the same BIG.
    
    Similar to the flow implemented for unicast, DEFER_SETUP will also be
    used to bind multiple BISes for the same BIG, before starting Periodic
    Advertising and creating the BIG.
    
    The user will have to open a new socket for each BIS. By setting the
    BT_DEFER_SETUP socket option and calling connect, a new connection
    will be added for the BIG and advertising handle set by the socket
    QoS parameters. Since all BISes will be bound for the same BIG and
    advertising handle, the socket QoS options and base parameters should
    match for all connections.
    
    By calling connect on a socket that does not have the BT_DEFER_SETUP
    option set, periodic advertising will be started and the BIG will
    be created, with a BIS for each previously bound connection. Since
    a BIG cannot be reconfigured with additional BISes after creation,
    no more connections can be bound for the BIG after the start periodic
    advertising and create BIG commands have been queued.
    
    The bis_cleanup function has also been updated, so that the advertising
    set and the BIG will not be terminated unless there are no more
    bound or connected BISes.
    
    The HCI_CONN_BIG_CREATED connection flag has been added to indicate
    that the BIG has been successfully created. This flag is checked at
    bis_cleanup, so that the BIG is only terminated if the
    HCI_LE_Create_BIG_Complete has been received.
    
    This implementation has been tested on hardware, using the "isotest"
    tool with an additional command line option, to specify the number of
    BISes to create as part of the desired BIG:
    
        tools/isotest -i hci0 -s 00:00:00:00:00:00 -N 2 -G 1 -T 1
    
    The btmon log shows that a BIG containing 2 BISes has been created:
    
    < HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31
            Handle: 0x01
            Advertising Handle: 0x01
            Number of BIS: 2
            SDU Interval: 10000 us (0x002710)
            Maximum SDU size: 40
            Maximum Latency: 10 ms (0x000a)
            RTN: 0x02
            PHY: LE 2M (0x02)
            Packing: Sequential (0x00)
            Framing: Unframed (0x00)
            Encryption: 0x00
            Broadcast Code: 00000000000000000000000000000000
    
    > HCI Event: Command Status (0x0f) plen 4
          LE Create Broadcast Isochronous Group (0x08|0x0068) ncmd 1
            Status: Success (0x00)
    
    > HCI Event: LE Meta Event (0x3e) plen 23
          LE Broadcast Isochronous Group Complete (0x1b)
            Status: Success (0x00)
            Handle: 0x01
            BIG Synchronization Delay: 1974 us (0x0007b6)
            Transport Latency: 1974 us (0x0007b6)
            PHY: LE 2M (0x02)
            NSE: 3
            BN: 1
            PTO: 1
            IRC: 3
            Maximum PDU: 40
            ISO Interval: 10.00 msec (0x0008)
            Connection Handle #0: 10
            Connection Handle #1: 11
    
    < HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13
            Handle: 10
            Data Path Direction: Input (Host to Controller) (0x00)
            Data Path: HCI (0x00)
            Coding Format: Transparent (0x03)
            Company Codec ID: Ericsson Technology Licensing (0)
            Vendor Codec ID: 0
            Controller Delay: 0 us (0x000000)
            Codec Configuration Length: 0
            Codec Configuration:
    
    > HCI Event: Command Complete (0x0e) plen 6
          LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
            Status: Success (0x00)
            Handle: 10
    
    < HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13
            Handle: 11
            Data Path Direction: Input (Host to Controller) (0x00)
            Data Path: HCI (0x00)
            Coding Format: Transparent (0x03)
            Company Codec ID: Ericsson Technology Licensing (0)
            Vendor Codec ID: 0
            Controller Delay: 0 us (0x000000)
            Codec Configuration Length: 0
            Codec Configuration:
    
    > HCI Event: Command Complete (0x0e) plen 6
          LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
            Status: Success (0x00)
            Handle: 11
    
    < ISO Data TX: Handle 10 flags 0x02 dlen 44
    
    < ISO Data TX: Handle 11 flags 0x02 dlen 44
    
    > HCI Event: Number of Completed Packets (0x13) plen 5
            Num handles: 1
            Handle: 10
            Count: 1
    
    > HCI Event: Number of Completed Packets (0x13) plen 5
            Num handles: 1
            Handle: 11
            Count: 1
    
    Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 7f74563e6140 ("Bluetooth: ISO: do not emit new LE Create CIS if previous is pending")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: do not emit new LE Create CIS if previous is pending [+ + +]
Author: Pauli Virtanen <pav@iki.fi>
Date:   Thu Jun 1 09:34:46 2023 +0300

    Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
    
    [ Upstream commit 7f74563e6140e42b4ffae62adbef7a65967a3f98 ]
    
    LE Create CIS command shall not be sent before all CIS Established
    events from its previous invocation have been processed. Currently it is
    sent via hci_sync but that only waits for the first event, but there can
    be multiple.
    
    Make it wait for all events, and simplify the CIS creation as follows:
    
    Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
    sent for the connection but it is not yet completed.
    
    Make BT_CONNECT state to mean the connection wants Create CIS.
    
    On events after which new Create CIS may need to be sent, send it if
    possible and some connections need it. These events are:
    hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
    hci_le_cis_estabilished_evt.
    
    The Create CIS status/completion events shall queue new Create CIS only
    if at least one of the connections transitions away from BT_CONNECT, so
    that we don't loop if controller is sending bogus events.
    
    This fixes sending multiple CIS Create for the same CIS in the
    "ISO AC 6(i) - Success" BlueZ test case:
    
    < HCI Command: LE Create Co.. (0x08|0x0064) plen 9  #129 [hci0]
            Number of CIS: 2
            CIS Handle: 257
            ACL Handle: 42
            CIS Handle: 258
            ACL Handle: 42
    > HCI Event: Command Status (0x0f) plen 4           #130 [hci0]
          LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
            Status: Success (0x00)
    > HCI Event: LE Meta Event (0x3e) plen 29           #131 [hci0]
          LE Connected Isochronous Stream Established (0x19)
            Status: Success (0x00)
            Connection Handle: 257
            ...
    < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  #132 [hci0]
            ...
    > HCI Event: Command Complete (0x0e) plen 6         #133 [hci0]
          LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
            ...
    < HCI Command: LE Create Co.. (0x08|0x0064) plen 5  #134 [hci0]
            Number of CIS: 1
            CIS Handle: 258
            ACL Handle: 42
    > HCI Event: Command Status (0x0f) plen 4           #135 [hci0]
          LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
            Status: ACL Connection Already Exists (0x0b)
    > HCI Event: LE Meta Event (0x3e) plen 29           #136 [hci0]
          LE Connected Isochronous Stream Established (0x19)
            Status: Success (0x00)
            Connection Handle: 258
            ...
    
    Fixes: c09b80be6ffc ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Fix not checking for valid CIG/CIS IDs [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Aug 3 14:41:46 2023 -0700

    Bluetooth: ISO: Fix not checking for valid CIG/CIS IDs
    
    [ Upstream commit b7f923b1ef6a2e76013089d30c9552257056360a ]
    
    Valid range of CIG/CIS are 0x00 to 0xEF, so this checks they are
    properly checked before attempting to use HCI_OP_LE_SET_CIG_PARAMS.
    
    Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Notify user space about failed bis connections [+ + +]
Author: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Date:   Mon Jul 3 10:02:38 2023 +0300

    Bluetooth: ISO: Notify user space about failed bis connections
    
    [ Upstream commit f777d88278170410b06a1f6633f3b9375a4ddd6b ]
    
    Some use cases require the user to be informed if BIG synchronization
    fails. This commit makes it so that even if the BIG sync established
    event arrives with error status, a new hconn is added for each BIS,
    and the iso layer is notified about the failed connections.
    
    Unsuccesful bis connections will be marked using the
    HCI_CONN_BIG_SYNC_FAILED flag. From the iso layer, the POLLERR event
    is triggered on the newly allocated bis sockets, before adding them
    to the accept list of the parent socket.
    
    From user space, a new fd for each failed bis connection will be
    obtained by calling accept. The user should check for the POLLERR
    event on the new socket, to determine if the connection was successful
    or not.
    
    The HCI_CONN_BIG_SYNC flag has been added to mark whether the BIG sync
    has been successfully established. This flag is checked at bis cleanup,
    so the HCI LE BIG Terminate Sync command is only issued if needed.
    
    The BT_SK_BIG_SYNC flag indicates if BIG create sync has been called
    for a listening socket, to avoid issuing the command everytime a BIGInfo
    advertising report is received.
    
    Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 94d9ba9f9888 ("Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: msft: Extended monitor tracking by address filter [+ + +]
Author: Hilda Wu <hildawu@realtek.com>
Date:   Wed Jun 21 18:00:31 2023 +0800

    Bluetooth: msft: Extended monitor tracking by address filter
    
    [ Upstream commit 9e14606d8f38ea52a38c27692a9c1513c987a5da ]
    
    Since limited tracking device per condition, this feature is to support
    tracking multiple devices concurrently.
    When a pattern monitor detects the device, this feature issues an address
    monitor for tracking that device. Let pattern monitor can keep monitor
    new devices.
    This feature adds an address filter when receiving a LE monitor device
    event which monitor handle is for a pattern, and the controller started
    monitoring the device. And this feature also has cancelled the monitor
    advertisement from address filters when receiving a LE monitor device
    event when the controller stopped monitoring the device specified by an
    address and monitor handle.
    
    Below is an example to know the feature adds the address filter.
    
    //Add MSFT pattern monitor
    < HCI Command: Vendor (0x3f|0x00f0) plen 14          #142 [hci0] 55.552420
            03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
    > HCI Event: Command Complete (0x0e) plen 6          #143 [hci0] 55.653960
          Vendor (0x3f|0x00f0) ncmd 2
            Status: Success (0x00)
            03 00
    
    //Got event from the pattern monitor
    > HCI Event: Vendor (0xff) plen 18                   #148 [hci0] 58.384953
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            00 01                                            ..
    
    //Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
    < HCI Command: Vendor (0x3f|0x00f0) plen 13          #149 [hci0] 58.385067
            03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.
    
    //Report to userspace about found device (ADV Monitor Device Found)
    @ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
            01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
            0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
            c1 03 03 03 12 18                                ......
    
    //Got event from address monitor
    > HCI Event: Vendor (0xff) plen 18                   #152 [hci0] 58.672956
            23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
            01 01
    
    Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
    Signed-off-by: Hilda Wu <hildawu@realtek.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 253f3399f4c0 ("Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: nokia: fix value check in nokia_bluetooth_serdev_probe() [+ + +]
Author: Yuanjun Gong <ruc_gongyuanjun@163.com>
Date:   Wed Jul 26 21:30:00 2023 +0800

    Bluetooth: nokia: fix value check in nokia_bluetooth_serdev_probe()
    
    [ Upstream commit e8b5aed31355072faac8092ead4938ddec3111fd ]
    
    in nokia_bluetooth_serdev_probe(), check the return value of
    clk_prepare_enable() and return the error code if
    clk_prepare_enable() returns an unexpected value.
    
    Fixes: 7bb318680e86 ("Bluetooth: add nokia driver")
    Signed-off-by: Yuanjun Gong <ruc_gongyuanjun@163.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Clear the probe_addr for uprobe [+ + +]
Author: Yafang Shao <laoar.shao@gmail.com>
Date:   Sun Jul 9 02:56:25 2023 +0000

    bpf: Clear the probe_addr for uprobe
    
    [ Upstream commit 5125e757e62f6c1d5478db4c2b61a744060ddf3f ]
    
    To avoid returning uninitialized or random values when querying the file
    descriptor (fd) and accessing probe_addr, it is necessary to clear the
    variable prior to its use.
    
    Fixes: 41bdc4b40ed6 ("bpf: introduce bpf subcommand BPF_TASK_FD_QUERY")
    Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20230709025630.3735-6-laoar.shao@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix a bpf_kptr_xchg() issue with local kptr [+ + +]
Author: Yonghong Song <yonghong.song@linux.dev>
Date:   Mon Aug 21 22:00:53 2023 -0700

    bpf: Fix a bpf_kptr_xchg() issue with local kptr
    
    [ Upstream commit ab6c637ad0276e42f8acabcbc64932a6d346dab3 ]
    
    When reviewing local percpu kptr support, Alexei discovered a bug
    wherea bpf_kptr_xchg() may succeed even if the map value kptr type and
    locally allocated obj type do not match ([1]). Missed struct btf_id
    comparison is the reason for the bug. This patch added such struct btf_id
    comparison and will flag verification failure if types do not match.
    
      [1] https://lore.kernel.org/bpf/20230819002907.io3iphmnuk43xblu@macbook-pro-8.dhcp.thefacebook.com/#t
    
    Reported-by: Alexei Starovoitov <ast@kernel.org>
    Fixes: 738c96d5e2e3 ("bpf: Allow local kptrs to be exchanged via bpf_kptr_xchg")
    Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
    Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Link: https://lore.kernel.org/r/20230822050053.2886960-1-yonghong.song@linux.dev
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix an error around PTR_UNTRUSTED [+ + +]
Author: Yafang Shao <laoar.shao@gmail.com>
Date:   Thu Jul 13 02:56:39 2023 +0000

    bpf: Fix an error around PTR_UNTRUSTED
    
    [ Upstream commit 7ce4dc3e4a9d954c8a1fb483c7a527e9b060b860 ]
    
    Per discussion with Alexei, the PTR_UNTRUSTED flag should not been
    cleared when we start to walk a new struct, because the struct in
    question may be a struct nested in a union. We should also check and set
    this flag before we walk its each member, in case itself is a union.
    We will clear this flag if the field is BTF_TYPE_SAFE_RCU_OR_NULL.
    
    Fixes: 6fcd486b3a0a ("bpf: Refactor RCU enforcement in the verifier.")
    Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
    Link: https://lore.kernel.org/r/20230713025642.27477-2-laoar.shao@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix an error in verifying a field in a union [+ + +]
Author: Yafang Shao <laoar.shao@gmail.com>
Date:   Thu Jul 13 02:56:41 2023 +0000

    bpf: Fix an error in verifying a field in a union
    
    [ Upstream commit 33937607efa050d9e237e0c4ac4ada02d961c466 ]
    
    We are utilizing BPF LSM to monitor BPF operations within our container
    environment. When we add support for raw_tracepoint, it hits below
    error.
    
    ; (const void *)attr->raw_tracepoint.name);
    27: (79) r3 = *(u64 *)(r2 +0)
    access beyond the end of member map_type (mend:4) in struct (anon) with off 0 size 8
    
    It can be reproduced with below BPF prog.
    
    SEC("lsm/bpf")
    int BPF_PROG(bpf_audit, int cmd, union bpf_attr *attr, unsigned int size)
    {
            switch (cmd) {
            case BPF_RAW_TRACEPOINT_OPEN:
                    bpf_printk("raw_tracepoint is %s", attr->raw_tracepoint.name);
                    break;
            default:
                    break;
            }
            return 0;
    }
    
    The reason is that when accessing a field in a union, such as bpf_attr,
    if the field is located within a nested struct that is not the first
    member of the union, it can result in incorrect field verification.
    
      union bpf_attr {
          struct {
              __u32 map_type; <<<< Actually it will find that field.
              __u32 key_size;
              __u32 value_size;
             ...
          };
          ...
          struct {
              __u64 name;    <<<< We want to verify this field.
              __u32 prog_fd;
          } raw_tracepoint;
      };
    
    Considering the potential deep nesting levels, finding a perfect
    solution to address this issue has proven challenging. Therefore, I
    propose a solution where we simply skip the verification process if the
    field in question is located within a union.
    
    Fixes: 7e3617a72df3 ("bpf: Add array support to btf_struct_access")
    Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
    Link: https://lore.kernel.org/r/20230713025642.27477-4-laoar.shao@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: fix bpf_dynptr_slice() to stop return an ERR_PTR. [+ + +]
Author: Kui-Feng Lee <thinker.li@gmail.com>
Date:   Thu Aug 3 16:12:06 2023 -0700

    bpf: fix bpf_dynptr_slice() to stop return an ERR_PTR.
    
    [ Upstream commit 5426700e6841bf72e652e34b5cec68eadf442435 ]
    
    Verify if the pointer obtained from bpf_xdp_pointer() is either an error or
    NULL before returning it.
    
    The function bpf_dynptr_slice() mistakenly returned an ERR_PTR. Instead of
    solely checking for NULL, it should also verify if the pointer returned by
    bpf_xdp_pointer() is an error or NULL.
    
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/bpf/d1360219-85c3-4a03-9449-253ea905f9d1@moroto.mountain/
    Fixes: 66e3a13e7c2c ("bpf: Add bpf_dynptr_slice and bpf_dynptr_slice_rdwr")
    Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
    Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Link: https://lore.kernel.org/r/20230803231206.1060485-1-thinker.li@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix check_func_arg_reg_off bug for graph root/node [+ + +]
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Tue Aug 22 23:21:39 2023 +0530

    bpf: Fix check_func_arg_reg_off bug for graph root/node
    
    [ Upstream commit 6785b2edf48c6b1c3ea61fe3b0d2e02b8fbf90c0 ]
    
    The commit being fixed introduced a hunk into check_func_arg_reg_off
    that bypasses reg->off == 0 enforcement when offset points to a graph
    node or root. This might possibly be done for treating bpf_rbtree_remove
    and others as KF_RELEASE and then later check correct reg->off in helper
    argument checks.
    
    But this is not the case, those helpers are already not KF_RELEASE and
    permit non-zero reg->off and verify it later to match the subobject in
    BTF type.
    
    However, this logic leads to bpf_obj_drop permitting free of register
    arguments with non-zero offset when they point to a graph root or node
    within them, which is not ok.
    
    For instance:
    
    struct foo {
            int i;
            int j;
            struct bpf_rb_node node;
    };
    
    struct foo *f = bpf_obj_new(typeof(*f));
    if (!f) ...
    bpf_obj_drop(f); // OK
    bpf_obj_drop(&f->i); // still ok from verifier PoV
    bpf_obj_drop(&f->node); // Not OK, but permitted right now
    
    Fix this by dropping the whole part of code altogether.
    
    Fixes: 6a3cd3318ff6 ("bpf: Migrate release_on_unlock logic to non-owning ref semantics")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Link: https://lore.kernel.org/r/20230822175140.1317749-2-memxor@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix issue in verifying allow_ptr_leaks [+ + +]
Author: Yafang Shao <laoar.shao@gmail.com>
Date:   Wed Aug 23 02:07:02 2023 +0000

    bpf: Fix issue in verifying allow_ptr_leaks
    
    commit d75e30dddf73449bc2d10bb8e2f1a2c446bc67a2 upstream.
    
    After we converted the capabilities of our networking-bpf program from
    cap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf program
    failed to start. Because it failed the bpf verifier, and the error log
    is "R3 pointer comparison prohibited".
    
    A simple reproducer as follows,
    
    SEC("cls-ingress")
    int ingress(struct __sk_buff *skb)
    {
            struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr);
    
            if ((long)(iph + 1) > (long)skb->data_end)
                    return TC_ACT_STOLEN;
            return TC_ACT_OK;
    }
    
    Per discussion with Yonghong and Alexei [1], comparison of two packet
    pointers is not a pointer leak. This patch fixes it.
    
    Our local kernel is 6.1.y and we expect this fix to be backported to
    6.1.y, so stable is CCed.
    
    [1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/
    
    Suggested-by: Yonghong Song <yonghong.song@linux.dev>
    Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
    Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
    Acked-by: Eduard Zingerman <eddyz87@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230823020703.3790-2-laoar.shao@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: reject unhashed sockets in bpf_sk_assign [+ + +]
Author: Lorenz Bauer <lmb@isovalent.com>
Date:   Thu Jul 20 17:30:06 2023 +0200

    bpf: reject unhashed sockets in bpf_sk_assign
    
    [ Upstream commit 67312adc96b5a585970d03b62412847afe2c6b01 ]
    
    The semantics for bpf_sk_assign are as follows:
    
        sk = some_lookup_func()
        bpf_sk_assign(skb, sk)
        bpf_sk_release(sk)
    
    That is, the sk is not consumed by bpf_sk_assign. The function
    therefore needs to make sure that sk lives long enough to be
    consumed from __inet_lookup_skb. The path through the stack for a
    TCPv4 packet is roughly:
    
      netif_receive_skb_core: takes RCU read lock
        __netif_receive_skb_core:
          sch_handle_ingress:
            tcf_classify:
              bpf_sk_assign()
          deliver_ptype_list_skb:
            deliver_skb:
              ip_packet_type->func == ip_rcv:
                ip_rcv_core:
                ip_rcv_finish_core:
                  dst_input:
                    ip_local_deliver:
                      ip_local_deliver_finish:
                        ip_protocol_deliver_rcu:
                          tcp_v4_rcv:
                            __inet_lookup_skb:
                              skb_steal_sock
    
    The existing helper takes advantage of the fact that everything
    happens in the same RCU critical section: for sockets with
    SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
    skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
    if necessary.
    
    This approach assumes that SOCK_RCU_FREE is never set on a sk
    between bpf_sk_assign and skb_steal_sock, but this invariant is
    violated by unhashed UDP sockets. A new UDP socket is created
    in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only
    added in udp_lib_get_port() which happens when a socket is bound.
    
    When bpf_sk_assign was added it wasn't possible to access unhashed
    UDP sockets from BPF, so this wasn't a problem. This changed
    in commit 0c48eefae712 ("sock_map: Lift socket state restriction
    for datagram sockets"), but the helper wasn't adjusted accordingly.
    The following sequence of events will therefore lead to a refcount
    leak:
    
    1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.
    2. Pull socket out of sockmap and bpf_sk_assign it. Since
       SOCK_RCU_FREE is not set we increment the refcount.
    3. bind() or connect() the socket, setting SOCK_RCU_FREE.
    4. skb_steal_sock will now set refcounted = false due to
       SOCK_RCU_FREE.
    5. tcp_v4_rcv() skips sock_put().
    
    Fix the problem by rejecting unhashed sockets in bpf_sk_assign().
    This matches the behaviour of __inet_lookup_skb which is ultimately
    the goal of bpf_sk_assign().
    
    Fixes: cf7fbe660f2d ("bpf: Add socket assign support")
    Cc: Joe Stringer <joe@cilium.io>
    Signed-off-by: Lorenz Bauer <lmb@isovalent.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20230720-so-reuseport-v6-2-7021b683cdae@isovalent.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpftool: Define a local bpf_perf_link to fix accessing its fields [+ + +]
Author: Alexander Lobakin <alobakin@pm.me>
Date:   Fri Jul 7 10:54:23 2023 +0100

    bpftool: Define a local bpf_perf_link to fix accessing its fields
    
    [ Upstream commit 67a43462ee2405c94e985a747bdcb8e3a0d66203 ]
    
    When building bpftool with !CONFIG_PERF_EVENTS:
    
    skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type 'struct bpf_perf_link'
            perf_link = container_of(link, struct bpf_perf_link, link);
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:74:22: note: expanded from macro 'container_of'
                    ((type *)(__mptr - offsetof(type, member)));    \
                                       ^~~~~~~~~~~~~~~~~~~~~~
    tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:68:60: note: expanded from macro 'offsetof'
     #define offsetof(TYPE, MEMBER)  ((unsigned long)&((TYPE *)0)->MEMBER)
                                                      ~~~~~~~~~~~^
    skeleton/pid_iter.bpf.c:44:9: note: forward declaration of 'struct bpf_perf_link'
            struct bpf_perf_link *perf_link;
                   ^
    
    &bpf_perf_link is being defined and used only under the ifdef.
    Define struct bpf_perf_link___local with the `preserve_access_index`
    attribute inside the pid_iter BPF prog to allow compiling on any
    configs. CO-RE will substitute it with the real struct bpf_perf_link
    accesses later on.
    container_of() uses offsetof(), which does the necessary CO-RE
    relocation if the field is specified with `preserve_access_index` - as
    is the case for struct bpf_perf_link___local.
    
    Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output")
    Suggested-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexander Lobakin <alobakin@pm.me>
    Signed-off-by: Quentin Monnet <quentin@isovalent.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20230707095425.168126-3-quentin@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpftool: Use a local bpf_perf_event_value to fix accessing its fields [+ + +]
Author: Alexander Lobakin <alobakin@pm.me>
Date:   Fri Jul 7 10:54:25 2023 +0100

    bpftool: Use a local bpf_perf_event_value to fix accessing its fields
    
    [ Upstream commit 658ac06801315b739774a15796ff06913ef5cad5 ]
    
    Fix the following error when building bpftool:
    
      CLANG   profiler.bpf.o
      CLANG   pid_iter.bpf.o
    skeleton/profiler.bpf.c:18:21: error: invalid application of 'sizeof' to an incomplete type 'struct bpf_perf_event_value'
            __uint(value_size, sizeof(struct bpf_perf_event_value));
                               ^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:13:39: note: expanded from macro '__uint'
    tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helper_defs.h:7:8: note: forward declaration of 'struct bpf_perf_event_value'
    struct bpf_perf_event_value;
           ^
    
    struct bpf_perf_event_value is being used in the kernel only when
    CONFIG_BPF_EVENTS is enabled, so it misses a BTF entry then.
    Define struct bpf_perf_event_value___local with the
    `preserve_access_index` attribute inside the pid_iter BPF prog to
    allow compiling on any configs. It is a full mirror of a UAPI
    structure, so is compatible both with and w/o CO-RE.
    bpf_perf_event_read_value() requires a pointer of the original type,
    so a cast is needed.
    
    Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
    Suggested-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexander Lobakin <alobakin@pm.me>
    Signed-off-by: Quentin Monnet <quentin@isovalent.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20230707095425.168126-5-quentin@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c [+ + +]
Author: Quentin Monnet <quentin@isovalent.com>
Date:   Fri Jul 7 10:54:24 2023 +0100

    bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c
    
    [ Upstream commit 44ba7b30e84fb40da2295e85a6d209e199fdc977 ]
    
    In order to allow the BPF program in bpftool's pid_iter.bpf.c to compile
    correctly on hosts where vmlinux.h does not define
    BPF_LINK_TYPE_PERF_EVENT (running kernel versions lower than 5.15, for
    example), define and use a local copy of the enum value. This requires
    LLVM 12 or newer to build the BPF program.
    
    Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output")
    Signed-off-by: Quentin Monnet <quentin@isovalent.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20230707095425.168126-4-quentin@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpftool: use a local copy of perf_event to fix accessing :: Bpf_cookie [+ + +]
Author: Alexander Lobakin <alobakin@pm.me>
Date:   Fri Jul 7 10:54:22 2023 +0100

    bpftool: use a local copy of perf_event to fix accessing :: Bpf_cookie
    
    [ Upstream commit 4cbeeb0dc02f8ac7b975b2ab0080ace53d43d62a ]
    
    When CONFIG_PERF_EVENTS is not set, struct perf_event remains empty.
    However, the structure is being used by bpftool indirectly via BTF.
    This leads to:
    
    skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in 'struct perf_event'
            return BPF_CORE_READ(event, bpf_cookie);
                   ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
    
    ...
    
    skeleton/pid_iter.bpf.c:49:9: error: returning 'void' from a function with incompatible result type '__u64' (aka 'unsigned long long')
            return BPF_CORE_READ(event, bpf_cookie);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Tools and samples can't use any CONFIG_ definitions, so the fields
    used there should always be present.
    Define struct perf_event___local with the `preserve_access_index`
    attribute inside the pid_iter BPF prog to allow compiling on any
    configs. CO-RE will substitute it with the real struct perf_event
    accesses later on.
    
    Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output")
    Suggested-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexander Lobakin <alobakin@pm.me>
    Signed-off-by: Quentin Monnet <quentin@isovalent.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20230707095425.168126-2-quentin@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
broadcom: b44: Use b44_writephy() return value [+ + +]
Author: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Date:   Tue Aug 15 00:00:30 2023 +0300

    broadcom: b44: Use b44_writephy() return value
    
    [ Upstream commit 9944d203fa63721b87eee84a89f7275dc3d25c05 ]
    
    Return result of b44_writephy() instead of zero to
    deal with possible error.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bus: ti-sysc: Fix build warning for 64-bit build [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri Aug 4 13:38:01 2023 +0300

    bus: ti-sysc: Fix build warning for 64-bit build
    
    [ Upstream commit e1e1e9bb9d943ec690670a609a5f660ca10eaf85 ]
    
    Fix "warning: cast from pointer to integer of different size" on 64-bit
    builds.
    
    Note that this is a cosmetic fix at this point as the driver is not yet
    used for 64-bit systems.
    
    Fixes: feaa8baee82a ("bus: ti-sysc: Implement SoC revision handling")
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Reviewed-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bus: ti-sysc: Fix cast to enum warning [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Aug 15 08:49:05 2023 +0300

    bus: ti-sysc: Fix cast to enum warning
    
    [ Upstream commit de44bf2f7683347f75690ef6cf61a1d5ba8f0891 ]
    
    Fix warning for "cast to smaller integer type 'enum sysc_soc' from 'const
    void *'".
    
    Cc: Nishanth Menon <nm@ti.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202308150723.ziuGCdM3-lkp@intel.com/
    Fixes: e1e1e9bb9d94 ("bus: ti-sysc: Fix build warning for 64-bit build")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: gs_usb: gs_usb_receive_bulk_callback(): count RX overflow errors also in case of OOM [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Tue Jul 4 11:23:37 2023 +0200

    can: gs_usb: gs_usb_receive_bulk_callback(): count RX overflow errors also in case of OOM
    
    [ Upstream commit 6c8bc15f02b85bc8f47074110d8fd8caf7a1e42d ]
    
    In case of an RX overflow error from the CAN controller and an OOM
    where no skb can be allocated, the error counters are not incremented.
    
    Fix this by first incrementing the error counters and then allocate
    the skb.
    
    Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
    Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-7-c3b9154ec605@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: tcan4x5x: Remove reserved register 0x814 from writable table [+ + +]
Author: Markus Schneider-Pargmann <msp@baylibre.com>
Date:   Fri Jul 28 16:19:19 2023 +0200

    can: tcan4x5x: Remove reserved register 0x814 from writable table
    
    [ Upstream commit fbe534f7bf213d485b0ed5362b24a41bf3e18803 ]
    
    The mentioned register is not writable. It is reserved and should not be
    written.
    
    Fixes: 39dbb21b6a29 ("can: tcan4x5x: Specify separate read/write ranges")
    Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Link: https://lore.kernel.org/all/20230728141923.162477-3-msp@baylibre.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cgroup/cpuset: Inherit parent's load balance state in v2 [+ + +]
Author: Waiman Long <longman@redhat.com>
Date:   Tue Jun 27 10:35:00 2023 -0400

    cgroup/cpuset: Inherit parent's load balance state in v2
    
    [ Upstream commit c8c926200c55454101f072a4b16c9ff5b8c9e56f ]
    
    Since commit f28e22441f35 ("cgroup/cpuset: Add a new isolated
    cpus.partition type"), the CS_SCHED_LOAD_BALANCE bit of a v2 cpuset
    can be on or off. The child cpusets of a partition root must have the
    same setting as its parent or it may screw up the rebuilding of sched
    domains. Fix this problem by making sure the a child v2 cpuset will
    follows its parent cpuset load balance state unless the child cpuset
    is a new partition root itself.
    
    Fixes: f28e22441f35 ("cgroup/cpuset: Add a new isolated cpus.partition type")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: fix charset issue in reconnection [+ + +]
Author: Winston Wen <wentao@uniontech.com>
Date:   Mon Jul 24 10:10:57 2023 +0800

    cifs: fix charset issue in reconnection
    
    [ Upstream commit a43f95fdd39490f7b156fd126f1e90ec2d5553f1 ]
    
    We need to specify charset, like "iocharset=utf-8", in mount options for
    Chinese path if the nls_default don't support it, such as iso8859-1, the
    default value for CONFIG_NLS_DEFAULT.
    
    But now in reconnection the nls_default is used, instead of the one we
    specified and used in mount, and this can lead to mount failure.
    
    Signed-off-by: Winston Wen <wentao@uniontech.com>
    Reviewed-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: fixed-mmio: make COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM [+ + +]
Author: Baoquan He <bhe@redhat.com>
Date:   Fri Jul 7 21:58:51 2023 +0800

    clk: fixed-mmio: make COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM
    
    [ Upstream commit e7dd44f4f3166db45248414f5df8f615392de47a ]
    
    On s390 systems (aka mainframes), it has classic channel devices for
    networking and permanent storage that are currently even more common
    than PCI devices. Hence it could have a fully functional s390 kernel
    with CONFIG_PCI=n, then the relevant iomem mapping functions
    [including ioremap(), devm_ioremap(), etc.] are not available.
    
    Here let COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM so that it won't
    be built to cause below compiling error if PCI is unset:
    
    ------
    ld: drivers/clk/clk-fixed-mmio.o: in function `fixed_mmio_clk_setup':
    clk-fixed-mmio.c:(.text+0x5e): undefined reference to `of_iomap'
    ld: clk-fixed-mmio.c:(.text+0xba): undefined reference to `iounmap'
    ------
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/
    Signed-off-by: Baoquan He <bhe@redhat.com>
    Cc: Michael Turquette <mturquette@baylibre.com>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: linux-clk@vger.kernel.org
    Link: https://lore.kernel.org/r/20230707135852.24292-8-bhe@redhat.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx8mp: fix sai4 clock [+ + +]
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Mon Jul 31 16:21:49 2023 +0200

    clk: imx8mp: fix sai4 clock
    
    [ Upstream commit c30f600f1f41dcf5ef0fb02e9a201f9b2e8f31bd ]
    
    The reference manual don't mention a SAI4 hardware block. This would be
    clock slice 78 which is skipped (TRM, page 237). Remove any reference to
    this clock to align the driver with the reality.
    
    Fixes: 9c140d992676 ("clk: imx: Add support for i.MX8MP clock driver")
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Link: https://lore.kernel.org/r/20230731142150.3186650-1-m.felsch@pengutronix.de
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: composite-8m: fix clock pauses when set_rate would be a no-op [+ + +]
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Mon Aug 7 10:22:00 2023 +0200

    clk: imx: composite-8m: fix clock pauses when set_rate would be a no-op
    
    [ Upstream commit 4dd432d985ef258e3bc436e568fba4b987b59171 ]
    
    Reconfiguring the clock divider to the exact same value is observed
    on an i.MX8MN to often cause a longer than usual clock pause, probably
    because the divider restarts counting whenever the register is rewritten.
    
    This issue doesn't show up normally, because the clock framework will
    take care to not call set_rate when the clock rate is the same.
    However, when we reconfigure an upstream clock, the common code will
    call set_rate with the newly calculated rate on all children, e.g.:
    
      - sai5 is running normally and divides Audio PLL out by 16.
      - Audio PLL rate is increased by 32Hz (glitch-free kdiv change)
      - rates for children are recalculated and rates are set recursively
      - imx8m_clk_composite_divider_set_rate(sai5) is called with
        32/16 = 2Hz more
      - imx8m_clk_composite_divider_set_rate computes same divider as before
      - divider register is written, so it restarts counting from zero and
        MCLK is briefly paused, so instead of e.g. 40ns, MCLK is low for 120ns.
    
    Some external clock consumers can be upset by such unexpected clock pauses,
    so let's make sure we only rewrite the divider value when the value to be
    written is actually different.
    
    Fixes: d3ff9728134e ("clk: imx: Add imx composite clock")
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/20230807082201.2332746-1-a.fatoum@pengutronix.de
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: imx8ulp: update SPLL2 type [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Sun Jun 25 20:33:40 2023 +0800

    clk: imx: imx8ulp: update SPLL2 type
    
    [ Upstream commit 7653a59be8af043adc4c09473975a860e6055ff9 ]
    
    The SPLL2 on iMX8ULP is different with other frac PLLs, it can
    support VCO from 650Mhz to 1Ghz. Following the changes to pllv4,
    use the new type IMX_PLLV4_IMX8ULP_1GHZ.
    
    Fixes: c43a801a5789 ("clk: imx: Add clock driver for imx8ulp")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20230625123340.4067536-2-peng.fan@oss.nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: pllv4: Fix SPLL2 MULT range [+ + +]
Author: Ye Li <ye.li@nxp.com>
Date:   Sun Jun 25 20:33:39 2023 +0800

    clk: imx: pllv4: Fix SPLL2 MULT range
    
    [ Upstream commit 3f0cdb945471f1abd1cf4d172190e9c489c5052a ]
    
    The SPLL2 on iMX8ULP is different with other frac PLLs, it can
    support VCO from 650Mhz to 1Ghz. According to RM, the MULT is
    using a range from 27 to 54, not some fixed values. If using
    current PLL implementation, some clock rate can't be supported.
    
    Fix the issue by adding new type for the SPLL2 and use MULT range
    to replace MULT table
    
    Fixes: 5f0601c47c33 ("clk: imx: Update the pllv4 to support imx8ulp")
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Jacky Bai <ping.bai@nxp.com>
    Signed-off-by: Ye Li <ye.li@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20230625123340.4067536-1-peng.fan@oss.nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: dispcc-sc8280xp: Use ret registers on GDSCs [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jul 25 10:51:56 2023 +0200

    clk: qcom: dispcc-sc8280xp: Use ret registers on GDSCs
    
    [ Upstream commit 20e1d75bc043c5ec1fd8f5169fde17db89eb11c3 ]
    
    The DISP_CC GDSCs have not been instructed to use the ret registers.
    Fix that.
    
    Fixes: 4a66e76fdb6d ("clk: qcom: Add SC8280XP display clock controller")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230725-topic-8280_dispcc_gdsc-v1-1-236590060531@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-qdu1000: Fix clkref clocks handling [+ + +]
Author: Imran Shaik <quic_imrashai@quicinc.com>
Date:   Thu Aug 3 16:27:36 2023 +0530

    clk: qcom: gcc-qdu1000: Fix clkref clocks handling
    
    [ Upstream commit 2524dae5cd453ca39e8ba1b95c2755a8a2d94059 ]
    
    Update the GCC clkref clock's halt_check to BRANCH_HALT, as it's
    status bit is not inverted in the latest hardware version of QDU1000
    and QRU1000 SoCs. While at it, fix the gcc clkref clock ops as well.
    
    Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support")
    Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230803105741.2292309-4-quic_imrashai@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-qdu1000: Fix gcc_pcie_0_pipe_clk_src clock handling [+ + +]
Author: Imran Shaik <quic_imrashai@quicinc.com>
Date:   Thu Aug 3 16:27:35 2023 +0530

    clk: qcom: gcc-qdu1000: Fix gcc_pcie_0_pipe_clk_src clock handling
    
    [ Upstream commit b311f5d3c4749259043a9a458a8db07915210142 ]
    
    Fix the gcc pcie pipe clock handling as per the clk_regmap_phy_mux_ops
    implementation to let the clock framework automatically park the clock
    at XO when the clock is switched off and restore the parent when the
    clock is switched on.
    
    Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support")
    Co-developed-by: Taniya Das <quic_tdas@quicinc.com>
    Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
    Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230803105741.2292309-3-quic_imrashai@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-qdu1000: Register gcc_gpll1_out_even clock [+ + +]
Author: Imran Shaik <quic_imrashai@quicinc.com>
Date:   Thu Aug 3 16:27:37 2023 +0530

    clk: qcom: gcc-qdu1000: Register gcc_gpll1_out_even clock
    
    [ Upstream commit 06d71fa10f2e507444c6759328a6c19d38eab788 ]
    
    gcc_gpll1_out_even clock is referenced as a parent, but not registered
    with the clock framework. Hence add support to register the same.
    
    Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support")
    Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230803105741.2292309-5-quic_imrashai@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sc7180: Fix up gcc_sdcc2_apps_clk_src [+ + +]
Author: David Wronek <davidwronek@gmail.com>
Date:   Sun Jul 23 21:05:02 2023 +0200

    clk: qcom: gcc-sc7180: Fix up gcc_sdcc2_apps_clk_src
    
    [ Upstream commit fd0b5ba87ad5709f0fd3d2bc4b7870494a75f96a ]
    
    Set .flags = CLK_OPS_PARENT_ENABLE to fix "gcc_sdcc2_apps_clk_src: rcg
    didn't update its configuration" error.
    
    Fixes: 17269568f726 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180")
    Signed-off-by: David Wronek <davidwronek@gmail.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230723190725.1619193-2-davidwronek@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sc8280xp: Add missing GDSC flags [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jun 26 19:48:06 2023 +0200

    clk: qcom: gcc-sc8280xp: Add missing GDSC flags
    
    [ Upstream commit 2fd02de27054576a4a8c89302e2f77122c55e957 ]
    
    All of the 8280's GCC GDSCs can and should use the retain registers so
    as not to lose their state when entering lower power modes.
    
    Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20230620-topic-sc8280_gccgdsc-v2-1-562c1428c10d@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sc8280xp: Add missing GDSCs [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jun 26 19:48:08 2023 +0200

    clk: qcom: gcc-sc8280xp: Add missing GDSCs
    
    [ Upstream commit 4712eb7ff85bd3dd09c6668b8de4080e02b3eea9 ]
    
    There are 10 more GDSCs that we've not been caring about, and by extension
    (and perhaps even more importantly), not putting to sleep. Add them.
    
    Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20230620-topic-sc8280_gccgdsc-v2-3-562c1428c10d@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sm6350: Fix gcc_sdcc2_apps_clk_src [+ + +]
Author: Luca Weiss <luca.weiss@fairphone.com>
Date:   Fri Aug 4 16:09:30 2023 +0200

    clk: qcom: gcc-sm6350: Fix gcc_sdcc2_apps_clk_src
    
    [ Upstream commit df04d166d1f346dbf740bbea64a3bed3e7f14c8d ]
    
    GPLL7 is not on by default, which causes a "gcc_sdcc2_apps_clk_src: rcg
    didn't update its configuration" error when booting. Set .flags =
    CLK_OPS_PARENT_ENABLE to fix the error.
    
    Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver")
    Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230804-sm6350-sdcc2-v1-1-3d946927d37d@fairphone.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sm7150: Add CLK_OPS_PARENT_ENABLE to sdcc2 rcg [+ + +]
Author: Danila Tikhonov <danila@jiaxyga.com>
Date:   Fri Jun 30 22:19:44 2023 +0300

    clk: qcom: gcc-sm7150: Add CLK_OPS_PARENT_ENABLE to sdcc2 rcg
    
    [ Upstream commit ff19022b9112d6bbd7c117c83e944cb21b438e91 ]
    
    Set .flags = CLK_OPS_PARENT_ENABLE to fix "gcc_sdcc2_apps_clk_src: rcg
    didn't update its configuration" error.
    
    Fixes: a808d58ddf29 ("clk: qcom: Add Global Clock Controller (GCC) driver for SM7150")
    Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230630191944.20282-1-danila@jiaxyga.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sm8250: Fix gcc_sdcc2_apps_clk_src [+ + +]
Author: Patrick Whewell <patrick.whewell@sightlineapplications.com>
Date:   Wed Aug 2 14:04:00 2023 -0700

    clk: qcom: gcc-sm8250: Fix gcc_sdcc2_apps_clk_src
    
    [ Upstream commit 783cb693828ce487cf0bc6ad16cbcf2caae6f8d9 ]
    
    GPLL9 is not on by default, which causes a "gcc_sdcc2_apps_clk_src: rcg
    didn't update its configuration" error when booting. Set .flags =
    CLK_OPS_PARENT_ENABLE to fix the error.
    
    Fixes: 3e5770921a88 ("clk: qcom: gcc: Add global clock controller driver for SM8250")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Patrick Whewell <patrick.whewell@sightlineapplications.com>
    Reviewed-by: Vinod Koul <vkoul@kernel.org>
    Link: https://lore.kernel.org/r/20230802210359.408-1-patrick.whewell@sightlineapplications.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 19:35:53 2023 +0200

    clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs
    
    [ Upstream commit a27ac3806b0a0e6954fb5967223b8635242e5b8f ]
    
    Use the floor ops to prevent warnings like this at suspend exit and boot:
    
    mmc0: Card appears overclocked; req 800000 Hz, actual 25000000 Hz
    
    Fixes: db0c944ee92b ("clk: qcom: Add clock driver for SM8450")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Vinod Koul <vkoul@kernel.org>
    Link: https://lore.kernel.org/r/20230811-topic-8450_clk-v1-1-88031478d548@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gpucc-sm6350: Fix clock source names [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Jun 14 13:35:33 2023 +0200

    clk: qcom: gpucc-sm6350: Fix clock source names
    
    [ Upstream commit 743913b343a3ec2510fe3c0dfaff03d049659922 ]
    
    fw_name for GCC inputs didn't match the bindings. Fix it.
    
    Fixes: 013804a727a0 ("clk: qcom: Add GPU clock controller driver for SM6350")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230315-topic-lagoon_gpu-v2-2-afcdfb18bb13@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gpucc-sm6350: Introduce index-based clk lookup [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Jun 14 13:35:32 2023 +0200

    clk: qcom: gpucc-sm6350: Introduce index-based clk lookup
    
    [ Upstream commit f6f89d194e4ddcfe197ac8a05ed4161f642a5c68 ]
    
    Add the nowadays-prefered and marginally faster way of looking up parent
    clocks in the device tree. It also allows for clock-names-independent
    operation, so long as the order (which is enforced by schema) is kept.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230315-topic-lagoon_gpu-v2-1-afcdfb18bb13@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 743913b343a3 ("clk: qcom: gpucc-sm6350: Fix clock source names")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: reset: Use the correct type of sleep/delay based on length [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Jul 28 09:57:38 2023 +0200

    clk: qcom: reset: Use the correct type of sleep/delay based on length
    
    [ Upstream commit 181b66ee7cdd824797fc99b53bec29cf5630a04f ]
    
    Use the fsleep() helper that (based on the length of the delay, see: [1])
    chooses the correct sleep/delay functions.
    
    [1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
    
    Fixes: 2cb8a39b6781 ("clk: qcom: reset: Allow specifying custom reset delay")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230726-topic-qcom_reset-v3-1-5958facd5db2@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: rockchip: rk3568: Fix PLL rate setting for 78.75MHz [+ + +]
Author: Alibek Omarov <a1ba.omarov@gmail.com>
Date:   Wed Jun 14 16:47:50 2023 +0300

    clk: rockchip: rk3568: Fix PLL rate setting for 78.75MHz
    
    [ Upstream commit dafebd0f9a4f56b10d7fbda0bff1f540d16a2ea4 ]
    
    PLL rate on RK356x is calculated through the simple formula:
    ((24000000 / _refdiv) * _fbdiv) / (_postdiv1 * _postdiv2)
    
    The PLL rate setting for 78.75MHz seems to be copied from 96MHz
    so this patch fixes it and configures it properly.
    
    Signed-off-by: Alibek Omarov <a1ba.omarov@gmail.com>
    Fixes: 842f4cb72639 ("clk: rockchip: Add more PLL rates for rk3568")
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Link: https://lore.kernel.org/r/20230614134750.1056293-1-a1ba.omarov@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: sunxi-ng: Modify mismatched function name [+ + +]
Author: Zhang Jianhua <chris.zjh@huawei.com>
Date:   Sat Jul 22 15:31:07 2023 +0000

    clk: sunxi-ng: Modify mismatched function name
    
    [ Upstream commit 075d9ca5b4e17f84fd1c744a405e69ec743be7f0 ]
    
    No functional modification involved.
    
    drivers/clk/sunxi-ng/ccu_mmc_timing.c:54: warning: expecting prototype for sunxi_ccu_set_mmc_timing_mode(). Prototype was for sunxi_ccu_get_mmc_timing_mode() instead
    
    Fixes: f6f64ed868d3 ("clk: sunxi-ng: Add interface to query or configure MMC timing modes.")
    Signed-off-by: Zhang Jianhua <chris.zjh@huawei.com>
    Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20230722153107.2078179-1-chris.zjh@huawei.com
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clocksource: Handle negative skews in "skew is too large" messages [+ + +]
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Wed Jun 7 11:59:49 2023 -0700

    clocksource: Handle negative skews in "skew is too large" messages
    
    [ Upstream commit e40806e9bcf8aaa86dbf0d484e7cf3cfa09cb86c ]
    
    The nanosecond-to-millisecond skew computation uses unsigned arithmetic,
    which produces user-unfriendly large positive numbers for negative skews.
    Therefore, use signed arithmetic for this computation in order to preserve
    the negativity.
    
    Reported-by: Chris Bainbridge <chris.bainbridge@gmail.com>
    Reported-by: Feng Tang <feng.tang@intel.com>
    Fixes: dd029269947a ("clocksource: Improve "skew is too large" messages")
    Reviewed-by: Feng Tang <feng.tang@intel.com>
    Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
coresight: tmc: Explicit type conversions to prevent integer overflow [+ + +]
Author: Ruidong Tian <tianruidong@linux.alibaba.com>
Date:   Fri Aug 4 16:15:14 2023 +0800

    coresight: tmc: Explicit type conversions to prevent integer overflow
    
    [ Upstream commit fd380097cdb305582b7a1f9476391330299d2c59 ]
    
    Perf cs_etm session executed unexpectedly when AUX buffer > 1G.
    
      perf record -C 0 -m ,2G -e cs_etm// -- <workload>
      [ perf record: Captured and wrote 2.615 MB perf.data ]
    
    Perf only collect about 2M perf data rather than 2G. This is becasuse
    the operation, "nr_pages << PAGE_SHIFT", in coresight tmc driver, will
    overflow when nr_pages >= 0x80000(correspond to 1G AUX buffer). The
    overflow cause buffer allocation to fail, and TMC driver will alloc
    minimal buffer size(1M). You can just get about 2M perf data(1M AUX
    buffer + perf data header) at least.
    
    Explicit convert nr_pages to 64 bit to avoid overflow.
    
    Fixes: 22f429f19c41 ("coresight: etm-perf: Add support for ETR backend")
    Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework")
    Fixes: 2e499bbc1a92 ("coresight: tmc: implementing TMC-ETF AUX space API")
    Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com>
    Reviewed-by: James Clark <james.clark@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20230804081514.120171-2-tianruidong@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

coresight: trbe: Fix TRBE potential sleep in atomic context [+ + +]
Author: Junhao He <hejunhao3@huawei.com>
Date:   Fri Aug 18 16:40:52 2023 +0800

    coresight: trbe: Fix TRBE potential sleep in atomic context
    
    [ Upstream commit c0a232f1e19e378c5c4e5973a996392942c80090 ]
    
    smp_call_function_single() will allocate an IPI interrupt vector to
    the target processor and send a function call request to the interrupt
    vector. After the target processor receives the IPI interrupt, it will
    execute arm_trbe_remove_coresight_cpu() call request in the interrupt
    handler.
    
    According to the device_unregister() stack information, if other process
    is useing the device, the down_write() may sleep, and trigger deadlocks
    or unexpected errors.
    
      arm_trbe_remove_coresight_cpu
        coresight_unregister
          device_unregister
            device_del
              kobject_del
                __kobject_del
                  sysfs_remove_dir
                    kernfs_remove
                      down_write ---------> it may sleep
    
    Add a helper arm_trbe_disable_cpu() to disable TRBE precpu irq and reset
    per TRBE.
    Simply call arm_trbe_remove_coresight_cpu() directly without useing the
    smp_call_function_single(), which is the same as registering the TRBE
    coresight device.
    
    Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
    Signed-off-by: Junhao He <hejunhao3@huawei.com>
    Link: https://lore.kernel.org/r/20230814093813.19152-2-hejunhao3@huawei.com
    [ Remove duplicate cpumask checks during removal ]
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    [ v3 - Remove the operation of assigning NULL to cpudata->drvdata ]
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20230818084052.10116-1-hejunhao3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpu/hotplug: Prevent self deadlock on CPU hot-unplug [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Aug 23 10:47:02 2023 +0200

    cpu/hotplug: Prevent self deadlock on CPU hot-unplug
    
    commit 2b8272ff4a70b866106ae13c36be7ecbef5d5da2 upstream.
    
    Xiongfeng reported and debugged a self deadlock of the task which initiates
    and controls a CPU hot-unplug operation vs. the CFS bandwidth timer.
    
        CPU1                                                 CPU2
    
    T1 sets cfs_quota
       starts hrtimer cfs_bandwidth 'period_timer'
    T1 is migrated to CPU2
                                                    T1 initiates offlining of CPU1
    Hotplug operation starts
      ...
    'period_timer' expires and is re-enqueued on CPU1
      ...
    take_cpu_down()
      CPU1 shuts down and does not handle timers
      anymore. They have to be migrated in the
      post dead hotplug steps by the control task.
    
                                                    T1 runs the post dead offline operation
                                                    T1 is scheduled out
                                                    T1 waits for 'period_timer' to expire
    
    T1 waits there forever if it is scheduled out before it can execute the hrtimer
    offline callback hrtimers_dead_cpu().
    
    Cure this by delegating the hotplug control operation to a worker thread on
    an online CPU. This takes the initiating user space task, which might be
    affected by the bandwidth timer, completely out of the picture.
    
    Reported-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Yu Liao <liaoyu15@huawei.com>
    Acked-by: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/lkml/8e785777-03aa-99e1-d20e-e956f5685be6@huawei.com
    Link: https://lore.kernel.org/r/87h6oqdq0i.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver [+ + +]
Author: Swapnil Sapkal <swapnil.sapkal@amd.com>
Date:   Fri Aug 18 11:44:52 2023 +0000

    cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver
    
    [ Upstream commit 60dd283804479c4a52f995b713f448e2cd65b8c8 ]
    
    After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf()
    and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy
    of the CPU and mark it as busy.
    
    In these functions, cpufreq_cpu_put() should be used to release the
    policy, but it is not, so any other entity trying to access the policy
    is blocked indefinitely.
    
    One such scenario is when amd_pstate mode is changed, leading to the
    following splat:
    
    [ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds.
    [ 1332.110001]       Not tainted 6.5.0-rc2-amd-pstate-ut #5
    [ 1332.115315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1332.123140] task:bash            state:D stack:0     pid:2929  ppid:2873   flags:0x00004006
    [ 1332.123143] Call Trace:
    [ 1332.123145]  <TASK>
    [ 1332.123148]  __schedule+0x3c1/0x16a0
    [ 1332.123154]  ? _raw_read_lock_irqsave+0x2d/0x70
    [ 1332.123157]  schedule+0x6f/0x110
    [ 1332.123160]  schedule_timeout+0x14f/0x160
    [ 1332.123162]  ? preempt_count_add+0x86/0xd0
    [ 1332.123165]  __wait_for_common+0x92/0x190
    [ 1332.123168]  ? __pfx_schedule_timeout+0x10/0x10
    [ 1332.123170]  wait_for_completion+0x28/0x30
    [ 1332.123173]  cpufreq_policy_put_kobj+0x4d/0x90
    [ 1332.123177]  cpufreq_policy_free+0x157/0x1d0
    [ 1332.123178]  ? preempt_count_add+0x58/0xd0
    [ 1332.123180]  cpufreq_remove_dev+0xb6/0x100
    [ 1332.123182]  subsys_interface_unregister+0x114/0x120
    [ 1332.123185]  ? preempt_count_add+0x58/0xd0
    [ 1332.123187]  ? __pfx_amd_pstate_change_driver_mode+0x10/0x10
    [ 1332.123190]  cpufreq_unregister_driver+0x3b/0xd0
    [ 1332.123192]  amd_pstate_change_driver_mode+0x1e/0x50
    [ 1332.123194]  store_status+0xe9/0x180
    [ 1332.123197]  dev_attr_store+0x1b/0x30
    [ 1332.123199]  sysfs_kf_write+0x42/0x50
    [ 1332.123202]  kernfs_fop_write_iter+0x143/0x1d0
    [ 1332.123204]  vfs_write+0x2df/0x400
    [ 1332.123208]  ksys_write+0x6b/0xf0
    [ 1332.123210]  __x64_sys_write+0x1d/0x30
    [ 1332.123213]  do_syscall_64+0x60/0x90
    [ 1332.123216]  ? fpregs_assert_state_consistent+0x2e/0x50
    [ 1332.123219]  ? exit_to_user_mode_prepare+0x49/0x1a0
    [ 1332.123223]  ? irqentry_exit_to_user_mode+0xd/0x20
    [ 1332.123225]  ? irqentry_exit+0x3f/0x50
    [ 1332.123226]  ? exc_page_fault+0x8e/0x190
    [ 1332.123228]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    [ 1332.123232] RIP: 0033:0x7fa74c514a37
    [ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37
    [ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001
    [ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff
    [ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008
    [ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00
    [ 1332.123247]  </TASK>
    
    Fix this by calling cpufreq_cpu_put() wherever necessary.
    
    Fixes: 14eb1c96e3a3 ("cpufreq: amd-pstate: Add test module for amd-pstate driver")
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Meng Li <li.meng@amd.com>
    Reviewed-by: Wyes Karny <wyes.karny@amd.com>
    Suggested-by: Wyes Karny <wyes.karny@amd.com>
    Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: amd-pstate-ut: Remove module parameter access [+ + +]
Author: Swapnil Sapkal <swapnil.sapkal@amd.com>
Date:   Fri Aug 18 11:44:51 2023 +0000

    cpufreq: amd-pstate-ut: Remove module parameter access
    
    [ Upstream commit 8d6e5e8268e89979d86501dbb8385ce2e6154de1 ]
    
    In amd-pstate-ut, shared memory-based systems call
    get_shared_mem() as part of amd_pstate_ut_check_enabled()
    function. This function was written when CONFIG_X86_AMD_PSTATE
    was tristate config and amd_pstate can be built as a module.
    
    Currently CONFIG_X86_AMD_PSTATE is a boolean config and module
    parameter shared_mem is removed. But amd-pstate-ut code still
    accesses this module parameter. Remove those accesses.
    
    Fixes: 456ca88d8a52 ("cpufreq: amd-pstate: change amd-pstate driver to be built-in type")
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Meng Li <li.meng@amd.com>
    Reviewed-by: Wyes Karny <wyes.karny@amd.com>
    Suggested-by: Wyes Karny <wyes.karny@amd.com>
    Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com>
    [ rjw: Subject edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bug [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Mon Jul 31 21:15:48 2023 -0600

    cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bug
    
    commit e520d0b6be950ce3738cf4b9bd3b392be818f1dc upstream.
    
    Allocate extra space for terminating element at:
    
    drivers/cpufreq/brcmstb-avs-cpufreq.c:
    449         table[i].frequency = CPUFREQ_TABLE_END;
    
    and add code comment to make this clear.
    
    This fixes the following -Warray-bounds warning seen after building
    ARM with multi_v7_defconfig (GCC 13):
    In function 'brcm_avs_get_freq_table',
        inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15:
    drivers/cpufreq/brcmstb-avs-cpufreq.c:449:28: warning: array subscript 5 is outside array bounds of 'void[60]' [-Warray-bounds=]
      449 |         table[i].frequency = CPUFREQ_TABLE_END;
    In file included from include/linux/node.h:18,
                     from include/linux/cpu.h:17,
                     from include/linux/cpufreq.h:12,
                     from drivers/cpufreq/brcmstb-avs-cpufreq.c:44:
    In function 'devm_kmalloc_array',
        inlined from 'devm_kcalloc' at include/linux/device.h:328:9,
        inlined from 'brcm_avs_get_freq_table' at drivers/cpufreq/brcmstb-avs-cpufreq.c:437:10,
        inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15:
    include/linux/device.h:323:16: note: at offset 60 into object of size 60 allocated by 'devm_kmalloc'
      323 |         return devm_kmalloc(dev, bytes, flags);
          |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
    routines on memcpy() and help us make progress towards globally
    enabling -Warray-bounds.
    
    Link: https://github.com/KSPP/linux/issues/324
    Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpufreq: Fix the race condition while updating the transition_task of policy [+ + +]
Author: Liao Chang <liaochang1@huawei.com>
Date:   Tue Aug 29 07:03:18 2023 +0000

    cpufreq: Fix the race condition while updating the transition_task of policy
    
    [ Upstream commit 61bfbf7951ba561dcbdd5357702d3cbc2d447812 ]
    
    The field 'transition_task' of policy structure is used to track the
    task which is performing the frequency transition. Using this field to
    print a warning once detect a case where the same task is calling
    _begin() again before completing the preivous frequency transition via
    the _end().
    
    However, there is a potential race condition in _end() and _begin() APIs
    while updating the field 'transition_task' of policy, the scenario is
    depicted below:
    
                 Task A                            Task B
    
            /* 1st freq transition */
            Invoke _begin() {
                    ...
                    ...
            }
                                            /* 2nd freq transition */
                                            Invoke _begin() {
                                                    ... //waiting for A to
                                                    ... //clear
                                                    ... //transition_ongoing
                                                    ... //in _end() for
                                                    ... //the 1st transition
                                                            |
            Change the frequency                            |
                                                            |
            Invoke _end() {                                 |
                    ...                                     |
                    ...                                     |
                    transition_ongoing = false;             V
                                                    transition_ongoing = true;
                                                    transition_task = current;
                    transition_task = NULL;
                    ... //A overwrites the task
                    ... //performing the transition
                    ... //result in error warning.
            }
    
    To fix this race condition, the transition_lock of policy structure is
    now acquired before updating policy structure in _end() API. Which ensure
    that only one task can update the 'transition_task' field at a time.
    
    Link: https://lore.kernel.org/all/b3c61d8a-d52d-3136-fbf0-d1de9f1ba411@huawei.com/
    Fixes: ca654dc3a93d ("cpufreq: Catch double invocations of cpufreq_freq_transition_begin/end")
    Signed-off-by: Liao Chang <liaochang1@huawei.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: intel_pstate: set stale CPU frequency to minimum [+ + +]
Author: Doug Smythies <dsmythies@telus.net>
Date:   Sun Aug 20 13:46:49 2023 -0700

    cpufreq: intel_pstate: set stale CPU frequency to minimum
    
    commit d51847acb018d83186e4af67bc93f9a00a8644f7 upstream.
    
    The intel_pstate CPU frequency scaling driver does not
    use policy->cur and it is 0.
    When the CPU frequency is outdated arch_freq_get_on_cpu()
    will default to the nominal clock frequency when its call to
    cpufreq_quick_getpolicy_cur returns the never updated 0.
    Thus, the listed frequency might be outside of currently
    set limits. Some users are complaining about the high
    reported frequency, albeit stale, when their system is
    idle and/or it is above the reduced maximum they have set.
    
    This patch will maintain policy_cur for the intel_pstate
    driver at the current minimum CPU frequency.
    
    Reported-by: Yang Jie <yang.jie@linux.intel.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217597
    Signed-off-by: Doug Smythies <dsmythies@telus.net>
    [ rjw: White space damage fixes and comment adjustment ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpufreq: powernow-k8: Use related_cpus instead of cpus in driver.exit() [+ + +]
Author: Liao Chang <liaochang1@huawei.com>
Date:   Sat Aug 26 09:51:13 2023 +0000

    cpufreq: powernow-k8: Use related_cpus instead of cpus in driver.exit()
    
    [ Upstream commit 03997da042dac73c69e60d91942c727c76828b65 ]
    
    Since the 'cpus' field of policy structure will become empty in the
    cpufreq core API, it is better to use 'related_cpus' in the exit()
    callback of driver.
    
    Fixes: c3274763bfc3 ("cpufreq: powernow-k8: Initialize per-cpu data-structures properly")
    Signed-off-by: Liao Chang <liaochang1@huawei.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: tegra194: add online/offline hooks [+ + +]
Author: Sumit Gupta <sumitg@nvidia.com>
Date:   Fri Aug 25 16:49:20 2023 +0530

    cpufreq: tegra194: add online/offline hooks
    
    [ Upstream commit a3aa97be69a7cc14ddc2bb0add0b9c51cb74bf83 ]
    
    Implement the light-weight tear down and bring up helpers to reduce the
    amount of work to do on CPU offline/online operation.
    This change helps to make the hotplugging paths much faster.
    
    Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
    Link: https://lore.kernel.org/lkml/20230816033402.3abmugb5goypvllm@vireshk-i7/
    [ Viresh: Fixed rebase conflict ]
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Stable-dep-of: de0e85b29edf ("cpufreq: tegra194: remove opp table in exit hook")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: tegra194: remove opp table in exit hook [+ + +]
Author: Sumit Gupta <sumitg@nvidia.com>
Date:   Fri Aug 25 16:46:17 2023 +0530

    cpufreq: tegra194: remove opp table in exit hook
    
    [ Upstream commit de0e85b29edfc68046d587c7d67bbd2bdc31b73f ]
    
    Add exit hook and remove OPP table when the device gets unregistered.
    This will fix the error messages when the CPU FREQ driver module is
    removed and then re-inserted. It also fixes these messages while
    onlining the first CPU from a policy whose all CPU's were previously
    offlined.
    
     debugfs: File 'cpu5' in directory 'opp' already present!
     debugfs: File 'cpu6' in directory 'opp' already present!
     debugfs: File 'cpu7' in directory 'opp' already present!
    
    Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth")
    Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
    [ Viresh: Dropped irrelevant change from it ]
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpuidle: teo: Update idle duration estimate when choosing shallower state [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Jul 31 20:56:35 2023 +0200

    cpuidle: teo: Update idle duration estimate when choosing shallower state
    
    [ Upstream commit 3f0b0966b30982e843950b170b7a9ddfd8094428 ]
    
    The TEO governor takes CPU utilization into account by refining idle state
    selection when the utilization is above a certain threshold.  This is done by
    choosing an idle state shallower than the previously selected one.
    
    However, when doing this, the idle duration estimate needs to be
    adjusted so as to prevent the scheduler tick from being stopped when the
    candidate idle state is shallow, which may lead to excessive energy
    usage if the CPU is not woken up quickly enough going forward.
    Moreover, if the scheduler tick has been stopped already and the new
    idle duration estimate is too small, the replacement candidate state
    cannot be used.
    
    Modify the relevant code to take the above observations into account.
    
    Fixes: 9ce0f7c4bc64 ("cpuidle: teo: Introduce util-awareness")
    Link: https://lore.kernel.org/linux-pm/CAJZ5v0jJxHj65r2HXBTd3wfbZtsg=_StzwO1kA5STDnaPe_dWA@mail.gmail.com
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-and-tested-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: af_alg - Decrement struct key.usage in alg_set_by_key_serial() [+ + +]
Author: Frederick Lawler <fred@cloudflare.com>
Date:   Tue Aug 1 08:57:09 2023 -0500

    crypto: af_alg - Decrement struct key.usage in alg_set_by_key_serial()
    
    commit 6b4b53ca0b7300ba2af98a49dbce22054bf034fe upstream.
    
    Calls to lookup_user_key() require a corresponding key_put() to
    decrement the usage counter. Once it reaches zero, we schedule key GC.
    Therefore decrement struct key.usage in alg_set_by_key_serial().
    
    Fixes: 7984ceb134bf ("crypto: af_alg - Support symmetric encryption via keyring keys")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Frederick Lawler <fred@cloudflare.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: api - Use work queue in crypto_destroy_instance [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Aug 3 17:59:28 2023 +0800

    crypto: api - Use work queue in crypto_destroy_instance
    
    [ Upstream commit 9ae4577bc077a7e32c3c7d442c95bc76865c0f17 ]
    
    The function crypto_drop_spawn expects to be called in process
    context.  However, when an instance is unregistered while it still
    has active users, the last user may cause the instance to be freed
    in atomic context.
    
    Fix this by delaying the freeing to a work queue.
    
    Fixes: 6bfd48096ff8 ("[CRYPTO] api: Added spawns")
    Reported-by: Florent Revest <revest@chromium.org>
    Reported-by: syzbot+d769eed29cc42d75e2a3@syzkaller.appspotmail.com
    Reported-by: syzbot+610ec0671f51e838436e@syzkaller.appspotmail.com
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Tested-by: Florent Revest <revest@chromium.org>
    Acked-by: Florent Revest <revest@chromium.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: caam - fix unchecked return value error [+ + +]
Author: Gaurav Jain <gaurav.jain@nxp.com>
Date:   Tue Aug 8 12:55:25 2023 +0200

    crypto: caam - fix unchecked return value error
    
    [ Upstream commit e30685204711a6be40dec2622606950ccd37dafe ]
    
    error:
    Unchecked return value (CHECKED_RETURN)
    check_return: Calling sg_miter_next without checking return value
    
    fix:
    added check if(!sg_miter_next)
    
    Fixes: 8a2a0dd35f2e ("crypto: caam - strip input zeros from RSA input buffer")
    Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
    Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
    Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - change value of default idle filter [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Jun 22 10:26:35 2023 +0100

    crypto: qat - change value of default idle filter
    
    [ Upstream commit 0f942bdfe9d463be3073301519492f8d53c6b2d5 ]
    
    The power management configuration of 4xxx devices is too aggressive
    and in some conditions the device might be prematurely put to a low
    power state.
    Increase the idle filter value to prevent that.
    In future, this will be set by firmware.
    
    Fixes: e5745f34113b ("crypto: qat - enable power management for QAT GEN4")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Damian Muszynski <damian.muszynski@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: stm32 - fix loop iterating through scatterlist for DMA [+ + +]
Author: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
Date:   Thu Jul 13 17:15:15 2023 +0200

    crypto: stm32 - fix loop iterating through scatterlist for DMA
    
    commit d9c83f71eeceed2cb54bb78be84f2d4055fd9a1f upstream.
    
    We were reading the length of the scatterlist sg after copying value of
    tsg inside.
    So we are using the size of the previous scatterlist and for the first
    one we are using an unitialised value.
    Fix this by copying tsg in sg[0] before reading the size.
    
    Fixes : 8a1012d3f2ab ("crypto: stm32 - Support for STM32 HASH module")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: stm32 - fix MDMAT condition [+ + +]
Author: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
Date:   Thu Jul 13 17:15:17 2023 +0200

    crypto: stm32 - fix MDMAT condition
    
    commit a4adfbc2544933ac12e7fbd50708290265546dbc upstream.
    
    If IP has MDMAT support, set or reset the bit MDMAT in Control Register.
    
    Fixes: b56403a25af7 ("crypto: stm32/hash - Support Ux500 hash")
    Cc: stable@vger.kernel.org
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: stm32 - Properly handle pm_runtime_get failing [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Jul 31 18:54:54 2023 +0200

    crypto: stm32 - Properly handle pm_runtime_get failing
    
    [ Upstream commit aec48805163338f8413118796c1dd035661b9140 ]
    
    If pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, this
    means the clk wasn't prepared and enabled. Returning early in this case
    however is wrong as then the following resource frees are skipped and this
    is never catched up. So do all the cleanups but clk_disable_unprepare().
    
    Also don't emit a warning, as stm32_hash_runtime_resume() already emitted
    one.
    
    Note that the return value of stm32_hash_remove() is mostly ignored by
    the device core. The only effect of returning zero instead of an error
    value is to suppress another warning in platform_remove(). So return 0
    even if pm_runtime_resume_and_get() failed.
    
    Fixes: 8b4d566de6a5 ("crypto: stm32/hash - Add power management support")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cteonxt2-pf: Fix backpressure config for multiple PFC priorities to work simultaneously [+ + +]
Author: Suman Ghosh <sumang@marvell.com>
Date:   Thu Aug 24 13:40:32 2023 +0530

    cteonxt2-pf: Fix backpressure config for multiple PFC priorities to work simultaneously
    
    [ Upstream commit 597d0ec0e4ca6a912affea4cc94df08959e9ec74 ]
    
    MAC (CGX or RPM) asserts backpressure at TL3 or TL2 node of the egress
    hierarchical scheduler tree depending on link level config done. If
    there are multiple PFC priorities enabled at a time and for all such
    flows to backoff, each priority will have to assert backpressure at
    different TL3/TL2 scheduler nodes and these flows will need to submit
    egress pkts to these nodes.
    
    Current PFC configuration has an issue where in only one backpressure
    scheduler node is being allocated which is resulting in only one PFC
    priority to work. This patch fixes this issue.
    
    Fixes: 99c969a83d82 ("octeontx2-pf: Add egress PFC support")
    Signed-off-by: Suman Ghosh <sumang@marvell.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824081032.436432-4-sumang@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dccp: Fix out of bounds access in DCCP error handler [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Fri Aug 25 15:32:41 2023 +0200

    dccp: Fix out of bounds access in DCCP error handler
    
    commit 977ad86c2a1bcaf58f01ab98df5cc145083c489c upstream.
    
    There was a previous attempt to fix an out-of-bounds access in the DCCP
    error handlers, but that fix assumed that the error handlers only want
    to access the first 8 bytes of the DCCP header. Actually, they also look
    at the DCCP sequence number, which is stored beyond 8 bytes, so an
    explicit pskb_may_pull() is required.
    
    Fixes: 6706a97fec96 ("dccp: fix out of bound access in dccp_v4_err()")
    Fixes: 1aa9d1a0e7ee ("ipv6: dccp: fix out of bound access in dccp_v6_err()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jann Horn <jannh@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dlm: fix plock lookup when using multiple lockspaces [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Aug 24 16:51:42 2023 -0400

    dlm: fix plock lookup when using multiple lockspaces
    
    commit 7c53e847ff5e97f033fdd31f71949807633d506b upstream.
    
    All posix lock ops, for all lockspaces (gfs2 file systems) are
    sent to userspace (dlm_controld) through a single misc device.
    The dlm_controld daemon reads the ops from the misc device
    and sends them to other cluster nodes using separate, per-lockspace
    cluster api communication channels.  The ops for a single lockspace
    are ordered at this level, so that the results are received in
    the same sequence that the requests were sent.  When the results
    are sent back to the kernel via the misc device, they are again
    funneled through the single misc device for all lockspaces.  When
    the dlm code in the kernel processes the results from the misc
    device, these results will be returned in the same sequence that
    the requests were sent, on a per-lockspace basis.  A recent change
    in this request/reply matching code missed the "per-lockspace"
    check (fsid comparison) when matching request and reply, so replies
    could be incorrectly matched to requests from other lockspaces.
    
    Cc: stable@vger.kernel.org
    Reported-by: Barry Marson <bmarson@redhat.com>
    Fixes: 57e2c2f2d94c ("fs: dlm: fix mismatch of plock results from userspace")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dma-buf/sync_file: Fix docs syntax [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Mon Jul 24 07:49:41 2023 -0700

    dma-buf/sync_file: Fix docs syntax
    
    [ Upstream commit 05d56d8079d510a2994039470f65bea85f0075ee ]
    
    Fixes the warning:
    
      include/uapi/linux/sync_file.h:77: warning: Function parameter or member 'num_fences' not described in 'sync_file_info'
    
    Fixes: 2d75c88fefb2 ("staging/android: refactor SYNC IOCTLs")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20230724145000.125880-1-robdclark@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: idxd: Allow ATS disable update only for configurable devices [+ + +]
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Thu Aug 10 18:26:34 2023 -0700

    dmaengine: idxd: Allow ATS disable update only for configurable devices
    
    [ Upstream commit 0056a7f07b0a63e6cee815a789eabba6f3a710f0 ]
    
    ATS disable status in a WQ is read-only if the device is not configurable.
    This change ensures that the ATS disable attribute can be modified via
    sysfs only on configurable devices.
    
    Fixes: 92de5fa2dc39 ("dmaengine: idxd: add ATS disable knob for work queues")
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20230811012635.535413-1-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: idxd: Expose ATS disable knob only when WQ ATS is supported [+ + +]
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Wed Jul 12 10:44:36 2023 -0700

    dmaengine: idxd: Expose ATS disable knob only when WQ ATS is supported
    
    [ Upstream commit 62b41b656666d2d35890124df5ef0881fe6d6769 ]
    
    WQ Advanced Translation Service (ATS) can be controlled only when
    WQ ATS is supported. The sysfs ATS disable knob should be visible only
    when the features is supported.
    
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20230712174436.3435088-2-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: 0056a7f07b0a ("dmaengine: idxd: Allow ATS disable update only for configurable devices")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: idxd: Fix issues with PRS disable sysfs knob [+ + +]
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Thu Aug 10 18:26:35 2023 -0700

    dmaengine: idxd: Fix issues with PRS disable sysfs knob
    
    [ Upstream commit 8cae66574398326134a41513b419e00ad4e380ca ]
    
    There are two issues in the current PRS disable sysfs store function
    wq_prs_disable_store():
    
    1. Since PRS disable knob is invisible if PRS disable is not supported
       in WQ, it's redundant to check PRS support again in the store function
       again. Remove the redundant PRS support check.
    2. Since PRS disable is read-only when the device is not configurable,
       PRS disable cannot be changed on the device. Add device configurable
       check in the store function.
    
    Fixes: f2dc327131b5 ("dmaengine: idxd: add per wq PRS disable")
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20230811012635.535413-2-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: idxd: Modify the dependence of attribute pasid_enabled [+ + +]
Author: Rex Zhang <rex.zhang@intel.com>
Date:   Wed Jun 14 14:27:06 2023 +0800

    dmaengine: idxd: Modify the dependence of attribute pasid_enabled
    
    [ Upstream commit 50c5e6f41d5ad7c731c31135a30d0e4f0e4fea26 ]
    
    Kernel PASID and user PASID are separately enabled. User needs to know the
    user PASID enabling status to decide how to use IDXD device in user space.
    This is done via the attribute /sys/bus/dsa/devices/dsa0/pasid_enabled.
    It's unnecessary for user to know the kernel PASID enabling status because
    user won't use the kernel PASID. But instead of showing the user PASID
    enabling status, the attribute shows the kernel PASID enabling status. Fix
    the issue by showing the user PASID enabling status in the attribute.
    
    Fixes: 42a1b73852c4 ("dmaengine: idxd: Separate user and kernel pasid enabling")
    Signed-off-by: Rex Zhang <rex.zhang@intel.com>
    Acked-by: Fenghua Yu <fenghua.yu@intel.com>
    Acked-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20230614062706.1743078-1-rex.zhang@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: idxd: Simplify WQ attribute visibility checks [+ + +]
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Wed Jul 12 10:44:35 2023 -0700

    dmaengine: idxd: Simplify WQ attribute visibility checks
    
    [ Upstream commit 97b1185fe54c8ce94104e3c7fa4ee0bbedd85920 ]
    
    The functions that check if WQ attributes are invisible are almost
    duplicate. Define a helper to simplify these functions and future
    WQ attribute visibility checks as well.
    
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20230712174436.3435088-1-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: 0056a7f07b0a ("dmaengine: idxd: Allow ATS disable update only for configurable devices")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ste_dma40: Add missing IRQ check in d40_probe [+ + +]
Author: ruanjinjie <ruanjinjie@huawei.com>
Date:   Mon Jul 24 14:41:08 2023 +0000

    dmaengine: ste_dma40: Add missing IRQ check in d40_probe
    
    [ Upstream commit c05ce6907b3d6e148b70f0bb5eafd61dcef1ddc1 ]
    
    Check for the return value of platform_get_irq(): if no interrupt
    is specified, it wouldn't make sense to call request_irq().
    
    Fixes: 8d318a50b3d7 ("DMAENGINE: Support for ST-Ericssons DMA40 block v3")
    Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20230724144108.2582917-1-ruanjinjie@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
docs: ABI: fix spelling/grammar in SBEFIFO timeout interface [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jul 9 22:23:05 2023 -0700

    docs: ABI: fix spelling/grammar in SBEFIFO timeout interface
    
    [ Upstream commit 2cd9ec2a51474d4c0b4d2a061f2de7da34eff476 ]
    
    Correct spelling problems as identified by codespell.
    Correct one grammar error.
    
    Fixes: 9a93de620e0a ("docs: ABI: testing: Document the SBEFIFO timeout interface")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Eddie James <eajames@linux.ibm.com>
    Cc: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20230710052305.29611-1-rdunlap@infradead.org
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
driver core: Call dma_cleanup() on the test_remove path [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Jul 24 14:40:46 2023 -0300

    driver core: Call dma_cleanup() on the test_remove path
    
    [ Upstream commit f429378a9bf84d79a7e2cae05d2e3384cf7d68ba ]
    
    When test_remove is enabled really_probe() does not properly pair
    dma_configure() with dma_remove(), it will end up calling dma_configure()
    twice. This corrupts the owner_cnt and renders the group unusable with
    VFIO/etc.
    
    Add the missing cleanup before going back to re_probe.
    
    Fixes: 25f3bcfc54bc ("driver core: Add dma_cleanup callback in bus_type")
    Reported-by: Zenghui Yu <yuzenghui@huawei.com>
    Tested-by: Zenghui Yu <yuzenghui@huawei.com>
    Closes: https://lore.kernel.org/all/6472f254-c3c4-8610-4a37-8d9dfdd54ce8@huawei.com/
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/0-v2-4deed94e283e+40948-really_probe_dma_cleanup_jgg@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

driver core: test_async: fix an error code [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Jul 18 10:03:49 2023 +0300

    driver core: test_async: fix an error code
    
    [ Upstream commit 22d2381bbd70a5853c2ee77522f4965139672db9 ]
    
    The test_platform_device_register_node() function should return error
    pointers instead of NULL.  That is what the callers are expecting.
    
    Fixes: 57ea974fb871 ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/1e11ed19-e1f6-43d8-b352-474134b7c008@moroto.mountain
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers: base: Free devm resources when unregistering a device [+ + +]
Author: David Gow <davidgow@google.com>
Date:   Thu Jul 20 14:45:09 2023 +0200

    drivers: base: Free devm resources when unregistering a device
    
    [ Upstream commit 699fb50d99039a50e7494de644f96c889279aca3 ]
    
    In the current code, devres_release_all() only gets called if the device
    has a bus and has been probed.
    
    This leads to issues when using bus-less or driver-less devices where
    the device might never get freed if a managed resource holds a reference
    to the device. This is happening in the DRM framework for example.
    
    We should thus call devres_release_all() in the device_del() function to
    make sure that the device-managed actions are properly executed when the
    device is unregistered, even if it has neither a bus nor a driver.
    
    This is effectively the same change than commit 2f8d16a996da ("devres:
    release resources on device_del()") that got reverted by commit
    a525a3ddeaca ("driver core: free devres in device_release") over
    memory leaks concerns.
    
    This patch effectively combines the two commits mentioned above to
    release the resources both on device_del() and device_release() and get
    the best of both worlds.
    
    Fixes: a525a3ddeaca ("driver core: free devres in device_release")
    Signed-off-by: David Gow <davidgow@google.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://lore.kernel.org/r/20230720-kunit-devm-inconsistencies-test-v3-3-6aa7e074f373@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers: clk: keystone: Fix parameter judgment in _of_pll_clk_init() [+ + +]
Author: Minjie Du <duminjie@vivo.com>
Date:   Wed Jul 12 18:22:46 2023 +0800

    drivers: clk: keystone: Fix parameter judgment in _of_pll_clk_init()
    
    [ Upstream commit a995c50db887ef97f3160775aef7d772635a6f6e ]
    
    The function clk_register_pll() may return NULL or an ERR_PTR. Don't
    treat an ERR_PTR as valid.
    
    Signed-off-by: Minjie Du <duminjie@vivo.com>
    Link: https://lore.kernel.org/r/20230712102246.10348-1-duminjie@vivo.com
    Fixes: b9e0d40c0d83 ("clk: keystone: add Keystone PLL clock driver")
    [sboyd@kernel.org: Reword commit text]
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Drivers: hv: vmbus: Don't dereference ACPI root object handle [+ + +]
Author: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Date:   Wed Aug 9 20:40:18 2023 +0200

    Drivers: hv: vmbus: Don't dereference ACPI root object handle
    
    [ Upstream commit 78e04bbff849b51b56f5925b1945db2c6e128b61 ]
    
    Since the commit referenced in the Fixes: tag below the VMBus client driver
    is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
    namespace root object trying to find Hyper-V MMIO ranges.
    
    However, if it is not able to find them it ends trying to walk resources of
    the ACPI namespace root object itself.
    This object has all-ones handle, which causes a NULL pointer dereference
    in the ACPI code (from dereferencing this pointer with an offset).
    
    This in turn causes an oops on boot with VMBus host implementations that do
    not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
    ancestors.
    The QEMU VMBus implementation is an example of such implementation.
    
    I guess providing these ranges is optional, since all tested Windows
    versions seem to be able to use VMBus devices without them.
    
    Fix this by explicitly terminating the lookup at the ACPI namespace root
    object.
    
    Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
    by default - they only do so if the KVM PV interface is missing or
    disabled.
    
    Example stack trace of such oops:
    [ 3.710827] ? __die+0x1f/0x60
    [ 3.715030] ? page_fault_oops+0x159/0x460
    [ 3.716008] ? exc_page_fault+0x73/0x170
    [ 3.716959] ? asm_exc_page_fault+0x22/0x30
    [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
    [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
    [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0
    [ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200
    [ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0
    [ 3.723559] ? down_timeout+0x3a/0x60
    [ 3.724455] ? acpi_ns_get_node+0x3a/0x60
    [ 3.725412] acpi_ns_get_node+0x3a/0x60
    [ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0
    [ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0
    [ 3.728400] acpi_rs_get_method_data+0x2b/0x70
    [ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
    [ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
    [ 3.732411] acpi_walk_resources+0x78/0xd0
    [ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]
    [ 3.734802] platform_probe+0x3d/0x90
    [ 3.735684] really_probe+0x19b/0x400
    [ 3.736570] ? __device_attach_driver+0x100/0x100
    [ 3.737697] __driver_probe_device+0x78/0x160
    [ 3.738746] driver_probe_device+0x1f/0x90
    [ 3.739743] __driver_attach+0xc2/0x1b0
    [ 3.740671] bus_for_each_dev+0x70/0xc0
    [ 3.741601] bus_add_driver+0x10e/0x210
    [ 3.742527] driver_register+0x55/0xf0
    [ 3.744412] ? 0xffffffffc039a000
    [ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]
    
    Fixes: 7f163a6fd957 ("drivers:hv: Modify hv_vmbus to search for all MMIO ranges available.")
    Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Link: https://lore.kernel.org/r/fd8e64ceeecfd1d95ff49021080cf699e88dbbde.1691606267.git.maciej.szmigiero@oracle.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers: usb: smsusb: fix error handling code in smsusb_init_device [+ + +]
Author: Dongliang Mu <dzm91@hust.edu.cn>
Date:   Mon Feb 27 18:24:08 2023 +0800

    drivers: usb: smsusb: fix error handling code in smsusb_init_device
    
    [ Upstream commit b9c7141f384097fa4fa67d2f72e5731d628aef7c ]
    
    The previous commit 4b208f8b561f ("[media] siano: register media controller
    earlier")moves siano_media_device_register before smscore_register_device,
    and adds corresponding error handling code if smscore_register_device
    fails. However, it misses the following error handling code of
    smsusb_init_device.
    
    Fix this by moving error handling code at the end of smsusb_init_device
    and adding a goto statement in the following error handling parts.
    
    Fixes: 4b208f8b561f ("[media] siano: register media controller earlier")
    Signed-off-by: Dongliang Mu <dzm91@hust.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Add smu write msg id fail retry process [+ + +]
Author: Fudong Wang <fudong.wang@amd.com>
Date:   Fri Aug 11 08:24:59 2023 +0800

    drm/amd/display: Add smu write msg id fail retry process
    
    commit 72105dcfa3d12b5af49311f857e3490baa225135 upstream.
    
    A benchmark stress test (12-40 machines x 48hours) found that DCN315 has
    cases where DC writes to an indirect register to set the smu clock msg
    id, but when we go to read the same indirect register the returned msg
    id doesn't match with what we just set it to. So, to fix this retry the
    write until the register's value matches with the requested value.
    
    Cc: stable@vger.kernel.org # 6.1+
    Fixes: f94903996140 ("drm/amd/display: Add DCN315 CLK_MGR")
    Reviewed-by: Charlene Liu <charlene.liu@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Fudong Wang <fudong.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Do not set drr on pipe commit [+ + +]
Author: Wesley Chalmers <Wesley.Chalmers@amd.com>
Date:   Thu Nov 3 22:29:31 2022 -0400

    drm/amd/display: Do not set drr on pipe commit
    
    [ Upstream commit e101bf95ea87ccc03ac2f48dfc0757c6364ff3c7 ]
    
    [WHY]
    Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
    pipe commit can cause underflow.
    
    [HOW]
    Move DMUB p-state delegate into optimze_bandwidth; enabling FAMS sets
    optimized_required.
    
    This change expects that Freesync requests are blocked when
    optimized_required is true.
    
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: ensure async flips are only accepted for fast updates [+ + +]
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date:   Fri Aug 4 11:13:04 2023 -0400

    drm/amd/display: ensure async flips are only accepted for fast updates
    
    commit a7c0cad0dc060bb77e9c9d235d68441b0fc69507 upstream.
    
    We should be checking to see if async flips are supported in
    amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
    async flipping isn't supported if a plane's framebuffer changes memory
    domains during an atomic commit. So, move the check from
    dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if
    the memory domain has changed in amdgpu_dm_atomic_check().
    
    Cc: stable@vger.kernel.org
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2733
    Fixes: c1e18c44dc7f ("drm/amd/display: only accept async flips for fast updates")
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Exit idle optimizations before attempt to access PHY [+ + +]
Author: Leo Chen <sancchen@amd.com>
Date:   Wed Jul 12 16:50:15 2023 -0400

    drm/amd/display: Exit idle optimizations before attempt to access PHY
    
    [ Upstream commit de612738e9771bd66aeb20044486c457c512f684 ]
    
    [Why & How]
    DMUB may hang when powering down pixel clocks due to no dprefclk.
    
    It is fixed by exiting idle optimization before the attempt to access PHY.
    
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Acked-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Leo Chen <sancchen@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Guard DCN31 PHYD32CLK logic against chip family [+ + +]
Author: George Shen <george.shen@amd.com>
Date:   Tue Jul 11 13:22:36 2023 -0400

    drm/amd/display: Guard DCN31 PHYD32CLK logic against chip family
    
    [ Upstream commit 25b054c3c89cb6a7106a7982f0f70e83d0797dab ]
    
    [Why]
    Current yellow carp B0 PHYD32CLK logic is incorrectly applied to other
    ASICs.
    
    [How]
    Add guard to check chip family is yellow carp before applying logic.
    
    Reviewed-by: Hansen Dsouza <hansen.dsouza@amd.com>
    Acked-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: George Shen <george.shen@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: register edp_backlight_control() for DCN301 [+ + +]
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date:   Tue Aug 22 12:31:09 2023 -0400

    drm/amd/display: register edp_backlight_control() for DCN301
    
    commit 1611917f39bee1abfc01501238db8ac19649042d upstream.
    
    As made mention of in commit 099303e9a9bd ("drm/amd/display: eDP
    intermittent black screen during PnP"), we need to turn off the
    display's backlight before powering off an eDP display. Not doing so
    will result in undefined behaviour according to the eDP spec. So, set
    DCN301's edp_backlight_control() function pointer to
    dce110_edp_backlight_control().
    
    Cc: stable@vger.kernel.org
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2765
    Fixes: 9c75891feef0 ("drm/amd/display: rework recent update PHY state commit")
    Suggested-by: Swapnil Patel <swapnil.patel@amd.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/pm: Fix temperature unit of SMU v13.0.6 [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Thu Aug 10 16:10:03 2023 +0530

    drm/amd/pm: Fix temperature unit of SMU v13.0.6
    
    [ Upstream commit 8d036427f0042a91136e6f19a39542eedec4e96c ]
    
    Temperature needs to be reported in millidegree Celsius.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix variable dereferenced issue in amdgpu_device_attr_create() [+ + +]
Author: Yang Wang <kevinyang.wang@amd.com>
Date:   Tue Aug 1 16:53:23 2023 +0800

    drm/amd/pm: fix variable dereferenced issue in amdgpu_device_attr_create()
    
    [ Upstream commit 25e6373a5b8efc623443f2699d2b929bf3067d76 ]
    
    - fix variable ('attr') dereferenced issue.
    - using condition check instead of BUG_ON().
    
    Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
    Cc: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
    Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/smu: use AverageGfxclkFrequency* to replace previous GFX Curr Clock [+ + +]
Author: Jane Jian <Jane.Jian@amd.com>
Date:   Thu Jul 20 18:08:07 2023 +0800

    drm/amd/smu: use AverageGfxclkFrequency* to replace previous GFX Curr Clock
    
    [ Upstream commit 4a37c55b859a69f429bfa7fab4fc43ee470b60ed ]
    
    Report current GFX clock also from average clock value as the original
    CurrClock data is not valid/accurate any more as per FW team
    
    Signed-off-by: Jane Jian <Jane.Jian@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar() [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 7 13:11:51 2023 +0200

    drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()
    
    [ Upstream commit 822130b5e8834ab30ad410cf19a582e5014b9a85 ]
    
    On 32-bit architectures comparing a resource against a value larger than
    U32_MAX can cause a warning:
    
    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
                        res->start > 0x100000000ull)
                        ~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
    
    As gcc does not warn about this in dead code, add an IS_ENABLED() check at
    the start of the function. This will always return success but not actually resize
    the BAR on 32-bit architectures without high memory, which is exactly what
    we want here, as the driver can fall back to bank switching the VRAM
    access.
    
    Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR resize")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Match against exact bootloader status [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Tue Jul 25 19:11:54 2023 +0530

    drm/amdgpu: Match against exact bootloader status
    
    [ Upstream commit d3de41ee5febe5c2d9989fe9810bce2bb54a3a8e ]
    
    On PSP v13.x ASICs, boot loader will set only the MSB to 1 and clear the
    least significant bits for any command submission. Hence match against
    the exact register value, otherwise a register value of all 0xFFs also
    could falsely indicate that boot loader is ready. Also, from PSP v13.0.6
    and newer, bits[7:0] will be used to indicate command error status.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Update min() to min_t() in 'amdgpu_info_ioctl' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Sun Jul 23 12:29:14 2023 +0530

    drm/amdgpu: Update min() to min_t() in 'amdgpu_info_ioctl'
    
    [ Upstream commit a0cc8e1512ad72c9f97cdcb76d42715730adaf62 ]
    
    Fixes the following:
    
    WARNING: min() should probably be min_t(size_t, size, sizeof(ip))
    +               ret = copy_to_user(out, &ip, min((size_t)size, sizeof(ip)));
    
    And other style fixes:
    
    WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
    WARNING: Missing a blank line after declarations
    
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Use RMW accessors for changing LNKCTL [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 15:04:57 2023 +0300

    drm/amdgpu: Use RMW accessors for changing LNKCTL
    
    [ Upstream commit ce7d88110b9ed5f33fe79ea6d4ed049fb0e57bce ]
    
    Don't assume that only the driver would be accessing LNKCTL. ASPM policy
    changes can trigger write to LNKCTL outside of driver's control.  And in
    the case of upstream bridge, the driver does not even own the device it's
    changing the registers for.
    
    Use RMW capability accessors which do proper locking to avoid losing
    concurrent updates to the register value.
    
    Suggested-by: Lukas Wunner <lukas@wunner.de>
    Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
    Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
    Link: https://lore.kernel.org/r/20230717120503.15276-6-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/armada: Fix off-by-one error in armada_overlay_get_property() [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Jul 17 15:25:40 2023 +0200

    drm/armada: Fix off-by-one error in armada_overlay_get_property()
    
    [ Upstream commit 5f0d984053f74983a287100a9519b2fabb785fb5 ]
    
    As ffs() returns one more than the index of the first bit set (zero
    means no bits set), the color key mode value is shifted one position too
    much.
    
    Fix this by using FIELD_GET() instead.
    
    Fixes: c96103b6c49ff9a8 ("drm/armada: move colorkey properties into overlay plane state")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/a4d779d954a7515ddbbf31cb0f0d8184c0e7c879.1689600265.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/ast: report connection status on Display Port. [+ + +]
Author: Jocelyn Falempe <jfalempe@redhat.com>
Date:   Thu Jul 13 15:41:31 2023 +0200

    drm/ast: report connection status on Display Port.
    
    [ Upstream commit f81bb0ac7872893241319ea82504956676ef02fd ]
    
    Aspeed always report the display port as "connected", because it
    doesn't set a .detect_ctx callback.
    Fix this by providing the proper detect callback for astdp and dp501.
    
    This also fixes the following regression:
    Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
    EDID on DP") The default resolution is now 640x480 when no monitor is
    connected. But Aspeed graphics is mostly used in servers, where no monitor
    is attached. This also affects the remote BMC resolution to 640x480, which
    is inconvenient, and breaks the anaconda installer.
    
    v2: Add .detect callback to the dp/dp501 connector (Jani Nikula)
    v3: Use .detect_ctx callback, and refactors (Thomas Zimmermann)
        Add a BMC virtual connector
    v4: Better indent detect_ctx() functions (Thomas Zimmermann)
    v5: Enable polling of the dp and dp501 connector status
        (Thomas Zimmermann)
    v6: Change check order in ast_astdp_is_connected (Jammy Huang)
    
    Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID on DP")
    Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230713134316.332502-2-jfalempe@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: anx7625: Use common macros for DP power sequencing commands [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Mon Jul 10 17:09:27 2023 +0800

    drm/bridge: anx7625: Use common macros for DP power sequencing commands
    
    [ Upstream commit 2ba776f903cb7157e80b5f314fb0b4faf6ea6958 ]
    
    The DRM DP code has macros for the DP power sequencing commands. Use
    them in the anx7625 driver instead of raw numbers.
    
    Fixes: 548b512e144f ("drm/bridge: anx7625: send DPCD command to downstream")
    Fixes: 27f26359de9b ("drm/bridge: anx7625: Set downstream sink into normal status")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230710090929.1873646-1-wenst@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: anx7625: Use common macros for HDCP capabilities [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Mon Jul 10 17:12:01 2023 +0800

    drm/bridge: anx7625: Use common macros for HDCP capabilities
    
    [ Upstream commit 41639b3a8b0f1f194dfe0577d99db70613f78626 ]
    
    The DRM DP code has macros for the DP HDCP capabilities. Use them in the
    anx7625 driver instead of raw numbers.
    
    Fixes: cd1637c7e480 ("drm/bridge: anx7625: add HDCP support")
    Suggested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230710091203.1874317-1-wenst@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358764: Fix debug print parameter order [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu Jun 15 17:28:17 2023 +0200

    drm/bridge: tc358764: Fix debug print parameter order
    
    [ Upstream commit 7f947be02aab5b154427cb5b0fffe858fc387b02 ]
    
    The debug print parameters were swapped in the output and they were
    printed as decimal values, both the hardware address and the value.
    Update the debug print to print the parameters in correct order, and
    use hexadecimal print for both address and value.
    
    Fixes: f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230615152817.359420-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/etnaviv: fix dumping of active MMU context [+ + +]
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Apr 14 16:38:10 2023 +0200

    drm/etnaviv: fix dumping of active MMU context
    
    [ Upstream commit 20faf2005ec85fa1a6acc9a74ff27de667f90576 ]
    
    gpu->mmu_context is the MMU context of the last job in the HW queue, which
    isn't necessarily the same as the context from the bad job. Dump the MMU
    context from the scheduler determined bad submit to make it work as intended.
    
    Fixes: 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on MMUv2")
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/hyperv: Fix a compilation issue because of not including screen_info.h [+ + +]
Author: Sui Jingfeng <suijingfeng@loongson.cn>
Date:   Sun Jul 9 18:05:14 2023 +0800

    drm/hyperv: Fix a compilation issue because of not including screen_info.h
    
    [ Upstream commit 8d1077cf2e43b15fefd76ebec2b71541eb27ef2c ]
    
    Fixes the following build errors on arm64:
    
    drivers/video/fbdev/hyperv_fb.c: In function 'hvfb_getmem':
    >> drivers/video/fbdev/hyperv_fb.c:1033:24: error: 'screen_info' undeclared (first use in this function)
        1033 |                 base = screen_info.lfb_base;
             |                        ^~~~~~~~~~~
    drivers/video/fbdev/hyperv_fb.c:1033:24: note: each undeclared identifier is reported only once for each function it appears in
    
    >> drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: error: 'screen_info' undeclared (first use in this function)
          75 |         drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
             |                                                      ^~~~~~~~~~~
    drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: note: each undeclared identifier is reported only once for each function it appears in
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202307090823.nxnT8Kk5-lkp@intel.com/
    Fixes: 81d2393485f0 ("fbdev/hyperv-fb: Do not set struct fb_info.apertures")
    Fixes: 8b0d13545b09 ("efi: Do not include <linux/screen_info.h> from EFI header")
    Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230709100514.703759-1-suijingfeng@loongson.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/mediatek: Add cnt checking for coverity issue [+ + +]
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Fri Jul 14 17:49:06 2023 +0800

    drm/mediatek: Add cnt checking for coverity issue
    
    [ Upstream commit d761b9450e31e5abd212f0085d424ed32760de5a ]
    
    CERT-C Characters and Strings (CERT STR31-C)
    all_drm_priv[cnt] evaluates to an address that could be at negative
    offset of an array.
    
    In mtk_drm_get_all_drm_priv():
    Guarantee that storage for strings has sufficient space for character
    data and the null terminator.
    
    So change cnt to unsigned int and check its max value.
    
    Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support")
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230714094908.13087-3-jason-jh.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: dp: Add missing error checks in mtk_dp_parse_capabilities [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Tue Jul 25 09:32:24 2023 +0200

    drm/mediatek: dp: Add missing error checks in mtk_dp_parse_capabilities
    
    [ Upstream commit cfc146137a9f12e883ba64bc496b6da4d23f26d5 ]
    
    If reading the RX capabilities fails the training pattern will be set
    wrongly: add error checking for drm_dp_read_dpcd_caps() and return if
    anything went wrong with it.
    
    While at it, also add a less critical error check when writing to
    clear the ESI0 IRQ vector.
    
    Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Tested-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230725073234.55892-2-angelogioacchino.delregno@collabora.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Fix potential memory leak if vmap() fail [+ + +]
Author: Sui Jingfeng <suijingfeng@loongson.cn>
Date:   Thu Jul 6 21:40:00 2023 +0800

    drm/mediatek: Fix potential memory leak if vmap() fail
    
    [ Upstream commit 379091e0f6d179d1a084c65de90fa44583b14a70 ]
    
    Also return -ENOMEM if such a failure happens, the implement should take
    responsibility for the error handling.
    
    Fixes: 3df64d7b0a4f ("drm/mediatek: Implement gem prime vmap/vunmap function")
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230706134000.130098-1-suijingfeng@loongson.cn/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Fix uninitialized symbol [+ + +]
Author: Nancy.Lin <nancy.lin@mediatek.com>
Date:   Thu Aug 3 17:48:43 2023 +0800

    drm/mediatek: Fix uninitialized symbol
    
    [ Upstream commit 63ee9438f2aeffb2d1b2df2599c168ca08d35025 ]
    
    Fix Smatch static checker warning
      -Fix uninitialized symbol comp_pdev in mtk_ddp_comp_init.
    
    Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
    Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230803094843.4439-1-nancy.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Fix void-pointer-to-enum-cast warning [+ + +]
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Wed Jun 21 15:54:21 2023 +0800

    drm/mediatek: Fix void-pointer-to-enum-cast warning
    
    [ Upstream commit 89cba955f879b1c6a9a71f67c8fb92ea8f5dfdc4 ]
    
    1. Fix build warning message in mtk_disp_ovl_adaptor.c
    >> drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c:415:10:
      warning: cast to smaller integer type 'enum mtk_ovl_adaptor_comp_type'
      from 'const void *' [-Wvoid-pointer-to-enum-cast]
    
      type = (enum mtk_ovl_adaptor_comp_type)of_id->data;
    
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             1 warning generated.
    
    2. Also fix the same warning message in mtk_drm_drv.c
    >> drivers/gpu/drm/mediatek/mtk_drm_drv.c:832:15:
       warning: cast to smaller integer type 'enum mtk_ddp_comp_type'
       from 'const void *' [-Wvoid-pointer-to-enum-cast]
    
       comp_type = (enum mtk_ddp_comp_type)of_id->data;
    
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                   1 warning generated.
    
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Fixes: 453c3364632a ("drm/mediatek: Add ovl_adaptor support for MT8195")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202305042054.ZtWME9OU-lkp@intel.com/
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230621075421.1982-1-jason-jh.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: Remove freeing not dynamic allocated memory [+ + +]
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Fri Jul 14 17:49:05 2023 +0800

    drm/mediatek: Remove freeing not dynamic allocated memory
    
    [ Upstream commit 27b9e2ea3f2757da26bb8280e46f7fdbb1acb219 ]
    
    Fixing the coverity issue of:
    mtk_drm_cmdq_pkt_destroy frees address of mtk_crtc->cmdq_handle
    
    So remove the free function.
    
    Fixes: 7627122fd1c0 ("drm/mediatek: Add cmdq_handle in mtk_crtc")
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20230714094908.13087-2-jason-jh.lin@mediatek.com/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/a2xx: Call adreno_gpu_init() earlier [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Tue Jun 20 20:23:19 2023 -0300

    drm/msm/a2xx: Call adreno_gpu_init() earlier
    
    [ Upstream commit db07ce5da8b26bfeaf437a676ae49bd3bb1eace6 ]
    
    The adreno_is_a20x() and adreno_is_a225() functions rely on the
    GPU revision, but such information is retrieved inside adreno_gpu_init(),
    which is called afterwards.
    
    Fix this problem by caling adreno_gpu_init() earlier, so that
    the GPU information revision is available when adreno_is_a20x()
    and adreno_is_a225() run.
    
    Tested on a imx53-qsb board.
    
    Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/543456/
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/a6xx: Fix GMU lockdep splat [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Thu Aug 3 10:34:28 2023 -0700

    drm/msm/a6xx: Fix GMU lockdep splat
    
    [ Upstream commit 3136a0f83519076edfbc14be65f286785434189a ]
    
    For normal GPU devfreq, we need to acquire the GMU lock while already
    holding devfreq locks.  But in the teardown path, we were calling
    dev_pm_domain_detach() while already holding the GMU lock, resulting in
    this lockdep splat:
    
       ======================================================
       WARNING: possible circular locking dependency detected
       6.4.3-debug+ #3 Not tainted
       ------------------------------------------------------
       ring0/391 is trying to acquire lock:
       ffffff80a025c078 (&devfreq->lock){+.+.}-{3:3}, at: qos_notifier_call+0x30/0x74
    
       but task is already holding lock:
       ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78
    
       which lock already depends on the new lock.
    
       the existing dependency chain (in reverse order) is:
    
       -> #4 (&(c->notifiers)->rwsem){++++}-{3:3}:
              down_write+0x58/0x74
              __blocking_notifier_chain_register+0x64/0x84
              blocking_notifier_chain_register+0x1c/0x28
              freq_qos_add_notifier+0x5c/0x7c
              dev_pm_qos_add_notifier+0xd4/0xf0
              devfreq_add_device+0x42c/0x560
              devm_devfreq_add_device+0x6c/0xb8
              msm_devfreq_init+0xa8/0x16c [msm]
              msm_gpu_init+0x368/0x54c [msm]
              adreno_gpu_init+0x248/0x2b0 [msm]
              a6xx_gpu_init+0x2d0/0x384 [msm]
              adreno_bind+0x264/0x2bc [msm]
              component_bind_all+0x124/0x1f4
              msm_drm_bind+0x2d0/0x5f4 [msm]
              try_to_bring_up_aggregate_device+0x88/0x1a4
              __component_add+0xd4/0x128
              component_add+0x1c/0x28
              dp_display_probe+0x37c/0x3c0 [msm]
              platform_probe+0x70/0xc0
              really_probe+0x148/0x280
              __driver_probe_device+0xfc/0x114
              driver_probe_device+0x44/0x100
              __device_attach_driver+0x64/0xdc
              bus_for_each_drv+0xb0/0xd8
              __device_attach+0xe4/0x140
              device_initial_probe+0x1c/0x28
              bus_probe_device+0x44/0xb0
              deferred_probe_work_func+0xb0/0xc8
              process_one_work+0x288/0x3d8
              worker_thread+0x1f0/0x260
              kthread+0xf0/0x100
              ret_from_fork+0x10/0x20
    
       -> #3 (dev_pm_qos_mtx){+.+.}-{3:3}:
              __mutex_lock+0xc8/0x388
              mutex_lock_nested+0x2c/0x38
              dev_pm_qos_remove_notifier+0x3c/0xc8
              genpd_remove_device+0x40/0x11c
              genpd_dev_pm_detach+0x88/0x130
              dev_pm_domain_detach+0x2c/0x3c
              a6xx_gmu_remove+0x44/0xdc [msm]
              a6xx_destroy+0x7c/0xa4 [msm]
              adreno_unbind+0x50/0x64 [msm]
              component_unbind+0x44/0x64
              component_unbind_all+0xb4/0xbc
              msm_drm_uninit.isra.0+0x124/0x17c [msm]
              msm_drm_bind+0x340/0x5f4 [msm]
              try_to_bring_up_aggregate_device+0x88/0x1a4
              __component_add+0xd4/0x128
              component_add+0x1c/0x28
              dp_display_probe+0x37c/0x3c0 [msm]
              platform_probe+0x70/0xc0
              really_probe+0x148/0x280
              __driver_probe_device+0xfc/0x114
              driver_probe_device+0x44/0x100
              __device_attach_driver+0x64/0xdc
              bus_for_each_drv+0xb0/0xd8
              __device_attach+0xe4/0x140
              device_initial_probe+0x1c/0x28
              bus_probe_device+0x44/0xb0
              deferred_probe_work_func+0xb0/0xc8
              process_one_work+0x288/0x3d8
              worker_thread+0x1f0/0x260
              kthread+0xf0/0x100
              ret_from_fork+0x10/0x20
    
       -> #2 (&a6xx_gpu->gmu.lock){+.+.}-{3:3}:
              __mutex_lock+0xc8/0x388
              mutex_lock_nested+0x2c/0x38
              a6xx_gpu_set_freq+0x38/0x64 [msm]
              msm_devfreq_target+0x170/0x18c [msm]
              devfreq_set_target+0x90/0x1e4
              devfreq_update_target+0xb4/0xf0
              update_devfreq+0x1c/0x28
              devfreq_monitor+0x3c/0x10c
              process_one_work+0x288/0x3d8
              worker_thread+0x1f0/0x260
              kthread+0xf0/0x100
              ret_from_fork+0x10/0x20
    
       -> #1 (&df->lock){+.+.}-{3:3}:
              __mutex_lock+0xc8/0x388
              mutex_lock_nested+0x2c/0x38
              msm_devfreq_get_dev_status+0x4c/0x104 [msm]
              devfreq_simple_ondemand_func+0x5c/0x128
              devfreq_update_target+0x68/0xf0
              update_devfreq+0x1c/0x28
              devfreq_monitor+0x3c/0x10c
              process_one_work+0x288/0x3d8
              worker_thread+0x1f0/0x260
              kthread+0xf0/0x100
              ret_from_fork+0x10/0x20
    
       -> #0 (&devfreq->lock){+.+.}-{3:3}:
              __lock_acquire+0xdf8/0x109c
              lock_acquire+0x234/0x284
              __mutex_lock+0xc8/0x388
              mutex_lock_nested+0x2c/0x38
              qos_notifier_call+0x30/0x74
              qos_min_notifier_call+0x1c/0x28
              notifier_call_chain+0xf4/0x114
              blocking_notifier_call_chain+0x4c/0x78
              pm_qos_update_target+0x184/0x190
              freq_qos_apply+0x4c/0x64
              apply_constraint+0xf8/0xfc
              __dev_pm_qos_update_request+0x138/0x164
              dev_pm_qos_update_request+0x44/0x68
              msm_devfreq_boost+0x40/0x70 [msm]
              msm_devfreq_active+0xc0/0xf0 [msm]
              msm_gpu_submit+0xc8/0x12c [msm]
              msm_job_run+0x88/0x128 [msm]
              drm_sched_main+0x240/0x324 [gpu_sched]
              kthread+0xf0/0x100
              ret_from_fork+0x10/0x20
    
       other info that might help us debug this:
       Chain exists of:
         &devfreq->lock --> dev_pm_qos_mtx --> &(c->notifiers)->rwsem
        Possible unsafe locking scenario:
              CPU0                    CPU1
              ----                    ----
         rlock(&(c->notifiers)->rwsem);
                                      lock(dev_pm_qos_mtx);
                                      lock(&(c->notifiers)->rwsem);
         lock(&devfreq->lock);
    
        *** DEADLOCK ***
       4 locks held by ring0/391:
        #0: ffffff809c811170 (&gpu->lock){+.+.}-{3:3}, at: msm_job_run+0x7c/0x128 [msm]
        #1: ffffff809c811208 (&gpu->active_lock){+.+.}-{3:3}, at: msm_gpu_submit+0xa8/0x12c [msm]
        #2: ffffffecbbb46600 (dev_pm_qos_mtx){+.+.}-{3:3}, at: dev_pm_qos_update_request+0x38/0x68
        #3: ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78
    
       stack backtrace:
       CPU: 6 PID: 391 Comm: ring0 Not tainted 6.4.3debug+ #3
       Hardware name: Google Villager (rev1+) with LTE (DT)
       Call trace:
        dump_backtrace+0xb4/0xf0
        show_stack+0x20/0x30
        dump_stack_lvl+0x60/0x84
        dump_stack+0x18/0x24
        print_circular_bug+0x1cc/0x234
        check_noncircular+0x78/0xac
        __lock_acquire+0xdf8/0x109c
        lock_acquire+0x234/0x284
        __mutex_lock+0xc8/0x388
        mutex_lock_nested+0x2c/0x38
        qos_notifier_call+0x30/0x74
        qos_min_notifier_call+0x1c/0x28
        notifier_call_chain+0xf4/0x114
        blocking_notifier_call_chain+0x4c/0x78
        pm_qos_update_target+0x184/0x190
        freq_qos_apply+0x4c/0x64
        apply_constraint+0xf8/0xfc
        __dev_pm_qos_update_request+0x138/0x164
        dev_pm_qos_update_request+0x44/0x68
        msm_devfreq_boost+0x40/0x70 [msm]
        msm_devfreq_active+0xc0/0xf0 [msm]
        msm_gpu_submit+0xc8/0x12c [msm]
        msm_job_run+0x88/0x128 [msm]
        drm_sched_main+0x240/0x324 [gpu_sched]
        kthread+0xf0/0x100
        ret_from_fork+0x10/0x20
    
    Fix this by only synchronizing access to gmu->initialized.
    
    Fixes: 4cd15a3e8b36 ("drm/msm/a6xx: Make GPU destroy a bit safer")
    Cc: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/551171/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dpu: drop the regdma configuration [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Apr 21 01:25:57 2023 +0300

    drm/msm/dpu: drop the regdma configuration
    
    [ Upstream commit 078f766e165097c03629cc1a8f7e1a7b7ec0e79b ]
    
    The regdma is currently not used by the current driver. We have no way
    to practically verify that the regdma is described correctly. Drop it
    now.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/533148/
    Link: https://lore.kernel.org/r/20230420222558.1208887-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Stable-dep-of: 42d0d253ed03 ("drm/msm/dpu: increase memtype count to 16 for sm8550")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: fix the irq index in dpu_encoder_phys_wb_wait_for_commit_done [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Aug 2 13:04:19 2023 +0300

    drm/msm/dpu: fix the irq index in dpu_encoder_phys_wb_wait_for_commit_done
    
    [ Upstream commit d93cf453f51da168f4410ba73656f1e862096973 ]
    
    Since commit 1e7ac595fa46 ("drm/msm/dpu: pass irq to
    dpu_encoder_helper_wait_for_irq()") the
    dpu_encoder_phys_wb_wait_for_commit_done expects the IRQ index rather
    than the IRQ index in phys_enc->intr table, however writeback got the
    older invocation in place. This was unnoticed for several releases, but
    now it's time to fix it.
    
    Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/550924/
    Link: https://lore.kernel.org/r/20230802100426.4184892-2-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: increase memtype count to 16 for sm8550 [+ + +]
Author: Jonathan Marek <jonathan@marek.ca>
Date:   Wed Aug 2 09:48:53 2023 -0400

    drm/msm/dpu: increase memtype count to 16 for sm8550
    
    [ Upstream commit 42d0d253ed03b961c325ff756eec0480cb4adc6b ]
    
    sm8550 has 16 vbif clients.
    
    This fixes the extra 2 clients (DMA4/DMA5) not having their memtype
    initialized. This fixes DMA4/DMA5 planes not displaying correctly.
    
    Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
    Signed-off-by: Jonathan Marek <jonathan@marek.ca>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
    Patchwork: https://patchwork.freedesktop.org/patch/550968/
    Link: https://lore.kernel.org/r/20230802134900.30435-1-jonathan@marek.ca
    [DB: fixed the Fixes tag]
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/mdp5: Don't leak some plane state [+ + +]
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 3 22:45:21 2023 +0200

    drm/msm/mdp5: Don't leak some plane state
    
    [ Upstream commit fd0ad3b2365c1c58aa5a761c18efc4817193beb6 ]
    
    Apparently no one noticed that mdp5 plane states leak like a sieve
    ever since we introduced plane_state->commit refcount a few years ago
    in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
    early by tracking commits, v3.")
    
    Fix it by using the right helpers.
    
    Fixes: 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.")
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Rob Clark <robdclark@gmail.com>
    Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Cc: linux-arm-msm@vger.kernel.org
    Cc: freedreno@lists.freedesktop.org
    Reported-and-tested-by: dorum@noisolation.com
    Cc: dorum@noisolation.com
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/551236/
    Link: https://lore.kernel.org/r/20230803204521.928582-1-daniel.vetter@ffwll.ch
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm: Update dev core dump to not print backwards [+ + +]
Author: Ryan McCann <quic_rmccann@quicinc.com>
Date:   Fri Jul 7 18:24:40 2023 -0700

    drm/msm: Update dev core dump to not print backwards
    
    [ Upstream commit 903705111d863ed8ccf73465da77d232fc422ec1 ]
    
    Device core dump add block method adds hardware blocks to dumping queue
    with stack behavior which causes the hardware blocks to be printed in
    reverse order. Change the addition to dumping queue data structure
    from "list_add" to "list_add_tail" for FIFO queue behavior.
    
    Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Ryan McCann <quic_rmccann@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/546200/
    Link: https://lore.kernel.org/r/20230622-devcoredump_patch-v5-1-67e8b66c4723@quicinc.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panel: simple: Add missing connector type and pixel format for AUO T215HVN01 [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Sun Jul 9 15:49:14 2023 +0200

    drm/panel: simple: Add missing connector type and pixel format for AUO T215HVN01
    
    [ Upstream commit 7a675a8fa598edb29a664a91adb80f0340649f6f ]
    
    The connector type and pixel format are missing for this panel,
    add them to prevent various drivers from failing to determine
    either of those parameters.
    
    Fixes: 7ee933a1d5c4 ("drm/panel: simple: Add support for AUO T215HVN01")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230709134914.449328-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon: Use RMW accessors for changing LNKCTL [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 15:04:58 2023 +0300

    drm/radeon: Use RMW accessors for changing LNKCTL
    
    [ Upstream commit 7189576e8a829130192b33c5b64e8a475369c776 ]
    
    Don't assume that only the driver would be accessing LNKCTL. ASPM policy
    changes can trigger write to LNKCTL outside of driver's control.  And in
    the case of upstream bridge, the driver does not even own the device it's
    changing the registers for.
    
    Use RMW capability accessors which do proper locking to avoid losing
    concurrent updates to the register value.
    
    Suggested-by: Lukas Wunner <lukas@wunner.de>
    Fixes: 8a7cd27679d0 ("drm/radeon/cik: add support for pcie gen1/2/3 switching")
    Fixes: b9d305dfb66c ("drm/radeon: implement pcie gen2/3 support for SI")
    Link: https://lore.kernel.org/r/20230717120503.15276-7-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/repaper: Reduce temporary buffer size in repaper_fb_dirty() [+ + +]
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Thu Mar 17 09:18:30 2022 +0100

    drm/repaper: Reduce temporary buffer size in repaper_fb_dirty()
    
    [ Upstream commit fedf429e071f6dbbe7a69dfc342492e037692018 ]
    
    As the temporary buffer is no longer used to store 8-bit grayscale data,
    its size can be reduced to the size needed to store the monochrome
    bitmap data.
    
    Fixes: 24c6bedefbe71de9 ("drm/repaper: Use format helper for xrgb8888 to monochrome conversion")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-6-geert@linux-m68k.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/tegra: dpaux: Fix incorrect return value of platform_get_irq [+ + +]
Author: Yangtao Li <frank.li@vivo.com>
Date:   Mon Jul 10 11:23:49 2023 +0800

    drm/tegra: dpaux: Fix incorrect return value of platform_get_irq
    
    [ Upstream commit 2a1ca44b654346cadfc538c4fb32eecd8daf3140 ]
    
    When platform_get_irq fails, we should return dpaux->irq
    instead of -ENXIO.
    
    Fixes: 6b6b604215c6 ("drm/tegra: Add eDP support")
    Signed-off-by: Yangtao Li <frank.li@vivo.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230710032355.72914-13-frank.li@vivo.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: adv7511: Fix low refresh rate register for ADV7533/5 [+ + +]
Author: Bogdan Togorean <bogdan.togorean@analog.com>
Date:   Wed Jul 19 09:01:43 2023 +0300

    drm: adv7511: Fix low refresh rate register for ADV7533/5
    
    [ Upstream commit d281eeaa4de2636ff0c8e6ae387bb07b50e5fcbb ]
    
    For ADV7533 and ADV7535 low refresh rate is selected using
    bits [3:2] of 0x4a main register.
    So depending on ADV model write 0xfb or 0x4a register.
    
    Fixes: 2437e7cd88e8 ("drm/bridge: adv7533: Initial support for ADV7533")
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Signed-off-by: Bogdan Togorean <bogdan.togorean@analog.com>
    Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
    Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230719060143.63649-1-alex@shruggie.ro
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI controller [+ + +]
Author: Ondrej Jirman <megi@xff.cz>
Date:   Sun Jun 18 00:48:25 2023 +0200

    drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI controller
    
    [ Upstream commit 05aa61334592adb230749ff465b103ee10e63936 ]
    
    Before this patch, booting to Linux VT and doing a simple:
    
      echo 2 > /sys/class/graphics/fb0/blank
      echo 0 > /sys/class/graphics/fb0/blank
    
    would result in failures to re-enable the panel. Mode set callback is
    called only once during boot in this scenario, while calls to
    enable/disable callbacks are balanced afterwards. The driver doesn't
    work unless userspace calls modeset before enabling the CRTC/connector.
    
    This patch moves enabling of the DSI host from mode_set into pre_enable
    callback, and removes some old hacks where this bridge driver is
    directly calling into other bridge driver's callbacks.
    
    pre_enable_prev_first flag is set on the panel's bridge so that panel
    drivers will get their prepare function called between DSI host's
    pre_enable and enable callbacks, so that they get a chance to
    perform panel setup while DSI host is already enabled in command
    mode. Otherwise panel's prepare would be called before DSI host
    is enabled, and any DSI communication used in prepare callback
    would fail.
    
    With all these changes, the enable/disable sequence is now well
    balanced, and host's and panel's callbacks are called in proper order
    documented in the drm_panel API documentation without needing the old
    hacks. (Mainly that panel->prepare is called when DSI host is ready to
    allow the panel driver to send DSI commands and vice versa during
    disable.)
    
    Tested on Pinephone Pro. Trace of the callbacks follows.
    
    Before:
    
    [    1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
    [    1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare
    [    1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable
    [    1.475593] panel-himax-hx8394 ff960000.dsi.0: enable
    
    echo 2 > /sys/class/graphics/fb0/blank
    
    [   13.722799] panel-himax-hx8394 ff960000.dsi.0: disable
    [   13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
    [   13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare
    
    echo 0 > /sys/class/graphics/fb0/blank
    
    [   17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare
    [   17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable
    [   17.923540] panel-himax-hx8394 ff960000.dsi.0: enable
    [   17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
    [   17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
    [   17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110
    
    echo 2 > /sys/class/graphics/fb0/blank
    
    [  431.148583] panel-himax-hx8394 ff960000.dsi.0: disable
    [  431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
    [  431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110
    [  431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
    [  431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare
    [  431.169357] pclk_mipi_dsi0 already disabled
    
    echo 0 > /sys/class/graphics/fb0/blank
    
    [  432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare
    [  432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable
    [  432.981568] panel-himax-hx8394 ff960000.dsi.0: enable
    [  433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
    [  433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
    [  433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110
    
    -----------------------------------------------------------------------
    
    After:
    
    [    1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
    [    1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
    [    1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare
    [    1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable
    [    1.468421] panel-himax-hx8394 ff960000.dsi.0: enable
    
    echo 2 > /sys/class/graphics/fb0/blank
    
    [   16.210357] panel-himax-hx8394 ff960000.dsi.0: disable
    [   16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
    [   16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare
    
    echo 0 > /sys/class/graphics/fb0/blank
    
    [   19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
    [   19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare
    [   19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable
    [   19.382158] panel-himax-hx8394 ff960000.dsi.0: enable
    
           (But depends on functionality intorduced in Linux 6.3, so this patch will
            not build on older kernels when applied to older stable branches.)
    
    Fixes: 46fc51546d44 ("drm/bridge/synopsys: Add MIPI DSI host controller bridge")
    Signed-off-by: Ondrej Jirman <megi@xff.cz>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230617224915.1923630-1-megi@xff.cz
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: xlnx: zynqmp_dpsub: Add missing check for dma_set_mask [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Wed Jun 7 10:05:29 2023 +0800

    drm: xlnx: zynqmp_dpsub: Add missing check for dma_set_mask
    
    [ Upstream commit 1832fba7f9780aff67c96ad30f397c2d76141833 ]
    
    Add check for dma_set_mask() and return the error if it fails.
    
    Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: clock: qcom,gcc-sc8280xp: Add missing GDSCs [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jun 26 19:48:07 2023 +0200

    dt-bindings: clock: qcom,gcc-sc8280xp: Add missing GDSCs
    
    [ Upstream commit 9eba4db02a88e7a810aabd70f7a6960f184f391f ]
    
    There are 10 more GDSCs that we've not been caring about, and by extension
    (and perhaps even more importantly), not putting to sleep. Add them.
    
    Fixes: a66a82f2a55e ("dt-bindings: clock: Add Qualcomm SC8280XP GCC bindings")
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20230620-topic-sc8280_gccgdsc-v2-2-562c1428c10d@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: clock: Update GCC clocks for QDU1000 and QRU1000 SoCs [+ + +]
Author: Imran Shaik <quic_imrashai@quicinc.com>
Date:   Thu Aug 3 16:27:34 2023 +0530

    dt-bindings: clock: Update GCC clocks for QDU1000 and QRU1000 SoCs
    
    [ Upstream commit df873243b2398a082d34a006bebe0e0ed7538f5c ]
    
    Add support for GCC_GPLL1_OUT_EVEN and GCC_DDRSS_ECPRI_GSI_CLK clock
    bindings for QDU1000 and QRU1000 SoCs. While at it, update the
    maintainers list.
    
    Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20230803105741.2292309-2-quic_imrashai@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 06d71fa10f2e ("clk: qcom: gcc-qdu1000: Register gcc_gpll1_out_even clock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: extcon: maxim,max77843: restrict connector properties [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Jul 20 10:01:40 2023 +0200

    dt-bindings: extcon: maxim,max77843: restrict connector properties
    
    [ Upstream commit fb2c3f72e819254d8c76de95917e5f9ff232586c ]
    
    Do not allow any other properties in connector child, except what
    usb-connector.yaml evaluates.
    
    Fixes: 9729cad0278b ("dt-bindings: extcon: maxim,max77843: Add MAX77843 bindings")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/i10nm: Skip the absent memory controllers [+ + +]
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date:   Mon Jul 10 09:32:32 2023 +0800

    EDAC/i10nm: Skip the absent memory controllers
    
    [ Upstream commit c545f5e412250555bd4e717d062b117f20bab418 ]
    
    Some Sapphire Rapids workstations' absent memory controllers
    still appear as PCIe devices that fool the i10nm_edac driver
    and result in "shift exponent -66 is negative" call traces
    from skx_get_dimm_info().
    
    Skip the absent memory controllers to avoid the call traces.
    
    Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Closes: https://lore.kernel.org/linux-edac/CAAd53p41Ku1m1rapeqb1xtD+kKuk+BaUW=dumuoF0ZO3GhFjFA@mail.gmail.com/T/#m5de16dce60a8c836ec235868c7c16e3fefad0cc2
    Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reported-by: Koba Ko <koba.ko@canonical.com>
    Closes: https://lore.kernel.org/linux-edac/SA1PR11MB71305B71CCCC3D9305835202892AA@SA1PR11MB7130.namprd11.prod.outlook.com/T/#t
    Tested-by: Koba Ko <koba.ko@canonical.com>
    Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors")
    Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20230710013232.59712-1-qiuxu.zhuo@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/igen6: Fix the issue of no error events [+ + +]
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date:   Tue Jul 25 16:04:27 2023 +0800

    EDAC/igen6: Fix the issue of no error events
    
    [ Upstream commit ce53ad81ed36c24aff075f94474adecfabfcf239 ]
    
    Current igen6_edac checks for pending errors before the registration
    of the error handler. However, there is a possibility that the error
    occurs during the registration process, leading to unhandled pending
    errors and no future error events. This issue can be reproduced by
    repeatedly injecting errors during the loading of the igen6_edac.
    
    Fix this issue by moving the pending error handler after the registration
    of the error handler, ensuring that no pending errors are left unhandled.
    
    Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC")
    Reported-by: Ee Wey Lim <ee.wey.lim@intel.com>
    Tested-by: Ee Wey Lim <ee.wey.lim@intel.com>
    Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20230725080427.23883-1-qiuxu.zhuo@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ethernet: atheros: fix return value check in atl1c_tso_csum() [+ + +]
Author: Yuanjun Gong <ruc_gongyuanjun@163.com>
Date:   Thu Jul 20 22:42:08 2023 +0800

    ethernet: atheros: fix return value check in atl1c_tso_csum()
    
    [ Upstream commit 8d01da0a1db237c44c92859ce3612df7af8d3a53 ]
    
    in atl1c_tso_csum, it should check the return value of pskb_trim(),
    and return an error code if an unexpected value is returned
    by pskb_trim().
    
    Signed-off-by: Yuanjun Gong <ruc_gongyuanjun@163.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eventfd: prevent underflow for eventfd semaphores [+ + +]
Author: Wen Yang <wenyang.linux@foxmail.com>
Date:   Sun Jul 9 14:54:51 2023 +0800

    eventfd: prevent underflow for eventfd semaphores
    
    [ Upstream commit 758b492047816a3158d027e9fca660bc5bcf20bf ]
    
    For eventfd with flag EFD_SEMAPHORE, when its ctx->count is 0, calling
    eventfd_ctx_do_read will cause ctx->count to overflow to ULLONG_MAX.
    
    An underflow can happen with EFD_SEMAPHORE eventfds in at least the
    following three subsystems:
    
    (1) virt/kvm/eventfd.c
    (2) drivers/vfio/virqfd.c
    (3) drivers/virt/acrn/irqfd.c
    
    where (2) and (3) are just modeled after (1). An eventfd must be
    specified for use with the KVM_IRQFD ioctl(). This can also be an
    EFD_SEMAPHORE eventfd. When the eventfd count is zero or has been
    decremented to zero an underflow can be triggered when the irqfd is shut
    down by raising the KVM_IRQFD_FLAG_DEASSIGN flag in the KVM_IRQFD
    ioctl():
    
            // ctx->count == 0
            kvm_vm_ioctl()
            -> kvm_irqfd()
               -> kvm_irqfd_deassign()
                  -> irqfd_deactivate()
                     -> irqfd_shutdown()
                        -> eventfd_ctx_remove_wait_queue(&cnt)
                           -> eventfd_ctx_do_read(&cnt)
    
    Userspace polling on the eventfd wouldn't notice the underflow because 1
    is always returned as the value from eventfd_read() while ctx->count
    would've underflowed. It's not a huge deal because this should only be
    happening when the irqfd is shutdown but we should still fix it and
    avoid the spurious wakeup.
    
    Fixes: cb289d6244a3 ("eventfd - allow atomic read and waitqueue remove")
    Signed-off-by: Wen Yang <wenyang.linux@foxmail.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Dylan Yudaken <dylany@fb.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: linux-fsdevel@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Message-Id: <tencent_7588DFD1F365950A757310D764517A14B306@qq.com>
    [brauner: rewrite commit message and add explanation how this underflow can happen]
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: avoid potential data overflow in next_linear_group [+ + +]
Author: Kemeng Shi <shikemeng@huaweicloud.com>
Date:   Tue Aug 1 22:31:56 2023 +0800

    ext4: avoid potential data overflow in next_linear_group
    
    [ Upstream commit 60c672b7f2d1e5dd1774f2399b355c9314e709f8 ]
    
    ngroups is ext4_group_t (unsigned int) while next_linear_group treat it
    in int. If ngroups is bigger than max number described by int, it will
    be treat as a negative number. Then "return group + 1 >= ngroups ? 0 :
    group + 1;" may keep returning 0.
    Switch int to ext4_group_t in next_linear_group to fix the overflow.
    
    Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning")
    Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20230801143204.2284343-3-shikemeng@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: correct grp validation in ext4_mb_good_group [+ + +]
Author: Kemeng Shi <shikemeng@huaweicloud.com>
Date:   Tue Aug 1 22:31:55 2023 +0800

    ext4: correct grp validation in ext4_mb_good_group
    
    [ Upstream commit a9ce5993a0f5c0887c8a1b4ffa3b8046fbcfdc93 ]
    
    Group corruption check will access memory of grp and will trigger kernel
    crash if grp is NULL. So do NULL check before corruption check.
    
    Fixes: 5354b2af3406 ("ext4: allow ext4_get_group_info() to fail")
    Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20230801143204.2284343-2-shikemeng@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix unttached inode after power cut with orphan file feature enabled [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Wed Jun 28 21:20:11 2023 +0800

    ext4: fix unttached inode after power cut with orphan file feature enabled
    
    [ Upstream commit 1524773425ae8113b0b782886366e68656b34e53 ]
    
    Running generic/475(filesystem consistent tests after power cut) could
    easily trigger unattached inode error while doing fsck:
      Unattached zero-length inode 39405.  Clear? no
    
      Unattached inode 39405
      Connect to /lost+found? no
    
    Above inconsistence is caused by following process:
           P1                       P2
    ext4_create
     inode = ext4_new_inode_start_handle  // itable records nlink=1
     ext4_add_nondir
       err = ext4_add_entry  // ENOSPC
        ext4_append
         ext4_bread
          ext4_getblk
           ext4_map_blocks // returns ENOSPC
       drop_nlink(inode) // won't be updated into disk inode
       ext4_orphan_add(handle, inode)
        ext4_orphan_file_add
     ext4_journal_stop(handle)
                          jbd2_journal_commit_transaction // commit success
                  >> power cut <<
    ext4_fill_super
     ext4_load_and_init_journal   // itable records nlink=1
     ext4_orphan_cleanup
      ext4_process_orphan
       if (inode->i_nlink)        // true, inode won't be deleted
    
    Then, allocated inode will be reserved on disk and corresponds to no
    dentries, so e2fsck reports 'unattached inode' problem.
    
    The problem won't happen if orphan file feature is disabled, because
    ext4_orphan_add() will update disk inode in orphan list mode. There
    are several places not updating disk inode while putting inode into
    orphan area, such as ext4_add_nondir(), ext4_symlink() and whiteout
    in ext4_rename(). Fix it by updating inode into disk in all error
    branches of these places.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217605
    Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230628132011.650383-1-chengzhihao1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
extcon: cht_wc: add POWER_SUPPLY dependency [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Aug 4 15:28:49 2023 +0200

    extcon: cht_wc: add POWER_SUPPLY dependency
    
    [ Upstream commit d20a3a8a32e3fa564ff25da860c5fc1a97642dfe ]
    
    The driver fails to link when CONFIG_POWER_SUPPLY is disabled:
    
    x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_psy_get_prop':
    extcon-intel-cht-wc.c:(.text+0x15ccda7): undefined reference to `power_supply_get_drvdata'
    x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_pwrsrc_event':
    extcon-intel-cht-wc.c:(.text+0x15cd3e9): undefined reference to `power_supply_changed'
    x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_probe':
    extcon-intel-cht-wc.c:(.text+0x15cd596): undefined reference to `devm_power_supply_register'
    
    It should be possible to change the driver to not require this at
    compile time and still provide other functions, but adding a hard
    Kconfig dependency does not seem to have any practical downsides
    and is simpler since the option is normally enabled anyway.
    
    Fixes: 66e31186cd2aa ("extcon: intel-cht-wc: Add support for registering a power_supply class-device")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: fix spelling in ABI documentation [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jul 9 22:23:24 2023 -0700

    f2fs: fix spelling in ABI documentation
    
    [ Upstream commit c709d099a0d2befa2b16c249ef8df722b43e6c28 ]
    
    Correct spelling problems as identified by codespell.
    
    Fixes: 9e615dbba41e ("f2fs: add missing description for ipu_policy node")
    Fixes: b2e4a2b300e5 ("f2fs: expose discard related parameters in sysfs")
    Fixes: 846ae671ad36 ("f2fs: expose extension_list sysfs entry")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Jaegeuk Kim <jaegeuk@kernel.org>
    Cc: Chao Yu <chao@kernel.org>
    Cc: linux-f2fs-devel@lists.sourceforge.net
    Cc: Yangtao Li <frank.li@vivo.com>
    Cc: Konstantin Vyshetsky <vkon@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to account cp stats correctly [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue Aug 8 08:59:49 2023 +0800

    f2fs: fix to account cp stats correctly
    
    [ Upstream commit eb61c2cca2eb2110cc7b61a7bc15b3850977a778 ]
    
    cp_foreground_calls sysfs entry shows total CP call count rather than
    foreground CP call count, fix it.
    
    Fixes: fc7100ea2a52 ("f2fs: Add f2fs stats to sysfs")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to account gc stats correctly [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue Aug 8 08:59:48 2023 +0800

    f2fs: fix to account gc stats correctly
    
    [ Upstream commit 9bf1dcbdfdc8892d9cfeaeab02519c0ecf17fe51 ]
    
    As reported, status debugfs entry shows inconsistent GC stats as below:
    
    GC calls: 6008 (BG: 6161)
      - data segments : 3053 (BG: 3053)
      - node segments : 2955 (BG: 2955)
    
    Total GC calls is larger than BGGC calls, the reason is:
    - f2fs_stat_info.call_count accounts total migrated section count
    by f2fs_gc()
    - f2fs_stat_info.bg_gc accounts total call times of f2fs_gc() from
    background gc_thread
    
    Another issue is gc_foreground_calls sysfs entry shows total GC call
    count rather than FGGC call count.
    
    This patch changes as below for fix:
    - account GC calls and migrated segment count separately
    - support to account migrated section count if it enables large section
    mode
    - fix to show correct value in gc_foreground_calls sysfs entry
    
    Fixes: fc7100ea2a52 ("f2fs: Add f2fs stats to sysfs")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to avoid mmap vs set_compress_option case [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Thu Jul 6 10:06:14 2023 +0800

    f2fs: fix to avoid mmap vs set_compress_option case
    
    [ Upstream commit b5ab3276eb69cacf44ecfb11b2bfab73096ff4e4 ]
    
    Compression option in inode should not be changed after they have
    been used, however, it may happen in below race case:
    
    Thread A                                Thread B
    - f2fs_ioc_set_compress_option
     - check f2fs_is_mmap_file()
     - check get_dirty_pages()
     - check F2FS_HAS_BLOCKS()
                                            - f2fs_file_mmap
                                             - set_inode_flag(FI_MMAP_FILE)
                                            - fault
                                             - do_page_mkwrite
                                              - f2fs_vm_page_mkwrite
                                              - f2fs_get_block_locked
                                             - fault_dirty_shared_page
                                              - set_page_dirty
     - update i_compress_algorithm
     - update i_log_cluster_size
     - update i_cluster_size
    
    Avoid such race condition by covering f2fs_file_mmap() w/ i_sem lock,
    meanwhile add mmap file check condition in f2fs_may_compress() as well.
    
    Fixes: e1e8debec656 ("f2fs: add F2FS_IOC_SET_COMPRESS_OPTION ioctl")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to drop all dirty meta/node pages during umount() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sun May 28 15:47:12 2023 +0800

    f2fs: fix to drop all dirty meta/node pages during umount()
    
    [ Upstream commit 20872584b8c0b006c007da9588a272c9e28d2e18 ]
    
    For cp error case, there will be dirty meta/node pages remained after
    f2fs_write_checkpoint() in f2fs_put_super(), drop them explicitly, and
    do sanity check on reference count of dirty pages and inflight IOs.
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: eb61c2cca2eb ("f2fs: fix to account cp stats correctly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: Only lfs mode is allowed with zoned block device feature [+ + +]
Author: Chunhai Guo <guochunhai@vivo.com>
Date:   Thu Aug 3 22:28:42 2023 +0800

    f2fs: Only lfs mode is allowed with zoned block device feature
    
    [ Upstream commit 2bd4df8fcbc72f58ce3c62ed021ab291ca42de0b ]
    
    Now f2fs support four block allocation modes: lfs, adaptive,
    fragment:segment, fragment:block. Only lfs mode is allowed with zoned block
    device feature.
    
    Fixes: 6691d940b0e0 ("f2fs: introduce fragment allocation mode mount option")
    Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: refactor struct f2fs_attr macro [+ + +]
Author: Yangtao Li <frank.li@vivo.com>
Date:   Sat May 6 23:16:03 2023 +0800

    f2fs: refactor struct f2fs_attr macro
    
    [ Upstream commit 6201c478dedcf7c50361b23b5c4d4f41a68921ac ]
    
    This patch provides a large number of variants of F2FS_RW_ATTR
    and F2FS_RO_ATTR macros, reducing the number of parameters required
    to initialize the f2fs_attr structure.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/oe-kbuild-all/202304152234.wjaY3IYm-lkp@intel.com/
    Signed-off-by: Yangtao Li <frank.li@vivo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: 9bf1dcbdfdc8 ("f2fs: fix to account gc stats correctly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: goldfishfb: Do not check 0 for platform_get_irq() [+ + +]
Author: Zhu Wang <wangzhu9@huawei.com>
Date:   Thu Aug 3 15:10:06 2023 +0800

    fbdev: goldfishfb: Do not check 0 for platform_get_irq()
    
    [ Upstream commit 0650d5098f8b6b232cd5ea0e15437fc38f7d63ba ]
    
    Since platform_get_irq() never returned zero, so it need not to check
    whether it returned zero, and we use the return error code of
    platform_get_irq() to replace the current return error code.
    
    Please refer to the commit a85a6c86c25b ("driver core: platform: Clarify
    that IRQ 0 is invalid") to get that platform_get_irq() never returned
    zero.
    
    Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: cs_dsp: Fix new control name check [+ + +]
Author: Vlad Karpovich <vkarpovi@opensource.cirrus.com>
Date:   Tue Aug 15 12:29:08 2023 -0500

    firmware: cs_dsp: Fix new control name check
    
    [ Upstream commit 7ac1102b227b36550452b663fd39ab1c09378a95 ]
    
    Before adding a new FW control, its name is checked against
    existing controls list. But the string length in strncmp used
    to compare controls names is taken from the list, so if beginnings
    of the controls are matching,  then the new control is not created.
    For example, if CAL_R control already exists, CAL_R_SELECTED
    is not created.
    The fix is to compare string lengths as well.
    
    Fixes: 6477960755fb ("ASoC: wm_adsp: Move check for control existence")
    Signed-off-by: Vlad Karpovich <vkarpovi@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20230815172908.3454056-1-vkarpovi@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: meson_sm: fix to avoid potential NULL pointer dereference [+ + +]
Author: Zhang Shurong <zhang_shurong@foxmail.com>
Date:   Sat Jul 15 22:13:38 2023 +0800

    firmware: meson_sm: fix to avoid potential NULL pointer dereference
    
    [ Upstream commit f2ed165619c16577c02b703a114a1f6b52026df4 ]
    
    of_match_device() may fail and returns a NULL pointer.
    
    Fix this by checking the return value of of_match_device.
    
    Fixes: 8cde3c2153e8 ("firmware: meson_sm: Rework driver as a proper platform driver")
    Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/tencent_AA08AAA6C4F34D53ADCE962E188A879B8206@qq.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: ti_sci: Use system_state to determine polling [+ + +]
Author: Nishanth Menon <nm@ti.com>
Date:   Tue Jun 20 08:03:29 2023 -0500

    firmware: ti_sci: Use system_state to determine polling
    
    [ Upstream commit 9225bcdedf16297a346082e7d23b0e8434aa98ed ]
    
    Commit b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled
    mode during system suspend") aims to resolve issues with tisci
    operations during system suspend operation. However, the system may
    enter a no_irq stage in various other usage modes, including power-off
    and restart. To determine if polling mode is appropriate, use the
    system_state instead.
    
    While at this, drop the unused is_suspending state variable and
    related helpers.
    
    Fixes: b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled mode during system suspend")
    Reported-by: Francesco Dolcini <francesco@dolcini.it>
    Reported-by: Wadim Egorov <w.egorov@phytec.de>
    Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com> # Toradex Verdin AM62
    Link: https://lore.kernel.org/r/20230620130329.4120443-1-nm@ti.com
    Closes: https://lore.kernel.org/all/ZGeHMjlnob2GFyHF@francesco-nb.int.toradex.com/
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/nls: make load_nls() take a const parameter [+ + +]
Author: Winston Wen <wentao@uniontech.com>
Date:   Mon Jul 24 10:10:56 2023 +0800

    fs/nls: make load_nls() take a const parameter
    
    [ Upstream commit c1ed39ec116272935528ca9b348b8ee79b0791da ]
    
    load_nls() take a char * parameter, use it to find nls module in list or
    construct the module name to load it.
    
    This change make load_nls() take a const parameter, so we don't need do
    some cast like this:
    
            ses->local_nls = load_nls((char *)ctx->local_nls->charset);
    
    Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Winston Wen <wentao@uniontech.com>
    Reviewed-by: Paulo Alcantara <pc@manguebit.com>
    Reviewed-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: Fix error checking for d_hash_and_lookup() [+ + +]
Author: Wang Ming <machel@vivo.com>
Date:   Thu Jul 13 20:05:42 2023 +0800

    fs: Fix error checking for d_hash_and_lookup()
    
    [ Upstream commit 0d5a4f8f775ff990142cdc810a84eae078589d27 ]
    
    The d_hash_and_lookup() function returns error pointers or NULL.
    Most incorrect error checks were fixed, but the one in int path_pts()
    was forgotten.
    
    Fixes: eedf265aa003 ("devpts: Make each mount of devpts an independent filesystem.")
    Signed-off-by: Wang Ming <machel@vivo.com>
    Message-Id: <20230713120555.7025-1-machel@vivo.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: lockd: avoid possible wrong NULL parameter [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Fri Aug 4 09:26:57 2023 +0800

    fs: lockd: avoid possible wrong NULL parameter
    
    [ Upstream commit de8d38cf44bac43e83bad28357ba84784c412752 ]
    
    clang's static analysis warning: fs/lockd/mon.c: line 293, column 2:
    Null pointer passed as 2nd argument to memory copy function.
    
    Assuming 'hostname' is NULL and calling 'nsm_create_handle()', this will
    pass NULL as 2nd argument to memory copy function 'memcpy()'. So return
    NULL if 'hostname' is invalid.
    
    Fixes: 77a3ef33e2de ("NSM: More clean up of nsm_get_handle()")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: ocfs2: namei: check return value of ocfs2_add_entry() [+ + +]
Author: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Date:   Thu Aug 3 17:54:17 2023 +0300

    fs: ocfs2: namei: check return value of ocfs2_add_entry()
    
    [ Upstream commit 6b72e5f9e79360fce4f2be7fe81159fbdf4256a5 ]
    
    Process result of ocfs2_add_entry() in case we have an error
    value.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://lkml.kernel.org/r/20230803145417.177649-1-artem.chernyshev@red-soft.ru
    Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
    Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Artem Chernyshev <artem.chernyshev@red-soft.ru>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Kurt Hackel <kurt.hackel@oracle.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fsi: aspeed: Reset master errors after CFAM reset [+ + +]
Author: Eddie James <eajames@linux.ibm.com>
Date:   Mon Jun 12 14:56:50 2023 -0500

    fsi: aspeed: Reset master errors after CFAM reset
    
    [ Upstream commit 52300909f4670ac552bfeb33c1355b896eac8c06 ]
    
    It has been observed that sometimes the FSI master will return all 0xffs
    after a CFAM has been taken out of reset, without presenting any error.
    Resetting the FSI master errors resolves the issue.
    
    Fixes: 4a851d714ead ("fsi: aspeed: Support CFAM reset GPIO")
    Signed-off-by: Eddie James <eajames@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230612195657.245125-8-eajames@linux.ibm.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fsverity: skip PKCS#7 parser when keyring is empty [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Aug 1 21:03:53 2023 -0700

    fsverity: skip PKCS#7 parser when keyring is empty
    
    commit 919dc320956ea353a7fb2d84265195ad5ef525ac upstream.
    
    If an fsverity builtin signature is given for a file but the
    ".fs-verity" keyring is empty, there's no real reason to run the PKCS#7
    parser.  Skip this to avoid the PKCS#7 attack surface when builtin
    signature support is configured into the kernel but is not being used.
    
    This is a hardening improvement, not a fix per se, but I've added
    Fixes and Cc stable to get it out to more users.
    
    Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures")
    Cc: stable@vger.kernel.org
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Link: https://lore.kernel.org/r/20230820173237.2579-1-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpiolib: fix reference leaks when removing GPIO chips still in use [+ + +]
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Fri Aug 11 21:30:34 2023 +0200

    gpiolib: fix reference leaks when removing GPIO chips still in use
    
    [ Upstream commit 3386fb86ecdef0d39ee3306aea8ec290e61b934f ]
    
    After we remove a GPIO chip that still has some requested descriptors,
    gpiod_free_commit() will fail and we will never put the references to the
    GPIO device and the owning module in gpiod_free().
    
    Rework this function to:
    - not warn on desc == NULL as this is a use-case on which most free
      functions silently return
    - put the references to desc->gdev and desc->gdev->owner unconditionally
      so that the release callback actually gets called when the remaining
      references are dropped by external GPIO users
    
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: input: Support devices sending Eraser without Invert [+ + +]
Author: Illia Ostapyshyn <ostapyshyn@sra.uni-hannover.de>
Date:   Tue Jun 13 17:26:00 2023 +0200

    HID: input: Support devices sending Eraser without Invert
    
    [ Upstream commit 276e14e6c3993317257e1787e93b7166fbc30905 ]
    
    Some digitizers (notably XP-Pen Artist 24) do not report the Invert
    usage when erasing.  This causes the device to be permanently stuck with
    the BTN_TOOL_RUBBER tool after sending Eraser, as Invert is the only
    usage that can release the tool.  In this state, Touch and Inrange are
    no longer reported to userspace, rendering the pen unusable.
    
    Prior to commit 87562fcd1342 ("HID: input: remove the need for
    HID_QUIRK_INVERT"), BTN_TOOL_RUBBER was never set and Eraser events were
    simply translated into BTN_TOUCH without causing an inconsistent state.
    
    Introduce HID_QUIRK_NOINVERT for such digitizers and detect them during
    hidinput_configure_usage().  This quirk causes the tool to be released
    as soon as Eraser is reported as not set.  Set BTN_TOOL_RUBBER in
    input->keybit when mapping Eraser.
    
    Fixes: 87562fcd1342 ("HID: input: remove the need for HID_QUIRK_INVERT")
    Co-developed-by: Nils Fuhler <nils@nilsfuhler.de>
    Signed-off-by: Nils Fuhler <nils@nilsfuhler.de>
    Signed-off-by: Illia Ostapyshyn <ostapyshyn@sra.uni-hannover.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Tue Jun 13 03:16:35 2023 -0700

    HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode()
    
    [ Upstream commit 6f20d3261265885f6a6be4cda49d7019728760e0 ]
    
    Presently, if a call to logi_dj_recv_send_report() fails, we do
    not learn about the error until after sending short
    HID_OUTPUT_REPORT with hid_hw_raw_request().
    To handle this somewhat unlikely issue, return on error in
    logi_dj_recv_send_report() (minding ugly sleep workaround) and
    take into account the result of hid_hw_raw_request().
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 6a9ddc897883 ("HID: logitech-dj: enable notifications on connect/disconnect")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Link: https://lore.kernel.org/r/20230613101635.77820-1-n.zhandarovich@fintech.ru
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: logitech-hidpp: rework one more time the retries attempts [+ + +]
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Wed Jul 12 17:02:34 2023 +0200

    HID: logitech-hidpp: rework one more time the retries attempts
    
    commit 60165ab774cb0c509680a73cf826d0e158454653 upstream.
    
    Extract the internal code inside a helper function, fix the
    initialization of the parameters used in the helper function
    (`hidpp->answer_available` was not reset and `*response` wasn't either),
    and use a `do {...} while();` loop.
    
    Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy")
    Cc: stable@vger.kernel.org
    Reviewed-by: Bastien Nocera <hadess@hadess.net>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Link: https://lore.kernel.org/r/20230621-logitech-fixes-v2-1-3635f7f9c8af@kernel.org
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: multitouch: Correct devm device reference for hidinput input_dev name [+ + +]
Author: Rahul Rameshbabu <sergeantsagara@protonmail.com>
Date:   Thu Aug 24 06:14:33 2023 +0000

    HID: multitouch: Correct devm device reference for hidinput input_dev name
    
    [ Upstream commit 4794394635293a3e74591351fff469cea7ad15a2 ]
    
    Reference the HID device rather than the input device for the devm
    allocation of the input_dev name. Referencing the input_dev would lead to a
    use-after-free when the input_dev was unregistered and subsequently fires a
    uevent that depends on the name. At the point of firing the uevent, the
    name would be freed by devres management.
    
    Use devm_kasprintf to simplify the logic for allocating memory and
    formatting the input_dev name string.
    
    Reported-by: Maxime Ripard <mripard@kernel.org>
    Closes: https://lore.kernel.org/linux-input/ZOZIZCND+L0P1wJc@penguin/T/#m443f3dce92520f74b6cf6ffa8653f9c92643d4ae
    Fixes: c08d46aa805b ("HID: multitouch: devm conversion")
    Suggested-by: Maxime Ripard <mripard@kernel.org>
    Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://lore.kernel.org/r/20230824061308.222021-3-sergeantsagara@protonmail.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: uclogic: Correct devm device reference for hidinput input_dev name [+ + +]
Author: Rahul Rameshbabu <sergeantsagara@protonmail.com>
Date:   Thu Aug 24 06:14:17 2023 +0000

    HID: uclogic: Correct devm device reference for hidinput input_dev name
    
    [ Upstream commit dd613a4e45f8d35f49a63a2064e5308fa5619e29 ]
    
    Reference the HID device rather than the input device for the devm
    allocation of the input_dev name. Referencing the input_dev would lead to a
    use-after-free when the input_dev was unregistered and subsequently fires a
    uevent that depends on the name. At the point of firing the uevent, the
    name would be freed by devres management.
    
    Use devm_kasprintf to simplify the logic for allocating memory and
    formatting the input_dev name string.
    
    Reported-by: syzbot+3a0ebe8a52b89c63739d@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-input/ZOZIZCND+L0P1wJc@penguin/T/
    Reported-by: Maxime Ripard <mripard@kernel.org>
    Closes: https://lore.kernel.org/linux-input/ZOZIZCND+L0P1wJc@penguin/T/#m443f3dce92520f74b6cf6ffa8653f9c92643d4ae
    Fixes: cce2dbdf258e ("HID: uclogic: name the input nodes based on their tool")
    Suggested-by: Maxime Ripard <mripard@kernel.org>
    Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://lore.kernel.org/r/20230824061308.222021-2-sergeantsagara@protonmail.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (tmp513) Fix the channel number in tmp51x_is_visible() [+ + +]
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Thu Aug 24 21:44:54 2023 +0100

    hwmon: (tmp513) Fix the channel number in tmp51x_is_visible()
    
    [ Upstream commit d103337e38e7e64c3d915029e947b1cb0b512737 ]
    
    The supported channels for this driver are {0..3}. Fix the incorrect
    channel in tmp51x_is_visible().
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Closes: https://lore.kernel.org/all/ea0eccc0-a29f-41e4-9049-a1a13f8b16f1@roeck-us.net/
    Fixes: 59dfa75e5d82 ("hwmon: Add driver for Texas Instruments TMP512/513 sensor chips.")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Link: https://lore.kernel.org/r/20230824204456.401580-2-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwrng: iproc-rng200 - Implement suspend and resume calls [+ + +]
Author: Florian Fainelli <florian.fainelli@broadcom.com>
Date:   Thu Aug 10 12:22:08 2023 -0700

    hwrng: iproc-rng200 - Implement suspend and resume calls
    
    [ Upstream commit 8e03dd62e5be811efbf0cbeba47e79e793519105 ]
    
    Chips such as BCM7278 support system wide suspend/resume which will
    cause the HWRNG block to lose its state and reset to its power on reset
    register values. We need to cleanup and re-initialize the HWRNG for it
    to be functional coming out of a system suspend cycle.
    
    Fixes: c3577f6100ca ("hwrng: iproc-rng200 - Add support for BCM7278")
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwrng: nomadik - keep clock enabled while hwrng is registered [+ + +]
Author: Martin Kaiser <martin@kaiser.cx>
Date:   Sun Jul 2 19:35:02 2023 +0200

    hwrng: nomadik - keep clock enabled while hwrng is registered
    
    [ Upstream commit 039980de89dc9dd757418d6f296e4126cc3f86c3 ]
    
    The nomadik driver uses devres to register itself with the hwrng core,
    the driver will be unregistered from hwrng when its device goes out of
    scope. This happens after the driver's remove function is called.
    
    However, nomadik's clock is disabled in the remove function. There's a
    short timeframe where nomadik is still registered with the hwrng core
    although its clock is disabled. I suppose the clock must be active to
    access the hardware and serve requests from the hwrng core.
    
    Switch to devm_clk_get_enabled and let devres disable the clock and
    unregister the hwrng. This avoids the race condition.
    
    Fixes: 3e75241be808 ("hwrng: drivers - Use device-managed registration API")
    Signed-off-by: Martin Kaiser <martin@kaiser.cx>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwrng: pic32 - use devm_clk_get_enabled [+ + +]
Author: Martin Kaiser <martin@kaiser.cx>
Date:   Tue Jul 4 19:32:01 2023 +0200

    hwrng: pic32 - use devm_clk_get_enabled
    
    [ Upstream commit 6755ad74aac0fb1c79b14724feb81b2f6ff25847 ]
    
    Use devm_clk_get_enabled in the pic32 driver. Ensure that the clock is
    enabled as long as the driver is registered with the hwrng core.
    
    Fixes: 7ea39973d1e5 ("hwrng: pic32 - Use device-managed registration API")
    Signed-off-by: Martin Kaiser <martin@kaiser.cx>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: imx-lpi2c: return -EINVAL when i2c peripheral clk doesn't work [+ + +]
Author: Carlos Song <carlos.song@nxp.com>
Date:   Wed Jul 26 17:22:38 2023 +0800

    i2c: imx-lpi2c: return -EINVAL when i2c peripheral clk doesn't work
    
    [ Upstream commit b610c4bbd153c2cde548db48559e170905d7c369 ]
    
    On MX8X platforms, the default clock rate is 0 if without explicit
    clock setting in dts nodes. I2c can't work when i2c peripheral clk
    rate is 0.
    
    Add a i2c peripheral clk rate check before configuring the clock
    register. When i2c peripheral clk rate is 0 and directly return
    -EINVAL.
    
    Signed-off-by: Carlos Song <carlos.song@nxp.com>
    Acked-by: Dong Aisheng <Aisheng.dong@nxp.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i3c: master: svc: fix probe failure when no i3c device exist [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Thu Aug 31 10:13:24 2023 -0400

    i3c: master: svc: fix probe failure when no i3c device exist
    
    commit 6e13d6528be2f7e801af63c8153b87293f25d736 upstream.
    
    I3C masters are expected to support hot-join. This means at initialization
    time we might not yet discover any device and this should not be treated
    as a fatal error.
    
    During the DAA procedure which happens at probe time, if no device has
    joined, all CCC will be NACKed (from a bus perspective). This leads to an
    early return with an error code which fails the probe of the master.
    
    Let's avoid this by just telling the core through an I3C_ERROR_M2
    return command code that no device was discovered, which is a valid
    situation. This way the master will no longer bail out and fail to probe
    for a wrong reason.
    
    Cc: stable@vger.kernel.org
    Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20230831141324.2841525-1-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
IB/uverbs: Fix an potential error pointer dereference [+ + +]
Author: Xiang Yang <xiangyang3@huawei.com>
Date:   Fri Aug 4 10:25:25 2023 +0800

    IB/uverbs: Fix an potential error pointer dereference
    
    [ Upstream commit 26b7d1a27167e7adf75b150755e05d2bc123ce55 ]
    
    smatch reports the warning below:
    drivers/infiniband/core/uverbs_std_types_counters.c:110
    ib_uverbs_handler_UVERBS_METHOD_COUNTERS_READ() error: 'uattr'
    dereferencing possible ERR_PTR()
    
    The return value of uattr maybe ERR_PTR(-ENOENT), fix this by checking
    the value of uattr before using it.
    
    Fixes: ebb6796bd397 ("IB/uverbs: Add read counters support")
    Signed-off-by: Xiang Yang <xiangyang3@huawei.com>
    Link: https://lore.kernel.org/r/20230804022525.1916766-1-xiangyang3@huawei.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: avoid executing commands on other ports when driving sync [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Aug 23 08:18:14 2023 -0700

    ice: avoid executing commands on other ports when driving sync
    
    [ Upstream commit 0aacec49c29e7c5b1487e859b0c0a42388c34092 ]
    
    The ice hardware has a synchronization mechanism used to drive the
    simultaneous application of commands on both PHY ports and the source timer
    in the MAC.
    
    When issuing a sync via ice_ptp_exec_tmr_cmd(), the hardware will
    simultaneously apply the commands programmed for the main timer and each
    PHY port. Neither the main timer command register, nor the PHY port command
    registers auto clear on command execution.
    
    During the execution of a timer command intended for a single port on E822
    devices, such as those used to configure a PHY during link up, the driver
    is not correctly clearing the previous commands.
    
    This results in unintentionally executing the last programmed command on
    the main timer and other PHY ports whenever performing reconfiguration on
    E822 ports after link up. This results in unintended side effects on other
    timers, depending on what command was previously programmed.
    
    To fix this, the driver must ensure that the main timer and all other PHY
    ports are properly initialized to perform no action.
    
    The enumeration for timer commands does not include an enumeration value
    for doing nothing. Introduce ICE_PTP_NOP for this purpose. When writing a
    timer command to hardware, leave the command bits set to zero which
    indicates that no operation should be performed on that port.
    
    Modify ice_ptp_one_port_cmd() to always initialize all ports. For all ports
    other than the one being configured, write their timer command register to
    ICE_PTP_NOP. This ensures that no side effect happens on the timer command.
    
    To fix this for the PHY ports, modify ice_ptp_one_port_cmd() to always
    initialize all other ports to ICE_PTP_NOP. This ensures that no side
    effects happen on the other ports.
    
    Call ice_ptp_src_cmd() with a command value if ICE_PTP_NOP in
    ice_sync_phy_timer_e822() and ice_start_phy_timer_e822().
    
    With both of these changes, the driver should no longer execute a stale
    command on the main timer or another PHY port when reconfiguring one of the
    PHY ports after link up.
    
    Fixes: 3a7496234d17 ("ice: implement basic E822 PTP support")
    Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: ice_aq_check_events: fix off-by-one check when filling buffer [+ + +]
Author: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Date:   Tue Aug 8 17:54:15 2023 -0400

    ice: ice_aq_check_events: fix off-by-one check when filling buffer
    
    [ Upstream commit e1e8a142c43336e3d25bfa1cb3a4ae7d00875c48 ]
    
    Allow task's event buffer to be filled also in the case that it's size
    is exactly the size of the message.
    
    Fixes: d69ea414c9b4 ("ice: implement device flash update via devlink")
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM [+ + +]
Author: Baoquan He <bhe@redhat.com>
Date:   Fri Jul 7 21:58:45 2023 +0800

    idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM
    
    [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ]
    
    On s390 systems (aka mainframes), it has classic channel devices for
    networking and permanent storage that are currently even more common
    than PCI devices. Hence it could have a fully functional s390 kernel
    with CONFIG_PCI=n, then the relevant iomem mapping functions
    [including ioremap(), devm_ioremap(), etc.] are not available.
    
    Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it
    won't be built to cause below compiling error if PCI is unset.
    
    --------
    ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined!
    ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined!
    --------
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/
    Signed-off-by: Baoquan He <bhe@redhat.com>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: dmaengine@vger.kernel.org
    Link: https://lore.kernel.org/r/20230707135852.24292-2-bhe@redhat.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
igb: set max size RX buffer when store bad packet is enabled [+ + +]
Author: Radoslaw Tyl <radoslawx.tyl@intel.com>
Date:   Thu Aug 24 13:46:19 2023 -0700

    igb: set max size RX buffer when store bad packet is enabled
    
    commit bb5ed01cd2428cd25b1c88a3a9cba87055eb289f upstream.
    
    Increase the RX buffer size to 3K when the SBP bit is on. The size of
    the RX buffer determines the number of pages allocated which may not
    be sufficient for receive frames larger than the set MTU size.
    
    Cc: stable@vger.kernel.org
    Fixes: 89eaefb61dc9 ("igb: Support RX-ALL feature flag.")
    Reported-by: Manfred Rudigier <manfred.rudigier@omicronenergy.com>
    Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
    Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
igmp: limit igmpv3_newpack() packet size to IP_MAX_MTU [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 5 04:23:38 2023 +0000

    igmp: limit igmpv3_newpack() packet size to IP_MAX_MTU
    
    commit c3b704d4a4a265660e665df51b129e8425216ed1 upstream.
    
    This is a follow up of commit 915d975b2ffa ("net: deal with integer
    overflows in kmalloc_reserve()") based on David Laight feedback.
    
    Back in 2010, I failed to realize malicious users could set dev->mtu
    to arbitrary values. This mtu has been since limited to 0x7fffffff but
    regardless of how big dev->mtu is, it makes no sense for igmpv3_newpack()
    to allocate more than IP_MAX_MTU and risk various skb fields overflows.
    
    Fixes: 57e1ab6eaddc ("igmp: refine skb allocations")
    Link: https://lore.kernel.org/netdev/d273628df80f45428e739274ab9ecb72@AcuMS.aculab.com/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: David Laight <David.Laight@ACULAB.COM>
    Cc: Kyle Zeng <zengyhkyle@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iio: accel: adxl313: Fix adxl313_i2c_id[] table [+ + +]
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Tue Jul 25 18:16:23 2023 +0100

    iio: accel: adxl313: Fix adxl313_i2c_id[] table
    
    [ Upstream commit f636554c4cd1c644109cc525900a056495b86cc9 ]
    
    The .driver_data in adxl313_i2c_id[] for adxl312 and adxl314 is
    wrong. Fix this issue by adding corresponding adxl31x_chip_info
    data.
    
    Reported-by: Jonathan Cameron <jic23@kernel.org>
    Closes: https://lore.kernel.org/all/20230722172832.04ad7738@jic23-huawei
    Fixes: a7a1c60bc4c9 ("drivers: iio: accel: adxl312 and adxl314 support")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20230725171624.331283-2-biju.das.jz@bp.renesas.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig [+ + +]
Author: Nayna Jain <nayna@linux.ibm.com>
Date:   Tue Jul 11 12:44:47 2023 -0400

    ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig
    
    [ Upstream commit 5087fd9e80e539d2163accd045b73da64de7de95 ]
    
    Time to remove "IMA_TRUSTED_KEYRING".
    
    Fixes: f4dc37785e9b ("integrity: define '.evm' as a builtin 'trusted' keyring") # v4.5+
    Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: i8042 - add quirk for TUXEDO Gemini 17 Gen1/Clevo PD70PN [+ + +]
Author: Werner Sembach <wse@tuxedocomputers.com>
Date:   Wed Jul 12 11:56:51 2023 -0700

    Input: i8042 - add quirk for TUXEDO Gemini 17 Gen1/Clevo PD70PN
    
    commit eb09074bdb05ffd6bfe77f8b4a41b76ef78c997b upstream.
    
    The touchpad of this device is both connected via PS/2 and i2c. This causes
    strange behavior when both driver fight for control. The easy fix is to
    prevent the PS/2 driver from accessing the mouse port as the full feature
    set of the touchpad is only supported in the i2c interface anyway.
    
    The strange behavior in this case is, that when an external screen is
    connected and the notebook is closed, the pointer on the external screen is
    moving to the lower right corner. When the notebook is opened again, this
    movement stops, but the touchpad clicks are unresponsive afterwards until
    reboot.
    
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230607173331.851192-1-wse@tuxedocomputers.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
interconnect: qcom: bcm-voter: Improve enable_mask handling [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:16:15 2023 +0200

    interconnect: qcom: bcm-voter: Improve enable_mask handling
    
    [ Upstream commit a1f4170dec440f023601d57e49227b784074d218 ]
    
    We don't need all the complex arithmetic for BCMs utilizing enable_mask,
    as all we need to do is to determine whether there's any user (or
    keepalive) asking for it to be on.
    
    Separate the logic for such BCMs for a small speed boost.
    
    Suggested-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-icc_fix_1he-v2-1-0620af8ac133@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Stable-dep-of: 1a70ca71547b ("interconnect: qcom: bcm-voter: Use enable_maks for keepalive voting")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: bcm-voter: Use enable_maks for keepalive voting [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Aug 12 01:16:16 2023 +0200

    interconnect: qcom: bcm-voter: Use enable_maks for keepalive voting
    
    [ Upstream commit 1a70ca71547be051769f0628aa09717694f508f0 ]
    
    BCMs with an enable_mask expect to only have that specific value written
    to them. The current implementation only works by miracle for BCMs with
    enable mask == BIT(0), as the minimal vote we've been using so far just
    so happens to be equal to that.
    
    Use the correct value with keepalive voting.
    
    Fixes: d8630f050d3f ("interconnect: qcom: Add support for mask-based BCMs")
    Reported-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230811-topic-icc_fix_1he-v2-2-0620af8ac133@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: qcm2290: Enable sync state [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jul 24 12:49:22 2023 +0200

    interconnect: qcom: qcm2290: Enable sync state
    
    [ Upstream commit 4e048e9b7a160f7112069c0ec2947be15f3e8154 ]
    
    Enable the generic .sync_state callback to ensure there are no
    outstanding votes that would waste power.
    
    Generally one would need a bunch of interface clocks to access the QoS
    registers when trying to go over all possible nodes during sync_state,
    but QCM2290 surprisingly does not seem to require any such handling.
    
    Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230720-topic-qcm2290_icc-v2-2-a2ceb9d3e713@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: sm8450: Enable sync_state [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Aug 11 19:34:57 2023 +0200

    interconnect: qcom: sm8450: Enable sync_state
    
    [ Upstream commit 16862f1b2110eca6330e5be6d804e1a08e06a202 ]
    
    Enable sync_state on sm8450 so that the interconnect votes actually mean
    anything and aren't just pinned to INT_MAX.
    
    Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Vinod Koul <vkoul@kernel.org>
    Link: https://lore.kernel.org/r/20230811-topic-8450_syncstate-v1-1-69ae5552a18b@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/sqpoll: fix io-wq affinity when IORING_SETUP_SQPOLL is used [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Aug 13 11:05:36 2023 -0600

    io_uring/sqpoll: fix io-wq affinity when IORING_SETUP_SQPOLL is used
    
    commit ebdfefc09c6de7897962769bd3e63a2ff443ebf5 upstream.
    
    If we setup the ring with SQPOLL, then that polling thread has its
    own io-wq setup. This means that if the application uses
    IORING_REGISTER_IOWQ_AFF to set the io-wq affinity, we should not be
    setting it for the invoking task, but rather the sqpoll task.
    
    Add an sqpoll helper that parks the thread and updates the affinity,
    and use that one if we're using SQPOLL.
    
    Fixes: fe76421d1da1 ("io_uring: allow user configurable IO thread CPU affinity")
    Cc: stable@vger.kernel.org # 5.10+
    Link: https://github.com/axboe/liburing/discussions/884
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring: break iopolling on signal [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Aug 9 16:20:21 2023 +0100

    io_uring: break iopolling on signal
    
    commit dc314886cb3d0e4ab2858003e8de2917f8a3ccbd upstream.
    
    Don't keep spinning iopoll with a signal set. It'll eventually return
    back, e.g. by virtue of need_resched(), but it's not a nice user
    experience.
    
    Cc: stable@vger.kernel.org
    Fixes: def596e9557c9 ("io_uring: support for IO polling")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/eeba551e82cad12af30c3220125eb6cb244cc94c.1691594339.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring: break out of iowq iopoll on teardown [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Thu Sep 7 13:50:07 2023 +0100

    io_uring: break out of iowq iopoll on teardown
    
    commit 45500dc4e01c167ee063f3dcc22f51ced5b2b1e9 upstream.
    
    io-wq will retry iopoll even when it failed with -EAGAIN. If that
    races with task exit, which sets TIF_NOTIFY_SIGNAL for all its workers,
    such workers might potentially infinitely spin retrying iopoll again and
    again and each time failing on some allocation / waiting / etc. Don't
    keep spinning if io-wq is dying.
    
    Fixes: 561fb04a6a225 ("io_uring: replace workqueue usage with io-wq")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring: Don't set affinity on a dying sqpoll thread [+ + +]
Author: Gabriel Krisman Bertazi <krisman@suse.de>
Date:   Mon Aug 28 19:42:49 2023 -0400

    io_uring: Don't set affinity on a dying sqpoll thread
    
    commit bd6fc5da4c51107e1e0cec4a3a07963d1dae2c84 upstream.
    
    Syzbot reported a null-ptr-deref of sqd->thread inside
    io_sqpoll_wq_cpu_affinity.  It turns out the sqd->thread can go away
    from under us during io_uring_register, in case the process gets a
    fatal signal during io_uring_register.
    
    It is not particularly hard to hit the race, and while I am not sure
    this is the exact case hit by syzbot, it solves it.  Finally, checking
    ->thread is enough to close the race because we locked sqd while
    "parking" the thread, thus preventing it from going away.
    
    I reproduced it fairly consistently with a program that does:
    
    int main(void) {
      ...
      io_uring_queue_init(RING_LEN, &ring1, IORING_SETUP_SQPOLL);
      while (1) {
        io_uring_register_iowq_aff(ring, 1, &mask);
      }
    }
    
    Executed in a loop with timeout to trigger SIGTERM:
      while true; do timeout 1 /a.out ; done
    
    This will hit the following BUG() in very few attempts.
    
    BUG: kernel NULL pointer dereference, address: 00000000000007a8
    PGD 800000010e949067 P4D 800000010e949067 PUD 10e46e067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 0 PID: 15715 Comm: dead-sqpoll Not tainted 6.5.0-rc7-next-20230825-g193296236fa0-dirty #23
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
    RIP: 0010:io_sqpoll_wq_cpu_affinity+0x27/0x70
    Code: 90 90 90 0f 1f 44 00 00 55 53 48 8b 9f 98 03 00 00 48 85 db 74 4f
    48 89 df 48 89 f5 e8 e2 f8 ff ff 48 8b 43 38 48 85 c0 74 22 <48> 8b b8
    a8 07 00 00 48 89 ee e8 ba b1 00 00 48 89 df 89 c5 e8 70
    RSP: 0018:ffffb04040ea7e70 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff93c010749e40 RCX: 0000000000000001
    RDX: 0000000000000000 RSI: ffffffffa7653331 RDI: 00000000ffffffff
    RBP: ffffb04040ea7eb8 R08: 0000000000000000 R09: c0000000ffffdfff
    R10: ffff93c01141b600 R11: ffffb04040ea7d18 R12: ffff93c00ea74840
    R13: 0000000000000011 R14: 0000000000000000 R15: ffff93c00ea74800
    FS:  00007fb7c276ab80(0000) GS:ffff93c36f200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000000007a8 CR3: 0000000111634003 CR4: 0000000000370ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ? __die_body+0x1a/0x60
     ? page_fault_oops+0x154/0x440
     ? do_user_addr_fault+0x174/0x7b0
     ? exc_page_fault+0x63/0x140
     ? asm_exc_page_fault+0x22/0x30
     ? io_sqpoll_wq_cpu_affinity+0x27/0x70
     __io_register_iowq_aff+0x2b/0x60
     __io_uring_register+0x614/0xa70
     __x64_sys_io_uring_register+0xaa/0x1a0
     do_syscall_64+0x3a/0x90
     entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    RIP: 0033:0x7fb7c226fec9
    Code: 2e 00 b8 ca 00 00 00 0f 05 eb a5 66 0f 1f 44 00 00 48 89 f8 48 89
    f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
    f0 ff ff 73 01 c3 48 8b 0d 97 7f 2d 00 f7 d8 64 89 01 48
    RSP: 002b:00007ffe2c0674f8 EFLAGS: 00000246 ORIG_RAX: 00000000000001ab
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb7c226fec9
    RDX: 00007ffe2c067530 RSI: 0000000000000011 RDI: 0000000000000003
    RBP: 00007ffe2c0675d0 R08: 00007ffe2c067550 R09: 00007ffe2c067550
    R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffe2c067750 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    Modules linked in:
    CR2: 00000000000007a8
    ---[ end trace 0000000000000000 ]---
    
    Reported-by: syzbot+c74fea926a78b8a91042@syzkaller.appspotmail.com
    Fixes: ebdfefc09c6d ("io_uring/sqpoll: fix io-wq affinity when IORING_SETUP_SQPOLL is used")
    Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
    Link: https://lore.kernel.org/r/87v8cybuo6.fsf@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring: fix drain stalls by invalid SQE [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Aug 9 13:21:41 2023 +0100

    io_uring: fix drain stalls by invalid SQE
    
    [ Upstream commit cfdbaa3a291d6fd2cb4a1a70d74e63b4abc2f5ec ]
    
    cq_extra is protected by ->completion_lock, which io_get_sqe() misses.
    The bug is harmless as it doesn't happen in real life, requires invalid
    SQ index array and racing with submission, and only messes up the
    userspace, i.e. stall requests execution but will be cleaned up on
    ring destruction.
    
    Fixes: 15641e427070f ("io_uring: don't cache number of dropped SQEs")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/66096d54651b1a60534bb2023f2947f09f50ef73.1691538547.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: fix false positive KASAN warnings [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Aug 9 13:22:16 2023 +0100

    io_uring: fix false positive KASAN warnings
    
    commit 569f5308e54352a12181cc0185f848024c5443e8 upstream.
    
    io_req_local_work_add() peeks into the work list, which can be executed
    in the meanwhile. It's completely fine without KASAN as we're in an RCU
    read section and it's SLAB_TYPESAFE_BY_RCU. With KASAN though it may
    trigger a false positive warning because internal io_uring caches are
    sanitised.
    
    Remove sanitisation from the io_uring request cache for now.
    
    Cc: stable@vger.kernel.org
    Fixes: 8751d15426a31 ("io_uring: reduce scheduling due to tw")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/c6fbf7a82a341e66a0007c76eefd9d57f2d3ba51.1691541473.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iomap: Remove large folio handling in iomap_invalidate_folio() [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Fri Jun 2 18:09:11 2023 -0400

    iomap: Remove large folio handling in iomap_invalidate_folio()
    
    [ Upstream commit a221ab717c43147f728d93513923ba3528f861bf ]
    
    We do not need to release the iomap_page in iomap_invalidate_folio()
    to allow the folio to be split.  The splitting code will call
    ->release_folio() if there is still per-fs private data attached to
    the folio.  At that point, we will check if the folio is still dirty
    and decline to release the iomap_page.  It is possible to trigger the
    warning in perfectly legitimate circumstances (eg if a disk read fails,
    we do a partial write to the folio, then we truncate the folio), which
    will cause those writes to be lost.
    
    Fixes: 60d8231089f0 ("iomap: Support large folios in invalidatepage")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind [+ + +]
Author: Daniel Marcovitch <dmarcovitch@nvidia.com>
Date:   Fri Jun 9 10:51:45 2023 +0000

    iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind
    
    [ Upstream commit 534103bcd52ca9c1fecbc70e717b4a538dc4ded8 ]
    
    When unbinding pasid - a race condition exists vs outstanding page faults.
    
    To prevent this, the pasid_state object contains a refcount.
        * set to 1 on pasid bind
        * incremented on each ppr notification start
        * decremented on each ppr notification done
        * decremented on pasid unbind
    
    Since refcount_dec assumes that refcount will never reach 0:
      the current implementation causes the following to be invoked on
      pasid unbind:
            REFCOUNT_WARN("decrement hit 0; leaking memory")
    
    Fix this issue by changing refcount_dec to refcount_dec_and_test
    to explicitly handle refcount=1.
    
    Fixes: 8bc54824da4e ("iommu/amd: Convert from atomic_t to refcount_t on pasid_state->count")
    Signed-off-by: Daniel Marcovitch <dmarcovitch@nvidia.com>
    Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
    Link: https://lore.kernel.org/r/20230609105146.7773-2-vasant.hegde@amd.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/mediatek: Fix two IOMMU share pagetable issue [+ + +]
Author: Chengci.Xu <chengci.xu@mediatek.com>
Date:   Fri Jun 2 17:02:22 2023 +0800

    iommu/mediatek: Fix two IOMMU share pagetable issue
    
    [ Upstream commit cf69ef46dbd980a0b1c956d668e066a73e0acd0f ]
    
    Prepare for mt8188 to fix a two IOMMU HWs share pagetable issue.
    
    We have two MM IOMMU HWs in mt8188, one is VPP-IOMMU, the other is
    VDO-IOMMU. The 2 MM IOMMU HWs share pagetable don't work in this case:
     a) VPP-IOMMU probe firstly.
     b) VDO-IOMMU probe.
     c) The master for VDO-IOMMU probe (means frstdata is vpp-iommu).
     d) The master in another domain probe. No matter it is vdo or vpp.
    Then it still create a new pagetable in step d). The problem is
    "frstdata->bank[0]->m4u_dom" was not initialized. Then when d) enter, it
    still create a new one.
    
    In this patch, we create a new variable "share_dom" for this share
    pgtable case, it should be helpful for readable. and put all the share
    pgtable logic in the mtk_iommu_domain_finalise.
    
    In mt8195, the master of VPP-IOMMU probes before than VDO-IOMMU
    from its dtsi node sequence, we don't see this issue in it. Prepare for
    mt8188.
    
    Fixes: 645b87c190c9 ("iommu/mediatek: Fix 2 HW sharing pgtable issue")
    Signed-off-by: Chengci.Xu <chengci.xu@mediatek.com>
    Signed-off-by: Yong Wu <yong.wu@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Link: https://lore.kernel.org/r/20230602090227.7264-3-yong.wu@mediatek.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/qcom: Disable and reset context bank before programming [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Jun 22 11:27:39 2023 +0200

    iommu/qcom: Disable and reset context bank before programming
    
    [ Upstream commit 9f3fef23d9b5a858a6e6d5f478bb1b6b76265e76 ]
    
    Writing the new TTBRs, TCRs and MAIRs on a previously enabled
    context bank may trigger a context fault, resulting in firmware
    driven AP resets: change the domain initialization programming
    sequence to disable the context bank(s) and to also clear the
    related fault address (CB_FAR) and fault status (CB_FSR)
    registers before writing new values to TTBR0/1, TCR/TCR2, MAIR0/1.
    
    Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20230622092742.74819-4-angelogioacchino.delregno@collabora.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/sprd: Add missing force_aperture [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Jul 24 14:36:05 2023 -0300

    iommu/sprd: Add missing force_aperture
    
    [ Upstream commit d48a51286c698f7fe8efc688f23a532f4fe9a904 ]
    
    force_aperture was intended to false only by GART drivers that have an
    identity translation outside the aperture. This does not describe sprd, so
    add the missing 'force_aperture = true'.
    
    Fixes: b23e4fc4e3fa ("iommu: add Unisoc IOMMU basic driver")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/vt-d: Fix to flush cache of PASID directory table [+ + +]
Author: Yanfei Xu <yanfei.xu@intel.com>
Date:   Wed Aug 9 20:48:04 2023 +0800

    iommu/vt-d: Fix to flush cache of PASID directory table
    
    [ Upstream commit 8a3b8e63f8371c1247b7aa24ff9c5312f1a6948b ]
    
    Even the PCI devices don't support pasid capability, PASID table is
    mandatory for a PCI device in scalable mode. However flushing cache
    of pasid directory table for these devices are not taken after pasid
    table is allocated as the "size" of table is zero. Fix it by
    calculating the size by page order.
    
    Found this when reading the code, no real problem encountered for now.
    
    Fixes: 194b3348bdbb ("iommu/vt-d: Fix PASID directory pointer coherency")
    Suggested-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Yanfei Xu <yanfei.xu@intel.com>
    Link: https://lore.kernel.org/r/20230616081045.721873-1-yanfei.xu@intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu: Remove kernel-doc warnings [+ + +]
Author: Zhu Wang <wangzhu9@huawei.com>
Date:   Mon Jul 31 19:27:58 2023 +0800

    iommu: Remove kernel-doc warnings
    
    [ Upstream commit 6b7867b5b8a6b14c487bf04a693ab424c7a8718d ]
    
    Remove kernel-doc warnings:
    
    drivers/iommu/iommu.c:3261: warning: Function parameter or member 'group'
    not described in 'iommu_group_release_dma_owner'
    drivers/iommu/iommu.c:3261: warning: Excess function parameter 'dev'
    description in 'iommu_group_release_dma_owner'
    drivers/iommu/iommu.c:3275: warning: Function parameter or member 'dev'
    not described in 'iommu_device_release_dma_owner'
    drivers/iommu/iommu.c:3275: warning: Excess function parameter 'group'
    description in 'iommu_device_release_dma_owner'
    
    Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
    Fixes: 89395ccedbc1 ("iommu: Add device-centric DMA ownership interfaces")
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/20230731112758.214775-1-wangzhu9@huawei.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu: rockchip: Fix directory table address encoding [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Sat Jun 17 18:25:45 2023 +0000

    iommu: rockchip: Fix directory table address encoding
    
    [ Upstream commit 6df63b7ebdaf5fcd75dceedf6967d0761e56eca1 ]
    
    The physical address to the directory table is currently encoded using
    the following bit layout for IOMMU v2.
    
     31:12 - Address bit 31:0
     11: 4 - Address bit 39:32
    
    This is also the bit layout used by the vendor kernel.
    
    However, testing has shown that addresses to the directory/page tables
    and memory pages are all encoded using the same bit layout.
    
    IOMMU v1:
     31:12 - Address bit 31:0
    
    IOMMU v2:
     31:12 - Address bit 31:0
     11: 8 - Address bit 35:32
      7: 4 - Address bit 39:36
    
    Change to use the mk_dtentries ops to encode the directory table address
    correctly. The value written to DTE_ADDR may include the valid bit set,
    a bit that is ignored and DTE_ADDR reg read it back as 0.
    
    This also update the bit layout comment for the page address and the
    number of nybbles that are read back for DTE_ADDR comment.
    
    These changes render the dte_addr_phys and dma_addr_dte ops unused and
    is removed.
    
    Fixes: 227014b33f62 ("iommu: rockchip: Add internal ops to handle variants")
    Fixes: c55356c534aa ("iommu: rockchip: Add support for iommu v2")
    Fixes: c987b65a574f ("iommu/rockchip: Fix physical address decoding")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20230617182540.3091374-2-jonas@kwiboo.se
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommufd: Fix locking around hwpt allocation [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Mon Jul 17 15:12:07 2023 -0300

    iommufd: Fix locking around hwpt allocation
    
    [ Upstream commit 31422dff187b243c58f3a97d16bbe9e9ada639fe ]
    
    Due to the auto_domains mechanism the ioas->mutex must be held until
    the hwpt is completely setup by iommufd_object_abort_and_destroy() or
    iommufd_object_finalize().
    
    This prevents a concurrent iommufd_device_auto_get_domain() from seeing
    an incompletely initialized object through the ioas->hwpt_list.
    
    To make this more consistent move the unlock until after finalize.
    
    Fixes: e8d57210035b ("iommufd: Add kAPI toward external drivers for physical devices")
    Link: https://lore.kernel.org/r/11-v8-6659224517ea+532-iommufd_alloc_jgg@nvidia.com
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Tested-by: Nicolin Chen <nicolinc@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iov_iter: Fix iov_iter_extract_pages() with zero-sized entries [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Sep 8 17:03:20 2023 +0100

    iov_iter: Fix iov_iter_extract_pages() with zero-sized entries
    
    commit f741bd7178c95abd7aeac5a9d933ee542f9a5509 upstream.
    
    iov_iter_extract_pages() doesn't correctly handle skipping over initial
    zero-length entries in ITER_KVEC and ITER_BVEC-type iterators.
    
    The problem is that it accidentally reduces maxsize to 0 when it
    skipping and thus runs to the end of the array and returns 0.
    
    Fix this by sticking the calculated size-to-copy in a new variable
    rather than back in maxsize.
    
    Fixes: 7d58fe731028 ("iov_iter: Add a function to extract a page list from an iterator")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: ipmi:ssif: Add check for kstrdup [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Mon Jun 19 17:28:02 2023 +0800

    ipmi:ssif: Add check for kstrdup
    
    [ Upstream commit c5586d0f711e9744d0cade39b0c4a2d116a333ca ]
    
    Add check for the return value of kstrdup() and return the error
    if it fails in order to avoid NULL pointer dereference.
    
    Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Message-Id: <20230619092802.35384-1-jiasheng@iscas.ac.cn>
    Signed-off-by: Corey Minyard <minyard@acm.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Linux: ipmi:ssif: Fix a memory leak when scanning for an adapter [+ + +]
Author: Corey Minyard <minyard@acm.org>
Date:   Mon Jun 19 11:43:33 2023 -0500

    ipmi:ssif: Fix a memory leak when scanning for an adapter
    
    [ Upstream commit b8d72e32e1453d37ee5c8a219f24e7eeadc471ef ]
    
    The adapter scan ssif_info_find() sets info->adapter_name if the adapter
    info came from SMBIOS, as it's not set in that case.  However, this
    function can be called more than once, and it will leak the adapter name
    if it had already been set.  So check for NULL before setting it.
    
    Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface")
    Signed-off-by: Corey Minyard <minyard@acm.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipmi_si: fix a memleak in try_smi_init() [+ + +]
Author: Yi Yang <yiyang13@huawei.com>
Date:   Thu Jun 29 20:33:28 2023 +0800

    ipmi_si: fix a memleak in try_smi_init()
    
    commit 6cf1a126de2992b4efe1c3c4d398f8de4aed6e3f upstream.
    
    Kmemleak reported the following leak info in try_smi_init():
    
    unreferenced object 0xffff00018ecf9400 (size 1024):
      comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)
      backtrace:
        [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0
        [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si]
        [<000000006460d325>] 0xffff800081b10148
        [<0000000039206ea5>] do_one_initcall+0x64/0x2a4
        [<00000000601399ce>] do_init_module+0x50/0x300
        [<000000003c12ba3c>] load_module+0x7a8/0x9e0
        [<00000000c246fffe>] __se_sys_init_module+0x104/0x180
        [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30
        [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250
        [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0
        [<000000005a05337f>] el0_svc+0x24/0x3c
        [<000000005eb248d6>] el0_sync_handler+0x160/0x164
        [<0000000030a59039>] el0_sync+0x160/0x180
    
    The problem was that when an error occurred before handlers registration
    and after allocating `new_smi->si_sm`, the variable wouldn't be freed in
    the error handling afterwards since `shutdown_smi()` hadn't been
    registered yet. Fix it by adding a `kfree()` in the error handling path
    in `try_smi_init()`.
    
    Cc: stable@vger.kernel.org # 4.19+
    Fixes: 7960f18a5647 ("ipmi_si: Convert over to a shutdown handler")
    Signed-off-by: Yi Yang <yiyang13@huawei.com>
    Co-developed-by: GONG, Ruiqi <gongruiqi@huaweicloud.com>
    Signed-off-by: GONG, Ruiqi <gongruiqi@huaweicloud.com>
    Message-Id: <20230629123328.2402075-1-gongruiqi@huaweicloud.com>
    Signed-off-by: Corey Minyard <minyard@acm.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/loongson-eiointc: Fix return value checking of eiointc_index [+ + +]
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Fri Aug 11 17:58:04 2023 +0800

    irqchip/loongson-eiointc: Fix return value checking of eiointc_index
    
    [ Upstream commit 2e99b73afde18853754c5fae8e8d1a66fe5e3f64 ]
    
    Return value of function eiointc_index is int, however it is converted
    into uint32_t and then compared smaller than zero, this will cause logic
    problem.
    
    Fixes: dd281e1a1a93 ("irqchip: Add Loongson Extended I/O interrupt controller support")
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20230811095805.2974722-2-maobibo@loongson.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jfs: validate max amount of blocks before allocation. [+ + +]
Author: Alexei Filippov <halip0503@gmail.com>
Date:   Sat Aug 19 20:32:16 2023 +0300

    jfs: validate max amount of blocks before allocation.
    
    [ Upstream commit 0225e10972fa809728b8d4c1bd2772b3ec3fdb57 ]
    
    The lack of checking bmp->db_max_freebud in extBalloc() can lead to
    shift out of bounds, so this patch prevents undefined behavior, because
    bmp->db_max_freebud == -1 only if there is no free space.
    
    Signed-off-by: Aleksei Filippov <halip0503@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-and-tested-by: syzbot+5f088f29593e6b4c8db8@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?id=01abadbd6ae6a08b1f1987aa61554c6b3ac19ff2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kbuild: rust_is_available: add check for `bindgen` invocation [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Fri Jun 16 02:16:25 2023 +0200

    kbuild: rust_is_available: add check for `bindgen` invocation
    
    [ Upstream commit 52cae7f28ed6c3992489f16bb355f5b623f0912e ]
    
    `scripts/rust_is_available.sh` calls `bindgen` with a special
    header in order to check whether the `libclang` version in use
    is suitable.
    
    However, the invocation itself may fail if, for instance, `bindgen`
    cannot locate `libclang`. This is fine for Kconfig (since the
    script will still fail and therefore disable Rust as it should),
    but it is pretty confusing for users of the `rustavailable` target
    given the error will be unrelated:
    
        ./scripts/rust_is_available.sh: 21: arithmetic expression: expecting primary: "100000 *  + 100 *  + "
        make: *** [Makefile:1816: rustavailable] Error 2
    
    Instead, run the `bindgen` invocation independently in a previous
    step, saving its output and return code. If it fails, then show
    the user a proper error message. Otherwise, continue as usual
    with the saved output.
    
    Since the previous patch we show a reference to the docs, and
    the docs now explain how `bindgen` looks for `libclang`,
    thus the error message can leverage the documentation, avoiding
    duplication here (and making users aware of the setup guide in
    the documentation).
    
    Reported-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/rust-for-linux/CAKwvOdm5JT4wbdQQYuW+RT07rCi6whGBM2iUAyg8A1CmLXG6Nw@mail.gmail.com/
    Reported-by: François Valenduc <francoisvalenduc@gmail.com>
    Closes: https://github.com/Rust-for-Linux/linux/issues/934
    Reported-by: Alexandru Radovici <msg4alex@gmail.com>
    Closes: https://github.com/Rust-for-Linux/linux/pull/921
    Reported-by: Matthew Leach <dev@mattleach.net>
    Closes: https://lore.kernel.org/rust-for-linux/20230507084116.1099067-1-dev@mattleach.net/
    Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`")
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20230616001631.463536-6-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kbuild: rust_is_available: fix confusion when a version appears in the path [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Fri Jun 16 02:16:27 2023 +0200

    kbuild: rust_is_available: fix confusion when a version appears in the path
    
    [ Upstream commit 9eb7e20e0c5cd069457845f965b3e8a7d736ecb7 ]
    
    `bindgen`'s output for `libclang`'s version check contains paths, which
    in turn may contain strings that look like version numbers [1][2]:
    
        .../6.1.0-dev/.../rust_is_available_bindgen_libclang.h:2:9: warning: clang version 11.1.0  [-W#pragma-messages], err: false
    
    which the script will pick up as the version instead of the latter.
    
    It is also the case that versions may appear after the actual version
    (e.g. distribution's version text), which was the reason behind `head` [3]:
    
        .../rust-is-available-bindgen-libclang.h:2:9: warning: clang version 13.0.0 (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false
    
    Thus instead ask for a match after the `clang version` string.
    
    Reported-by: Jordan Isaacs <mail@jdisaacs.com>
    Closes: https://github.com/Rust-for-Linux/linux/issues/942 [1]
    Reported-by: "Ethan D. Twardy" <ethan.twardy@gmail.com>
    Closes: https://lore.kernel.org/rust-for-linux/20230528131802.6390-2-ethan.twardy@gmail.com/ [2]
    Reported-by: Tiago Lam <tiagolam@gmail.com>
    Closes: https://github.com/Rust-for-Linux/linux/pull/789 [3]
    Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`")
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Reviewed-by: Ethan Twardy <ethan.twardy@gmail.com>
    Tested-by: Ethan Twardy <ethan.twardy@gmail.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20230616001631.463536-8-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kbuild: rust_is_available: fix version check when CC has multiple arguments [+ + +]
Author: Russell Currey <ruscur@russell.cc>
Date:   Fri Jun 16 02:16:22 2023 +0200

    kbuild: rust_is_available: fix version check when CC has multiple arguments
    
    [ Upstream commit dee3a6b819c96fc8b1907577f585fd66f5c0fefe ]
    
    rust_is_available.sh uses cc-version.sh to identify which C compiler is
    in use, as scripts/Kconfig.include does.  cc-version.sh isn't designed to
    be able to handle multiple arguments in one variable, i.e. "ccache clang".
    Its invocation in rust_is_available.sh quotes "$CC", which makes
    $1 == "ccache clang" instead of the intended $1 == ccache & $2 == clang.
    
    cc-version.sh could also be changed to handle having "ccache clang" as one
    argument, but it only has the one consumer upstream, making it simpler to
    fix the caller here.
    
    Signed-off-by: Russell Currey <ruscur@russell.cc>
    Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`")
    Link: https://github.com/Rust-for-Linux/linux/pull/873
    [ Reworded title prefix and reflow line to 75 columns. ]
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20230616001631.463536-3-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kbuild: rust_is_available: remove -v option [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri Jun 16 02:16:21 2023 +0200

    kbuild: rust_is_available: remove -v option
    
    [ Upstream commit d824d2f98565e7c4cb1b862c230198fbe1a968be ]
    
    The -v option is passed when this script is invoked from Makefile,
    but not when invoked from Kconfig.
    
    As you can see in scripts/Kconfig.include, the 'success' macro suppresses
    stdout and stderr anyway, so this script does not need to be quiet.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
    Tested-by: Miguel Ojeda <ojeda@kernel.org>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/r/20230109061436.3146442-1-masahiroy@kernel.org
    [ Reworded prefix to match the others in the patch series. ]
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Link: https://lore.kernel.org/r/20230616001631.463536-2-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Stable-dep-of: dee3a6b819c9 ("kbuild: rust_is_available: fix version check when CC has multiple arguments")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kernfs: add stub helper for kernfs_generic_poll() [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jul 24 14:18:16 2023 +0200

    kernfs: add stub helper for kernfs_generic_poll()
    
    [ Upstream commit 79038a99445f69c5d28494dd4f8c6f0509f65b2e ]
    
    In some randconfig builds, kernfs ends up being disabled, so there is no prototype
    for kernfs_generic_poll()
    
    In file included from kernel/sched/build_utility.c:97:
    kernel/sched/psi.c:1479:3: error: implicit declaration of function 'kernfs_generic_poll' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                    kernfs_generic_poll(t->of, wait);
                    ^
    
    Add a stub helper for it, as we have it for other kernfs functions.
    
    Fixes: aff037078ecae ("sched/psi: use kernfs polling functions for PSI trigger polling")
    Fixes: 147e1a97c4a0b ("fs: kernfs: add poll file operation")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
    Link: https://lore.kernel.org/r/20230724121823.1357562-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kprobes: Prohibit probing on CFI preamble symbol [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Tue Jul 11 10:50:47 2023 +0900

    kprobes: Prohibit probing on CFI preamble symbol
    
    [ Upstream commit de02f2ac5d8cfb311f44f2bf144cc20002f1fbbd ]
    
    Do not allow to probe on "__cfi_" or "__pfx_" started symbol, because those
    are used for CFI and not executed. Probing it will break the CFI.
    
    Link: https://lore.kernel.org/all/168904024679.116016.18089228029322008512.stgit@devnote2/
    
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: fix out of bounds in init_smb2_rsp_hdr() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jul 23 15:27:37 2023 +0900

    ksmbd: fix out of bounds in init_smb2_rsp_hdr()
    
    [ Upstream commit 536bb492d39bb6c080c92f31e8a55fe9934f452b ]
    
    If client send smb2 negotiate request and then send smb1 negotiate
    request, init_smb2_rsp_hdr is called for smb1 negotiate request since
    need_neg is set to false. This patch ignore smb1 packets after ->need_neg
    is set to false.
    
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-21541
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: fix out of bounds in smb3_decrypt_req() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sat Jul 22 00:09:28 2023 +0900

    ksmbd: fix out of bounds in smb3_decrypt_req()
    
    [ Upstream commit dc318846f3dd54574a36ae97fc8d8b75dd7cdb1e ]
    
    smb3_decrypt_req() validate if pdu_length is smaller than
    smb2_transform_hdr size.
    
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-21589
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: Fix unsigned expression compared with zero [+ + +]
Author: Wang Ming <machel@vivo.com>
Date:   Tue Jul 4 15:40:47 2023 +0800

    ksmbd: Fix unsigned expression compared with zero
    
    [ Upstream commit 0266a2f791294e0b4ba36f4a1d89b8615ea3cac0 ]
    
    The return value of the ksmbd_vfs_getcasexattr() is signed.
    However, the return value is being assigned to an unsigned
    variable and subsequently recasted, causing warnings. Use
    a signed type.
    
    Signed-off-by: Wang Ming <machel@vivo.com>
    Acked-by: Tom Talpey <tom@talpey.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: no response from compound read [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jul 23 15:22:33 2023 +0900

    ksmbd: no response from compound read
    
    [ Upstream commit e202a1e8634b186da38cbbff85382ea2b9e297cf ]
    
    ksmbd doesn't support compound read. If client send read-read in
    compound to ksmbd, there can be memory leak from read buffer.
    Windows and linux clients doesn't send it to server yet. For now,
    No response from compound read. compound read will be supported soon.
    
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-21587, ZDI-CAN-21588
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: validate session id and tree id in compound request [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jul 23 15:21:11 2023 +0900

    ksmbd: validate session id and tree id in compound request
    
    [ Upstream commit 3df0411e132ee74a87aa13142dfd2b190275332e ]
    
    `smb2_get_msg()` in smb2_get_ksmbd_tcon() and smb2_check_user_session()
    will always return the first request smb2 header in a compound request.
    if `SMB2_TREE_CONNECT_HE` is the first command in compound request, will
    return 0, i.e. The tree id check is skipped.
    This patch use ksmbd_req_buf_next() to get current command in compound.
    
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-21506
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kvm/vfio: ensure kvg instance stays around in kvm_vfio_group_add() [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Jul 14 15:45:32 2023 -0700

    kvm/vfio: ensure kvg instance stays around in kvm_vfio_group_add()
    
    [ Upstream commit 9e0f4f2918c2ff145d3dedee862d9919a6ed5812 ]
    
    kvm_vfio_group_add() creates kvg instance, links it to kv->group_list,
    and calls kvm_vfio_file_set_kvm() with kvg->file as an argument after
    dropping kv->lock. If we race group addition and deletion calls, kvg
    instance may get freed by the time we get around to calling
    kvm_vfio_file_set_kvm().
    
    Previous iterations of the code did not reference kvg->file outside of
    the critical section, but used a temporary variable. Still, they had
    similar problem of the file reference being owned by kvg structure and
    potential for kvm_vfio_group_del() dropping it before
    kvm_vfio_group_add() had a chance to complete.
    
    Fix this by moving call to kvm_vfio_file_set_kvm() under the protection
    of kv->lock. We already call it while holding the same lock when vfio
    group is being deleted, so it should be safe here as well.
    
    Fixes: 2fc1bec15883 ("kvm: set/clear kvm to/from vfio_group when group add/delete")
    Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20230714224538.404793-1-dmitry.torokhov@gmail.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kvm/vfio: Prepare for accepting vfio device fd [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Tue Jul 18 06:55:29 2023 -0700

    kvm/vfio: Prepare for accepting vfio device fd
    
    [ Upstream commit 2f99073a722beef5f74f3b0f32bda227ba3df1e0 ]
    
    This renames kvm_vfio_group related helpers to prepare for accepting
    vfio device fd. No functional change is intended.
    
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Tested-by: Terrence Xu <terrence.xu@intel.com>
    Tested-by: Nicolin Chen <nicolinc@nvidia.com>
    Tested-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Tested-by: Yanting Jiang <yanting.jiang@intel.com>
    Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
    Tested-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Link: https://lore.kernel.org/r/20230718135551.6592-5-yi.l.liu@intel.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Stable-dep-of: 9e0f4f2918c2 ("kvm/vfio: ensure kvg instance stays around in kvm_vfio_group_add()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: x86/mmu: Add "never" option to allow sticky disabling of nx_huge_pages [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Jun 1 17:58:59 2023 -0700

    KVM: x86/mmu: Add "never" option to allow sticky disabling of nx_huge_pages
    
    commit 0b210faf337314e4bc88e796218bc70c72a51209 upstream.
    
    Add a "never" option to the nx_huge_pages module param to allow userspace
    to do a one-way hard disabling of the mitigation, and don't create the
    per-VM recovery threads when the mitigation is hard disabled.  Letting
    userspace pinky swear that userspace doesn't want to enable NX mitigation
    (without reloading KVM) allows certain use cases to avoid the latency
    problems associated with spawning a kthread for each VM.
    
    E.g. in FaaS use cases, the guest kernel is trusted and the host may
    create 100+ VMs per logical CPU, which can result in 100ms+ latencies when
    a burst of VMs is created.
    
    Reported-by: Li RongQing <lirongqing@baidu.com>
    Closes: https://lore.kernel.org/all/1679555884-32544-1-git-send-email-lirongqing@baidu.com
    Cc: Yong He <zhuangel570@gmail.com>
    Cc: Robert Hoo <robert.hoo.linux@gmail.com>
    Cc: Kai Huang <kai.huang@intel.com>
    Reviewed-by: Robert Hoo <robert.hoo.linux@gmail.com>
    Acked-by: Kai Huang <kai.huang@intel.com>
    Tested-by: Luiz Capitulino <luizcap@amazon.com>
    Reviewed-by: Li RongQing <lirongqing@baidu.com>
    Link: https://lore.kernel.org/r/20230602005859.784190-1-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Luiz Capitulino <luizcap@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false [+ + +]
Author: Marek Behún <kabel@kernel.org>
Date:   Tue Aug 1 17:16:23 2023 +0200

    leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false
    
    [ Upstream commit c3f853184bed04105682383c2971798c572226b5 ]
    
    At the time we call
        BUG_ON(props.color == LED_COLOR_ID_MULTI);
    the props variable is still initialized to zero.
    
    Call the BUG_ON only after we parse fwnode into props.
    
    Fixes: 77dce3a22e89 ("leds: disallow /sys/class/leds/*:multi:* for now")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Link: https://lore.kernel.org/r/20230801151623.30387-1-kabel@kernel.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

leds: multicolor: Use rounded division when calculating color components [+ + +]
Author: Marek Behún <kabel@kernel.org>
Date:   Tue Aug 1 14:49:31 2023 +0200

    leds: multicolor: Use rounded division when calculating color components
    
    [ Upstream commit 065d099f1be58187e6629273c50b948a02b7e1bf ]
    
    Given channel intensity, LED brightness and max LED brightness, the
    multicolor LED framework helper led_mc_calc_color_components() computes
    the color channel brightness as
    
        chan_brightness = brightness * chan_intensity / max_brightness
    
    Consider the situation when (brightness, intensity, max_brightness) is
    for example (16, 15, 255), then chan_brightness is computed to 0
    although the fractional divison would give 0.94, which should be rounded
    to 1.
    
    Use DIV_ROUND_CLOSEST here for the division to give more realistic
    component computation:
    
        chan_brightness = DIV_ROUND_CLOSEST(brightness * chan_intensity,
                                            max_brightness)
    
    Fixes: 55d5d3b46b08 ("leds: multicolor: Introduce a multicolor class definition")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Link: https://lore.kernel.org/r/20230801124931.8661-1-kabel@kernel.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

leds: pwm: Fix error code in led_pwm_create_fwnode() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Jul 11 09:13:34 2023 +0300

    leds: pwm: Fix error code in led_pwm_create_fwnode()
    
    [ Upstream commit cadb2de2a7fd9e955381307de3eddfcc386c208e ]
    
    Negative -EINVAL was intended, not positive EINVAL.  Fix it.
    
    Fixes: 95138e01275e ("leds: pwm: Make error handling more robust")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/a33b981a-b2c4-4dc2-b00a-626a090d2f11@moroto.mountain
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead [+ + +]
Author: Marek Behún <kabel@kernel.org>
Date:   Wed Aug 2 11:07:53 2023 +0200

    leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead
    
    [ Upstream commit 730094577e0c37e1bc40be37cbd41f71b0a8a2a4 ]
    
    The tty LED trigger uses the obsolete LED_ON & LED_OFF constants when
    setting LED brightness. This is bad because the LED_ON constant is equal
    to 1, and so when activating the tty LED trigger on a LED class device
    with max_brightness greater than 1, the LED is dimmer than it can be
    (when max_brightness is 255, the LED is very dimm indeed; some devices
    translate 1/255 to 0, so the LED is OFF all the time).
    
    Instead of directly setting brightness to a specific value, use the
    led_blink_set_oneshot() function from LED core to configure the blink.
    This function takes the current configured brightness as blink
    brightness if not zero, and max brightness otherwise.
    
    This also changes the behavior of the TTY LED trigger. Previously if
    rx/tx stats kept changing, the LED was ON all the time they kept
    changing. With this patch the LED will blink on TTY activity.
    
    Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Link: https://lore.kernel.org/r/20230802090753.13611-1-kabel@kernel.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libbpf: Fix realloc API handling in zero-sized edge cases [+ + +]
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Mon Jul 10 19:41:50 2023 -0700

    libbpf: Fix realloc API handling in zero-sized edge cases
    
    [ Upstream commit 8a0260dbf6553c969248b6530cafadac46562f47 ]
    
    realloc() and reallocarray() can either return NULL or a special
    non-NULL pointer, if their size argument is zero. This requires a bit
    more care to handle NULL-as-valid-result situation differently from
    NULL-as-error case. This has caused real issues before ([0]), and just
    recently bit again in production when performing bpf_program__attach_usdt().
    
    This patch fixes 4 places that do or potentially could suffer from this
    mishandling of NULL, including the reported USDT-related one.
    
    There are many other places where realloc()/reallocarray() is used and
    NULL is always treated as an error value, but all those have guarantees
    that their size is always non-zero, so those spot don't need any extra
    handling.
    
      [0] d08ab82f59d5 ("libbpf: Fix double-free when linker processes empty sections")
    
    Fixes: 999783c8bbda ("libbpf: Wire up spec management and other arch-independent USDT logic")
    Fixes: b63b3c490eee ("libbpf: Add bpf_program__set_insns function")
    Fixes: 697f104db8a6 ("libbpf: Support custom SEC() handlers")
    Fixes: b12688267280 ("libbpf: Change the order of data and text relocations.")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20230711024150.1566433-1-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

libbpf: only reset sec_def handler when necessary [+ + +]
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Fri Jul 7 16:11:56 2023 -0700

    libbpf: only reset sec_def handler when necessary
    
    [ Upstream commit c628747cc8800cf6d33d09f7f42c8b6f91e64dc7 ]
    
    Don't reset recorded sec_def handler unconditionally on
    bpf_program__set_type(). There are two situations where this is wrong.
    
    First, if the program type didn't actually change. In that case original
    SEC handler should work just fine.
    
    Second, catch-all custom SEC handler is supposed to work with any BPF
    program type and SEC() annotation, so it also doesn't make sense to
    reset that.
    
    This patch fixes both issues. This was reported recently in the context
    of breaking perf tool, which uses custom catch-all handler for fancy BPF
    prologue generation logic. This patch should fix the issue.
    
      [0] https://lore.kernel.org/linux-perf-users/ab865e6d-06c5-078e-e404-7f90686db50d@amd.com/
    
    Fixes: d6e6286a12e7 ("libbpf: disassociate section handler on explicit bpf_program__set_type() call")
    Reported-by: Ravi Bangoria <ravi.bangoria@amd.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/r/20230707231156.1711948-1-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.4.16 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 13 09:48:45 2023 +0200

    Linux 6.4.16
    
    Link: https://lore.kernel.org/r/20230911134650.286315610@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
locking/arch: Avoid variable shadowing in local_try_cmpxchg() [+ + +]
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Sat Jul 8 11:00:36 2023 +0200

    locking/arch: Avoid variable shadowing in local_try_cmpxchg()
    
    [ Upstream commit d6b45484c130f4095313ae3edeb4aae662c12fb1 ]
    
    Several architectures define arch_try_local_cmpxchg macro using
    internal temporary variables named ___old, __old or _old. Remove
    temporary varible in local_try_cmpxchg to avoid variable shadowing.
    
    No functional change intended.
    
    Fixes: d994f2c8e241 ("locking/arch: Wire up local_try_cmpxchg()")
    Closes: https://lore.kernel.org/lkml/CAFGhKbyxtuk=LoW-E3yLXgcmR93m+Dfo5-u9oQA_YC5Fcy_t9g@mail.gmail.com/
    Reported-by: Charlemagne Lasse <charlemagnelasse@gmail.com>
    Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20230708090048.63046-1-ubizjak@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
LoongArch: Ensure FP/SIMD registers in the core dump file is up to date [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Sat Aug 26 22:21:57 2023 +0800

    LoongArch: Ensure FP/SIMD registers in the core dump file is up to date
    
    [ Upstream commit 656f9aec07dba7c61d469727494a5d1b18d0bef4 ]
    
    This is a port of commit 379eb01c21795edb4c ("riscv: Ensure the value
    of FP registers in the core dump file is up to date").
    
    The values of FP/SIMD registers in the core dump file come from the
    thread.fpu. However, kernel saves the FP/SIMD registers only before
    scheduling out the process. If no process switch happens during the
    exception handling, kernel will not have a chance to save the latest
    values of FP/SIMD registers. So it may cause their values in the core
    dump file incorrect. To solve this problem, force fpr_get()/simd_get()
    to save the FP/SIMD registers into the thread.fpu if the target task
    equals the current task.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

LoongArch: Fix CMDLINE_EXTEND and CMDLINE_BOOTLOADER handling [+ + +]
Author: Zhihong Dong <donmor3000@hotmail.com>
Date:   Fri Jul 28 10:30:42 2023 +0800

    LoongArch: Fix CMDLINE_EXTEND and CMDLINE_BOOTLOADER handling
    
    [ Upstream commit 83da30d73b86ab5898fb84f8b49c11557c3fcc67 ]
    
    On FDT systems these command line processing are already taken care of
    by early_init_dt_scan_chosen(). Add similar handling to the ACPI (non-
    FDT) code path to allow these config options to work for ACPI (non-FDT)
    systems too.
    
    Signed-off-by: Zhihong Dong <donmor3000@hotmail.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

LoongArch: mm: Add p?d_leaf() definitions [+ + +]
Author: Hongchen Zhang <zhanghongchen@loongson.cn>
Date:   Wed Sep 6 22:53:09 2023 +0800

    LoongArch: mm: Add p?d_leaf() definitions
    
    commit 303be4b33562a5b689261ced1616bf16ad49efa7 upstream.
    
    When I do LTP test, LTP test case ksm06 caused panic at
            break_ksm_pmd_entry
              -> pmd_leaf (Huge page table but False)
              -> pte_present (panic)
    
    The reason is pmd_leaf() is not defined, So like commit 501b81046701
    ("mips: mm: add p?d_leaf() definitions") add p?d_leaf() definition for
    LoongArch.
    
    Fixes: 09cfefb7fa70 ("LoongArch: Add memory management")
    Cc: stable@vger.kernel.org
    Acked-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

LoongArch: Only fiddle with CHECKFLAGS if `need-compiler' [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Jul 28 10:30:42 2023 +0800

    LoongArch: Only fiddle with CHECKFLAGS if `need-compiler'
    
    [ Upstream commit 54c2c9df083fe1d4a9df54d9876f32582ce6d77a ]
    
    This is a port of commit 4fe4a6374c4db9ae2b ("MIPS: Only fiddle with
    CHECKFLAGS if `need-compiler'") to LoongArch.
    
    We have originally guarded fiddling with CHECKFLAGS in our arch Makefile
    by checking for the CONFIG_LOONGARCH variable, not set for targets such
    as `distclean', etc. that neither include `.config' nor use the compiler.
    
    Starting from commit 805b2e1d427aab4 ("kbuild: include Makefile.compiler
    only when compiler is needed") we have had a generic `need-compiler'
    variable explicitly telling us if the compiler will be used and thus its
    capabilities need to be checked and expressed in the form of compilation
    flags.  If this variable is not set, then `make' functions such as
    `cc-option' are undefined, causing all kinds of weirdness to happen if
    we expect specific results to be returned.
    
    It doesn't cause problems on LoongArch now. But as a guard we replace
    the check for CONFIG_LOONGARCH with one for `need-compiler' instead, so
    as to prevent the compiler from being ever called for CHECKFLAGS when
    not needed.
    
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
lwt: Check LWTUNNEL_XMIT_CONTINUE strictly [+ + +]
Author: Yan Zhai <yan@cloudflare.com>
Date:   Thu Aug 17 19:58:14 2023 -0700

    lwt: Check LWTUNNEL_XMIT_CONTINUE strictly
    
    [ Upstream commit a171fbec88a2c730b108c7147ac5e7b2f5a02b47 ]
    
    LWTUNNEL_XMIT_CONTINUE is implicitly assumed in ip(6)_finish_output2,
    such that any positive return value from a xmit hook could cause
    unexpected continue behavior, despite that related skb may have been
    freed. This could be error-prone for future xmit hook ops. One of the
    possible errors is to return statuses of dst_output directly.
    
    To make the code safer, redefine LWTUNNEL_XMIT_CONTINUE value to
    distinguish from dst_output statuses and check the continue
    condition explicitly.
    
    Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure")
    Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Yan Zhai <yan@cloudflare.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/96b939b85eda00e8df4f7c080f770970a4c5f698.1692326837.git.yan@cloudflare.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

lwt: Fix return values of BPF xmit ops [+ + +]
Author: Yan Zhai <yan@cloudflare.com>
Date:   Thu Aug 17 19:58:11 2023 -0700

    lwt: Fix return values of BPF xmit ops
    
    [ Upstream commit 29b22badb7a84b783e3a4fffca16f7768fb31205 ]
    
    BPF encap ops can return different types of positive values, such like
    NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function
    skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return
    values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in
    ip(6)_finish_output2. When this happens, skbs that have been freed would
    continue to the neighbor subsystem, causing use-after-free bug and
    kernel crashes.
    
    To fix the incorrect behavior, skb_do_redirect return values can be
    simply discarded, the same as tc-egress behavior. On the other hand,
    bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU
    information. Thus convert its return values to avoid the conflict with
    LWTUNNEL_XMIT_CONTINUE.
    
    Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure")
    Reported-by: Jordan Griege <jgriege@cloudflare.com>
    Suggested-by: Martin KaFai Lau <martin.lau@linux.dev>
    Suggested-by: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: Yan Zhai <yan@cloudflare.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/0d2b878186cfe215fec6b45769c1cd0591d3628d.1692326837.git.yan@cloudflare.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
m68k: Fix invalid .section syntax [+ + +]
Author: Ben Hutchings <benh@debian.org>
Date:   Fri Jun 16 17:36:10 2023 +0200

    m68k: Fix invalid .section syntax
    
    [ Upstream commit 922a9bd138101e3e5718f0f4d40dba68ef89bb43 ]
    
    gas supports several different forms for .section for ELF targets,
    including:
        .section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]]
    and:
        .section "NAME"[, #FLAGS...]
    
    In several places we use a mix of these two forms:
        .section NAME, #FLAGS...
    
    A current development snapshot of binutils (2.40.50.20230611) treats
    this mixed syntax as an error.
    
    Change to consistently use:
        .section NAME, "FLAGS"
    as is used elsewhere in the kernel.
    
    Link: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1
    Signed-off-by: Ben Hutchings <benh@debian.org>
    Tested-by: Jan-Benedict Glaw <jbglaw@lug-owl.de>
    Link: https://lore.kernel.org/r/ZIyBaueWT9jnTwRC@decadent.org.uk
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mac80211: make ieee80211_tx_info padding explicit [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jun 23 17:24:00 2023 +0200

    mac80211: make ieee80211_tx_info padding explicit
    
    [ Upstream commit a7a2ef0c4b3efbd7d6f3fabd87dbbc0b3f2de5af ]
    
    While looking at a bug, I got rather confused by the layout of the
    'status' field in ieee80211_tx_info. Apparently, the intention is that
    status_driver_data[] is used for driver specific data, and fills up the
    size of the union to 40 bytes, just like the other ones.
    
    This is indeed what actually happens, but only because of the
    combination of two mistakes:
    
     - "void *status_driver_data[18 / sizeof(void *)];" is intended
       to be 18 bytes long but is actually two bytes shorter because of
       rounding-down in the division, to a multiple of the pointer
       size (4 bytes or 8 bytes).
    
     - The other fields combined are intended to be 22 bytes long, but
       are actually 24 bytes because of padding in front of the
       unaligned tx_time member, and in front of the pointer array.
    
    The two mistakes cancel out. so the size ends up fine, but it seems
    more helpful to make this explicit, by having a multiple of 8 bytes
    in the size calculation and explicitly describing the padding.
    
    Fixes: ea5907db2a9cc ("mac80211: fix struct ieee80211_tx_info size")
    Fixes: 02219b3abca59 ("mac80211: add WMM admission control support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20230623152443.2296825-2-arnd@kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md/md-bitmap: hold 'reconfig_mutex' in backlog_store() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Jul 6 16:37:27 2023 +0800

    md/md-bitmap: hold 'reconfig_mutex' in backlog_store()
    
    [ Upstream commit 44abfa6a95df425c0660d56043020b67e6d93ab8 ]
    
    Several reasons why 'reconfig_mutex' should be held:
    
    1) rdev_for_each() is not safe to be called without the lock, because
       rdev can be removed concurrently.
    2) mddev_destroy_serial_pool() and mddev_create_serial_pool() should not
       be called concurrently.
    3) mddev_suspend() from mddev_destroy/create_serial_pool() should be
       protected by the lock.
    
    Fixes: 10c92fca636e ("md-bitmap: create and destroy wb_info_pool with the change of backlog")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20230706083727.608914-3-yukuai1@huaweicloud.com
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

md/md-bitmap: remove unnecessary local variable in backlog_store() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Jul 6 16:37:26 2023 +0800

    md/md-bitmap: remove unnecessary local variable in backlog_store()
    
    [ Upstream commit b4d129640f194ffc4cc64c3e97f98ae944c072e8 ]
    
    Local variable is definied first in the beginning of backlog_store(),
    there is no need to define it again.
    
    Fixes: 8c13ab115b57 ("md/bitmap: don't set max_write_behind if there is no write mostly device")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20230706083727.608914-2-yukuai1@huaweicloud.com
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md/raid0: Factor out helper for mapping and submitting a bio [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Aug 14 11:27:07 2023 +0200

    md/raid0: Factor out helper for mapping and submitting a bio
    
    [ Upstream commit af50e20afb401cc203bd2a9ff62ece0ae4976103 ]
    
    Factor out helper function for mapping and submitting a bio out of
    raid0_make_request(). We will use it later for submitting both parts of
    a split bio.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20230814092720.3931-1-jack@suse.cz
    Signed-off-by: Song Liu <song@kernel.org>
    Stable-dep-of: 319ff40a5427 ("md/raid0: Fix performance regression for large sequential writes")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

md/raid0: Fix performance regression for large sequential writes [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Aug 14 11:27:08 2023 +0200

    md/raid0: Fix performance regression for large sequential writes
    
    [ Upstream commit 319ff40a542736d67e5bce18635de35d0e7a0bff ]
    
    Commit f00d7c85be9e ("md/raid0: fix up bio splitting.") among other
    things changed how bio that needs to be split is submitted. Before this
    commit, we have split the bio, mapped and submitted each part. After
    this commit, we map only the first part of the split bio and submit the
    second part unmapped. Due to bio sorting in __submit_bio_noacct() this
    results in the following request ordering:
    
      9,0   18     1181     0.525037895 15995  Q  WS 1479315464 + 63392
    
      Split off chunk-sized (1024 sectors) request:
    
      9,0   18     1182     0.629019647 15995  X  WS 1479315464 / 1479316488
    
      Request is unaligned to the chunk so it's split in
      raid0_make_request().  This is the first part mapped and punted to
      bio_list:
    
      8,0   18     7053     0.629020455 15995  A  WS 739921928 + 1016 <- (9,0) 1479315464
    
      Now raid0_make_request() returns, second part is postponed on
      bio_list. __submit_bio_noacct() resorts the bio_list, mapped request
      is submitted to the underlying device:
    
      8,0   18     7054     0.629022782 15995  G  WS 739921928 + 1016
    
      Now we take another request from the bio_list which is the remainder
      of the original huge request. Split off another chunk-sized bit from
      it and the situation repeats:
    
      9,0   18     1183     0.629024499 15995  X  WS 1479316488 / 1479317512
      8,16  18     6998     0.629025110 15995  A  WS 739921928 + 1016 <- (9,0) 1479316488
      8,16  18     6999     0.629026728 15995  G  WS 739921928 + 1016
      ...
      9,0   18     1184     0.629032940 15995  X  WS 1479317512 / 1479318536 [libnetacq-write]
      8,0   18     7059     0.629033294 15995  A  WS 739922952 + 1016 <- (9,0) 1479317512
      8,0   18     7060     0.629033902 15995  G  WS 739922952 + 1016
      ...
    
      This repeats until we consume the whole original huge request. Now we
      finally get to processing the second parts of the split off requests
      (in reverse order):
    
      8,16  18     7181     0.629161384 15995  A  WS 739952640 + 8 <- (9,0) 1479377920
      8,0   18     7239     0.629162140 15995  A  WS 739952640 + 8 <- (9,0) 1479376896
      8,16  18     7186     0.629163881 15995  A  WS 739951616 + 8 <- (9,0) 1479375872
      8,0   18     7242     0.629164421 15995  A  WS 739951616 + 8 <- (9,0) 1479374848
      ...
    
    I guess it is obvious that this IO pattern is extremely inefficient way
    to perform sequential IO. It also makes bio_list to grow to rather long
    lengths.
    
    Change raid0_make_request() to map both parts of the split bio. Since we
    know we are provided with at most chunk-sized bios, we will always need
    to split the incoming bio at most once.
    
    Fixes: f00d7c85be9e ("md/raid0: fix up bio splitting.")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20230814092720.3931-2-jack@suse.cz
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md/raid10: factor out dereference_rdev_and_rrdev() [+ + +]
Author: Li Nan <linan122@huawei.com>
Date:   Sat Jul 1 16:05:28 2023 +0800

    md/raid10: factor out dereference_rdev_and_rrdev()
    
    [ Upstream commit b99f8fd2d91eb734f13098aa1cf337edaca454b7 ]
    
    Factor out a helper to get 'rdev' and 'replacement' from config->mirrors.
    Just to make code cleaner and prepare to fix the bug of io loss while
    'replacement' replace 'rdev'.
    
    There is no functional change.
    
    Signed-off-by: Li Nan <linan122@huawei.com>
    Link: https://lore.kernel.org/r/20230701080529.2684932-3-linan666@huaweicloud.com
    Signed-off-by: Song Liu <song@kernel.org>
    Stable-dep-of: 673643490b9a ("md/raid10: use dereference_rdev_and_rrdev() to get devices")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

md/raid10: use dereference_rdev_and_rrdev() to get devices [+ + +]
Author: Li Nan <linan122@huawei.com>
Date:   Sat Jul 1 16:05:29 2023 +0800

    md/raid10: use dereference_rdev_and_rrdev() to get devices
    
    [ Upstream commit 673643490b9a0eb3b25633abe604f62b8f63dba1 ]
    
    Commit 2ae6aaf76912 ("md/raid10: fix io loss while replacement replace
    rdev") reads replacement first to prevent io loss. However, there are same
    issue in wait_blocked_dev() and raid10_handle_discard(), too. Fix it by
    using dereference_rdev_and_rrdev() to get devices.
    
    Fixes: d30588b2731f ("md/raid10: improve raid10 discard request")
    Fixes: f2e7e269a752 ("md/raid10: pull the code that wait for blocked dev into one function")
    Signed-off-by: Li Nan <linan122@huawei.com>
    Link: https://lore.kernel.org/r/20230701080529.2684932-4-linan666@huaweicloud.com
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md/raid5-cache: fix a deadlock in r5l_exit_log() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat Jul 8 17:17:27 2023 +0800

    md/raid5-cache: fix a deadlock in r5l_exit_log()
    
    [ Upstream commit a705b11b358dee677aad80630e7608b2d5f56691 ]
    
    Commit b13015af94cf ("md/raid5-cache: Clear conf->log after finishing
    work") introduce a new problem:
    
    // caller hold reconfig_mutex
    r5l_exit_log
     flush_work(&log->disable_writeback_work)
                            r5c_disable_writeback_async
                             wait_event
                              /*
                               * conf->log is not NULL, and mddev_trylock()
                               * will fail, wait_event() can never pass.
                               */
     conf->log = NULL
    
    Fix this problem by setting 'config->log' to NULL before wake_up() as it
    used to be, so that wait_event() from r5c_disable_writeback_async() can
    exist. In the meantime, move forward md_unregister_thread() so that
    null-ptr-deref this commit fixed can still be fixed.
    
    Fixes: b13015af94cf ("md/raid5-cache: Clear conf->log after finishing work")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20230708091727.1417894-1-yukuai1@huaweicloud.com
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Aug 8 18:49:12 2023 +0800

    md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid()
    
    [ Upstream commit 0d0bd28c500173bfca78aa840f8f36d261ef1765 ]
    
    r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is
    empty, and then submit 'flush_bio', however, r5l_log_flush_endio()
    is clearing the list first and then clear the bio, which will cause
    null-ptr-deref:
    
    T1: submit flush io
    raid5d
     handle_active_stripes
      r5l_flush_stripe_to_raid
       // list is empty
       // add 'io_end_ios' to the list
       bio_init
       submit_bio
       // io1
    
    T2: io1 is done
    r5l_log_flush_endio
     list_splice_tail_init
     // clear the list
                            T3: submit new flush io
                            ...
                            r5l_flush_stripe_to_raid
                             // list is empty
                             // add 'io_end_ios' to the list
                             bio_init
     bio_uninit
     // clear bio->bi_blkg
                             submit_bio
                             // null-ptr-deref
    
    Fix this problem by clearing bio before clearing the list in
    r5l_log_flush_endio().
    
    Fixes: 0dd00cba99c3 ("raid5-cache: fully initialize flush_bio when needed")
    Reported-and-tested-by: Corey Hickey <bugfood-ml@fatooh.org>
    Closes: https://lore.kernel.org/all/cddd7213-3dfd-4ab7-a3ac-edd54d74a626@fatooh.org/
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: raid0: account for split bio in iostat accounting [+ + +]
Author: David Jeffery <djeffery@redhat.com>
Date:   Wed Aug 16 14:13:55 2023 -0400

    md: raid0: account for split bio in iostat accounting
    
    [ Upstream commit cc22b5407e9ca76adb7efeed843146510b1b72a5 ]
    
    When a bio is split by md raid0, the newly created bio will not be tracked
    by md for I/O accounting. Only the portion of I/O still assigned to the
    original bio which was reduced by the split will be accounted for. This
    results in md iostat data sometimes showing I/O values far below the actual
    amount of data being sent through md.
    
    md_account_bio() needs to be called for all bio generated by the bio split.
    
    A simple example of the issue was generated using a raid0 device on partitions
    to the same device. Since all raid0 I/O then goes to one device, it makes it
    easy to see a gap between the md device and its sd storage. Reading an lvm
    device on top of the md device, the iostat output (some 0 columns and extra
    devices removed to make the data more compact) was:
    
    Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read
    md2               0.00         0.00         0.00         0.00          0
    sde               0.00         0.00         0.00         0.00          0
    md2            1364.00    411496.00         0.00         0.00     411496
    sde            1734.00    646144.00         0.00         0.00     646144
    md2            1699.00    510680.00         0.00         0.00     510680
    sde            2155.00    802784.00         0.00         0.00     802784
    md2             803.00    241480.00         0.00         0.00     241480
    sde            1016.00    377888.00         0.00         0.00     377888
    md2               0.00         0.00         0.00         0.00          0
    sde               0.00         0.00         0.00         0.00          0
    
    I/O was generated doing large direct I/O reads (12M) with dd to a linear
    lvm volume on top of the 4 leg raid0 device.
    
    The md2 reads were showing as roughly 2/3 of the reads to the sde device
    containing all of md2's raid partitions. The sum of reads to sde was
    1826816 kB, which was the expected amount as it was the amount read by
    dd. With the patch, the total reads from md will match the reads from
    sde and be consistent with the amount of I/O generated.
    
    Fixes: 10764815ff47 ("md: add io accounting for raid0 and raid5")
    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20230816181433.13289-1-djeffery@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

md: restore 'noio_flag' for the last mddev_resume() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Wed Jun 28 09:29:31 2023 +0800

    md: restore 'noio_flag' for the last mddev_resume()
    
    [ Upstream commit e24ed04389f9619e0aaef615a8948633c182a8b0 ]
    
    memalloc_noio_save() is called for the first mddev_suspend(), and
    repeated mddev_suspend() only increase 'suspended'. However,
    memalloc_noio_restore() is also called for the first mddev_resume(),
    which means that memory reclaim will be enabled before the last
    mddev_resume() is called, while the array is still suspended.
    
    Fix this problem by restore 'noio_flag' for the last mddev_resume().
    
    Fixes: 78f57ef9d50a ("md: use memalloc scope APIs in mddev_suspend()/mddev_resume()")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20230628012931.88911-3-yukuai1@huaweicloud.com
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: ad5820: Drop unsupported ad5823 from i2c_ and of_device_id tables [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Jun 18 20:17:40 2023 +0200

    media: ad5820: Drop unsupported ad5823 from i2c_ and of_device_id tables
    
    [ Upstream commit f126ff7e4024f6704e6ec0d4137037568708a3c7 ]
    
    The supported ad5820 and ad5821 VCMs both use a single 16 bit register
    which is written by sending 2 bytes with the data directly after sending
    the i2c-client address.
    
    The ad5823 OTOH has a more typical i2c / smbus device setup with multiple
    8 bit registers where the first byte send after the i2c-client address is
    the register address and the actual data only starts from the second byte
    after the i2c-client address.
    
    The ad5823 i2c_ and of_device_id-s was added at the same time as
    the ad5821 ids with as rationale:
    
    """
    Some camera modules also refer that AD5823 is a replacement of AD5820:
    https://download.kamami.com/p564094-OV8865_DS.pdf
    """
    
    The AD5823 may be an electrical and functional replacement of the AD5820,
    but from a software pov it is not compatible at all and it is going to
    need its own driver, drop its id from the ad5820 driver.
    
    Fixes: b8bf73136bae ("media: ad5820: Add support for ad5821 and ad5823")
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Ricardo Ribalda Delgado <ribalda@kernel.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: add helper function to get id name [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Jun 13 17:14:08 2023 +0800

    media: amphion: add helper function to get id name
    
    [ Upstream commit 12cd8b8ac02525977b2e860a877add10e8ce7468 ]
    
    convert numbers into meaningful names,
    then it can improve the log readability
    
    Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: decoder support display delay for all formats [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Mon Jul 10 15:44:11 2023 +0800

    media: amphion: decoder support display delay for all formats
    
    [ Upstream commit b69713f502027150ecc08e663fa1804d78b3ef42 ]
    
    the firmware only support low latency mode for h264,
    but firmware will notify an event to driver
    when one frame is decoded,
    if V4L2_CID_MPEG_VIDEO_DEC_DISPLAY_DELAY_ENABLE is enabled,
    and V4L2_CID_MPEG_VIDEO_DEC_DISPLAY_DELAY is set to 0,
    driver can display the decoded frame immediately.
    
    Fixes: ffa331d9bf94 ("media: amphion: decoder implement display delay enable")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: ensure the bitops don't cross boundaries [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Jul 18 17:50:13 2023 +0800

    media: amphion: ensure the bitops don't cross boundaries
    
    [ Upstream commit 5bd28eae48589694ff4e5badb03bf75dae695b3f ]
    
    the supported_instance_count determine the instance index range,
    it shouldn't exceed the bits number of instance_mask,
    otherwise the bitops of instance_mask may cross boundaries
    
    Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: fix CHECKED_RETURN issues reported by coverity [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Jul 18 17:50:09 2023 +0800

    media: amphion: fix CHECKED_RETURN issues reported by coverity
    
    [ Upstream commit b237b058adbc7825da9c8f358f1ff3f0467d623a ]
    
    calling "vpu_cmd_send/vpu_get_buffer_state/vpu_session_alloc_fs"
    without checking return value
    
    Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: fix REVERSE_INULL issues reported by coverity [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Jul 18 17:50:10 2023 +0800

    media: amphion: fix REVERSE_INULL issues reported by coverity
    
    [ Upstream commit 79d3bafaecc13bccab1ebbd28a15e669c5a4cdaf ]
    
    null-checking of a pointor is suggested before dereferencing it
    
    Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: fix UNINIT issues reported by coverity [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Jul 18 17:50:11 2023 +0800

    media: amphion: fix UNINIT issues reported by coverity
    
    [ Upstream commit c224d0497a31ea2d173e1ea16af308945bff9037 ]
    
    using uninitialized value may introduce risk
    
    Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: fix UNUSED_VALUE issue reported by coverity [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Jul 18 17:50:12 2023 +0800

    media: amphion: fix UNUSED_VALUE issue reported by coverity
    
    [ Upstream commit cf6a06354989c41b536be8e094561ee16223cf1f ]
    
    assign value '-EINVAL' to ret, but the stored value is overwritten
    before it can be used
    
    Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: reinit vpu if reqbufs output 0 [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue Jun 13 15:48:46 2023 +0800

    media: amphion: reinit vpu if reqbufs output 0
    
    [ Upstream commit 73e3f09292a0492a3fe0f87a8170a74f12624c5e ]
    
    according to v4l2 stateful decoder document 4.5.1.3. State Machine,
    the state should change from seek to initialization
    if call VIDIOC_REQBUFS(OUTPUT, 0).
    
    so reinit the vpu decoder if reqbufs output 0
    
    Fixes: 6de8d628df6e ("media: amphion: add v4l2 m2m vpu decoder stateful driver")
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: amphion: use dev_err_probe [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Tue Jan 31 11:32:44 2023 +0100

    media: amphion: use dev_err_probe
    
    [ Upstream commit 517f088385e1b8015606143e6212cb30f8714070 ]
    
    This simplifies the code and silences -517 error messages. Also
    the reason is listed in /sys/kernel/debug/devices_deferred.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Reviewed-by: ming_qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cec: core: add adap_nb_transmit_canceled() callback [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Mon Jun 12 15:58:37 2023 +0200

    media: cec: core: add adap_nb_transmit_canceled() callback
    
    [ Upstream commit da53c36ddd3f118a525a04faa8c47ca471e6c467 ]
    
    A potential deadlock was found by Zheng Zhang with a local syzkaller
    instance.
    
    The problem is that when a non-blocking CEC transmit is canceled by calling
    cec_data_cancel, that in turn can call the high-level received() driver
    callback, which can call cec_transmit_msg() to transmit a new message.
    
    The cec_data_cancel() function is called with the adap->lock mutex held,
    and cec_transmit_msg() tries to take that same lock.
    
    The root cause is that the received() callback can either be used to pass
    on a received message (and then adap->lock is not held), or to report a
    canceled transmit (and then adap->lock is held).
    
    This is confusing, so create a new low-level adap_nb_transmit_canceled
    callback that reports back that a non-blocking transmit was canceled.
    
    And the received() callback is only called when a message is received,
    as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass
    on reply results") complicated matters.
    
    Reported-by: Zheng Zhang <zheng.zhang@email.ucr.edu>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cec: core: add adap_unconfigured() callback [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Mon Jun 12 15:58:38 2023 +0200

    media: cec: core: add adap_unconfigured() callback
    
    [ Upstream commit 948a77aaecf202f722cf2264025f9987e5bd5c26 ]
    
    The adap_configured() callback was called with the adap->lock mutex
    held if the 'configured' argument was false, and without the adap->lock
    mutex held if that argument was true.
    
    That was very confusing, and so split this up in a adap_unconfigured()
    callback and a high-level configured() callback.
    
    This also makes it easier to understand when the mutex is held: all
    low-level adap_* callbacks are called with the mutex held. All other
    callbacks are called without that mutex held.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: f1b57164305d ("media: cec: add optional adap_configured callback")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cx24120: Add retval check for cx24120_message_send() [+ + +]
Author: Daniil Dulov <d.dulov@aladdin.ru>
Date:   Fri Jun 2 01:55:01 2023 -0700

    media: cx24120: Add retval check for cx24120_message_send()
    
    [ Upstream commit 96002c0ac824e1773d3f706b1f92e2a9f2988047 ]
    
    If cx24120_message_send() returns error, we should keep local struct
    unchanged.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 5afc9a25be8d ("[media] Add support for TechniSat Skystar S2")
    Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dib7000p: Fix potential division by zero [+ + +]
Author: Daniil Dulov <d.dulov@aladdin.ru>
Date:   Fri Mar 24 06:38:32 2023 -0700

    media: dib7000p: Fix potential division by zero
    
    [ Upstream commit a1db7b2c5533fc67e2681eb5efc921a67bc7d5b8 ]
    
    Variable loopdiv can be assigned 0, then it is used as a denominator,
    without checking it for 0.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 713d54a8bd81 ("[media] DiB7090: add support for the dib7090 based")
    Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    [hverkuil: (bw != NULL) -> bw]
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: Documentation: Fix [GS]_ROUTING documentation [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Thu Jul 20 10:08:28 2023 +0200

    media: Documentation: Fix [GS]_ROUTING documentation
    
    [ Upstream commit 997a6b01cd97b74684728d5af6511c333f25957d ]
    
    Add mention that successful VIDIOC_SUBDEV_G_ROUTING call will update
    'num_routes' and remove mention about non-existing streams, which is
    incorrect.
    
    Fixes: ea73eda50813 ("media: Documentation: Add GS_ROUTING documentation")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon May 29 07:58:36 2023 +0200

    media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()
    
    [ Upstream commit ea9ef6c2e001c5dc94bee35ebd1c8a98621cf7b8 ]
    
    'read' is freed when it is known to be NULL, but not when a read error
    occurs.
    
    Revert the logic to avoid a small leak, should a m920x_read() call fail.
    
    Fixes: a2ab06d7c4d6 ("media: m920x: don't use stack on USB reads")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb: symbol fixup for dvb_attach() [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 8 10:20:36 2023 +0100

    media: dvb: symbol fixup for dvb_attach()
    
    commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
    
    In commit 9011e49d54dc ("modules: only allow symbol_get of
    EXPORT_SYMBOL_GPL modules") the use of symbol_get is properly restricted
    to GPL-only marked symbols.  This interacts oddly with the DVB logic
    which only uses dvb_attach() to load the dvb driver which then uses
    symbol_get().
    
    Fix this up by properly marking all of the dvb_attach attach symbols as
    EXPORT_SYMBOL_GPL().
    
    Fixes: 9011e49d54dc ("modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules")
    Cc: stable <stable@kernel.org>
    Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: linux-media@vger.kernel.org
    Cc: linux-modules@vger.kernel.org
    Acked-by: Luis Chamberlain <mcgrof@kernel.org>
    Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Link: https://lore.kernel.org/r/20230908092035.3815268-2-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: go7007: Remove redundant if statement [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Thu Jul 27 19:40:07 2023 +0200

    media: go7007: Remove redundant if statement
    
    [ Upstream commit f33cb49081da0ec5af0888f8ecbd566bd326eed1 ]
    
    The if statement that compares msgs[i].len != 3 is always false because
    it is in a code block where msg[i].len is equal to 3. The check is
    redundant and can be removed.
    
    As detected by cppcheck static analysis:
    drivers/media/usb/go7007/go7007-i2c.c:168:20: warning: Opposite inner
    'if' condition leads to a dead code block. [oppositeInnerCondition]
    
    Link: https://lore.kernel.org/linux-media/20230727174007.635572-1-colin.i.king@gmail.com
    
    Fixes: 866b8695d67e ("Staging: add the go7007 video driver")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: i2c: Add a camera sensor top level menu [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Jun 15 10:29:07 2023 +0200

    media: i2c: Add a camera sensor top level menu
    
    commit 7d3c7d2a2914e10bec3b9cdacdadb8e1f65f715a upstream.
    
    Select V4L2_FWNODE and VIDEO_V4L2_SUBDEV_API for all sensor drivers. This
    also adds the options to drivers that don't specifically need them, these
    are still seldom used drivers using old APIs. The upside is that these
    should now all compile --- many drivers have had missing dependencies.
    
    The "menu" is replaced by selectable "menuconfig" to select the needed
    V4L2_FWNODE and VIDEO_V4L2_SUBDEV_API options.
    
    Also select MEDIA_CONTROLLER which VIDEO_V4L2_SUBDEV_API effectively
    depends on, and add the I2C dependency to the menu.
    
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: stable@vger.kernel.org # for >= 6.1
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: ccs: Check rules is non-NULL [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Sat Jul 29 20:59:25 2023 +0200

    media: i2c: ccs: Check rules is non-NULL
    
    commit 607bcc4213d998d051541d8f10b5bbb7d546c0be upstream.
    
    Fix the following smatch warning:
    
    drivers/media/i2c/ccs/ccs-data.c:524 ccs_data_parse_rules() warn: address
    of NULL pointer 'rules'
    
    The CCS static data rule parser does not check an if rule has been
    obtained before checking for other rule types (which depend on the if
    rule). In practice this means parsing invalid CCS static data could lead
    to dereferencing a NULL pointer.
    
    Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
    Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library")
    Cc: stable@vger.kernel.org # for 5.11 and up
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: imx290: drop format param from imx290_ctrl_update [+ + +]
Author: Tommaso Merciai <tomm.merciai@gmail.com>
Date:   Tue Jun 13 10:07:34 2023 +0200

    media: i2c: imx290: drop format param from imx290_ctrl_update
    
    [ Upstream commit 9b4e0e7a570d222be5f5e0f914d3c4528eadeeb4 ]
    
    The format param actually is not used in imx290_ctrl_update
    function, let's drop this
    
    Fixes: bc35f9a21a55 ("media: i2c: imx290: Fix the pixel rate at 148.5Mpix/s")
    Signed-off-by: Tommaso Merciai <tomm.merciai@gmail.com>
    Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: i2c: rdacm21: Fix uninitialized value [+ + +]
Author: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Date:   Thu Aug 10 15:33:37 2023 +0200

    media: i2c: rdacm21: Fix uninitialized value
    
    [ Upstream commit 33c7ae8f49e3413c81e879e1fdfcea4c5516e37b ]
    
    Fix the following smatch warning:
    
    drivers/media/i2c/rdacm21.c:373 ov10640_check_id() error: uninitialized
    symbol 'val'.
    
    Initialize 'val' to 0 in the ov10640_check_id() function.
    
    Fixes: 2b821698dc73 ("media: i2c: rdacm21: Power up OV10640 before OV490")
    Reported-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: i2c: tvp5150: check return value of devm_kasprintf() [+ + +]
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Jun 15 12:30:30 2023 +0200

    media: i2c: tvp5150: check return value of devm_kasprintf()
    
    [ Upstream commit 26ce7054d804be73935b9268d6e0ecf2fbbc8aef ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory.
    Pointer could be NULL in case allocation fails. Check pointer validity.
    Identified with coccinelle (kmerr.cocci script).
    
    Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx-jpeg: Support to assign slot for encoder/decoder [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Tue May 30 09:16:30 2023 +0200

    media: imx-jpeg: Support to assign slot for encoder/decoder
    
    [ Upstream commit 53ebeea50599c1ed05277d7a57e331a34e6d6a82 ]
    
    imx jpeg encoder and decoder support 4 slots each,
    aim to support some virtualization scenarios.
    
    driver should only enable one slot one time.
    
    but due to some hardware issue,
    only slot 0 can be enabled in imx8q platform,
    and they may be fixed in imx9 platform.
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ipu-bridge: Do not use on stack memory for software_node.name field [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Jul 5 23:29:54 2023 +0200

    media: ipu-bridge: Do not use on stack memory for software_node.name field
    
    [ Upstream commit 11e0a7c8e04ee5f406f2baa27761746cbedcfa11 ]
    
    Commit 567f97bd381f ("media: ipu3-cio2: support multiple sensors and VCMs
    with same HID") introduced an on stack vcm_name and then uses this for
    the name field of the software_node struct used for the vcm.
    
    But the software_node struct is much longer lived then the current
    stack-frame, so this is no good.
    
    Instead extend the ipu_node_names struct with an extra field to store
    the vcm software_node name and use that.
    
    Note this also changes the length of the allocated buffer from
    ACPI_ID_LEN + 4 to 16. the name is filled with "<ipu_vcm_types[x]>-%u"
    where ipu_vcm_types[x] is not an ACPI_ID. The maximum length of
    the strings in the ipu_vcm_types[] array is 11 + 5 bytes for "-255\0"
    means 16 bytes are needed in the worst case scenario.
    
    Fixes: 567f97bd381f ("media: ipu3-cio2: support multiple sensors and VCMs with same HID")
    Cc: Bingbu Cao <bingbu.cao@intel.com>
    Reviewed-by: Andy Shevchenko <andy@kernel.org>
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Jul 5 23:29:53 2023 +0200

    media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings
    
    [ Upstream commit 284be5693163343e1cf17c03917eecd1d6681bcf ]
    
    When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run
    sensor->adev is not set yet.
    
    So if either of the dev_warn() calls about unknown values are hit this
    will lead to a NULL pointer deref.
    
    Set sensor->adev earlier, with a borrowed ref to avoid making unrolling
    on errors harder, to fix this.
    
    Fixes: 485aa3df0dff ("media: ipu3-cio2: Parse sensor orientation and rotation")
    Cc: Fabian Wüthrich <me@fabwu.ch>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ipu3-cio2: allow ipu_bridge to be a module again [+ + +]
Author: Arnd Bergmann <arnd@kernel.org>
Date:   Thu Jul 27 14:22:58 2023 +0200

    media: ipu3-cio2: allow ipu_bridge to be a module again
    
    commit 2545a2c02ba1da9cfb9ec218623c71b00eb4a555 upstream.
    
    This code was previously part of the VIDEO_IPU3_CIO2 driver, which could
    be built-in or a loadable module, but after the move it turned into a
    builtin-only driver. This fails to link when the I2C subsystem is a
    module:
    
    x86_64-linux-ld: drivers/media/pci/intel/ipu-bridge.o: in function `ipu_bridge_unregister_sensors':
    ipu-bridge.c:(.text+0x50): undefined reference to `i2c_unregister_device'
    x86_64-linux-ld: drivers/media/pci/intel/ipu-bridge.o: in function `ipu_bridge_init':
    ipu-bridge.c:(.text+0x9c9): undefined reference to `i2c_acpi_new_device_by_fwnode'
    
    In general, drivers should not have to be built-in, so change the option
    to a tristate with the corresponding dependency. This in turn opens a
    new problem with the dependency, as the IPU bridge can be a loadable module
    while the ipu3 driver itself is built-in, producing a new link failure:
    
    86_64-linux-ld: drivers/media/pci/intel/ipu3/ipu3-cio2.o: in function `cio2_pci_probe':
    ipu3-cio2.c:(.text+0x197e): undefined reference to `ipu_bridge_init'
    
    In order to fix this, restore the old Kconfig option that controlled
    the ipu bridge driver before it was split out, but make it select a
    hidden symbol that now corresponds to the bridge driver.
    
    When other drivers get added that share ipu-bridge, this should cover
    all corner cases, and allow any combination of them to be built-in
    or modular.
    
    Link: https://lore.kernel.org/linux-media/20230727122331.2421453-1-arnd@kernel.org
    
    Fixes: 881ca25978c6 ("media: ipu3-cio2: rename cio2 bridge to ipu bridge and move out of ipu3")'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: ipu3-cio2: rename cio2 bridge to ipu bridge and move out of ipu3 [+ + +]
Author: Bingbu Cao <bingbu.cao@intel.com>
Date:   Thu May 18 12:05:21 2023 +0200

    media: ipu3-cio2: rename cio2 bridge to ipu bridge and move out of ipu3
    
    [ Upstream commit 881ca25978c6f536a00205daa8b2452edd057ff9 ]
    
    cio2 bridge was involved along with IPU3. However, in fact all Intel IPUs
    besides IPU3 CIO2 need this bridge driver. This patch move bridge driver
    out of ipu3 directory and rename as ipu-bridge. Then it can be worked with
    IPU3 and other Intel IPUs.
    
    Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Stable-dep-of: 11e0a7c8e04e ("media: ipu-bridge: Do not use on stack memory for software_node.name field")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: mediatek: vcodec: fix potential double free [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Jun 14 16:05:39 2023 +0300

    media: mediatek: vcodec: fix potential double free
    
    [ Upstream commit be40f524b6edac4fb9a98ef79620fd9b9497a998 ]
    
    The "lat_buf->private_data" needs to be set to NULL to prevent a
    double free.  How this would happen is if vdec_msg_queue_init() failed
    twice in a row and on the second time it failed earlier than on the
    first time.
    
    The vdec_msg_queue_init() function has a loop which does:
            for (i = 0; i < NUM_BUFFER_COUNT; i++) {
    
    Each iteration initializes one element in the msg_queue->lat_buf[] array
    and then the clean up function vdec_msg_queue_deinit() frees each
    element of the msg_queue->lat_buf[] array.  This clean up code relies
    on the assumption that every element is either initialized or zeroed.
    Leaving a freed pointer which is non-zero breaks the assumption.
    
    Fixes: b199fe46f35c ("media: mtk-vcodec: Add msg queue feature for lat and core architecture")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Jun 14 16:06:47 2023 +0300

    media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init()
    
    [ Upstream commit cf10b0bb503c974ba049d6f888b21178be20a962 ]
    
    If we encounter any error in the vdec_msg_queue_init() then we need
    to set "msg_queue->wdma_addr.size = 0;".  Normally, this is done
    inside the vdec_msg_queue_deinit() function.  However, if the
    first call to allocate &msg_queue->wdma_addr fails, then the
    vdec_msg_queue_deinit() function is a no-op.  For that situation, just
    set the size to zero explicitly and return.
    
    There were two other error paths which did not clean up before returning.
    Change those error paths to goto mem_alloc_err.
    
    Fixes: b199fe46f35c ("media: mtk-vcodec: Add msg queue feature for lat and core architecture")
    Fixes: 2f5d0aef37c6 ("media: mediatek: vcodec: support stateless AV1 decoder")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: mediatek: vcodec: Return NULL if no vdec_fb is found [+ + +]
Author: Irui Wang <irui.wang@mediatek.com>
Date:   Wed Jul 5 17:14:41 2023 +0800

    media: mediatek: vcodec: Return NULL if no vdec_fb is found
    
    [ Upstream commit dfa2d6e07432270330ae191f50a0e70636a4cd2b ]
    
    "fb_use_list" is used to store used or referenced frame buffers for
    vp9 stateful decoder. "NULL" should be returned when getting target
    frame buffer failed from "fb_use_list", not a random unexpected one.
    
    Fixes: f77e89854b3e ("[media] vcodec: mediatek: Add Mediatek VP9 Video Decoder Driver")
    Signed-off-by: Irui Wang <irui.wang@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: mtk-jpeg: Fix use after free bug due to uncanceled work [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Fri Jul 7 17:24:14 2023 +0800

    media: mtk-jpeg: Fix use after free bug due to uncanceled work
    
    [ Upstream commit c677d7ae83141d390d1253abebafa49c962afb52 ]
    
    In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with
    mtk_jpeg_job_timeout_work. Then mtk_jpeg_dec_device_run
    and mtk_jpeg_enc_device_run may be called to start the
    work.
    If we remove the module which will call mtk_jpeg_remove
    to make cleanup, there may be a unfinished work. The
    possible sequence is as follows, which will cause a
    typical UAF bug.
    
    Fix it by canceling the work before cleanup in the mtk_jpeg_remove
    
    CPU0                  CPU1
    
                        |mtk_jpeg_job_timeout_work
    mtk_jpeg_remove     |
      v4l2_m2m_release  |
        kfree(m2m_dev); |
                        |
                        | v4l2_m2m_get_curr_priv
                        |   m2m_dev->curr_ctx //use
    Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: nxp: Fix wrong return pointer check in mxc_isi_crossbar_init() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Jul 25 21:00:24 2023 +0800

    media: nxp: Fix wrong return pointer check in mxc_isi_crossbar_init()
    
    commit 4b60db99babad0254129ddc58e0927ffa9e93e35 upstream.
    
    It should check 'xbar->inputs', when allocate memory for it.
    
    Cc: stable@vger.kernel.org
    Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: ov2680: Add ov2680_fill_format() helper function [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:21 2023 +0200

    media: ov2680: Add ov2680_fill_format() helper function
    
    [ Upstream commit 6d6849b2203f3244b575ba01d3e41ee19aa2cadf ]
    
    Add a ov2680_fill_format() helper function and use this everywhere were
    a v4l2_mbus_framefmt struct needs to be filled in so that the driver always
    fills it consistently.
    
    This is a preparation patch for fixing ov2680_set_fmt()
    which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in
    the passed in v4l2_mbus_framefmt struct.
    
    Note that for ov2680_init_cfg() this now simply always fills
    the try_fmt struct of the passed in sd_state. This is correct because
    ov2680_init_cfg() is never called with a NULL sd_state so the old
    sd_state check is not necessary.
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Don't take the lock for try_fmt calls [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:20 2023 +0200

    media: ov2680: Don't take the lock for try_fmt calls
    
    [ Upstream commit e521b9cc1a49de677f4fc65909ce4877fbf7b113 ]
    
    On ov2680_set_fmt() calls with format->which == V4L2_SUBDEV_FORMAT_TRY,
    ov2680_set_fmt() does not talk to the sensor.
    
    So in this case there is no need to lock the sensor->lock mutex or
    to check that the sensor is streaming.
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Fix ov2680_bayer_order() [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:17 2023 +0200

    media: ov2680: Fix ov2680_bayer_order()
    
    [ Upstream commit 50a7bad4e0a37d7018ab6fe843dd84bc6b2ecf72 ]
    
    The index into ov2680_hv_flip_bayer_order[] should be 0-3, but
    ov2680_bayer_order() was using 0 + BIT(2) + (BIT(2) << 1) as
    max index, while the intention was to use: 0 + 1 + 2 as max index.
    
    Fix the index calculation in ov2680_bayer_order(), while at it
    also just use the ctrl values rather then reading them back using
    a slow i2c-read transaction.
    
    This also allows making the function void, since there now are
    no more i2c-reads to error check.
    
    Note the check for the ctrls being NULL is there to allow
    adding an ov2680_fill_format() helper later, which will call
    ov2680_set_bayer_order() during probe() before the ctrls are created.
    
    [Sakari Ailus: Change all users of ov2680_set_bayer_order() here]
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Fix ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY not working [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:22 2023 +0200

    media: ov2680: Fix ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY not working
    
    [ Upstream commit c0e97a4b4f20639f74cd5809b42ba6cbf9736a7d ]
    
    ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY was getting
    the try_fmt v4l2_mbus_framefmt struct from the passed in sd_state
    and then storing the contents of that into the return by reference
    format->format struct.
    
    While the right thing to do would be filling format->format based on
    the just looked up mode and then store the results of that in
    sd_state->pads[0].try_fmt .
    
    Before the previous change introducing ov2680_fill_format() this
    resulted in ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY always
    returning the zero-ed out sd_state->pads[0].try_fmt in format->format
    breaking callers using this.
    
    After the introduction of ov2680_fill_format() which at least
    initializes sd_state->pads[0].try_fmt properly, format->format
    is now always being filled with the default 800x600 mode set by
    ov2680_init_cfg() independent of the actual requested mode.
    
    Move the filling of format->format with ov2680_fill_format() to
    before the if (which == V4L2_SUBDEV_FORMAT_TRY) and then store
    the filled in format->format in sd_state->pads[0].try_fmt to
    fix this.
    
    Note this removes the fmt local variable because IMHO having a local
    variable which points to a sub-struct of one of the function arguments
    just leads to confusion when reading the code.
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Fix regulators being left enabled on ov2680_power_on() errors [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:23 2023 +0200

    media: ov2680: Fix regulators being left enabled on ov2680_power_on() errors
    
    [ Upstream commit 84b4bd7e0d98166aa32fd470e672721190492eae ]
    
    When the ov2680_power_on() "sensor soft reset failed" path is hit during
    probe() the WARN() about putting an enabled regulator at
    drivers/regulator/core.c:2398 triggers 3 times (once for each regulator),
    filling dmesg with backtraces.
    
    Fix this by properly disabling the regulators on ov2680_power_on() errors.
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Fix vflip / hflip set functions [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:18 2023 +0200

    media: ov2680: Fix vflip / hflip set functions
    
    [ Upstream commit d5d08ad330c9ccebc5e066fda815423a290f48b0 ]
    
    ov2680_vflip_disable() / ov2680_hflip_disable() pass BIT(0) instead of
    0 as value to ov2680_mod_reg().
    
    While fixing this also:
    
    1. Stop having separate enable/disable functions for hflip / vflip
    2. Move the is_streaming check, which is unique to hflip / vflip
       into the ov2680_set_?flip() functions.
    
    for a nice code cleanup.
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Remove auto-gain and auto-exposure controls [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:16 2023 +0200

    media: ov2680: Remove auto-gain and auto-exposure controls
    
    [ Upstream commit 7b5a42e6ae71927359ea67a2c22570ba97fa4059 ]
    
    Quoting the OV2680 datasheet:
    
    "3.2 exposure and gain control
    
    In the OV2680, the exposure time and gain are set manually from an external
    controller. The OV2680 supports manual gain and exposure control only for
    normal applications, no auto mode."
    
    And indeed testing with the atomisp_ov2680 fork of ov2680.c has shown that
    auto-exposure and auto-gain do not work.
    
    Note that the code setting the auto-exposure flag was broken, callers
    of ov2680_exposure_set() were directly passing !!ctrls->auto_exp->val as
    "bool auto_exp" value, but ctrls->auto_exp is a menu control with:
    
    enum  v4l2_exposure_auto_type {
            V4L2_EXPOSURE_AUTO = 0,
            V4L2_EXPOSURE_MANUAL = 1,
            ...
    
    So instead of passing !!ctrls->auto_exp->val they should have been passing
    ctrls->auto_exp->val == V4L2_EXPOSURE_AUTO, iow the passed value was
    inverted of what it should have been.
    
    Also remove ov2680_g_volatile_ctrl() since without auto support the gain
    and exposure controls are not volatile.
    
    This also fixes the control values not being properly applied in
    ov2680_mode_set(). The 800x600 mode register-list also sets gain,
    exposure and vflip overriding the last set ctrl values.
    
    ov2680_mode_set() does call ov2680_gain_set() and ov2680_exposure_set()
    but did this before writing the mode register-list, so these values
    would still be overridden by the mode register-list.
    
    Add a v4l2_ctrl_handler_setup() call after writing the mode register-list
    to restore all ctrl values. Also remove the ctrls->gain->is_new check from
    ov2680_gain_set() so that the gain always gets restored properly.
    
    Last since ov2680_mode_set() now calls v4l2_ctrl_handler_setup(), remove
    the v4l2_ctrl_handler_setup() call after ov2680_mode_restore() since
    ov2680_mode_restore() calls ov2680_mode_set().
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Remove VIDEO_V4L2_SUBDEV_API ifdef-s [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 3 11:33:19 2023 +0200

    media: ov2680: Remove VIDEO_V4L2_SUBDEV_API ifdef-s
    
    [ Upstream commit 49c282d5a8c5f4d1d9088622bec792294c716010 ]
    
    VIDEO_V4L2_SUBDEV_API is now automatically selected in Kconfig
    for all sensor drivers. Remove the ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
    checks.
    
    This is a preparation patch for fixing ov2680_set_fmt()
    which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in
    the passed in v4l2_mbus_framefmt struct.
    
    Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov5640: Enable MIPI interface in ov5640_set_power_mipi() [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Wed Aug 2 16:47:25 2023 +0200

    media: ov5640: Enable MIPI interface in ov5640_set_power_mipi()
    
    [ Upstream commit 98cb72d3b9c5e03b10fa993752ecfcbd9c572d8c ]
    
    Set OV5640_REG_IO_MIPI_CTRL00 bit 2 to 1 instead of 0, since 1 means
    MIPI CSI2 interface, while 0 means CPI parallel interface.
    
    In the ov5640_set_power_mipi() the interface should obviously be set
    to MIPI CSI2 since this functions is used to power up the sensor when
    operated in MIPI CSI2 mode. The sensor should not be in CPI mode in
    that case.
    
    This fixes a corner case where capturing the first frame on i.MX8MN
    with CSI/ISI resulted in corrupted frame.
    
    Fixes: aa4bb8b8838f ("media: ov5640: Re-work MIPI startup sequence")
    Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Tested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> # [Test on imx6q]
    Signed-off-by: Marek Vasut <marex@denx.de>
    Tested-by: Jai Luthra <j-luthra@ti.com> # [Test on bplay, sk-am62]
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov5640: Fix initial RESETB state and annotate timings [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Tue Jul 25 00:21:16 2023 +0200

    media: ov5640: Fix initial RESETB state and annotate timings
    
    [ Upstream commit a210df337c5f5c2cd82f36c9dbb154ec63365c80 ]
    
    The initial state of RESETB input signal of OV5640 should be
    asserted, i.e. the sensor should be in reset. This is not the
    case, make it so.
    
    Since the subsequent assertion of RESETB signal is no longer
    necessary and the timing of the power sequencing could be
    slightly adjusted, add annotations to the delays which match
    OV5640 datasheet rev. 2.03, both:
      figure 2-3 power up timing with internal DVDD
      figure 2-4 power up timing with external DVDD source
    
    The 5..10ms delay between PWDN assertion and RESETB assertion
    is not even documented in the power sequencing diagram, and
    with this reset fix, it is no longer even necessary.
    
    Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver")
    Reported-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Tested-by: Jai Luthra <j-luthra@ti.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov5640: fix low resolution image abnormal issue [+ + +]
Author: Guoniu.zhou <guoniu.zhou@nxp.com>
Date:   Mon Jun 12 04:43:40 2023 +0200

    media: ov5640: fix low resolution image abnormal issue
    
    [ Upstream commit a828002f38c5ee49d3f0c0e64c0f0caa1aec8dc2 ]
    
    OV5640 will output abnormal image data when work at low resolution
    (320x240, 176x144 and 160x120) after switching from high resolution,
    such as 1080P, the time interval between high and low switching must
    be less than 1000ms in order to OV5640 don't enter suspend state during
    the time.
    
    The reason is by 0x3824 value don't restore to initialize value when
    do resolution switching. In high resolution setting array, 0x3824 is
    set to 0x04, but low resolution setting array remove 0x3824 in commit
    db15c1957a2d ("media: ov5640: Remove duplicated mode settings"). So
    when do resolution switching from high to low, such as 1080P to 320x240,
    and the time interval is less than auto suspend delay time which means
    global initialize setting array will not be loaded, the output image
    data are abnormal. Hence move 0x3824 from ov5640_init_setting[] table
    to ov5640_setting_low_res[] table and also move 0x4407 0x460b, 0x460c
    to avoid same issue.
    
    Fixes: db15c1957a2d ("media: ov5640: Remove duplicated mode settings")
    Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
    Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: pci: cx23885: fix error handling for cx23885 ATSC boards [+ + +]
Author: Nikolay Burykin <burikin@ivk.ru>
Date:   Tue Jan 10 10:09:00 2023 +0100

    media: pci: cx23885: fix error handling for cx23885 ATSC boards
    
    [ Upstream commit 4aaa96b59df5fac41ba891969df6b092061ea9d7 ]
    
    After having been assigned to NULL value at cx23885-dvb.c:1202,
    pointer '0' is dereferenced at cx23885-dvb.c:2469.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Nikolay Burykin <burikin@ivk.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: pulse8-cec: handle possible ping error [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Tue Jun 6 06:38:15 2023 +0200

    media: pulse8-cec: handle possible ping error
    
    [ Upstream commit 92cbf865ea2e0f2997ff97815c6db182eb23df1b ]
    
    Handle (and warn about) possible error waiting for MSGCODE_PING result.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: rkvdec: increase max supported height for H.264 [+ + +]
Author: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Date:   Mon Jul 17 17:06:11 2023 +0200

    media: rkvdec: increase max supported height for H.264
    
    [ Upstream commit f000e6ca2d60fefd02a180a57df2c4162fa0c1b7 ]
    
    After testing it is possible for the hardware to decode H264
    bistream with a height up to 2560.
    
    Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
    Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver")
    Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: v4l2-core: Fix a potential resource leak in v4l2_fwnode_parse_link() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jun 14 20:31:05 2023 +0200

    media: v4l2-core: Fix a potential resource leak in v4l2_fwnode_parse_link()
    
    [ Upstream commit d7b13edd4cb4bfa335b6008ab867ac28582d3e5c ]
    
    If fwnode_graph_get_remote_endpoint() fails, 'fwnode' is known to be NULL,
    so fwnode_handle_put() is a no-op.
    
    Release the reference taken from a previous fwnode_graph_get_port_parent()
    call instead.
    
    Also handle fwnode_graph_get_port_parent() failures.
    
    In order to fix these issues, add an error handling path to the function
    and the needed gotos.
    
    Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: venus: hfi_venus: Only consider sys_idle_indicator on V1 [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue May 30 14:30:35 2023 +0200

    media: venus: hfi_venus: Only consider sys_idle_indicator on V1
    
    [ Upstream commit 6283e4834c69fa93a108efa18c6aa09c7e626f49 ]
    
    As per information from Qualcomm [1], this property is not really
    supported beyond msm8916 (HFI V1) and some newer HFI versions really
    dislike receiving it, going as far as crashing the device.
    
    Only consider toggling it (via the module option) on HFIV1.
    While at it, get rid of the global static variable (which defaulted
    to zero) which was never explicitly assigned to for V1.
    
    Note: [1] is a reply to the actual message in question, as lore did not
    properly receive some of the emails..
    
    [1] https://lore.kernel.org/lkml/955cd520-3881-0c22-d818-13fe9a47e124@linaro.org/
    Fixes: 7ed9e0b3393c ("media: venus: hfi, vdec: v6 Add IS_V6() to existing IS_V4() if locations")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue May 30 14:30:36 2023 +0200

    media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts
    
    commit d74e481609808330b4625b3691cf01e1f56e255e upstream.
    
    The startup procedure shouldn't be started with interrupts masked, as that
    may entail silent failures.
    
    Kick off initialization only after the interrupts are unmasked.
    
    Cc: stable@vger.kernel.org # v4.12+
    Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: verisilicon: Fix TRY_FMT on encoder OUTPUT [+ + +]
Author: Michael Tretter <m.tretter@pengutronix.de>
Date:   Thu Jul 6 09:15:10 2023 +0200

    media: verisilicon: Fix TRY_FMT on encoder OUTPUT
    
    [ Upstream commit b3b4c9d3cb3bf8725a3ded26f7042b1a37f25333 ]
    
    Commit f100ce3bbd6a ("media: verisilicon: Fix crash when probing
    encoder") removed vpu_fmt from hantro_try_fmt(), since it was
    initialized from vpu_dst_fmt, which may not be initialized, when TRY_FMT
    is called. It was replaced by fmt, which is found using the pixelformat.
    
    For the encoder, this changed the fmt to contain the raw format instead
    of the coded format. The format constraints as of fmt->frmsize are only
    valid for the coded format and are 0 for the raw formats. Therefore, the
    size of a encoder OUTPUT device is constrained to 0 and the
    v4l2-compliance tests for G_FMT, TRY_FMT, and SET_FMT fail.
    
    Bring back vpu_fmt to use the coded format on an encoder OUTPUT device,
    but initialize it using the currently set pixelformat on dst_fmt, which
    is the coded format on an encoder.
    
    Fixes: f100ce3bbd6a ("media: verisilicon: Fix crash when probing encoder")
    Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2 [+ + +]
Author: Aleksa Sarai <cyphar@cyphar.com>
Date:   Mon Aug 14 18:40:58 2023 +1000

    memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2
    
    [ Upstream commit 202e14222fadb246dfdf182e67de1518e86a1e20 ]
    
    Given the difficulty of auditing all of userspace to figure out whether
    every memfd_create() user has switched to passing MFD_EXEC and
    MFD_NOEXEC_SEAL flags, it seems far less distruptive to make it possible
    for older programs that don't make use of executable memfds to run under
    vm.memfd_noexec=2.  Otherwise, a small dependency change can result in
    spurious errors.  For programs that don't use executable memfds, passing
    MFD_NOEXEC_SEAL is functionally a no-op and thus having the same
    
    In addition, every failure under vm.memfd_noexec=2 needs to print to the
    kernel log so that userspace can figure out where the error came from.
    The concerns about pr_warn_ratelimited() spam that caused the switch to
    pr_warn_once()[1,2] do not apply to the vm.memfd_noexec=2 case.
    
    This is a user-visible API change, but as it allows programs to do
    something that would be blocked before, and the sysctl itself was broken
    and recently released, it seems unlikely this will cause any issues.
    
    [1]: https://lore.kernel.org/Y5yS8wCnuYGLHMj4@x1n/
    [2]: https://lore.kernel.org/202212161233.85C9783FB@keescook/
    
    Link: https://lkml.kernel.org/r/20230814-memfd-vm-noexec-uapi-fixes-v2-2-7ff9e3e10ba6@cyphar.com
    Fixes: 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC")
    Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
    Cc: Dominique Martinet <asmadeus@codewreck.org>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Daniel Verkamp <dverkamp@chromium.org>
    Cc: Jeff Xu <jeffxu@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

memfd: improve userspace warnings for missing exec-related flags [+ + +]
Author: Aleksa Sarai <cyphar@cyphar.com>
Date:   Mon Aug 14 18:40:59 2023 +1000

    memfd: improve userspace warnings for missing exec-related flags
    
    [ Upstream commit 434ed3350f57c03a9654fe0619755cc137a58935 ]
    
    In order to incentivise userspace to switch to passing MFD_EXEC and
    MFD_NOEXEC_SEAL, we need to provide a warning on each attempt to call
    memfd_create() without the new flags.  pr_warn_once() is not useful
    because on most systems the one warning is burned up during the boot
    process (on my system, systemd does this within the first second of boot)
    and thus userspace will in practice never see the warnings to push them to
    switch to the new flags.
    
    The original patchset[1] used pr_warn_ratelimited(), however there were
    concerns about the degree of spam in the kernel log[2,3].  The resulting
    inability to detect every case was flagged as an issue at the time[4].
    
    While we could come up with an alternative rate-limiting scheme such as
    only outputting the message if vm.memfd_noexec has been modified, or only
    outputting the message once for a given task, these alternatives have
    downsides that don't make sense given how low-stakes a single kernel
    warning message is.  Switching to pr_info_ratelimited() instead should be
    fine -- it's possible some monitoring tool will be unhappy with a stream
    of warning-level messages but there's already plenty of info-level message
    spam in dmesg.
    
    [1]: https://lore.kernel.org/20221215001205.51969-4-jeffxu@google.com/
    [2]: https://lore.kernel.org/202212161233.85C9783FB@keescook/
    [3]: https://lore.kernel.org/Y5yS8wCnuYGLHMj4@x1n/
    [4]: https://lore.kernel.org/f185bb42-b29c-977e-312e-3349eea15383@linuxfoundation.org/
    
    Link: https://lkml.kernel.org/r/20230814-memfd-vm-noexec-uapi-fixes-v2-3-7ff9e3e10ba6@cyphar.com
    Fixes: 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC")
    Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Daniel Verkamp <dverkamp@chromium.org>
    Cc: Dominique Martinet <asmadeus@codewreck.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: fastrpc: Pass proper scm arguments for static process init [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Fri Aug 11 12:56:43 2023 +0100

    misc: fastrpc: Pass proper scm arguments for static process init
    
    commit fe6518d547fc52ba74201018dc9aeb364072ac78 upstream.
    
    Memory is allocated for dynamic loading when audio daemon is trying
    to attach to audioPD on DSP side. This memory is allocated from
    reserved CMA memory region and needs ownership assignment to
    new VMID in order to use it from audioPD.
    
    In the current implementation, arguments are not correctly passed
    to the scm call which might result in failure of dynamic loading
    on audioPD. Added changes to pass correct arguments during daemon
    attach request.
    
    Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd")
    Cc: stable <stable@kernel.org>
    Tested-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20230811115643.38578-4-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mlxsw: core_hwmon: Adjust module label names based on MTCAP sensor counter [+ + +]
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Thu Aug 24 15:43:10 2023 +0200

    mlxsw: core_hwmon: Adjust module label names based on MTCAP sensor counter
    
    [ Upstream commit 3fc134a07438055fc93ce1bbacf2702ddd09500c ]
    
    Transceiver module temperature sensors are indexed after ASIC and
    platform sensors. The current label printing method does not take this
    into account and simply prints the index of the transceiver module
    sensor.
    
    On new systems that have platform sensors this results in incorrect
    (shifted) transceiver module labels being printed:
    
    $ sensors
    [...]
    front panel 002:  +37.0°C  (crit = +70.0°C, emerg = +75.0°C)
    front panel 003:  +47.0°C  (crit = +70.0°C, emerg = +75.0°C)
    [...]
    
    Fix by taking the sensor count into account. After the fix:
    
    $ sensors
    [...]
    front panel 001:  +37.0°C  (crit = +70.0°C, emerg = +75.0°C)
    front panel 002:  +47.0°C  (crit = +70.0°C, emerg = +75.0°C)
    [...]
    
    Fixes: a53779de6a0e ("mlxsw: core: Add QSFP module temperature label attribute to hwmon")
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: i2c: Fix chunk size setting in output mailbox buffer [+ + +]
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Thu Aug 24 15:43:08 2023 +0200

    mlxsw: i2c: Fix chunk size setting in output mailbox buffer
    
    [ Upstream commit 146c7c330507c0384bf29d567186632bfe975927 ]
    
    The driver reads commands output from the output mailbox. If the size
    of the output mailbox is not a multiple of the transaction /
    block size, then the driver will not issue enough read transactions
    to read the entire output, which can result in driver initialization
    errors.
    
    Fix by determining the number of transactions using DIV_ROUND_UP().
    
    Fixes: 3029a693beda ("mlxsw: i2c: Allow flexible setting of I2C transactions size")
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: i2c: Limit single transaction buffer size [+ + +]
Author: Vadim Pasternak <vadimp@nvidia.com>
Date:   Thu Aug 24 15:43:09 2023 +0200

    mlxsw: i2c: Limit single transaction buffer size
    
    [ Upstream commit d7248f1cc835bd80e936dc5b2d94b149bdd0077d ]
    
    Maximum size of buffer is obtained from underlying I2C adapter and in
    case adapter allows I2C transaction buffer size greater than 100 bytes,
    transaction will fail due to firmware limitation.
    
    As a result driver will fail initialization.
    
    Limit the maximum size of transaction buffer by 100 bytes to fit to
    firmware.
    
    Remove unnecessary calculation:
    max_t(u16, MLXSW_I2C_BLK_DEF, quirk_size).
    This condition can not happened.
    
    Fixes: 3029a693beda ("mlxsw: i2c: Allow flexible setting of I2C transactions size")
    Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED [+ + +]
Author: Jeff Xu <jeffxu@google.com>
Date:   Wed Jul 5 06:33:14 2023 +0000

    mm/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED
    
    [ Upstream commit 72de259130229412ca49871e70ffaf17dc9fba98 ]
    
    Patch series "mm/memfd: fix sysctl MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED", v2.
    
    When sysctl vm.memfd_noexec is 2 (MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED),
    memfd_create(.., MFD_EXEC) should fail.
    
    This complies with how MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED is defined -
    "memfd_create() without MFD_NOEXEC_SEAL will be rejected"
    
    Thanks to Dominique Martinet <asmadeus@codewreck.org> who reported the bug.
    see [1] for context.
    
    [1] https://lore.kernel.org/linux-mm/CABi2SkXUX_QqTQ10Yx9bBUGpN1wByOi_=gZU6WEy5a8MaQY3Jw@mail.gmail.com/T/
    
    This patch (of 2):
    
    When vm.memfd_noexec is 2 (MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED),
    memfd_create(.., MFD_EXEC) should fail.
    
    This complies with how MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED is
    defined - "memfd_create() without MFD_NOEXEC_SEAL will be rejected"
    
    Link: https://lkml.kernel.org/r/20230705063315.3680666-1-jeffxu@google.com
    Link: https://lkml.kernel.org/r/20230705063315.3680666-2-jeffxu@google.com
    Fixes: 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC")
    Reported-by: Dominique Martinet <asmadeus@codewreck.org>
    Closes: https://lore.kernel.org/linux-mm/CABi2SkXUX_QqTQ10Yx9bBUGpN1wByOi_=gZU6WEy5a8MaQY3Jw@mail.gmail.com/T/
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202306301351.kkbSegQW-lkp@intel.com/
    Signed-off-by: Jeff Xu <jeffxu@google.com>
    Cc: Daniel Verkamp <dverkamp@chromium.org>
    Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 202e14222fad ("memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/vmalloc: add a safer version of find_vm_area() for debug [+ + +]
Author: Joel Fernandes (Google) <joel@joelfernandes.org>
Date:   Mon Sep 4 18:08:04 2023 +0000

    mm/vmalloc: add a safer version of find_vm_area() for debug
    
    commit 0818e739b5c061b0251c30152380600fb9b84c0c upstream.
    
    It is unsafe to dump vmalloc area information when trying to do so from
    some contexts.  Add a safer trylock version of the same function to do a
    best-effort VMA finding and use it from vmalloc_dump_obj().
    
    [applied test robot feedback on unused function fix.]
    [applied Uladzislau feedback on locking.]
    Link: https://lkml.kernel.org/r/20230904180806.1002832-1-joel@joelfernandes.org
    Fixes: 98f180837a89 ("mm: Make mem_dump_obj() handle vmalloc() memory")
    Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Reported-by: Zhen Lei <thunder.leizhen@huaweicloud.com>
    Cc: Paul E. McKenney <paulmck@kernel.org>
    Cc: Zqiang <qiang.zhang1211@gmail.com>
    Cc: <stable@vger.kernel.org>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: renesas_sdhi: register irqs before registering controller [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Jul 12 16:00:11 2023 +0200

    mmc: renesas_sdhi: register irqs before registering controller
    
    commit 74f45de394d979cc7770271f92fafa53e1ed3119 upstream.
    
    IRQs should be ready to serve when we call mmc_add_host() via
    tmio_mmc_host_probe(). To achieve that, ensure that all irqs are masked
    before registering the handlers.
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230712140011.18602-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: rawnand: brcmnand: Fix mtd oobsize [+ + +]
Author: William Zhang <william.zhang@broadcom.com>
Date:   Thu Jul 6 11:29:09 2023 -0700

    mtd: rawnand: brcmnand: Fix mtd oobsize
    
    [ Upstream commit 60177390fa061c62d156f4a546e3efd90df3c183 ]
    
    brcmnand controller can only access the flash spare area up to certain
    bytes based on the ECC level. It can be less than the actual flash spare
    area size. For example, for many NAND chip supporting ECC BCH-8, it has
    226 bytes spare area. But controller can only uses 218 bytes. So brcmand
    driver overrides the mtd oobsize with the controller's accessible spare
    area size. When the nand base driver utilizes the nand_device object, it
    resets the oobsize back to the actual flash spare aprea size from
    nand_memory_organization structure and controller may not able to access
    all the oob area as mtd advises.
    
    This change fixes the issue by overriding the oobsize in the
    nand_memory_organization structure to the controller's accessible spare
    area size.
    
    Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object")
    Signed-off-by: William Zhang <william.zhang@broadcom.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230706182909.79151-6-william.zhang@broadcom.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: rawnand: fsmc: handle clk prepare error in fsmc_nand_resume() [+ + +]
Author: Yi Yang <yiyang13@huawei.com>
Date:   Thu Aug 17 19:58:39 2023 +0800

    mtd: rawnand: fsmc: handle clk prepare error in fsmc_nand_resume()
    
    [ Upstream commit a5a88125d00612586e941ae13e7fcf36ba8f18a7 ]
    
    In fsmc_nand_resume(), the return value of clk_prepare_enable() should be
    checked since it might fail.
    
    Fixes: e25da1c07dfb ("mtd: fsmc_nand: Add clk_{un}prepare() support")
    Signed-off-by: Yi Yang <yiyang13@huawei.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230817115839.10192-1-yiyang13@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: spi-nor: Check bus width while setting QE bit [+ + +]
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Fri Aug 18 14:42:23 2023 +0800

    mtd: spi-nor: Check bus width while setting QE bit
    
    [ Upstream commit f01d8155a92e33cdaa85d20bfbe6c441907b3c1f ]
    
    spi_nor_write_16bit_sr_and_check() should also check if bus width is
    4 before setting QE bit.
    
    Fixes: 39d1e3340c73 ("mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()")
    Suggested-by: Michael Walle <michael@walle.cc>
    Suggested-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Reviewed-by: Michael Walle <michael@walle.cc>
    Link: https://lore.kernel.org/r/20230818064524.1229100-2-hsinyi@chromium.org
    Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Multi-gen LRU: fix per-zone reclaim [+ + +]
Author: Kalesh Singh <kaleshsingh@google.com>
Date:   Tue Aug 1 19:56:02 2023 -0700

    Multi-gen LRU: fix per-zone reclaim
    
    commit 669281ee7ef731fb5204df9d948669bf32a5e68d upstream.
    
    MGLRU has a LRU list for each zone for each type (anon/file) in each
    generation:
    
            long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
    
    The min_seq (oldest generation) can progress independently for each
    type but the max_seq (youngest generation) is shared for both anon and
    file. This is to maintain a common frame of reference.
    
    In order for eviction to advance the min_seq of a type, all the per-zone
    lists in the oldest generation of that type must be empty.
    
    The eviction logic only considers pages from eligible zones for
    eviction or promotion.
    
        scan_folios() {
            ...
            for (zone = sc->reclaim_idx; zone >= 0; zone--)  {
                ...
                sort_folio();       // Promote
                ...
                isolate_folio();    // Evict
            }
            ...
        }
    
    Consider the system has the movable zone configured and default 4
    generations. The current state of the system is as shown below
    (only illustrating one type for simplicity):
    
    Type: ANON
    
            Zone    DMA32     Normal    Movable    Device
    
            Gen 0       0          0        4GB         0
    
            Gen 1       0        1GB        1MB         0
    
            Gen 2     1MB        4GB        1MB         0
    
            Gen 3     1MB        1MB        1MB         0
    
    Now consider there is a GFP_KERNEL allocation request (eligible zone
    index <= Normal), evict_folios() will return without doing any work
    since there are no pages to scan in the eligible zones of the oldest
    generation. Reclaim won't make progress until triggered from a ZONE_MOVABLE
    allocation request; which may not happen soon if there is a lot of free
    memory in the movable zone. This can lead to OOM kills, although there
    is 1GB pages in the Normal zone of Gen 1 that we have not yet tried to
    reclaim.
    
    This issue is not seen in the conventional active/inactive LRU since
    there are no per-zone lists.
    
    If there are no (not enough) folios to scan in the eligible zones, move
    folios from ineligible zone (zone_index > reclaim_index) to the next
    generation. This allows for the progression of min_seq and reclaiming
    from the next generation (Gen 1).
    
    Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
    
    [1] https://github.com/raspberrypi/linux/issues/5395
    
    Link: https://lkml.kernel.org/r/20230802025606.346758-1-kaleshsingh@google.com
    Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
    Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
    Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
    Reported-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
    Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [mediatek]
    Tested-by: Charan Teja Kalla <quic_charante@quicinc.com>
    Cc: Yu Zhao <yuzhao@google.com>
    Cc: Barry Song <baohua@kernel.org>
    Cc: Brian Geffon <bgeffon@google.com>
    Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
    Cc: Matthias Brugger <matthias.bgg@gmail.com>
    Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
    Cc: Qi Zheng <zhengqi.arch@bytedance.com>
    Cc: Steven Barrett <steven@liquorix.net>
    Cc: Suleiman Souhlal <suleiman@google.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net-memcg: Fix scope of sockmem pressure indicators [+ + +]
Author: Abel Wu <wuyun.abel@bytedance.com>
Date:   Mon Aug 14 15:09:11 2023 +0800

    net-memcg: Fix scope of sockmem pressure indicators
    
    [ Upstream commit ac8a52962164a50e693fa021d3564d7745b83a7f ]
    
    Now there are two indicators of socket memory pressure sit inside
    struct mem_cgroup, socket_pressure and tcpmem_pressure, indicating
    memory reclaim pressure in memcg->memory and ->tcpmem respectively.
    
    When in legacy mode (cgroupv1), the socket memory is charged into
    ->tcpmem which is independent of ->memory, so socket_pressure has
    nothing to do with socket's pressure at all. Things could be worse
    by taking socket_pressure into consideration in legacy mode, as a
    pressure in ->memory can lead to premature reclamation/throttling
    in socket.
    
    While for the default mode (cgroupv2), the socket memory is charged
    into ->memory, and ->tcpmem/->tcpmem_pressure are simply not used.
    
    So {socket,tcpmem}_pressure are only used in default/legacy mode
    respectively for indicating socket memory pressure. This patch fixes
    the pieces of code that make mixed use of both.
    
    Fixes: 8e8ae645249b ("mm: memcontrol: hook up vmpressure to socket pressure")
    Signed-off-by: Abel Wu <wuyun.abel@bytedance.com>
    Acked-by: Shakeel Butt <shakeelb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Dynamic cyclecounter shift calculation for PTP free running clock [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Mon Aug 21 16:05:54 2023 -0700

    net/mlx5: Dynamic cyclecounter shift calculation for PTP free running clock
    
    [ Upstream commit 84a58e60038fa0366006977dba85eae16b2e3d78 ]
    
    Use a dynamic calculation to determine the shift value for the internal
    timer cyclecounter that will lead to the highest precision frequency
    adjustments. Previously used a constant for the shift value assuming all
    devices supported by the driver had a nominal frequency of 1GHz. However,
    there are devices that operate at different frequencies. The previous shift
    value constant would break the PHC functionality for those devices.
    
    Reported-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
    Closes: https://lore.kernel.org/netdev/20230815151507.3028503-1-vadfed@meta.com/
    Fixes: 6a4010927562 ("net/mlx5: Update cyclecounter shift value to improve ptp free running mode precision")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Tested-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Acked-by: Saeed Mahameed <saeedm@nvidia.com>
    Link: https://lore.kernel.org/r/20230821230554.236210-1-rrameshbabu@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Use RMW accessors for changing LNKCTL [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 15:04:59 2023 +0300

    net/mlx5: Use RMW accessors for changing LNKCTL
    
    [ Upstream commit 30de872537bda526664d7a20b646adfb3e7ce6e6 ]
    
    Don't assume that only the driver would be accessing LNKCTL of the upstream
    bridge. ASPM policy changes can trigger write to LNKCTL outside of driver's
    control.
    
    Use RMW capability accessors which do proper locking to avoid losing
    concurrent updates to the register value.
    
    Suggested-by: Lukas Wunner <lukas@wunner.de>
    Fixes: eabe8e5e88f5 ("net/mlx5: Handle sync reset now event")
    Link: https://lore.kernel.org/r/20230717120503.15276-8-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: sch_hfsc: Ensure inner classes have fsc curve [+ + +]
Author: Budimir Markovic <markovicbudimir@gmail.com>
Date:   Thu Aug 24 01:49:05 2023 -0700

    net/sched: sch_hfsc: Ensure inner classes have fsc curve
    
    [ Upstream commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f ]
    
    HFSC assumes that inner classes have an fsc curve, but it is currently
    possible for classes without an fsc curve to become parents. This leads
    to bugs including a use-after-free.
    
    Don't allow non-root classes without HFSC_FSC to become parents.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
    Signed-off-by: Budimir Markovic <markovicbudimir@gmail.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Link: https://lore.kernel.org/r/20230824084905.422-1-markovicbudimir@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: annotate data-races around sk->sk_lingertime [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Aug 19 04:06:46 2023 +0000

    net: annotate data-races around sk->sk_lingertime
    
    [ Upstream commit bc1fb82ae11753c5dec53c667a055dc37796dbd2 ]
    
    sk_getsockopt() runs locklessly. This means sk->sk_lingertime
    can be read while other threads are changing its value.
    
    Other reads also happen without socket lock being held,
    and must be annotated.
    
    Remove preprocessor logic using BITS_PER_LONG, compilers
    are smart enough to figure this by themselves.
    
    v2: fixed a clang W=1 (-Wtautological-constant-out-of-range-compare) warning
        (Jakub)
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: annotate data-races around sk->sk_{rcv|snd}timeo [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jul 28 15:03:12 2023 +0000

    net: annotate data-races around sk->sk_{rcv|snd}timeo
    
    [ Upstream commit 285975dd674258ccb33e77a1803e8f2015e67105 ]
    
    sk_getsockopt() runs without locks, we must add annotations
    to sk->sk_rcvtimeo and sk->sk_sndtimeo.
    
    In the future we might allow fetching these fields before
    we lock the socket in TCP fast path.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: arcnet: Do not call kfree_skb() under local_irq_disable() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Aug 24 14:43:36 2023 +0800

    net: arcnet: Do not call kfree_skb() under local_irq_disable()
    
    [ Upstream commit 786c96e92fb9e854cb8b0cb7399bb2fb28e15c4b ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with hardware interrupts being disabled.
    So replace kfree_skb() with dev_kfree_skb_irq() under
    local_irq_disable(). Compile tested only.
    
    Fixes: 05fcd31cc472 ("arcnet: add err_skb package for package status feedback")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: Avoid address overwrite in kernel_connect [+ + +]
Author: Jordan Rife <jrife@google.com>
Date:   Mon Aug 21 16:45:23 2023 -0500

    net: Avoid address overwrite in kernel_connect
    
    commit 0bdf399342c5acbd817c9098b6c7ed21f1974312 upstream.
    
    BPF programs that run on connect can rewrite the connect address. For
    the connect system call this isn't a problem, because a copy of the address
    is made when it is moved into kernel space. However, kernel_connect
    simply passes through the address it is given, so the caller may observe
    its address value unexpectedly change.
    
    A practical example where this is problematic is where NFS is combined
    with a system such as Cilium which implements BPF-based load balancing.
    A common pattern in software-defined storage systems is to have an NFS
    mount that connects to a persistent virtual IP which in turn maps to an
    ephemeral server IP. This is usually done to achieve high availability:
    if your server goes down you can quickly spin up a replacement and remap
    the virtual IP to that endpoint. With BPF-based load balancing, mounts
    will forget the virtual IP address when the address rewrite occurs
    because a pointer to the only copy of that address is passed down the
    stack. Server failover then breaks, because clients have forgotten the
    virtual IP address. Reconnects fail and mounts remain broken. This patch
    was tested by setting up a scenario like this and ensuring that NFS
    reconnects worked after applying the patch.
    
    Signed-off-by: Jordan Rife <jrife@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: deal with integer overflows in kmalloc_reserve() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Aug 31 18:37:50 2023 +0000

    net: deal with integer overflows in kmalloc_reserve()
    
    commit 915d975b2ffa58a14bfcf16fafe00c41315949ff upstream.
    
    Blamed commit changed:
        ptr = kmalloc(size);
        if (ptr)
          size = ksize(ptr);
    
    to:
        size = kmalloc_size_roundup(size);
        ptr = kmalloc(size);
    
    This allowed various crash as reported by syzbot [1]
    and Kyle Zeng.
    
    Problem is that if @size is bigger than 0x80000001,
    kmalloc_size_roundup(size) returns 2^32.
    
    kmalloc_reserve() uses a 32bit variable (obj_size),
    so 2^32 is truncated to 0.
    
    kmalloc(0) returns ZERO_SIZE_PTR which is not handled by
    skb allocations.
    
    Following trace can be triggered if a netdev->mtu is set
    close to 0x7fffffff
    
    We might in the future limit netdev->mtu to more sensible
    limit (like KMALLOC_MAX_SIZE).
    
    This patch is based on a syzbot report, and also a report
    and tentative fix from Kyle Zeng.
    
    [1]
    BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]
    BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
    Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554
    
    CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
    Call trace:
    dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279
    show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106
    print_report+0xe4/0x4b4 mm/kasan/report.c:398
    kasan_report+0x150/0x1ac mm/kasan/report.c:495
    kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189
    memset+0x40/0x70 mm/kasan/shadow.c:44
    __build_skb_around net/core/skbuff.c:294 [inline]
    __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
    alloc_skb include/linux/skbuff.h:1316 [inline]
    igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359
    add_grec+0x81c/0x1124 net/ipv4/igmp.c:534
    igmpv3_send_cr net/ipv4/igmp.c:667 [inline]
    igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810
    call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474
    expire_timers kernel/time/timer.c:1519 [inline]
    __run_timers+0x54c/0x710 kernel/time/timer.c:1790
    run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803
    _stext+0x380/0xfbc
    ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79
    call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891
    do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84
    invoke_softirq kernel/softirq.c:437 [inline]
    __irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683
    irq_exit_rcu+0x14/0x78 kernel/softirq.c:695
    el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717
    __el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724
    el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729
    el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584
    
    Fixes: 12d6c1d3a2ad ("skbuff: Proactively round up to kmalloc bucket size")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: dsa: microchip: KSZ9477 register regmap alignment to 32 bit boundaries [+ + +]
Author: Lukasz Majewski <lukma@denx.de>
Date:   Thu Jul 27 10:13:42 2023 +0200

    net: dsa: microchip: KSZ9477 register regmap alignment to 32 bit boundaries
    
    [ Upstream commit 8d7ae22ae9f8c8a4407f8e993df64440bdbd0cee ]
    
    The commit (SHA1: 5c844d57aa7894154e49cf2fc648bfe2f1aefc1c) provided code
    to apply "Module 6: Certain PHY registers must be written as pairs instead
    of singly" errata for KSZ9477 as this chip for certain PHY registers
    (0xN120 to 0xN13F, N=1,2,3,4,5) must be accesses as 32 bit words instead
    of 16 or 8 bit access.
    Otherwise, adjacent registers (no matter if reserved or not) are
    overwritten with 0x0.
    
    Without this patch some registers (e.g. 0x113c or 0x1134) required for 32
    bit access are out of valid regmap ranges.
    
    As a result, following error is observed and KSZ9477 is not properly
    configured:
    
    ksz-switch spi1.0: can't rmw 32bit reg 0x113c: -EIO
    ksz-switch spi1.0: can't rmw 32bit reg 0x1134: -EIO
    ksz-switch spi1.0 lan1 (uninitialized): failed to connect to PHY: -EIO
    ksz-switch spi1.0 lan1 (uninitialized): error -5 setting up PHY for tree 0, switch 0, port 0
    
    The solution is to modify regmap_reg_range to allow accesses with 4 bytes
    boundaries.
    
    Signed-off-by: Lukasz Majewski <lukma@denx.de>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: handle ARPHRD_PPP in dev_is_mac_header_xmit() [+ + +]
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Wed Aug 23 15:41:02 2023 +0200

    net: handle ARPHRD_PPP in dev_is_mac_header_xmit()
    
    commit a4f39c9f14a634e4cd35fcd338c239d11fcc73fc upstream.
    
    The goal is to support a bpf_redirect() from an ethernet device (ingress)
    to a ppp device (egress).
    The l2 header is added automatically by the ppp driver, thus the ethernet
    header should be removed.
    
    CC: stable@vger.kernel.org
    Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Tested-by: Siwar Zitouni <siwar.zitouni@6wind.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: hns3: add tm flush when setting tm [+ + +]
Author: Hao Lan <lanhao@huawei.com>
Date:   Thu Jul 20 10:05:08 2023 +0800

    net: hns3: add tm flush when setting tm
    
    [ Upstream commit 6d2336120aa6e1a8a64fa5d6ee5c3f3d0809fe9b ]
    
    When the tm module is configured with traffic, traffic
    may be abnormal. This patch fixes this problem.
    Before the tm module is configured, traffic processing
    should be stopped. After the tm module is configured,
    traffic processing is enabled.
    
    Signed-off-by: Hao Lan <lanhao@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: fix wrong rpu tln reg issue [+ + +]
Author: Jijie Shao <shaojijie@huawei.com>
Date:   Tue Aug 15 14:06:41 2023 +0800

    net: hns3: fix wrong rpu tln reg issue
    
    [ Upstream commit 36122201eeaefd78547def9681aa5d83b5a00b6a ]
    
    In the original RPU query command, the status register values of
    multiple RPU tunnels are accumulated by default, which is unreasonable.
    This patch Fix it by querying the specified tunnel ID.
    The tunnel number of the device can be obtained from firmware
    during initialization.
    
    Fixes: ddb54554fa51 ("net: hns3: add DFX registers information for ethtool -d")
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: move dump regs function to a separate file [+ + +]
Author: Jijie Shao <shaojijie@huawei.com>
Date:   Tue Aug 15 14:06:38 2023 +0800

    net: hns3: move dump regs function to a separate file
    
    [ Upstream commit 939ccd107ffcade20c9c7055a2e7ae0fd724fb72 ]
    
    The dump register function is being refactored.
    The first step in refactoring is put the dump regs function
    into a separate file.
    
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 36122201eeae ("net: hns3: fix wrong rpu tln reg issue")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: restore user pause configure when disable autoneg [+ + +]
Author: Jian Shen <shenjian15@huawei.com>
Date:   Mon Aug 7 19:34:49 2023 +0800

    net: hns3: restore user pause configure when disable autoneg
    
    [ Upstream commit 15159ec0c831b565820c2de05114ea1b4cf07681 ]
    
    Restore the mac pause state to user configuration when autoneg is disabled
    
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Peiyang Wang <wangpeiyang1@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/20230807113452.474224-2-shaojijie@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: Support tlv in regs data for HNS3 PF driver [+ + +]
Author: Jijie Shao <shaojijie@huawei.com>
Date:   Tue Aug 15 14:06:39 2023 +0800

    net: hns3: Support tlv in regs data for HNS3 PF driver
    
    [ Upstream commit d8634b7c3f62d265fc2ecf29286aa9c5b78f969f ]
    
    The dump register function is being refactored.
    The second step in refactoring is to support tlv info in regs data for
    HNS3 PF driver.
    
    Currently, if we use "ethtool -d" to dump regs value,
    the output is as follows:
      offset1: 00 01 02 03 04 05 ...
      offset2:10 11 12 13 14 15 ...
      ......
    
    We can't get the value of a register directly.
    
    This patch deletes the original separator information and
    add tag_len_value information in regs data.
    ethtool can parse register data in key-value format by -d command.
    
    a patch will be added to the ethtool to parse regs data
    in the following format:
      reg1 : value2
      reg2 : value2
      ......
    
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 36122201eeae ("net: hns3: fix wrong rpu tln reg issue")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: lan966x: Fix return value check for vcap_get_rule() [+ + +]
Author: Ruan Jinjie <ruanjinjie@huawei.com>
Date:   Fri Aug 18 13:05:04 2023 +0800

    net: lan966x: Fix return value check for vcap_get_rule()
    
    [ Upstream commit ab104318f63997113b0ce7ac288e51359925ed79 ]
    
    As Simon Horman suggests, update vcap_get_rule() to always
    return an ERR_PTR() and update the error detection conditions to
    use IS_ERR(), so use IS_ERR() to fix the return value issue.
    
    Fixes: 72df3489fb10 ("net: lan966x: Add ptp trap rules")
    Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
    Suggested-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sfp: handle 100G/25G active optical cables in sfp_parse_support [+ + +]
Author: Josua Mayer <josua@solid-run.com>
Date:   Fri Aug 18 13:05:56 2023 +0200

    net: sfp: handle 100G/25G active optical cables in sfp_parse_support
    
    [ Upstream commit db1a6ad77c180efc7242d7204b9a0c72c8a5a1bb ]
    
    Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC)
    for active optical cables supporting 25G and 100G speeds.
    
    Since the specification makes no statement about transmitter range, and
    as the specific sfp module that had been tested features only 2m fiber -
    short-range (SR) modes are selected.
    
    The 100G speed is irrelevant because it would require multiple fibers /
    multiple SFP28 modules combined under one netdev.
    sfp-bus.c only handles a single module per netdev, so only 25Gbps modes
    are selected.
    
    sfp_parse_support already handles SFF8024_ECC_100GBASE_SR4_25GBASE_SR
    with compatible properties, however that entry is a contradiction in
    itself since with SFP(28) 100GBASE_SR4 is impossible - that would likely
    be a mode for qsfp modules only.
    
    Add a case for SFF8024_ECC_100G_25GAUI_C2M_AOC selecting 25gbase-r
    interface mode and 25000baseSR link mode.
    Also enforce SFP28 bitrate limits on the values read from sfp eeprom as
    requested by Russell King.
    
    Tested with fs.com S28-AO02 AOC SFP28 module.
    
    Signed-off-by: Josua Mayer <josua@solid-run.com>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: tcp: fix unexcepted socket die when snd_wnd is 0 [+ + +]
Author: Menglong Dong <imagedong@tencent.com>
Date:   Fri Aug 11 10:55:29 2023 +0800

    net: tcp: fix unexcepted socket die when snd_wnd is 0
    
    [ Upstream commit e89688e3e97868451a5d05b38a9d2633d6785cd4 ]
    
    In tcp_retransmit_timer(), a window shrunk connection will be regarded
    as timeout if 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX'. This is not
    right all the time.
    
    The retransmits will become zero-window probes in tcp_retransmit_timer()
    if the 'snd_wnd==0'. Therefore, the icsk->icsk_rto will come up to
    TCP_RTO_MAX sooner or later.
    
    However, the timer can be delayed and be triggered after 122877ms, not
    TCP_RTO_MAX, as I tested.
    
    Therefore, 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX' is always true
    once the RTO come up to TCP_RTO_MAX, and the socket will die.
    
    Fix this by replacing the 'tcp_jiffies32' with '(u32)icsk->icsk_timeout',
    which is exact the timestamp of the timeout.
    
    However, "tp->rcv_tstamp" can restart from idle, then tp->rcv_tstamp
    could already be a long time (minutes or hours) in the past even on the
    first RTO. So we double check the timeout with the duration of the
    retransmission.
    
    Meanwhile, making "2 * TCP_RTO_MAX" as the timeout to avoid the socket
    dying too soon.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Link: https://lore.kernel.org/netdev/CADxym3YyMiO+zMD4zj03YPM3FBi-1LHi6gSD2XT8pyAMM096pg@mail.gmail.com/
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: qmi_wwan: add Quectel EM05GV2 [+ + +]
Author: Martin Kohn <m.kohn@welotec.com>
Date:   Thu Jul 27 20:00:43 2023 +0000

    net: usb: qmi_wwan: add Quectel EM05GV2
    
    [ Upstream commit d4480c9bb9258db9ddf2e632f6ef81e96b41089c ]
    
    Add support for Quectel EM05GV2 (G=global) with vendor ID
    0x2c7c and product ID 0x030e
    
    Enabling DTR on this modem was necessary to ensure stable operation.
    Patch for usb: serial: option: is also in progress.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=030e Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Martin Kohn <m.kohn@welotec.com>
    Link: https://lore.kernel.org/r/AM0PR04MB57648219DE893EE04FA6CC759701A@AM0PR04MB5764.eurprd04.prod.outlook.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c [+ + +]
Author: Kyle Zeng <zengyhkyle@gmail.com>
Date:   Tue Sep 5 15:04:09 2023 -0700

    netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c
    
    commit 050d91c03b28ca479df13dfb02bcd2c60dd6a878 upstream.
    
    The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can
    lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,
    which can lead to integer underflow. As a result, it leads to slab
    out-of-bound access.
    This patch adds back the IP_SET_HASH_WITH_NET0 macro to
    ip_set_hash_netportnet to address the issue.
    
    Fixes: 886503f34d63 ("netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net")
    Suggested-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Kyle Zeng <zengyhkyle@gmail.com>
    Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nft_exthdr: Fix non-linear header modification [+ + +]
Author: Xiao Liang <shaw.leon@gmail.com>
Date:   Fri Aug 25 13:33:27 2023 +0800

    netfilter: nft_exthdr: Fix non-linear header modification
    
    commit 28427f368f0e08d504ed06e74bc7cc79d6d06511 upstream.
    
    Fix skb_ensure_writable() size. Don't use nft_tcp_header_pointer() to
    make it explicit that pointers point to the packet (not local buffer).
    
    Fixes: 99d1712bc41c ("netfilter: exthdr: tcp option set support")
    Fixes: 7890cbea66e7 ("netfilter: exthdr: add support for tcp option removal")
    Cc: stable@vger.kernel.org
    Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: xt_sctp: validate the flag_info count [+ + +]
Author: Wander Lairson Costa <wander@redhat.com>
Date:   Mon Aug 28 19:12:55 2023 -0300

    netfilter: xt_sctp: validate the flag_info count
    
    commit e99476497687ef9e850748fe6d232264f30bc8f9 upstream.
    
    sctp_mt_check doesn't validate the flag_count field. An attacker can
    take advantage of that to trigger a OOB read and leak memory
    information.
    
    Add the field validation in the checkentry function.
    
    Fixes: 2e4e6a17af35 ("[NETFILTER] x_tables: Abstraction layer for {ip,ip6,arp}_tables")
    Cc: stable@vger.kernel.org
    Reported-by: Lucas Leong <wmliang@infosec.exchange>
    Signed-off-by: Wander Lairson Costa <wander@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: xt_u32: validate user space input [+ + +]
Author: Wander Lairson Costa <wander@redhat.com>
Date:   Mon Aug 28 10:21:07 2023 -0300

    netfilter: xt_u32: validate user space input
    
    commit 69c5d284f67089b4750d28ff6ac6f52ec224b330 upstream.
    
    The xt_u32 module doesn't validate the fields in the xt_u32 structure.
    An attacker may take advantage of this to trigger an OOB read by setting
    the size fields with a value beyond the arrays boundaries.
    
    Add a checkentry function to validate the structure.
    
    This was originally reported by the ZDI project (ZDI-CAN-18408).
    
    Fixes: 1b50b8a371e9 ("[NETFILTER]: Add u32 match")
    Cc: stable@vger.kernel.org
    Signed-off-by: Wander Lairson Costa <wander@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netrom: Deny concurrent connect(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Aug 24 09:50:59 2023 -0700

    netrom: Deny concurrent connect().
    
    [ Upstream commit c2f8fd7949603efb03908e05abbf7726748c8de3 ]
    
    syzkaller reported null-ptr-deref [0] related to AF_NETROM.
    This is another self-accept issue from the strace log. [1]
    
    syz-executor creates an AF_NETROM socket and calls connect(), which
    is blocked at that time.  Then, sk->sk_state is TCP_SYN_SENT and
    sock->state is SS_CONNECTING.
    
      [pid  5059] socket(AF_NETROM, SOCK_SEQPACKET, 0) = 4
      [pid  5059] connect(4, {sa_family=AF_NETROM, sa_data="..." <unfinished ...>
    
    Another thread calls connect() concurrently, which finally fails
    with -EINVAL.  However, the problem here is the socket state is
    reset even while the first connect() is blocked.
    
      [pid  5060] connect(4, NULL, 0 <unfinished ...>
      [pid  5060] <... connect resumed>)      = -1 EINVAL (Invalid argument)
    
    As sk->state is TCP_CLOSE and sock->state is SS_UNCONNECTED, the
    following listen() succeeds.  Then, the first connect() looks up
    itself as a listener and puts skb into the queue with skb->sk itself.
    As a result, the next accept() gets another FD of itself as 3, and
    the first connect() finishes.
    
      [pid  5060] listen(4, 0 <unfinished ...>
      [pid  5060] <... listen resumed>)       = 0
      [pid  5060] accept(4, NULL, NULL <unfinished ...>
      [pid  5060] <... accept resumed>)       = 3
      [pid  5059] <... connect resumed>)      = 0
    
    Then, accept4() is called but blocked, which causes the general protection
    fault later.
    
      [pid  5059] accept4(4, NULL, 0x20000400, SOCK_NONBLOCK <unfinished ...>
    
    After that, another self-accept occurs by accept() and writev().
    
      [pid  5060] accept(4, NULL, NULL <unfinished ...>
      [pid  5061] writev(3, [{iov_base=...}] <unfinished ...>
      [pid  5061] <... writev resumed>)       = 99
      [pid  5060] <... accept resumed>)       = 6
    
    Finally, the leader thread close()s all FDs.  Since the three FDs
    reference the same socket, nr_release() does the cleanup for it
    three times, and the remaining accept4() causes the following fault.
    
      [pid  5058] close(3)                    = 0
      [pid  5058] close(4)                    = 0
      [pid  5058] close(5)                    = -1 EBADF (Bad file descriptor)
      [pid  5058] close(6)                    = 0
      [pid  5058] <... exit_group resumed>)   = ?
      [   83.456055][ T5059] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
    
    To avoid the issue, we need to return an error for connect() if
    another connect() is in progress, as done in __inet_stream_connect().
    
    [0]:
    general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
    CPU: 0 PID: 5059 Comm: syz-executor.0 Not tainted 6.5.0-rc5-syzkaller-00194-gace0ab3a4b54 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
    RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5012
    Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 11 6e 23 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 69 48 90 0f 84 96 0d 00
    RSP: 0018:ffffc90003d6f9e0 EFLAGS: 00010006
    RAX: ffff8880244c8000 RBX: 1ffff920007adf6c RCX: 0000000000000003
    RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000018
    RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001
    R10: 0000000000000018 R11: 0000000000000000 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  00007f51d519a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f51d5158d58 CR3: 000000002943f000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     lock_acquire kernel/locking/lockdep.c:5761 [inline]
     lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726
     __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
     _raw_spin_lock_irqsave+0x3a/0x50 kernel/locking/spinlock.c:162
     prepare_to_wait+0x47/0x380 kernel/sched/wait.c:269
     nr_accept+0x20d/0x650 net/netrom/af_netrom.c:798
     do_accept+0x3a6/0x570 net/socket.c:1872
     __sys_accept4_file net/socket.c:1913 [inline]
     __sys_accept4+0x99/0x120 net/socket.c:1943
     __do_sys_accept4 net/socket.c:1954 [inline]
     __se_sys_accept4 net/socket.c:1951 [inline]
     __x64_sys_accept4+0x96/0x100 net/socket.c:1951
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7f51d447cae9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f51d519a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000120
    RAX: ffffffffffffffda RBX: 00007f51d459bf80 RCX: 00007f51d447cae9
    RDX: 0000000020000400 RSI: 0000000000000000 RDI: 0000000000000004
    RBP: 00007f51d44c847a R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000800 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007f51d459bf80 R15: 00007ffc25c34e48
     </TASK>
    
    Link: https://syzkaller.appspot.com/text?tag=CrashLog&x=152cdb63a80000 [1]
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+666c97e4686410e79649@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=666c97e4686410e79649
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfs/blocklayout: Use the passed in gfp flags [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Jul 24 11:08:46 2023 +0300

    nfs/blocklayout: Use the passed in gfp flags
    
    [ Upstream commit 08b45fcb2d4675f6182fe0edc0d8b1fe604051fa ]
    
    This allocation should use the passed in GFP_ flags instead of
    GFP_KERNEL.  One places where this matters is in filelayout_pg_init_write()
    which uses GFP_NOFS as the allocation flags.
    
    Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFS: Guard against READDIR loop when entry names exceed MAXNAMELEN [+ + +]
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Tue Aug 22 14:22:38 2023 -0400

    NFS: Guard against READDIR loop when entry names exceed MAXNAMELEN
    
    [ Upstream commit f67b55b6588bcf9316a1e6e8d529100a5aa3ebe6 ]
    
    Commit 64cfca85bacd asserts the only valid return values for
    nfs2/3_decode_dirent should not include -ENAMETOOLONG, but for a server
    that sends a filename3 which exceeds MAXNAMELEN in a READDIR response the
    client's behavior will be to endlessly retry the operation.
    
    We could map -ENAMETOOLONG into -EBADCOOKIE, but that would produce
    truncated listings without any error.  The client should return an error
    for this case to clearly assert that the server implementation must be
    corrected.
    
    Fixes: 64cfca85bacd ("NFS: Return valid errors from nfs2/3_decode_dirent()")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSD: da_addr_body field missing in some GETDEVICEINFO replies [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Aug 16 10:20:52 2023 -0400

    NFSD: da_addr_body field missing in some GETDEVICEINFO replies
    
    [ Upstream commit 6372e2ee629894433fe6107d7048536a3280a284 ]
    
    The XDR specification in RFC 8881 looks like this:
    
    struct device_addr4 {
            layouttype4     da_layout_type;
            opaque          da_addr_body<>;
    };
    
    struct GETDEVICEINFO4resok {
            device_addr4    gdir_device_addr;
            bitmap4         gdir_notification;
    };
    
    union GETDEVICEINFO4res switch (nfsstat4 gdir_status) {
    case NFS4_OK:
            GETDEVICEINFO4resok gdir_resok4;
    case NFS4ERR_TOOSMALL:
            count4          gdir_mincount;
    default:
            void;
    };
    
    Looking at nfsd4_encode_getdeviceinfo() ....
    
    When the client provides a zero gd_maxcount, then the Linux NFS
    server implementation encodes the da_layout_type field and then
    skips the da_addr_body field completely, proceeding directly to
    encode gdir_notification field.
    
    There does not appear to be an option in the specification to skip
    encoding da_addr_body. Moreover, Section 18.40.3 says:
    
    > If the client wants to just update or turn off notifications, it
    > MAY send a GETDEVICEINFO operation with gdia_maxcount set to zero.
    > In that event, if the device ID is valid, the reply's da_addr_body
    > field of the gdir_device_addr field will be of zero length.
    
    Since the layout drivers are responsible for encoding the
    da_addr_body field, put this fix inside the ->encode_getdeviceinfo
    methods.
    
    Fixes: 9cf514ccfacb ("nfsd: implement pNFS operations")
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Cc: Tom Haynes <loghyr@gmail.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSv4.2: fix handling of COPY ERR_OFFLOAD_NO_REQ [+ + +]
Author: Olga Kornievskaia <kolga@netapp.com>
Date:   Thu Aug 24 16:43:53 2023 -0400

    NFSv4.2: fix handling of COPY ERR_OFFLOAD_NO_REQ
    
    [ Upstream commit 5690eed941ab7e33c3c3d6b850100cabf740f075 ]
    
    If the client sent a synchronous copy and the server replied with
    ERR_OFFLOAD_NO_REQ indicating that it wants an asynchronous
    copy instead, the client should retry with asynchronous copy.
    
    Fixes: 539f57b3e0fd ("NFS handle COPY ERR_OFFLOAD_NO_REQS")
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

NFSv4.2: Fix READ_PLUS size calculations [+ + +]
Author: Anna Schumaker <Anna.Schumaker@Netapp.com>
Date:   Wed May 31 17:02:54 2023 -0400

    NFSv4.2: Fix READ_PLUS size calculations
    
    [ Upstream commit 8d18f6c5bb864d97a730f471c56cdecf313efe64 ]
    
    I bump the decode_read_plus_maxsz to account for hole segments, but I
    need to subtract out this increase when calling
    rpc_prepare_reply_pages() so the common case of single data segment
    replies can be directly placed into the xdr pages without needing to be
    shifted around.
    
    Reported-by: Chuck Lever <chuck.lever@oracle.com>
    Fixes: d3b00a802c845 ("NFS: Replace the READ_PLUS decoding code")
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

NFSv4.2: Fix READ_PLUS smatch warnings [+ + +]
Author: Anna Schumaker <Anna.Schumaker@Netapp.com>
Date:   Wed May 24 17:27:08 2023 -0400

    NFSv4.2: Fix READ_PLUS smatch warnings
    
    [ Upstream commit bb05a617f06b7a882e19c4f475b8e37f14d9ceac ]
    
    Smatch reports:
      fs/nfs/nfs42xdr.c:1131 decode_read_plus() warn: missing error code? 'status'
    
    Which Dan suggests to fix by doing a hardcoded "return 0" from the
    "if (segments == 0)" check.
    
    Additionally, smatch reports that the "status = -EIO" assignment is not
    used. This patch addresses both these issues.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Closes: https://lore.kernel.org/r/202305222209.6l5VM2lL-lkp@intel.com/
    Fixes: d3b00a802c845 ("NFS: Replace the READ_PLUS decoding code")
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

NFSv4.2: Rework scratch handling for READ_PLUS (again) [+ + +]
Author: Anna Schumaker <Anna.Schumaker@Netapp.com>
Date:   Fri Jun 9 15:26:25 2023 -0400

    NFSv4.2: Rework scratch handling for READ_PLUS (again)
    
    [ Upstream commit 303a78052091c81e9003915c521fdca1c7e117af ]
    
    I found that the read code might send multiple requests using the same
    nfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is
    how we ended up occasionally double-freeing the scratch buffer, but also
    means we set a NULL pointer but non-zero length to the xdr scratch
    buffer. This results in an oops the first time decoding needs to copy
    something to scratch, which frequently happens when decoding READ_PLUS
    hole segments.
    
    I fix this by moving scratch handling into the pageio read code. I
    provide a function to allocate scratch space for decoding read replies,
    and free the scratch buffer when the nfs_pgio_header is freed.
    
    Fixes: fbd2a05f29a9 (NFSv4.2: Rework scratch handling for READ_PLUS)
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ntb: Clean up tx tail index on link down [+ + +]
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Aug 22 09:04:45 2023 -0700

    ntb: Clean up tx tail index on link down
    
    commit cc79bd2738c2d40aba58b2be6ce47dc0e471df0e upstream.
    
    The tx tail index is not reset when the link goes down. This causes the
    tail index to go out of sync when the link goes down and comes back up.
    Refactor the ntb_qp_link_down_reset() and reset the tail index as well.
    
    Fixes: 2849b5d70641 ("NTB: Reset transport QP link stats on down")
    Reported-by: Yuan Y Lu <yuan.y.lu@intel.com>
    Tested-by: Yuan Y Lu <yuan.y.lu@intel.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ntb: Drop packets when qp link is down [+ + +]
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Aug 22 09:04:51 2023 -0700

    ntb: Drop packets when qp link is down
    
    commit f195a1a6fe416882984f8bd6c61afc1383171860 upstream.
    
    Currently when the transport receive packets after netdev has closed the
    transport returns error and triggers tx errors to be incremented and
    carrier to be stopped. There is no reason to return error if the device is
    already closed. Drop the packet and return 0.
    
    Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
    Reported-by: Yuan Y Lu <yuan.y.lu@intel.com>
    Tested-by: Yuan Y Lu <yuan.y.lu@intel.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ntb: Fix calculation ntb_transport_tx_free_entry() [+ + +]
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Aug 22 09:04:57 2023 -0700

    ntb: Fix calculation ntb_transport_tx_free_entry()
    
    commit 5a7693e6bbf19b22fd6c1d2c4b7beb0a03969e2c upstream.
    
    ntb_transport_tx_free_entry() never returns 0 with the current
    calculation. If head == tail, then it would return qp->tx_max_entry.
    Change compare to tail >= head and when they are equal, a 0 would be
    returned.
    
    Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev")
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: renlonglong <ren.longlong@h3c.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvdimm: Fix dereference after free in register_nvdimm_pmu() [+ + +]
Author: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Date:   Thu Aug 17 19:41:03 2023 +0800

    nvdimm: Fix dereference after free in register_nvdimm_pmu()
    
    [ Upstream commit 08ca6906a4b7e48f8e93b7c1f49a742a415be6d5 ]
    
    'nd_pmu->pmu.attr_groups' is dereferenced in function
    'nvdimm_pmu_free_hotplug_memory' call after it has been freed. Because in
    function 'nvdimm_pmu_free_hotplug_memory' memory pointed by the fields of
    'nd_pmu->pmu.attr_groups' is deallocated it is necessary to call 'kfree'
    after 'nvdimm_pmu_free_hotplug_memory'.
    
    Fixes: 0fab1ba6ad6b ("drivers/nvdimm: Add perf interface to expose nvdimm performance stats")
    Co-developed-by: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
    Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Link: https://lore.kernel.org/r/20230817114103.754977-1-konstantin.meskhidze@huawei.com
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu() [+ + +]
Author: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Date:   Thu Aug 17 19:59:45 2023 +0800

    nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()
    
    [ Upstream commit 85ae42c72142346645e63c33835da947dfa008b3 ]
    
    Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function
    'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function
    'unregister_nvdimm_pmu'.
    
    Fixes: 0fab1ba6ad6b ("drivers/nvdimm: Add perf interface to expose nvdimm performance stats")
    Co-developed-by: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
    Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Link: https://lore.kernel.org/r/20230817115945.771826-1-konstantin.meskhidze@huawei.com
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmem: core: Return NULL when no nvmem layout is found [+ + +]
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Wed Aug 23 14:27:42 2023 +0100

    nvmem: core: Return NULL when no nvmem layout is found
    
    [ Upstream commit 81e1d9a39569d315f747c2af19ce502cd08645ed ]
    
    Currently, of_nvmem_layout_get_container() returns NULL on error, or an
    error pointer if either CONFIG_NVMEM or CONFIG_OF is turned off. We
    should likely avoid this kind of mix for two reasons: to clarify the
    intend and anyway fix the !CONFIG_OF which will likely always if we use
    this helper somewhere else. Let's just return NULL when no layout is
    found, we don't need an error value here.
    
    Link: https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/
    Fixes: 266570f496b9 ("nvmem: core: introduce NVMEM layouts")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/r/202308030002.DnSFOrMB-lkp@intel.com/
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20230823132744.350618-21-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: CN10KB: fix PFC configuration [+ + +]
Author: Hariprasad Kelam <hkelam@marvell.com>
Date:   Thu Aug 24 13:40:31 2023 +0530

    octeontx2-af: CN10KB: fix PFC configuration
    
    [ Upstream commit 47bcc9c1cf6aa60156c7532983090e86d9d171b6 ]
    
    Suppose user has enabled pfc with prio 0,1 on a PF netdev(eth0)
            dcb pfc set dev eth0 prio-pfc o:on 1:on
    later user enabled pfc priorities 2 and 3 on the VF interface(eth1)
            dcb pfc set dev eth1 prio-pfc 2:on 3:on
    
    Instead of enabling pfc on all priorities (0..3), the driver only
    enables on priorities 2,3. This patch corrects the issue by using
    the proper CSR address.
    
    Fixes: b9d0fedc6234 ("octeontx2-af: cn10kb: Add RPM_USX MAC support")
    Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824081032.436432-3-sumang@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Fix PFC TX scheduler free [+ + +]
Author: Suman Ghosh <sumang@marvell.com>
Date:   Thu Aug 24 13:40:30 2023 +0530

    octeontx2-pf: Fix PFC TX scheduler free
    
    [ Upstream commit a9ac2e18779597f280d68a5b5f5bdd51a34080fa ]
    
    During PFC TX schedulers free, flag TXSCHQ_FREE_ALL was being set
    which caused free up all schedulers other than the PFC schedulers.
    This patch fixes that to free only the PFC Tx schedulers.
    
    Fixes: 99c969a83d82 ("octeontx2-pf: Add egress PFC support")
    Signed-off-by: Suman Ghosh <sumang@marvell.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824081032.436432-2-sumang@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

octeontx2-pf: Refactor schedular queue alloc/free calls [+ + +]
Author: Hariprasad Kelam <hkelam@marvell.com>
Date:   Sat May 13 14:21:39 2023 +0530

    octeontx2-pf: Refactor schedular queue alloc/free calls
    
    [ Upstream commit 6b4b2ded9c4282deea421eef144ab0ced954721c ]
    
    1. Upon txschq free request, the transmit schedular config in hardware
    is not getting reset. This patch adds necessary changes to do the same.
    
    2. Current implementation calls txschq alloc during interface
    initialization and in response handler updates the default txschq array.
    This creates a problem for htb offload where txsch alloc will be called
    for every tc class. This patch addresses the issue by reading txschq
    response in mbox caller function instead in the response handler.
    
    3. Current otx2_txschq_stop routine tries to free all txschq nodes
    allocated to the interface. This creates a problem for htb offload.
    This patch introduces the otx2_txschq_free_one to free txschq in a
    given level.
    
    Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
    Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: a9ac2e187795 ("octeontx2-pf: Fix PFC TX scheduler free")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: overlay: Call of_changeset_init() early [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Jul 28 10:50:28 2023 +0200

    of: overlay: Call of_changeset_init() early
    
    [ Upstream commit a9515ff4fb142b690a0d2b58782b15903b990dba ]
    
    When of_overlay_fdt_apply() fails, the changeset may be partially
    applied, and the caller is still expected to call of_overlay_remove() to
    clean up this partial state.
    
    However, of_overlay_apply() calls of_resolve_phandles() before
    init_overlay_changeset().  Hence if the overlay fails to apply due to an
    unresolved symbol, the overlay_changeset.cset.entries list is still
    uninitialized, and cleanup will crash with a NULL-pointer dereference in
    overlay_removal_is_ok().
    
    Fix this by moving the call to of_changeset_init() from
    init_overlay_changeset() to of_overlay_fdt_apply(), where all other
    early initialization is done.
    
    Fixes: f948d6d8b792bb90 ("of: overlay: avoid race condition between applying multiple overlays")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/4f1d6d74b61cba2599026adb6d1948ae559ce91f.1690533838.git.geert+renesas@glider.be
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

of: property: fw_devlink: Add a devlink for panel followers [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Jul 27 10:16:31 2023 -0700

    of: property: fw_devlink: Add a devlink for panel followers
    
    commit fbf0ea2da3c7cd0b33ed7ae53a67ab1c24838cba upstream.
    
    Inform fw_devlink of the fact that a panel follower (like a
    touchscreen) is effectively a consumer of the panel from the purposes
    of fw_devlink.
    
    NOTE: this patch isn't required for correctness but instead optimizes
    probe order / helps avoid deferrals.
    
    Acked-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.4.Ibf8e1342b5b7906279db2365aca45e6253857bb3@changeid
    Cc: Adam Ford <aford173@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name() [+ + +]
Author: Ruan Jinjie <ruanjinjie@huawei.com>
Date:   Thu Jul 27 16:02:46 2023 +0800

    of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()
    
    [ Upstream commit d6ce4f0ea19c32f10867ed93d8386924326ab474 ]
    
    when kmalloc() fail to allocate memory in kasprintf(), name
    or full_name will be NULL, strcmp() will cause
    null pointer dereference.
    
    Fixes: 0d638a07d3a1 ("of: Convert to using %pOF instead of full_name")
    Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20230727080246.519539-1-ruanjinjie@huawei.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

of: unittest: Fix overlay type in apply/revert check [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Jul 28 10:50:29 2023 +0200

    of: unittest: Fix overlay type in apply/revert check
    
    [ Upstream commit 6becf8f845ae1f0b1cfed395bbeccbd23654162d ]
    
    The removal check in of_unittest_apply_revert_overlay_check()
    always uses the platform device overlay type, while it should use the
    actual overlay type, as passed as a parameter to the function.
    
    This has no impact on any current test, as all tests calling
    of_unittest_apply_revert_overlay_check() use the platform device overlay
    type.
    
    Fixes: d5e75500ca401d31 ("of: unitest: Add I2C overlay unit tests.")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/ba0234c41ba808f10112094f88792beeb6dbaedf.1690533838.git.geert+renesas@glider.be
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
OPP: Fix passing 0 to PTR_ERR in _opp_attach_genpd() [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Fri Jul 21 18:16:34 2023 +0530

    OPP: Fix passing 0 to PTR_ERR in _opp_attach_genpd()
    
    [ Upstream commit d920920f85a82c1c806a4143871a0e8f534732f2 ]
    
    If dev_pm_domain_attach_by_name() returns NULL, then 0 will be passed to
    PTR_ERR() as reported by the smatch warning below:
    
    drivers/opp/core.c:2456 _opp_attach_genpd() warn: passing zero to 'PTR_ERR'
    
    Fix it by checking for the non-NULL virt_dev pointer before passing it to
    PTR_ERR. Otherwise return -ENODEV.
    
    Fixes: 4ea9496cbc95 ("opp: Fix error check in dev_pm_opp_attach_genpd()")
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ovl: Always reevaluate the file signature for IMA [+ + +]
Author: Eric Snowberg <eric.snowberg@oracle.com>
Date:   Tue Jul 25 17:56:46 2023 -0400

    ovl: Always reevaluate the file signature for IMA
    
    [ Upstream commit 18b44bc5a67275641fb26f2c54ba7eef80ac5950 ]
    
    Commit db1d1e8b9867 ("IMA: use vfs_getattr_nosec to get the i_version")
    partially closed an IMA integrity issue when directly modifying a file
    on the lower filesystem.  If the overlay file is first opened by a user
    and later the lower backing file is modified by root, but the extended
    attribute is NOT updated, the signature validation succeeds with the old
    original signature.
    
    Update the super_block s_iflags to SB_I_IMA_UNVERIFIABLE_SIGNATURE to
    force signature reevaluation on every file access until a fine grained
    solution can be found.
    
    Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parisc: Fix /proc/cpuinfo output for lscpu [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Fri Aug 18 22:48:04 2023 +0200

    parisc: Fix /proc/cpuinfo output for lscpu
    
    commit 9f5ba4b3e1b3c123eeca5d2d09161e8720048b5c upstream.
    
    The lscpu command is broken since commit cab56b51ec0e ("parisc: Fix
    device names in /proc/iomem") added the PA pathname to all PA
    devices, includig the CPUs.
    
    lscpu parses /proc/cpuinfo and now believes it found different CPU
    types since every CPU is listed with an unique identifier (PA
    pathname).
    
    Fix this problem by simply dropping the PA pathname when listing the
    CPUs in /proc/cpuinfo. There is no need to show the pathname in this
    procfs file.
    
    Fixes: cab56b51ec0e ("parisc: Fix device names in /proc/iomem")
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org> # v4.9+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Partially revert "drm/amd/display: Fix possible underflow for displays with large vblank" [+ + +]
Author: Daniel Miess <daniel.miess@amd.com>
Date:   Wed May 31 11:47:35 2023 -0400

    Partially revert "drm/amd/display: Fix possible underflow for displays with large vblank"
    
    [ Upstream commit a99a4ff6ef205d125002fc7e0857074e4e6597b6 ]
    
    This partially reverts commit de231189e7bf ("drm/amd/display: Fix
    possible underflow for displays with large vblank").
    
    [Why]
    The increased value of VBlankNomDefaultUS causes underflow at the
    desktop of an IP KVM setup
    
    [How]
    Change the value from 800 back to 668
    
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Reviewed-by: Jun Lei <jun.lei@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Daniel Miess <daniel.miess@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/ASPM: Use RMW accessors for changing LNKCTL [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 15:04:56 2023 +0300

    PCI/ASPM: Use RMW accessors for changing LNKCTL
    
    [ Upstream commit e09060b3b6b4661278ff8e1b7b81a37d5ea86eae ]
    
    Don't assume that the device is fully under the control of ASPM and use RMW
    capability accessors which do proper locking to avoid losing concurrent
    updates to the register values.
    
    If configuration fails in pcie_aspm_configure_common_clock(), the
    function attempts to restore the old PCI_EXP_LNKCTL_CCC settings. Store
    only the old PCI_EXP_LNKCTL_CCC bit for the relevant devices rather
    than the content of the whole LNKCTL registers. It aligns better with
    how pcie_lnkctl_clear_and_set() expects its parameter and makes the
    code more obvious to understand.
    
    Suggested-by: Lukas Wunner <lukas@wunner.de>
    Fixes: 2a42d9dba784 ("PCIe: ASPM: Break out of endless loop waiting for PCI config bits to switch")
    Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
    Link: https://lore.kernel.org/r/20230717120503.15276-5-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/DOE: Fix destroy_work_on_stack() race [+ + +]
Author: Ira Weiny <ira.weiny@intel.com>
Date:   Wed Jul 26 11:29:42 2023 -0700

    PCI/DOE: Fix destroy_work_on_stack() race
    
    [ Upstream commit e3a3a097eaebaf234a482b4d2f9f18fe989208c1 ]
    
    The following debug object splat was observed in testing:
    
      ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510
      WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0
      ...
      Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work
      RIP: 0010:debug_print_object+0x7d/0xb0
      ...
      Call Trace:
       ? debug_print_object+0x7d/0xb0
       ? __pfx_doe_statemachine_work+0x10/0x10
       debug_object_free.part.0+0x11b/0x150
       doe_statemachine_work+0x45e/0x510
       process_one_work+0x1d4/0x3c0
    
    This occurs because destroy_work_on_stack() was called after signaling
    the completion in the calling thread.  This creates a race between
    destroy_work_on_stack() and the task->work struct going out of scope in
    pci_doe().
    
    Signal the work complete after destroying the work struct.  This is safe
    because signal_task_complete() is the final thing the work item does and
    the workqueue code is careful not to access the work struct after.
    
    Fixes: abf04be0e707 ("PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y")
    Link: https://lore.kernel.org/r/20230726-doe-fix-v1-1-af07e614d4dd@intel.com
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Lukas Wunner <lukas@wunner.de>
    Acked-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/PM: Only read PCI_PM_CTRL register when available [+ + +]
Author: Feiyang Chen <chenfeiyang@loongson.cn>
Date:   Thu Aug 24 09:37:38 2023 +0800

    PCI/PM: Only read PCI_PM_CTRL register when available
    
    commit 5694ba13b004eea683c6d4faeb6d6e7a9636bda0 upstream.
    
    For a device with no Power Management Capability, pci_power_up() previously
    returned 0 (success) if the platform was able to put the device in D0,
    which led to pci_set_full_power_state() trying to read PCI_PM_CTRL, even
    though it doesn't exist.
    
    Since dev->pm_cap == 0 in this case, pci_set_full_power_state() actually
    read the wrong register, interpreted it as PCI_PM_CTRL, and corrupted
    dev->current_state.  This led to messages like this in some cases:
    
      pci 0000:01:00.0: Refused to change power state from D3hot to D0
    
    To prevent this, make pci_power_up() always return a negative failure code
    if the device lacks a Power Management Capability, even if non-PCI platform
    power management has been able to put the device in D0.  The failure will
    prevent pci_set_full_power_state() from trying to access PCI_PM_CTRL.
    
    Fixes: e200904b275c ("PCI/PM: Split pci_power_up()")
    Link: https://lore.kernel.org/r/20230824013738.1894965-1-chenfeiyang@loongson.cn
    Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: stable@vger.kernel.org      # v5.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: Add locking to RMW PCI Express Capability Register accessors [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 15:04:53 2023 +0300

    PCI: Add locking to RMW PCI Express Capability Register accessors
    
    [ Upstream commit 5e70d0acf0825f439079736080350371f8d6699a ]
    
    Many places in the kernel write the Link Control and Root Control PCI
    Express Capability Registers without proper concurrency control and this
    could result in losing the changes one of the writers intended to make.
    
    Add pcie_cap_lock spinlock into the struct pci_dev and use it to protect
    bit changes made in the RMW capability accessors. Protect only a selected
    set of registers by differentiating the RMW accessor internally to
    locked/unlocked variants using a wrapper which has the same signature as
    pcie_capability_clear_and_set_word(). As the Capability Register (pos)
    given to the wrapper is always a constant, the compiler should be able to
    simplify all the dead-code away.
    
    So far only the Link Control Register (ASPM, hotplug, link retraining,
    various drivers) and the Root Control Register (AER & PME) seem to
    require RMW locking.
    
    Suggested-by: Lukas Wunner <lukas@wunner.de>
    Fixes: c7f486567c1d ("PCI PM: PCIe PME root port service driver")
    Fixes: f12eb72a268b ("PCI/ASPM: Use PCI Express Capability accessors")
    Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
    Fixes: affa48de8417 ("staging/rdma/hfi1: Add support for enabling/disabling PCIe ASPM")
    Fixes: 849a9366cba9 ("misc: rtsx: Add support new chip rts5228 mmc: rtsx: Add support MMC_CAP2_NO_MMC")
    Fixes: 3d1e7aa80d1c ("misc: rtsx: Use pcie_capability_clear_and_set_word() for PCI_EXP_LNKCTL")
    Fixes: c0e5f4e73a71 ("misc: rtsx: Add support for RTS5261")
    Fixes: 3df4fce739e2 ("misc: rtsx: separate aspm mode into MODE_REG and MODE_CFG")
    Fixes: 121e9c6b5c4c ("misc: rtsx: modify and fix init_hw function")
    Fixes: 19f3bd548f27 ("mfd: rtsx: Remove LCTLR defination")
    Fixes: 773ccdfd9cc6 ("mfd: rtsx: Read vendor setting from config space")
    Fixes: 8275b77a1513 ("mfd: rts5249: Add support for RTS5250S power saving")
    Fixes: 5da4e04ae480 ("misc: rtsx: Add support for RTS5260")
    Fixes: 0f49bfbd0f2e ("tg3: Use PCI Express Capability accessors")
    Fixes: 5e7dfd0fb94a ("tg3: Prevent corruption at 10 / 100Mbps w CLKREQ")
    Fixes: b726e493e8dc ("r8169: sync existing 8168 device hardware start sequences with vendor driver")
    Fixes: e6de30d63eb1 ("r8169: more 8168dp support.")
    Fixes: 8a06127602de ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards")
    Fixes: 6f461f6c7c96 ("e1000e: enable/disable ASPM L0s and L1 and ERT according to hardware errata")
    Fixes: 1eae4eb2a1c7 ("e1000e: Disable L1 ASPM power savings for 82573 mobile variants")
    Fixes: 8060e169e02f ("ath9k: Enable extended synch for AR9485 to fix L0s recovery issue")
    Fixes: 69ce674bfa69 ("ath9k: do btcoex ASPM disabling at initialization time")
    Fixes: f37f05503575 ("mt76: mt76x2e: disable pcie_aspm by default")
    Link: https://lore.kernel.org/r/20230717120503.15276-2-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: "Rafael J. Wysocki" <rafael@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: apple: Initialize pcie->nvecs before use [+ + +]
Author: Sven Peter <sven@svenpeter.dev>
Date:   Sat Mar 11 14:34:53 2023 +0100

    PCI: apple: Initialize pcie->nvecs before use
    
    [ Upstream commit d8650c0c2aa2e413594e4cb0faafa9958c1d7782 ]
    
    The apple_pcie_setup_port() function computes ilog2(pcie->nvecs) to set
    up the number of MSIs available for each port. However, it's called
    before apple_msi_init(), which initializes pcie->nvecs.
    
    Luckily, pcie->nvecs is part of kzalloc()-ed structure and, as such,
    initialized as zero. ilog2(0) happens to be 0xffffffff which then simply
    configures more MSIs in hardware than we have. This doesn't break
    anything because we never hand out those vectors.
    
    Thus, swap the order of the two calls so that the correctly initialized
    value is then used.
    
    [kwilczynski: commit log]
    Link: https://lore.kernel.org/linux-pci/20230311133453.63246-1-sven@svenpeter.dev
    Fixes: 476c41ed4597 ("PCI: apple: Implement MSI support")
    Signed-off-by: Sven Peter <sven@svenpeter.dev>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
    Reviewed-by: Eric Curtin <ecurtin@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Free released resource after coalescing [+ + +]
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Wed Sep 6 12:08:46 2023 +0100

    PCI: Free released resource after coalescing
    
    commit 8ec9c1d5d0a5a4744516adb483b97a238892f9d5 upstream.
    
    release_resource() doesn't actually free the resource or resource list
    entry so free the resource list entry to avoid a leak.
    
    Closes: https://lore.kernel.org/r/878r9sga1t.fsf@kernel.org/
    Fixes: e54223275ba1 ("PCI: Release resource invalidated by coalescing")
    Link: https://lore.kernel.org/r/20230906110846.225369-1-ross.lagerwall@citrix.com
    Reported-by: Kalle Valo <kvalo@kernel.org>
    Tested-by: Kalle Valo <kvalo@kernel.org>
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org      # v5.16+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation [+ + +]
Author: Dexuan Cui <decui@microsoft.com>
Date:   Wed Aug 16 10:59:39 2023 -0700

    PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation
    
    commit 04bbe863241a9be7d57fb4cf217ee4a72f480e70 upstream.
    
    When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI
    device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the
    device yet), doing a VM hibernation triggers a panic in
    hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because
    pdev->dev.msi.data is still NULL.
    
    Avoid the panic by checking if MSI-X/MSI is enabled.
    
    Link: https://lore.kernel.org/r/20230816175939.21566-1-decui@microsoft.com
    Fixes: dc2b453290c4 ("PCI: hv: Rework MSI handling")
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
    Reviewed-by: sathyanarayanan.kuppuswamy@linux.intel.com
    Reviewed-by: Michael Kelley <mikelley@microsoft.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: Mark NVIDIA T4 GPUs to avoid bus reset [+ + +]
Author: Wu Zongyong <wuzongyong@linux.alibaba.com>
Date:   Mon Apr 10 20:34:11 2023 +0800

    PCI: Mark NVIDIA T4 GPUs to avoid bus reset
    
    [ Upstream commit d5af729dc2071273f14cbb94abbc60608142fd83 ]
    
    NVIDIA T4 GPUs do not work with SBR. This problem is found when the T4 card
    is direct attached to a Root Port only. Avoid bus reset by marking T4 GPUs
    PCI_DEV_FLAGS_NO_BUS_RESET.
    
    Fixes: 4c207e7121fa ("PCI: Mark some NVIDIA GPUs to avoid bus reset")
    Link: https://lore.kernel.org/r/2dcebea53a6eb9bd212ec6d8974af2e5e0333ef6.1681129861.git.wuzongyong@linux.alibaba.com
    Signed-off-by: Wu Zongyong <wuzongyong@linux.alibaba.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: microchip: Correct the DED and SEC interrupt bit offsets [+ + +]
Author: Daire McNamara <daire.mcnamara@microchip.com>
Date:   Fri Jul 28 14:13:55 2023 +0100

    PCI: microchip: Correct the DED and SEC interrupt bit offsets
    
    [ Upstream commit 6d473a5a26136edf55c435a1c433e52910e03926 ]
    
    The SEC and DED interrupt bits are laid out the wrong way round so the SEC
    interrupt handler attempts to mask, unmask, and clear the DED interrupt
    and vice versa. Correct the bit offsets so that each interrupt handler
    operates properly.
    
    Link: https://lore.kernel.org/r/20230728131401.1615724-2-daire.mcnamara@microchip.com
    Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver")
    Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com>
    Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: pciehp: Use RMW accessors for changing LNKCTL [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 15:04:55 2023 +0300

    PCI: pciehp: Use RMW accessors for changing LNKCTL
    
    [ Upstream commit 5f75f96c61039151c193775d776fde42477eace1 ]
    
    As hotplug is not the only driver touching LNKCTL, use the RMW capability
    accessor which handles concurrent changes correctly.
    
    Suggested-by: Lukas Wunner <lukas@wunner.de>
    Fixes: 7f822999e12a ("PCI: pciehp: Add Disable/enable link functions")
    Link: https://lore.kernel.org/r/20230717120503.15276-4-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: qcom-ep: Switch MHI bus master clock off during L1SS [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Tue Jun 27 19:40:36 2023 +0530

    PCI: qcom-ep: Switch MHI bus master clock off during L1SS
    
    [ Upstream commit b9cbc06049cb6b7a322d708c2098195fb9fdcc4c ]
    
    Currently, as part of the qcom_pcie_perst_deassert() function, instead
    of writing the updated value to clear PARF_MSTR_AXI_CLK_EN, the variable
    "val" is re-read.
    
    This must be fixed to ensure that the master clock supplied to the MHI
    bus is correctly gated during L1.1/L1.2 to save power.
    
    Thus, replace the line that re-reads "val" with a line that writes the
    updated value to the register to clear PARF_MSTR_AXI_CLK_EN.
    
    [kwilczynski: commit log]
    Fixes: c457ac029e44 ("PCI: qcom-ep: Gate Master AXI clock to MHI bus during L1SS")
    Link: https://lore.kernel.org/linux-pci/20230627141036.11600-1-manivannan.sadhasivam@linaro.org
    Reported-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: rockchip: Use 64-bit mask on MSI 64-bit PCI address [+ + +]
Author: Rick Wertenbroek <rick.wertenbroek@gmail.com>
Date:   Mon Jul 3 10:58:45 2023 +0200

    PCI: rockchip: Use 64-bit mask on MSI 64-bit PCI address
    
    commit cdb50033dd6dfcf02ae3d4ee56bc1a9555be6d36 upstream.
    
    A 32-bit mask was used on the 64-bit PCI address used for mapping MSIs.
    This would result in the upper 32 bits being unintentionally zeroed and
    MSIs getting mapped to incorrect PCI addresses if the address had any
    of the upper bits set.
    
    Replace 32-bit mask by appropriate 64-bit mask.
    
    [kwilczynski: use GENMASK_ULL() over GENMASK() for 32-bit compatibility]
    Fixes: dc73ed0f1b8b ("PCI: rockchip: Fix window mapping and address translation for endpoint")
    Closes: https://lore.kernel.org/linux-pci/8d19e5b7-8fa0-44a4-90e2-9bb06f5eb694@moroto.mountain
    Link: https://lore.kernel.org/linux-pci/20230703085845.2052008-1-rick.wertenbroek@gmail.com
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pds_core: check for work queue before use [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Thu Aug 24 09:17:53 2023 -0700

    pds_core: check for work queue before use
    
    [ Upstream commit 969cfd4c8ca50c32901342cdd3d677c3ffe61371 ]
    
    Add a check that the wq exists before queuing up work for a
    failed devcmd, as the PF is responsible for health and the VF
    doesn't have a wq.
    
    Fixes: c2dbb0904310 ("pds_core: health timer and workqueue")
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824161754.34264-5-shannon.nelson@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pds_core: no health reporter in VF [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Thu Aug 24 09:17:51 2023 -0700

    pds_core: no health reporter in VF
    
    [ Upstream commit e48b894a1db7f6ce66bff0402ab21ff9f0e56034 ]
    
    Make sure the health reporter is set up before we use it in
    our devlink health updates, especially since the VF doesn't
    set up the health reporter.
    
    Fixes: 25b450c05a49 ("pds_core: add devlink health facilities")
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824161754.34264-3-shannon.nelson@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pds_core: no reset command for VF [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Thu Aug 24 09:17:52 2023 -0700

    pds_core: no reset command for VF
    
    [ Upstream commit 95e383226d6fcda6c217912f11edf8d74de9cc85 ]
    
    The VF doesn't need to send a reset command, and in a PCI reset
    scenario it might not have a valid IO space to write to anyway.
    
    Fixes: 523847df1b37 ("pds_core: add devcmd device interfaces")
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824161754.34264-4-shannon.nelson@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pds_core: pass opcode to devcmd_wait [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Thu Aug 24 09:17:54 2023 -0700

    pds_core: pass opcode to devcmd_wait
    
    [ Upstream commit 0ea064e74bc8f915aba3f2d0fb3418247a09b73d ]
    
    Don't rely on the PCI memory for the devcmd opcode because we
    read a 0xff value if the PCI bus is broken, which can cause us
    to report a bogus dev_cmd opcode later.
    
    Fixes: 523847df1b37 ("pds_core: add devcmd device interfaces")
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824161754.34264-6-shannon.nelson@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pds_core: protect devlink callbacks from fw_down state [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Thu Aug 24 09:17:50 2023 -0700

    pds_core: protect devlink callbacks from fw_down state
    
    [ Upstream commit 91202ce78fcd070982a115f0bf6f328af619aa00 ]
    
    Don't access structs that have been cleared when in the fw_down
    state and the various structs have been cleaned and are waiting
    to recover.  This caused a panic on rmmod when already in fw_down
    and devlink_param_unregister() tried to check the parameters.
    
    Fixes: 40ced8944536 ("pds_core: devlink params for enabling VIF support")
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20230824161754.34264-2-shannon.nelson@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/imx_ddr: don't enable counter0 if none of 4 counters are used [+ + +]
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Fri Aug 11 09:54:38 2023 +0800

    perf/imx_ddr: don't enable counter0 if none of 4 counters are used
    
    [ Upstream commit f4e2bd91ddf5e8543cbe7ad80b3fba3d2dc63fa3 ]
    
    In current driver, counter0 will be enabled after ddr_perf_pmu_enable()
    is called even though none of the 4 counters are used. This will cause
    counter0 continue to count until ddr_perf_pmu_disabled() is called. If
    pmu is not disabled all the time, the pmu interrupt will be asserted
    from time to time due to counter0 will overflow and irq handler will
    clear it. It's not an expected behavior. This patch will not enable
    counter0 if none of 4 counters are used.
    
    Fixes: 9a66d36cc7ac ("drivers/perf: imx_ddr: Add DDR performance counter support to perf")
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20230811015438.1999307-2-xu.yang_2@nxp.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/x86/uncore: Correct the number of CHAs on EMR [+ + +]
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Tue Sep 5 06:42:48 2023 -0700

    perf/x86/uncore: Correct the number of CHAs on EMR
    
    commit 6f7f984fa85b305799076a1bcec941b9377587de upstream.
    
    Starting from SPR, the basic uncore PMON information is retrieved from
    the discovery table (resides in an MMIO space populated by BIOS). It is
    called the discovery method. The existing value of the type->num_boxes
    is from the discovery table.
    
    On some SPR variants, there is a firmware bug that makes the value from the
    discovery table incorrect. We use the value from the
    SPR_MSR_UNC_CBO_CONFIG MSR to replace the one from the discovery table:
    
       38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR")
    
    Unfortunately, the SPR_MSR_UNC_CBO_CONFIG isn't available for the EMR
    XCC (Always returns 0), but the above firmware bug doesn't impact the
    EMR XCC.
    
    Don't let the value from the MSR replace the existing value from the
    discovery table.
    
    Fixes: 38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR")
    Reported-by: Stephane Eranian <eranian@google.com>
    Reported-by: Yunying Sun <yunying.sun@intel.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Tested-by: Yunying Sun <yunying.sun@intel.com>
    Link: https://lore.kernel.org/r/20230905134248.496114-1-kan.liang@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Thu Jun 15 17:10:21 2023 +0000

    phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write
    
    [ Upstream commit 19a1d46bd699940a496d3b0d4e142ef99834988c ]
    
    inno_write is used to configure 0xaa reg, that also hold the
    POST_PLL_POWER_DOWN bit.
    When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not
    taken into consideration.
    
    Fix this by keeping the power down bit until configuration is complete.
    Also reorder the reg write order for consistency.
    
    Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Link: https://lore.kernel.org/r/20230615171005.2251032-5-jonas@kwiboo.se
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate [+ + +]
Author: Zheng Yang <zhengyang@rock-chips.com>
Date:   Thu Jun 15 17:10:19 2023 +0000

    phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate
    
    [ Upstream commit d5ef343c1d62bc4c4c2c393af654a41cb34b449f ]
    
    inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found
    in the pre pll config table when the fractal divider is used.
    This can prevent proper power_on because a tmdsclock for the new rate
    is not found in the pre pll config table.
    
    Fix this by saving and returning a rounded pixel rate that exist
    in the pre pll config table.
    
    Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
    Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Link: https://lore.kernel.org/r/20230615171005.2251032-3-jonas@kwiboo.se
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328 [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Thu Jun 15 17:10:17 2023 +0000

    phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328
    
    [ Upstream commit 644c06dfbd0da713f772abf0a8f8581ac78e6264 ]
    
    inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
    when configuring vco_div_5 on RK3328.
    
    Fix this by using correct vco_div_5 macro for RK3328.
    
    Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Link: https://lore.kernel.org/r/20230615171005.2251032-2-jonas@kwiboo.se
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: qcom-snps-femto-v2: use qcom_snps_hsphy_suspend/resume error code [+ + +]
Author: Adrien Thierry <athierry@redhat.com>
Date:   Thu Jun 29 10:45:40 2023 -0400

    phy: qcom-snps-femto-v2: use qcom_snps_hsphy_suspend/resume error code
    
    [ Upstream commit 8932089b566c24ea19b57e37704c492678de1420 ]
    
    The return value from qcom_snps_hsphy_suspend/resume is not used. Make
    sure qcom_snps_hsphy_runtime_suspend/resume return this value as well.
    
    Signed-off-by: Adrien Thierry <athierry@redhat.com>
    Link: https://lore.kernel.org/r/20230629144542.14906-4-athierry@redhat.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: mcp23s08: check return value of devm_kasprintf() [+ + +]
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Wed Jun 21 13:04:09 2023 +0300

    pinctrl: mcp23s08: check return value of devm_kasprintf()
    
    [ Upstream commit f941714a7c7698eadb59bc27d34d6d6f38982705 ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory.
    Pointer could be NULL in case allocation fails. Check pointer validity.
    Identified with coccinelle (kmerr.cocci script).
    
    Fixes: 0f04a81784fe ("pinctrl: mcp23s08: Split to three parts: core, I²C, SPI")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20230621100409.1608395-1-claudiu.beznea@microchip.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: mediatek: assign functions to configure pin bias on MT7986 [+ + +]
Author: Daniel Golle <daniel@makrotopia.org>
Date:   Fri Aug 18 04:03:26 2023 +0100

    pinctrl: mediatek: assign functions to configure pin bias on MT7986
    
    [ Upstream commit 0d8387fba9f151220e48dc3dcdc2335539708f13 ]
    
    Assign bias_disable_get/set and bias_get/set functions to allow
    configuring pin bias on MT7986.
    
    Fixes: 2c58d8dc9cd0 ("pinctrl: mediatek: add pull_type attribute for mediatek MT7986 SoC")
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Link: https://lore.kernel.org/r/47f72372354312a839b9337e09476aadcc206e8b.1692327317.git.daniel@makrotopia.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: mediatek: fix pull_type data for MT7981 [+ + +]
Author: Daniel Golle <daniel@makrotopia.org>
Date:   Fri Aug 18 04:02:35 2023 +0100

    pinctrl: mediatek: fix pull_type data for MT7981
    
    [ Upstream commit 8f6f16fe1553ce63edfb98a39ef9d4754a0c39bf ]
    
    MediaTek has released pull_type data for MT7981 in their SDK.
    Use it and set functions to configure pin bias.
    
    Fixes: 6c83b2d94fcc ("pinctrl: add mt7981 pinctrl driver")
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Link: https://lore.kernel.org/r/7bcc8ead25dbfabc7f5a85d066224a926fbb4941.1692327317.git.daniel@makrotopia.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/chrome: chromeos_acpi: print hex string for ACPI_TYPE_BUFFER [+ + +]
Author: Tzung-Bi Shih <tzungbi@kernel.org>
Date:   Thu Aug 3 09:12:45 2023 +0800

    platform/chrome: chromeos_acpi: print hex string for ACPI_TYPE_BUFFER
    
    commit 0820debb7d489e9eb1f68b7bb69e6ae210699b3f upstream.
    
    `element->buffer.pointer` should be binary blob.  `%s` doesn't work
    perfect for them.
    
    Print hex string for ACPI_TYPE_BUFFER.  Also update the documentation
    to reflect this.
    
    Fixes: 0a4cad9c11ad ("platform/chrome: Add ChromeOS ACPI device driver")
    Cc: stable@vger.kernel.org
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20230803011245.3773756-1-tzungbi@kernel.org
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/mellanox: Fix mlxbf-tmfifo not handling all virtio CONSOLE notifications [+ + +]
Author: Shih-Yi Chen <shihyic@nvidia.com>
Date:   Mon Aug 21 11:06:27 2023 -0400

    platform/mellanox: Fix mlxbf-tmfifo not handling all virtio CONSOLE notifications
    
    [ Upstream commit 0848cab765c634597636810bf76d0934003cce28 ]
    
    rshim console does not show all entries of dmesg.
    
    Fixed by setting MLXBF_TM_TX_LWM_IRQ for every CONSOLE notification.
    
    Signed-off-by: Shih-Yi Chen <shihyic@nvidia.com>
    Reviewed-by: Liming Sung <limings@nvidia.com>
    Reviewed-by: David Thompson <davthompson@nvidia.com>
    Link: https://lore.kernel.org/r/20230821150627.26075-1-shihyic@nvidia.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86/amd/pmf: Fix a missing cleanup path [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Aug 23 13:54:21 2023 -0500

    platform/x86/amd/pmf: Fix a missing cleanup path
    
    [ Upstream commit 4dbd6e61adc7e52dd1c9165f0ccaa90806611e40 ]
    
    On systems that support slider notifications but don't otherwise support
    granular slider the SPS cleanup path doesn't run.
    
    This means that loading/unloading/loading leads to failures because
    the sysfs files don't get setup properly when reloaded.
    
    Add the missing cleanup path.
    
    Fixes: 33c9ab5b493a ("platform/x86/amd/pmf: Notify OS power slider update")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20230823185421.23959-1-mario.limonciello@amd.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86/amd/pmf: Fix unsigned comparison with less than zero [+ + +]
Author: Yang Li <yang.lee@linux.alibaba.com>
Date:   Thu Jul 27 09:43:15 2023 +0800

    platform/x86/amd/pmf: Fix unsigned comparison with less than zero
    
    [ Upstream commit 785c00993dc4c4bb2f7b0f3a3f29c03a6f7aab2e ]
    
    The return value from the call to amd_pmf_get_pprof_modes() is int.
    However, the return value is being assigned to an unsigned char
    variable 'mode', so making 'mode' an int.
    
    silence the warning:
    ./drivers/platform/x86/amd/pmf/sps.c:183:5-9: WARNING: Unsigned expression compared with zero: mode < 0
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5995
    Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230727014315.51375-1-yang.lee@linux.alibaba.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86/intel/hid: Add HP Dragonfly G2 to VGBS DMI quirks [+ + +]
Author: Maxim Mikityanskiy <maxtram95@gmail.com>
Date:   Sun Jul 16 21:32:13 2023 +0300

    platform/x86/intel/hid: Add HP Dragonfly G2 to VGBS DMI quirks
    
    [ Upstream commit 7783e97f8558ad7a4d1748922461bc88483fbcdf ]
    
    HP Elite Dragonfly G2 (a convertible laptop/tablet) has a reliable VGBS
    method. If VGBS is not called on boot, the firmware sends an initial
    0xcd event shortly after calling the BTNL method, but only if the device
    is booted in the laptop mode. However, if the device is booted in the
    tablet mode and VGBS is not called, there is no initial 0xcc event, and
    the input device for SW_TABLET_MODE is not registered up until the user
    turns the device into the laptop mode.
    
    Call VGBS on boot on this device to get the initial state of
    SW_TABLET_MODE in a reliable way.
    
    Tested with BIOS 1.13.1.
    
    Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
    Link: https://lore.kernel.org/r/20230716183213.64173-1-maxtram95@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: asus-wmi: Fix setting RGB mode on some TUF laptops [+ + +]
Author: Kristian Angelov <kristiana2000@abv.bg>
Date:   Thu Jul 20 18:29:50 2023 +0300

    platform/x86: asus-wmi: Fix setting RGB mode on some TUF laptops
    
    [ Upstream commit 6a758a3e831ce1a84c9c209ac6dc755f4c8ce77a ]
    
    This patch fixes setting the cmd values to 0xb3 and 0xb4.
    This is necessary on some TUF laptops in order to set the RGB mode.
    
    Closes: https://lore.kernel.org/platform-driver-x86/443078148.491022.1677576298133@nm83.abv.bg
    Signed-off-by: Kristian Angelov <kristiana2000@abv.bg>
    Reviewed-by: Luke D. Jones <luke@ljones.dev>
    Link: https://lore.kernel.org/r/ZLlS7o6UdTUBkyqa@wyvern.localdomain
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: dell-sysman: Fix reference leak [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Sat Aug 5 07:36:10 2023 +0200

    platform/x86: dell-sysman: Fix reference leak
    
    [ Upstream commit 7295a996fdab7bf83dc3d4078fa8b139b8e0a1bf ]
    
    If a duplicate attribute is found using kset_find_obj(),
    a reference to that attribute is returned. This means
    that we need to dispose it accordingly. Use kobject_put()
    to dispose the duplicate attribute in such a case.
    
    Compile-tested only.
    
    Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20230805053610.7106-1-W_Armin@gmx.de
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: huawei-wmi: Silence ambient light sensor [+ + +]
Author: Konstantin Shelekhin <k.shelekhin@ftml.net>
Date:   Sat Jul 22 18:59:20 2023 +0300

    platform/x86: huawei-wmi: Silence ambient light sensor
    
    [ Upstream commit c21733754cd6ecbca346f2adf9b17d4cfa50504f ]
    
    Currently huawei-wmi causes a lot of spam in dmesg on my
    Huawei MateBook X Pro 2022:
    
      ...
      [36409.328463] input input9: Unknown key pressed, code: 0x02c1
      [36411.335104] input input9: Unknown key pressed, code: 0x02c1
      [36412.338674] input input9: Unknown key pressed, code: 0x02c1
      [36414.848564] input input9: Unknown key pressed, code: 0x02c1
      [36416.858706] input input9: Unknown key pressed, code: 0x02c1
      ...
    
    Fix that by ignoring events generated by ambient light sensor.
    
    This issue was reported on GitHub and resolved with the following merge
    request:
    
      https://github.com/aymanbagabas/Huawei-WMI/pull/70
    
    I've contacted the mainter of this repo and he gave me the "go ahead" to
    send this patch to the maling list.
    
    Signed-off-by: Konstantin Shelekhin <k.shelekhin@ftml.net>
    Link: https://lore.kernel.org/r/20230722155922.173856-1-k.shelekhin@ftml.net
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: intel: hid: Always call BTNL ACPI method [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Jul 15 20:15:16 2023 +0200

    platform/x86: intel: hid: Always call BTNL ACPI method
    
    [ Upstream commit e3ab18de2b09361d6f0e4aafb9cfd6d002ce43a1 ]
    
    On a HP Elite Dragonfly G2 the 0xcc and 0xcd events for SW_TABLET_MODE
    are only send after the BTNL ACPI method has been called.
    
    Likely more devices need this, so make the BTNL ACPI method unconditional
    instead of only doing it on devices with a 5 button array.
    
    Note this also makes the intel_button_array_enable() call in probe()
    unconditional, that function does its own priv->array check. This makes
    the intel_button_array_enable() call in probe() consistent with the calls
    done on suspend/resume which also rely on the priv->array check inside
    the function.
    
    Reported-by: Maxim Mikityanskiy <maxtram95@gmail.com>
    Closes: https://lore.kernel.org/platform-driver-x86/20230712175023.31651-1-maxtram95@gmail.com/
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230715181516.5173-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: think-lmi: Use kfree_sensitive instead of kfree [+ + +]
Author: Wang Ming <machel@vivo.com>
Date:   Mon Jul 17 18:11:02 2023 +0800

    platform/x86: think-lmi: Use kfree_sensitive instead of kfree
    
    [ Upstream commit 1da0893aed2e48e2bdf37c29b029f2e060d25927 ]
    
    key might contain private part of the key, so better use
    kfree_sensitive to free it.
    
    Signed-off-by: Wang Ming <machel@vivo.com>
    Link: https://lore.kernel.org/r/20230717101114.18966-1-machel@vivo.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM / devfreq: Fix leak in devfreq_dev_release() [+ + +]
Author: Boris Brezillon <boris.brezillon@collabora.com>
Date:   Wed Aug 9 13:31:08 2023 +0200

    PM / devfreq: Fix leak in devfreq_dev_release()
    
    commit 5693d077595de721f9ddbf9d37f40e5409707dfe upstream.
    
    srcu_init_notifier_head() allocates resources that need to be released
    with a srcu_cleanup_notifier_head() call.
    
    Reported by kmemleak.
    
    Fixes: 0fe3a66410a3 ("PM / devfreq: Add new DEVFREQ_TRANSITION_NOTIFIER notifier")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pNFS: Fix assignment of xprtdata.cred [+ + +]
Author: Anna Schumaker <Anna.Schumaker@Netapp.com>
Date:   Wed Aug 30 14:31:31 2023 -0400

    pNFS: Fix assignment of xprtdata.cred
    
    [ Upstream commit c4a123d2e8c4dc91d581ee7d05c0cd51a0273fab ]
    
    The comma at the end of the line was leftover from an earlier refactor
    of the _nfs4_pnfs_v3_ds_connect() function. This is technically valid C,
    so the compilers didn't catch it, but if I'm understanding how it works
    correctly it assigns the return value of rpc_clnt_add_xprtr() to
    xprtdata.cred.
    
    Reported-by: Olga Kornievskaia <kolga@netapp.com>
    Fixes: a12f996d3413 ("NFSv4/pNFS: Use connections to a DS that are all of the same protocol family")
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powercap: arm_scmi: Remove recursion while parsing zones [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Tue Jul 18 11:17:26 2023 +0100

    powercap: arm_scmi: Remove recursion while parsing zones
    
    [ Upstream commit 3e767d6850f867cc33ac16ca097350a1d2417982 ]
    
    Powercap zones can be defined as arranged in a hierarchy of trees and when
    registering a zone with powercap_register_zone(), the kernel powercap
    subsystem expects this to happen starting from the root zones down to the
    leaves; on the other side, de-registration by powercap_deregister_zone()
    must begin from the leaf zones.
    
    Available SCMI powercap zones are retrieved dynamically from the platform
    at probe time and, while any defined hierarchy between the zones is
    described properly in the zones descriptor, the platform returns the
    availables zones with no particular well-defined order: as a consequence,
    the trees possibly composing the hierarchy of zones have to be somehow
    walked properly to register the retrieved zones from the root.
    
    Currently the ARM SCMI Powercap driver walks the zones using a recursive
    algorithm; this approach, even though correct and tested can lead to kernel
    stack overflow when processing a returned hierarchy of zones composed by
    particularly high trees.
    
    Avoid possible kernel stack overflow by substituting the recursive approach
    with an iterative one supported by a dynamically allocated stack-like data
    structure.
    
    Fixes: b55eef5226b7 ("powercap: arm_scmi: Add SCMI Powercap based driver")
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Acked-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/fadump: reset dump area size if fadump memory reserve fails [+ + +]
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Tue Jul 4 10:37:15 2023 +0530

    powerpc/fadump: reset dump area size if fadump memory reserve fails
    
    [ Upstream commit d1eb75e0dfed80d2d85b664e28a39f65b290ab55 ]
    
    In case fadump_reserve_mem() fails to reserve memory, the
    reserve_dump_area_size variable will retain the reserve area size. This
    will lead to /sys/kernel/fadump/mem_reserved node displaying an incorrect
    memory reserved by fadump.
    
    To fix this problem, reserve dump area size variable is set to 0 if fadump
    failed to reserve memory.
    
    Fixes: 8255da95e545 ("powerpc/fadump: release all the memory above boot memory size")
    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230704050715.203581-1-sourabhjain@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/ftrace: Fix dropping weak symbols with older toolchains [+ + +]
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:19 2023 +0530

    powerpc/ftrace: Fix dropping weak symbols with older toolchains
    
    commit f6834c8c59a8e977a6f6e4f96c5d28dfa5db8430 upstream.
    
    The minimum level of gcc supported for building the kernel is v5.1.
    v5.x releases of gcc emitted a three instruction sequence for
    -mprofile-kernel:
            mflr    r0
            std     r0, 16(r1)
            bl      _mcount
    
    It is only with the v6.x releases that gcc started emitting the two
    instruction sequence for -mprofile-kernel, omitting the second store
    instruction.
    
    With the older three instruction sequence, the actual ftrace location
    can be the 5th instruction into a function. Update the allowed offset
    for ftrace location from 12 to 16 to accommodate the same.
    
    Cc: stable@vger.kernel.org
    Fixes: 7af82ff90a2b06 ("powerpc/ftrace: Ignore weak functions")
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/7b265908a9461e38fc756ef9b569703860a80621.1687166935.git.naveen@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/iommu: Fix notifiers being shared by PCI and VIO buses [+ + +]
Author: Russell Currey <ruscur@russell.cc>
Date:   Wed Mar 22 14:53:22 2023 +1100

    powerpc/iommu: Fix notifiers being shared by PCI and VIO buses
    
    [ Upstream commit c37b6908f7b2bd24dcaaf14a180e28c9132b9c58 ]
    
    fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both
    PCI and VIO buses.  struct notifier_block is a linked list node, so this
    causes any notifiers later registered to either bus type to also be
    registered to the other since they share the same node.
    
    This causes issues in (at least) the vgaarb code, which registers a
    notifier for PCI buses.  pci_notify() ends up being called on a vio
    device, converted with to_pci_dev() even though it's not a PCI device,
    and finally makes a bad access in vga_arbiter_add_pci_device() as
    discovered with KASAN:
    
     BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00
     Read of size 4 at addr c000000264c26fdc by task swapper/0/1
    
     Call Trace:
       dump_stack_lvl+0x1bc/0x2b8 (unreliable)
       print_report+0x3f4/0xc60
       kasan_report+0x244/0x698
       __asan_load4+0xe8/0x250
       vga_arbiter_add_pci_device+0x60/0xe00
       pci_notify+0x88/0x444
       notifier_call_chain+0x104/0x320
       blocking_notifier_call_chain+0xa0/0x140
       device_add+0xac8/0x1d30
       device_register+0x58/0x80
       vio_register_device_node+0x9ac/0xce0
       vio_bus_scan_register_devices+0xc4/0x13c
       __machine_initcall_pseries_vio_device_init+0x94/0xf0
       do_one_initcall+0x12c/0xaa8
       kernel_init_freeable+0xa48/0xba8
       kernel_init+0x64/0x400
       ret_from_kernel_thread+0x5c/0x64
    
    Fix this by creating separate notifier_block structs for each bus type.
    
    Fixes: d6b9a81b2a45 ("powerpc: IOMMU fault injection")
    Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
    Signed-off-by: Russell Currey <ruscur@russell.cc>
    Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
    Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
    [mpe: Add #ifdef to fix CONFIG_IBMVIO=n build]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230322035322.328709-1-ruscur@russell.cc
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/mpc5xxx: Add missing fwnode_handle_put() [+ + +]
Author: Liang He <windhl@126.com>
Date:   Wed Mar 22 11:04:23 2023 +0800

    powerpc/mpc5xxx: Add missing fwnode_handle_put()
    
    [ Upstream commit b9bbbf4979073d5536b7650decd37fcb901e6556 ]
    
    In mpc5xxx_fwnode_get_bus_frequency(), we should add
    fwnode_handle_put() when break out of the iteration
    fwnode_for_each_parent_node() as it will automatically
    increase and decrease the refcounter.
    
    Fixes: de06fba62af6 ("powerpc/mpc5xxx: Switch mpc5xxx_get_bus_frequency() to use fwnode")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230322030423.1855440-1-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/perf: Convert fsl_emb notifier to state machine callbacks [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Fri Aug 18 10:59:44 2023 +0200

    powerpc/perf: Convert fsl_emb notifier to state machine callbacks
    
    [ Upstream commit 34daf445f82bd3a4df852bb5f1dffd792ac830a0 ]
    
      CC      arch/powerpc/perf/core-fsl-emb.o
    arch/powerpc/perf/core-fsl-emb.c:675:6: error: no previous prototype for 'hw_perf_event_setup' [-Werror=missing-prototypes]
      675 | void hw_perf_event_setup(int cpu)
          |      ^~~~~~~~~~~~~~~~~~~
    
    Looks like fsl_emb was completely missed by commit 3f6da3905398 ("perf:
    Rework and fix the arch CPU-hotplug hooks")
    
    So, apply same changes as commit 3f6da3905398 ("perf: Rework and fix
    the arch CPU-hotplug hooks") then commit 57ecde42cc74 ("powerpc/perf:
    Convert book3s notifier to state machine callbacks")
    
    While at it, also fix following error:
    
    arch/powerpc/perf/core-fsl-emb.c: In function 'perf_event_interrupt':
    arch/powerpc/perf/core-fsl-emb.c:648:13: error: variable 'found' set but not used [-Werror=unused-but-set-variable]
      648 |         int found = 0;
          |             ^~~~~
    
    Fixes: 3f6da3905398 ("perf: Rework and fix the arch CPU-hotplug hooks")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/603e1facb32608f88f40b7d7b9094adc50e7b2dc.1692349125.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/powermac: Use early_* IO variants in via_calibrate_decr() [+ + +]
Author: Benjamin Gray <bgray@linux.ibm.com>
Date:   Thu Jul 6 11:08:16 2023 +1000

    powerpc/powermac: Use early_* IO variants in via_calibrate_decr()
    
    [ Upstream commit 86582e6189dd8f9f52c25d46c70fe5d111da6345 ]
    
    On a powermac platform, via the call path:
    
      start_kernel()
        time_init()
          ppc_md.calibrate_decr() (pmac_calibrate_decr)
            via_calibrate_decr()
    
    ioremap() and iounmap() are called. The unmap can enable interrupts
    unexpectedly (cond_resched() in vunmap_pmd_range()), which causes a
    warning later in the boot sequence in start_kernel().
    
    Use the early_* variants of these IO functions to prevent this.
    
    The issue is pre-existing, but is surfaced by commit 721255b9826b
    ("genirq: Use a maple tree for interrupt descriptor management").
    
    Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230706010816.72682-1-bgray@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries: Fix hcall tracepoints with JUMP_LABEL=n [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue May 9 19:15:59 2023 +1000

    powerpc/pseries: Fix hcall tracepoints with JUMP_LABEL=n
    
    [ Upstream commit 750bd41aeaeb1f0e0128aa4f8fcd6dd759713641 ]
    
    With JUMP_LABEL=n, hcall_tracepoint_refcount's address is being tested
    instead of its value. This results in the tracing slowpath always being
    taken unnecessarily.
    
    Fixes: 9a10ccb29c0a2 ("powerpc/pseries: move hcall_tracepoint_refcount out of .toc")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230509091600.70994-1-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT [+ + +]
Author: Russell Currey <ruscur@russell.cc>
Date:   Wed Aug 23 15:53:17 2023 +1000

    powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
    
    [ Upstream commit eac030b22ea12cdfcbb2e941c21c03964403c63f ]
    
    lppaca_shared_proc() takes a pointer to the lppaca which is typically
    accessed through get_lppaca().  With DEBUG_PREEMPT enabled, this leads
    to checking if preemption is enabled, for example:
    
      BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
      caller is lparcfg_data+0x408/0x19a0
      CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
      Call Trace:
        dump_stack_lvl+0x154/0x200 (unreliable)
        check_preemption_disabled+0x214/0x220
        lparcfg_data+0x408/0x19a0
        ...
    
    This isn't actually a problem however, as it does not matter which
    lppaca is accessed, the shared proc state will be the same.
    vcpudispatch_stats_procfs_init() already works around this by disabling
    preemption, but the lparcfg code does not, erroring any time
    /proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.
    
    Instead of disabling preemption on the caller side, rework
    lppaca_shared_proc() to not take a pointer and instead directly access
    the lppaca, bypassing any potential preemption checks.
    
    Fixes: f13c13a00512 ("powerpc: Stop using non-architected shared_proc field in lppaca")
    Signed-off-by: Russell Currey <ruscur@russell.cc>
    [mpe: Rework to avoid needing a definition in paca.h and lppaca.h]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230823055317.751786-4-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Wed Aug 9 10:01:43 2023 +0200

    powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
    
    [ Upstream commit 4a9dd8f292efd614f0a18452e6474fe19ae17b47 ]
    
    With skiboot_defconfig, Clang reports:
    
      CC      arch/powerpc/mm/book3s64/radix_tlb.o
    arch/powerpc/mm/book3s64/radix_tlb.c:419:20: error: unused function '_tlbie_pid_lpid' [-Werror,-Wunused-function]
    static inline void _tlbie_pid_lpid(unsigned long pid, unsigned long lpid,
                       ^
    arch/powerpc/mm/book3s64/radix_tlb.c:663:20: error: unused function '_tlbie_va_range_lpid' [-Werror,-Wunused-function]
    static inline void _tlbie_va_range_lpid(unsigned long start, unsigned long end,
                       ^
    
    This is because those functions are only called from functions
    enclosed in a #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
    
    Move below functions inside that #ifdef
    * __tlbie_pid_lpid(unsigned long pid,
    * __tlbie_va_lpid(unsigned long va, unsigned long pid,
    * fixup_tlbie_pid_lpid(unsigned long pid, unsigned long lpid)
    * _tlbie_pid_lpid(unsigned long pid, unsigned long lpid,
    * fixup_tlbie_va_range_lpid(unsigned long va,
    * __tlbie_va_range_lpid(unsigned long start, unsigned long end,
    * _tlbie_va_range_lpid(unsigned long start, unsigned long end,
    
    Fixes: f0c6fbbb9050 ("KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202307260802.Mjr99P5O-lkp@intel.com/
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/3d72efd39f986ee939d068af69fdce28bd600766.1691568093.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: Don't include lppaca.h in paca.h [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Aug 23 15:53:16 2023 +1000

    powerpc: Don't include lppaca.h in paca.h
    
    [ Upstream commit 1aa000667669fa855853decbb1c69e974d8ff716 ]
    
    By adding a forward declaration for struct lppaca we can untangle paca.h
    and lppaca.h. Also move get_lppaca() into lppaca.h for consistency.
    
    Add includes of lppaca.h to some files that need it.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230823055317.751786-3-mpe@ellerman.id.au
    Stable-dep-of: eac030b22ea1 ("powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
printk: ringbuffer: Fix truncating buffer size min_t cast [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Aug 10 22:45:32 2023 -0700

    printk: ringbuffer: Fix truncating buffer size min_t cast
    
    commit 53e9e33ede37a247d926db5e4a9e56b55204e66c upstream.
    
    If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in
    copy_data() was causing writes to truncate. This manifested as output
    bytes being skipped, seen as %NUL bytes in pstore dumps when the available
    record size was larger than 65536. Fix the cast to no longer truncate
    the calculation.
    
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: John Ogness <john.ogness@linutronix.de>
    Reported-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
    Link: https://lore.kernel.org/lkml/d8bb1ec7-a4c5-43a2-9de0-9643a70b899f@linux.microsoft.com/
    Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Tested-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
    Tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> # Steam Deck
    Reviewed-by: Tyler Hicks (Microsoft) <code@tyhicks.com>
    Tested-by: Tyler Hicks (Microsoft) <code@tyhicks.com>
    Reviewed-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20230811054528.never.165-kees@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
procfs: block chmod on /proc/thread-self/comm [+ + +]
Author: Aleksa Sarai <cyphar@cyphar.com>
Date:   Fri Jul 14 00:09:58 2023 +1000

    procfs: block chmod on /proc/thread-self/comm
    
    commit ccf61486fe1e1a48e18c638d1813cda77b3c0737 upstream.
    
    Due to an oversight in commit 1b3044e39a89 ("procfs: fix pthread
    cross-thread naming if !PR_DUMPABLE") in switching from REG to NOD,
    chmod operations on /proc/thread-self/comm were no longer blocked as
    they are on almost all other procfs files.
    
    A very similar situation with /proc/self/environ was used to as a root
    exploit a long time ago, but procfs has SB_I_NOEXEC so this is simply a
    correctness issue.
    
    Ref: https://lwn.net/Articles/191954/
    Ref: 6d76fa58b050 ("Don't allow chmod() on the /proc/<pid>/ files")
    Fixes: 1b3044e39a89 ("procfs: fix pthread cross-thread naming if !PR_DUMPABLE")
    Cc: stable@vger.kernel.org # v4.7+
    Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
    Message-Id: <20230713141001.27046-1-cyphar@cyphar.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pstore/ram: Check start of empty przs during init [+ + +]
Author: Enlin Mu <enlin.mu@unisoc.com>
Date:   Tue Aug 1 14:04:32 2023 +0800

    pstore/ram: Check start of empty przs during init
    
    commit fe8c3623ab06603eb760444a032d426542212021 upstream.
    
    After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as
    valid"), initialization would assume a prz was valid after seeing that
    the buffer_size is zero (regardless of the buffer start position). This
    unchecked start value means it could be outside the bounds of the buffer,
    leading to future access panics when written to:
    
     sysdump_panic_event+0x3b4/0x5b8
     atomic_notifier_call_chain+0x54/0x90
     panic+0x1c8/0x42c
     die+0x29c/0x2a8
     die_kernel_fault+0x68/0x78
     __do_kernel_fault+0x1c4/0x1e0
     do_bad_area+0x40/0x100
     do_translation_fault+0x68/0x80
     do_mem_abort+0x68/0xf8
     el1_da+0x1c/0xc0
     __raw_writeb+0x38/0x174
     __memcpy_toio+0x40/0xac
     persistent_ram_update+0x44/0x12c
     persistent_ram_write+0x1a8/0x1b8
     ramoops_pstore_write+0x198/0x1e8
     pstore_console_write+0x94/0xe0
     ...
    
    To avoid this, also check if the prz start is 0 during the initialization
    phase. If not, the next prz sanity check case will discover it (start >
    size) and zap the buffer back to a sane state.
    
    Fixes: 30696378f68a ("pstore/ram: Do not treat empty buffers as valid")
    Cc: Yunlong Xing <yunlong.xing@unisoc.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
    Link: https://lore.kernel.org/r/20230801060432.1307717-1-yunlong.xing@unisoc.com
    [kees: update commit log with backtrace and clarifications]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
quota: add new helper dquot_active() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 30 19:08:20 2023 +0800

    quota: add new helper dquot_active()
    
    [ Upstream commit 33bcfafc48cb186bc4bbcea247feaa396594229e ]
    
    Add new helper function dquot_active() to make the code more concise.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Message-Id: <20230630110822.3881712-4-libaokun1@huawei.com>
    Stable-dep-of: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

quota: factor out dquot_write_dquot() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 30 19:08:18 2023 +0800

    quota: factor out dquot_write_dquot()
    
    [ Upstream commit 024128477809f8073d870307c8157b8826ebfd08 ]
    
    Refactor out dquot_write_dquot() to reduce duplicate code.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Message-Id: <20230630110822.3881712-2-libaokun1@huawei.com>
    Stable-dep-of: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

quota: fix dqput() to follow the guarantees dquot_srcu should provide [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 30 19:08:21 2023 +0800

    quota: fix dqput() to follow the guarantees dquot_srcu should provide
    
    [ Upstream commit dabc8b20756601b9e1cc85a81d47d3f98ed4d13a ]
    
    The dquot_mark_dquot_dirty() using dquot references from the inode
    should be protected by dquot_srcu. quota_off code takes care to call
    synchronize_srcu(&dquot_srcu) to not drop dquot references while they
    are used by other users. But dquot_transfer() breaks this assumption.
    We call dquot_transfer() to drop the last reference of dquot and add
    it to free_dquots, but there may still be other users using the dquot
    at this time, as shown in the function graph below:
    
           cpu1              cpu2
    _________________|_________________
    wb_do_writeback         CHOWN(1)
     ...
      ext4_da_update_reserve_space
       dquot_claim_block
        ...
         dquot_mark_dquot_dirty // try to dirty old quota
          test_bit(DQ_ACTIVE_B, &dquot->dq_flags) // still ACTIVE
          if (test_bit(DQ_MOD_B, &dquot->dq_flags))
          // test no dirty, wait dq_list_lock
                        ...
                         dquot_transfer
                          __dquot_transfer
                          dqput_all(transfer_from) // rls old dquot
                           dqput // last dqput
                            dquot_release
                             clear_bit(DQ_ACTIVE_B, &dquot->dq_flags)
                            atomic_dec(&dquot->dq_count)
                            put_dquot_last(dquot)
                             list_add_tail(&dquot->dq_free, &free_dquots)
                             // add the dquot to free_dquots
          if (!test_and_set_bit(DQ_MOD_B, &dquot->dq_flags))
            add dqi_dirty_list // add released dquot to dirty_list
    
    This can cause various issues, such as dquot being destroyed by
    dqcache_shrink_scan() after being added to free_dquots, which can trigger
    a UAF in dquot_mark_dquot_dirty(); or after dquot is added to free_dquots
    and then to dirty_list, it is added to free_dquots again after
    dquot_writeback_dquots() is executed, which causes the free_dquots list to
    be corrupted and triggers a UAF when dqcache_shrink_scan() is called for
    freeing dquot twice.
    
    As Honza said, we need to fix dquot_transfer() to follow the guarantees
    dquot_srcu should provide. But calling synchronize_srcu() directly from
    dquot_transfer() is too expensive (and mostly unnecessary). So we add
    dquot whose last reference should be dropped to the new global dquot
    list releasing_dquots, and then queue work item which would call
    synchronize_srcu() and after that perform the final cleanup of all the
    dquots on releasing_dquots.
    
    Fixes: 4580b30ea887 ("quota: Do not dirty bad dquots")
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Message-Id: <20230630110822.3881712-5-libaokun1@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

quota: rename dquot_active() to inode_quota_active() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Jun 30 19:08:19 2023 +0800

    quota: rename dquot_active() to inode_quota_active()
    
    [ Upstream commit 4b9bdfa16535de8f49bf954aeed0f525ee2fc322 ]
    
    Now we have a helper function dquot_dirty() to determine if dquot has
    DQ_MOD_B bit. dquot_active() can easily be misunderstood as a helper
    function to determine if dquot has DQ_ACTIVE_B bit. So we avoid this by
    renaming it to inode_quota_active() and later on we will add the helper
    function dquot_active() to determine if dquot has DQ_ACTIVE_B bit.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Message-Id: <20230630110822.3881712-3-libaokun1@huawei.com>
    Stable-dep-of: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r8169: fix ASPM-related issues on a number of systems with NIC version from RTL8168h [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Fri Aug 25 21:44:01 2023 +0200

    r8169: fix ASPM-related issues on a number of systems with NIC version from RTL8168h
    
    commit 90ca51e8c654699b672ba61aeaa418dfb3252e5e upstream.
    
    This effectively reverts 4b5f82f6aaef. On a number of systems ASPM L1
    causes tx timeouts with RTL8168h, see referenced bug report.
    
    Fixes: 4b5f82f6aaef ("r8169: enable ASPM L1/L1.1 from RTL8168h")
    Cc: stable@vger.kernel.org
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217814
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rcu: dump vmalloc memory info safely [+ + +]
Author: Zqiang <qiang.zhang1211@gmail.com>
Date:   Mon Sep 4 18:08:05 2023 +0000

    rcu: dump vmalloc memory info safely
    
    commit c83ad36a18c02c0f51280b50272327807916987f upstream.
    
    Currently, for double invoke call_rcu(), will dump rcu_head objects memory
    info, if the objects is not allocated from the slab allocator, the
    vmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need to
    be held, since the call_rcu() can be invoked in interrupt context,
    therefore, there is a possibility of spinlock deadlock scenarios.
    
    And in Preempt-RT kernel, the rcutorture test also trigger the following
    lockdep warning:
    
    BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
    preempt_count: 1, expected: 0
    RCU nest depth: 1, expected: 1
    3 locks held by swapper/0/1:
     #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0
     #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370
     #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70
    irq event stamp: 565512
    hardirqs last  enabled at (565511): [<ffffffffb379b138>] __call_rcu_common+0x218/0x940
    hardirqs last disabled at (565512): [<ffffffffb5804262>] rcu_torture_init+0x20b2/0x2370
    softirqs last  enabled at (399112): [<ffffffffb36b2586>] __local_bh_enable_ip+0x126/0x170
    softirqs last disabled at (399106): [<ffffffffb43fef59>] inet_register_protosw+0x9/0x1d0
    Preemption disabled at:
    [<ffffffffb58040c3>] rcu_torture_init+0x1f13/0x2370
    CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W          6.5.0-rc4-rt2-yocto-preempt-rt+ #15
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x68/0xb0
     dump_stack+0x14/0x20
     __might_resched+0x1aa/0x280
     ? __pfx_rcu_torture_err_cb+0x10/0x10
     rt_spin_lock+0x53/0x130
     ? find_vmap_area+0x1f/0x70
     find_vmap_area+0x1f/0x70
     vmalloc_dump_obj+0x20/0x60
     mem_dump_obj+0x22/0x90
     __call_rcu_common+0x5bf/0x940
     ? debug_smp_processor_id+0x1b/0x30
     call_rcu_hurry+0x14/0x20
     rcu_torture_init+0x1f82/0x2370
     ? __pfx_rcu_torture_leak_cb+0x10/0x10
     ? __pfx_rcu_torture_leak_cb+0x10/0x10
     ? __pfx_rcu_torture_init+0x10/0x10
     do_one_initcall+0x6c/0x300
     ? debug_smp_processor_id+0x1b/0x30
     kernel_init_freeable+0x2b9/0x540
     ? __pfx_kernel_init+0x10/0x10
     kernel_init+0x1f/0x150
     ret_from_fork+0x40/0x50
     ? __pfx_kernel_init+0x10/0x10
     ret_from_fork_asm+0x1b/0x30
     </TASK>
    
    The previous patch fixes this by using the deadlock-safe best-effort
    version of find_vm_area.  However, in case of failure print the fact that
    the pointer was a vmalloc pointer so that we print at least something.
    
    Link: https://lkml.kernel.org/r/20230904180806.1002832-2-joel@joelfernandes.org
    Fixes: 98f180837a89 ("mm: Make mem_dump_obj() handle vmalloc() memory")
    Signed-off-by: Zqiang <qiang.zhang1211@gmail.com>
    Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Reported-by: Zhen Lei <thunder.leizhen@huaweicloud.com>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Paul E. McKenney <paulmck@kernel.org>
    Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/bnxt_re: Remove a redundant flag [+ + +]
Author: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Date:   Thu Aug 3 01:45:22 2023 -0700

    RDMA/bnxt_re: Remove a redundant flag
    
    [ Upstream commit fd28c8a8c7a10e7b53851129c6d8dc5945108fe9 ]
    
    After the cited commit, BNXT_RE_FLAG_GOT_MSIX is redundant.
    Remove it.
    
    Fixes: 303432211324 ("bnxt_en: Remove runtime interrupt vector allocation")
    Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1691052326-32143-3-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/efa: Fix wrong resources deallocation order [+ + +]
Author: Yonatan Nachum <ynachum@amazon.com>
Date:   Tue Aug 22 08:27:25 2023 +0000

    RDMA/efa: Fix wrong resources deallocation order
    
    [ Upstream commit dc202c57e9a1423aed528e4b8dc949509cd32191 ]
    
    When trying to destroy QP or CQ, we first decrease the refcount and
    potentially free memory regions allocated for the object and then
    request the device to destroy the object. If the device fails, the
    object isn't fully destroyed so the user/IB core can try to destroy the
    object again which will lead to underflow when trying to decrease an
    already zeroed refcount.
    
    Deallocate resources in reverse order of allocating them to safely free
    them.
    
    Fixes: ff6629f88c52 ("RDMA/efa: Do not delay freeing of DMA pages")
    Reviewed-by: Michael Margolin <mrgolin@amazon.com>
    Reviewed-by: Yossi Leybovich <sleybo@amazon.com>
    Signed-off-by: Yonatan Nachum <ynachum@amazon.com>
    Link: https://lore.kernel.org/r/20230822082725.31719-1-ynachum@amazon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hns: Fix CQ and QP cache affinity [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Fri Aug 4 09:27:11 2023 +0800

    RDMA/hns: Fix CQ and QP cache affinity
    
    [ Upstream commit 9e03dbea2b0634b21a45946b4f8097e0dc86ebe1 ]
    
    Currently, the affinity between QP cache and CQ cache is not
    considered when assigning QPN, it will affect the message rate of HW.
    
    Allocate QPN from QP cache with better CQ affinity to get better
    performance.
    
    Fixes: 71586dd20010 ("RDMA/hns: Create QP with selected QPN for bank load balance")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20230804012711.808069-5-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix inaccurate error label name in init instance [+ + +]
Author: Junxian Huang <huangjunxian6@hisilicon.com>
Date:   Fri Aug 4 09:27:10 2023 +0800

    RDMA/hns: Fix inaccurate error label name in init instance
    
    [ Upstream commit c9c0bd3c177d93d80968f720304087ba83fe8f74 ]
    
    This patch fixes inaccurate error label name in init instance.
    
    Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT")
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20230804012711.808069-4-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix incorrect post-send with direct wqe of wr-list [+ + +]
Author: Junxian Huang <huangjunxian6@hisilicon.com>
Date:   Fri Aug 4 09:27:09 2023 +0800

    RDMA/hns: Fix incorrect post-send with direct wqe of wr-list
    
    [ Upstream commit 706efac4477cdb8be857f6322457de524acc02ff ]
    
    Currently, direct wqe is not supported for wr-list. RoCE driver excludes
    direct wqe for wr-list by judging whether the number of wr is 1.
    
    For a wr-list where the second wr is a length-error atomic wr, the
    post-send driver handles the first wr and adds 1 to the wr number counter
    firstly. While handling the second wr, the driver finds out a length error
    and terminates the wr handle process, remaining the counter at 1. This
    causes the driver mistakenly judges there is only 1 wr and thus enters
    the direct wqe process, carrying the current length-error atomic wqe.
    
    This patch fixes the error by adding a judgement whether the current wr
    is a bad wr. If so, use the normal doorbell process but not direct wqe
    despite the wr number is 1.
    
    Fixes: 01584a5edcc4 ("RDMA/hns: Add support of direct wqe")
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20230804012711.808069-3-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix port active speed [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Fri Aug 4 09:27:08 2023 +0800

    RDMA/hns: Fix port active speed
    
    [ Upstream commit df1bcf90a66a10967a3a43510b42cb3566208011 ]
    
    HW supports a variety of different speed, but the current speed
    is fixed.
    
    The real speed should be querried from ethernet.
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20230804012711.808069-2-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/irdma: Prevent zero-length STAG registration [+ + +]
Author: Christopher Bednarz <christopher.n.bednarz@intel.com>
Date:   Fri Aug 18 09:48:38 2023 -0500

    RDMA/irdma: Prevent zero-length STAG registration
    
    [ Upstream commit bb6d73d9add68ad270888db327514384dfa44958 ]
    
    Currently irdma allows zero-length STAGs to be programmed in HW during
    the kernel mode fast register flow. Zero-length MR or STAG registration
    disable HW memory length checks.
    
    Improve gaps in bounds checking in irdma by preventing zero-length STAG or
    MR registrations except if the IB_PD_UNSAFE_GLOBAL_RKEY is set.
    
    This addresses the disclosure CVE-2023-25775.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Christopher Bednarz <christopher.n.bednarz@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Link: https://lore.kernel.org/r/20230818144838.1758-1-shiraz.saleem@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/irdma: Replace one-element array with flexible-array member [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Wed Aug 2 08:46:26 2023 -0600

    RDMA/irdma: Replace one-element array with flexible-array member
    
    [ Upstream commit 38313c6d2a02c28162e06753b01bd885caf9386d ]
    
    One-element and zero-length arrays are deprecated. So, replace
    one-element array in struct irdma_qvlist_info with flexible-array
    member.
    
    A patch for this was sent a while ago[1]. However, it seems that, at
    the time, the changes were partially folded[2][3], and the actual
    flexible-array transformation was omitted. This patch fixes that.
    
    The only binary difference seen before/after changes is shown below:
    
    |  drivers/infiniband/hw/irdma/hw.o
    | @@ -868,7 +868,7 @@
    | drivers/infiniband/hw/irdma/hw.c:484 (discriminator 2)
    |       size += struct_size(iw_qvlist, qv_info, rf->msix_count);
    |      55b:      imul   $0x45c,%rdi,%rdi
    |-     562:      add    $0x10,%rdi
    |+     562:      add    $0x4,%rdi
    
    which is, of course, expected as it reflects the mistake made
    while folding the patch I've mentioned above.
    
    Worth mentioning is the fact that with this change we save 12 bytes
    of memory, as can be inferred from the diff snapshot above. Notice
    that:
    
    $ pahole -C rdma_qv_info idrivers/infiniband/hw/irdma/hw.o
    struct irdma_qv_info {
            u32                        v_idx;                /*     0     4 */
            u16                        ceq_idx;              /*     4     2 */
            u16                        aeq_idx;              /*     6     2 */
            u8                         itr_idx;              /*     8     1 */
    
            /* size: 12, cachelines: 1, members: 4 */
            /* padding: 3 */
            /* last cacheline: 12 bytes */
    };
    
    Link: https://lore.kernel.org/linux-hardening/20210525230038.GA175516@embeddedor/ [1]
    Link: https://lore.kernel.org/linux-hardening/bf46b428deef4e9e89b0ea1704b1f0e5@intel.com/ [2]
    Link: https://lore.kernel.org/linux-rdma/20210520143809.819-1-shiraz.saleem@intel.com/T/#u [3]
    Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions")
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Link: https://lore.kernel.org/r/ZMpsQrZadBaJGkt4@work
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/qedr: Remove a duplicate assignment in irdma_query_ah() [+ + +]
Author: Minjie Du <duminjie@vivo.com>
Date:   Thu Jul 6 10:27:03 2023 +0800

    RDMA/qedr: Remove a duplicate assignment in irdma_query_ah()
    
    [ Upstream commit 65e02e840847158c7ee48ca8e6e91062b0f78662 ]
    
    Delete a duplicate statement from this function implementation.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Minjie Du <duminjie@vivo.com>
    Acked-by: Alok Prasad <palok@marvell.com>
    Link: https://lore.kernel.org/r/20230706022704.1260-1-duminjie@vivo.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rxe: Fix incomplete state save in rxe_requester [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Fri Jul 21 15:07:49 2023 -0500

    RDMA/rxe: Fix incomplete state save in rxe_requester
    
    [ Upstream commit 5d122db2ff80cd2aed4dcd630befb56b51ddf947 ]
    
    If a send packet is dropped by the IP layer in rxe_requester()
    the call to rxe_xmit_packet() can fail with err == -EAGAIN.
    To recover, the state of the wqe is restored to the state before
    the packet was sent so it can be resent. However, the routines
    that save and restore the state miss a significnt part of the
    variable state in the wqe, the dma struct which is used to process
    through the sge table. And, the state is not saved before the packet
    is built which modifies the dma struct.
    
    Under heavy stress testing with many QPs on a fast node sending
    large messages to a slow node dropped packets are observed and
    the resent packets are corrupted because the dma struct was not
    restored. This patch fixes this behavior and allows the test cases
    to succeed.
    
    Fixes: 3050b9985024 ("IB/rxe: Fix race condition between requester and completer")
    Link: https://lore.kernel.org/r/20230721200748.4604-1-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Fix rxe_modify_srq [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Tue Jun 20 09:01:43 2023 -0500

    RDMA/rxe: Fix rxe_modify_srq
    
    [ Upstream commit cc28f351155def8db209647f2e20a59a7080825b ]
    
    This patch corrects an error in rxe_modify_srq where if the
    caller changes the srq size the actual new value is not returned
    to the caller since it may be larger than what is requested.
    Additionally it open codes the subroutine rcv_wqe_size() which
    adds very little value, and makes some whitespace changes.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20230620140142.9452-1-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Fix unsafe drain work queue code [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Tue Jun 20 08:55:21 2023 -0500

    RDMA/rxe: Fix unsafe drain work queue code
    
    [ Upstream commit 5993b75d0bc71cd2b441d174b028fc36180f032c ]
    
    If create_qp does not fully succeed it is possible for qp cleanup
    code to attempt to drain the send or recv work queues before the
    queues have been created causing a seg fault. This patch checks
    to see if the queues exist before attempting to drain them.
    
    Link: https://lore.kernel.org/r/20230620135519.9365-3-rpearsonhpe@gmail.com
    Reported-by: syzbot+2da1965168e7dbcba136@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-rdma/00000000000012d89205fe7cfe00@google.com/raw
    Fixes: 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c")
    Fixes: fbdeb828a21f ("RDMA/rxe: Cleanup error state handling in rxe_comp.c")
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Move work queue code to subroutines [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Tue Jun 20 08:55:19 2023 -0500

    RDMA/rxe: Move work queue code to subroutines
    
    [ Upstream commit e0ba8ff46704fc924e2ef0451ba196cbdc0d68f2 ]
    
    This patch:
            - Moves code to initialize a qp send work queue to a
              subroutine named rxe_init_sq.
            - Moves code to initialize a qp recv work queue to a
              subroutine named rxe_init_rq.
            - Moves initialization of qp request and response packet
              queues ahead of work queue initialization so that cleanup
              of a qp if it is not fully completed can successfully
              attempt to drain the packet queues without a seg fault.
            - Makes minor whitespace cleanups.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20230620135519.9365-2-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/siw: Balance the reference of cep->kref in the error path [+ + +]
Author: Guoqing Jiang <guoqing.jiang@linux.dev>
Date:   Mon Aug 21 21:32:53 2023 +0800

    RDMA/siw: Balance the reference of cep->kref in the error path
    
    [ Upstream commit b056327bee09e6b86683d3f709a438ccd6031d72 ]
    
    The siw_connect can go to err in below after cep is allocated successfully:
    
    1. If siw_cm_alloc_work returns failure. In this case socket is not
    assoicated with cep so siw_cep_put can't be called by siw_socket_disassoc.
    We need to call siw_cep_put twice since cep->kref is increased once after
    it was initialized.
    
    2. If siw_cm_queue_work can't find a work, which means siw_cep_get is not
    called in siw_cm_queue_work, so cep->kref is increased twice by siw_cep_get
    and when associate socket with cep after it was initialized. So we need to
    call siw_cep_put three times (one in siw_socket_disassoc).
    
    3. siw_send_mpareqrep returns error, this scenario is similar as 2.
    
    So we need to remove one siw_cep_put in the error path.
    
    Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Link: https://lore.kernel.org/r/20230821133255.31111-2-guoqing.jiang@linux.dev
    Acked-by: Bernard Metzler <bmt@zurich.ibm.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/siw: Correct wrong debug message [+ + +]
Author: Guoqing Jiang <guoqing.jiang@linux.dev>
Date:   Mon Aug 21 21:32:54 2023 +0800

    RDMA/siw: Correct wrong debug message
    
    [ Upstream commit bee024d20451e4ce04ea30099cad09f7f75d288b ]
    
    We need to print num_sle first then pbl->max_buf per the condition.
    Also replace mem->pbl with pbl while at it.
    
    Fixes: 303ae1cdfdf7 ("rdma/siw: application interface")
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Link: https://lore.kernel.org/r/20230821133255.31111-3-guoqing.jiang@linux.dev
    Acked-by: Bernard Metzler <bmt@zurich.ibm.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/siw: Fabricate a GID on tun and loopback devices [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Jul 17 11:12:12 2023 -0400

    RDMA/siw: Fabricate a GID on tun and loopback devices
    
    [ Upstream commit bad5b6e34ffbaacc77ad28a0f482e33b3929e635 ]
    
    LOOPBACK and NONE (tunnel) devices have all-zero MAC addresses.
    Currently, siw_device_create() falls back to copying the IB device's
    name in those cases, because an all-zero MAC address breaks the RDMA
    core address resolution mechanism.
    
    However, at the point when siw_device_create() constructs a GID, the
    ib_device::name field is uninitialized, leaving the MAC address to
    remain in an all-zero state.
    
    Fabricate a random artificial GID for such devices, and ensure this
    artificial GID is returned for all device query operations.
    
    Link: https://lore.kernel.org/r/168960673260.3007.12378736853793339110.stgit@manet.1015granger.net
    Reported-by: Tom Talpey <tom@talpey.com>
    Fixes: a2d36b02c15d ("RDMA/siw: Enable siw on tunnel devices")
    Reviewed-by: Bernard Metzler <bmt@zurich.ibm.com>
    Reviewed-by: Tom Talpey <tom@talpey.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
refscale: Fix uninitalized use of wait_queue_head_t [+ + +]
Author: Waiman Long <longman@redhat.com>
Date:   Fri Jul 7 13:53:55 2023 -0400

    refscale: Fix uninitalized use of wait_queue_head_t
    
    [ Upstream commit f5063e8948dad7f31adb007284a5d5038ae31bb8 ]
    
    Running the refscale test occasionally crashes the kernel with the
    following error:
    
    [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8
    [ 8569.952900] #PF: supervisor read access in kernel mode
    [ 8569.952902] #PF: error_code(0x0000) - not-present page
    [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0
    [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI
    [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021
    [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190
      :
    [ 8569.952940] Call Trace:
    [ 8569.952941]  <TASK>
    [ 8569.952944]  ref_scale_reader+0x380/0x4a0 [refscale]
    [ 8569.952959]  kthread+0x10e/0x130
    [ 8569.952966]  ret_from_fork+0x1f/0x30
    [ 8569.952973]  </TASK>
    
    The likely cause is that init_waitqueue_head() is called after the call to
    the torture_create_kthread() function that creates the ref_scale_reader
    kthread.  Although this init_waitqueue_head() call will very likely
    complete before this kthread is created and starts running, it is
    possible that the calling kthread will be delayed between the calls to
    torture_create_kthread() and init_waitqueue_head().  In this case, the
    new kthread will use the waitqueue head before it is properly initialized,
    which is not good for the kernel's health and well-being.
    
    The above crash happened here:
    
            static inline void __add_wait_queue(...)
            {
                    :
                    if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here
    
    The offset of flags from list_head entry in wait_queue_entry is
    -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task
    structure is zero initialized, the instruction will try to access address
    0xffffffffffffffe8, which is exactly the fault address listed above.
    
    This commit therefore invokes init_waitqueue_head() before creating
    the kthread.
    
    Fixes: 653ed64b01dc ("refperf: Add a test to measure performance of read-side synchronization")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Acked-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regmap: Load register defaults in blocks rather than register by register [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Tue May 23 22:22:27 2023 +0100

    regmap: Load register defaults in blocks rather than register by register
    
    [ Upstream commit 3a48d2127f4dbd767d43bf8280b67d585e701f75 ]
    
    Currently we use the normal single register write function to load the
    default values into the cache, resulting in a large number of reallocations
    when there are blocks of registers as we extend the memory region we are
    using to store the values. Instead scan through the list of defaults for
    blocks of adjacent registers and do a single allocation and insert for each
    such block. No functional change.
    
    We do not take advantage of the maple tree preallocation, this is purely at
    the regcache level. It is not clear to me yet if the maple tree level would
    help much here or if we'd have more overhead from overallocating and then
    freeing maple tree data.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20230523-regcache-maple-load-defaults-v1-1-0c04336f005d@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: b0393e1fe40e ("regmap: maple: Use alloc_flags for memory allocations")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regmap: maple: Use alloc_flags for memory allocations [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Jul 20 10:20:21 2023 -0700

    regmap: maple: Use alloc_flags for memory allocations
    
    [ Upstream commit b0393e1fe40e962574613a5cdc4a470d6c1de023 ]
    
    REGCACHE_MAPLE needs to allocate memory for regmap operations.
    This results in lockdep splats if used with fast_io since fast_io uses
    spinlocks for locking.
    
    BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
    in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 167, name: kunit_try_catch
    preempt_count: 1, expected: 0
    1 lock held by kunit_try_catch/167:
     #0: 838e9c10 (regmap_kunit:86:(config)->lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c
    irq event stamp: 146
    hardirqs last  enabled at (145): [<8078bfa8>] crng_make_state+0x1a0/0x294
    hardirqs last disabled at (146): [<80c5f62c>] _raw_spin_lock_irqsave+0x7c/0x80
    softirqs last  enabled at (0): [<80110cc4>] copy_process+0x810/0x216c
    softirqs last disabled at (0): [<00000000>] 0x0
    CPU: 0 PID: 167 Comm: kunit_try_catch Tainted: G                 N 6.5.0-rc1-00028-gc4be22597a36-dirty #6
    Hardware name: Generic DT based system
     unwind_backtrace from show_stack+0x18/0x1c
     show_stack from dump_stack_lvl+0x38/0x5c
     dump_stack_lvl from __might_resched+0x188/0x2d0
     __might_resched from __kmem_cache_alloc_node+0x1f4/0x258
     __kmem_cache_alloc_node from __kmalloc+0x48/0x170
     __kmalloc from regcache_maple_write+0x194/0x248
     regcache_maple_write from _regmap_write+0x88/0x140
     _regmap_write from regmap_write+0x44/0x68
     regmap_write from basic_read_write+0x8c/0x27c
     basic_read_write from kunit_generic_run_threadfn_adapter+0x1c/0x28
     kunit_generic_run_threadfn_adapter from kthread+0xf8/0x120
     kthread from ret_from_fork+0x14/0x3c
    Exception stack(0x881a5fb0 to 0x881a5ff8)
    5fa0:                                     00000000 00000000 00000000 00000000
    5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
    
    Use map->alloc_flags instead of GFP_KERNEL for memory allocations to fix
    the problem.
    
    Fixes: f033c26de5a5 ("regmap: Add maple tree based register cache")
    Cc: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20230720172021.2617326-1-linux@roeck-us.net
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regmap: rbtree: Use alloc_flags for memory allocations [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Jul 21 17:55:33 2023 +0300

    regmap: rbtree: Use alloc_flags for memory allocations
    
    [ Upstream commit 0c8b0bf42c8cef56f7cd9cd876fbb7ece9217064 ]
    
    The kunit tests discovered a sleeping in atomic bug.  The allocations
    in the regcache-rbtree code should use the map->alloc_flags instead of
    GFP_KERNEL.
    
    [    5.005510] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
    [    5.005960] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 117, name: kunit_try_catch
    [    5.006219] preempt_count: 1, expected: 0
    [    5.006414] 1 lock held by kunit_try_catch/117:
    [    5.006590]  #0: 833b9010 (regmap_kunit:86:(config)->lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c
    [    5.007493] irq event stamp: 162
    [    5.007627] hardirqs last  enabled at (161): [<80786738>] crng_make_state+0x1a0/0x294
    [    5.007871] hardirqs last disabled at (162): [<80c531ec>] _raw_spin_lock_irqsave+0x7c/0x80
    [    5.008119] softirqs last  enabled at (0): [<801110ac>] copy_process+0x810/0x2138
    [    5.008356] softirqs last disabled at (0): [<00000000>] 0x0
    [    5.008688] CPU: 0 PID: 117 Comm: kunit_try_catch Tainted: G                 N 6.4.4-rc3-g0e8d2fdfb188 #1
    [    5.009011] Hardware name: Generic DT based system
    [    5.009277]  unwind_backtrace from show_stack+0x18/0x1c
    [    5.009497]  show_stack from dump_stack_lvl+0x38/0x5c
    [    5.009676]  dump_stack_lvl from __might_resched+0x188/0x2d0
    [    5.009860]  __might_resched from __kmem_cache_alloc_node+0x1dc/0x25c
    [    5.010061]  __kmem_cache_alloc_node from kmalloc_trace+0x30/0xc8
    [    5.010254]  kmalloc_trace from regcache_rbtree_write+0x26c/0x468
    [    5.010446]  regcache_rbtree_write from _regmap_write+0x88/0x140
    [    5.010634]  _regmap_write from regmap_write+0x44/0x68
    [    5.010803]  regmap_write from basic_read_write+0x8c/0x270
    [    5.010980]  basic_read_write from kunit_try_run_case+0x48/0xa0
    
    Fixes: 28644c809f44 ("regmap: Add the rbtree cache support")
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Closes: https://lore.kernel.org/all/ee59d128-413c-48ad-a3aa-d9d350c80042@roeck-us.net/
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/58f12a07-5f4b-4a8f-ab84-0a42d1908cb9@moroto.mountain
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: dt-bindings: qcom,rpm: fix pattern for children [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Jul 25 18:40:47 2023 +0200

    regulator: dt-bindings: qcom,rpm: fix pattern for children
    
    commit 75d9bf03e2fa38242b35e941ce7c7cdabe479961 upstream.
    
    The "or" (|) in regular expression must be within parentheses,
    otherwise it is not really an "or" and it matches supplies:
    
      qcom-apq8060-dragonboard.dtb: regulators-1: vdd_ncp-supply: [[34]] is not of type 'object'
    
    Fixes: fde0e25b71a9 ("dt-bindings: regulators: convert non-smd RPM Regulators bindings to dt-schema")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230725164047.368892-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
reiserfs: Check the return value from __getblk() [+ + +]
Author: Matthew Wilcox <willy@infradead.org>
Date:   Sun Jun 4 12:16:06 2023 +0100

    reiserfs: Check the return value from __getblk()
    
    [ Upstream commit ba38980add7ffc9e674ada5b4ded4e7d14e76581 ]
    
    __getblk() can return a NULL pointer if we run out of memory or if we
    try to access beyond the end of the device; check it and handle it
    appropriately.
    
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Link: https://lore.kernel.org/lkml/CAFcO6XOacq3hscbXevPQP7sXRoYFz34ZdKPYjmd6k5sZuhGFDw@mail.gmail.com/
    Tested-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") # probably introduced in 2002
    Acked-by: Edward Shishkin <edward.shishkin@gmail.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "bridge: Add extack warning when enabling STP in netns." [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jul 18 10:41:52 2023 -0700

    Revert "bridge: Add extack warning when enabling STP in netns."
    
    [ Upstream commit 7ebd00a5a20c48e6020d49a3b2afb3cdfd2da8b7 ]
    
    This reverts commit 56a16035bb6effb37177867cea94c13a8382f745.
    
    Since the previous commit, STP works on bridge in netns.
    
      # unshare -n
      # ip link add br0 type bridge
      # ip link add veth0 type veth peer name veth1
    
      # ip link set veth0 master br0 up
      [   50.558135] br0: port 1(veth0) entered blocking state
      [   50.558366] br0: port 1(veth0) entered disabled state
      [   50.558798] veth0: entered allmulticast mode
      [   50.564401] veth0: entered promiscuous mode
    
      # ip link set veth1 master br0 up
      [   54.215487] br0: port 2(veth1) entered blocking state
      [   54.215657] br0: port 2(veth1) entered disabled state
      [   54.215848] veth1: entered allmulticast mode
      [   54.219577] veth1: entered promiscuous mode
    
      # ip link set br0 type bridge stp_state 1
      # ip link set br0 up
      [   61.960726] br0: port 2(veth1) entered blocking state
      [   61.961097] br0: port 2(veth1) entered listening state
      [   61.961495] br0: port 1(veth0) entered blocking state
      [   61.961653] br0: port 1(veth0) entered listening state
      [   63.998835] br0: port 2(veth1) entered blocking state
      [   77.437113] br0: port 1(veth0) entered learning state
      [   86.653501] br0: received packet on veth0 with own address as source address (addr:6e:0f:e7:6f:5f:5f, vlan:0)
      [   92.797095] br0: port 1(veth0) entered forwarding state
      [   92.797398] br0: topology change detected, propagating
    
    Let's remove the warning.
    
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
Revert "drm/amd/display: Do not set drr on pipe commit" [+ + +]
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Mon May 22 15:08:23 2023 +0200

    Revert "drm/amd/display: Do not set drr on pipe commit"
    
    commit 360930985ec9f394c82ba0b235403b4a366d1560 upstream.
    
    This reverts commit e101bf95ea87ccc03ac2f48dfc0757c6364ff3c7.
    
    Caused a regression:
    
    Samsung Odyssey Neo G9, running at 5120x1440@240/VRR, connected to Navi
    21 via DisplayPort, blanks and the GPU hangs while starting the Steam
    game Assetto Corsa Competizione (via Proton 7.0).
    
    Example dmesg excerpt:
    
     amdgpu 0000:0c:00.0: [drm] ERROR [CRTC:82:crtc-0] flip_done timed out
     NMI watchdog: Watchdog detected hard LOCKUP on cpu 6
     [...]
     RIP: 0010:amdgpu_device_rreg.part.0+0x2f/0xf0 [amdgpu]
     Code: 41 54 44 8d 24 b5 00 00 00 00 55 89 f5 53 48 89 fb 4c 3b a7 60 0b 00 00 73 6a 83 e2 02 74 29 4c 03 a3 68 0b 00 00 45 8b 24 24 <48> 8b 43 08 0f b7 70 3e 66 90 44 89 e0 5b 5d 41 5c 31 d2 31 c9 31
     RSP: 0000:ffffb39a119dfb88 EFLAGS: 00000086
     RAX: ffffffffc0eb96a0 RBX: ffff9e7963dc0000 RCX: 0000000000007fff
     RDX: 0000000000000000 RSI: 0000000000004ff6 RDI: ffff9e7963dc0000
     RBP: 0000000000004ff6 R08: ffffb39a119dfc40 R09: 0000000000000010
     R10: ffffb39a119dfc40 R11: ffffb39a119dfc44 R12: 00000000000e05ae
     R13: 0000000000000000 R14: ffff9e7963dc0010 R15: 0000000000000000
     FS:  000000001012f6c0(0000) GS:ffff9e805eb80000(0000) knlGS:000000007fd40000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00000000461ca000 CR3: 00000002a8a20000 CR4: 0000000000350ee0
     Call Trace:
      <TASK>
      dm_read_reg_func+0x37/0xc0 [amdgpu]
      generic_reg_get2+0x22/0x60 [amdgpu]
      optc1_get_crtc_scanoutpos+0x6a/0xc0 [amdgpu]
      dc_stream_get_scanoutpos+0x74/0x90 [amdgpu]
      dm_crtc_get_scanoutpos+0x82/0xf0 [amdgpu]
      amdgpu_display_get_crtc_scanoutpos+0x91/0x190 [amdgpu]
      ? dm_read_reg_func+0x37/0xc0 [amdgpu]
      amdgpu_get_vblank_counter_kms+0xb4/0x1a0 [amdgpu]
      dm_pflip_high_irq+0x213/0x2f0 [amdgpu]
      amdgpu_dm_irq_handler+0x8a/0x200 [amdgpu]
      amdgpu_irq_dispatch+0xd4/0x220 [amdgpu]
      amdgpu_ih_process+0x7f/0x110 [amdgpu]
      amdgpu_irq_handler+0x1f/0x70 [amdgpu]
      __handle_irq_event_percpu+0x46/0x1b0
      handle_irq_event+0x34/0x80
      handle_edge_irq+0x9f/0x240
      __common_interrupt+0x66/0x110
      common_interrupt+0x5c/0xd0
      asm_common_interrupt+0x22/0x40
    
    Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "f2fs: fix to do sanity check on extent cache correctly" [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Thu Jul 20 19:29:53 2023 +0800

    Revert "f2fs: fix to do sanity check on extent cache correctly"
    
    [ Upstream commit 958ccbbf1ce716d77c7cfa79ace50a421c1eed73 ]
    
    syzbot reports a f2fs bug as below:
    
    UBSAN: array-index-out-of-bounds in fs/f2fs/f2fs.h:3275:19
    index 1409 is out of range for type '__le32[923]' (aka 'unsigned int[923]')
    Call Trace:
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
     ubsan_epilogue lib/ubsan.c:217 [inline]
     __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
     inline_data_addr fs/f2fs/f2fs.h:3275 [inline]
     __recover_inline_status fs/f2fs/inode.c:113 [inline]
     do_read_inode fs/f2fs/inode.c:480 [inline]
     f2fs_iget+0x4730/0x48b0 fs/f2fs/inode.c:604
     f2fs_fill_super+0x640e/0x80c0 fs/f2fs/super.c:4601
     mount_bdev+0x276/0x3b0 fs/super.c:1391
     legacy_get_tree+0xef/0x190 fs/fs_context.c:611
     vfs_get_tree+0x8c/0x270 fs/super.c:1519
     do_new_mount+0x28f/0xae0 fs/namespace.c:3335
     do_mount fs/namespace.c:3675 [inline]
     __do_sys_mount fs/namespace.c:3884 [inline]
     __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    The issue was bisected to:
    
    commit d48a7b3a72f121655d95b5157c32c7d555e44c05
    Author: Chao Yu <chao@kernel.org>
    Date:   Mon Jan 9 03:49:20 2023 +0000
    
        f2fs: fix to do sanity check on extent cache correctly
    
    The root cause is we applied both v1 and v2 of the patch, v2 is the right
    fix, so it needs to revert v1 in order to fix reported issue.
    
    v1:
    commit d48a7b3a72f1 ("f2fs: fix to do sanity check on extent cache correctly")
    https://lore.kernel.org/lkml/20230109034920.492914-1-chao@kernel.org/
    
    v2:
    commit 269d11948100 ("f2fs: fix to do sanity check on extent cache correctly")
    https://lore.kernel.org/lkml/20230207134808.1827869-1-chao@kernel.org/
    
    Reported-by: syzbot+601018296973a481f302@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000fcf0690600e4d04d@google.com/
    Fixes: d48a7b3a72f1 ("f2fs: fix to do sanity check on extent cache correctly")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "fuse: in fuse_flush only wait if someone wants the return code" [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Mon Aug 14 13:05:30 2023 +0200

    Revert "fuse: in fuse_flush only wait if someone wants the return code"
    
    commit 91ec6c85599b60c00caf4e9a9d6c4d6e5dd5e93c upstream.
    
    This reverts commit 5a8bee63b10f6f2f52f6d22e109a4a147409842a.
    
    Jürg Billeter reports the following regression:
    
      Since v6.3-rc1 commit 5a8bee63b1 ("fuse: in fuse_flush only wait if
      someone wants the return code") `fput()` is called asynchronously if a
      file is closed as part of a process exiting, i.e., if there was no
      explicit `close()` before exit.
    
      If the file was open for writing, also `put_write_access()` is called
      asynchronously as part of the async `fput()`.
    
      If that newly written file is an executable, attempting to `execve()` the
      new file can fail with `ETXTBSY` if it's called after the writer process
      exited but before the async `fput()` has run.
    
    Reported-and-tested-by: "Jürg Billeter" <j@bitron.ch>
    Cc: <stable@vger.kernel.org> # v6.3
    Link: https://lore.kernel.org/all/4f66cded234462964899f2a661750d6798a57ec0.camel@bitron.ch/
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "IB/isert: Fix incorrect release of isert connection" [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Mon Aug 21 10:57:14 2023 +0300

    Revert "IB/isert: Fix incorrect release of isert connection"
    
    [ Upstream commit dfe261107c080709459c32695847eec96238852b ]
    
    Commit: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection") is
    causing problems on OPA when DEVICE_REMOVAL is happening.
    
     ------------[ cut here ]------------
     WARNING: CPU: 52 PID: 2117247 at drivers/infiniband/core/cq.c:359
    ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
     Modules linked in: nfsd nfs_acl target_core_user uio tcm_fc libfc
    scsi_transport_fc tcm_loop target_core_pscsi target_core_iblock target_core_file
    rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs
    rfkill rpcrdma rdma_ucm ib_srpt sunrpc ib_isert iscsi_target_mod target_core_mod
    opa_vnic ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib iw_cm
    ib_cm hfi1(-) rdmavt ib_uverbs intel_rapl_msr intel_rapl_common sb_edac ib_core
    x86_pkg_temp_thermal intel_powerclamp coretemp i2c_i801 mxm_wmi rapl iTCO_wdt
    ipmi_si iTCO_vendor_support mei_me ipmi_devintf mei intel_cstate ioatdma
    intel_uncore i2c_smbus joydev pcspkr lpc_ich ipmi_msghandler acpi_power_meter
    acpi_pad xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg crct10dif_pclmul
    crc32_pclmul crc32c_intel drm_kms_helper drm_shmem_helper ahci libahci
    ghash_clmulni_intel igb drm libata dca i2c_algo_bit wmi fuse
     CPU: 52 PID: 2117247 Comm: modprobe Not tainted 6.5.0-rc1+ #1
     Hardware name: Intel Corporation S2600CWR/S2600CW, BIOS
    SE5C610.86B.01.01.0014.121820151719 12/18/2015
     RIP: 0010:ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
     Code: ff 48 8b 43 40 48 8d 7b 40 48 83 e8 40 4c 39 e7 75 b3 49 83
    c4 10 4d 39 fc 75 94 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b eb a1
    90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f
     RSP: 0018:ffffc10bea13fc80 EFLAGS: 00010206
     RAX: 000000000000010c RBX: ffff9bf5c7e66c00 RCX: 000000008020001d
     RDX: 000000008020001e RSI: fffff175221f9900 RDI: ffff9bf5c7e67640
     RBP: ffff9bf5c7e67600 R08: ffff9bf5c7e64400 R09: 000000008020001d
     R10: 0000000040000000 R11: 0000000000000000 R12: ffff9bee4b1e8a18
     R13: dead000000000122 R14: dead000000000100 R15: ffff9bee4b1e8a38
     FS:  00007ff1e6d38740(0000) GS:ffff9bfd9fb00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00005652044ecc68 CR3: 0000000889b5c005 CR4: 00000000001706e0
     Call Trace:
      <TASK>
      ? __warn+0x80/0x130
      ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
      ? report_bug+0x195/0x1a0
      ? handle_bug+0x3c/0x70
      ? exc_invalid_op+0x14/0x70
      ? asm_exc_invalid_op+0x16/0x20
      ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
      disable_device+0x9d/0x160 [ib_core]
      __ib_unregister_device+0x42/0xb0 [ib_core]
      ib_unregister_device+0x22/0x30 [ib_core]
      rvt_unregister_device+0x20/0x90 [rdmavt]
      hfi1_unregister_ib_device+0x16/0xf0 [hfi1]
      remove_one+0x55/0x1a0 [hfi1]
      pci_device_remove+0x36/0xa0
      device_release_driver_internal+0x193/0x200
      driver_detach+0x44/0x90
      bus_remove_driver+0x69/0xf0
      pci_unregister_driver+0x2a/0xb0
      hfi1_mod_cleanup+0xc/0x3c [hfi1]
      __do_sys_delete_module.constprop.0+0x17a/0x2f0
      ? exit_to_user_mode_prepare+0xc4/0xd0
      ? syscall_trace_enter.constprop.0+0x126/0x1a0
      do_syscall_64+0x5c/0x90
      ? syscall_exit_to_user_mode+0x12/0x30
      ? do_syscall_64+0x69/0x90
      ? syscall_exit_work+0x103/0x130
      ? syscall_exit_to_user_mode+0x12/0x30
      ? do_syscall_64+0x69/0x90
      ? exc_page_fault+0x65/0x150
      entry_SYSCALL_64_after_hwframe+0x6e/0xd8
     RIP: 0033:0x7ff1e643f5ab
     Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3
    66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0
    ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48
     RSP: 002b:00007ffec9103cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
     RAX: ffffffffffffffda RBX: 00005615267fdc50 RCX: 00007ff1e643f5ab
     RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00005615267fdcb8
     RBP: 00005615267fdc50 R08: 0000000000000000 R09: 0000000000000000
     R10: 00007ff1e659eac0 R11: 0000000000000206 R12: 00005615267fdcb8
     R13: 0000000000000000 R14: 00005615267fdcb8 R15: 00007ffec9105ff8
      </TASK>
     ---[ end trace 0000000000000000 ]---
    
    And...
    
     restrack: ------------[ cut here ]------------
     infiniband hfi1_0: BUG: RESTRACK detected leak of resources
     restrack: Kernel PD object allocated by ib_isert is not freed
     restrack: Kernel CQ object allocated by ib_core is not freed
     restrack: Kernel QP object allocated by rdma_cm is not freed
     restrack: ------------[ cut here ]------------
    
    Fixes: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection")
    Reported-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Closes: https://lore.kernel.org/all/921cd1d9-2879-f455-1f50-0053fe6a6655@cornelisnetworks.com
    Link: https://lore.kernel.org/r/a27982d3235005c58f6d321f3fad5eb6e1beaf9e.1692604607.git.leonro@nvidia.com
    Tested-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
revert "memfd: improve userspace warnings for missing exec-related flags". [+ + +]
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Sat Sep 2 15:59:31 2023 -0700

    revert "memfd: improve userspace warnings for missing exec-related flags".
    
    commit 2562d67b1bdf91c7395b0225d60fdeb26b4bc5a0 upstream.
    
    This warning is telling userspace developers to pass MFD_EXEC and
    MFD_NOEXEC_SEAL to memfd_create().  Commit 434ed3350f57 ("memfd: improve
    userspace warnings for missing exec-related flags") made the warning more
    frequent and visible in the hope that this would accelerate the fixing of
    errant userspace.
    
    But the overall effect is to generate far too much dmesg noise.
    
    Fixes: 434ed3350f57 ("memfd: improve userspace warnings for missing exec-related flags")
    Reported-by: Damian Tometzki <dtometzki@fedoraproject.org>
    Closes: https://lkml.kernel.org/r/ZPFzCSIgZ4QuHsSC@fedora.fritz.box
    Cc: Aleksa Sarai <cyphar@cyphar.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Daniel Verkamp <dverkamp@chromium.org>
    Cc: Jeff Xu <jeffxu@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "net: macsec: preserve ingress frame ordering" [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Mon Sep 4 10:56:04 2023 +0200

    Revert "net: macsec: preserve ingress frame ordering"
    
    commit d3287e4038ca4f81e02067ab72d087af7224c68b upstream.
    
    This reverts commit ab046a5d4be4c90a3952a0eae75617b49c0cb01b.
    
    It was trying to work around an issue at the crypto layer by excluding
    ASYNC implementations of gcm(aes), because a bug in the AESNI version
    caused reordering when some requests bypassed the cryptd queue while
    older requests were still pending on the queue.
    
    This was fixed by commit 38b2f68b4264 ("crypto: aesni - Fix cryptd
    reordering problem on gcm"), which pre-dates ab046a5d4be4.
    
    Herbert Xu confirmed that all ASYNC implementations are expected to
    maintain the ordering of completions wrt requests, so we can use them
    in MACsec.
    
    On my test machine, this restores the performance of a single netperf
    instance, from 1.4Gbps to 4.4Gbps.
    
    Link: https://lore.kernel.org/netdev/9328d206c5d9f9239cae27e62e74de40b258471d.1692279161.git.sd@queasysnail.net/T/
    Link: https://lore.kernel.org/netdev/1b0cec71-d084-8153-2ba4-72ce71abeb65@byu.edu/
    Link: https://lore.kernel.org/netdev/d335ddaa-18dc-f9f0-17ee-9783d3b2ca29@mailbox.tu-dresden.de/
    Fixes: ab046a5d4be4 ("net: macsec: preserve ingress frame ordering")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/11c952469d114db6fb29242e1d9545e61f52f512.1693757159.git.sd@queasysnail.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "PCI: Mark NVIDIA T4 GPUs to avoid bus reset" [+ + +]
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Fri Sep 8 14:55:30 2023 -0500

    Revert "PCI: Mark NVIDIA T4 GPUs to avoid bus reset"
    
    commit 5260bd6d36c83c5b269c33baaaf8c78e520908b0 upstream.
    
    This reverts commit d5af729dc2071273f14cbb94abbc60608142fd83.
    
    d5af729dc207 ("PCI: Mark NVIDIA T4 GPUs to avoid bus reset") avoided
    Secondary Bus Reset on the T4 because the reset seemed to not work when the
    T4 was directly attached to a Root Port.
    
    But NVIDIA thinks the issue is probably related to some issue with the Root
    Port, not with the T4.  The T4 provides neither PM nor FLR reset, so
    masking bus reset compromises this device for assignment scenarios.
    
    Revert d5af729dc207 as requested by Wu Zongyong.  This will leave SBR
    broken in the specific configuration Wu tested, as it was in v6.5, so Wu
    will debug that further.
    
    Link: https://lore.kernel.org/r/ZPqMCDWvITlOLHgJ@wuzongyong-alibaba
    Link: https://lore.kernel.org/r/20230908201104.GA305023@bhelgaas
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "PCI: tegra194: Enable support for 256 Byte payload" [+ + +]
Author: Vidya Sagar <vidyas@nvidia.com>
Date:   Mon Jun 19 15:56:04 2023 +0530

    Revert "PCI: tegra194: Enable support for 256 Byte payload"
    
    commit ebfde1584d9f037b6309fc682c96e22dac7bcb7a upstream.
    
    After commit 4fb8e46c1bc4 ("PCI: tegra194: Enable support for 256 Byte
    payload"), we initialize MPS=256 for tegra194 Root Ports before enumerating
    the hierarchy.
    
    Consider an Endpoint that supports only MPS=128.  In the default situation
    (CONFIG_PCIE_BUS_DEFAULT set and no "pci=pcie_bus_*" parameter), Linux
    tries to configure the MPS of every device to match the upstream bridge.
    If the Endpoint is directly below the Root Port, Linux can reduce the Root
    Port MPS to 128 to match the Endpoint.  But if there's a switch in the
    middle, Linux doesn't reduce the Root Port MPS because other devices below
    the switch may already be configured with MPS larger than 128.
    
    This scenario results in uncorrectable Malformed TLP errors if the Root
    Port sends TLPs with payloads larger than 128 bytes.  These errors can
    be avoided by using the "pci=pcie_bus_safe" parameter, but it doesn't
    seem to be a good idea to always have this parameter even for basic
    functionality to work.
    
    Revert commit 4fb8e46c1bc4 ("PCI: tegra194: Enable support for 256 Byte
    payload") so the Root Ports default to MPS=128, which all devices
    support.
    
    If peer-to-peer DMA is not required, one can use "pci=pcie_bus_perf" to
    get the benefit of larger MPS settings.
    
    [bhelgaas: commit log; kwilczynski: retain "u16 val_16" declaration at
    the top, add missing acked by tag]
    Fixes: 4fb8e46c1bc4 ("PCI: tegra194: Enable support for 256 Byte payload")
    Link: https://lore.kernel.org/linux-pci/20230619102604.3735001-1-vidyas@nvidia.com
    Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Acked-by: Jon Hunter <jonathanh@nvidia.com>
    Cc: stable@vger.kernel.org # v6.0-rc1+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "scsi: qla2xxx: Fix buffer overrun" [+ + +]
Author: Nilesh Javali <njavali@marvell.com>
Date:   Mon Aug 21 18:30:44 2023 +0530

    Revert "scsi: qla2xxx: Fix buffer overrun"
    
    commit 641671d97b9199f1ba35ccc2222d4b189a6a5de5 upstream.
    
    Revert due to Get PLOGI Template failed.
    This reverts commit b68710a8094fdffe8dd4f7a82c82649f479bb453.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20230821130045.34850-9-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "wifi: ath6k: silence false positive -Wno-dangling-pointer warning on GCC 12" [+ + +]
Author: Kalle Valo <kvalo@kernel.org>
Date:   Mon Jul 24 13:08:23 2023 +0300

    Revert "wifi: ath6k: silence false positive -Wno-dangling-pointer warning on GCC 12"
    
    [ Upstream commit a1ce186db7f0e449f35d12fb55ae0da2a1b400e2 ]
    
    This reverts commit bd1d129daa3ede265a880e2c6a7f91eab0f4dc62.
    
    The dangling-pointer warnings were disabled kernel-wide by commit 49beadbd47c2
    ("gcc-12: disable '-Wdangling-pointer' warning for now") for v5.19. So this
    hack in ath6kl is not needed anymore.
    
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230724100823.2948804-1-kvalo@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: Mark KASAN tmp* page tables variables as static [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Tue Jul 4 09:43:56 2023 +0200

    riscv: Mark KASAN tmp* page tables variables as static
    
    commit dd7664d67b478afeb79a89e4586c2cd7707d17d6 upstream.
    
    tmp_pg_dir, tmp_p4d and tmp_pud are only used in kasan_init.c so they
    should be declared as static.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202306282202.bODptiGE-lkp@intel.com/
    Fixes: 96f9d4daf745 ("riscv: Rework kasan population functions")
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20230704074357.233982-1-alexghiti@rivosinc.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

riscv: Move create_tmp_mapping() to init sections [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Tue Jul 4 09:43:57 2023 +0200

    riscv: Move create_tmp_mapping() to init sections
    
    commit 9bdd924803787ceeb10f1ea399e91d75fb05d3a7 upstream.
    
    This function is only used at boot time so mark it as __init.
    
    Fixes: 96f9d4daf745 ("riscv: Rework kasan population functions")
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20230704074357.233982-2-alexghiti@rivosinc.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rpmsg: glink: Add check for kstrdup [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Mon Jun 19 11:06:31 2023 +0800

    rpmsg: glink: Add check for kstrdup
    
    [ Upstream commit b5c9ee8296a3760760c7b5d2e305f91412adc795 ]
    
    Add check for the return value of kstrdup() and return the error
    if it fails in order to avoid NULL pointer dereference.
    
    Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230619030631.12361-1-jiasheng@iscas.ac.cn
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/dasd: fix hanging device after request requeue [+ + +]
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Fri Jul 21 21:36:46 2023 +0200

    s390/dasd: fix hanging device after request requeue
    
    [ Upstream commit 8a2278ce9c25048d999fe1a3561def75d963f471 ]
    
    The DASD device driver has a function to requeue requests to the
    blocklayer.
    This function is used in various cases when basic settings for the device
    have to be changed like High Performance Ficon related parameters or copy
    pair settings.
    
    The functions iterates over the device->ccw_queue and also removes the
    requests from the block->ccw_queue.
    In case the device is started on an alias device instead of the base
    device it might be removed from the block->ccw_queue without having it
    canceled properly before. This might lead to a hanging device since the
    request is no longer on a queue and can not be handled properly.
    
    Fix by iterating over the block->ccw_queue instead of the
    device->ccw_queue. This will take care of all blocklayer related requests
    and handle them on all associated DASD devices.
    
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230721193647.3889634-4-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/dasd: fix string length handling [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Aug 28 17:31:42 2023 +0200

    s390/dasd: fix string length handling
    
    commit f7cf22424665043787a96a66a048ff6b2cfd473c upstream.
    
    Building dasd_eckd.o with latest clang reveals this bug:
    
        CC      drivers/s390/block/dasd_eckd.o
          drivers/s390/block/dasd_eckd.c:1082:3: warning: 'snprintf' will always be truncated;
          specified size is 1, but format string expands to at least 11 [-Wfortify-source]
           1082 |                 snprintf(print_uid, sizeof(*print_uid),
                |                 ^
          drivers/s390/block/dasd_eckd.c:1087:3: warning: 'snprintf' will always be truncated;
          specified size is 1, but format string expands to at least 10 [-Wfortify-source]
           1087 |                 snprintf(print_uid, sizeof(*print_uid),
                |                 ^
    
    Fix this by moving and using the existing UID_STRLEN for the arrays
    that are being written to. Also rename UID_STRLEN to DASD_UID_STRLEN
    to clarify its scope.
    
    Fixes: 23596961b437 ("s390/dasd: split up dasd_eckd_read_conf")
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1923
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20230828153142.2843753-2-hca@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/dasd: use correct number of retries for ERP requests [+ + +]
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Fri Jul 21 21:36:45 2023 +0200

    s390/dasd: use correct number of retries for ERP requests
    
    [ Upstream commit acea28a6b74f458defda7417d2217b051ba7d444 ]
    
    If a DASD request fails an error recovery procedure (ERP) request might
    be built as a copy of the original request to do error recovery.
    
    The ERP request gets a number of retries assigned.
    This number is always 256 no matter what other value might have been set
    for the original request. This is not what is expected when a user
    specifies a certain amount of retries for the device via sysfs.
    
    Correctly use the number of retries of the original request for ERP
    requests.
    
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230721193647.3889634-3-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/dcssblk: fix kernel crash with list_add corruption [+ + +]
Author: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Date:   Thu Aug 10 10:22:36 2023 +0200

    s390/dcssblk: fix kernel crash with list_add corruption
    
    commit c8f40a0bccefd613748d080147469a4652d6e74c upstream.
    
    Commit fb08a1908cb1 ("dax: simplify the dax_device <-> gendisk
    association") introduced new logic for gendisk association, requiring
    drivers to explicitly call dax_add_host() and dax_remove_host().
    
    For dcssblk driver, some dax_remove_host() calls were missing, e.g. in
    device remove path. The commit also broke error handling for out_dax case
    in device add path, resulting in an extra put_device() w/o the previous
    get_device() in that case.
    
    This lead to stale xarray entries after device add / remove cycles. In the
    case when a previously used struct gendisk pointer (xarray index) would be
    used again, because blk_alloc_disk() happened to return such a pointer, the
    xa_insert() in dax_add_host() would fail and go to out_dax, doing the extra
    put_device() in the error path. In combination with an already flawed error
    handling in dcssblk (device_register() cleanup), which needs to be
    addressed in a separate patch, this resulted in a missing device_del() /
    klist_del(), and eventually in the kernel crash with list_add corruption on
    a subsequent device_add() / klist_add().
    
    Fix this by adding the missing dax_remove_host() calls, and also move the
    put_device() in the error path to restore the previous logic.
    
    Fixes: fb08a1908cb1 ("dax: simplify the dax_device <-> gendisk association")
    Cc: <stable@vger.kernel.org> # 5.17+
    Acked-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/ipl: add missing secure/has_secure file to ipl type 'unknown' [+ + +]
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Tue Aug 15 09:26:06 2023 +0200

    s390/ipl: add missing secure/has_secure file to ipl type 'unknown'
    
    commit ea5717cb13468323a7c3dd394748301802991f39 upstream.
    
    OS installers are relying on /sys/firmware/ipl/has_secure to be
    present on machines supporting secure boot. This file is present
    for all IPL types, but not the unknown type, which prevents a secure
    installation when an LPAR is booted in HMC via FTP(s), because
    this is an unknown IPL type in linux. While at it, also add the secure
    file.
    
    Fixes: c9896acc7851 ("s390/ipl: Provide has_secure sysfs attribute")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/paes: fix PKEY_TYPE_EP11_AES handling for secure keyblobs [+ + +]
Author: Holger Dengler <dengler@linux.ibm.com>
Date:   Wed Aug 9 14:23:45 2023 +0200

    s390/paes: fix PKEY_TYPE_EP11_AES handling for secure keyblobs
    
    [ Upstream commit cba33db3fc4dbf2e54294b0e499d2335a3a00d78 ]
    
    Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC
    private keys")' introduced PKEY_TYPE_EP11_AES securekey blobs as a
    supplement to the PKEY_TYPE_EP11 (which won't work in environments
    with session-bound keys). This new keyblobs has a different maximum
    size, so fix paes crypto module to accept also these larger keyblobs.
    
    Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")
    Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
    Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/pkey: fix PKEY_TYPE_EP11_AES handling for sysfs attributes [+ + +]
Author: Holger Dengler <dengler@linux.ibm.com>
Date:   Fri Aug 4 16:02:58 2023 +0200

    s390/pkey: fix PKEY_TYPE_EP11_AES handling for sysfs attributes
    
    [ Upstream commit b9352e4b9b9eff949bcc6907b8569b3a1d992f1e ]
    
    Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC
    private keys")' introduced a new PKEY_TYPE_EP11_AES securekey type as
    a supplement to the existing PKEY_TYPE_EP11 (which won't work in
    environments with session-bound keys). The pkey EP11 securekey
    attributes use PKEY_TYPE_EP11_AES (instead of PKEY_TYPE_EP11)
    keyblobs, to make the generated keyblobs usable also in environments,
    where session-bound keys are required.
    
    There should be no negative impacts to userspace because the internal
    structure of the keyblobs is opaque. The increased size of the
    generated keyblobs is reflected by the changed size of the attributes.
    
    Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")
    Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
    Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_GENSECK2 IOCTL [+ + +]
Author: Holger Dengler <dengler@linux.ibm.com>
Date:   Tue Jul 25 09:49:55 2023 +0200

    s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_GENSECK2 IOCTL
    
    [ Upstream commit fb249ce7f7bfd8621a38e4ad401ba74b680786d4 ]
    
    Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC
    private keys")' introduced PKEY_TYPE_EP11_AES for the PKEY_GENSECK2
    IOCTL, to enable userspace to generate securekey blobs of this
    type. Unfortunately, all PKEY_GENSECK2 IOCTL requests for
    PKEY_TYPE_EP11_AES return with an error (-EINVAL). Fix the handling
    for PKEY_TYPE_EP11_AES in PKEY_GENSECK2 IOCTL, so that userspace can
    generate securekey blobs of this type.
    
    The start of the header and the keyblob, as well as the length need
    special handling, depending on the internal keyversion. Add a helper
    function that splits an uninitialized buffer into start and size of
    the header as well as start and size of the payload, depending on the
    requested keyversion.
    
    Do the header-related calculations and the raw genkey request handling
    in separate functions. Use the raw genkey request function for
    internal purposes.
    
    Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")
    Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
    Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/pkey: fix/harmonize internal keyblob headers [+ + +]
Author: Holger Dengler <dengler@linux.ibm.com>
Date:   Wed Jul 26 11:33:45 2023 +0200

    s390/pkey: fix/harmonize internal keyblob headers
    
    [ Upstream commit 37a08f010b7c423b5e4c9ed3b187d21166553007 ]
    
    Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC
    private keys")' introduced PKEY_TYPE_EP11_AES as a supplement to
    PKEY_TYPE_EP11. All pkeys have an internal header/payload structure,
    which is opaque to the userspace. The header structures for
    PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES are nearly identical and there
    is no reason, why different structures are used. In preparation to fix
    the keyversion handling in the broken PKEY IOCTLs, the same header
    structure is used for PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES. This
    reduces the number of different code paths and increases the
    readability.
    
    Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")
    Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
    Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
samples/bpf: fix bio latency check with tracepoint [+ + +]
Author: Daniel T. Lee <danieltimlee@gmail.com>
Date:   Fri Aug 18 18:01:16 2023 +0900

    samples/bpf: fix bio latency check with tracepoint
    
    [ Upstream commit 92632115fb57ff9e368f256913e96d6fd5abf5ab ]
    
    Recently, a new tracepoint for the block layer, specifically the
    block_io_start/done tracepoints, was introduced in commit 5a80bd075f3b
    ("block: introduce block_io_start/block_io_done tracepoints").
    
    Previously, the kprobe entry used for this purpose was quite unstable
    and inherently broke relevant probes [1]. Now that a stable tracepoint
    is available, this commit replaces the bio latency check with it.
    
    One of the changes made during this replacement is the key used for the
    hash table. Since 'struct request' cannot be used as a hash key, the
    approach taken follows that which was implemented in bcc/biolatency [2].
    (uses dev:sector for the key)
    
    [1]: https://github.com/iovisor/bcc/issues/4261
    [2]: https://github.com/iovisor/bcc/pull/4691
    
    Fixes: 450b7879e345 ("block: move blk_account_io_{start,done} to blk-mq.c")
    Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
    Link: https://lore.kernel.org/r/20230818090119.477441-7-danieltimlee@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

samples/bpf: fix broken map lookup probe [+ + +]
Author: Daniel T. Lee <danieltimlee@gmail.com>
Date:   Fri Aug 18 18:01:17 2023 +0900

    samples/bpf: fix broken map lookup probe
    
    [ Upstream commit d93a7cf6ca2cfcd7de5d06f753ce8d5e863316ac ]
    
    In the commit 7c4cd051add3 ("bpf: Fix syscall's stackmap lookup
    potential deadlock"), a potential deadlock issue was addressed, which
    resulted in *_map_lookup_elem not triggering BPF programs.
    (prior to lookup, bpf_disable_instrumentation() is used)
    
    To resolve the broken map lookup probe using "htab_map_lookup_elem",
    this commit introduces an alternative approach. Instead, it utilize
    "bpf_map_copy_value" and apply a filter specifically for the hash table
    with map_type.
    
    Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com>
    Fixes: 7c4cd051add3 ("bpf: Fix syscall's stackmap lookup potential deadlock")
    Link: https://lore.kernel.org/r/20230818090119.477441-8-danieltimlee@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sbitmap: fix batching wakeup [+ + +]
Author: David Jeffery <djeffery@redhat.com>
Date:   Fri Jul 21 17:57:15 2023 +0800

    sbitmap: fix batching wakeup
    
    commit 106397376c0369fcc01c58dd189ff925a2724a57 upstream.
    
    Current code supposes that it is enough to provide forward progress by
    just waking up one wait queue after one completion batch is done.
    
    Unfortunately this way isn't enough, cause waiter can be added to wait
    queue just after it is woken up.
    
    Follows one example(64 depth, wake_batch is 8)
    
    1) all 64 tags are active
    
    2) in each wait queue, there is only one single waiter
    
    3) each time one completion batch(8 completions) wakes up just one
       waiter in each wait queue, then immediately one new sleeper is added
       to this wait queue
    
    4) after 64 completions, 8 waiters are wakeup, and there are still 8
       waiters in each wait queue
    
    5) after another 8 active tags are completed, only one waiter can be
       wakeup, and the other 7 can't be waken up anymore.
    
    Turns out it isn't easy to fix this problem, so simply wakeup enough
    waiters for single batch.
    
    Cc: Kemeng Shi <shikemeng@huaweicloud.com>
    Cc: Chengming Zhou <zhouchengming@bytedance.com>
    Cc: Jan Kara <jack@suse.cz>
    Signed-off-by: David Jeffery <djeffery@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Link: https://lore.kernel.org/r/20230721095715.232728-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sched/psi: Select KERNFS as needed [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jul 30 20:07:40 2023 -0700

    sched/psi: Select KERNFS as needed
    
    [ Upstream commit 98dfdd9ee93995a408192dbbf3dd219ba23e3738 ]
    
    Users of KERNFS should select it to enforce its being built, so
    do this to prevent a build error.
    
    In file included from ../kernel/sched/build_utility.c:97:
    ../kernel/sched/psi.c: In function 'psi_trigger_poll':
    ../kernel/sched/psi.c:1479:17: error: implicit declaration of function 'kernfs_generic_poll' [-Werror=implicit-function-declaration]
     1479 |                 kernfs_generic_poll(t->of, wait);
    
    Fixes: aff037078eca ("sched/psi: use kernfs polling functions for PSI trigger polling")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Suren Baghdasaryan <surenb@google.com>
    Link: lore.kernel.org/r/202307310732.r65EQFY0-lkp@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/rt: Fix sysctl_sched_rr_timeslice intial value [+ + +]
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Wed Aug 2 17:19:05 2023 +0200

    sched/rt: Fix sysctl_sched_rr_timeslice intial value
    
    [ Upstream commit c7fcb99877f9f542c918509b2801065adcaf46fa ]
    
    There is a 10% rounding error in the intial value of the
    sysctl_sched_rr_timeslice with CONFIG_HZ_300=y.
    
    This was found with LTP test sched_rr_get_interval01:
    
    sched_rr_get_interval01.c:57: TPASS: sched_rr_get_interval() passed
    sched_rr_get_interval01.c:64: TPASS: Time quantum 0s 99999990ns
    sched_rr_get_interval01.c:72: TFAIL: /proc/sys/kernel/sched_rr_timeslice_ms != 100 got 90
    sched_rr_get_interval01.c:57: TPASS: sched_rr_get_interval() passed
    sched_rr_get_interval01.c:64: TPASS: Time quantum 0s 99999990ns
    sched_rr_get_interval01.c:72: TFAIL: /proc/sys/kernel/sched_rr_timeslice_ms != 100 got 90
    
    What this test does is to compare the return value from the
    sched_rr_get_interval() and the sched_rr_timeslice_ms sysctl file and
    fails if they do not match.
    
    The problem it found is the intial sysctl file value which was computed as:
    
    static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;
    
    which works fine as long as MSEC_PER_SEC is multiple of HZ, however it
    introduces 10% rounding error for CONFIG_HZ_300:
    
    (MSEC_PER_SEC / HZ) * (100 * HZ / 1000)
    
    (1000 / 300) * (100 * 300 / 1000)
    
    3 * 30 = 90
    
    This can be easily fixed by reversing the order of the multiplication
    and division. After this fix we get:
    
    (MSEC_PER_SEC * (100 * HZ / 1000)) / HZ
    
    (1000 * (100 * 300 / 1000)) / 300
    
    (1000 * 30) / 300 = 100
    
    Fixes: 975e155ed873 ("sched/rt: Show the 'sched_rr_timeslice' SCHED_RR timeslice tuning knob in milliseconds")
    Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Petr Vorel <pvorel@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Tested-by: Petr Vorel <pvorel@suse.cz>
    Link: https://lore.kernel.org/r/20230802151906.25258-2-chrubis@suse.cz
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts/gdb: fix 'lx-lsmod' show the wrong size [+ + +]
Author: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Date:   Mon Jul 10 17:28:46 2023 +0800

    scripts/gdb: fix 'lx-lsmod' show the wrong size
    
    [ Upstream commit fb40b0537342e1acd5c2daf2ff6780c1d0d2883c ]
    
    'lsmod' shows total core layout size, so we need to sum up all the
    sections in core layout in gdb scripts.
    
    / # lsmod
    kasan_test 200704 0 - Live 0xffff80007f640000
    
    Before patch:
    (gdb) lx-lsmod
    Address            Module                  Size  Used by
    0xffff80007f640000 kasan_test             36864  0
    
    After patch:
    (gdb) lx-lsmod
    Address            Module                  Size  Used by
    0xffff80007f640000 kasan_test            200704  0
    
    Link: https://lkml.kernel.org/r/20230710092852.31049-1-Kuan-Ying.Lee@mediatek.com
    Fixes: b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address")
    Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
    Reviewed-by: Pankaj Raghav <p.raghav@samsung.com>
    Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Cc: Chinwen Chang <chinwen.chang@mediatek.com>
    Cc: Jan Kiszka <jan.kiszka@siemens.com>
    Cc: Kieran Bingham <kbingham@kernel.org>
    Cc: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Matthias Brugger <matthias.bgg@gmail.com>
    Cc: Qun-Wei Lin <qun-wei.lin@mediatek.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: be2iscsi: Add length check when parsing nlattrs [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Sun Jul 23 15:59:38 2023 +0800

    scsi: be2iscsi: Add length check when parsing nlattrs
    
    [ Upstream commit ee0268f230f66cb472df3424f380ea668da2749a ]
    
    beiscsi_iface_set_param() parses nlattr with nla_for_each_attr and assumes
    every attributes can be viewed as struct iscsi_iface_param_info.
    
    This is not true because there is no any nla_policy to validate the
    attributes passed from the upper function iscsi_set_iface_params().
    
    Add the nla_len check before accessing the nlattr data and return EINVAL if
    the length check fails.
    
    Fixes: 0e43895ec1f4 ("[SCSI] be2iscsi: adding functionality to change network settings using iscsiadm")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Link: https://lore.kernel.org/r/20230723075938.3713864-1-linma@zju.edu.cn
    Reviewed-by: Chris Leech <cleech@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: core: Fix the scsi_set_resid() documentation [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Fri Jul 21 09:01:32 2023 -0700

    scsi: core: Fix the scsi_set_resid() documentation
    
    commit f669b8a683e4ee26fa5cafe19d71cec1786b556a upstream.
    
    Because scsi_finish_command() subtracts the residual from the buffer
    length, residual overflows must not be reported. Reflect this in the SCSI
    documentation. See also commit 9237f04e12cc ("scsi: core: Fix
    scsi_get/set_resid() interface")
    
    Cc: Damien Le Moal <dlemoal@kernel.org>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20230721160154.874010-2-bvanassche@acm.org
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: core: Use 32-bit hostnum in scsi_host_lookup() [+ + +]
Author: Tony Battersby <tonyb@cybernetics.com>
Date:   Mon Aug 14 10:03:25 2023 -0400

    scsi: core: Use 32-bit hostnum in scsi_host_lookup()
    
    [ Upstream commit 62ec2092095b678ff89ce4ba51c2938cd1e8e630 ]
    
    Change scsi_host_lookup() hostnum argument type from unsigned short to
    unsigned int to match the type used everywhere else.
    
    Fixes: 6d49f63b415c ("[SCSI] Make host_no an unsigned int")
    Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
    Link: https://lore.kernel.org/r/a02497e7-c12b-ef15-47fc-3f0a0b00ffce@cybernetics.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock [+ + +]
Author: Chengfeng Ye <dg573847474@gmail.com>
Date:   Thu Aug 17 07:47:08 2023 +0000

    scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock
    
    [ Upstream commit 1a1975551943f681772720f639ff42fbaa746212 ]
    
    There is a long call chain that &fip->ctlr_lock is acquired by isr
    fnic_isr_msix_wq_copy() under hard IRQ context. Thus other process context
    code acquiring the lock should disable IRQ, otherwise deadlock could happen
    if the IRQ preempts the execution while the lock is held in process context
    on the same CPU.
    
    [ISR]
    fnic_isr_msix_wq_copy()
     -> fnic_wq_copy_cmpl_handler()
     -> fnic_fcpio_cmpl_handler()
     -> fnic_fcpio_flogi_reg_cmpl_handler()
     -> fnic_flush_tx()
     -> fnic_send_frame()
     -> fcoe_ctlr_els_send()
     -> spin_lock_bh(&fip->ctlr_lock)
    
    [Process Context]
    1. fcoe_ctlr_timer_work()
     -> fcoe_ctlr_flogi_send()
     -> spin_lock_bh(&fip->ctlr_lock)
    
    2. fcoe_ctlr_recv_work()
     -> fcoe_ctlr_recv_handler()
     -> fcoe_ctlr_recv_els()
     -> fcoe_ctlr_announce()
     -> spin_lock_bh(&fip->ctlr_lock)
    
    3. fcoe_ctlr_recv_work()
     -> fcoe_ctlr_recv_handler()
     -> fcoe_ctlr_recv_els()
     -> fcoe_ctlr_flogi_retry()
     -> spin_lock_bh(&fip->ctlr_lock)
    
    4. -> fcoe_xmit()
     -> fcoe_ctlr_els_send()
     -> spin_lock_bh(&fip->ctlr_lock)
    
    spin_lock_bh() is not enough since fnic_isr_msix_wq_copy() is a
    hardirq.
    
    These flaws were found by an experimental static analysis tool I am
    developing for irq-related deadlock.
    
    The patch fix the potential deadlocks by spin_lock_irqsave() to disable
    hard irq.
    
    Fixes: 794d98e77f59 ("[SCSI] libfcoe: retry rejected FLOGI to another FCF if possible")
    Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
    Link: https://lore.kernel.org/r/20230817074708.7509-1-dg573847474@gmail.com
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hisi_sas: Fix normally completed I/O analysed as failed [+ + +]
Author: Xingui Yang <yangxingui@huawei.com>
Date:   Tue Jul 11 11:14:58 2023 +0800

    scsi: hisi_sas: Fix normally completed I/O analysed as failed
    
    [ Upstream commit f5393a5602cacfda2014e0ff8220e5a7564e7cd1 ]
    
    The PIO read command has no response frame and the struct iu[1024] won't be
    filled. I/Os which are normally completed will be treated as failed in
    sas_ata_task_done() when iu contains abnormal dirty data.
    
    Consequently ending_fis should not be filled by iu when the response frame
    hasn't been written to memory.
    
    Fixes: d380f55503ed ("scsi: hisi_sas: Don't bother clearing status buffer IU in task prep")
    Signed-off-by: Xingui Yang <yangxingui@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/1689045300-44318-2-git-send-email-chenxiang66@hisilicon.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hisi_sas: Fix warnings detected by sparse [+ + +]
Author: Xingui Yang <yangxingui@huawei.com>
Date:   Mon May 15 10:41:21 2023 +0800

    scsi: hisi_sas: Fix warnings detected by sparse
    
    [ Upstream commit c0328cc595124579328462fc45d7a29a084cf357 ]
    
    This patch fixes the following warning:
    
    drivers/scsi/hisi_sas/hisi_sas_v3_hw.c:2168:43: sparse: sparse: restricted __le32 degrades to integer
    
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/oe-kbuild-all/202304161254.NztCVZIO-lkp@intel.com/
    Signed-off-by: Xingui Yang <yangxingui@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/1684118481-95908-4-git-send-email-chenxiang66@hisilicon.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Stable-dep-of: f5393a5602ca ("scsi: hisi_sas: Fix normally completed I/O analysed as failed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: iscsi: Add length check for nlattr payload [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Tue Jul 25 10:45:29 2023 +0800

    scsi: iscsi: Add length check for nlattr payload
    
    [ Upstream commit 971dfcb74a800047952f5288512b9c7ddedb050a ]
    
    The current NETLINK_ISCSI netlink parsing loop checks every nlmsg to make
    sure the length is bigger than sizeof(struct iscsi_uevent) and then calls
    iscsi_if_recv_msg().
    
      nlh = nlmsg_hdr(skb);
      if (nlh->nlmsg_len < sizeof(*nlh) + sizeof(*ev) ||
        skb->len < nlh->nlmsg_len) {
        break;
      }
      ...
      err = iscsi_if_recv_msg(skb, nlh, &group);
    
    Hence, in iscsi_if_recv_msg() the nlmsg_data can be safely converted to
    iscsi_uevent as the length is already checked.
    
    However, in other cases the length of nlattr payload is not checked before
    the payload is converted to other data structures. One example is
    iscsi_set_path() which converts the payload to type iscsi_path without any
    checks:
    
      params = (struct iscsi_path *)((char *)ev + sizeof(*ev));
    
    Whereas iscsi_if_transport_conn() correctly checks the pdu_len:
    
      pdu_len = nlh->nlmsg_len - sizeof(*nlh) - sizeof(*ev);
      if ((ev->u.send_pdu.hdr_size > pdu_len) ..
        err = -EINVAL;
    
    To sum up, some code paths called in iscsi_if_recv_msg() do not check the
    length of the data (see below picture) and directly convert the data to
    another data structure. This could result in an out-of-bound reads and heap
    dirty data leakage.
    
                 _________  nlmsg_len(nlh) _______________
                /                                         \
    +----------+--------------+---------------------------+
    | nlmsghdr | iscsi_uevent |          data              |
    +----------+--------------+---------------------------+
                              \                          /
                             iscsi_uevent->u.set_param.len
    
    Fix the issue by adding the length check before accessing it. To clean up
    the code, an additional parameter named rlen is added. The rlen is
    calculated at the beginning of iscsi_if_recv_msg() which avoids duplicated
    calculation.
    
    Fixes: ac20c7bf070d ("[SCSI] iscsi_transport: Added Ping support")
    Fixes: 43514774ff40 ("[SCSI] iscsi class: Add new NETLINK_ISCSI messages for cnic/bnx2i driver.")
    Fixes: 1d9bf13a9cf9 ("[SCSI] iscsi class: add iscsi host set param event")
    Fixes: 01cb225dad8d ("[SCSI] iscsi: add target discvery event to transport class")
    Fixes: 264faaaa1254 ("[SCSI] iscsi: add transport end point callbacks")
    Fixes: fd7255f51a13 ("[SCSI] iscsi: add sysfs attrs for uspace sync up")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Link: https://lore.kernel.org/r/20230725024529.428311-1-linma@zju.edu.cn
    Reviewed-by: Chris Leech <cleech@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: iscsi: Add strlen() check in iscsi_if_set{_host}_param() [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Sun Jul 23 15:58:20 2023 +0800

    scsi: iscsi: Add strlen() check in iscsi_if_set{_host}_param()
    
    [ Upstream commit ce51c817008450ef4188471db31639d42d37a5e1 ]
    
    The functions iscsi_if_set_param() and iscsi_if_set_host_param() convert an
    nlattr payload to type char* and then call C string handling functions like
    sscanf and kstrdup:
    
      char *data = (char*)ev + sizeof(*ev);
      ...
      sscanf(data, "%d", &value);
    
    However, since the nlattr is provided by the user-space program and the
    nlmsg skb is allocated with GFP_KERNEL instead of GFP_ZERO flag (see
    netlink_alloc_large_skb() in netlink_sendmsg()), dirty data on the heap can
    lead to an OOB access for those string handling functions.
    
    By investigating how the bug is introduced, we find it is really
    interesting as the old version parsing code starting from commit
    fd7255f51a13 ("[SCSI] iscsi: add sysfs attrs for uspace sync up") treated
    the nlattr as integer bytes instead of string and had length check in
    iscsi_copy_param():
    
      if (ev->u.set_param.len != sizeof(uint32_t))
        BUG();
    
    But, since the commit a54a52caad4b ("[SCSI] iscsi: fixup set/get param
    functions"), the code treated the nlattr as C string while forgetting to
    add any strlen checks(), opening the possibility of an OOB access.
    
    Fix the potential OOB by adding the strlen() check before accessing the
    buf. If the data passes this check, all low-level set_param handlers can
    safely treat this buf as legal C string.
    
    Fixes: fd7255f51a13 ("[SCSI] iscsi: add sysfs attrs for uspace sync up")
    Fixes: 1d9bf13a9cf9 ("[SCSI] iscsi class: add iscsi host set param event")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Link: https://lore.kernel.org/r/20230723075820.3713119-1-linma@zju.edu.cn
    Reviewed-by: Chris Leech <cleech@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Remove reftag check in DIF paths [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Thu Aug 3 14:19:32 2023 -0700

    scsi: lpfc: Remove reftag check in DIF paths
    
    [ Upstream commit 8eebf0e84f0614cebc7347f7bbccba4056d77d42 ]
    
    When preparing protection DIF I/O for DMA, the driver obtains reference
    tags from scsi_prot_ref_tag().  Previously, there was a wrong assumption
    that an all 0xffffffff value meant error and thus the driver failed the
    I/O.  This patch removes the evaluation code and accepts whatever the upper
    layer returns.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20230803211932.155745-1-justintee8345@gmail.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpt3sas: Perform additional retries if doorbell read returns 0 [+ + +]
Author: Ranjan Kumar <ranjan.kumar@broadcom.com>
Date:   Tue Aug 29 14:30:19 2023 +0530

    scsi: mpt3sas: Perform additional retries if doorbell read returns 0
    
    commit 4ca10f3e31745d35249a727ecd108eb58f0a8c5e upstream.
    
    The driver retries certain register reads 3 times if the returned value is
    0. This was done because the controller could return 0 for certain
    registers if other registers were being accessed concurrently by the BMC.
    
    In certain systems with increased BMC interactions, the register values
    returned can be 0 for longer than 3 retries. Change the retry count from 3
    to 30 for the affected registers to prevent problems with out-of-band
    management.
    
    Fixes: b899202901a8 ("scsi: mpt3sas: Add separate function for aero doorbell reads")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
    Link: https://lore.kernel.org/r/20230829090020.5417-2-ranjan.kumar@broadcom.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qedf: Do not touch __user pointer in qedf_dbg_debug_cmd_read() directly [+ + +]
Author: Oleksandr Natalenko <oleksandr@natalenko.name>
Date:   Mon Jul 31 10:40:33 2023 +0200

    scsi: qedf: Do not touch __user pointer in qedf_dbg_debug_cmd_read() directly
    
    [ Upstream commit 31b5991a9a91ba97237ac9da509d78eec453ff72 ]
    
    The qedf_dbg_debug_cmd_read() function invokes sprintf() directly on a
    __user pointer, which may crash the kernel.
    
    Avoid doing that by using a small on-stack buffer for scnprintf() and then
    calling simple_read_from_buffer() which does a proper copy_to_user() call.
    
    Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
    Link: https://lore.kernel.org/lkml/20230724120241.40495-1-oleksandr@redhat.com/
    Link: https://lore.kernel.org/linux-scsi/20230726101236.11922-1-skashyap@marvell.com/
    Cc: Saurav Kashyap <skashyap@marvell.com>
    Cc: Rob Evers <revers@redhat.com>
    Cc: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Jozef Bacik <jobacik@redhat.com>
    Cc: Laurence Oberman <loberman@redhat.com>
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: GR-QLogic-Storage-Upstream@marvell.com
    Cc: linux-scsi@vger.kernel.org
    Reviewed-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Acked-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com>
    Link: https://lore.kernel.org/r/20230731084034.37021-3-oleksandr@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qedf: Do not touch __user pointer in qedf_dbg_fp_int_cmd_read() directly [+ + +]
Author: Oleksandr Natalenko <oleksandr@natalenko.name>
Date:   Mon Jul 31 10:40:34 2023 +0200

    scsi: qedf: Do not touch __user pointer in qedf_dbg_fp_int_cmd_read() directly
    
    [ Upstream commit 25dbc20deab5165f847b4eb42f376f725a986ee8 ]
    
    The qedf_dbg_fp_int_cmd_read() function invokes sprintf() directly on a
    __user pointer, which may crash the kernel.
    
    Avoid doing that by vmalloc()'ating a buffer for scnprintf() and then
    calling simple_read_from_buffer() which does a proper copy_to_user() call.
    
    Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
    Link: https://lore.kernel.org/lkml/20230724120241.40495-1-oleksandr@redhat.com/
    Link: https://lore.kernel.org/linux-scsi/20230726101236.11922-1-skashyap@marvell.com/
    Cc: Saurav Kashyap <skashyap@marvell.com>
    Cc: Rob Evers <revers@redhat.com>
    Cc: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Jozef Bacik <jobacik@redhat.com>
    Cc: Laurence Oberman <loberman@redhat.com>
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: GR-QLogic-Storage-Upstream@marvell.com
    Cc: linux-scsi@vger.kernel.org
    Reviewed-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Acked-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com>
    Link: https://lore.kernel.org/r/20230731084034.37021-4-oleksandr@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qedf: Do not touch __user pointer in qedf_dbg_stop_io_on_error_cmd_read() directly [+ + +]
Author: Oleksandr Natalenko <oleksandr@natalenko.name>
Date:   Mon Jul 31 10:40:32 2023 +0200

    scsi: qedf: Do not touch __user pointer in qedf_dbg_stop_io_on_error_cmd_read() directly
    
    [ Upstream commit 7d3d20dee4f648ec44e9717d5f647d594d184433 ]
    
    The qedf_dbg_stop_io_on_error_cmd_read() function invokes sprintf()
    directly on a __user pointer, which may crash the kernel.
    
    Avoid doing that by using a small on-stack buffer for scnprintf() and then
    calling simple_read_from_buffer() which does a proper copy_to_user() call.
    
    Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
    Link: https://lore.kernel.org/lkml/20230724120241.40495-1-oleksandr@redhat.com/
    Link: https://lore.kernel.org/linux-scsi/20230726101236.11922-1-skashyap@marvell.com/
    Cc: Saurav Kashyap <skashyap@marvell.com>
    Cc: Rob Evers <revers@redhat.com>
    Cc: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Jozef Bacik <jobacik@redhat.com>
    Cc: Laurence Oberman <loberman@redhat.com>
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: GR-QLogic-Storage-Upstream@marvell.com
    Cc: linux-scsi@vger.kernel.org
    Reviewed-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Acked-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com>
    Link: https://lore.kernel.org/r/20230731084034.37021-2-oleksandr@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock [+ + +]
Author: Chengfeng Ye <dg573847474@gmail.com>
Date:   Wed Jul 26 12:56:55 2023 +0000

    scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock
    
    [ Upstream commit dd64f80587190265ca8a0f4be6c64c2fda6d3ac2 ]
    
    As &qedi_percpu->p_work_lock is acquired by hard IRQ qedi_msix_handler(),
    other acquisitions of the same lock under process context should disable
    IRQ, otherwise deadlock could happen if the IRQ preempts the execution
    while the lock is held in process context on the same CPU.
    
    qedi_cpu_offline() is one such function which acquires the lock in process
    context.
    
    [Deadlock Scenario]
    qedi_cpu_offline()
        ->spin_lock(&p->p_work_lock)
            <irq>
            ->qedi_msix_handler()
            ->edi_process_completions()
            ->spin_lock_irqsave(&p->p_work_lock, flags); (deadlock here)
    
    This flaw was found by an experimental static analysis tool I am developing
    for IRQ-related deadlocks.
    
    The tentative patch fix the potential deadlock by spin_lock_irqsave()
    under process context.
    
    Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
    Link: https://lore.kernel.org/r/20230726125655.4197-1-dg573847474@gmail.com
    Acked-by: Manish Rangankar <mrangankar@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla4xxx: Add length check when parsing nlattrs [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Sun Jul 23 16:00:53 2023 +0800

    scsi: qla4xxx: Add length check when parsing nlattrs
    
    [ Upstream commit 47cd3770e31df942e2bb925a9a855c79ed0662eb ]
    
    There are three places that qla4xxx parses nlattrs:
    
     - qla4xxx_set_chap_entry()
    
     - qla4xxx_iface_set_param()
    
     - qla4xxx_sysfs_ddb_set_param()
    
    and each of them directly converts the nlattr to specific pointer of
    structure without length checking. This could be dangerous as those
    attributes are not validated and a malformed nlattr (e.g., length 0) could
    result in an OOB read that leaks heap dirty data.
    
    Add the nla_len check before accessing the nlattr data and return EINVAL if
    the length check fails.
    
    Fixes: 26ffd7b45fe9 ("[SCSI] qla4xxx: Add support to set CHAP entries")
    Fixes: 1e9e2be3ee03 ("[SCSI] qla4xxx: Add flash node mgmt support")
    Fixes: 00c31889f751 ("[SCSI] qla4xxx: fix data alignment and use nl helpers")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Link: https://lore.kernel.org/r/20230723080053.3714534-1-linma@zju.edu.cn
    Reviewed-by: Chris Leech <cleech@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: RDMA/srp: Fix residual handling [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon Jul 24 13:08:30 2023 -0700

    scsi: RDMA/srp: Fix residual handling
    
    [ Upstream commit 89e637c19b2441aabc8dbf22a8745b932fd6996e ]
    
    Although the code for residual handling in the SRP initiator follows the
    SCSI documentation, that documentation has never been correct. Because
    scsi_finish_command() starts from the data buffer length and subtracts the
    residual, scsi_set_resid() must not be called if a residual overflow
    occurs. Hence remove the scsi_set_resid() calls from the SRP initiator if a
    residual overflow occurrs.
    
    Cc: Leon Romanovsky <leon@kernel.org>
    Cc: Jason Gunthorpe <jgg@nvidia.com>
    Fixes: 9237f04e12cc ("scsi: core: Fix scsi_get/set_resid() interface")
    Fixes: e714531a349f ("IB/srp: Fix residual handling")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20230724200843.3376570-3-bvanassche@acm.org
    Acked-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: Fix residual handling [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon Jul 24 13:08:29 2023 -0700

    scsi: ufs: Fix residual handling
    
    [ Upstream commit 2903265e27bfc6dea915dd9e17a1b2587f621f73 ]
    
    Only call scsi_set_resid() in case of an underflow. Do not call
    scsi_set_resid() in case of an overflow.
    
    Cc: Avri Altman <avri.altman@wdc.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: cb38845d90fc ("scsi: ufs: core: Set the residual byte count")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20230724200843.3376570-2-bvanassche@acm.org
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
security: keys: perform capable check only on privileged operations [+ + +]
Author: Christian Göttsche <cgzones@googlemail.com>
Date:   Thu May 11 14:32:52 2023 +0200

    security: keys: perform capable check only on privileged operations
    
    [ Upstream commit 2d7f105edbb3b2be5ffa4d833abbf9b6965e9ce7 ]
    
    If the current task fails the check for the queried capability via
    `capable(CAP_SYS_ADMIN)` LSMs like SELinux generate a denial message.
    Issuing such denial messages unnecessarily can lead to a policy author
    granting more privileges to a subject than needed to silence them.
    
    Reorder CAP_SYS_ADMIN checks after the check whether the operation is
    actually privileged.
    
    Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/bpf: Clean up fmod_ret in bench_rename test script [+ + +]
Author: Yipeng Zou <zouyipeng@huawei.com>
Date:   Mon Aug 14 11:07:27 2023 +0800

    selftests/bpf: Clean up fmod_ret in bench_rename test script
    
    [ Upstream commit 83a89c4b6ae93481d3f618aba6a29d89208d26ed ]
    
    Running the bench_rename test script, the following error occurs:
    
      # ./benchs/run_bench_rename.sh
      base      :    0.819 ± 0.012M/s
      kprobe    :    0.538 ± 0.009M/s
      kretprobe :    0.503 ± 0.004M/s
      rawtp     :    0.779 ± 0.020M/s
      fentry    :    0.726 ± 0.007M/s
      fexit     :    0.691 ± 0.007M/s
      benchmark 'rename-fmodret' not found
    
    The bench_rename_fmodret has been removed in commit b000def2e052
    ("selftests: Remove fmod_ret from test_overhead"), thus remove it
    from the runners in the test script.
    
    Fixes: b000def2e052 ("selftests: Remove fmod_ret from test_overhead")
    Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20230814030727.3010390-1-zouyipeng@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: Fix bpf_nf failure upon test rerun [+ + +]
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Mon Jun 26 15:19:42 2023 +0200

    selftests/bpf: Fix bpf_nf failure upon test rerun
    
    [ Upstream commit 17e8e5d6e09adb4b4f4fb5c89b3ec3fcae2c64a6 ]
    
    Alexei reported:
    
      After fast forwarding bpf-next today bpf_nf test started to fail when
      run twice:
    
      $ ./test_progs -t bpf_nf
      #17      bpf_nf:OK
      Summary: 1/10 PASSED, 0 SKIPPED, 0 FAILED
    
      $ ./test_progs -t bpf_nf
      All error logs:
      test_bpf_nf_ct:PASS:test_bpf_nf__open_and_load 0 nsec
      test_bpf_nf_ct:PASS:iptables-legacy -t raw -A PREROUTING -j CONNMARK
      --set-mark 42/0 0 nsec
      (network_helpers.c:102: errno: Address already in use) Failed to bind socket
      test_bpf_nf_ct:FAIL:start_server unexpected start_server: actual -1 < expected 0
      #17/1    bpf_nf/xdp-ct:FAIL
      test_bpf_nf_ct:PASS:test_bpf_nf__open_and_load 0 nsec
      test_bpf_nf_ct:PASS:iptables-legacy -t raw -A PREROUTING -j CONNMARK
      --set-mark 42/0 0 nsec
      (network_helpers.c:102: errno: Address already in use) Failed to bind socket
      test_bpf_nf_ct:FAIL:start_server unexpected start_server: actual -1 < expected 0
      #17/2    bpf_nf/tc-bpf-ct:FAIL
      #17      bpf_nf:FAIL
      Summary: 0/8 PASSED, 0 SKIPPED, 1 FAILED
    
    I was able to locally reproduce as well. Rearrange the connection teardown
    so that the client closes its connection first so that we don't need to
    linger in TCP time-wait.
    
    Fixes: e81fbd4c1ba7 ("selftests/bpf: Add existing connection bpf_*_ct_lookup() test")
    Reported-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/CAADnVQ+0dnDq_v_vH1EfkacbfGnHANaon7zsw10pMb-D9FS0Pw@mail.gmail.com
    Link: https://lore.kernel.org/bpf/20230626131942.5100-1-daniel@iogearbox.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: Fix repeat option when kfunc_call verification fails [+ + +]
Author: Yipeng Zou <zouyipeng@huawei.com>
Date:   Mon Aug 14 11:14:34 2023 +0800

    selftests/bpf: Fix repeat option when kfunc_call verification fails
    
    [ Upstream commit 811915db674f8daf19bb4fcb67da9017235ce26d ]
    
    There is no way where topts.repeat can be set to 1 when tc_test fails.
    Fix the typo where the break statement slipped by one line.
    
    Fixes: fb66223a244f ("selftests/bpf: add test for accessing ctx from syscall program type")
    Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Li Zetao <lizetao1@huawei.com>
    Link: https://lore.kernel.org/bpf/20230814031434.3077944-1-zouyipeng@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: fix static assert compilation issue for test_cls_*.c [+ + +]
Author: Alan Maguire <alan.maguire@oracle.com>
Date:   Wed Aug 2 08:39:06 2023 +0100

    selftests/bpf: fix static assert compilation issue for test_cls_*.c
    
    [ Upstream commit 416c6d01244ecbf0abfdb898fd091b50ef951b48 ]
    
    commit bdeeed3498c7 ("libbpf: fix offsetof() and container_of() to work with CO-RE")
    
    ...was backported to stable trees such as 5.15. The problem is that with older
    LLVM/clang (14/15) - which is often used for older kernels - we see compilation
    failures in BPF selftests now:
    
    In file included from progs/test_cls_redirect_subprogs.c:2:
    progs/test_cls_redirect.c:90:2: error: static assertion expression is not an integral constant expression
            sizeof(flow_ports_t) !=
            ^~~~~~~~~~~~~~~~~~~~~~~
    progs/test_cls_redirect.c:91:3: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
                    offsetofend(struct bpf_sock_tuple, ipv4.dport) -
                    ^
    progs/test_cls_redirect.c:32:3: note: expanded from macro 'offsetofend'
            (offsetof(TYPE, MEMBER) + sizeof((((TYPE *)0)->MEMBER)))
             ^
    tools/testing/selftests/bpf/tools/include/bpf/bpf_helpers.h:86:33: note: expanded from macro 'offsetof'
                                     ^
    In file included from progs/test_cls_redirect_subprogs.c:2:
    progs/test_cls_redirect.c:95:2: error: static assertion expression is not an integral constant expression
            sizeof(flow_ports_t) !=
            ^~~~~~~~~~~~~~~~~~~~~~~
    progs/test_cls_redirect.c:96:3: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
                    offsetofend(struct bpf_sock_tuple, ipv6.dport) -
                    ^
    progs/test_cls_redirect.c:32:3: note: expanded from macro 'offsetofend'
            (offsetof(TYPE, MEMBER) + sizeof((((TYPE *)0)->MEMBER)))
             ^
    tools/testing/selftests/bpf/tools/include/bpf/bpf_helpers.h:86:33: note: expanded from macro 'offsetof'
                                     ^
    2 errors generated.
    make: *** [Makefile:594: tools/testing/selftests/bpf/test_cls_redirect_subprogs.bpf.o] Error 1
    
    The problem is the new offsetof() does not play nice with static asserts.
    Given that the context is a static assert (and CO-RE relocation is not
    needed at compile time), offsetof() usage can be replaced by restoring
    the original offsetof() definition as __builtin_offsetof().
    
    Fixes: bdeeed3498c7 ("libbpf: fix offsetof() and container_of() to work with CO-RE")
    Reported-by: Colm Harrington <colm.harrington@oracle.com>
    Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
    Tested-by: Yipeng Zou <zouyipeng@huawei.com>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Link: https://lore.kernel.org/r/20230802073906.3197480-1-alan.maguire@oracle.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/futex: Order calls to futex_lock_pi [+ + +]
Author: Nysal Jan K.A <nysal@linux.ibm.com>
Date:   Mon Aug 14 13:39:27 2023 +0530

    selftests/futex: Order calls to futex_lock_pi
    
    [ Upstream commit fbf4dec702774286db409815ffb077711a96b824 ]
    
    Observed occassional failures in the futex_wait_timeout test:
    
    ok 1 futex_wait relative succeeds
    ok 2 futex_wait_bitset realtime succeeds
    ok 3 futex_wait_bitset monotonic succeeds
    ok 4 futex_wait_requeue_pi realtime succeeds
    ok 5 futex_wait_requeue_pi monotonic succeeds
    not ok 6 futex_lock_pi realtime returned 0
    ......
    
    The test expects the child thread to complete some steps before
    the parent thread gets to run. There is an implicit expectation
    of the order of invocation of futex_lock_pi between the child thread
    and the parent thread. Make this order explicit. If the order is
    not met, the futex_lock_pi call in the parent thread succeeds and
    will not timeout.
    
    Fixes: f4addd54b161 ("selftests: futex: Expand timeout test")
    Signed-off-by: Nysal Jan K.A <nysal@linux.ibm.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/harness: Actually report SKIP for signal tests [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Aug 7 10:43:58 2023 -0700

    selftests/harness: Actually report SKIP for signal tests
    
    [ Upstream commit b3d46e11fec0c5a8972e5061bb1462119ae5736d ]
    
    Tests that were expecting a signal were not correctly checking for a
    SKIP condition. Move the check before the signal checking when
    processing test result.
    
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Will Drewry <wad@chromium.org>
    Cc: linux-kselftest@vger.kernel.org
    Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED [+ + +]
Author: Jeff Xu <jeffxu@google.com>
Date:   Wed Jul 5 06:33:15 2023 +0000

    selftests/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED
    
    [ Upstream commit badbbcd76545c58eff64bb1548f7f834a30dc52a ]
    
    Add selftest for sysctl vm.memfd_noexec is 2
    (MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED)
    
    memfd_create(.., MFD_EXEC) should fail in this case.
    
    Link: https://lkml.kernel.org/r/20230705063315.3680666-3-jeffxu@google.com
    Reported-by: Dominique Martinet <asmadeus@codewreck.org>
    Closes: https://lore.kernel.org/linux-mm/CABi2SkXUX_QqTQ10Yx9bBUGpN1wByOi_=gZU6WEy5a8MaQY3Jw@mail.gmail.com/T/
    Signed-off-by: Jeff Xu <jeffxu@google.com>
    Cc: Daniel Verkamp <dverkamp@chromium.org>
    Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Jorge Lucangeli Obes <jorgelo@chromium.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: kernel test robot <lkp@intel.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 202e14222fad ("memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/resctrl: Add resctrl.h into build deps [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 16:14:49 2023 +0300

    selftests/resctrl: Add resctrl.h into build deps
    
    [ Upstream commit 8e289f4542890168705219e54f0231dccfabddbe ]
    
    Makefile only lists *.c as build dependencies for the resctrl_tests
    executable which excludes resctrl.h.
    
    Add *.h to wildcard() to include resctrl.h.
    
    Fixes: 591a6e8588fc ("selftests/resctrl: Add basic resctrl file system operations and data")
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Tested-by: Babu Moger <babu.moger@amd.com>
    Tested-by: Shaopeng Tan (Fujitsu) <tan.shaopeng@fujitsu.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/resctrl: Close perf value read fd on errors [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 16:14:52 2023 +0300

    selftests/resctrl: Close perf value read fd on errors
    
    [ Upstream commit 51a0c3b7f028169e40db930575dd01fe81c3e765 ]
    
    Perf event fd (fd_lm) is not closed when run_fill_buf() returns error.
    
    Close fd_lm only in cat_val() to make it easier to track it is always
    closed.
    
    Fixes: 790bf585b0ee ("selftests/resctrl: Add Cache Allocation Technology (CAT) selftest")
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Tested-by: Babu Moger <babu.moger@amd.com>
    Tested-by: Shaopeng Tan (Fujitsu) <tan.shaopeng@fujitsu.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/resctrl: Don't leak buffer in fill_cache() [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 16:14:50 2023 +0300

    selftests/resctrl: Don't leak buffer in fill_cache()
    
    [ Upstream commit 2d320b1029ee7329ee0638181be967789775b962 ]
    
    The error path in fill_cache() does return before the allocated buffer
    is freed leaking the buffer.
    
    The leak was introduced when fill_cache_read() started to return errors
    in commit c7b607fa9325 ("selftests/resctrl: Fix null pointer
    dereference on open failed"), before that both fill functions always
    returned 0.
    
    Move free() earlier to prevent the mem leak.
    
    Fixes: c7b607fa9325 ("selftests/resctrl: Fix null pointer dereference on open failed")
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Tested-by: Babu Moger <babu.moger@amd.com>
    Tested-by: Shaopeng Tan (Fujitsu) <tan.shaopeng@fujitsu.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/resctrl: Unmount resctrl FS if child fails to run benchmark [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jul 17 16:14:51 2023 +0300

    selftests/resctrl: Unmount resctrl FS if child fails to run benchmark
    
    [ Upstream commit f99e413eb54652e2436cc56d081176bc9a34cd8d ]
    
    A child calls PARENT_EXIT() when it fails to run a benchmark to kill
    the parent process. PARENT_EXIT() lacks unmount for the resctrl FS and
    the parent won't be there to unmount it either after it gets killed.
    
    Add the resctrl FS unmount also to PARENT_EXIT().
    
    Fixes: 591a6e8588fc ("selftests/resctrl: Add basic resctrl file system operations and data")
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Tested-by: Babu Moger <babu.moger@amd.com>
    Tested-by: Shaopeng Tan (Fujitsu) <tan.shaopeng@fujitsu.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: memfd: error out test process when child test fails [+ + +]
Author: Aleksa Sarai <cyphar@cyphar.com>
Date:   Mon Aug 14 18:40:57 2023 +1000

    selftests: memfd: error out test process when child test fails
    
    [ Upstream commit 99f34659e78b9b781a3248e0b080b4dfca4957e2 ]
    
    Patch series "memfd: cleanups for vm.memfd_noexec", v2.
    
    The most critical issue with vm.memfd_noexec=2 (the fact that passing
    MFD_EXEC would bypass it entirely[1]) has been fixed in Andrew's
    tree[2], but there are still some outstanding issues that need to be
    addressed:
    
     * vm.memfd_noexec=2 shouldn't reject old-style memfd_create(2) syscalls
       because it will make it far to difficult to ever migrate. Instead it
       should imply MFD_EXEC.
    
     * The dmesg warnings are pr_warn_once(), which on most systems means
       that they will be used up by systemd or some other boot process and
       userspace developers will never see it.
    
       - For the !(flags & (MFD_EXEC | MFD_NOEXEC_SEAL)) case, outputting a
         rate-limited message to the kernel log is necessary to tell
         userspace that they should add the new flags.
    
         Arguably the most ideal way to deal with the spam concern[3,4]
         while still prompting userspace to switch to the new flags would be
         to only log the warning once per task or something similar.
         However, adding something to task_struct for tracking this would be
         needless bloat for a single pr_warn_ratelimited().
    
         So just switch to pr_info_ratelimited() to avoid spamming the log
         with something that isn't a real warning. There's lots of
         info-level stuff in dmesg, it seems really unlikely that this
         should be an actual problem. Most programs are already switching to
         the new flags anyway.
    
       - For the vm.memfd_noexec=2 case, we need to log a warning for every
         failure because otherwise userspace will have no idea why their
         previously working program started returning -EACCES (previously
         -EINVAL) from memfd_create(2). pr_warn_once() is simply wrong here.
    
     * The racheting mechanism for vm.memfd_noexec makes it incredibly
       unappealing for most users to enable the sysctl because enabling it
       on &init_pid_ns means you need a system reboot to unset it. Given the
       actual security threat being protected against, CAP_SYS_ADMIN users
       being restricted in this way makes little sense.
    
       The argument for this ratcheting by the original author was that it
       allows you to have a hierarchical setting that cannot be unset by
       child pidnses, but this is not accurate -- changing the parent
       pidns's vm.memfd_noexec setting to be more restrictive didn't affect
       children.
    
       Instead, switch the vm.memfd_noexec sysctl to be properly
       hierarchical and allow CAP_SYS_ADMIN users (in the pidns's owning
       userns) to lower the setting as long as it is not lower than the
       parent's effective setting. This change also makes it so that
       changing a parent pidns's vm.memfd_noexec will affect all
       descendants, providing a properly hierarchical setting. The
       performance impact of this is incredibly minimal since the maximum
       depth of pidns is 32 and it is only checked during memfd_create(2)
       and unshare(CLONE_NEWPID).
    
     * The memfd selftests would not exit with a non-zero error code when
       certain tests that ran in a forked process (specifically the ones
       related to MFD_EXEC and MFD_NOEXEC_SEAL) failed.
    
    [1]: https://lore.kernel.org/all/ZJwcsU0vI-nzgOB_@codewreck.org/
    [2]: https://lore.kernel.org/all/20230705063315.3680666-1-jeffxu@google.com/
    [3]: https://lore.kernel.org/Y5yS8wCnuYGLHMj4@x1n/
    [4]: https://lore.kernel.org/f185bb42-b29c-977e-312e-3349eea15383@linuxfoundation.org/
    
    This patch (of 5):
    
    Before this change, a test runner using this self test would see a return
    code of 0 when the tests using a child process (namely the MFD_NOEXEC_SEAL
    and MFD_EXEC tests) failed, masking test failures.
    
    Link: https://lkml.kernel.org/r/20230814-memfd-vm-noexec-uapi-fixes-v2-0-7ff9e3e10ba6@cyphar.com
    Link: https://lkml.kernel.org/r/20230814-memfd-vm-noexec-uapi-fixes-v2-1-7ff9e3e10ba6@cyphar.com
    Fixes: 11f75a01448f ("selftests/memfd: add tests for MFD_NOEXEC_SEAL MFD_EXEC")
    Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
    Reviewed-by: Jeff Xu <jeffxu@google.com>
    Cc: "Christian Brauner (Microsoft)" <brauner@kernel.org>
    Cc: Daniel Verkamp <dverkamp@chromium.org>
    Cc: Dominique Martinet <asmadeus@codewreck.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: sc16is7xx: fix regression with GPIO configuration [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Mon Aug 7 17:45:54 2023 -0400

    serial: sc16is7xx: fix regression with GPIO configuration
    
    [ Upstream commit 0499942928341d572a42199580433c2b0725211e ]
    
    Commit 679875d1d880 ("sc16is7xx: Separate GPIOs from modem control lines")
    and commit 21144bab4f11 ("sc16is7xx: Handle modem status lines")
    changed the function of the GPIOs pins to act as modem control
    lines without any possibility of selecting GPIO function.
    
    As a consequence, applications that depends on GPIO lines configured
    by default as GPIO pins no longer work as expected.
    
    Also, the change to select modem control lines function was done only
    for channel A of dual UART variants (752/762). This was not documented
    in the log message.
    
    Allow to specify GPIO or modem control line function in the device
    tree, and for each of the ports (A or B).
    
    Do so by using the new device-tree property named
    "nxp,modem-control-line-ports" (property added in separate patch).
    
    When registering GPIO chip controller, mask-out GPIO pins declared as
    modem control lines according to this new DT property.
    
    Fixes: 679875d1d880 ("sc16is7xx: Separate GPIOs from modem control lines")
    Fixes: 21144bab4f11 ("sc16is7xx: Handle modem status lines")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com>
    Tested-by: Lech Perczak <lech.perczak@camlingroup.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20230807214556.540627-5-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: sc16is7xx: remove obsolete out_thread label [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Mon Aug 7 17:45:52 2023 -0400

    serial: sc16is7xx: remove obsolete out_thread label
    
    [ Upstream commit dabc54a45711fe77674a6c0348231e00e66bd567 ]
    
    Commit c8f71b49ee4d ("serial: sc16is7xx: setup GPIO controller later
    in probe") moved GPIO setup code later in probe function. Doing so
    also required to move ports cleanup code (out_ports label) after the
    GPIO cleanup code.
    
    After these moves, the out_thread label becomes misplaced and makes
    part of the cleanup code illogical.
    
    This patch remove the now obsolete out_thread label and make GPIO
    setup code jump to out_ports label if it fails.
    
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com>
    Tested-by: Lech Perczak <lech.perczak@camlingroup.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20230807214556.540627-3-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 049994292834 ("serial: sc16is7xx: fix regression with GPIO configuration")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: sprd: Assign sprd_port after initialized to avoid wrong access [+ + +]
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date:   Tue Jul 25 14:40:52 2023 +0800

    serial: sprd: Assign sprd_port after initialized to avoid wrong access
    
    [ Upstream commit f9608f1887568b728839d006024585ab02ef29e5 ]
    
    The global pointer 'sprd_port' may not zero when sprd_probe returns
    failure, that is a risk for sprd_port to be accessed afterward, and
    may lead to unexpected errors.
    
    For example:
    
    There are two UART ports, UART1 is used for console and configured in
    kernel command line, i.e. "console=";
    
    The UART1 probe failed and the memory allocated to sprd_port[1] was
    released, but sprd_port[1] was not set to NULL;
    
    In UART2 probe, the same virtual address was allocated to sprd_port[2],
    and UART2 probe process finally will go into sprd_console_setup() to
    register UART1 as console since it is configured as preferred console
    (filled to console_cmdline[]), but the console parameters (sprd_port[1])
    belong to UART2.
    
    So move the sprd_port[] assignment to where the port already initialized
    can avoid the above issue.
    
    Fixes: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support")
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Link: https://lore.kernel.org/r/20230725064053.235448-1-chunyan.zhang@unisoc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: sprd: Fix DMA buffer leak issue [+ + +]
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date:   Tue Jul 25 14:40:53 2023 +0800

    serial: sprd: Fix DMA buffer leak issue
    
    [ Upstream commit cd119fdc3ee1450fbf7f78862b5de44c42b6e47f ]
    
    Release DMA buffer when _probe() returns failure to avoid memory leak.
    
    Fixes: f4487db58eb7 ("serial: sprd: Add DMA mode support")
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230725064053.235448-2-chunyan.zhang@unisoc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: tegra: handle clk prepare error in tegra_uart_hw_init() [+ + +]
Author: Yi Yang <yiyang13@huawei.com>
Date:   Thu Aug 17 18:54:06 2023 +0800

    serial: tegra: handle clk prepare error in tegra_uart_hw_init()
    
    [ Upstream commit 5abd01145d0cc6cd1b7c2fe6ee0b9ea0fa13671e ]
    
    In tegra_uart_hw_init(), the return value of clk_prepare_enable() should
    be checked since it might fail.
    
    Fixes: e9ea096dd225 ("serial: tegra: add serial driver")
    Signed-off-by: Yi Yang <yiyang13@huawei.com>
    Link: https://lore.kernel.org/r/20230817105406.228674-1-yiyang13@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sfc: Check firmware supports Ethernet PTP filter [+ + +]
Author: Alex Austin <alex.austin@amd.com>
Date:   Thu Aug 24 17:46:57 2023 +0100

    sfc: Check firmware supports Ethernet PTP filter
    
    [ Upstream commit c4413a20fa6d7c4888009fb7dd391685f196cd36 ]
    
    Not all firmware variants support RSS filters. Do not fail all PTP
    functionality when raw ethernet PTP filters fail to insert.
    
    Fixes: e4616f64726b ("sfc: support PTP over Ethernet")
    Signed-off-by: Alex Austin <alex.austin@amd.com>
    Acked-by: Edward Cree <ecree.xilinx@gmail.com>
    Reviewed-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>
    Link: https://lore.kernel.org/r/20230824164657.42379-1-alex.austin@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
skbuff: skb_segment, Call zero copy functions before using skbuff frags [+ + +]
Author: Mohamed Khalfella <mkhalfella@purestorage.com>
Date:   Thu Aug 31 02:17:02 2023 -0600

    skbuff: skb_segment, Call zero copy functions before using skbuff frags
    
    commit 2ea35288c83b3d501a88bc17f2df8f176b5cc96f upstream.
    
    Commit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions
    once per nskb") added the call to zero copy functions in skb_segment().
    The change introduced a bug in skb_segment() because skb_orphan_frags()
    may possibly change the number of fragments or allocate new fragments
    altogether leaving nrfrags and frag to point to the old values. This can
    cause a panic with stacktrace like the one below.
    
    [  193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc
    [  193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G           O      5.15.123+ #26
    [  193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0
    [  194.021892] Call Trace:
    [  194.027422]  <TASK>
    [  194.072861]  tcp_gso_segment+0x107/0x540
    [  194.082031]  inet_gso_segment+0x15c/0x3d0
    [  194.090783]  skb_mac_gso_segment+0x9f/0x110
    [  194.095016]  __skb_gso_segment+0xc1/0x190
    [  194.103131]  netem_enqueue+0x290/0xb10 [sch_netem]
    [  194.107071]  dev_qdisc_enqueue+0x16/0x70
    [  194.110884]  __dev_queue_xmit+0x63b/0xb30
    [  194.121670]  bond_start_xmit+0x159/0x380 [bonding]
    [  194.128506]  dev_hard_start_xmit+0xc3/0x1e0
    [  194.131787]  __dev_queue_xmit+0x8a0/0xb30
    [  194.138225]  macvlan_start_xmit+0x4f/0x100 [macvlan]
    [  194.141477]  dev_hard_start_xmit+0xc3/0x1e0
    [  194.144622]  sch_direct_xmit+0xe3/0x280
    [  194.147748]  __dev_queue_xmit+0x54a/0xb30
    [  194.154131]  tap_get_user+0x2a8/0x9c0 [tap]
    [  194.157358]  tap_sendmsg+0x52/0x8e0 [tap]
    [  194.167049]  handle_tx_zerocopy+0x14e/0x4c0 [vhost_net]
    [  194.173631]  handle_tx+0xcd/0xe0 [vhost_net]
    [  194.176959]  vhost_worker+0x76/0xb0 [vhost]
    [  194.183667]  kthread+0x118/0x140
    [  194.190358]  ret_from_fork+0x1f/0x30
    [  194.193670]  </TASK>
    
    In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags
    local variable in skb_segment() stale. This resulted in the code hitting
    i >= nrfrags prematurely and trying to move to next frag_skb using
    list_skb pointer, which was NULL, and caused kernel panic. Move the call
    to zero copy functions before using frags and nr_frags.
    
    Fixes: bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions once per nskb")
    Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
    Reported-by: Amit Goyal <agoyal@purestorage.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smackfs: Prevent underflow in smk_set_cipso() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Jul 6 08:52:39 2023 +0300

    smackfs: Prevent underflow in smk_set_cipso()
    
    [ Upstream commit 3ad49d37cf5759c3b8b68d02e3563f633d9c1aee ]
    
    There is a upper bound to "catlen" but no lower bound to prevent
    negatives.  I don't see that this necessarily causes a problem but we
    may as well be safe.
    
    Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: qcom: ocmem: Add OCMEM hardware version print [+ + +]
Author: Luca Weiss <luca@z3ntu.xyz>
Date:   Mon May 29 10:41:15 2023 +0200

    soc: qcom: ocmem: Add OCMEM hardware version print
    
    [ Upstream commit e81a16e77259294cd4ff0a9c1fbe5aa0e311a47d ]
    
    It might be useful to know what hardware version of the OCMEM block the
    SoC contains. Add a debug print for that.
    
    Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230509-ocmem-hwver-v3-1-e51f3488e0f4@z3ntu.xyz
    Stable-dep-of: a7b484b1c933 ("soc: qcom: ocmem: Fix NUM_PORTS & NUM_MACROS macros")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: qcom: ocmem: Fix NUM_PORTS & NUM_MACROS macros [+ + +]
Author: Luca Weiss <luca@z3ntu.xyz>
Date:   Wed Jun 14 18:35:47 2023 +0200

    soc: qcom: ocmem: Fix NUM_PORTS & NUM_MACROS macros
    
    [ Upstream commit a7b484b1c9332a1ee12e8799d62a11ee3f8e0801 ]
    
    Since we're using these two macros to read a value from a register, we
    need to use the FIELD_GET instead of the FIELD_PREP macro, otherwise
    we're getting wrong values.
    
    So instead of:
    
      [    3.111779] ocmem fdd00000.sram: 2 ports, 1 regions, 512 macros, not interleaved
    
    we now get the correct value of:
    
      [    3.129672] ocmem fdd00000.sram: 2 ports, 1 regions, 2 macros, not interleaved
    
    Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver")
    Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
    Link: https://lore.kernel.org/r/20230506-msm8226-ocmem-v3-1-79da95a2581f@z3ntu.xyz
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: qcom: smem: Fix incompatible types in comparison [+ + +]
Author: Chen Jiahao <chenjiahao16@huawei.com>
Date:   Tue Aug 1 17:48:07 2023 +0800

    soc: qcom: smem: Fix incompatible types in comparison
    
    [ Upstream commit 5f908786cf44fcb397cfe0f322ef2f41b0909e2a ]
    
    This patch fixes the following sparse error:
    
    drivers/soc/qcom/smem.c:738:30: error: incompatible types in comparison expression (different add        ress spaces):
    drivers/soc/qcom/smem.c:738:30:    void *
    drivers/soc/qcom/smem.c:738:30:    void [noderef] __iomem *
    
    In addr_in_range(), "base" is of type void __iomem *, converting
    void *addr to the same type to fix above sparse error.
    
    Fixes: 20bb6c9de1b7 ("soc: qcom: smem: map only partitions used by local HOST")
    Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
    Link: https://lore.kernel.org/r/20230801094807.4146779-1-chenjiahao16@huawei.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: mpc5xxx-psc: Fix unsigned expression compared with zero [+ + +]
Author: Li Zetao <lizetao1@huawei.com>
Date:   Thu Aug 3 21:48:05 2023 +0800

    spi: mpc5xxx-psc: Fix unsigned expression compared with zero
    
    [ Upstream commit de5e92cb5cefd2968b96075995a36e28298edf71 ]
    
    There is two warnings reported by coccinelle:
    
    ./drivers/spi/spi-mpc512x-psc.c:493:5-13: WARNING:
            Unsigned expression compared with zero: mps -> irq     <     0
    ./drivers/spi/spi-mpc52xx-psc.c:332:5-13: WARNING:
            Unsigned expression compared with zero: mps -> irq     <     0
    
    The commit "208ee586f862"
    ("spi: mpc5xxx-psc: Return immediately if IRQ resource is unavailable")
    was to check whether the IRQ resource is unavailable. When the IRQ
    resource is unavailable, an error code is returned, however, the type
    of "mps->irq" is "unsigned int", causing the error code to flip. Modify
    the type of "mps->irq" to solve this problem.
    
    Fixes: 208ee586f862 ("spi: mpc5xxx-psc: Return immediately if IRQ resource is unavailable")
    Signed-off-by: Li Zetao <lizetao1@huawei.com>
    Link: https://lore.kernel.org/r/20230803134805.1037251-1-lizetao1@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: tegra20-sflash: fix to check return value of platform_get_irq() in tegra_sflash_probe() [+ + +]
Author: Zhang Shurong <zhang_shurong@foxmail.com>
Date:   Sat Jul 22 23:49:09 2023 +0800

    spi: tegra20-sflash: fix to check return value of platform_get_irq() in tegra_sflash_probe()
    
    [ Upstream commit 29a449e765ff70a5bd533be94babb6d36985d096 ]
    
    The platform_get_irq might be failed and return a negative result. So
    there should have an error handling code.
    
    Fixed this by adding an error handling code.
    
    Fixes: 8528547bcc33 ("spi: tegra: add spi driver for sflash controller")
    Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
    Link: https://lore.kernel.org/r/tencent_71FC162D589E4788C2152AAC84CD8D5C6D06@qq.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
splice: always fsnotify_access(in), fsnotify_modify(out) on success [+ + +]
Author: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Date:   Mon Jul 3 16:42:13 2023 +0200

    splice: always fsnotify_access(in), fsnotify_modify(out) on success
    
    [ Upstream commit 12ee4b66af34f8e72f3b2fd93a946a955efe7c86 ]
    
    The current behaviour caused an asymmetry where some write APIs
    (write, sendfile) would notify the written-to/read-from objects,
    but splice wouldn't.
    
    This affected userspace which uses inotify, most notably coreutils
    tail -f, to monitor pipes.
    If the pipe buffer had been filled by a splice-family function:
      * tail wouldn't know and thus wouldn't service the pipe, and
      * all writes to the pipe would block because it's full,
    thus service was denied.
    (For the particular case of tail -f this could be worked around
     with ---disable-inotify.)
    
    Fixes: 983652c69199 ("splice: report related fsnotify events")
    Link: https://lore.kernel.org/linux-fsdevel/jbyihkyk5dtaohdwjyivambb2gffyjs3dodpofafnkkunxq7bu@jngkdxx65pux/t/#u
    Link: https://bugs.debian.org/1039488
    Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
    Acked-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Message-Id: <604ec704d933e0e0121d9e107ce914512e045fad.1688393619.git.nabijaczleweli@nabijaczleweli.xyz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

splice: fsnotify_access(fd)/fsnotify_modify(fd) in vmsplice [+ + +]
Author: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Date:   Mon Jul 3 16:42:17 2023 +0200

    splice: fsnotify_access(fd)/fsnotify_modify(fd) in vmsplice
    
    [ Upstream commit 7f0f1ea069e52d5a16921abd59377a7da6c25149 ]
    
    Same logic applies here: this can fill up the pipe and pollers that rely
    on getting IN_MODIFY notifications never wake up.
    
    Fixes: 983652c69199 ("splice: report related fsnotify events")
    Link: https://lore.kernel.org/linux-fsdevel/jbyihkyk5dtaohdwjyivambb2gffyjs3dodpofafnkkunxq7bu@jngkdxx65pux/t/#u
    Link: https://bugs.debian.org/1039488
    Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
    Acked-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Message-Id: <8d9ad5acb9c5c1dd2376a2ff5da6ac3183115389.1688393619.git.nabijaczleweli@nabijaczleweli.xyz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

splice: fsnotify_access(in), fsnotify_modify(out) on success in tee [+ + +]
Author: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Date:   Mon Jul 3 16:42:21 2023 +0200

    splice: fsnotify_access(in), fsnotify_modify(out) on success in tee
    
    [ Upstream commit 576d498e0ac5caff2d9f6312573ab54d98f12d32 ]
    
    Same logic applies here: this can fill up the pipe, and pollers that rely
    on getting IN_MODIFY notifications never wake up.
    
    Fixes: 983652c69199 ("splice: report related fsnotify events")
    Link: https://lore.kernel.org/linux-fsdevel/jbyihkyk5dtaohdwjyivambb2gffyjs3dodpofafnkkunxq7bu@jngkdxx65pux/t/#u
    Link: https://bugs.debian.org/1039488
    Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
    Acked-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Message-Id: <10d76dd8c85017ae3cd047c9b9a32e26daefdaa2.1688393619.git.nabijaczleweli@nabijaczleweli.xyz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
staging: fbtft: ili9341: use macro FBTFT_REGISTER_SPI_DRIVER [+ + +]
Author: Raphael Gallais-Pou <rgallaispou@gmail.com>
Date:   Tue Jul 18 19:20:24 2023 +0200

    staging: fbtft: ili9341: use macro FBTFT_REGISTER_SPI_DRIVER
    
    [ Upstream commit 4912649e1cf0317bf563f91655e04a303cacaf8d ]
    
    Using FBTFT_REGISTER_DRIVER resolves to a NULL struct spi_device_id. This
    ultimately causes a warning when the module probes. Fixes it.
    
    Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
    Link: https://lore.kernel.org/r/20230718172024.67488-1-rgallaispou@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: tcp_enter_quickack_mode() should be static [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 18 16:20:49 2023 +0000

    tcp: tcp_enter_quickack_mode() should be static
    
    [ Upstream commit 03b123debcbc8db987bda17ed8412cc011064c22 ]
    
    After commit d2ccd7bc8acd ("tcp: avoid resetting ACK timer in DCTCP"),
    tcp_enter_quickack_mode() is only used from net/ipv4/tcp_input.c.
    
    Fixes: d2ccd7bc8acd ("tcp: avoid resetting ACK timer in DCTCP")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Link: https://lore.kernel.org/r/20230718162049.1444938-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal/drivers/imx8mm: Suppress log message on probe deferral [+ + +]
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Sat Jul 8 13:26:46 2023 +0200

    thermal/drivers/imx8mm: Suppress log message on probe deferral
    
    [ Upstream commit 4afcb58ea47e66c025d2b0a5f091dce5aaf95b0f ]
    
    nvmem_cell_read_u32() may return -EPROBE_DEFER if NVMEM supplier has not
    yet been probed. Future reprobe may succeed, so printing:
    
      i.mx8mm_thermal 30260000.tmu: Failed to read OCOTP nvmem cell (-517).
    
    to the log is confusing. Fix this by using dev_err_probe. This also
    elevates the message from warning to error, which is more correct: The
    log message is only ever printed in probe error path and probe aborts
    afterwards, so it really warrants an error-level message.
    
    Fixes: 403291648823 ("thermal/drivers/imx: Add support for loading calibration data from OCOTP")
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230708112647.2897294-1-a.fatoum@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal/drivers/mediatek/lvts_thermal: Disable undesired interrupts [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Jul 6 11:37:35 2023 -0400

    thermal/drivers/mediatek/lvts_thermal: Disable undesired interrupts
    
    [ Upstream commit 487bf099e85b724c824f5fafaf93c6749c4d2120 ]
    
    Out of the many interrupts supported by the hardware, the only ones of
    interest to the driver currently are:
    * The temperature went over the high offset threshold, for any of the
      sensors
    * The temperature went below the low offset threshold, for any of the
      sensors
    * The temperature went over the stage3 threshold
    
    These are the only thresholds configured by the driver through the
    OFFSETH, OFFSETL, and PROTTC registers, respectively.
    
    The current interrupt mask in LVTS_MONINT_CONF, enables many more
    interrupts, including data ready on sensors for both filtered and
    immediate mode. These are not only not handled by the driver, but they
    are also triggered too often, causing unneeded overhead. Disable these
    unnecessary interrupts.
    
    The meaning of each bit can be seen in the comment describing
    LVTS_MONINTST in the IRQ handler.
    
    Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230706153823.201943-5-nfraprado@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal/drivers/mediatek/lvts_thermal: Don't leave threshold zeroed [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Jul 6 11:37:36 2023 -0400

    thermal/drivers/mediatek/lvts_thermal: Don't leave threshold zeroed
    
    [ Upstream commit 77354eaef8218bc40d6b37e783b0b8dcca22a7d9 ]
    
    The thermal framework might leave the low threshold unset if there
    aren't any lower trip points. This leaves the register zeroed, which
    translates to a very high temperature for the low threshold. The
    interrupt for this threshold is then immediately triggered, and the
    state machine gets stuck, preventing any other temperature monitoring
    interrupts to ever trigger.
    
    (The same happens by not setting the Cold or Hot to Normal thresholds
    when using those)
    
    Set the unused threshold to a valid low value. This value was chosen so
    that for any valid golden temperature read from the efuse, when the
    value is converted to raw and back again to milliCelsius, the result
    doesn't underflow.
    
    Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230706153823.201943-6-nfraprado@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal/drivers/mediatek/lvts_thermal: Handle IRQ on all controllers [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Jul 6 11:37:32 2023 -0400

    thermal/drivers/mediatek/lvts_thermal: Handle IRQ on all controllers
    
    [ Upstream commit cbd8c5aae2a988bafd4586bea710eeddc30a82ce ]
    
    There is a single IRQ handler for each LVTS thermal domain, and it is
    supposed to check each of its underlying controllers for the origin of
    the interrupt and clear its status. However due to a typo, only the
    first controller was ever being handled, which resulted in the interrupt
    never being cleared when it happened on the other controllers. Add the
    missing index so interrupts are handled for all controllers.
    
    Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Tested-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230706153823.201943-2-nfraprado@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal/drivers/mediatek/lvts_thermal: Honor sensors in immediate mode [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Jul 6 11:37:33 2023 -0400

    thermal/drivers/mediatek/lvts_thermal: Honor sensors in immediate mode
    
    [ Upstream commit 64de162e34e4cb2982a1d96e492f018026a61c1d ]
    
    Each controller can be configured to operate on immediate or filtered
    mode. On filtered mode, the sensors are enabled by setting the
    corresponding bits in MONCTL0, while on immediate mode, by setting
    MSRCTL1.
    
    Previously, the code would set MSRCTL1 for all four sensors when
    configured to immediate mode, but given that the controller might not
    have all four sensors connected, this would cause interrupts to trigger
    for non-existent sensors. Fix this by handling the MSRCTL1 register
    analogously to the MONCTL0: only enable the sensors that were declared.
    
    Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Tested-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230706153823.201943-3-nfraprado@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal/drivers/mediatek/lvts_thermal: Manage threshold between sensors [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Jul 6 11:37:37 2023 -0400

    thermal/drivers/mediatek/lvts_thermal: Manage threshold between sensors
    
    [ Upstream commit 2bba1acf7a4cbe62abbb4c686e0414209ec5943b ]
    
    Each LVTS thermal controller can have up to four sensors, each capable
    of triggering its own interrupt when its measured temperature crosses
    the configured threshold. The threshold for each sensor is handled
    separately by the thermal framework, since each one is registered with
    its own thermal zone and trips. However, the temperature thresholds are
    configured on the controller, and therefore are shared between all
    sensors on that controller.
    
    When the temperature measured by the sensors is different enough to
    cause the thermal framework to configure different thresholds for each
    one, interrupts start triggering on sensors outside the last threshold
    configured.
    
    To address the issue, track the thresholds required by each sensor and
    only actually set the highest one in the hardware, and disable
    interrupts for all sensors outside the current configured range.
    
    Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230706153823.201943-7-nfraprado@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal/drivers/mediatek/lvts_thermal: Use offset threshold for IRQ [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Jul 6 11:37:34 2023 -0400

    thermal/drivers/mediatek/lvts_thermal: Use offset threshold for IRQ
    
    [ Upstream commit f79e996c7ed27bb196facbcd1c69ee33631d7051 ]
    
    There are two kinds of temperature monitoring interrupts available:
    * High Offset, Low Offset
    * Hot, Hot to normal, Cold
    
    The code currently uses the hot/h2n/cold interrupts, however in a way
    that doesn't work: the cold threshold is left uninitialized, which
    prevents the other thresholds from ever triggering, and the h2n
    interrupt is used as the lower threshold, which prevents the hot
    interrupt from triggering again after the thresholds are updated by the
    thermal framework, since a hot interrupt can only trigger again after
    the hot to normal interrupt has been triggered.
    
    But better yet than addressing those issues, is to use the high/low
    offset interrupts instead. This way only two thresholds need to be
    managed, which have a simpler state machine, making them a better match
    to the thermal framework's high and low thresholds.
    
    Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20230706153823.201943-4-nfraprado@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal/of: Fix potential uninitialized value access [+ + +]
Author: Peng Fan <peng.fan@nxp.com>
Date:   Wed Jul 19 09:16:36 2023 +0800

    thermal/of: Fix potential uninitialized value access
    
    [ Upstream commit f96801f0cfcefc0a16b146596577c53c75ee9773 ]
    
    If of_parse_phandle_with_args() called from __thermal_of_bind() or
    __thermal_of_unbind() fails, cooling_spec.np will not be initialized,
    so move the of_node_put() calls below the respective return value checks
    to avoid dereferencing an uninitialized pointer.
    
    Fixes: 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree initialization")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal: core: constify params in thermal_zone_device_register [+ + +]
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Sat Jul 8 13:27:19 2023 +0200

    thermal: core: constify params in thermal_zone_device_register
    
    [ Upstream commit 80ddce5f2dbd0e83eadc9f9d373439180d599fe5 ]
    
    Since commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone
    parameters structure"), thermal_zone_device_register() allocates a copy
    of the tzp argument and callers need not explicitly manage its lifetime.
    
    This means the function no longer cares about the parameter being
    mutable, so constify it.
    
    No functional change.
    
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tick/rcu: Fix false positive "softirq work is pending" messages [+ + +]
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri Aug 18 16:07:57 2023 -0400

    tick/rcu: Fix false positive "softirq work is pending" messages
    
    [ Upstream commit 96c1fa04f089a7e977a44e4e8fdc92e81be20bef ]
    
    In commit 0345691b24c0 ("tick/rcu: Stop allowing RCU_SOFTIRQ in idle") the
    new function report_idle_softirq() was created by breaking code out of the
    existing can_stop_idle_tick() for kernels v5.18 and newer.
    
    In doing so, the code essentially went from a one conditional:
    
            if (a && b && c)
                    warn();
    
    to a three conditional:
    
            if (!a)
                    return;
            if (!b)
                    return;
            if (!c)
                    return;
            warn();
    
    But that conversion got the condition for the RT specific
    local_bh_blocked() wrong. The original condition was:
    
            !local_bh_blocked()
    
    but the conversion failed to negate it so it ended up as:
    
            if (!local_bh_blocked())
                    return false;
    
    This issue lay dormant until another fixup for the same commit was added
    in commit a7e282c77785 ("tick/rcu: Fix bogus ratelimit condition").
    This commit realized the ratelimit was essentially set to zero instead
    of ten, and hence *no* softirq pending messages would ever be issued.
    
    Once this commit was backported via linux-stable, both the v6.1 and v6.4
    preempt-rt kernels started printing out 10 instances of this at boot:
    
      NOHZ tick-stop error: local softirq work is pending, handler #80!!!
    
    Remove the negation and return when local_bh_blocked() evaluates to true to
    bring the correct behaviour back.
    
    Fixes: 0345691b24c0 ("tick/rcu: Stop allowing RCU_SOFTIRQ in idle")
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Wen Yang <wenyang.linux@foxmail.com>
    Acked-by: Frederic Weisbecker <frederic@kernel.org>
    Link: https://lore.kernel.org/r/20230818200757.1808398-1-paul.gortmaker@windriver.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tmpfs: verify {g,u}id mount options correctly [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Tue Aug 1 18:17:04 2023 +0200

    tmpfs: verify {g,u}id mount options correctly
    
    [ Upstream commit 0200679fc7953177941e41c2a4241d0b6c2c5de8 ]
    
    A while ago we received the following report:
    
    "The other outstanding issue I noticed comes from the fact that
    fsconfig syscalls may occur in a different userns than that which
    called fsopen. That means that resolving the uid/gid via
    current_user_ns() can save a kuid that isn't mapped in the associated
    namespace when the filesystem is finally mounted. This means that it
    is possible for an unprivileged user to create files owned by any
    group in a tmpfs mount (since we can set the SUID bit on the tmpfs
    directory), or a tmpfs that is owned by any user, including the root
    group/user."
    
    The contract for {g,u}id mount options and {g,u}id values in general set
    from userspace has always been that they are translated according to the
    caller's idmapping. In so far, tmpfs has been doing the correct thing.
    But since tmpfs is mountable in unprivileged contexts it is also
    necessary to verify that the resulting {k,g}uid is representable in the
    namespace of the superblock to avoid such bugs as above.
    
    The new mount api's cross-namespace delegation abilities are already
    widely used. After having talked to a bunch of userspace this is the
    most faithful solution with minimal regression risks. I know of one
    users - systemd - that makes use of the new mount api in this way and
    they don't set unresolable {g,u}ids. So the regression risk is minimal.
    
    Link: https://lore.kernel.org/lkml/CALxfFW4BXhEwxR0Q5LSkg-8Vb4r2MONKCcUCVioehXQKr35eHg@mail.gmail.com
    Fixes: f32356261d44 ("vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API")
    Reviewed-by: "Seth Forshee (DigitalOcean)" <sforshee@kernel.org>
    Reported-by: Seth Jenkins <sethjenkins@google.com>
    Message-Id: <20230801-vfs-fs_context-uidgid-v1-1-daf46a050bbf@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tpm: Enable hwrng only for Pluton on AMD CPUs [+ + +]
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Mon Sep 4 21:12:10 2023 +0300

    tpm: Enable hwrng only for Pluton on AMD CPUs
    
    commit 8f7f35e5aa6f2182eabcfa3abef4d898a48e9aa8 upstream.
    
    The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for
    all AMD fTPMs") doesn't work properly on a number of Intel fTPMs.  On the
    reported systems the TPM doesn't reply at bootup and returns back the
    command code. This makes the TPM fail probe on Lenovo Legion Y540 laptop.
    
    Since only Microsoft Pluton is the only known combination of AMD CPU and
    fTPM from other vendor, disable hwrng otherwise. In order to make sysadmin
    aware of this, print also info message to the klog.
    
    Cc: stable@vger.kernel.org
    Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
    Reported-by: Todd Brandt <todd.e.brandt@intel.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804
    Reported-by: Patrick Steinhardt <ps@pks.im>
    Reported-by: Raymond Jay Golo <rjgolo@gmail.com>
    Reported-by: Ronan Pigott <ronan@rjp.ie>
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Cc: Thorsten Leemhuis <regressions@leemhuis.info>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Fix race issue between cpu buffer write and swap [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Thu Aug 31 21:27:39 2023 +0800

    tracing: Fix race issue between cpu buffer write and swap
    
    [ Upstream commit 3163f635b20e9e1fb4659e74f47918c9dddfe64e ]
    
    Warning happened in rb_end_commit() at code:
            if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)))
    
      WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142
            rb_commit+0x402/0x4a0
      Call Trace:
       ring_buffer_unlock_commit+0x42/0x250
       trace_buffer_unlock_commit_regs+0x3b/0x250
       trace_event_buffer_commit+0xe5/0x440
       trace_event_buffer_reserve+0x11c/0x150
       trace_event_raw_event_sched_switch+0x23c/0x2c0
       __traceiter_sched_switch+0x59/0x80
       __schedule+0x72b/0x1580
       schedule+0x92/0x120
       worker_thread+0xa0/0x6f0
    
    It is because the race between writing event into cpu buffer and swapping
    cpu buffer through file per_cpu/cpu0/snapshot:
    
      Write on CPU 0             Swap buffer by per_cpu/cpu0/snapshot on CPU 1
      --------                   --------
                                 tracing_snapshot_write()
                                   [...]
    
      ring_buffer_lock_reserve()
        cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a';
        [...]
        rb_reserve_next_event()
          [...]
    
                                   ring_buffer_swap_cpu()
                                     if (local_read(&cpu_buffer_a->committing))
                                         goto out_dec;
                                     if (local_read(&cpu_buffer_b->committing))
                                         goto out_dec;
                                     buffer_a->buffers[cpu] = cpu_buffer_b;
                                     buffer_b->buffers[cpu] = cpu_buffer_a;
                                     // 2. cpu_buffer has swapped here.
    
          rb_start_commit(cpu_buffer);
          if (unlikely(READ_ONCE(cpu_buffer->buffer)
              != buffer)) { // 3. This check passed due to 'cpu_buffer->buffer'
            [...]           //    has not changed here.
            return NULL;
          }
                                     cpu_buffer_b->buffer = buffer_a;
                                     cpu_buffer_a->buffer = buffer_b;
                                     [...]
    
          // 4. Reserve event from 'cpu_buffer_a'.
    
      ring_buffer_unlock_commit()
        [...]
        cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!!
        rb_commit(cpu_buffer)
          rb_end_commit()  // 6. WARN for the wrong 'committing' state !!!
    
    Based on above analysis, we can easily reproduce by following testcase:
      ``` bash
      #!/bin/bash
    
      dmesg -n 7
      sysctl -w kernel.panic_on_warn=1
      TR=/sys/kernel/tracing
      echo 7 > ${TR}/buffer_size_kb
      echo "sched:sched_switch" > ${TR}/set_event
      while [ true ]; do
              echo 1 > ${TR}/per_cpu/cpu0/snapshot
      done &
      while [ true ]; do
              echo 1 > ${TR}/per_cpu/cpu0/snapshot
      done &
      while [ true ]; do
              echo 1 > ${TR}/per_cpu/cpu0/snapshot
      done &
      ```
    
    To fix it, IIUC, we can use smp_call_function_single() to do the swap on
    the target cpu where the buffer is located, so that above race would be
    avoided.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230831132739.4070878-1-zhengyejian1@huawei.com
    
    Cc: <mhiramat@kernel.org>
    Fixes: f1affcaaa861 ("tracing: Add snapshot in the per_cpu trace directories")
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Introduce pipe_cpumask to avoid race on trace_pipes [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Fri Aug 18 10:26:45 2023 +0800

    tracing: Introduce pipe_cpumask to avoid race on trace_pipes
    
    [ Upstream commit c2489bb7e6be2e8cdced12c16c42fa128403ac03 ]
    
    There is race issue when concurrently splice_read main trace_pipe and
    per_cpu trace_pipes which will result in data read out being different
    from what actually writen.
    
    As suggested by Steven:
      > I believe we should add a ref count to trace_pipe and the per_cpu
      > trace_pipes, where if they are opened, nothing else can read it.
      >
      > Opening trace_pipe locks all per_cpu ref counts, if any of them are
      > open, then the trace_pipe open will fail (and releases any ref counts
      > it had taken).
      >
      > Opening a per_cpu trace_pipe will up the ref count for just that
      > CPU buffer. This will allow multiple tasks to read different per_cpu
      > trace_pipe files, but will prevent the main trace_pipe file from
      > being opened.
    
    But because we only need to know whether per_cpu trace_pipe is open or
    not, using a cpumask instead of using ref count may be easier.
    
    After this patch, users will find that:
     - Main trace_pipe can be opened by only one user, and if it is
       opened, all per_cpu trace_pipes cannot be opened;
     - Per_cpu trace_pipes can be opened by multiple users, but each per_cpu
       trace_pipe can only be opened by one user. And if one of them is
       opened, main trace_pipe cannot be opened.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230818022645.1948314-1-zhengyejian1@huawei.com
    
    Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Remove extra space at the end of hwlat_detector/mode [+ + +]
Author: Mikhail Kobuk <m.kobuk@ispras.ru>
Date:   Fri Aug 25 13:34:30 2023 +0300

    tracing: Remove extra space at the end of hwlat_detector/mode
    
    [ Upstream commit 2cf0dee989a8b2501929eaab29473b6b1fa11057 ]
    
    Space is printed after each mode value including the last one:
    $ echo \"$(sudo cat /sys/kernel/tracing/hwlat_detector/mode)\"
    "none [round-robin] per-cpu "
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230825103432.7750-1-m.kobuk@ispras.ru
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Fixes: 8fa826b7344d ("trace/hwlat: Implement the mode config option")
    Signed-off-by: Mikhail Kobuk <m.kobuk@ispras.ru>
    Reviewed-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Zero the pipe cpumask on alloc to avoid spurious -EBUSY [+ + +]
Author: Brian Foster <bfoster@redhat.com>
Date:   Thu Aug 31 08:55:00 2023 -0400

    tracing: Zero the pipe cpumask on alloc to avoid spurious -EBUSY
    
    commit 3d07fa1dd19035eb0b13ae6697efd5caa9033e74 upstream.
    
    The pipe cpumask used to serialize opens between the main and percpu
    trace pipes is not zeroed or initialized. This can result in
    spurious -EBUSY returns if underlying memory is not fully zeroed.
    This has been observed by immediate failure to read the main
    trace_pipe file on an otherwise newly booted and idle system:
    
     # cat /sys/kernel/debug/tracing/trace_pipe
     cat: /sys/kernel/debug/tracing/trace_pipe: Device or resource busy
    
    Zero the allocation of pipe_cpumask to avoid the problem.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230831125500.986862-1-bfoster@redhat.com
    
    Cc: stable@vger.kernel.org
    Fixes: c2489bb7e6be ("tracing: Introduce pipe_cpumask to avoid race on trace_pipes")
    Reviewed-by: Zheng Yejian <zhengyejian1@huawei.com>
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tty: serial: qcom-geni-serial: Poll primary sequencer irq status after cancel_tx [+ + +]
Author: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
Date:   Wed Aug 9 16:23:13 2023 +0530

    tty: serial: qcom-geni-serial: Poll primary sequencer irq status after cancel_tx
    
    [ Upstream commit 9c8441330bb399cba6177acce9b0e68c0dbaa597 ]
    
    TX is handled by primary sequencer. After cancelling primary command, poll
    primary sequencer's irq status instead of that of secondary.
    While at it, also remove a couple of redundant lines that read from IRQ_EN
    register and write back same.
    
    Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
    Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
    Link: https://lore.kernel.org/r/1691578393-9891-1-git-send-email-quic_vnivarth@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udp: re-score reuseport groups when connected sockets are present [+ + +]
Author: Lorenz Bauer <lmb@isovalent.com>
Date:   Thu Jul 20 17:30:05 2023 +0200

    udp: re-score reuseport groups when connected sockets are present
    
    [ Upstream commit f0ea27e7bfe1c34e1f451a63eb68faa1d4c3a86d ]
    
    Contrary to TCP, UDP reuseport groups can contain TCP_ESTABLISHED
    sockets. To support these properly we remember whether a group has
    a connected socket and skip the fast reuseport early-return. In
    effect we continue scoring all reuseport sockets and then choose the
    one with the highest score.
    
    The current code fails to re-calculate the score for the result of
    lookup_reuseport. According to Kuniyuki Iwashima:
    
        1) SO_INCOMING_CPU is set
           -> selected sk might have +1 score
    
        2) BPF prog returns ESTABLISHED and/or SO_INCOMING_CPU sk
           -> selected sk will have more than 8
    
      Using the old score could trigger more lookups depending on the
      order that sockets are created.
    
        sk -> sk (SO_INCOMING_CPU) -> sk (ESTABLISHED)
        |     |
        `-> select the next SO_INCOMING_CPU sk
              |
              `-> select itself (We should save this lookup)
    
    Fixes: efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Lorenz Bauer <lmb@isovalent.com>
    Link: https://lore.kernel.org/r/20230720-so-reuseport-v6-1-7021b683cdae@isovalent.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
um: Fix hostaudio build errors [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Aug 1 22:15:00 2023 -0700

    um: Fix hostaudio build errors
    
    [ Upstream commit db4bfcba7bb8d10f00bba2a3da6b9a9c2a1d7b71 ]
    
    Use "select" to ensure that the required kconfig symbols are set
    as expected.
    Drop HOSTAUDIO since it is now equivalent to UML_SOUND.
    
    Set CONFIG_SOUND=m in ARCH=um defconfig files to maintain the
    status quo of the default configs.
    
    Allow SOUND with UML regardless of HAS_IOMEM. Otherwise there is a
    kconfig warning for unmet dependencies. (This was not an issue when
    SOUND was defined in arch/um/drivers/Kconfig. I have done 50 randconfig
    builds and didn't find any issues.)
    
    This fixes build errors when CONFIG_SOUND is not set:
    
    ld: arch/um/drivers/hostaudio_kern.o: in function `hostaudio_cleanup_module':
    hostaudio_kern.c:(.exit.text+0xa): undefined reference to `unregister_sound_mixer'
    ld: hostaudio_kern.c:(.exit.text+0x15): undefined reference to `unregister_sound_dsp'
    ld: arch/um/drivers/hostaudio_kern.o: in function `hostaudio_init_module':
    hostaudio_kern.c:(.init.text+0x19): undefined reference to `register_sound_dsp'
    ld: hostaudio_kern.c:(.init.text+0x31): undefined reference to `register_sound_mixer'
    ld: hostaudio_kern.c:(.init.text+0x49): undefined reference to `unregister_sound_dsp'
    
    and this kconfig warning:
    WARNING: unmet direct dependencies detected for SOUND
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Fixes: d886e87cb82b ("sound: make OSS sound core optional")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: lore.kernel.org/r/202307141416.vxuRVpFv-lkp@intel.com
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Cc: linux-um@lists.infradead.org
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Takashi Iwai <tiwai@suse.de>
    Cc: Jaroslav Kysela <perex@perex.cz>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Nicolas Schier <nicolas@fjasle.eu>
    Cc: linux-kbuild@vger.kernel.org
    Cc: alsa-devel@alsa-project.org
    Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

um: virt-pci: fix missing declaration warning [+ + +]
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Wed Aug 23 12:40:44 2023 +0200

    um: virt-pci: fix missing declaration warning
    
    [ Upstream commit 974b808d85abbc03c3914af63d60d5816aabf2ca ]
    
    Fix this warning which appears with W=1 and without CONFIG_OF:
    
     warning: no previous declaration for 'pcibios_get_phb_of_node'
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202308230949.PphIIlhq-lkp@intel.com/
    Fixes: 314a1408b79a ("um: virt-pci: implement pcibios_get_phb_of_node()")
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: core: Change usb_get_device_descriptor() API [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 4 15:12:21 2023 -0400

    USB: core: Change usb_get_device_descriptor() API
    
    commit de28e469da75359a2bb8cd8778b78aa64b1be1f4 upstream.
    
    The usb_get_device_descriptor() routine reads the device descriptor
    from the udev device and stores it directly in udev->descriptor.  This
    interface is error prone, because the USB subsystem expects in-memory
    copies of a device's descriptors to be immutable once the device has
    been initialized.
    
    The interface is changed so that the device descriptor is left in a
    kmalloc-ed buffer, not copied into the usb_device structure.  A
    pointer to the buffer is returned to the caller, who is then
    responsible for kfree-ing it.  The corresponding changes needed in the
    various callers are fairly small.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Fix oversight in SuperSpeed initialization [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 11 13:38:46 2023 -0400

    USB: core: Fix oversight in SuperSpeed initialization
    
    commit 59cf445754566984fd55af19ba7146c76e6627bc upstream.
    
    Commit 85d07c556216 ("USB: core: Unite old scheme and new scheme
    descriptor reads") altered the way USB devices are enumerated
    following detection, and in the process it messed up the
    initialization of SuperSpeed (or faster) devices:
    
    [   31.650759] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
    [   31.663107] usb 2-1: device descriptor read/8, error -71
    [   31.952697] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd
    [   31.965122] usb 2-1: device descriptor read/8, error -71
    [   32.080991] usb usb2-port1: attempt power cycle
    ...
    
    The problem was caused by the commit forgetting that in SuperSpeed or
    faster devices, the device descriptor uses a logarithmic encoding of
    the bMaxPacketSize0 value.  (For some reason I thought the 255 case in
    the switch statement was meant for these devices, but it isn't -- it
    was meant for Wireless USB and is no longer needed.)
    
    We can fix the oversight by testing for buf->bMaxPacketSize0 = 9
    (meaning 512, the actual maxpacket size for ep0 on all SuperSpeed
    devices) and straightening out the logic that checks and adjusts our
    initial guesses of the maxpacket value.
    
    Reported-and-tested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Closes: https://lore.kernel.org/linux-usb/20230810002257.nadxmfmrobkaxgnz@synopsys.com/
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads")
    Link: https://lore.kernel.org/r/8809e6c5-59d5-4d2d-ac8f-6d106658ad73@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 4 15:14:14 2023 -0400

    USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
    
    commit ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b upstream.
    
    Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
    
    BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
    Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
    
    CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
     print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
     print_report mm/kasan/report.c:462 [inline]
     kasan_report+0x11c/0x130 mm/kasan/report.c:572
     read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
    ...
    Allocated by task 758:
    ...
     __do_kmalloc_node mm/slab_common.c:966 [inline]
     __kmalloc+0x5e/0x190 mm/slab_common.c:979
     kmalloc include/linux/slab.h:563 [inline]
     kzalloc include/linux/slab.h:680 [inline]
     usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
     usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
     usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
    
    As analyzed by Khazhy Kumykov, the cause of this bug is a race between
    read_descriptors() and hub_port_init(): The first routine uses a field
    in udev->descriptor, not expecting it to change, while the second
    overwrites it.
    
    Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while
    reading the "descriptors" sysfs file") this race couldn't occur,
    because the routines were mutually exclusive thanks to the device
    locking.  Removing that locking from read_descriptors() exposed it to
    the race.
    
    The best way to fix the bug is to keep hub_port_init() from changing
    udev->descriptor once udev has been initialized and registered.
    Drivers expect the descriptors stored in the kernel to be immutable;
    we should not undermine this expectation.  In fact, this change should
    have been made long ago.
    
    So now hub_port_init() will take an additional argument, specifying a
    buffer in which to store the device descriptor it reads.  (If udev has
    not yet been initialized, the buffer pointer will be NULL and then
    hub_port_init() will store the device descriptor in udev as before.)
    This eliminates the data race responsible for the out-of-bounds read.
    
    The changes to hub_port_init() appear more extensive than they really
    are, because of indentation changes resulting from an attempt to avoid
    writing to other parts of the usb_device structure after it has been
    initialized.  Similar changes should be made to the code that reads
    the BOS descriptor, but that can be handled in a separate patch later
    on.  This patch is sufficient to fix the bug found by syzbot.
    
    Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: Khazhy Kumykov <khazhy@google.com>
    Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Unite old scheme and new scheme descriptor reads [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 4 15:10:59 2023 -0400

    USB: core: Unite old scheme and new scheme descriptor reads
    
    commit 85d07c55621676d47d873d2749b88f783cd4d5a1 upstream.
    
    In preparation for reworking the usb_get_device_descriptor() routine,
    it is desirable to unite the two different code paths responsible for
    initially determining endpoint 0's maximum packet size in a newly
    discovered USB device.  Making this determination presents a
    chicken-and-egg sort of problem, in that the only way to learn the
    maxpacket value is to get it from the device descriptor retrieved from
    the device, but communicating with the device to retrieve a descriptor
    requires us to know beforehand the ep0 maxpacket size.
    
    In practice this problem is solved in two different ways, referred to
    in hub.c as the "old scheme" and the "new scheme".  The old scheme
    (which is the approach recommended by the USB-2 spec) involves asking
    the device to send just the first eight bytes of its device
    descriptor.  Such a transfer uses packets containing no more than
    eight bytes each, and every USB device must have an ep0 maxpacket size
    >= 8, so this should succeed.  Since the bMaxPacketSize0 field of the
    device descriptor lies within the first eight bytes, this is all we
    need.
    
    The new scheme is an imitation of the technique used in an early
    Windows USB implementation, giving it the happy advantage of working
    with a wide variety of devices (some of them at the time would not
    work with the old scheme, although that's probably less true now).  It
    involves making an initial guess of the ep0 maxpacket size, asking the
    device to send up to 64 bytes worth of its device descriptor (which is
    only 18 bytes long), and then resetting the device to clear any error
    condition that might have resulted from the guess being wrong.  The
    initial guess is determined by the connection speed; it should be
    correct in all cases other than full speed, for which the allowed
    values are 8, 16, 32, and 64 (in this case the initial guess is 64).
    
    The reason for this patch is that the old- and new-scheme parts of
    hub_port_init() use different code paths, one involving
    usb_get_device_descriptor() and one not, for their initial reads of
    the device descriptor.  Since these reads have essentially the same
    purpose and are made under essentially the same circumstances, this is
    illogical.  It makes more sense to have both of them use a common
    subroutine.
    
    This subroutine does basically what the new scheme's code did, because
    that approach is more general than the one used by the old scheme.  It
    only needs to know how many bytes to transfer and whether or not it is
    being called for the first iteration of a retry loop (in case of
    certain time-out errors).  There are two main differences from the
    former code:
    
            We initialize the bDescriptorType field of the transfer buffer
            to 0 before performing the transfer, to avoid possibly
            accessing an uninitialized value afterward.
    
            We read the device descriptor into a temporary buffer rather
            than storing it directly into udev->descriptor, which the old
            scheme implementation used to do.
    
    Since the whole point of this first read of the device descriptor is
    to determine the bMaxPacketSize0 value, that is what the new routine
    returns (or an error code).  The value is stored in a local variable
    rather than in udev->descriptor.  As a side effect, this necessitates
    moving a section of code that checks the bcdUSB field for SuperSpeed
    devices until after the full device descriptor has been retrieved.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: gadget: core: Add missing kerneldoc for vbus_work [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 11 13:44:38 2023 -0400

    USB: gadget: core: Add missing kerneldoc for vbus_work
    
    [ Upstream commit 159a98afc88e88f588077afe818081d67f50a5e0 ]
    
    Add a missing kerneldoc description of the vbus_work field in struct usb_udc.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: 50966da807c8 ("usb: gadget: udc: core: Offload usb_udc_vbus_handler processing")
    Link: https://lore.kernel.org/r/1e5e7cda-b2c8-4917-9952-4354f365ede0@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

USB: gadget: f_mass_storage: Fix unused variable warning [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Aug 11 13:47:04 2023 -0400

    USB: gadget: f_mass_storage: Fix unused variable warning
    
    [ Upstream commit 55c3e571d2a0aabef4f1354604443f1c415d2e85 ]
    
    Fix a "variable set but not used" warning in f_mass_storage.c.  rc is
    used if verbose debugging is enabled but not otherwise.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: d5e2b67aae79 ("USB: g_mass_storage: template f_mass_storage.c file created")
    Link: https://lore.kernel.org/r/cfed16c7-aa46-494b-ba84-b0e0dc99be3a@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host() [+ + +]
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Tue Jun 27 19:03:52 2023 +0800

    usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()
    
    [ Upstream commit 5eda42aebb7668b4dcff025cd3ccb0d3d7c53da6 ]
    
    The function mxs_phy_is_otg_host() will return true if OTG_ID_VALUE is
    0 at USBPHY_CTRL register. However, OTG_ID_VALUE will not reflect the real
    state if the ID pin is float, such as Host-only or Type-C cases. The value
    of OTG_ID_VALUE is always 1 which means device mode.
    This patch will fix the issue by judging the current mode based on
    last_event. The controller will update last_event in time.
    
    Fixes: 7b09e67639d6 ("usb: phy: mxs: refine mxs_phy_disconnect_line")
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20230627110353.1879477-2-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: typec: bus: verify partner exists in typec_altmode_attention [+ + +]
Author: RD Babiera <rdbabiera@google.com>
Date:   Mon Aug 14 18:05:59 2023 +0000

    usb: typec: bus: verify partner exists in typec_altmode_attention
    
    commit f23643306430f86e2f413ee2b986e0773e79da31 upstream.
    
    Some usb hubs will negotiate DisplayPort Alt mode with the device
    but will then negotiate a data role swap after entering the alt
    mode. The data role swap causes the device to unregister all alt
    modes, however the usb hub will still send Attention messages
    even after failing to reregister the Alt Mode. type_altmode_attention
    currently does not verify whether or not a device's altmode partner
    exists, which results in a NULL pointer error when dereferencing
    the typec_altmode and typec_altmode_ops belonging to the altmode
    partner.
    
    Verify the presence of a device's altmode partner before sending
    the Attention message to the Alt Mode driver.
    
    Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes")
    Cc: stable@vger.kernel.org
    Signed-off-by: RD Babiera <rdbabiera@google.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20230814180559.923475-1-rdbabiera@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: tcpm: set initial svdm version based on pd revision [+ + +]
Author: RD Babiera <rdbabiera@google.com>
Date:   Mon Jul 31 16:59:23 2023 +0000

    usb: typec: tcpm: set initial svdm version based on pd revision
    
    commit c97cd0b4b54eb42aed7f6c3c295a2d137f6d2416 upstream.
    
    When sending Discover Identity messages to a Port Partner that uses Power
    Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0,
    expecting the port partner to respond with its highest supported SVDM
    version as stated in Section 6.4.4.2.3 in the Power Delivery v3
    specification. However, sending SVDM v2 to some Power Delivery v2 port
    partners results in a NAK whereas sending SVDM v1 does not.
    
    NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1),
    and one solution could be to resend Discover Identity on a lower SVDM
    version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK
    response Should be taken as an indication not to retry that particular
    Command."
    
    Instead, we can set the SVDM version to the maximum one supported by the
    negotiated PD revision. When operating in PD v2, this obeys Section
    6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate
    Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate
    Version 2.0."
    
    Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work")
    Cc: stable@vger.kernel.org
    Signed-off-by: RD Babiera <rdbabiera@google.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20230731165926.1815338-1-rdbabiera@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vdpa/mlx5: Correct default number of queues when MQ is on [+ + +]
Author: Dragos Tatulea <dtatulea@nvidia.com>
Date:   Thu Jul 27 20:23:46 2023 +0300

    vdpa/mlx5: Correct default number of queues when MQ is on
    
    [ Upstream commit 3fe024193340b225d1fd410d78c495434a9d68e0 ]
    
    The standard specifies that the initial number of queues is the
    default, which is 1 (1 tx, 1 rx).
    
    Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
    Reviewed-by: Eugenio Pérez <eperezma@redhat.com>
    Message-Id: <20230727172354.68243-2-dtatulea@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Tested-by: Lei Yang <leiyang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfio/type1: fix cap_migration information leak [+ + +]
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date:   Tue Aug 1 11:53:52 2023 -0400

    vfio/type1: fix cap_migration information leak
    
    [ Upstream commit cd24e2a60af633f157d7e59c0a6dba64f131c0b1 ]
    
    Fix an information leak where an uninitialized hole in struct
    vfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.
    
    The definition of struct vfio_iommu_type1_info_cap_migration contains a hole as
    shown in this pahole(1) output:
    
      struct vfio_iommu_type1_info_cap_migration {
              struct vfio_info_cap_header header;              /*     0     8 */
              __u32                      flags;                /*     8     4 */
    
              /* XXX 4 bytes hole, try to pack */
    
              __u64                      pgsize_bitmap;        /*    16     8 */
              __u64                      max_dirty_bitmap_size; /*    24     8 */
    
              /* size: 32, cachelines: 1, members: 4 */
              /* sum members: 28, holes: 1, sum holes: 4 */
              /* last cacheline: 32 bytes */
      };
    
    The cap_mig variable is filled in without initializing the hole:
    
      static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,
                             struct vfio_info_cap *caps)
      {
          struct vfio_iommu_type1_info_cap_migration cap_mig;
    
          cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION;
          cap_mig.header.version = 1;
    
          cap_mig.flags = 0;
          /* support minimum pgsize */
          cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap);
          cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX;
    
          return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig));
      }
    
    The structure is then copied to a temporary location on the heap. At this point
    it's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspace
    later:
    
      int vfio_info_add_capability(struct vfio_info_cap *caps,
                       struct vfio_info_cap_header *cap, size_t size)
      {
          struct vfio_info_cap_header *header;
    
          header = vfio_info_cap_add(caps, size, cap->id, cap->version);
          if (IS_ERR(header))
              return PTR_ERR(header);
    
          memcpy(header + 1, cap + 1, size - sizeof(*header));
    
          return 0;
      }
    
    This issue was found by code inspection.
    
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Fixes: ad721705d09c ("vfio iommu: Add migration capability to report supported features")
    Link: https://lore.kernel.org/r/20230801155352.1391945-1-stefanha@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfs, security: Fix automount superblock LSM init problem, preventing NFS sb sharing [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Tue Aug 8 07:34:20 2023 -0400

    vfs, security: Fix automount superblock LSM init problem, preventing NFS sb sharing
    
    [ Upstream commit d80a8f1b58c2bc8d7c6bfb65401ea4f7ec8cddc2 ]
    
    When NFS superblocks are created by automounting, their LSM parameters
    aren't set in the fs_context struct prior to sget_fc() being called,
    leading to failure to match existing superblocks.
    
    This bug leads to messages like the following appearing in dmesg when
    fscache is enabled:
    
        NFS: Cache volume key already in use (nfs,4.2,2,108,106a8c0,1,,,,100000,100000,2ee,3a98,1d4c,3a98,1)
    
    Fix this by adding a new LSM hook to load fc->security for submount
    creation.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Link: https://lore.kernel.org/r/165962680944.3334508.6610023900349142034.stgit@warthog.procyon.org.uk/ # v1
    Link: https://lore.kernel.org/r/165962729225.3357250.14350728846471527137.stgit@warthog.procyon.org.uk/ # v2
    Link: https://lore.kernel.org/r/165970659095.2812394.6868894171102318796.stgit@warthog.procyon.org.uk/ # v3
    Link: https://lore.kernel.org/r/166133579016.3678898.6283195019480567275.stgit@warthog.procyon.org.uk/ # v4
    Link: https://lore.kernel.org/r/217595.1662033775@warthog.procyon.org.uk/ # v5
    Fixes: 9bc61ab18b1d ("vfs: Introduce fs_context, switch vfs_kern_mount() to it.")
    Fixes: 779df6a5480f ("NFS: Ensure security label is set for root inode")
    Tested-by: Jeff Layton <jlayton@kernel.org>
    Acked-by: Casey Schaufler <casey@schaufler-ca.com>
    Acked-by: "Christian Brauner (Microsoft)" <brauner@kernel.org>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Message-Id: <20230808-master-v9-1-e0ecde888221@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vhost-scsi: Fix alignment handling with windows [+ + +]
Author: Mike Christie <michael.christie@oracle.com>
Date:   Sun Jul 9 15:28:58 2023 -0500

    vhost-scsi: Fix alignment handling with windows
    
    [ Upstream commit 5ced58bfa132c8ba0f9c893eb621595a84cfee12 ]
    
    The linux block layer requires bios/requests to have lengths with a 512
    byte alignment. Some drivers/layers like dm-crypt and the directi IO code
    will test for it and just fail. Other drivers like SCSI just assume the
    requirement is met and will end up in infinte retry loops. The problem
    for drivers like SCSI is that it uses functions like blk_rq_cur_sectors
    and blk_rq_sectors which divide the request's length by 512. If there's
    lefovers then it just gets dropped. But other code in the block/scsi
    layer may use blk_rq_bytes/blk_rq_cur_bytes and end up thinking there is
    still data left and try to retry the cmd. We can then end up getting
    stuck in retry loops where part of the block/scsi thinks there is data
    left, but other parts think we want to do IOs of zero length.
    
    Linux will always check for alignment, but windows will not. When
    vhost-scsi t