aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-sqlite.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2022-09-25serial: Deassert Transmit Enable on probe in driver-specific wayLukas Wunner7-42/+37
When a UART port is newly registered, uart_configure_port() seeks to deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl. However a number of UART drivers interpret a set RTS bit as *assertion* instead of deassertion: Affected drivers include those using serial8250_em485_config() (except 8250_bcm2835aux.c) and some using mctrl_gpio (e.g. imx.c). Since the interpretation of the RTS bit is driver-specific, it is not suitable as a means to centrally deassert Transmit Enable in the serial core. Instead, the serial core must call on drivers to deassert it in their driver-specific way. One way to achieve that is to call ->rs485_config(). It implicitly deasserts Transmit Enable. So amend uart_configure_port() and uart_resume_port() to invoke uart_rs485_config(). That allows removing calls to uart_rs485_config() from drivers' ->probe() hooks and declaring the function static. Skip any invocation of ->set_mctrl() if RS485 is enabled. RS485 has no hardware flow control, so the modem control lines are irrelevant and need not be touched. When leaving RS485 mode, reset the modem control lines to the state stored in port->mctrl. That way, UARTs which are muxed between RS485 and RS232 transceivers drive the lines correctly when switched to RS232. (serial8250_do_startup() historically raises the OUT1 modem signal because otherwise interrupts are not signaled on ancient PC UARTs, but I believe that no longer applies to modern, RS485-capable UARTs and is thus safe to be skipped.) imx.c modifies port->mctrl whenever Transmit Enable is asserted and deasserted. Stop it from doing that so port->mctrl reflects the RS232 line state. 8250_omap.c deasserts Transmit Enable on ->runtime_resume() by calling ->set_mctrl(). Because that is now a no-op in RS485 mode, amend the function to call serial8250_em485_stop_tx(). fsl_lpuart.c retrieves and applies the RS485 device tree properties after registering the UART port. Because applying now happens on registration in uart_configure_port(), move retrieval of the properties ahead of uart_add_one_port(). Link: https://lore.kernel.org/all/20220329085050.311408-1-matthias.schiffer@ew.tq-group.com/ Link: https://lore.kernel.org/all/8f538a8903795f22f9acc94a9a31b03c9c4ccacb.camel@ginzinger.com/ Fixes: d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart open") Cc: stable@vger.kernel.org # v4.14+ Reported-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reported-by: Roosen Henri <Henri.Roosen@ginzinger.com> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-25serial: 8250_dma: Convert to use uart_xmit_advance()Andy Shevchenko1-3/+1
uart_xmit_advance() provides a common way on how to advance the Tx queue. Use it for the sake of unification and robustness. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220909091102.58941-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-25serial: 8250_omap: Convert to use uart_xmit_advance()Andy Shevchenko1-3/+1
uart_xmit_advance() provides a common way on how to advance the Tx queue. Use it for the sake of unification and robustness. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220909091258.68886-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-24MAINTAINERS: Solve warning regarding inexistent atmel-usart bindingSergiu Moga1-3/+3
After the conversion to json-schema, what was previously known as `Documentation/devicetree/bindings/mfd/atmel-usart.txt` has been moved to another bindings directory and renamed to `Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml`. Thus, make `MAINTAINERS` reflect this change. Fixes: b9e947fbf008 ("dt-bindings: serial: atmel,at91-usart: convert to json-schema") Reported-by: kernel test robot <lkp@intel.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Link: https://lore.kernel.org/r/20220923113415.90236-1-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23io_uring: ensure that cached task references are always put on exitJens Axboe1-0/+3
io_uring caches task references to avoid doing atomics for each of them per request. If a request is put from the same task that allocated it, then we can maintain a per-ctx cache of them. This obviously relies on io_uring always pruning caches in a reliable way, and there's currently a case off io_uring fd release where we can miss that. One example is a ring setup with IOPOLL, which relies on the task polling for completions, which will free them. However, if such a task submits a request and then exits or closes the ring without reaping the completion, then ring release will reap and put. If release happens from that very same task, the completed request task refs will get put back into the cache pool. This is problematic, as we're now beyond the point of pruning caches. Manually drop these caches after doing an IOPOLL reap. This releases references from the current task, which is enough. If another task happens to be doing the release, then the caching will not be triggered and there's no issue. Cc: stable@vger.kernel.org Fixes: e98e49b2bbf7 ("io_uring: extend task put optimisations") Reported-by: Homin Rhee <hominlab@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-23cgroup: cgroup_get_from_id() must check the looked-up kn is a directoryMing Lei1-1/+4
cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace. Reported-by: Marco Patalano <mpatalan@redhat.com> Fixes: 6b658c4863c1 ("scsi: cgroup: Add cgroup_get_from_id()") Cc: Muneendra <muneendra.kumar@broadcom.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Acked-by: Mukesh Ojha <quic_mojha@quicinc.com> Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Tejun Heo <tj@kernel.org>
2022-09-23vmlinux.lds.h: CFI: Reduce alignment of jump-table to function alignmentWill Deacon1-2/+1
Due to undocumented, hysterical raisins on x86, the CFI jump-table sections in .text are needlessly aligned to PMD_SIZE in the vmlinux linker script. When compiling a CFI-enabled arm64 kernel with a 64KiB page-size, a PMD maps 512MiB of virtual memory and so the .text section increases to a whopping 940MiB and blows the final Image up to 960MiB. Others report a link failure. Since the CFI jump-table requires only instruction alignment, reduce the alignment directives to function alignment for parity with other parts of the .text section. This reduces the size of the .text section for the aforementioned 64KiB page size arm64 kernel to 19MiB for a much more reasonable total Image size of 39MiB. Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: "Mohan Rao .vanimina" <mailtoc.mohanrao@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/all/CAL_GTzigiNOMYkOPX1KDnagPhJtFNqSK=1USNbS0wUL4PW6-Uw@mail.gmail.com/ Fixes: cf68fffb66d6 ("add support for Clang CFI") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220922215715.13345-1-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2022-09-23MAINTAINERS: switch graphics to airlied other addressesDave Airlie1-3/+4
My linux.ie address is in a bad place. also add dri-devel for agpgart. Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-09-22KVM: x86: Inject #UD on emulated XSETBV if XSAVES isn't enabledSean Christopherson2-0/+4
Inject #UD when emulating XSETBV if CR4.OSXSAVE is not set. This also covers the "XSAVE not supported" check, as setting CR4.OSXSAVE=1 #GPs if XSAVE is not supported (and userspace gets to keep the pieces if it forces incoherent vCPU state). Add a comment to kvm_emulate_xsetbv() to call out that the CPU checks CR4.OSXSAVE before checking for intercepts. AMD'S APM implies that #UD has priority (says that intercepts are checked before #GP exceptions), while Intel's SDM says nothing about interception priority. However, testing on hardware shows that both AMD and Intel CPUs prioritize the #UD over interception. Fixes: 02d4160fbd76 ("x86: KVM: add xsetbv to the emulator") Cc: stable@vger.kernel.org Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220824033057.3576315-4-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-22KVM: x86: Always enable legacy FP/SSE in allowed user XFEATURESDr. David Alan Gilbert1-1/+7
Allow FP and SSE state to be saved and restored via KVM_{G,SET}_XSAVE on XSAVE-capable hosts even if their bits are not exposed to the guest via XCR0. Failing to allow FP+SSE first showed up as a QEMU live migration failure, where migrating a VM from a pre-XSAVE host, e.g. Nehalem, to an XSAVE host failed due to KVM rejecting KVM_SET_XSAVE. However, the bug also causes problems even when migrating between XSAVE-capable hosts as KVM_GET_SAVE won't set any bits in user_xfeatures if XSAVE isn't exposed to the guest, i.e. KVM will fail to actually migrate FP+SSE. Because KVM_{G,S}ET_XSAVE are designed to allowing migrating between hosts with and without XSAVE, KVM_GET_XSAVE on a non-XSAVE (by way of fpu_copy_guest_fpstate_to_uabi()) always sets the FP+SSE bits in the header so that KVM_SET_XSAVE will work even if the new host supports XSAVE. Fixes: ad856280ddea ("x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0") bz: https://bugzilla.redhat.com/show_bug.cgi?id=2079311 Cc: stable@vger.kernel.org Cc: Leonardo Bras <leobras@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> [sean: add comment, massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220824033057.3576315-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-22KVM: x86: Reinstate kvm_vcpu_arch.guest_supported_xcr0Sean Christopherson3-10/+5
Reinstate the per-vCPU guest_supported_xcr0 by partially reverting commit 988896bb6182; the implicit assessment that guest_supported_xcr0 is always the same as guest_fpu.fpstate->user_xfeatures was incorrect. kvm_vcpu_after_set_cpuid() isn't the only place that sets user_xfeatures, as user_xfeatures is set to fpu_user_cfg.default_features when guest_fpu is allocated via fpu_alloc_guest_fpstate() => __fpstate_reset(). guest_supported_xcr0 on the other hand is zero-allocated. If userspace never invokes KVM_SET_CPUID2, supported XCR0 will be '0', whereas the allowed user XFEATURES will be non-zero. Practically speaking, the edge case likely doesn't matter as no sane userspace will live migrate a VM without ever doing KVM_SET_CPUID2. The primary motivation is to prepare for KVM intentionally and explicitly setting bits in user_xfeatures that are not set in guest_supported_xcr0. Because KVM_{G,S}ET_XSAVE can be used to svae/restore FP+SSE state even if the host doesn't support XSAVE, KVM needs to set the FP+SSE bits in user_xfeatures even if they're not allowed in XCR0, e.g. because XCR0 isn't exposed to the guest. At that point, the simplest fix is to track the two things separately (allowed save/restore vs. allowed XCR0). Fixes: 988896bb6182 ("x86/kvm/fpu: Remove kvm_vcpu_arch.guest_supported_xcr0") Cc: stable@vger.kernel.org Cc: Leonardo Bras <leobras@redhat.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220824033057.3576315-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-22KVM: x86/mmu: add missing update to max_mmu_rmap_sizeMiaohe Lin1-0/+2
The update to statistic max_mmu_rmap_size is unintentionally removed by commit 4293ddb788c1 ("KVM: x86/mmu: Remove redundant spte present check in mmu_set_spte"). Add missing update to it or max_mmu_rmap_size will always be nonsensical 0. Fixes: 4293ddb788c1 ("KVM: x86/mmu: Remove redundant spte present check in mmu_set_spte") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Message-Id: <20220907080657.42898-1-linmiaohe@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-22selftests: kvm: Fix a compile error in selftests/kvm/rseq_test.cJinrong Liang1-1/+1
The following warning appears when executing: make -C tools/testing/selftests/kvm rseq_test.c: In function ‘main’: rseq_test.c:237:33: warning: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Wimplicit-function-declaration] (void *)(unsigned long)gettid()); ^~~~~~ getgid /usr/bin/ld: /tmp/ccr5mMko.o: in function `main': ../kvm/tools/testing/selftests/kvm/rseq_test.c:237: undefined reference to `gettid' collect2: error: ld returned 1 exit status make: *** [../lib.mk:173: ../kvm/tools/testing/selftests/kvm/rseq_test] Error 1 Use the more compatible syscall(SYS_gettid) instead of gettid() to fix it. More subsequent reuse may cause it to be wrapped in a lib file. Signed-off-by: Jinrong Liang <cloudliang@tencent.com> Message-Id: <20220802071240.84626-1-cloudliang@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-22mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.Maurizio Lombardi1-1/+8
Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") moved all flush_cpu_slab() invocations to the global workqueue to avoid a problem related with deactivate_slab()/__free_slab() being called from an IRQ context on PREEMPT_RT kernels. When the flush_all_cpu_locked() function is called from a task context it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core] Fix this bug by creating a workqueue for the flush operation with the WQ_MEM_RECLAIM bit set. Fixes: 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") Cc: <stable@vger.kernel.org> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2022-09-22serial: stm32: Deassert Transmit Enable on ->rs485_config()Lukas Wunner1-47/+53
The STM32 USART can control RS-485 Transmit Enable in hardware. Since commit 7df5081cbf5e ("serial: stm32: Add RS485 RTS GPIO control"), it can alternatively be controlled in software. That was done to allow RS-485 even if the RTS pin is unavailable because it's pinmuxed to a different function. However the commit neglected to deassert Transmit Enable upon invocation of the ->rs485_config() callback. Fix it. Avoid forward declarations by moving stm32_usart_tx_empty(), stm32_usart_rs485_rts_enable() and stm32_usart_rs485_rts_disable() further up in the driver. Fixes: 7df5081cbf5e ("serial: stm32: Add RS485 RTS GPIO control") Cc: stable@vger.kernel.org # v5.9+ Cc: Marek Vasut <marex@denx.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/6059eab35dba394468335ef640df8b0050fd9dbd.1662886616.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: ar933x: Deassert Transmit Enable on ->rs485_config()Lukas Wunner1-0/+7
The ar933x_uart driver neglects to deassert Transmit Enable when ->rs485_config() is invoked. Fix it. Fixes: 9be1064fe524 ("serial: ar933x_uart: add RS485 support") Cc: stable@vger.kernel.org # v5.7+ Cc: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/5b36af26e57553f084334666e7d24c7fd131a01e.1662887231.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: sifive: enable clocks for UART when probedOlof Johansson1-1/+1
When the PWM driver was changed to disable clocks if no PWMs are enabled, it ended up also disabling the shared parent with the UART, since the UART doesn't do any clock enablement on its own. To avoid these surprises, switch to clk_get_enabled(). Fixes: ace41d7564e655 ("pwm: sifive: Ensure the clk is enabled exactly once per running PWM") Cc: stable <stable@kernel.org> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Emil Renner Berthing <emil.renner.berthing@canonical.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Olof Johansson <olof@lixom.net> Link: https://lore.kernel.org/r/20220920160017.7315-1-olof@lixom.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: 8250: omap: Use serial8250_em485_supportedMatthias Schiffer1-0/+1
8250_omap uses em485, fill in rs485_supported accordingly. This makes RS485 work with 8250_omap again, which was broken with the introduction of the RS485 config sanitization. Fixes: be2e2cb1d2819 ("serial: Sanitize rs485_struct") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20220916110955.161099-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: fsl_lpuart: Reset prior to registrationLukas Wunner1-4/+5
Since commit bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp and imx8qxp"), certain i.MX UARTs are reset after they've already been registered. Register state may thus be clobbered after user space has begun to open and access the UART. Avoid by performing the reset prior to registration. Fixes: bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp and imx8qxp") Cc: stable@vger.kernel.org # v5.15+ Cc: Fugang Duan <fugang.duan@nxp.com> Cc: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/72fb646c1b0b11c989850c55f52f9ff343d1b2fa.1662884345.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22selftests: forwarding: add shebang for sch_red.shHangbin Liu1-0/+1
RHEL/Fedora RPM build checks are stricter, and complain when executable files don't have a shebang line, e.g. *** WARNING: ./kselftests/net/forwarding/sch_red.sh is executable but has no shebang, removing executable bit Fix it by adding shebang line. Fixes: 6cf0291f9517 ("selftests: forwarding: Add a RED test for SW datapath") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20220922024453.437757-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22bnxt: prevent skb UAF after handing over to PTP workerJakub Kicinski1-5/+5
When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free. Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL. Fixes: 83bb623c968e ("bnxt_en: Transmit and retrieve packet timestamps") Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20220921201005.335390-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22tty: serial: atmel: Use FIELD_PREP/FIELD_GETSergiu Moga1-36/+38
Convert all open-coded instances of bitfields retrieval/setting to FIELD_PREP/FIELD_GET where possible. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220922113347.144383-10-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: atmel: Make the driver aware of the existence of GCLKSergiu Moga2-1/+58
Previously, the atmel serial driver did not take into account the possibility of using the more customizable generic clock as its baudrate generator. Unless there is a Fractional Part available to increase accuracy, there is a high chance that we may be able to generate a baudrate closer to the desired one by using the GCLK as the clock source. Now, depending on the error rate between the desired baudrate and the actual baudrate, the serial driver will fallback on the generic clock. The generic clock must be provided in the DT node of the serial that may need a more flexible clock source. Furthermore, define the bit that represents the choice of having GCLK as a baudrate source clock inside the USCLKS bitmask of the Mode Register of USART IP's. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Link: https://lore.kernel.org/r/20220922113347.144383-9-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: atmel: Only divide Clock Divisor if the IP is USARTSergiu Moga1-1/+16
Make sure that the driver only divides the clock divisor if the IP handled at that point is USART, since UART IP's do not support implicit peripheral clock division. Instead, in the case of UART, go with the highest possible clock divisor. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220922113347.144383-8-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: atmel: Separate mode clearing between UART and USARTSergiu Moga2-2/+7
When clearing the mode of the serial IP inside the atmel_set_termios() method, make sure that the difference between the bitfields placement of the UART IP's and USART IP's is taken into account, as some of them overlap with each other. For example, ATMEL_UA_BRSRCCK overlaps with ATMEL_US_NBSTOP and ATMEL_US_USCLKS overlaps with ATMEL_UA_FILTER. Furthermore, add definitions for the Baud Rate Source Clock and the Filter bitfields of the Mode Register of UART IP's, since they were missing. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Link: https://lore.kernel.org/r/20220922113347.144383-7-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22dt-bindings: serial: atmel,at91-usart: Add gclk as a possible USART clockSergiu Moga1-2/+8
The Devicetree nodes for FLEXCOM's USART can also have an alternative clock source for the baudrate generator (other than the peripheral clock), namely the Generick Clock. Thus make the binding aware of this clock that someone may place in the clock related properties of the USART node. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220922113347.144383-6-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22dt-bindings: serial: atmel,at91-usart: Add SAM9260 compatibles to SAM9X60Sergiu Moga1-0/+2
Require SAM9260 fallback compatible for SAM9X60, because SAM9X60 is fully compatible with SAM9260 and Linux driver requires the latter. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220922113347.144383-4-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22dt-bindings: serial: atmel,at91-usart: convert to json-schemaSergiu Moga2-98/+182
Convert at91 USART DT Binding for Atmel/Microchip SoCs to json-schema format. Furthermore, move this binding to the serial directory, since binding directories match hardware, unlike the driver subsystems which match Linux convention. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220922113347.144383-3-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdownSherry Sun1-0/+2
lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can still occur which in turn tries to access dma apis if lpuart_dma_tx_use flag is true. At this point since dma is torn down, these dma apis can abort. Set lpuart_dma_tx_use and the corresponding rx flag lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not accessed after they are relinquished. Otherwise, when try to kill btattach, kernel may panic. This patch may fix this issue. root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 90.189806] Modules linked in: moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37 [ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040 [ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652] ____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [ 90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [ 90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]--- [ 90.397073] note: btattach[503] exited with preempt_count 1 [ 90.402636] Fixing recursive fault but reboot is needed! Fixes: 6250cc30c4c4 ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Thara Gopinath <tgopinath@microsoft.com> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20220920111703.1532-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: 8250: Toggle IER bits on only after irq has been set upIlpo Järvinen3-8/+17
Invoking TIOCVHANGUP on 8250_mid port on Ice Lake-D and then reopening the port triggers these faults during serial8250_do_startup(): DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Write NO_PASID] Request device [00:1a.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set If the IRQ hasn't been set up yet, the UART will have zeroes in its MSI address/data registers. Disabling the IRQ at the interrupt controller won't stop the UART from performing a DMA write to the address programmed in its MSI address register (zero) when it wants to signal an interrupt. The UARTs (in Ice Lake-D) implement PCI 2.1 style MSI without masking capability, so there is no way to mask the interrupt at the source PCI function level, except disabling the MSI capability entirely, but that would cause it to fall back to INTx# assertion, and the PCI specification prohibits disabling the MSI capability as a way to mask a function's interrupt service request. The MSI address register is zeroed by the hangup as the irq is freed. The interrupt is signalled during serial8250_do_startup() performing a THRE test that temporarily toggles THRI in IER. The THRE test currently occurs before UART's irq (and MSI address) is properly set up. Refactor serial8250_do_startup() such that irq is set up before the THRE test. The current irq setup code is intermixed with the timer setup code. As THRE test must be performed prior to the timer setup, extract it into own function and call it only after the THRE test. The ->setup_timer() needs to be part of the struct uart_8250_ops in order to not create circular dependency between 8250 and 8250_base modules. Fixes: 40b36daad0ac ("[PATCH] 8250 UART backup timer") Reported-by: Lennert Buytenhek <buytenh@arista.com> Tested-by: Lennert Buytenhek <buytenh@arista.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220922070005.2965-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: 8250: Switch UART port flags to using BIT_ULLMaciej W. Rozycki1-14/+14
Use BIT_ULL rather than encoding bits explicitly where applicable with UART port flags. This makes a (__force upf_t) cast redundant, but keep it for visual consistency with the flags defined in terms of userspace macros. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209210007030.41633@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: 8250: Request full 16550A feature probing for OxSemi PCIe devicesMaciej W. Rozycki1-0/+5
Oxford Semiconductor PCIe (Tornado) 950 serial port devices need to operate in the enhanced mode via the EFR register for the Divide-by-M N/8 baud rate generator prescaler to be used in their native UART mode. Otherwise the prescaler is fixed at 1 causing grossly incorrect baud rates to be programmed. Accessing the EFR register requires 16550A features to have been probed for, so request this to happen regardless of SERIAL_8250_16550A_VARIANTS by setting UPF_FULL_PROBE in port flags. Fixes: 366f6c955d4d ("serial: 8250: Add proper clock handling for OxSemi PCIe devices") Cc: stable@vger.kernel.org # v5.19+ Reported-by: Anders Blomdell <anders.blomdell@control.lth.se> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209210005040.41633@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: 8250: Let drivers request full 16550A feature probingMaciej W. Rozycki2-2/+4
A SERIAL_8250_16550A_VARIANTS configuration option has been recently defined that lets one request the 8250 driver not to probe for 16550A device features so as to reduce the driver's device startup time in virtual machines. Some actual hardware devices require these features to have been fully determined however for their driver to work correctly, so define a flag to let drivers request full 16550A feature probing on a device-by-device basis if required regardless of the SERIAL_8250_16550A_VARIANTS option setting chosen. Fixes: dc56ecb81a0a ("serial: 8250: Support disabling mdelay-filled probes of 16550A variants") Cc: stable@vger.kernel.org # v5.6+ Reported-by: Anders Blomdell <anders.blomdell@control.lth.se> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209202357520.41633@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22net: marvell: Fix refcounting bugs in prestera_port_sfp_bind()Liang He1-0/+2
In prestera_port_sfp_bind(), there are two refcounting bugs: (1) we should call of_node_get() before of_find_node_by_name() as it will automaitcally decrease the refcount of 'from' argument; (2) we should call of_node_put() for the break of the iteration for_each_child_of_node() as it will automatically increase and decrease the 'child'. Fixes: 52323ef75414 ("net: marvell: prestera: add phylink support") Signed-off-by: Liang He <windhl@126.com> Reviewed-by: Yevhen Orlov <yevhen.orlov@plvision.eu> Link: https://lore.kernel.org/r/20220921133245.4111672-1-windhl@126.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22tty: serial: extract serial_omap_put_char() from transmit_chars()Jiri Slaby1-9/+11
This non-trivial code is doubled in transmit_chars(), so it deserves its own function. This will make next patches easier. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920052049.20507-8-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: switch mpc52xx_uart_int_{r,t}x_chars() to boolJiri Slaby1-9/+9
mpc52xx_uart_int_rx_chars() returns unsigned int. mpc52xx_uart_int_tx_chars() returns int. The both results are binary ORed to the "keepgoing" variable. Unify all three to bool as the only interesting value is whether we should keep looping (true/false). Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920052049.20507-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: extract tx_ready() from __serial_lpc32xx_tx()Jiri Slaby1-2/+8
The condition in __serial_lpc32xx_tx()'s loop is barely readable. Extract it to a separate function. This will make the cleanup in the next patches easier too. Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: <linux-arm-kernel@lists.infradead.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920052049.20507-6-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: extract lqasc_tx_ready() from lqasc_tx_chars()Jiri Slaby1-2/+8
The condition in lqasc_tx_chars()'s loop is barely readable. Extract it to a separate function. This will make the cleanup in the next patches easier too. (Put it before lqasc_start_tx(), so that we can use it there later.) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920052049.20507-5-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: altera_uart_{r,t}x_chars() need only uart_portJiri Slaby1-6/+4
Both altera_uart_{r,t}x_chars() need only uart_port, not altera_uart. So pass the former from altera_uart_interrupt() directly. Apart it maybe saves a dereference, this makes the transition of altera_uart_tx_chars() easier to follow in the next patch. Cc: Tobias Klauser <tklauser@distanz.ch> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920052049.20507-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: clean up stop-tx part in altera_uart_tx_chars()Jiri Slaby1-4/+2
The "stop TX" path in altera_uart_tx_chars() is open-coded, so: * use uart_circ_empty() to check if the buffer is empty, and * when true, call altera_uart_stop_tx(). Cc: Tobias Klauser <tklauser@distanz.ch> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920052049.20507-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: move and cleanup vt8500_tx_empty()Jiri Slaby1-7/+8
Make vt8500_tx_empty() more readable by introducing a new local variable and move the function before handle_tx(). That way we can reuse it in there too. Cc: <linux-arm-kernel@lists.infradead.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920052049.20507-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: hvc: remove HVC_IUCV_MAGICнаб1-6/+5
According to Greg, in the context of magic numbers as defined in magic-number.rst, "the tty layer should not need this and I'll gladly take patches" This stretches that definition slightly, since it multiplexes it with the terminal number as a constant offset, but is equivalent Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Ref: https://lore.kernel.org/linux-doc/YyMlovoskUcHLEb7@kroah.com/ Link: https://lore.kernel.org/r/8c8a2c9dfc1bfbe6ef3f3237368e483865fc1c29.1663288066.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: synclink_gt: remove MGSL_MAGICнаб5-12/+0
According to Greg, in the context of magic numbers as defined in magic-number.rst, "the tty layer should not need this and I'll gladly take patches" Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Ref: https://lore.kernel.org/linux-doc/YyMlovoskUcHLEb7@kroah.com/ Link: https://lore.kernel.org/r/3d82b3c864970cdec6717c56dd906b54e78694d7.1663288066.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: n_hdlc: remove HDLC_MAGICнаб5-31/+0
According to Greg, in the context of magic numbers as defined in magic-number.rst, "the tty layer should not need this and I'll gladly take patches" Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Ref: https://lore.kernel.org/linux-doc/YyMlovoskUcHLEb7@kroah.com/ Link: https://lore.kernel.org/r/c31d228302da3f426cebf6fcff855181a5590a66.1663288066.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: remove TTY_DRIVER_MAGICнаб6-10/+0
According to Greg, in the context of magic numbers as defined in magic-number.rst, "the tty layer should not need this and I'll gladly take patches" Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Ref: https://lore.kernel.org/linux-doc/YyMlovoskUcHLEb7@kroah.com/ Link: https://lore.kernel.org/r/723478a270a3858f27843cbec621df4d5d44efcc.1663288066.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: remove TTY_MAGICнаб7-24/+0
According to Greg, in the context of magic numbers as defined in magic-number.rst, "the tty layer should not need this and I'll gladly take patches" Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Ref: https://lore.kernel.org/linux-doc/YyMlovoskUcHLEb7@kroah.com/ Link: https://lore.kernel.org/r/476d024cd6b04160a5de381ea2b9856b60088cbd.1663288066.git.nabijaczleweli@nabijaczleweli.xyz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22drivers: serial: jsm: fix some leaks in probeDan Carpenter1-1/+2
This error path needs to unwind instead of just returning directly. Fixes: 03a8482c17dd ("drivers: serial: jsm: Enable support for Digi Classic adapters") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YyxFh1+lOeZ9WfKO@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22dt-bindings: serial: rockchip: add rockchip,rk3128-uartJohan Jonker1-0/+1
Add rockchip,rk3128-uart compatible string. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Acked-by: Jamie Iles <jamie@jamieiles.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/4f283231-2ed4-202b-0c23-157bce0841ee@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: omap: Disallow RS-485 if rts-gpio is not specifiedLukas Wunner1-14/+13
The serial-omap driver requires an rts-gpio for RS-485 to work. Historically it has allowed enabling RS-485 even if no rts-gpio was specified in the device tree. That doesn't make any sense, so disable RS-485 on probe if rts-gpio is missing and disallow user space from enabling it. Three NULL pointer checks for up->rts_gpiod can be dropped as a result, simplifying the driver slightly. Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/f191dcca0d8ea03598c463fc0d3fba8941ff2275.1662888075.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22tty: serial: cpm_uart: remove unused cpm_uart_nr declarationGaosheng Cui1-1/+0
cpm_uart_nr has been removed since commit 0b2a2e5b7747 ("cpm_uart: Remove !CONFIG_PPC_CPM_NEW_BINDING code"), so remove it. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Link: https://lore.kernel.org/r/20220911093654.3222701-1-cuigaosheng1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>