On May 28, 2026, NVD published CVE-2026-46148 for a Linux kernel fix in the Microchip coreQSPI SPI controller driver, after kernel.org reported that the controller’s built-in chip select could be asserted while Linux was communicating with another SPI device. The bug is narrow, hardware-specific, and still awaiting NVD enrichment, but it is a useful reminder that embedded Linux failures often arrive not as dramatic memory corruption, but as one badly timed electrical assumption. This is a vulnerability about trust at the boundary between software policy and hardware automation. And for administrators responsible for appliances, industrial systems, or Linux-based edge devices, that boundary is where “just a driver fix” can become a fleet-management problem.
CVE-2026-46148 is not the kind of Linux kernel vulnerability that will dominate general-purpose server patch dashboards. It does not currently come with an NVD CVSS score, a polished exploit chain, or the usual panic language around privilege escalation. The affected code lives in the
That specificity is exactly why it matters. Embedded Linux is full of these sharply scoped defects: a controller behaves one way, a board designer wires devices another way, and the driver quietly encodes an assumption that holds until a product ships in a configuration the original test bench did not exercise. The result is not necessarily a remote shell. It may be a bus collision, a misaddressed peripheral, a corrupted transaction, or a system whose security model depends on hardware isolation that was not quite as isolated as everyone believed.
The kernel fix changes how the driver handles the controller’s built-in chip select. Previously, the hardware could automatically drive that chip select low when transmission began and high when the programmed byte count completed. That sounds convenient until a board has multiple devices on the same SPI controller and Linux is trying to access a GPIO-selected device while the built-in chip select is also being pulled active.
In other words, this is a bug born from automation. The hardware did what it was designed to do. The driver allowed that behavior to persist in a context where it was no longer safe.
The Microchip coreQSPI controller, according to the kernel description, supports only a single built-in chip select. Additional devices must use GPIO lines for their chip selects. That creates a mixed-control environment: one device may be governed by the controller’s native chip-select behavior, while others are selected through ordinary GPIOs under software control.
The reported failure was that when two devices were attached to the controller, the built-in chip select could be driven low while Linux was attempting to access a device attached to a GPIO chip select. That is the critical sentence. If two peripherals are effectively selected during one transaction, the bus is no longer a clean one-to-one conversation.
This does not automatically mean data disclosure in every affected design. The actual impact depends on what devices are attached, how they interpret bus traffic, whether they are read-only or writable, and whether any sensitive component shares the controller. But the class of failure is serious because chip select is not merely a convenience signal. In multi-device SPI designs, it is the line that says who is allowed to participate.
The CVE’s significance is therefore less about a universal Linux emergency and more about a failure mode that system designers recognize immediately. If a flash device, sensor, secure element, radio, FPGA, or board-management component is on the wrong side of an unintended transaction, consequences can range from harmless noise to state corruption.
The problem is that Linux’s SPI framework has to model more than the easiest board. It has to support devices with active-low and active-high chip selects, devices that use GPIOs, and devices that require transfers while chip select is disabled. The CVE description notes that the built-in chip select, when left to automatic control, is active low and inactive high. That rules out certain devices and complicates others.
The patch moves control back into the driver. For memory operations, the driver retains the behavior of keeping chip select active for the duration of the operation. For regular transfers, it implements a
There is a philosophical point here that shows up again and again in kernel work. Hardware shortcuts are only safe when the operating system can reason about them. If a controller autonomously manipulates a line that the kernel treats as part of device selection, the driver has to make that behavior explicit or turn it off.
That is a familiar embedded story. The designs most likely to expose a bug were not the ones in routine testing. Engineers had already routed around the awkward hardware behavior by using GPIO chip selects everywhere, so the mixed built-in-plus-GPIO configuration escaped attention. The driver still supported the dangerous arrangement, but the common boards did not stress it.
This is one reason kernel CVEs can look strange to administrators accustomed to browser, VPN, or Windows remote-code-execution advisories. In embedded Linux, vulnerability discovery is often a byproduct of expanding hardware coverage. Someone builds a board that combines peripherals differently, reuses an IP block in a new context, or enables a device-tree configuration that was theoretically valid but practically untested.
That also means risk is uneven. A data-center Linux server almost certainly does not care about this bug. A Microchip FPGA-based system, RISC-V development board, industrial controller, custom appliance, or vendor product using this QSPI controller might care very much. The hard part for IT is that such components often sit inside products labeled by a vendor’s brand, not by the kernel driver that makes them work.
For this CVE, scoring is genuinely non-trivial. The bug is not a straightforward “local attacker gets root” flaw. It is a hardware interaction defect whose severity depends on the board topology and the devices sharing the SPI controller. If the second selected device is inert, unused, or tolerant of stray traffic, impact may be limited. If it is writable flash, a configuration device, or a peripheral involved in trust decisions, the impact could be much more interesting.
This is where vulnerability management tools often perform badly. They prefer package names, version ranges, and severity numbers. Embedded risk needs a bill of materials, a board schematic, a kernel configuration, a device tree, and an understanding of which peripherals share buses.
The practical message is not to treat CVE-2026-46148 as a five-alarm incident. It is to avoid treating an unscored CVE as invisible. For organizations managing Linux appliances or custom hardware, the right response is targeted inventory, not generalized panic.
This is the second embedded lesson in the patch. A driver that reconfigures controller state per device can create subtle cross-device hazards when several peripherals share the same bus. What looks like ordinary setup code for one device can be disruptive if another device depends on stable controller behavior.
The patch also moves settings for
Finally, the new setup callback sets the built-in chip select to its inactive state for active-low devices, because the reset value in software-controlled mode is low. That detail is wonderfully mundane and exactly the sort of thing that matters in real hardware. A “safe” software-controlled mode is not safe if the line begins in the asserted state.
CVE-2026-46148 is especially relevant to organizations with Microchip-based embedded products or custom Linux hardware. The driver name points to a specific controller family, not a broad class of PCs. That should narrow the search, but it does not eliminate the work.
The vulnerable population is likely to be vendor-specific. Some products will never use the affected driver. Some will include the driver but not use the risky hardware configuration. Some will use only GPIO chip selects and effectively avoid the triggering scenario. Others may combine the built-in chip select with GPIO-selected devices and therefore match the problem described in the CVE.
This is where the traditional “apply the latest kernel” advice becomes too blunt. Many embedded systems do not track mainline kernels quickly, and vendor kernels may carry years of backports and board-specific patches. The more realistic question is whether the vendor has imported the relevant stable kernel fix, whether the deployed firmware includes it, and whether the affected hardware configuration exists in the product at all.
CVE-2026-46148 is a good example of the tension. On one hand, it is highly specific and probably irrelevant to most general-purpose Linux deployments. On the other hand, it describes a condition where one device’s bus transaction may unintentionally assert another device’s chip-select line. In a hardware security context, that is not cosmetic.
The kernel community often fixes these problems in the language of correctness. The CVE system then recasts them in the language of vulnerability management. Both framings are partly right. A bus-selection bug is a correctness bug; if it crosses isolation boundaries or corrupts sensitive state, it is also a security bug.
Administrators should resist two opposite mistakes. The first is assuming every kernel CVE is immediately exploitable at scale. The second is assuming obscure driver CVEs are mere noise. The useful middle position is to ask whether the affected subsystem exists in your environment and whether the described failure mode maps to a real asset.
If user-controlled software can trigger access to one SPI device, and the built-in chip select for another device is asserted at the same time, the attacker may be able to influence what the unintended device sees. Whether that matters depends on protocol framing and device behavior. Some devices ignore malformed commands. Others may interpret a prefix of the transaction as a valid command. Still others may latch state in ways that only become visible after reboot or during a later operation.
This is why shared buses are security-sensitive. They are economical and common, but they depend on clean arbitration. The operating system may present devices as separate abstractions, yet electrically they are neighbors on the same wires.
For secure boot chains and trusted hardware designs, this kind of bug is particularly uncomfortable. Many embedded systems rely on SPI or QSPI flash for boot firmware or configuration data. If the affected controller participates in those paths, the difference between “wrong chip selected” and “wrong data written” is a matter of device-specific behavior, not a comfort blanket.
That is where CVE-2026-46148 fits. It is not a client OS emergency. It is a reminder that vulnerability programs built only around desktops, servers, and cloud workloads miss the embedded layer. The inventory problem is harder because the affected component may be buried beneath a vendor SKU.
The practical workflow begins with vendor exposure. If you operate appliances or custom hardware using Microchip FPGA or SoC platforms, ask whether the product uses the
For organizations building their own Linux images, the path is more direct. Identify kernels containing the affected driver, check whether the relevant stable commits have been applied, and verify the device-tree chip-select configuration. The test case is not simply whether the kernel boots. It is whether transfers to GPIO-selected devices leave the built-in chip select inactive unless the built-in-selected device is intentionally in use.
The fix effectively reasserts software ownership. The driver now explicitly controls the built-in chip select and integrates that control with the SPI core’s expectations. It also avoids unsafe clock-idle changes during operation and moves stable controller initialization to probe.
These are modest changes, but modest changes are often what mature kernel engineering looks like. Nobody is redesigning the bus. Nobody is adding a large security subsystem. The patch aligns driver behavior with the reality of multi-device hardware.
That alignment matters because embedded deployments tend to last. A board design can remain in products for a decade. A kernel fork can linger for years. A small driver assumption, once shipped into the field, can become part of the operational baseline of factories, utilities, retail systems, medical peripherals, and networking appliances.
Kernel.org stable references indicate that fixes have landed in stable branches, but organizations rarely consume kernel.org directly on appliances. They consume vendor firmware. That introduces familiar questions: Which product lines are affected? Which firmware trains include the fix? Are end-of-support devices abandoned? Is the same driver present in a vendor’s long-term support kernel under a modified patch set?
The validation burden is also different from a conventional software patch. A driver change that alters chip-select handling must be tested against actual hardware. It should improve correctness, but embedded vendors still need to verify timing, polarity, memory operations, and regular SPI transfers across supported boards.
That is not an argument against patching. It is an argument for treating firmware updates as part of security operations rather than as occasional maintenance chores. The slower the firmware pipeline, the more important it is to know which devices actually sit in the blast radius.
A sensible response looks like this:
The Small CVE That Says Something Larger About Embedded Linux
CVE-2026-46148 is not the kind of Linux kernel vulnerability that will dominate general-purpose server patch dashboards. It does not currently come with an NVD CVSS score, a polished exploit chain, or the usual panic language around privilege escalation. The affected code lives in the spi: microchip-core-qspi driver, which supports Microchip’s coreQSPI controller hardware.That specificity is exactly why it matters. Embedded Linux is full of these sharply scoped defects: a controller behaves one way, a board designer wires devices another way, and the driver quietly encodes an assumption that holds until a product ships in a configuration the original test bench did not exercise. The result is not necessarily a remote shell. It may be a bus collision, a misaddressed peripheral, a corrupted transaction, or a system whose security model depends on hardware isolation that was not quite as isolated as everyone believed.
The kernel fix changes how the driver handles the controller’s built-in chip select. Previously, the hardware could automatically drive that chip select low when transmission began and high when the programmed byte count completed. That sounds convenient until a board has multiple devices on the same SPI controller and Linux is trying to access a GPIO-selected device while the built-in chip select is also being pulled active.
In other words, this is a bug born from automation. The hardware did what it was designed to do. The driver allowed that behavior to persist in a context where it was no longer safe.
A Chip-Select Line Became a Security Boundary
SPI is simple enough in concept that its risks are easy to underestimate. A controller talks to one or more peripherals over shared signal lines, and chip-select signals determine which device is meant to listen. If the wrong chip select is asserted, the wrong device may see traffic it was never meant to see.The Microchip coreQSPI controller, according to the kernel description, supports only a single built-in chip select. Additional devices must use GPIO lines for their chip selects. That creates a mixed-control environment: one device may be governed by the controller’s native chip-select behavior, while others are selected through ordinary GPIOs under software control.
The reported failure was that when two devices were attached to the controller, the built-in chip select could be driven low while Linux was attempting to access a device attached to a GPIO chip select. That is the critical sentence. If two peripherals are effectively selected during one transaction, the bus is no longer a clean one-to-one conversation.
This does not automatically mean data disclosure in every affected design. The actual impact depends on what devices are attached, how they interpret bus traffic, whether they are read-only or writable, and whether any sensitive component shares the controller. But the class of failure is serious because chip select is not merely a convenience signal. In multi-device SPI designs, it is the line that says who is allowed to participate.
The CVE’s significance is therefore less about a universal Linux emergency and more about a failure mode that system designers recognize immediately. If a flash device, sensor, secure element, radio, FPGA, or board-management component is on the wrong side of an unintended transaction, consequences can range from harmless noise to state corruption.
The Driver Assumed Hardware Automation Was Harmless
The vulnerable behavior grew out of a hardware feature that appears reasonable in isolation. The coreQSPI IP can automatically operate its built-in chip select: drive it active when data is written to the transmit buffer, then return it inactive after the number of bytes in the transfer frame has been sent. For a single-device bus, this is exactly the sort of assist that keeps software simpler.The problem is that Linux’s SPI framework has to model more than the easiest board. It has to support devices with active-low and active-high chip selects, devices that use GPIOs, and devices that require transfers while chip select is disabled. The CVE description notes that the built-in chip select, when left to automatic control, is active low and inactive high. That rules out certain devices and complicates others.
The patch moves control back into the driver. For memory operations, the driver retains the behavior of keeping chip select active for the duration of the operation. For regular transfers, it implements a
set_cs callback so the SPI core can tell the controller when the line should change state. The effect is not glamorous, but it is important: Linux stops letting the hardware make an implicit selection decision at the exact moment the bus is supposed to be under coordinated software control.There is a philosophical point here that shows up again and again in kernel work. Hardware shortcuts are only safe when the operating system can reason about them. If a controller autonomously manipulates a line that the kernel treats as part of device selection, the driver has to make that behavior explicit or turn it off.
The Bug Hid Because Real Boards Avoided the Dangerous Combination
The most revealing detail in the CVE text is not the register-level fix. It is the explanation for why the issue went unnoticed. Boards that connected multiple devices to the SPI controller reportedly used GPIOs for chip selects exclusively, rather than relying on the built-in chip select at all.That is a familiar embedded story. The designs most likely to expose a bug were not the ones in routine testing. Engineers had already routed around the awkward hardware behavior by using GPIO chip selects everywhere, so the mixed built-in-plus-GPIO configuration escaped attention. The driver still supported the dangerous arrangement, but the common boards did not stress it.
This is one reason kernel CVEs can look strange to administrators accustomed to browser, VPN, or Windows remote-code-execution advisories. In embedded Linux, vulnerability discovery is often a byproduct of expanding hardware coverage. Someone builds a board that combines peripherals differently, reuses an IP block in a new context, or enables a device-tree configuration that was theoretically valid but practically untested.
That also means risk is uneven. A data-center Linux server almost certainly does not care about this bug. A Microchip FPGA-based system, RISC-V development board, industrial controller, custom appliance, or vendor product using this QSPI controller might care very much. The hard part for IT is that such components often sit inside products labeled by a vendor’s brand, not by the kernel driver that makes them work.
NVD’s Empty Score Is Not the Same as No Risk
As of publication, NVD lists CVE-2026-46148 as awaiting enrichment, with no CVSS 4.0, 3.x, or 2.0 vector assigned by NIST. That absence should not be read as a safety rating. It means the public vulnerability record has not yet been fully analyzed and scored by NVD.For this CVE, scoring is genuinely non-trivial. The bug is not a straightforward “local attacker gets root” flaw. It is a hardware interaction defect whose severity depends on the board topology and the devices sharing the SPI controller. If the second selected device is inert, unused, or tolerant of stray traffic, impact may be limited. If it is writable flash, a configuration device, or a peripheral involved in trust decisions, the impact could be much more interesting.
This is where vulnerability management tools often perform badly. They prefer package names, version ranges, and severity numbers. Embedded risk needs a bill of materials, a board schematic, a kernel configuration, a device tree, and an understanding of which peripherals share buses.
The practical message is not to treat CVE-2026-46148 as a five-alarm incident. It is to avoid treating an unscored CVE as invisible. For organizations managing Linux appliances or custom hardware, the right response is targeted inventory, not generalized panic.
The Fix Removes More Than One Unsafe Assumption
The kernel change does more than manually control chip select. The CVE description also notes that the old setup callback,mchp_coreqspi_setup_op(), is removed. That matters because the removed setup path modified the CLKIDLE field, and the fix text says doing so during operation is not safe when multiple devices are present.This is the second embedded lesson in the patch. A driver that reconfigures controller state per device can create subtle cross-device hazards when several peripherals share the same bus. What looks like ordinary setup code for one device can be disruptive if another device depends on stable controller behavior.
The patch also moves settings for
MASTER and ENABLE to probe time, because they do not need to be repeated for each device. That is housekeeping, but it is security-relevant housekeeping. Less repeated mutable state means fewer chances for one device’s setup path to perturb another device’s transaction.Finally, the new setup callback sets the built-in chip select to its inactive state for active-low devices, because the reset value in software-controlled mode is low. That detail is wonderfully mundane and exactly the sort of thing that matters in real hardware. A “safe” software-controlled mode is not safe if the line begins in the asserted state.
This Is a Supply-Chain Patch, Not a Desktop Patch Tuesday Moment
For WindowsForum readers, the Linux angle may appear distant until you remember how often Linux hides inside infrastructure that Windows shops depend on. Storage appliances, network gear, security cameras, industrial gateways, lab equipment, hyperconverged boxes, and management controllers frequently run vendor-customized Linux builds. The administrator may never log into a shell, but the kernel is still there.CVE-2026-46148 is especially relevant to organizations with Microchip-based embedded products or custom Linux hardware. The driver name points to a specific controller family, not a broad class of PCs. That should narrow the search, but it does not eliminate the work.
The vulnerable population is likely to be vendor-specific. Some products will never use the affected driver. Some will include the driver but not use the risky hardware configuration. Some will use only GPIO chip selects and effectively avoid the triggering scenario. Others may combine the built-in chip select with GPIO-selected devices and therefore match the problem described in the CVE.
This is where the traditional “apply the latest kernel” advice becomes too blunt. Many embedded systems do not track mainline kernels quickly, and vendor kernels may carry years of backports and board-specific patches. The more realistic question is whether the vendor has imported the relevant stable kernel fix, whether the deployed firmware includes it, and whether the affected hardware configuration exists in the product at all.
Kernel CVEs Are Becoming a Language for Bug-Fix Accountability
The Linux kernel project’s CVE practice has changed the way these defects surface. More kernel bug fixes are now visible as CVEs, including many that do not look like classic security vulnerabilities to non-kernel readers. That can be frustrating for vulnerability teams, but it also forces a useful conversation about impact.CVE-2026-46148 is a good example of the tension. On one hand, it is highly specific and probably irrelevant to most general-purpose Linux deployments. On the other hand, it describes a condition where one device’s bus transaction may unintentionally assert another device’s chip-select line. In a hardware security context, that is not cosmetic.
The kernel community often fixes these problems in the language of correctness. The CVE system then recasts them in the language of vulnerability management. Both framings are partly right. A bus-selection bug is a correctness bug; if it crosses isolation boundaries or corrupts sensitive state, it is also a security bug.
Administrators should resist two opposite mistakes. The first is assuming every kernel CVE is immediately exploitable at scale. The second is assuming obscure driver CVEs are mere noise. The useful middle position is to ask whether the affected subsystem exists in your environment and whether the described failure mode maps to a real asset.
The Threat Model Lives on the Circuit Board
The interesting question for CVE-2026-46148 is not “Can an attacker exploit Linux?” in the abstract. It is “Can an attacker cause transactions on this SPI bus, and what else is on that bus?” That moves the analysis from CVSS dashboards to hardware architecture.If user-controlled software can trigger access to one SPI device, and the built-in chip select for another device is asserted at the same time, the attacker may be able to influence what the unintended device sees. Whether that matters depends on protocol framing and device behavior. Some devices ignore malformed commands. Others may interpret a prefix of the transaction as a valid command. Still others may latch state in ways that only become visible after reboot or during a later operation.
This is why shared buses are security-sensitive. They are economical and common, but they depend on clean arbitration. The operating system may present devices as separate abstractions, yet electrically they are neighbors on the same wires.
For secure boot chains and trusted hardware designs, this kind of bug is particularly uncomfortable. Many embedded systems rely on SPI or QSPI flash for boot firmware or configuration data. If the affected controller participates in those paths, the difference between “wrong chip selected” and “wrong data written” is a matter of device-specific behavior, not a comfort blanket.
The Windows Angle Is Operational, Not Ideological
Windows administrators do not need to become Linux SPI driver specialists. They do need to recognize that modern Windows environments depend on non-Windows systems at every layer. The update console may run on Windows, the help desk may support Windows endpoints, and the identity stack may be Microsoft-heavy, but the network path, security appliance, storage target, or OT gateway in the middle may be Linux-based.That is where CVE-2026-46148 fits. It is not a client OS emergency. It is a reminder that vulnerability programs built only around desktops, servers, and cloud workloads miss the embedded layer. The inventory problem is harder because the affected component may be buried beneath a vendor SKU.
The practical workflow begins with vendor exposure. If you operate appliances or custom hardware using Microchip FPGA or SoC platforms, ask whether the product uses the
microchip-core-qspi driver and whether multiple SPI devices share the controller with mixed built-in and GPIO chip selects. If the answer is yes or unknown, ask for the firmware version containing the upstream stable fix.For organizations building their own Linux images, the path is more direct. Identify kernels containing the affected driver, check whether the relevant stable commits have been applied, and verify the device-tree chip-select configuration. The test case is not simply whether the kernel boots. It is whether transfers to GPIO-selected devices leave the built-in chip select inactive unless the built-in-selected device is intentionally in use.
The Real Patch Is Discipline Around Shared Hardware
There is a broader engineering moral here. Shared hardware resources need a single coherent owner. If the SPI core believes it is controlling selection through callbacks, but the controller hardware is also making automatic decisions, the model has split in two. That split is where bugs live.The fix effectively reasserts software ownership. The driver now explicitly controls the built-in chip select and integrates that control with the SPI core’s expectations. It also avoids unsafe clock-idle changes during operation and moves stable controller initialization to probe.
These are modest changes, but modest changes are often what mature kernel engineering looks like. Nobody is redesigning the bus. Nobody is adding a large security subsystem. The patch aligns driver behavior with the reality of multi-device hardware.
That alignment matters because embedded deployments tend to last. A board design can remain in products for a decade. A kernel fork can linger for years. A small driver assumption, once shipped into the field, can become part of the operational baseline of factories, utilities, retail systems, medical peripherals, and networking appliances.
The Firmware Pipeline Is Where This CVE Will Be Won or Lost
The public CVE record is only the first stage. The next stages are backporting, vendor firmware integration, validation, and deployment. For embedded Linux, those stages are often slower and less transparent than administrators would like.Kernel.org stable references indicate that fixes have landed in stable branches, but organizations rarely consume kernel.org directly on appliances. They consume vendor firmware. That introduces familiar questions: Which product lines are affected? Which firmware trains include the fix? Are end-of-support devices abandoned? Is the same driver present in a vendor’s long-term support kernel under a modified patch set?
The validation burden is also different from a conventional software patch. A driver change that alters chip-select handling must be tested against actual hardware. It should improve correctness, but embedded vendors still need to verify timing, polarity, memory operations, and regular SPI transfers across supported boards.
That is not an argument against patching. It is an argument for treating firmware updates as part of security operations rather than as occasional maintenance chores. The slower the firmware pipeline, the more important it is to know which devices actually sit in the blast radius.
The Narrow Advisory That Rewards Precise Inventory
The value of CVE-2026-46148 lies in its precision. It tells defenders exactly where to look: Linux kernels with the Microchip coreQSPI driver, hardware using the affected controller, and configurations where the built-in chip select can coexist with GPIO-selected devices. That is not a broad net, but it is a clear one.A sensible response looks like this:
- Organizations should not treat CVE-2026-46148 as a general Linux server emergency unless they know the affected Microchip QSPI hardware is present.
- Embedded and appliance teams should check whether their kernels include the
microchip-core-qspidriver and whether their board designs mix the built-in chip select with GPIO chip selects. - Vendors shipping Microchip-based Linux products should document whether their firmware contains the stable kernel fix and which product versions are affected.
- Security teams should avoid relying on the missing NVD score as evidence of low impact, because the real severity depends on the devices sharing the SPI bus.
- Test plans should verify chip-select behavior electrically or through hardware-aware diagnostics, not merely confirm that the patched kernel boots.
- Long-lived devices without clear firmware support deserve special scrutiny, because embedded driver fixes often arrive upstream long before they arrive in fielded products.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:02:32-07:00
NVD - CVE-2026-46148
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:02:32-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH v2 1/3] spi: microchip-core-qspi: control built-in cs manually — Linux Kernel
Linux Kernel: [PATCH v2 1/3] spi: microchip-core-qspi: control built-in cs manually
www.spinics.net
- Related coverage: lore-kernel.gnuweeb.org
- Related coverage: codebrowser.dev
spi-microchip-core-qspi.c source code [linux/drivers/spi/spi-microchip-core-qspi.c] - Codebrowser
Source code of linux/drivers/spi/spi-microchip-core-qspi.c linux v6.19-r on KDAB Codebrowser
codebrowser.dev
