Re: [PATCH wireless-next v2 00/34] wifi: inffmac: introducing a driver for Infineon's new generation chipsets

[Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>]

On 01/14, Marek Vasut wrote:
> On 1/13/26 9:33 PM, Gokul Sivakumar wrote:
> > Infineon(Cypress) is introducing a new INFFMAC (WLAN FULLMAC) Linux driver
> > specifically for its new-generation AIROC family of Wi-Fi Connectivity
> > Processor (CP) chipsets (CYW5591x), Wi-Fi + Bluetooth combo chipsets
> > (CYW5557x, CYW5551x, CYW5591x, CYW43022), and also for all future chipsets.
> Support for the CYW55572 can be easily added into the existing brcmfmac
> driver, I already posted a patch over a year ago [1], but it was blocked
> by an off-list email.

> Frankly, I do not see any good reason why the brcmfmac driver shouldn't
> be extended when it is clearly easily doable. Adding new fork of the
> brcmfmac would only increase maintenance burden and prevent bugfixes
> from reaching the brcmfmac.
> 
> [1] https://lore.kernel.org/all/20240909203133.74777-2-marex@denx.de/

There are multiple reasons behind Infineon's proposal for this new INFFMAC
driver for its new-generation chips. Sharing a few here, and more info
is available in the v1 cover-letter [1]. For Example, the CYW5591x family
chipsets that is currently supported in this INFFMAC driver has a unique
Connected-MCU / Connectivtiy Processor (CP) Architecture [2], primarly
intended for IoT applications and it is completely different from any of
the legacy Broadcom architecture chipsets of Infineon supported currently
in upstream BRCMFMAC. The CYW5591x family chipsets has dedicated MCU Core
in addition to the WLAN core and an onboard FLASH memory for the Firmware.

And with respect to the support for the new-generation CYW5557x family of
Secure chipsets, that requires a Secure boot handshake with the Bootloader.
Even if the enumeration and firmware download support for the CYW55572 is
somehow retro-fitted into the existing upstream BRCMFMAC driver, there are
multiple other features and aspects of the Driver-Device communication that
are unique to each WLAN vendor, which are not always practically feasible
to support in the same upstream driver. Because currently BRCMFMAC driver
has a shared ownership with more than 3 WLAN vendor organizations and this
approach has its limitations. For Example, the version of the PCIe and SDIO
BUS specific shared info in Device Memory is expected same from chipsets
from all vendors. There would be a complex need to maintain vendor specifc
as well as BUS specific Shared info version, vendor specific BUS Protocol
layers, vendor specific firmware event header OUIs (currently always expects
BRCM OUI even from other vendor chips) and even more.

Confining different architecture chips from different WLAN vendors into the
same legacy BRCMFMAC driver codebase, may not be sustainable and could
potentially increase the maintainence effort and codebase complexity.
And not practically feasible to continue splitting this driver with more
vendor specific checks in the longer run. Since being different vendors,
each will only naturally diverge even more in the future with their chipset
Architecture, Driver-Device communication flow, etc. Infineon will continue
to support its legacy chipsets, already supported in the upstream BRCMFMAC.

[1] https://lore.kernel.org/linux-wireless/20250916221821.4387-1-gokulkumar.sivakumar@infineon.com/ 
[2] https://www.infineon.com/products/wireless-connectivity/airoc-connected-mcu

Gokul