kernel/linux.git/drivers/parport, branch v6.1.176

parport: Fix race between port and client registration

2026-06-19T11:37:00+00:00

commit ef15ccbb3e8640a723c42ad90eaf81d66ae02017 upstream. The parport subsystem registers port devices before they are fully initialised, resulting in a race condition where client drivers such as lp can attach to ports that are not completely initialised or even being torn down. When the port and client drivers are built as modules and loaded around the same time during boot, this occasionally results in a crash. I was able to make this happen reliably in a VM with a PC-style parallel port by patching parport_pc to fail probing: > --- a/drivers/parport/parport_pc.c > +++ b/drivers/parport/parport_pc.c > @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port(unsigned long int base, > if (!p) > goto out3; > > - base_res = request_region(base, 3, p->name); > + base_res = NULL; > if (!base_res) > goto out4; > and then running: while true; do modprobe lp & modprobe parport_pc wait rmmod lp parport_pc done for a few seconds. In the long term I think port registration should be changed to put the call to device_add() inside parport_announce_port(), but since the latter currently cannot fail this will require changing all port drivers. For now, add a flag to indicate whether a port has been "announced" and only try to attach client drivers to ports when the flag is set. Fixes: 6fa45a226897 ("parport: add device-model to parport subsystem") Closes: https://bugs.debian.org/1130365 Closes: https://lore.kernel.org/all/6ba903ad-9897-42bb-8c2d-337385cc3746@molgen.mpg.de/ Cc: stable Signed-off-by: Ben Hutchings Acked-by: Sudip Mukherjee Link: https://patch.msgid.link/afo6uBv68GDevbMD@decadent.org.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

parport_pc: add support for ASIX AX99100

2025-02-21T12:50:11+00:00

commit 16aae4c64600a6319a6f10dbff833fa198bf9599 upstream. The PCI function 2 on ASIX AX99100 PCIe to Multi I/O Controller can be configured as a single-port parallel port controller. The subvendor id is 0x2000 when configured as parallel port. It supports IEEE-1284 EPP / ECP with its ECR on BAR1. Signed-off-by: Jiaqing Zhao Reviewed-by: Andy Shevchenko Acked-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20230724083933.3173513-5-jiaqing.zhao@linux.intel.com Signed-off-by: Tomita Moeko Signed-off-by: Greg Kroah-Hartman

parport: Proper fix for array out-of-bounds access

2024-10-22T13:56:49+00:00

commit 02ac3a9ef3a18b58d8f3ea2b6e46de657bf6c4f9 upstream. The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly. Fixes: ab11dac93d2d ("dev/parport: fix the array out-of-bounds risk") Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20240920103318.19271-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman

dev/parport: fix the array out-of-bounds risk

2024-08-03T06:49:37+00:00

commit ab11dac93d2d568d151b1918d7b84c2d02bacbd5 upstream. Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] Signed-off-by: tuhaowen Cc: stable Link: https://lore.kernel.org/r/20240708080430.8221-1-tuhaowen@uniontech.com Signed-off-by: Greg Kroah-Hartman

parport: parport_serial: Add Brainboxes device IDs and geometry

2024-01-20T10:50:11+00:00

commit 6aa1fc5a8085bbc01687aa708dcf2dbe637a5ee3 upstream. Add device IDs for the Brainboxes UC-203, UC-257, UC-414, UC-475, IS-300/IS-500 and PX-263/PX-295 and define the relevant "geometry" for the cards. This patch requires part 1 of this series. Cc: Signed-off-by: Cameron Williams Acked-by: Sudip Mukherjee Link: https://lore.kernel.org/r/AS4PR02MB7903A4094564BE28F1F926A6C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman

parport: parport_serial: Add Brainboxes BAR details

2024-01-20T10:50:10+00:00

commit 65fde134b0a4ffe838729f9ee11b459a2f6f2815 upstream. Add BAR/enum entries for Brainboxes serial/parallel cards. Cc: Signed-off-by: Cameron Williams Acked-by: Sudip Mukherjee Link: https://lore.kernel.org/r/AS4PR02MB79035155C2D5C3333AE6FA52C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman

parport: Add support for Brainboxes IX/UC/PX parallel cards

2023-12-13T17:39:26+00:00

commit 1a031f6edc460e9562098bdedc3918da07c30a6e upstream. Adds support for Intashield IX-500/IX-550, UC-146/UC-157, PX-146/PX-157, PX-203 and PX-475 (LPT port) Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams Acked-by: Sudip Mukherjee Link: https://lore.kernel.org/r/AS4PR02MB790389C130410BD864C8DCC9C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman

parport_pc: Avoid FIFO port location truncation

2022-11-09T14:40:32+00:00

Match the data type of a temporary holding a reference to the FIFO port with the type of the original reference coming from `struct parport', avoiding data truncation with LP64 ports such as SPARC64 that refer to PCI port I/O locations via their corresponding MMIO addresses and will therefore have non-zero bits in the high 32-bit part of the reference. And in any case it is cleaner to have the data types matching here. Signed-off-by: Maciej W. Rozycki Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/linux-pci/20220419033752.GA1101844@bhelgaas/ Acked-by: Sudip Mukherjee Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209231912550.29493@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman

parport: add support for Netmos device 9900

2022-09-01T15:46:06+00:00

The Netmos parallel port 9901 was already supported but the device 9900 was not. This patch adds the required settings for it and was successfully tested with the Netmos device 9900. Signed-off-by: Alexander Baehr Link: https://lore.kernel.org/r/20220806113334.264598686@osadl.org Signed-off-by: Greg Kroah-Hartman

parport_pc: Also enable driver for PCI systems

2022-03-18T13:01:41+00:00

Nowadays PC-style parallel ports come in the form of PCI and PCIe option cards and there are some combined parallel/serial option cards as well that we handle in the parport subsystem. There is nothing in particular that would prevent them from being used in any system equipped with PCI or PCIe connectivity, except that we do not permit the PARPORT_PC config option to be selected for platforms for which ARCH_MIGHT_HAVE_PC_PARPORT has not been set for. The only PCI platforms that actually can't make use of PC-style parallel port hardware are those newer PCIe systems that have no support for I/O cycles in the host bridge, required by such parallel ports. Notably, this includes the s390 arch, which has port I/O accessors that cause compilation warnings (promoted to errors with `-Werror'), and there are other cases such as the POWER9 PHB4 device, though this one has variable port I/O accessors that depend on the particular system. Also it is not clear whether the serial port side of devices enabled by PARPORT_SERIAL uses port I/O or MMIO. Finally Super I/O solutions are always either ISA or platform devices. Make the PARPORT_PC option selectable also for PCI systems then, except for the s390 arch, however limit the availability of PARPORT_PC_SUPERIO to platforms that enable ARCH_MIGHT_HAVE_PC_PARPORT. Update platforms accordingly for the required header. Acked-by: Sudip Mukherjee Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2202141955550.34636@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman