March 2025 - Linux-stable-mirror

[PATCH] fpga: bridge: incorrect set to clear freeze_illegal_request register

by Tanmay Kathpalia

A Partial Region Controller can be connected to one or more Freeze Bridge. Each Freeze Bridge has an illegal_request bit represented in the freeze_illegal_request register. Thus, instead of just set to clear the illegal_request bit for first Freeze Bridge, we need to ensure the set to clear action is applied to which ever Freeze Bridge that has occurrence of illegal request. Fixes: ca24a648f535 ("fpga: add altera freeze bridge support") Signed-off-by: Chiau Ee Chew <chiau.ee.chew(a)intel.com> Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia(a)altera.com> --- drivers/fpga/altera-freeze-bridge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fpga/altera-freeze-bridge.c b/drivers/fpga/altera-freeze-bridge.c index 594693ff786e..23e8b2b54355 100644 --- a/drivers/fpga/altera-freeze-bridge.c +++ b/drivers/fpga/altera-freeze-bridge.c @@ -52,7 +52,7 @@ static int altera_freeze_br_req_ack(struct altera_freeze_br_data *priv, if (illegal) { dev_err(dev, "illegal request detected 0x%x", illegal); - writel(1, csr_illegal_req_addr); + writel(illegal, csr_illegal_req_addr); illegal = readl(csr_illegal_req_addr); if (illegal) -- 2.19.0

3 months, 1 week

2
1
0 0

[PATCH net v3] qlcnic: fix memory leak issues in qlcnic_sriov_common.c

by Haoxiang Li

Add qlcnic_sriov_free_vlans() in qlcnic_sriov_alloc_vlans() if any sriov_vlans fails to be allocated. Add qlcnic_sriov_free_vlans() to free the memory allocated by qlcnic_sriov_alloc_vlans() if "sriov->allowed_vlans" fails to be allocated. Fixes: 91b7282b613d ("qlcnic: Support VLAN id config.") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- Changes in v3: - Handle allocation errors in qlcnic_sriov_alloc_vlans() - Modify the patch title and description. There's one more thing I'm confused about: I'm not sure if the fixes-tag is correct, because I noticed that the two modifications correspond to different commits. Should I split them into two separate patch submissions? Thanks, Paolo! Changes in v2: - Add qlcnic_sriov_free_vlans() if qlcnic_sriov_alloc_vlans() fails. - Modify the patch description. vf_info was allocated by kcalloc, no need to do more checks cause kfree(NULL) is safe. Thanks, Paolo! --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c index f9dd50152b1e..28d24d59efb8 100644 --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c @@ -454,8 +454,10 @@ static int qlcnic_sriov_set_guest_vlan_mode(struct qlcnic_adapter *adapter, num_vlans = sriov->num_allowed_vlans; sriov->allowed_vlans = kcalloc(num_vlans, sizeof(u16), GFP_KERNEL); - if (!sriov->allowed_vlans) + if (!sriov->allowed_vlans) { + qlcnic_sriov_free_vlans(adapter); return -ENOMEM; + } vlans = (u16 *)&cmd->rsp.arg[3]; for (i = 0; i < num_vlans; i++) @@ -2167,8 +2169,10 @@ int qlcnic_sriov_alloc_vlans(struct qlcnic_adapter *adapter) vf = &sriov->vf_info[i]; vf->sriov_vlans = kcalloc(sriov->num_allowed_vlans, sizeof(*vf->sriov_vlans), GFP_KERNEL); - if (!vf->sriov_vlans) + if (!vf->sriov_vlans) { + qlcnic_sriov_free_vlans(adapter); return -ENOMEM; + } } return 0; -- 2.25.1

3 months, 1 week

2
1
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) in vmlinux (Makefile:1212) [logspec:kbuild,kbuild.other]

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- in vmlinux (Makefile:1212) [logspec:kbuild,kbuild.other] --- - dashboard: https://d.kernelci.org/issue/maestro:d5c2be698989c7de46471109aae8df0339b713… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: a0e8dfa03993fda7b4d4b696c50f69726522abba Log excerpt: ===================================================== .lds In file included from ./include/linux/kernel.h:15, net/ipv6/udp.c: In function ‘udp_v6_send_skb’: ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast ./include/linux/minmax.h:26:18: note: in expansion of macro ‘__typecheck’ ./include/linux/minmax.h:36:31: note: in expansion of macro ‘__safe_cmp’ ./include/linux/minmax.h:45:25: note: in expansion of macro ‘__careful_cmp’ net/ipv6/udp.c:1213:28: note: in expansion of macro ‘min’ In file included from ./include/linux/uaccess.h:7, net/ipv4/udp.c: In function ‘udp_send_skb’: ./include/linux/minmax.h:20:35: warning: comparison of distinct pointer types lacks a cast ./include/linux/minmax.h:26:18: note: in expansion of macro ‘__typecheck’ ./include/linux/minmax.h:36:31: note: in expansion of macro ‘__safe_cmp’ ./include/linux/minmax.h:45:25: note: in expansion of macro ‘__careful_cmp’ net/ipv4/udp.c:926:28: note: in expansion of macro ‘min’ FAILED unresolved symbol filp_close ===================================================== # Builds where the incident occurred: ## cros://chromeos-5.10/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y on (x86_64): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:67ceffea18018371957ebdc0 #kernelci issue maestro:d5c2be698989c7de46471109aae8df0339b713c1 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 months, 1 week

2
1
0 0

queue-5.10: Panic on shutdown at platform_shutdown+0x9

by Chuck Lever

Hi - For the past 3-4 days, NFSD CI runs on queue-5.10.y have been failing. I looked into it today, and the test guest fails to reboot because it panics during a reboot shutdown: [ 146.793087] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 146.793918] #PF: supervisor read access in kernel mode [ 146.794544] #PF: error_code(0x0000) - not-present page [ 146.795172] PGD 3d5c14067 P4D 3d5c15067 PUD 3d5c17067 PMD 0 [ 146.795865] Oops: 0000 [#1] SMP NOPTI [ 146.796326] CPU: 3 PID: 1 Comm: systemd-shutdow Not tainted 5.10.234-g99349f441fe1 #1 [ 146.797256] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 146.798267] RIP: 0010:platform_shutdown+0x9/0x20 [ 146.798838] Code: b7 46 08 c3 cc cc cc cc 31 c0 83 bf a8 02 00 00 ff 75 ec c3 cc cc cc cc 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 68 <48> 8b 40 e8 48 85 c0 74 09 48 83 ef 10 ff e0 0f 1f 00 c3 cc cc cc [ 146.801012] RSP: 0018:ff7f86f440013de0 EFLAGS: 00010246 [ 146.801651] RAX: 0000000000000000 RBX: ff4f0637469df418 RCX: 0000000000000000 [ 146.802500] RDX: 0000000000000001 RSI: ff4f0637469df418 RDI: ff4f0637469df410 [ 146.803350] RBP: ffffffffb2e79220 R08: ff4f0637469dd808 R09: ffffffffb2c5c698 [ 146.804203] R10: 0000000000000000 R11: 0000000000000000 R12: ff4f0637469df410 [ 146.805059] R13: ff4f0637469df490 R14: 00000000fee1dead R15: 0000000000000000 [ 146.805909] FS: 00007f4e7ecc6b80(0000) GS:ff4f063aafd80000(0000) knlGS:0000000000000000 [ 146.806866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 146.807558] CR2: ffffffffffffffe8 CR3: 000000010ecb2001 CR4: 0000000000771ee0 [ 146.808412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 146.809262] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 146.810109] PKRU: 55555554 [ 146.810460] Call Trace: [ 146.810791] ? __die_body.cold+0x1a/0x1f [ 146.811282] ? no_context.constprop.0+0xf8/0x2f0 [ 146.811854] ? exc_page_fault+0xc5/0x150 [ 146.812342] ? asm_exc_page_fault+0x1e/0x30 [ 146.812862] ? platform_shutdown+0x9/0x20 [ 146.813362] device_shutdown+0x158/0x1c0 [ 146.813853] __do_sys_reboot.cold+0x2f/0x5b [ 146.814370] ? vfs_writev+0x9b/0x110 [ 146.814824] ? do_writev+0x57/0xf0 [ 146.815254] do_syscall_64+0x30/0x40 [ 146.815708] entry_SYSCALL_64_after_hwframe+0x67/0xd1 Let me know how to further assist. -- Chuck Lever

3 months, 1 week

3
8
0 0

[PATCH v2 1/2] PCI: Forcefully set the PCI_REASSIGN_ALL_BUS flag for Marvell CN96XX/CN10XXX boards

by Bo Sun

---8<--- Changes in v2: - Added explicit comment about the quirk, as requested by Mani. - Made commit message more clear, as requested by Bjorn. ---8<--- On our Marvell OCTEON CN96XX board, we observed the following panic on the latest kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc6 #20 Hardware name: Marvell OcteonTX CN96XX board (DT) pc : of_pci_add_properties+0x278/0x4c8 Call trace: of_pci_add_properties+0x278/0x4c8 (P) of_pci_make_dev_node+0xe0/0x158 pci_bus_add_device+0x158/0x228 pci_bus_add_devices+0x40/0x98 pci_host_probe+0x94/0x118 pci_host_common_probe+0x130/0x1b0 platform_probe+0x70/0xf0 The dmesg logs indicated that the PCI bridge was scanning with an invalid bus range: pci-host-generic 878020000000.pci: PCI host bridge to bus 0002:00 pci_bus 0002:00: root bus resource [bus 00-ff] pci 0002:00:00.0: scanning [bus f9-f9] behind bridge, pass 0 pci 0002:00:01.0: scanning [bus fa-fa] behind bridge, pass 0 pci 0002:00:02.0: scanning [bus fb-fb] behind bridge, pass 0 pci 0002:00:03.0: scanning [bus fc-fc] behind bridge, pass 0 pci 0002:00:04.0: scanning [bus fd-fd] behind bridge, pass 0 pci 0002:00:05.0: scanning [bus fe-fe] behind bridge, pass 0 pci 0002:00:06.0: scanning [bus ff-ff] behind bridge, pass 0 pci 0002:00:07.0: scanning [bus 00-00] behind bridge, pass 0 pci 0002:00:07.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0002:00:08.0: scanning [bus 01-01] behind bridge, pass 0 pci 0002:00:09.0: scanning [bus 02-02] behind bridge, pass 0 pci 0002:00:0a.0: scanning [bus 03-03] behind bridge, pass 0 pci 0002:00:0b.0: scanning [bus 04-04] behind bridge, pass 0 pci 0002:00:0c.0: scanning [bus 05-05] behind bridge, pass 0 pci 0002:00:0d.0: scanning [bus 06-06] behind bridge, pass 0 pci 0002:00:0e.0: scanning [bus 07-07] behind bridge, pass 0 pci 0002:00:0f.0: scanning [bus 08-08] behind bridge, pass 0 This regression was introduced by commit 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags"). On our board, the 0002:00:07.0 bridge is misconfigured by the bootloader. Both its secondary and subordinate bus numbers are initialized to 0, while its fixed secondary bus number is set to 8. However, bus number 8 is also assigned to another bridge (0002:00:0f.0). Although this is a bootloader issue, before the change in commit 7246a4520b4b, the PCI_REASSIGN_ALL_BUS flag was set by default when PCI_PROBE_ONLY was not enabled, ensuing that all the bus number for these bridges were reassigned, avoiding any conflicts. After the change introduced in commit 7246a4520b4b, the bus numbers assigned by the bootloader are reused by all other bridges, except the misconfigured 0002:00:07.0 bridge. The kernel attempt to reconfigure 0002:00:07.0 by reusing the fixed secondary bus number 8 assigned by bootloader. However, since a pci_bus has already been allocated for bus 8 due to the probe of 0002:00:0f.0, no new pci_bus allocated for 0002:00:07.0. This results in a pci bridge device without a pci_bus attached (pdev->subordinate == NULL). Consequently, accessing pdev->subordinate in of_pci_prop_bus_range() leads to a NULL pointer dereference. To summarize, we need to set the PCI_REASSIGN_ALL_BUS flag when PCI_PROBE_ONLY is not enabled in order to work around issue like the one described above. Cc: stable(a)vger.kernel.org Fixes: 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags") Signed-off-by: Bo Sun <Bo.Sun.CN(a)windriver.com> --- drivers/pci/quirks.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 82b21e34c545..cec58c7479e1 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -6181,6 +6181,23 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1536, rom_bar_overlap_defect); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1537, rom_bar_overlap_defect); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1538, rom_bar_overlap_defect); +/* + * Quirk for Marvell CN96XX/CN10XXX boards: + * + * Adds PCI_REASSIGN_ALL_BUS unless PCI_PROBE_ONLY is set, forcing bus number + * reassignment to avoid conflicts caused by bootloader misconfigured PCI bridges. + * + * This resolves a regression introduced by commit 7246a4520b4b ("PCI: Use + * preserve_config in place of pci_flags"), which removed this behavior. + */ +static void quirk_marvell_cn96xx_cn10xxx_reassign_all_busnr(struct pci_dev *dev) +{ + if (!pci_has_flag(PCI_PROBE_ONLY)) + pci_add_flags(PCI_REASSIGN_ALL_BUS); +} +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_CAVIUM, 0xa002, + quirk_marvell_cn96xx_cn10xxx_reassign_all_busnr); + #ifdef CONFIG_PCIEASPM /* * Several Intel DG2 graphics devices advertise that they can only tolerate -- 2.48.1

3 months, 1 week

1
1
0 0

[PATCH v9] arm64: mm: Populate vmemmap at the page level if not section aligned

by Zhenhua Huang

On the arm64 platform with 4K base page config, SECTION_SIZE_BITS is set to 27, making one section 128M. The related page struct which vmemmap points to is 2M then. Commit c1cc1552616d ("arm64: MMU initialisation") optimizes the vmemmap to populate at the PMD section level which was suitable initially since hot plug granule is always one section(128M). However, commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") introduced a 2M(SUBSECTION_SIZE) hot plug granule, which disrupted the existing arm64 assumptions. The first problem is that if start or end is not aligned to a section boundary, such as when a subsection is hot added, populating the entire section is wasteful. The next problem is if we hotplug something that spans part of 128 MiB section (subsections, let's call it memblock1), and then hotplug something that spans another part of a 128 MiB section(subsections, let's call it memblock2), and subsequently unplug memblock1, vmemmap_free() will clear the entire PMD entry which also supports memblock2 even though memblock2 is still active. Assuming hotplug/unplug sizes are guaranteed to be symmetric. Do the fix similar to x86-64: populate to pages levels if start/end is not aligned with section boundary. Cc: <stable(a)vger.kernel.org> # v5.4+ Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") Acked-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Zhenhua Huang <quic_zhenhuah(a)quicinc.com> --- arch/arm64/mm/mmu.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index b4df5bc5b1b8..1dfe1a8efdbe 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -1177,8 +1177,11 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, struct vmem_altmap *altmap) { WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); + /* [start, end] should be within one section */ + WARN_ON_ONCE(end - start > PAGES_PER_SECTION * sizeof(struct page)); - if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES)) + if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES) || + (end - start < PAGES_PER_SECTION * sizeof(struct page))) return vmemmap_populate_basepages(start, end, node, altmap); else return vmemmap_populate_hugepages(start, end, node, altmap); -- 2.25.1

3 months, 1 week

4
3
0 0

[PATCH] media: ov08x40: Extend sleep after reset to 5 ms

by Hans de Goede

Some users are reporting that ov08x40_identify_module() fails to identify the chip reading 0x00 as value for OV08X40_REG_CHIP_ID. Intel's out of tree IPU6 drivers include some ov08x40 changes including adding support for the reset GPIO for older kernels and Intel's patch for this uses 5 ms. Extend the sleep to 5 ms following Intel's example, this fixes the ov08x40_identify_module() problem. Link: https://github.com/intel/ipu6-drivers/blob/c09e2198d801e1eb701984d294837312… Fixes: df1ae2251a50 ("media: ov08x40: Add OF probe support") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/media/i2c/ov08x40.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov08x40.c b/drivers/media/i2c/ov08x40.c index cf0e41fc3071..54575eea3c49 100644 --- a/drivers/media/i2c/ov08x40.c +++ b/drivers/media/i2c/ov08x40.c @@ -1341,7 +1341,7 @@ static int ov08x40_power_on(struct device *dev) } gpiod_set_value_cansleep(ov08x->reset_gpio, 0); - usleep_range(1500, 1800); + usleep_range(5000, 5500); return 0; -- 2.48.1

3 months, 1 week

2
1
0 0

Re: [PATCH] parport: Add Brainboxes XC cards.

by Cameron Williams

Cc'ing stable Cc: stable(a)vger.kernel.org On 10 March 2025 22:25:08 GMT, Cameron Williams <cang1(a)live.co.uk> wrote: >Add ExpressCard parport cards. > >Signed-off-by: Cameron Williams <cang1(a)live.co.uk> >--- > drivers/parport/parport_pc.c | 6 ++++++ > 1 file changed, 6 insertions(+) > >diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c >index f33b5d1dd..787e894bb 100644 >--- a/drivers/parport/parport_pc.c >+++ b/drivers/parport/parport_pc.c >@@ -2854,6 +2854,12 @@ static const struct pci_device_id parport_pc_pci_tbl[] = { > /* Brainboxes PX-475 */ > { PCI_VENDOR_ID_INTASHIELD, 0x401f, > PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, >+ /* Brainboxes XC-157 */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4020, >+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, >+ /* Brainboxes XC-475 */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4022, >+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, > { 0, } /* terminate list */ > }; > MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);

3 months, 1 week

2
1
0 0

Re: [PATCH] tty: serial: 8250: Add Brainboxes XC devices

by Greg KH

On Tue, Mar 11, 2025 at 06:54:00AM +0000, Cameron Williams wrote: > Cc'ing stable > > Cc: stable(a)vger.kernel.org > <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. </formletter>

3 months, 1 week

1
0
0 0

Re: [PATCH] tty: serial: 8250: Add Brainboxes XC devices

by Cameron Williams

Cc'ing stable Cc: stable(a)vger.kernel.org On 10 March 2025 22:27:10 GMT, Cameron Williams <cang1(a)live.co.uk> wrote: >These ExpressCard devices use the OxPCIE chip and can be used with >this driver. > >Signed-off-by: Cameron Williams <cang1(a)live.co.uk> >--- > drivers/tty/serial/8250/8250_pci.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > >diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c >index df4d0d832..911774fb8 100644 >--- a/drivers/tty/serial/8250/8250_pci.c >+++ b/drivers/tty/serial/8250/8250_pci.c >@@ -2727,6 +2727,22 @@ static struct pci_serial_quirk pci_serial_quirks[] = { > .init = pci_oxsemi_tornado_init, > .setup = pci_oxsemi_tornado_setup, > }, >+ { >+ .vendor = PCI_VENDOR_ID_INTASHIELD, >+ .device = 0x4026, >+ .subvendor = PCI_ANY_ID, >+ .subdevice = PCI_ANY_ID, >+ .init = pci_oxsemi_tornado_init, >+ .setup = pci_oxsemi_tornado_setup, >+ }, >+ { >+ .vendor = PCI_VENDOR_ID_INTASHIELD, >+ .device = 0x4021, >+ .subvendor = PCI_ANY_ID, >+ .subdevice = PCI_ANY_ID, >+ .init = pci_oxsemi_tornado_init, >+ .setup = pci_oxsemi_tornado_setup, >+ }, > { > .vendor = PCI_VENDOR_ID_INTEL, > .device = 0x8811, >@@ -5599,6 +5615,20 @@ static const struct pci_device_id serial_pci_tbl[] = { > PCI_ANY_ID, PCI_ANY_ID, > 0, 0, > pbn_oxsemi_1_15625000 }, >+ /* >+ * Brainboxes XC-235 >+ */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4026, >+ PCI_ANY_ID, PCI_ANY_ID, >+ 0, 0, >+ pbn_oxsemi_1_15625000 }, >+ /* >+ * Brainboxes XC-475 >+ */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4021, >+ PCI_ANY_ID, PCI_ANY_ID, >+ 0, 0, >+ pbn_oxsemi_1_15625000 }, > > /* > * Perle PCI-RAS cards

3 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025