summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-30spi: tegra20-slink: fix reference leak in slink ops of tegra20Zhang Qilong1-0/+2
[ Upstream commit 763eab7074f6e71babd85d796156f05a675f9510 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in two callers(tegra_slink_setup and tegra_slink_resume), so we should fix it. Fixes: dc4dc36056392 ("spi: tegra: add spi driver for SLINK controller") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201103141345.6188-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30spi: spi-ti-qspi: fix reference leak in ti_qspi_setupZhang Qilong1-0/+1
[ Upstream commit 45c0cba753641e5d7c3207f04241bd0e7a021698 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in ti_qspi_setup, so we should fix it. Fixes: 505a14954e2d7 ("spi/qspi: Add qspi flash controller") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201103140947.3815-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30Bluetooth: hci_h5: fix memory leak in h5_closeAnant Thazhemadam1-0/+3
[ Upstream commit 855af2d74c870d747bf53509f8b2d7b9dc9ee2c3 ] When h5_close() is called, h5 is directly freed when !hu->serdev. However, h5->rx_skb is not freed, which causes a memory leak. Freeing h5->rx_skb and setting it to NULL, fixes this memory leak. Fixes: ce945552fde4 ("Bluetooth: hci_h5: Add support for serdev enumerated devices") Reported-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com Tested-by: syzbot+6ce141c55b2f7aafd1c4@syzkaller.appspotmail.com Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30Bluetooth: Fix null pointer dereference in hci_event_packet()Anmol Karn1-0/+5
[ Upstream commit 6dfccd13db2ff2b709ef60a50163925d477549aa ] AMP_MGR is getting derefernced in hci_phy_link_complete_evt(), when called from hci_event_packet() and there is a possibility, that hcon->amp_mgr may not be found when accessing after initialization of hcon. - net/bluetooth/hci_event.c:4945 The bug seems to get triggered in this line: bredr_hcon = hcon->amp_mgr->l2cap_conn->hcon; Fix it by adding a NULL check for the hcon->amp_mgr before checking the ev-status. Fixes: d5e911928bd8 ("Bluetooth: AMP: Process Physical Link Complete evt") Reported-and-tested-by: syzbot+0bef568258653cff272f@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=0bef568258653cff272f Signed-off-by: Anmol Karn <anmol.karan123@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30arm64: dts: exynos: Correct psci compatible used on Exynos7Paweł Chmiel1-1/+3
[ Upstream commit e1e47fbca668507a81bb388fcae044b89d112ecc ] It's not possible to reboot or poweroff Exynos7420 using PSCI. Instead we need to use syscon reboot/poweroff drivers, like it's done for other Exynos SoCs. This was confirmed by checking vendor source and testing it on Samsung Galaxy S6 device based on this SoC. To be able to use custom restart/poweroff handlers instead of PSCI functions, we need to correct psci compatible. This also requires us to provide function ids for CPU_ON and CPU_OFF. Fixes: fb026cb65247 ("arm64: dts: Add reboot node for exynos7") Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7") Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Link: https://lore.kernel.org/r/20201107133926.37187-2-pawel.mikolaj.chmiel@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30arm64: dts: exynos: Include common syscon restart/poweroff for Exynos7Paweł Chmiel1-7/+1
[ Upstream commit 73bc7510ea0dafb4ff1ae6808759627a8ec51f5a ] Exynos7 uses the same syscon reboot and poweroff nodes as other Exynos SoCs, so instead of duplicating code we can just include common dtsi file, which already contains definitions of them. After this change, poweroff node will be also available, previously this dts file did contain only reboot node. Fixes: fb026cb65247 ("arm64: dts: Add reboot node for exynos7") Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7") Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Link: https://lore.kernel.org/r/20201107133926.37187-1-pawel.mikolaj.chmiel@gmail.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30selinux: fix inode_doinit_with_dentry() LABEL_INVALID error handlingPaul Moore1-18/+13
[ Upstream commit 200ea5a2292dc444a818b096ae6a32ba3caa51b9 ] A previous fix, commit 83370b31a915 ("selinux: fix error initialization in inode_doinit_with_dentry()"), changed how failures were handled before a SELinux policy was loaded. Unfortunately that patch was potentially problematic for two reasons: it set the isec->initialized state without holding a lock, and it didn't set the inode's SELinux label to the "default" for the particular filesystem. The later can be a problem if/when a later attempt to revalidate the inode fails and SELinux reverts to the existing inode label. This patch should restore the default inode labeling that existed before the original fix, without affecting the LABEL_INVALID marking such that revalidation will still be attempted in the future. Fixes: 83370b31a915 ("selinux: fix error initialization in inode_doinit_with_dentry()") Reported-by: Sven Schnelle <svens@linux.ibm.com> Tested-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30ASoC: pcm: DRAIN support reactivationCezary Rojewski1-0/+2
[ Upstream commit 4c22b80f61540ea99d9b4af0127315338755f05b ] soc-pcm's dpcm_fe_dai_do_trigger() supported DRAIN commnad up to kernel v5.4 where explicit switch(cmd) has been introduced which takes into account all SNDRV_PCM_TRIGGER_xxx but SNDRV_PCM_TRIGGER_DRAIN. Update switch statement to reactive support for it. As DRAIN is somewhat unique by lacking negative/stop counterpart, bring behaviour of dpcm_fe_dai_do_trigger() for said command back to its pre-v5.4 state by adding it to START/RESUME/PAUSE_RELEASE group. Fixes: acbf27746ecf ("ASoC: pcm: update FE/BE trigger order based on the command") Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20201026100129.8216-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/msm/dsi_pll_10nm: restore VCO rate during restore_stateDmitry Baryshkov1-0/+8
[ Upstream commit a4ccc37693a271330a46208afbeaed939d54fdbb ] PHY disable/enable resets PLL registers to default values. Thus in addition to restoring several registers we also need to restore VCO rate settings. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: c6659785dfb3 ("drm/msm/dsi/pll: call vco set rate explicitly") Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30spi: img-spfi: fix reference leak in img_spfi_resumeZhang Qilong1-1/+3
[ Upstream commit ee5558a9084584015c8754ffd029ce14a5827fa8 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in img_spfi_resume, so we should fix it. Fixes: deba25800a12b ("spi: Add driver for IMG SPFI controller") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102145651.3875-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30powerpc/64: Set up a kernel stack for secondaries before cpu_restore()Jordan Niethe2-6/+6
[ Upstream commit 3c0b976bf20d236c57adcefa80f86a0a1d737727 ] Currently in generic_secondary_smp_init(), cur_cpu_spec->cpu_restore() is called before a stack has been set up in r1. This was previously fine as the cpu_restore() functions were implemented in assembly and did not use a stack. However commit 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features") used __restore_cpu_cpufeatures() as the cpu_restore() function for a device-tree features based cputable entry. This is a C function and hence uses a stack in r1. generic_secondary_smp_init() is entered on the secondary cpus via the primary cpu using the OPAL call opal_start_cpu(). In OPAL, each hardware thread has its own stack. The OPAL call is ran in the primary's hardware thread. During the call, a job is scheduled on a secondary cpu that will start executing at the address of generic_secondary_smp_init(). Hence the value that will be left in r1 when the secondary cpu enters the kernel is part of that secondary cpu's individual OPAL stack. This means that __restore_cpu_cpufeatures() will write to that OPAL stack. This is not horribly bad as each hardware thread has its own stack and the call that enters the kernel from OPAL never returns, but it is still wrong and should be corrected. Create the temp kernel stack before calling cpu_restore(). As noted by mpe, for a kexec boot, the secondary CPUs are released from the spin loop at address 0x60 by smp_release_cpus() and then jump to generic_secondary_smp_init(). The call to smp_release_cpus() is in setup_arch(), and it comes before the call to emergency_stack_init(). emergency_stack_init() allocates an emergency stack in the PACA for each CPU. This address in the PACA is what is used to set up the temp kernel stack in generic_secondary_smp_init(). Move releasing the secondary CPUs to after the PACAs have been allocated an emergency stack, otherwise the PACA stack pointer will contain garbage and hence the temp kernel stack created from it will be broken. Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features") Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201014072837.24539-1-jniethe5@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30crypto: inside-secure - Fix sizeof() mismatchColin Ian King1-1/+1
[ Upstream commit c98e233062cd9d0e2f10e445a671f0799daaef67 ] An incorrect sizeof() is being used, sizeof(priv->ring[i].rdr_req) is not correct, it should be sizeof(*priv->ring[i].rdr_req). Note that since the size of ** is the same size as * this is not causing any issues. Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)") Fixes: 9744fec95f06 ("crypto: inside-secure - remove request list to improve performance") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30crypto: talitos - Fix return type of current_desc_hdr()Christophe Leroy1-3/+3
[ Upstream commit 0237616173fd363a54bd272aa3bd376faa1d7caa ] current_desc_hdr() returns a u32 but in fact this is a __be32, leading to a lot of sparse warnings. Change the return type to __be32 and ensure it is handled as sure by the caller. Fixes: 3e721aeb3df3 ("crypto: talitos - handle descriptor not found in error path") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30crypto: talitos - Endianess in current_desc_hdr()Christophe Leroy1-2/+2
[ Upstream commit 195404db27f9533c71fdcb78d32a77075c2cb4a2 ] current_desc_hdr() compares the value of the current descriptor with the next_desc member of the talitos_desc struct. While the current descriptor is obtained from in_be32() which return CPU ordered bytes, next_desc member is in big endian order. Convert the current descriptor into big endian before comparing it with next_desc. This fixes a sparse warning. Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30sched: Reenable interrupts in do_sched_yield()Thomas Gleixner1-5/+1
[ Upstream commit 345a957fcc95630bf5535d7668a59ed983eb49a7 ] do_sched_yield() invokes schedule() with interrupts disabled which is not allowed. This goes back to the pre git era to commit a6efb709806c ("[PATCH] irqlock patch 2.5.27-H6") in the history tree. Reenable interrupts and remove the misleading comment which "explains" it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/87r1pt7y5c.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30sched/deadline: Fix sched_dl_global_validate()Peng Liu2-26/+21
[ Upstream commit a57415f5d1e43c3a5c5d412cd85e2792d7ed9b11 ] When change sched_rt_{runtime, period}_us, we validate that the new settings should at least accommodate the currently allocated -dl bandwidth: sched_rt_handler() --> sched_dl_bandwidth_validate() { new_bw = global_rt_runtime()/global_rt_period(); for_each_possible_cpu(cpu) { dl_b = dl_bw_of(cpu); if (new_bw < dl_b->total_bw) <------- ret = -EBUSY; } } But under CONFIG_SMP, dl_bw is per root domain , but not per CPU, dl_b->total_bw is the allocated bandwidth of the whole root domain. Instead, we should compare dl_b->total_bw against "cpus*new_bw", where 'cpus' is the number of CPUs of the root domain. Also, below annotation(in kernel/sched/sched.h) implied implementation only appeared in SCHED_DEADLINE v2[1], then deadline scheduler kept evolving till got merged(v9), but the annotation remains unchanged, meaningless and misleading, update it. * With respect to SMP, the bandwidth is given on a per-CPU basis, * meaning that: * - dl_bw (< 100%) is the bandwidth of the system (group) on each CPU; * - dl_total_bw array contains, in the i-eth element, the currently * allocated bandwidth on the i-eth CPU. [1]: https://lore.kernel.org/lkml/1267385230.13676.101.camel@Palantir/ Fixes: 332ac17ef5bf ("sched/deadline: Add bandwidth management for SCHED_DEADLINE tasks") Signed-off-by: Peng Liu <iwtbavbm@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Daniel Bristot de Oliveira <bristot@redhat.com> Acked-by: Juri Lelli <juri.lelli@redhat.com> Link: https://lkml.kernel.org/r/db6bbda316048cda7a1bbc9571defde193a8d67e.1602171061.git.iwtbavbm@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30x86/apic: Fix x2apic enablement without interrupt remappingDavid Woodhouse3-6/+18
[ Upstream commit 26573a97746c7a99f394f9d398ce91a8853b3b89 ] Currently, Linux as a hypervisor guest will enable x2apic only if there are no CPUs present at boot time with an APIC ID above 255. Hotplugging a CPU later with a higher APIC ID would result in a CPU which cannot be targeted by external interrupts. Add a filter in x2apic_apic_id_valid() which can be used to prevent such CPUs from coming online, and allow x2apic to be enabled even if they are present at boot time. Fixes: ce69a784504 ("x86/apic: Enable x2APIC without interrupt remapping under KVM") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201024213535.443185-2-dwmw2@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30ARM: p2v: fix handling of LPAE translation in BE modeArd Biesheuvel1-5/+1
[ Upstream commit 4e79f0211b473f8e1eab8211a9fd50cc41a3a061 ] When running in BE mode on LPAE hardware with a PA-to-VA translation that exceeds 4 GB, we patch bits 39:32 of the offset into the wrong byte of the opcode. So fix that, by rotating the offset in r0 to the right by 8 bits, which will put the 8-bit immediate in bits 31:24. Note that this will also move bit #22 in its correct place when applying the rotation to the constant #0x400000. Fixes: d9a790df8e984 ("ARM: 7883/1: fix mov to mvn conversion in case of 64 bit phys_addr_t and BE") Acked-by: Nicolas Pitre <nico@fluxnic.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30x86/mm/ident_map: Check for errors from ident_pud_init()Arvind Sankar1-2/+10
[ Upstream commit 1fcd009102ee02e217f2e7635ab65517d785da8e ] Commit ea3b5e60ce80 ("x86/mm/ident_map: Add 5-level paging support") added ident_p4d_init() to support 5-level paging, but this function doesn't check and return errors from ident_pud_init(). For example, the decompressor stub uses this code to create an identity mapping. If it runs out of pages while trying to allocate a PMD pagetable, the error will be currently ignored. Fix this to propagate errors. [ bp: Space out statements for better readability. ] Fixes: ea3b5e60ce80 ("x86/mm/ident_map: Add 5-level paging support") Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Joerg Roedel <jroedel@suse.de> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lkml.kernel.org/r/20201027230648.1885111-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30RDMA/rxe: Compute PSN windows correctlyBob Pearson1-1/+2
[ Upstream commit bb3ab2979fd69db23328691cb10067861df89037 ] The code which limited the number of unacknowledged PSNs was incorrect. The PSNs are limited to 24 bits and wrap back to zero from 0x00ffffff. The test was computing a 32 bit value which wraps at 32 bits so that qp->req.psn can appear smaller than the limit when it is actually larger. Replace '>' test with psn_compare which is used for other PSN comparisons and correctly handles the 24 bit size. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20201013170741.3590-1-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearson@hpe.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30ARM: dts: aspeed: s2600wf: Fix VGA memory region locationJoel Stanley1-2/+2
[ Upstream commit 9e1cc9679776f5b9e42481d392b1550753ebd084 ] The VGA memory region is always from the top of RAM. On this board, that is 0x80000000 + 0x20000000 - 0x01000000 = 0x9f000000. This was not an issue in practice as the region is "reserved" by the vendor's u-boot reducing the amount of available RAM, and the only user is the host VGA device poking at RAM over PCIe. That is, nothing from the ARM touches it. It is worth fixing as developers copy existing device trees when building their machines, and the XDMA driver does use the memory region from the ARM side. Fixes: c4043ecac34a ("ARM: dts: aspeed: Add S2600WF BMC Machine") Reported-by: John Wang <wangzhiqiang.bj@bytedance.com> Link: https://lore.kernel.org/r/20200922064234.163799-1-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30selinux: fix error initialization in inode_doinit_with_dentry()Tianyue Ren1-3/+16
[ Upstream commit 83370b31a915493231e5b9addc72e4bef69f8d31 ] Mark the inode security label as invalid if we cannot find a dentry so that we will retry later rather than marking it initialized with the unlabeled SID. Fixes: 9287aed2ad1f ("selinux: Convert isec->lock into a spinlock") Signed-off-by: Tianyue Ren <rentianyue@kylinos.cn> [PM: minor comment tweaks] Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30RDMA/bnxt_re: Set queue pair state when being queriedKamal Heib1-0/+1
[ Upstream commit 53839b51a7671eeb3fb44d479d541cf3a0f2dd45 ] The API for ib_query_qp requires the driver to set cur_qp_state on return, add the missing set. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/20201021114952.38876-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Acked-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30soc: qcom: geni: More properly switch to DMA modeDouglas Anderson1-2/+15
[ Upstream commit 4b6ea87be44ef34732846fc71e44c41125f0c4fa ] On geni-i2c transfers using DMA, it was seen that if you program the command (I2C_READ) before calling geni_se_rx_dma_prep() that it could cause interrupts to fire. If we get unlucky, these interrupts can just keep firing (and not be handled) blocking further progress and hanging the system. In commit 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race") we avoided that by making sure we didn't program the command until after geni_se_rx_dma_prep() was called. While that avoided the problems, it also turns out to be invalid. At least in the TX case we started seeing sporadic corrupted transfers. This is easily seen by adding an msleep() between the DMA prep and the writing of the command, which makes the problem worse. That means we need to revert that commit and find another way to fix the bogus IRQs. Specifically, after reverting commit 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race"), I put some traces in. I found that the when the interrupts were firing like crazy: - "m_stat" had bits for M_RX_IRQ_EN, M_RX_FIFO_WATERMARK_EN set. - "dma" was set. Further debugging showed that I could make the problem happen more reliably by adding an "msleep(1)" any time after geni_se_setup_m_cmd() ran up until geni_se_rx_dma_prep() programmed the length. A rather simple fix is to change geni_se_select_dma_mode() so it's a true inverse of geni_se_select_fifo_mode() and disables all the FIFO related interrupts. Now the problematic interrupts can't fire and we can program things in the correct order without worrying. As part of this, let's also change the writel_relaxed() in the prepare function to a writel() so that our DMA is guaranteed to be prepared now that we can't rely on geni_se_setup_m_cmd()'s writel(). NOTE: the only current user of GENI_SE_DMA in mainline is i2c. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Fixes: 02b9aec59243 ("i2c: i2c-qcom-geni: Fix DMA transfer race") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201013142448.v2.1.Ifdb1b69fa3367b81118e16e9e4e63299980ca798@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30soc: mediatek: Check if power domains can be powered on at boot timeNicolas Boichat1-2/+3
[ Upstream commit 4007844b05815717f522c7ea9914e24ad0ff6c79 ] In the error case, where a power domain cannot be powered on successfully at boot time (in mtk_register_power_domains), pm_genpd_init would still be called with is_off=false, and the system would later try to disable the power domain again, triggering warnings as disabled clocks are disabled again (and other potential issues). Also print a warning splat in that case, as this should never happen. Fixes: c84e358718a66f7 ("soc: Mediatek: Add SCPSYS power domain driver") Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Link: https://lore.kernel.org/r/20200928113107.v2.1.I5e6f8c262031d0451fe7241b744f4f3111c1ce71@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30soc: renesas: rmobile-sysc: Fix some leaks in rmobile_init_pm_domains()Dan Carpenter1-0/+1
[ Upstream commit cf25d802e029c31efac8bdc979236927f37183bd ] This code needs to call iounmap() on one error path. Fixes: 2173fc7cb681 ("ARM: shmobile: R-Mobile: Add DT support for PM domains") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200923113142.GC1473821@mwanda Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/tve200: Fix handling of platform_get_irq() errorKrzysztof Kozlowski1-2/+2
[ Upstream commit 77bb5aaf2bb8180e7d1bb70b4df306f511707a7d ] platform_get_irq() returns -ERRNO on error. In such case comparison to 0 would pass the check. Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200827071107.27429-2-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/gma500: fix double free of gma_connectorTom Rix1-1/+1
[ Upstream commit 4e19d51ca5b28a1d435a844c7b2a8e1b1b6fa237 ] clang static analysis reports this problem: cdv_intel_dp.c:2101:2: warning: Attempt to free released memory kfree(gma_connector); ^~~~~~~~~~~~~~~~~~~~ In cdv_intel_dp_init() when the call to cdv_intel_edp_panel_vdd_off() fails, the handler calls cdv_intel_dp_destroy(connector) which does the first free of gma_connector. So adjust the goto label and skip the second free. Fixes: d112a8163f83 ("gma500/cdv: Add eDP support") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201003193928.18869-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30perf cs-etm: Move definition of 'traceid_list' global variable from header fileLeo Yan2-3/+3
commit 168200b6d6ea0cb5765943ec5da5b8149701f36a upstream. The variable 'traceid_list' is defined in the header file cs-etm.h, if multiple C files include cs-etm.h the compiler might complaint for multiple definition of 'traceid_list'. To fix multiple definition error, move the definition of 'traceid_list' into cs-etm.c. Fixes: cd8bfd8c973e ("perf tools: Add processing of coresight metadata") Reported-by: Thomas Backlund <tmb@mageia.org> Signed-off-by: Leo Yan <leo.yan@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Mike Leach <mike.leach@linaro.org> Tested-by: Mike Leach <mike.leach@linaro.org> Tested-by: Thomas Backlund <tmb@mageia.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Cc: Tor Jeremiassen <tor@ti.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lore.kernel.org/lkml/20200505133642.4756-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30perf cs-etm: Change tuple from traceID-CPU# to traceID-metadataLeo Yan3-12/+31
commit 95c6fe970a0160cb770c5dce9f80311b42d030c0 upstream. If packet processing wants to know the packet is bound with which ETM version, it needs to access metadata to decide that based on metadata magic number; but we cannot simply to use CPU logic ID number as index to access metadata sequential array, especially when system have hotplugged off CPUs, the metadata array are only allocated for online CPUs but not offline CPUs, so the CPU logic number doesn't match with its index in the array. This patch is to change tuple from traceID-CPU# to traceID-metadata, thus it can use the tuple to retrieve metadata pointer according to traceID. For safe accessing metadata fields, this patch provides helper function cs_etm__get_cpu() which is used to return CPU number according to traceID; cs_etm_decoder__buffer_packet() is the first consumer for this helper function. Signed-off-by: Leo Yan <leo.yan@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Leach <mike.leach@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Robert Walker <robert.walker@arm.com> Cc: Suzuki K Poulouse <suzuki.poulose@arm.com> Cc: coresight ml <coresight@lists.linaro.org> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20190129122842.32041-6-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> [Salvatore Bonaccorso: Adjust for context changes in tools/perf/util/cs-etm-decoder/cs-etm-decoder.c] Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30md: fix a warning caused by a race between concurrent md_ioctl()sDae R. Jeong1-2/+5
commit c731b84b51bf7fe83448bea8f56a6d55006b0615 upstream. Syzkaller reports a warning as belows. WARNING: CPU: 0 PID: 9647 at drivers/md/md.c:7169 ... Call Trace: ... RIP: 0010:md_ioctl+0x4017/0x5980 drivers/md/md.c:7169 RSP: 0018:ffff888096027950 EFLAGS: 00010293 RAX: ffff88809322c380 RBX: 0000000000000932 RCX: ffffffff84e266f2 RDX: 0000000000000000 RSI: ffffffff84e299f7 RDI: 0000000000000007 RBP: ffff888096027bc0 R08: ffff88809322c380 R09: ffffed101341a482 R10: ffff888096027940 R11: ffff88809a0d240f R12: 0000000000000932 R13: ffff8880a2c14100 R14: ffff88809a0d2268 R15: ffff88809a0d2408 __blkdev_driver_ioctl block/ioctl.c:304 [inline] blkdev_ioctl+0xece/0x1c10 block/ioctl.c:606 block_ioctl+0xee/0x130 fs/block_dev.c:1930 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe This is caused by a race between two concurrenct md_ioctl()s closing the array. CPU1 (md_ioctl()) CPU2 (md_ioctl()) ------ ------ set_bit(MD_CLOSING, &mddev->flags); did_set_md_closing = true; WARN_ON_ONCE(test_bit(MD_CLOSING, &mddev->flags)); if(did_set_md_closing) clear_bit(MD_CLOSING, &mddev->flags); Fix the warning by returning immediately if the MD_CLOSING bit is set in &mddev->flags which indicates that the array is being closed. Fixes: 065e519e71b2 ("md: MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop") Reported-by: syzbot+1e46a0864c1a6e9bd3d8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Dae R. Jeong <dae.r.jeong@kaist.ac.kr> Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30crypto: af_alg - avoid undefined behavior accessing salg_nameEric Biggers2-3/+23
commit 92eb6c3060ebe3adf381fd9899451c5b047bb14d upstream. Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") made the kernel start accepting arbitrarily long algorithm names in sockaddr_alg. However, the actual length of the salg_name field stayed at the original 64 bytes. This is broken because the kernel can access indices >= 64 in salg_name, which is undefined behavior -- even though the memory that is accessed is still located within the sockaddr structure. It would only be defined behavior if the array were properly marked as arbitrary-length (either by making it a flexible array, which is the recommended way these days, or by making it an array of length 0 or 1). We can't simply change salg_name into a flexible array, since that would break source compatibility with userspace programs that embed sockaddr_alg into another struct, or (more commonly) declare a sockaddr_alg like 'struct sockaddr_alg sa = { .salg_name = "foo" };'. One solution would be to change salg_name into a flexible array only when '#ifdef __KERNEL__'. However, that would keep userspace without an easy way to actually use the longer algorithm names. Instead, add a new structure 'sockaddr_alg_new' that has the flexible array field, and expose it to both userspace and the kernel. Make the kernel use it correctly in alg_bind(). This addresses the syzbot report "UBSAN: array-index-out-of-bounds in alg_bind" (https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e). Reported-by: syzbot+92ead4eb8e26a26d465e@syzkaller.appspotmail.com Fixes: 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30media: msi2500: assign SPI bus number dynamicallyAntti Palosaari1-1/+1
commit 9c60cc797cf72e95bb39f32316e9f0e5f85435f9 upstream. SPI bus number must be assigned dynamically for each device, otherwise it will crash when multiple devices are plugged to system. Reported-and-tested-by: syzbot+c60ddb60b685777d9d59@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30quota: Sanity-check quota file headers on loadJan Kara1-0/+19
commit 11c514a99bb960941535134f0587102855e8ddee upstream. Perform basic sanity checks of quota headers to avoid kernel crashes on corrupted quota files. CC: stable@vger.kernel.org Reported-by: syzbot+f816042a7ae2225f25ba@syzkaller.appspotmail.com Reviewed-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30Bluetooth: Fix slab-out-of-bounds read in hci_le_direct_adv_report_evt()Peilin Ye1-7/+5
commit f7e0e8b2f1b0a09b527885babda3e912ba820798 upstream. `num_reports` is not being properly checked. A malformed event packet with a large `num_reports` number makes hci_le_direct_adv_report_evt() read out of bounds. Fix it. Cc: stable@vger.kernel.org Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct Advertising Report events") Reported-and-tested-by: syzbot+24ebd650e20bd263ca01@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01 Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30serial_core: Check for port state when tty is in error stateAlexey Kardashevskiy1-0/+4
commit 2f70e49ed860020f5abae4f7015018ebc10e1f0e upstream. At the moment opening a serial device node (such as /dev/ttyS3) succeeds even if there is no actual serial device behind it. Reading/writing/ioctls fail as expected because the uart port is not initialized (the type is PORT_UNKNOWN) and the TTY_IO_ERROR error state bit is set fot the tty. However setting line discipline does not have these checks 8250_port.c (8250 is the default choice made by univ8250_console_init()). As the result of PORT_UNKNOWN, uart_port::iobase is NULL which a platform translates onto some address accessing which produces a crash like below. This adds tty_port_initialized() to uart_set_ldisc() to prevent the crash. Found by syzkaller. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Link: https://lore.kernel.org/r/20201203055834.45838-1-aik@ozlabs.ru Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30HID: i2c-hid: add Vero K147 to descriptor overrideJulian Sax1-0/+8
commit c870d50ce387d84b6438211a7044c60afbd5d60a upstream. This device uses the SIPODEV SP1064 touchpad, which does not supply descriptors, so it has to be added to the override list. Cc: stable@vger.kernel.org Signed-off-by: Julian Sax <jsbc@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30scsi: megaraid_sas: Check user-provided offsetsArnd Bergmann1-5/+11
commit 381d34e376e3d9d27730fda8a0e870600e6c8196 upstream. It sounds unwise to let user space pass an unchecked 32-bit offset into a kernel structure in an ioctl. This is an unsigned variable, so checking the upper bound for the size of the structure it points into is sufficient to avoid data corruption, but as the pointer might also be unaligned, it has to be written carefully as well. While I stumbled over this problem by reading the code, I did not continue checking the function for further problems like it. Link: https://lore.kernel.org/r/20201030164450.1253641-2-arnd@kernel.org Fixes: c4a3e0a529ab ("[SCSI] MegaRAID SAS RAID: new driver") Cc: <stable@vger.kernel.org> # v2.6.15+ Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30coresight: tmc-etr: Check if page is valid before dma_map_page()Mao Jinlong1-0/+2
commit 1cc573d5754e92372a7e30e35468644f8811e1a4 upstream. alloc_pages_node() return should be checked before calling dma_map_page() to make sure that valid page is mapped or else it can lead to aborts as below: Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: <snip>... pc : __dma_inv_area+0x40/0x58 lr : dma_direct_map_page+0xd8/0x1c8 Call trace: __dma_inv_area tmc_pages_alloc tmc_alloc_data_pages tmc_alloc_sg_table tmc_init_etr_sg_table tmc_alloc_etr_buf tmc_enable_etr_sink_sysfs tmc_enable_etr_sink coresight_enable_path coresight_enable enable_source_store dev_attr_store sysfs_kf_write Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Cc: stable@vger.kernel.org Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mao Jinlong <jinlmao@codeaurora.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201127175256.1092685-13-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30ARM: dts: exynos: fix USB 3.0 pins supply being turned off on Odroid XUKrzysztof Kozlowski1-0/+2
commit bd7e7ff56feea7810df900fb09c9741d259861d9 upstream. On Odroid XU LDO12 and LDO15 supplies the power to USB 3.0 blocks but the GPK GPIO pins are supplied by LDO7 (VDDQ_LCD). LDO7 also supplies GPJ GPIO pins. The Exynos pinctrl driver does not take any supplies, so to have entire GPIO block always available, make the regulator always on. Fixes: 88644b4c750b ("ARM: dts: exynos: Configure PWM, usb3503, PMIC and thermal on Odroid XU board") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201015182044.480562-3-krzk@kernel.org Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30ARM: dts: exynos: fix USB 3.0 VBUS control and over-current pins on Exynos5410Krzysztof Kozlowski2-0/+32
commit 3d992fd8f4e0f09c980726308d2f2725587b32d6 upstream. The VBUS control (PWREN) and over-current pins of USB 3.0 DWC3 controllers are on Exynos5410 regular GPIOs. This is different than for example on Exynos5422 where these are special ETC pins with proper reset values (pulls, functions). Therefore these pins should be configured to enable proper USB 3.0 peripheral and host modes. This also fixes over-current warning: [ 6.024658] usb usb4-port1: over-current condition [ 6.028271] usb usb3-port1: over-current condition Fixes: cb0896562228 ("ARM: dts: exynos: Add USB to Exynos5410") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201015182044.480562-2-krzk@kernel.org Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30ARM: dts: exynos: fix roles of USB 3.0 ports on Odroid XUKrzysztof Kozlowski1-2/+2
commit ecc1ff532b499d20304a4f682247137025814c34 upstream. On Odroid XU board the USB3-0 port is a microUSB and USB3-1 port is USB type A (host). The roles were copied from Odroid XU3 (Exynos5422) design which has it reversed. Fixes: 8149afe4dbf9 ("ARM: dts: exynos: Add initial support for Odroid XU board") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201015182044.480562-1-krzk@kernel.org Tested-by: Gabriel Ribba Esteva <gabriel.ribbae@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to imx6ulFabio Estevam1-1/+2
commit c7721e15f434920145c376e8fe77e1c079fc3726 upstream. According to the i.MX6UL Errata document: https://www.nxp.com/docs/en/errata/IMX6ULCE.pdf ERR007881 also affects i.MX6UL, so pass the CI_HDRC_DISABLE_DEVICE_STREAMING flag to workaround the issue. Fixes: 52fe568e5d71 ("usb: chipidea: imx: add imx6ul usb support") Cc: <stable@vger.kernel.org> Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20201207020909.22483-2-peter.chen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30USB: gadget: f_rndis: fix bitrate for SuperSpeed and aboveWill McVicker1-1/+3
commit b00f444f9add39b64d1943fa75538a1ebd54a290 upstream. Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate defined by commit 1650113888fe ("usb: gadget: f_ncm: add SuperSpeed descriptors for CDC NCM"). Cc: Felipe Balbi <balbi@kernel.org> Cc: EJ Hsu <ejh@nvidia.com> Cc: Peter Chen <peter.chen@nxp.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20201127140559.381351-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30usb: gadget: f_fs: Re-use SS descriptors for SuperSpeedPlusJack Pham1-1/+4
commit a353397b0d5dfa3c99b372505db3378fc919c6c6 upstream. In many cases a function that supports SuperSpeed can very well operate in SuperSpeedPlus, if a gadget controller supports it, as the endpoint descriptors (and companion descriptors) are generally identical and can be re-used. This is true for two commonly used functions: Android's ADB and MTP. So we can simply assign the usb_function's ssp_descriptors array to point to its ss_descriptors, if available. Similarly, we need to allow an epfile's ioctl for FUNCTIONFS_ENDPOINT_DESC to correctly return the corresponding SuperSpeed endpoint descriptor in case the connected speed is SuperSpeedPlus as well. The only exception is if a function wants to implement an Isochronous endpoint capable of transferring more than 48KB per service interval when operating at greater than USB 3.1 Gen1 speed, in which case it would require an additional SuperSpeedPlus Isochronous Endpo