commit 36d0e96f6d9c9a7745c33cd9ff964e12367b417e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 21 15:38:59 2023 +0200

    Linux 4.14.319
    
    Link: https://lore.kernel.org/r/20230619102127.461443957@linuxfoundation.org
    Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be24f8aae42e7a4ecf6efd3278acacb5bb82e5a8
Author: Christian Loehle <CLoehle@hyperstone.com>
Date:   Wed Apr 26 16:59:39 2023 +0000

    mmc: block: ensure error propagation for non-blk
    
    commit 003fb0a51162d940f25fc35e70b0996a12c9e08a upstream.
    
    Requests to the mmc layer usually come through a block device IO.
    The exceptions are the ioctl interface, RPMB chardev ioctl
    and debugfs, which issue their own blk_mq requests through
    blk_execute_rq and do not query the BLK_STS error but the
    mmcblk-internal drv_op_result. This patch ensures that drv_op_result
    defaults to an error and has to be overwritten by the operation
    to be considered successful.
    
    The behavior leads to a bug where the request never propagates
    the error, e.g. by directly erroring out at mmc_blk_mq_issue_rq if
    mmc_blk_part_switch fails. The ioctl caller of the rpmb chardev then
    can never see an error (BLK_STS_IOERR, but drv_op_result is unchanged)
    and thus may assume that their call executed successfully when it did not.
    
    While always checking the blk_execute_rq return value would be
    advised, let's eliminate the error by always setting
    drv_op_result as -EIO to be overwritten on success (or other error)
    
    Fixes: 614f0388f580 ("mmc: block: move single ioctl() commands to block requests")
    Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/59c17ada35664b818b7bd83752119b2d@hyperstone.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4c9414821d5bc8b787b88058e1f865e34dc893b
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Feb 7 16:16:52 2019 +1100

    powerpc: Fix defconfig choice logic when cross compiling
    
    commit af5cd05de5dd38cf25d14ea4d30ae9b791d2420b upstream.
    
    Our logic for choosing defconfig doesn't work well in some situations.
    
    For example if you're on a ppc64le machine but you specify a non-empty
    CROSS_COMPILE, in order to use a non-default toolchain, then defconfig
    will give you ppc64_defconfig (big endian):
    
      $ make CROSS_COMPILE=~/toolchains/gcc-8/bin/powerpc-linux- defconfig
      *** Default configuration is based on 'ppc64_defconfig'
    
    This is because we assume that CROSS_COMPILE being set means we
    can't be on a ppc machine and rather than checking we just default to
    ppc64_defconfig.
    
    We should just ignore CROSS_COMPILE, instead check the machine with
    uname and if it's one of ppc, ppc64 or ppc64le then use that
    defconfig. If it's none of those then we fall back to ppc64_defconfig.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Alyssa Ross <hi@alyssa.is>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f63e0e61fbcc9fb5cd0a87c1a1af74cc3d4965f3
Author: Leon Romanovsky <leon@kernel.org>
Date:   Wed Mar 8 11:23:13 2023 +0200

    neighbour: delete neigh_lookup_nodev as not used
    
    commit 76b9bf965c98c9b53ef7420b3b11438dbd764f92 upstream.
    
    neigh_lookup_nodev isn't used in the kernel after removal
    of DECnet. So let's remove it.
    
    Fixes: 1202cdd66531 ("Remove DECnet support from kernel")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/eb5656200d7964b2d177a36b77efa3c597d6d72d.1678267343.git.leonro@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8456d7c6041be024db3455ecf4057dd561096252
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Thu Sep 22 16:38:55 2022 +0800

    neighbour: Remove unused inline function neigh_key_eq16()
    
    commit c8f01a4a54473f88f8cc0d9046ec9eb5a99815d5 upstream.
    
    All uses of neigh_key_eq16() have
    been removed since commit 1202cdd66531 ("Remove DECnet support
    from kernel"), so remove it.
    
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c80247ab6efa2c09ec3ae1b404ebbcd0e2c94e60
Author: Alex Maftei <alex.maftei@amd.com>
Date:   Thu Jun 15 09:34:04 2023 +0100

    selftests/ptp: Fix timestamp printf format for PTP_SYS_OFFSET
    
    [ Upstream commit 76a4c8b82938bc5020b67663db41f451684bf327 ]
    
    Previously, timestamps were printed using "%lld.%u" which is incorrect
    for nanosecond values lower than 100,000,000 as they're fractional
    digits, therefore leading zeros are meaningful.
    
    This patch changes the format strings to "%lld.%09u" in order to add
    leading zeros to the nanosecond value.
    
    Fixes: 568ebc5985f5 ("ptp: add the PTP_SYS_OFFSET ioctl to the testptp program")
    Fixes: 4ec54f95736f ("ptp: Fix compiler warnings in the testptp utility")
    Fixes: 6ab0e475f1f3 ("Documentation: fix misc. warnings")
    Signed-off-by: Alex Maftei <alex.maftei@amd.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Link: https://lore.kernel.org/r/20230615083404.57112-1-alex.maftei@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4859df57243ab7b9a8a27c9f1da50056dde5ec2
Author: Lin Ma <linma@zju.edu.cn>
Date:   Wed Jun 14 20:06:04 2023 +0800

    net: tipc: resize nlattr array to correct size
    
    [ Upstream commit 44194cb1b6045dea33ae9a0d54fb7e7cd93a2e09 ]
    
    According to nla_parse_nested_deprecated(), the tb[] is supposed to the
    destination array with maxtype+1 elements. In current
    tipc_nl_media_get() and __tipc_nl_media_set(), a larger array is used
    which is unnecessary. This patch resize them to a proper size.
    
    Fixes: 1e55417d8fc6 ("tipc: add media set to new netlink api")
    Fixes: 46f15c6794fb ("tipc: add media get/dump to new netlink api")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Reviewed-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Link: https://lore.kernel.org/r/20230614120604.1196377-1-linma@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d374a8e90e4b66f99457a1a66ac023fe69f7f85b
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 14 16:18:02 2023 +0000

    net: lapbether: only support ethernet devices
    
    [ Upstream commit 9eed321cde22fc1afd76eac563ce19d899e0d6b2 ]
    
    It probbaly makes no sense to support arbitrary network devices
    for lapbether.
    
    syzbot reported:
    
    skbuff: skb_under_panic: text:ffff80008934c100 len:44 put:40 head:ffff0000d18dd200 data:ffff0000d18dd1ea tail:0x16 end:0x140 dev:bond1
    kernel BUG at net/core/skbuff.c:200 !
    Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 5643 Comm: dhcpcd Not tainted 6.4.0-rc5-syzkaller-g4641cff8e810 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : skb_panic net/core/skbuff.c:196 [inline]
    pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:210
    lr : skb_panic net/core/skbuff.c:196 [inline]
    lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:210
    sp : ffff8000973b7260
    x29: ffff8000973b7270 x28: ffff8000973b7360 x27: dfff800000000000
    x26: ffff0000d85d8150 x25: 0000000000000016 x24: ffff0000d18dd1ea
    x23: ffff0000d18dd200 x22: 000000000000002c x21: 0000000000000140
    x20: 0000000000000028 x19: ffff80008934c100 x18: ffff8000973b68a0
    x17: 0000000000000000 x16: ffff80008a43bfbc x15: 0000000000000202
    x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
    x11: 0000000000000201 x10: 0000000000000000 x9 : f22f7eb937cced00
    x8 : f22f7eb937cced00 x7 : 0000000000000001 x6 : 0000000000000001
    x5 : ffff8000973b6b78 x4 : ffff80008df9ee80 x3 : ffff8000805974f4
    x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086
    Call trace:
    skb_panic net/core/skbuff.c:196 [inline]
    skb_under_panic+0x13c/0x140 net/core/skbuff.c:210
    skb_push+0xf0/0x108 net/core/skbuff.c:2409
    ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1383
    dev_hard_header include/linux/netdevice.h:3137 [inline]
    lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257
    lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447
    lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149
    lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251
    lapb_establish_data_link+0x94/0xec
    lapb_device_event+0x348/0x4e0
    notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93
    raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461
    __dev_notify_flags+0x2bc/0x544
    dev_change_flags+0xd0/0x15c net/core/dev.c:8643
    devinet_ioctl+0x858/0x17e4 net/ipv4/devinet.c:1150
    inet_ioctl+0x2ac/0x4d8 net/ipv4/af_inet.c:979
    sock_do_ioctl+0x134/0x2dc net/socket.c:1201
    sock_ioctl+0x4ec/0x858 net/socket.c:1318
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:870 [inline]
    __se_sys_ioctl fs/ioctl.c:856 [inline]
    __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:856
    __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
    invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
    el0_svc_common+0x138/0x244 arch/arm64/kernel/syscall.c:142
    do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:191
    el0_svc+0x4c/0x160 arch/arm64/kernel/entry-common.c:647
    el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:665
    el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
    Code: aa1803e6 aa1903e7 a90023f5 947730f5 (d4210000)
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Martin Schiller <ms@dev.tdt.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 791cf4a8d8005ba1c9525c349d8eeae861145630
Author: Natalia Petrova <n.petrova@fintech.ru>
Date:   Fri May 12 14:15:26 2023 +0300

    drm/nouveau/dp: check for NULL nv_connector->native_mode
    
    [ Upstream commit 20a2ce87fbaf81e4c3dcb631d738e423959eb320 ]
    
    Add checking for NULL before calling nouveau_connector_detect_depth() in
    nouveau_connector_get_modes() function because nv_connector->native_mode
    could be dereferenced there since connector pointer passed to
    nouveau_connector_detect_depth() and the same value of
    nv_connector->native_mode is used there.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: d4c2c99bdc83 ("drm/nouveau/dp: remove broken display depth function, use the improved one")
    
    Signed-off-by: Natalia Petrova <n.petrova@fintech.ru>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230512111526.82408-1-n.petrova@fintech.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 860634f1680c33e1a851d8d122f2e3fed008c452
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Tue Apr 25 17:44:14 2023 +0200

    igb: fix nvm.ops.read() error handling
    
    [ Upstream commit 48a821fd58837800750ec1b3962f0f799630a844 ]
    
    Add error handling into igb_set_eeprom() function, in case
    nvm.ops.read() fails just quit with error code asap.
    
    Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver")
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56687d263345a0a0474dc9c8613befd3298afddc
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Jun 9 14:05:19 2023 +0300

    sctp: fix an error code in sctp_sf_eat_auth()
    
    [ Upstream commit 75e6def3b26736e7ff80639810098c9074229737 ]
    
    The sctp_sf_eat_auth() function is supposed to enum sctp_disposition
    values and returning a kernel error code will cause issues in the
    caller.  Change -ENOMEM to SCTP_DISPOSITION_NOMEM.
    
    Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccf5a1b28e2b73952e8d23126fa1abc6ff99de55
Author: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
Date:   Tue Jun 6 03:25:31 2023 -0700

    IB/isert: Fix incorrect release of isert connection
    
    [ Upstream commit 699826f4e30ab76a62c238c86fbef7e826639c8d ]
    
    The ib_isert module is releasing the isert connection both in
    isert_wait_conn() handler as well as isert_free_conn() handler.
    In isert_wait_conn() handler, it is expected to wait for iSCSI
    session logout operation to complete. It should free the isert
    connection only in isert_free_conn() handler.
    
    When a bunch of iSER target is cleared, this issue can lead to
    use-after-free memory issue as isert conn is twice released
    
    Fixes: b02efbfc9a05 ("iser-target: Fix implicit termination of connections")
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/20230606102531.162967-4-saravanan.vajravel@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f40a2503dc5692bb6917151bae578280772a531
Author: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
Date:   Tue Jun 6 03:25:30 2023 -0700

    IB/isert: Fix possible list corruption in CMA handler
    
    [ Upstream commit 7651e2d6c5b359a28c2d4c904fec6608d1021ca8 ]
    
    When ib_isert module receives connection error event, it is
    releasing the isert session and removes corresponding list
    node but it doesn't take appropriate mutex lock to remove
    the list node.  This can lead to linked  list corruption
    
    Fixes: bd3792205aae ("iser-target: Fix pending connections handling in target stack shutdown sequnce")
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
    Link: https://lore.kernel.org/r/20230606102531.162967-3-saravanan.vajravel@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13e29c379bc9d9aa47a3bfc8e8209719c3e9b7b6
Author: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
Date:   Tue Jun 6 03:25:29 2023 -0700

    IB/isert: Fix dead lock in ib_isert
    
    [ Upstream commit 691b0480933f0ce88a81ed1d1a0aff340ff6293a ]
    
    - When a iSER session is released, ib_isert module is taking a mutex
      lock and releasing all pending connections. As part of this, ib_isert
      is destroying rdma cm_id. To destroy cm_id, rdma_cm module is sending
      CM events to CMA handler of ib_isert. This handler is taking same
      mutex lock. Hence it leads to deadlock between ib_isert & rdma_cm
      modules.
    
    - For fix, created local list of pending connections and release the
      connection outside of mutex lock.
    
    Calltrace:
    ---------
    [ 1229.791410] INFO: task kworker/10:1:642 blocked for more than 120 seconds.
    [ 1229.791416]       Tainted: G           OE    --------- -  - 4.18.0-372.9.1.el8.x86_64 #1
    [ 1229.791418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1229.791419] task:kworker/10:1    state:D stack:    0 pid:  642 ppid:     2 flags:0x80004000
    [ 1229.791424] Workqueue: ib_cm cm_work_handler [ib_cm]
    [ 1229.791436] Call Trace:
    [ 1229.791438]  __schedule+0x2d1/0x830
    [ 1229.791445]  ? select_idle_sibling+0x23/0x6f0
    [ 1229.791449]  schedule+0x35/0xa0
    [ 1229.791451]  schedule_preempt_disabled+0xa/0x10
    [ 1229.791453]  __mutex_lock.isra.7+0x310/0x420
    [ 1229.791456]  ? select_task_rq_fair+0x351/0x990
    [ 1229.791459]  isert_cma_handler+0x224/0x330 [ib_isert]
    [ 1229.791463]  ? ttwu_queue_wakelist+0x159/0x170
    [ 1229.791466]  cma_cm_event_handler+0x25/0xd0 [rdma_cm]
    [ 1229.791474]  cma_ib_handler+0xa7/0x2e0 [rdma_cm]
    [ 1229.791478]  cm_process_work+0x22/0xf0 [ib_cm]
    [ 1229.791483]  cm_work_handler+0xf4/0xf30 [ib_cm]
    [ 1229.791487]  ? move_linked_works+0x6e/0xa0
    [ 1229.791490]  process_one_work+0x1a7/0x360
    [ 1229.791491]  ? create_worker+0x1a0/0x1a0
    [ 1229.791493]  worker_thread+0x30/0x390
    [ 1229.791494]  ? create_worker+0x1a0/0x1a0
    [ 1229.791495]  kthread+0x10a/0x120
    [ 1229.791497]  ? set_kthread_struct+0x40/0x40
    [ 1229.791499]  ret_from_fork+0x1f/0x40
    
    [ 1229.791739] INFO: task targetcli:28666 blocked for more than 120 seconds.
    [ 1229.791740]       Tainted: G           OE    --------- -  - 4.18.0-372.9.1.el8.x86_64 #1
    [ 1229.791741] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1229.791742] task:targetcli       state:D stack:    0 pid:28666 ppid:  5510 flags:0x00004080
    [ 1229.791743] Call Trace:
    [ 1229.791744]  __schedule+0x2d1/0x830
    [ 1229.791746]  schedule+0x35/0xa0
    [ 1229.791748]  schedule_preempt_disabled+0xa/0x10
    [ 1229.791749]  __mutex_lock.isra.7+0x310/0x420
    [ 1229.791751]  rdma_destroy_id+0x15/0x20 [rdma_cm]
    [ 1229.791755]  isert_connect_release+0x115/0x130 [ib_isert]
    [ 1229.791757]  isert_free_np+0x87/0x140 [ib_isert]
    [ 1229.791761]  iscsit_del_np+0x74/0x120 [iscsi_target_mod]
    [ 1229.791776]  lio_target_np_driver_store+0xe9/0x140 [iscsi_target_mod]
    [ 1229.791784]  configfs_write_file+0xb2/0x110
    [ 1229.791788]  vfs_write+0xa5/0x1a0
    [ 1229.791792]  ksys_write+0x4f/0xb0
    [ 1229.791794]  do_syscall_64+0x5b/0x1a0
    [ 1229.791798]  entry_SYSCALL_64_after_hwframe+0x65/0xca
    
    Fixes: bd3792205aae ("iser-target: Fix pending connections handling in target stack shutdown sequnce")
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
    Link: https://lore.kernel.org/r/20230606102531.162967-2-saravanan.vajravel@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 230dcd1df83885b4723e307e8c4d46dc124fee13
Author: Guillaume Nault <gnault@redhat.com>
Date:   Wed Jun 7 18:05:02 2023 +0200

    ping6: Fix send to link-local addresses with VRF.
    
    [ Upstream commit 91ffd1bae1dafbb9e34b46813f5b058581d9144d ]
    
    Ping sockets can't send packets when they're bound to a VRF master
    device and the output interface is set to a slave device.
    
    For example, when net.ipv4.ping_group_range is properly set, so that
    ping6 can use ping sockets, the following kind of commands fails:
      $ ip vrf exec red ping6 fe80::854:e7ff:fe88:4bf1%eth1
    
    What happens is that sk->sk_bound_dev_if is set to the VRF master
    device, but 'oif' is set to the real output device. Since both are set
    but different, ping_v6_sendmsg() sees their value as inconsistent and
    fails.
    
    Fix this by allowing 'oif' to be a slave device of ->sk_bound_dev_if.
    
    This fixes the following kselftest failure:
      $ ./fcnal-test.sh -t ipv6_ping
      [...]
      TEST: ping out, vrf device+address bind - ns-B IPv6 LLA        [FAIL]
    
    Reported-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
    Closes: https://lore.kernel.org/netdev/b6191f90-ffca-dbca-7d06-88a9788def9c@alu.unizg.hr/
    Tested-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
    Fixes: 5e457896986e ("net: ipv6: Fix ping to link-local addresses.")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/6c8b53108816a8d0d5705ae37bdc5a8322b5e3d9.1686153846.git.gnault@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit edeab0e105b05f5cae244e018d2b6cd5d2d57baf
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jun 8 00:19:12 2023 +0200

    netfilter: nfnetlink: skip error delivery on batch in case of ENOMEM
    
    [ Upstream commit a1a64a151dae8ac3581c1cbde44b672045cb658b ]
    
    If caller reports ENOMEM, then stop iterating over the batch and send a
    single netlink message to userspace to report OOM.
    
    Fixes: cbb8125eb40b ("netfilter: nfnetlink: deliver netlink errors on batch completion")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58befcf7da6c81a1692bbdee146b29678f278255
Author: Jerry Meng <jerry-meng@foxmail.com>
Date:   Wed May 31 11:51:16 2023 +0800

    USB: serial: option: add Quectel EM061KGL series
    
    commit f1832e2b5e498e258b090af3b065b85cf8cc5161 upstream.
    
    Add support for Quectel EM061KGL series which are based on Qualcomm
    SDX12 chip:
    
    EM061KGL_LTA(0x2c7c / 0x0123): MBIM + GNSS + DIAG + NMEA + AT + QDSS + DPL
    EM061KGL_LMS(0x2c7c / 0x0124): MBIM + GNSS + DIAG + NMEA + AT + QDSS + DPL
    EM061KGL_LWW(0x2c7c / 0x6008): MBIM + GNSS + DIAG + NMEA + AT + QDSS + DPL
    EM061KGL_LCN(0x2c7c / 0x6009): MBIM + GNSS + DIAG + NMEA + AT + QDSS + DPL
    
    Above products use the exact same interface layout and
    option driver is for interfaces DIAG, NMEA and AT.
    
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  5 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=6008 Rev= 5.04
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM061K-GL
    S:  SerialNumber=f6fa08b6
    C:* #Ifs= 8 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 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=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 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=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=8f(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Jerry Meng <jerry-meng@foxmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 975840f8dec3c1e6a6b28a387bb7cf55a4775e18
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Wed Aug 17 17:43:21 2022 -0700

    Remove DECnet support from kernel
    
    commit 1202cdd665315c525b5237e96e0bedc76d7e754f upstream.
    
    DECnet is an obsolete network protocol that receives more attention
    from kernel janitors than users. It belongs in computer protocol
    history museum not in Linux kernel.
    
    It has been "Orphaned" in kernel since 2010. The iproute2 support
    for DECnet was dropped in 5.0 release. The documentation link on
    Sourceforge says it is abandoned there as well.
    
    Leave the UAPI alone to keep userspace programs compiling.
    This means that there is still an empty neighbour table
    for AF_DECNET.
    
    The table of /proc/sys/net entries was updated to match
    current directories and reformatted to be alphabetical.
    
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: David Ahern <dsahern@kernel.org>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a664de3ee85f4646c688a17679ce3ce8bc78e40
Author: Wes Huang <wes.huang@moxa.com>
Date:   Thu Jun 8 11:01:42 2023 +0800

    net: usb: qmi_wwan: add support for Compal RXM-G1
    
    commit 863199199713908afaa47ba09332b87621c12496 upstream.
    
    Add support for Compal RXM-G1 which is based on Qualcomm SDX55 chip.
    This patch adds support for two compositions:
    
    0x9091: DIAG + MODEM + QMI_RMNET + ADB
    0x90db: DIAG + DUN + RMNET + DPL + QDSS(Trace) + ADB
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=05c6 ProdID=9091 Rev= 4.14
    S:  Manufacturer=QCOM
    S:  Product=SDXPRAIRIE-MTP _SN:719AB680
    S:  SerialNumber=719ab680
    C:* #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=84(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=05c6 ProdID=90db Rev= 4.14
    S:  Manufacturer=QCOM
    S:  Product=SDXPRAIRIE-MTP _SN:719AB680
    S:  SerialNumber=719ab680
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=84(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=8f(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wes Huang <wes.huang@moxa.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Link: https://lore.kernel.org/r/20230608030141.3546-1-wes.huang@moxa.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19dea83889dcd2ad6c3af084d1ae740226beaa0c
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed May 24 18:43:48 2023 +0900

    nilfs2: fix possible out-of-bounds segment allocation in resize ioctl
    
    commit fee5eaecca86afa544355569b831c1f90f334b85 upstream.
    
    Syzbot reports that in its stress test for resize ioctl, the log writing
    function nilfs_segctor_do_construct hits a WARN_ON in
    nilfs_segctor_truncate_segments().
    
    It turned out that there is a problem with the current implementation of
    the resize ioctl, which changes the writable range on the device (the
    range of allocatable segments) at the end of the resize process.
    
    This order is necessary for file system expansion to avoid corrupting the
    superblock at trailing edge.  However, in the case of a file system
    shrink, if log writes occur after truncating out-of-bounds trailing
    segments and before the resize is complete, segments may be allocated from
    the truncated space.
    
    The userspace resize tool was fine as it limits the range of allocatable
    segments before performing the resize, but it can run into this issue if
    the resize ioctl is called alone.
    
    Fix this issue by changing nilfs_sufile_resize() to update the range of
    allocatable segments immediately after successful truncation of segment
    space in case of file system shrink.
    
    Link: https://lkml.kernel.org/r/20230524094348.3784-1-konishi.ryusuke@gmail.com
    Fixes: 4e33f9eab07e ("nilfs2: implement resize ioctl")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+33494cd0df2ec2931851@syzkaller.appspotmail.com
    Closes: https://lkml.kernel.org/r/0000000000005434c405fbbafdc5@google.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@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>

commit ca91ab4bc38f7e1cd4ea178fccebcd40803e99b8
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sat May 13 19:24:28 2023 +0900

    nilfs2: fix incomplete buffer cleanup in nilfs_btnode_abort_change_key()
    
    commit 2f012f2baca140c488e43d27a374029c1e59098d upstream.
    
    A syzbot fault injection test reported that nilfs_btnode_create_block, a
    helper function that allocates a new node block for b-trees, causes a
    kernel BUG for disk images where the file system block size is smaller
    than the page size.
    
    This was due to unexpected flags on the newly allocated buffer head, and
    it turned out to be because the buffer flags were not cleared by
    nilfs_btnode_abort_change_key() after an error occurred during a b-tree
    update operation and the buffer was later reused in that state.
    
    Fix this issue by using nilfs_btnode_delete() to abandon the unused
    preallocated buffer in nilfs_btnode_abort_change_key().
    
    Link: https://lkml.kernel.org/r/20230513102428.10223-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+b0a35a5c1f7e846d3b09@syzkaller.appspotmail.com
    Closes: https://lkml.kernel.org/r/000000000000d1d6c205ebc4d512@google.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@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>

commit 74f27d32c82dda4829315c60adf8c7754d6602ce
Author: Janne Grunau <j@jannau.net>
Date:   Sun Feb 12 13:16:32 2023 +0100

    nios2: dts: Fix tse_mac "max-frame-size" property
    
    commit 85041e12418fd0c08ff972b7729f7971afb361f8 upstream.
    
    The given value of 1518 seems to refer to the layer 2 ethernet frame
    size without 802.1Q tag. Actual use of the "max-frame-size" including in
    the consumer of the "altr,tse-1.0" compatible is the MTU.
    
    Fixes: 95acd4c7b69c ("nios2: Device tree support")
    Fixes: 61c610ec61bb ("nios2: Add Max10 device tree")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Janne Grunau <j@jannau.net>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa8dfc7aa7bd9d4e227a97615b535292713d9db5
Author: Luís Henriques <ocfs2-devel@oss.oracle.com>
Date:   Mon May 29 16:26:45 2023 +0100

    ocfs2: check new file size on fallocate call
    
    commit 26a6ffff7de5dd369cdb12e38ba11db682f1dec0 upstream.
    
    When changing a file size with fallocate() the new size isn't being
    checked.  In particular, the FSIZE ulimit isn't being checked, which makes
    fstest generic/228 fail.  Simply adding a call to inode_newsize_ok() fixes
    this issue.
    
    Link: https://lkml.kernel.org/r/20230529152645.32680-1-lhenriques@suse.de
    Signed-off-by: Luís Henriques <lhenriques@suse.de>
    Reviewed-by: Mark Fasheh <mark@fasheh.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    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>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b88ccb9333723353d9f6c15f85088ac7f8ac57c
Author: Luís Henriques <ocfs2-devel@oss.oracle.com>
Date:   Mon May 22 11:21:12 2023 +0100

    ocfs2: fix use-after-free when unmounting read-only filesystem
    
    commit 50d927880e0f90d5cb25e897e9d03e5edacc79a8 upstream.
    
    It's trivial to trigger a use-after-free bug in the ocfs2 quotas code using
    fstest generic/452.  After a read-only remount, quotas are suspended and
    ocfs2_mem_dqinfo is freed through ->ocfs2_local_free_info().  When unmounting
    the filesystem, an UAF access to the oinfo will eventually cause a crash.
    
    BUG: KASAN: slab-use-after-free in timer_delete+0x54/0xc0
    Read of size 8 at addr ffff8880389a8208 by task umount/669
    ...
    Call Trace:
     <TASK>
     ...
     timer_delete+0x54/0xc0
     try_to_grab_pending+0x31/0x230
     __cancel_work_timer+0x6c/0x270
     ocfs2_disable_quotas.isra.0+0x3e/0xf0 [ocfs2]
     ocfs2_dismount_volume+0xdd/0x450 [ocfs2]
     generic_shutdown_super+0xaa/0x280
     kill_block_super+0x46/0x70
     deactivate_locked_super+0x4d/0xb0
     cleanup_mnt+0x135/0x1f0
     ...
     </TASK>
    
    Allocated by task 632:
     kasan_save_stack+0x1c/0x40
     kasan_set_track+0x21/0x30
     __kasan_kmalloc+0x8b/0x90
     ocfs2_local_read_info+0xe3/0x9a0 [ocfs2]
     dquot_load_quota_sb+0x34b/0x680
     dquot_load_quota_inode+0xfe/0x1a0
     ocfs2_enable_quotas+0x190/0x2f0 [ocfs2]
     ocfs2_fill_super+0x14ef/0x2120 [ocfs2]
     mount_bdev+0x1be/0x200
     legacy_get_tree+0x6c/0xb0
     vfs_get_tree+0x3e/0x110
     path_mount+0xa90/0xe10
     __x64_sys_mount+0x16f/0x1a0
     do_syscall_64+0x43/0x90
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    Freed by task 650:
     kasan_save_stack+0x1c/0x40
     kasan_set_track+0x21/0x30
     kasan_save_free_info+0x2a/0x50
     __kasan_slab_free+0xf9/0x150
     __kmem_cache_free+0x89/0x180
     ocfs2_local_free_info+0x2ba/0x3f0 [ocfs2]
     dquot_disable+0x35f/0xa70
     ocfs2_susp_quotas.isra.0+0x159/0x1a0 [ocfs2]
     ocfs2_remount+0x150/0x580 [ocfs2]
     reconfigure_super+0x1a5/0x3a0
     path_mount+0xc8a/0xe10
     __x64_sys_mount+0x16f/0x1a0
     do_syscall_64+0x43/0x90
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    Link: https://lkml.kernel.org/r/20230522102112.9031-1-lhenriques@suse.de
    Signed-off-by: Luís Henriques <lhenriques@suse.de>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Tested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    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>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ba0925b48205e06c913db2da46d5abbda0b2bbb
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Wed Apr 26 17:40:05 2023 +0100

    xen/blkfront: Only check REQ_FUA for writes
    
    [ Upstream commit b6ebaa8100090092aa602530d7e8316816d0c98d ]
    
    The existing code silently converts read operations with the
    REQ_FUA bit set into write-barrier operations. This results in data
    loss as the backend scribbles zeroes over the data instead of returning
    it.
    
    While the REQ_FUA bit doesn't make sense on a read operation, at least
    one well-known out-of-tree kernel module does set it and since it
    results in data loss, let's be safe here and only look at REQ_FUA for
    writes.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Acked-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20230426164005.2213139-1-ross.lagerwall@citrix.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a592589a30e8565d22b754e88dd86429eced2c1
Author: Liviu Dudau <liviu@dudau.co.uk>
Date:   Tue May 9 18:29:21 2023 +0100

    mips: Move initrd_start check after initrd address sanitisation.
    
    [ Upstream commit 4897a898a216058dec55e5e5902534e6e224fcdf ]
    
    PAGE_OFFSET is technically a virtual address so when checking the value of
    initrd_start against it we should make sure that it has been sanitised from
    the values passed by the bootloader. Without this change, even with a bootloader
    that passes correct addresses for an initrd, we are failing to load it on MT7621
    boards, for example.
    
    Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 10130470bb0003b784f4656cc3ef2b9dc396ebdd
Author: Manuel Lauss <manuel.lauss@gmail.com>
Date:   Thu May 11 17:30:10 2023 +0200

    MIPS: Alchemy: fix dbdma2
    
    [ Upstream commit 2d645604f69f3a772d58ead702f9a8e84ab2b342 ]
    
    Various fixes for the Au1200/Au1550/Au1300 DBDMA2 code:
    
    - skip cache invalidation if chip has working coherency circuitry.
    - invalidate KSEG0-portion of the (physical) data address.
    - force the dma channel doorbell write out to bus immediately with
      a sync.
    
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c313ba1565837de9ca96b8abf8a12b4e8d65ed0d
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Tue May 16 13:25:40 2023 -0500

    power: supply: Fix logic checking if system is running from battery
    
    [ Upstream commit 95339f40a8b652b5b1773def31e63fc53c26378a ]
    
    The logic used for power_supply_is_system_supplied() counts all power
    supplies and assumes that the system is running from AC if there is
    either a non-battery power-supply reporting to be online or if no
    power-supplies exist at all.
    
    The second rule is for desktop systems, that don't have any
    battery/charger devices. These systems will incorrectly report to be
    powered from battery once a device scope power-supply is registered
    (e.g. a HID device), since these power-supplies increase the counter.
    
    Apart from HID devices, recent dGPUs provide UCSI power supplies on a
    desktop systems. The dGPU by default doesn't have anything plugged in so
    it's 'offline'. This makes power_supply_is_system_supplied() return 0
    with a count of 1 meaning all drivers that use this get a wrong judgement.
    
    To fix this case adjust the logic to also examine the scope of the power
    supply. If the power supply is deemed a device power supply, then don't
    count it.
    
    Cc: Evan Quan <Evan.Quan@amd.com>
    Suggested-by: Lijo Lazar <Lijo.Lazar@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f864cf21105c797560695f9fd8882d0b2d4e63c
Author: Osama Muhammad <osmtendev@gmail.com>
Date:   Mon May 15 22:29:38 2023 +0500

    regulator: Fix error checking for debugfs_create_dir
    
    [ Upstream commit 2bf1c45be3b8f3a3f898d0756c1282f09719debd ]
    
    This patch fixes the error checking in core.c in debugfs_create_dir.
    The correct way to check if an error occurred is 'IS_ERR' inline function.
    
    Signed-off-by: Osama Muhammad <osmtendev@gmail.com
    Suggested-by: Ivan Orlov <ivan.orlov0322@gmail.com
    Link: https://lore.kernel.org/r/20230515172938.13338-1-osmtendev@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 248d9213cf78a23d73bd8c5a6c3cc34b3b487c31
Author: Marek Vasut <marex@denx.de>
Date:   Sun Mar 5 21:52:26 2023 +0100

    power: supply: Ratelimit no data debug output
    
    [ Upstream commit 155c45a25679f571c2ae57d10db843a9dfc63430 ]
    
    Reduce the amount of output this dev_dbg() statement emits into logs,
    otherwise if system software polls the sysfs entry for data and keeps
    getting -ENODATA, it could end up filling the logs up.
    
    This does in fact make systemd journald choke, since during boot the
    sysfs power supply entries are polled and if journald starts at the
    same time, the journal is just being repeatedly filled up, and the
    system stops on trying to start journald without booting any further.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15d914ed11ceead3e3829dd0108304107d0f5cc7
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Apr 23 17:08:37 2023 +0200

    ARM: dts: vexpress: add missing cache properties
    
    [ Upstream commit 328acc5657c6197753238d7ce0a6924ead829347 ]
    
    As all level 2 and level 3 caches are unified, add required
    cache-unified property to fix warnings like:
    
      vexpress-v2p-ca5s.dtb: cache-controller@2c0f0000: 'cache-unified' is a required property
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230423150837.118466-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 249c30ba447c08e383b533d33941b6bf91963d74
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 15 20:23:39 2023 +0200

    power: supply: bq27xxx: Use mod_delayed_work() instead of cancel() + schedule()
    
    [ Upstream commit 59dddea9879713423c7b2ade43c423bb71e0d216 ]
    
    Use mod_delayed_work() instead of separate cancel_delayed_work_sync() +
    schedule_delayed_work() calls.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05f7d8238bd86932b3c71d7b0b62b150130e787c
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 15 18:07:29 2023 +0200

    power: supply: ab8500: Fix external_power_changed race
    
    [ Upstream commit a5299ce4e96f3e8930e9c051b28d8093ada87b08 ]
    
    ab8500_btemp_external_power_changed() dereferences di->btemp_psy,
    which gets sets in ab8500_btemp_probe() like this:
    
            di->btemp_psy = devm_power_supply_register(dev, &ab8500_btemp_desc,
                                                       &psy_cfg);
    
    As soon as devm_power_supply_register() has called device_add()
    the external_power_changed callback can get called. So there is a window
    where ab8500_btemp_external_power_changed() may get called while
    di->btemp_psy has not been set yet leading to a NULL pointer dereference.
    
    Fixing this is easy. The external_power_changed callback gets passed
    the power_supply which will eventually get stored in di->btemp_psy,
    so ab8500_btemp_external_power_changed() can simply directly use
    the passed in psy argument which is always valid.
    
    And the same applies to ab8500_fg_external_power_changed().
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>