- Oct 22, 2023
-
-
Cameron Williams authored
The PX-803/PX-857 are variants of each other, add a note. Additionally fix up the port counts for the card (2, not 1). Fixes: ef5a03a2 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: stable@vger.kernel.org Signed-off-by:
Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB789978C8ED872FB4B014E132C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cameron Williams authored
The port count of the PX-257 Rev3 is actually 2, not 4. Fixes: ef5a03a2 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: stable@vger.kernel.org Signed-off-by:
Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899C804D9F04E727B5A0E8FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cameron Williams authored
Add support for the Intashield IS-100 1 port serial card. Cc: stable@vger.kernel.org Signed-off-by:
Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899A0E0CDAA505AF5A874CDC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cameron Williams authored
Add support for the Brainboxes UP (powered PCI) range of cards, namely UP-189, UP-200, UP-869 and UP-880. Cc: stable@vger.kernel.org Signed-off-by:
Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899B5B59FF3D8587E88C117C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cameron Williams authored
Add device IDs for some more Brainboxes UC cards, namely UC-235/UC-246, UC-253/UC-734, UC-302, UC-313, UC-346, UC-357, UC-607 and UC-836. Cc: stable@vger.kernel.org Signed-off-by:
Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB789969998A6C3FAFCD95C85DC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cameron Williams authored
The UC-257 is a serial + LPT card, so remove it from this driver. A patch has been submitted to add it to parport_serial instead. Additionaly, the UC-431 does not use this card ID, only the UC-420 does. The 431 is a 3-port card and there is no generic 3-port configuration available, so remove reference to it from this driver. Fixes: 152d1afa ("tty: Add support for Brainboxes UC cards.") Cc: stable@vger.kernel.org Signed-off-by:
Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB78995ADF7394C74AD4CF3357C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Richard authored
If the console suspend is disabled, the genpd of the console shall not be powered-off during suspend. Set the flag GENPD_FLAG_ALWAYS_ON to the corresponding genpd during suspend, and restore the original value during the resume. Signed-off-by:
Thomas Richard <thomas.richard@bootlin.com> Link: https://lore.kernel.org/r/20231017130540.1149721-1-thomas.richard@bootlin.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Woodhouse authored
On unplug of a Xen console, xencons_disconnect_backend() unconditionally calls free_irq() via unbind_from_irqhandler(), causing a warning of freeing an already-free IRQ: (qemu) device_del con1 [ 32.050919] ------------[ cut here ]------------ [ 32.050942] Trying to free already-free IRQ 33 [ 32.050990] WARNING: CPU: 0 PID: 51 at kernel/irq/manage.c:1895 __free_irq+0x1d4/0x330 It should be using evtchn_put() to tear down the event channel binding, and let the Linux IRQ side of it be handled by notifier_del_irq() through the HVC code. On which topic... xencons_disconnect_backend() should call hvc_remove() *first*, rather than tearing down the event channel and grant mapping while they are in use. And then the IRQ is guaranteed to be freed by the time it's torn down by evtchn_put(). Since evtchn_put() also closes the actual event channel, avoid calling xenbus_free_evtchn() except in the failure path where the IRQ was not successfully set up. However, calling hvc_remove() at the start of xencons_disconnect_backend() still isn't early enough. An unplug request is indicated by the backend setting its state to XenbusStateClosing, which triggers a notification to xencons_backend_changed(), which... does nothing except set its own frontend state directly to XenbusStateClosed without *actually* tearing down the HVC device or, you know, making sure it isn't actively in use. So the backend sees the guest frontend set its state to XenbusStateClosed and stops servicing the interrupt... and the guest spins for ever in the domU_write_console() function waiting for the ring to drain. Fix that one by calling hvc_remove() from xencons_backend_changed() before signalling to the backend that it's OK to proceed with the removal. Tested with 'dd if=/dev/zero of=/dev/hvc1' while telling Qemu to remove the console device. Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231020161529.355083-4-dwmw2@infradead.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Woodhouse authored
The xen_hvc_init() function should always register the frontend driver, even when there's no primary console — as there may be secondary consoles. (Qemu can always add secondary consoles, but only the toolstack can add the primary because it's special.) Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Reviewed-by:
Juergen Gross <jgross@suse.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231020161529.355083-3-dwmw2@infradead.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Woodhouse authored
The xencons_connect_backend() function allocates a local interdomain event channel with xenbus_alloc_evtchn(), then calls bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the *remote* domain. That doesn't work very well: (qemu) device_add xen-console,id=con1,chardev=pty0 [ 44.323872] xenconsole console-1: 2 xenbus_dev_probe on device/console/1 [ 44.323995] xenconsole: probe of console-1 failed with error -2 Fix it to use bind_evtchn_to_irq_lateeoi(), which does the right thing by just binding that *local* event channel to an irq. The backend will do the interdomain binding. This didn't affect the primary console because the setup for that is special — the toolstack allocates the guest event channel and the guest discovers it with HVMOP_get_param. Fixes: fe415186 ("xen/console: harden hvc_xen against event channel storms") Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Reviewed-by:
Juergen Gross <jgross@suse.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231020161529.355083-2-dwmw2@infradead.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Crescent CY Hsieh authored
Add support for MOXA Mini PCIe serial boards: - CP102N: 2 ports | RS232 - CP104N: 4 ports | RS232 - CP112N: 2 ports | RS232/RS422/RS485 - CP114N: 4 ports | RS232/RS422/RS485 - CP132N: 2 ports | RS422/RS485 - CP134N: 4 ports | RS422/RS485 Signed-off-by:
Crescent CY Hsieh <crescentcy.hsieh@moxa.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20231018091739.10125-5-crescentcy.hsieh@moxa.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Crescent CY Hsieh authored
Move PCI_DEVICE_ID macros to the top so that these macros can be used throughout 8250_pci.c Signed-off-by:
Crescent CY Hsieh <crescentcy.hsieh@moxa.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20231018091739.10125-4-crescentcy.hsieh@moxa.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Crescent CY Hsieh authored
To improve clarity, clean up the MOXA configurations within serial_pci_tbl using PCI_VDEVICE(). Signed-off-by:
Crescent CY Hsieh <crescentcy.hsieh@moxa.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20231018091739.10125-3-crescentcy.hsieh@moxa.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Crescent CY Hsieh authored
To improve clarity, modify the MOXA enum name within pci_board_num_t. Signed-off-by:
Crescent CY Hsieh <crescentcy.hsieh@moxa.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20231018091739.10125-2-crescentcy.hsieh@moxa.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Francesco Dolcini authored
Add rs485-rts-active-high property, this is a legacy property used by 8250_omap. This fixes the following make dt_binding_check warning: Documentation/devicetree/bindings/serial/8250_omap.yaml: rs485-rts-active-high: missing type definition Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdUkPiA=o_QLyuwsTYW7y1ksCjHAqyNSHFx2QZ-dP-HGsQ@mail.gmail.com/ Fixes: 403e97d6 ("dt-bindings: serial: 8250_omap: add rs485-rts-active-high") Cc: stable <stable@kernel.org> Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231019154834.41721-1-francesco@dolcini.it Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
André Draszik authored
When support for various old platforms was removed in commit 1ea35b35 ("ARM: s3c: remove s3c24xx specific hacks"), s3c24xx_serial_ops also became unused here because nothing sets port type TYPE_S3C24XX anymore. Remove s3c24xx_serial_ops and all the code that's unreachable now. Fixes: 1ea35b35 ("ARM: s3c: remove s3c24xx specific hacks") Signed-off-by:
André Draszik <andre.draszik@linaro.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20231019100901.4026680-1-andre.draszik@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Florian Eckert authored
Tabs were used in the function description, to make this look more uniform, the tabs were replaced by spaces where necessary. While we're at it, I also replaced the 'ndashes' with simple dashes, since only those are supported by sphinx. Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
Florian Eckert <fe@dev.tdt.de> Link: https://lore.kernel.org/r/20231019112809.881730-2-fe@dev.tdt.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Max Filippov authored
esp32s3 variant of the esp32 UART has limited baudrate divisor range that does not allow it to use 9600 and lower rates with 40MHz input clock. Use clock prescaler present in this UART variant to help with that. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Link: https://lore.kernel.org/r/20231018191252.1551972-1-jcmvbkbc@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Krzysztof Kozlowski authored
The DT schema coding convention expressed in Documentation/devicetree/bindings/example-schema.yaml expects entries in following order: - properties, patternProperties - required - if blocks, allOf with if-blocks - additionalProperties/unevaluatedProperties Re-order few schemas to match the convention to avoid repeating review comments for new patches using existing code as template. No functional changes. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231016181909.368429-1-krzysztof.kozlowski@linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 17, 2023
-
-
Arnd Bergmann authored
Separating the VGA console screen_info from the EFI one unfortunately caused a build failure for footbridge that I had never caught with randconfig builds: arch/arm/kernel/setup.c:932:27: error: static declaration of 'vgacon_screen_info' follows non-static declaration 932 | static struct screen_info vgacon_screen_info = { | ^~~~~~~~~~~~~~~~~~ In file included from arch/arm/kernel/setup.c:44: arch/arm/include/asm/setup.h:40:27: note: previous declaration of 'vgacon_screen_info' with type 'struct screen_info' 40 | extern struct screen_info vgacon_screen_info; | ^~~~~~~~~~~~~~~~~~ arm-linux-gnueabi-ld: drivers/video/console/dummycon.o: in function `dummycon_init': dummycon.c:(.text+0xe4): undefined reference to `screen_info' Make sure the variable is global to avoid the conflict with the extern declaration, and make it work in dummycon.c Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231017093947.3627976-2-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
After the vga console no longer relies on global screen_info, there are only two remaining use cases: - on the x86 architecture, it is used for multiple boot methods (bzImage, EFI, Xen, kexec) to commucate the initial VGA or framebuffer settings to a number of device drivers. - on other architectures, it is only used as part of the EFI stub, and only for the three sysfb framebuffers (simpledrm, simplefb, efifb). Remove the duplicate data structure definitions by moving it into the efi-init.c file that sets it up initially for the EFI case, leaving x86 as an exception that retains its own definition for non-EFI boots. The added #ifdefs here are optional, I added them to further limit the reach of screen_info to configurations that have at least one of the users enabled. Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231017093947.3627976-1-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tony Lindgren authored
While adding a preferred console handling for serial_core for serial port hardware based device addressing, Jiri suggested we constify name for add_preferred_console(). The name gets copied anyways. This allows serial core to add a preferred console using serial drv->dev_name without copying it. Note that constifying options causes changes all over the place because of struct console for match(). Suggested-by:
Jiri Slaby <jirislaby@kernel.org> Reviewed-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231012064300.50221-2-tony@atomide.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tony Lindgren authored
Let's check for valid console index values for preferred console to avoid bogus console index numbers from kernel command line. Let's also return an error for negative index numbers for the preferred console. Unlike for device drivers, a negative index is not valid for the preferred console. Let's also constify idx while at it. Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231012064300.50221-1-tony@atomide.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
The two hyperv framebuffer drivers (hyperv_fb or hyperv_drm_drv) access the global screen_info in order to take over from the sysfb framebuffer, which in turn could be handled by simplefb, simpledrm or efifb. Similarly, the vmbus_drv code marks the original EFI framebuffer as reserved, but this is not required if there is no sysfb. As a preparation for making screen_info itself more local to the sysfb helper code, add a compile-time conditional in all three files that relate to hyperv fb and just skip this code if there is no sysfb that needs to be unregistered. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231009211845.3136536-9-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
I noticed that commit 0db5b61e ("fbdev/vga16fb: Create EGA/VGA devices in sysfb code") broke vga16fb on non-x86 platforms, because the sysfb code never creates a vga-framebuffer device when screen_info.orig_video_isVGA is set to '1' instead of VIDEO_TYPE_VGAC. However, it turns out that the only architecture that has allowed building vga16fb in the past 20 years is powerpc, and this only worked on two 32-bit platforms and never on 64-bit powerpc. The last machine that actually used this was removed in linux-3.10, so this is all dead code and can be removed. The big-endian support in vga16fb.c could also be removed, but I'd just leave this in place. Fixes: 933ee711 ("powerpc: remove PReP platform") Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231009211845.3136536-8-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
To prepare for completely separating the VGA console screen_info from the one used in EFI/sysfb, rename the vgacon instances and make them local as much as possible. ia64 and arm both have confurations with vgacon and efi, but the contents never overlaps because ia64 has no EFI framebuffer, and arm only has vga console on legacy platforms without EFI. Renaming these is required before the EFI screen_info can be moved into drivers/firmware. The ia64 vga console is actually registered in two places from setup_arch(), but one of them is wrong, so drop the one in pcdp.c and fix the one in setup.c to use the correct conditional. x86 has to keep them together, as the boot protocol is used to switch between VGA text console and framebuffer through the screen_info data. Acked-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Khalid Aziz <khalid@gonehiking.org> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231009211845.3136536-7-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
The vga console driver is fairly self-contained, and only used by architectures that explicitly initialize the screen_info settings. Chance every instance that picks the vga console by setting conswitchp to call a function instead, and pass a reference to the screen_info there. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Khalid Azzi <khalid@gonehiking.org> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231009211845.3136536-6-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
A number of architectures either kept the screen_info definition for historical purposes as it used to be required by the generic VT code, or they copied it from another architecture in order to build the VGA console driver in an allmodconfig build. The mips definition is used by some platforms, but the initialization on jazz is not needed. Now that vgacon no longer builds on these architectures, remove the stale definitions and initializations. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by:
Dinh Nguyen <dinguyen@kernel.org> Acked-by:
Max Filippov <jcmvbkbc@gmail.com> Acked-by:
Palmer Dabbelt <palmer@rivosinc.com> Acked-by:
Guo Ren <guoren@kernel.org> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231009211845.3136536-5-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
The dummycon default console size used to be determined by architecture, but now this is a Kconfig setting on everything except ARM. Tracing this back in the historic git trees, this was used to match the size of VGA console or VGA framebuffer on early machines, but nowadays that code is no longer used, except probably on the old footbridge/netwinder since that is the only one that supports vgacon. On machines with a framebuffer, booting with DT so far results in always using the hardcoded 80x30 size in dummycon, while on ATAGS the setting can come from a bootloader specific override. Both seem to be worse choices than the Kconfig setting, since the actual text size for fbcon also depends on the selected font. Make this work the same way as everywhere else and use the normal Kconfig setting, except for the footbridge with vgacon, which keeps using the traditional code. If vgacon is disabled, footbridge can also ignore the setting. This means the screen_info only has to be provided when either vgacon or EFI are enabled now. To limit the amount of surprises on Arm, change the Kconfig default to the previously used 80x30 setting instead of the usual 80x25. Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231009211845.3136536-4-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
On non-x86 architectures, the screen_info variable is generally only used for the VGA console where supported, and in some cases the EFI framebuffer or vga16fb. Now that we have a definite list of which architectures actually use it for what, use consistent #ifdef checks so the global variable is only defined when it is actually used on those architectures. Loongarch and riscv have no support for vgacon or vga16fb, but they support EFI firmware, so only that needs to be checked, and the initialization can be removed because that is handled by EFI. IA64 has both vgacon and EFI, though EFI apparently never uses a framebuffer here. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Khalid Aziz <khalid@gonehiking.org> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231009211845.3136536-3-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
The list of dependencies here is phrased as an opt-out, but this is missing a lot of architectures that don't actually support VGA consoles, and some of the entries are stale: - powerpc used to support VGA consoles in the old arch/ppc codebase, but the merged arch/powerpc never did - arm lists footbridge, integrator and netwinder, but netwinder is actually part of footbridge, and integrator does not appear to have an actual VGA hardware, or list it in its ATAG or DT. - mips has a few platforms (malta, sibyte, and sni) that initialize screen_info, on everything else the console is selected but cannot actually work. - csky, hexgagon, loongarch, nios2, riscv and xtensa are not listed in the opt-out table and declare a screen_info to allow building vga_con, but this cannot work because the console is never selected. Replace this with an opt-in table that lists only the platforms that remain. This is effectively x86, plus a couple of historic workstation and server machines that reused parts of the x86 system architecture. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Khalid Aziz <khalid@gonehiking.org> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20231009211845.3136536-2-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pavel Krasavin authored
There might be hard lockup if we set crtscts mode on port without RTS/CTS configured: # stty -F /dev/ttyAML6 crtscts; echo 1 > /dev/ttyAML6; echo 2 > /dev/ttyAML6 [ 95.890386] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 95.890857] rcu: 3-...0: (201 ticks this GP) idle=e33c/1/0x4000000000000000 softirq=5844/5846 fqs=4984 [ 95.900212] rcu: (detected by 2, t=21016 jiffies, g=7753, q=296 ncpus=4) [ 95.906972] Task dump for CPU 3: [ 95.910178] task:bash state:R running task stack:0 pid:205 ppid:1 flags:0x00000202 [ 95.920059] Call trace: [ 95.922485] __switch_to+0xe4/0x168 [ 95.925951] 0xffffff8003477508 [ 95.974379] watchdog: Watchdog detected hard LOCKUP on cpu 3 [ 95.974424] Modules linked in: 88x2cs(O) rtc_meson_vrtc Possible solution would be to not allow to setup crtscts on such port. Tested on S905X3 based board. Fixes: ff7693d0 ("ARM: meson: serial: add MesonX SoC on-chip uart driver") Cc: stable@vger.kernel.org Signed-off-by:
Pavel Krasavin <pkrasavin@imaqliq.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Dmitry Rokosov <ddrokosov@salutedevices.com> v6: stable tag added v5: https://lore.kernel.org/lkml/OF43DA36FF.2BD3BB21-ON00258A47.005A8125-00258A47.005A9513@gdc.ru/ added missed Reviewed-by tags, Fixes tag added according to Dmitry and Neil notes v4: https://lore.kernel.org/lkml/OF55521400.7512350F-ON00258A47.003F7254-00258A47.0040E15C@gdc.ru/ More correct patch subject according to Jiri's note v3: https://lore.kernel.org/lkml/OF6CF5FFA0.CCFD0E8E-ON00258A46.00549EDF-00258A46.0054BB62@gdc.ru/ "From:" line added to the mail v2: https://lore.kernel.org/lkml/OF950BEF72.7F425944-ON00258A46.00488A76-00258A46.00497D44@gdc.ru/ braces for single statement removed according to Dmitry's note v1: https://lore.kernel.org/lkml/OF28B2B8C9.5BC0CD28-ON00258A46.0037688F-00258A46.0039155B@gdc.ru/ Link: https://lore.kernel.org/r/OF66360032.51C36182-ON00258A48.003F656B-00258A48.0040092C@gdc.ru Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Max Filippov authored
Add driver for the ACM gadget controller of the Espressif ESP32S3 SoC. Hardware specification is available at the following URL: https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf (Chapter 33 USB Serial/JTAG Controller) Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Link: https://lore.kernel.org/r/20231010085926.1021667-6-jcmvbkbc@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Max Filippov authored
Add documentation for the ESP32S3 USB CDC-ACM gadget controller. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231010085926.1021667-5-jcmvbkbc@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Max Filippov authored
Add driver for the UART controllers of the Espressif ESP32 and ESP32S3 SoCs. Hardware specification is available at the following URLs: https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf (Chapter 13 UART Controller) https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf (Chapter 26 UART Controller) Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Link: https://lore.kernel.org/r/20231010085926.1021667-4-jcmvbkbc@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Max Filippov authored
Add documentation for the ESP32xx UART controllers. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231010085926.1021667-3-jcmvbkbc@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Max Filippov authored
uart_get_baud_rate has input parameters 'min' and 'max' limiting the range of acceptable baud rates from the caller's perspective. If neither current or old termios structures have acceptable baud rate setting and 9600 is not in the min/max range either the function returns 0 and issues a warning. However for a UART that does not support speed of 9600 baud this is expected behavior. Clarify that 0 can be (and always could be) returned from the uart_get_baud_rate. Don't issue a warning in that case. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Link: https://lore.kernel.org/r/20231010085926.1021667-2-jcmvbkbc@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Julien Malik authored
Zynq UG585 states, in chapter B.33, for XUARTPS_CR_STARTBRK: It can only be set if STPBRK (Stop transmitter break) is not high This fixes tcsendbreak, which otherwise does not actually break. Signed-Off-By:
Julien Malik <julien.malik@unseenlabs.fr> Link: https://lore.kernel.org/r/20230624210323.88455-1-julien.malik@unseenlabs.fr Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hugo Villeneuve authored
Fix coding style. No functional changes. Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20231011130317.3562401-1-hugo@hugovil.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hugo Villeneuve authored
The 'allOf' block should go after the 'required' block according to DT bindings best practices. Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231013141925.3427158-2-hugo@hugovil.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-