Hi Francesco, Thank you for your review comments and sorry for the delay. > > > +#define FIRMWARE_W8987 "nxp/uartuart8987_bt.bin" > > +#define FIRMWARE_W8997 "nxp/uartuart8997_bt_v4.bin" > > +#define FIRMWARE_W9098 "nxp/uartuart9098_bt_v1.bin" > > +#define FIRMWARE_IW416 "nxp/uartiw416_bt_v0.bin" > > +#define FIRMWARE_IW612 "nxp/uartspi_n61x_v1.bin.se" > > Where are this files coming from? Where can I download those? > Is loading a combo firmware from the mwifiex driver supported? We are working on submitting these files to linux-firmware. They will be available under nxp/ directory once merged. > > > +#define HCI_NXP_PRI_BAUDRATE 115200 > > +#define HCI_NXP_SEC_BAUDRATE 3000000 > > What if the UART device does not support 3000000 baudrate (think at > limitation on the clock source/divider of the UART)? Shouldn't this be > configurable? We have noted this requirement and decided to design and implement on this in upcoming patches along with other new features. We have a number of customers out there who have been using these chips as well as the legacy Marvell chips, which need FW download at 3000000 baudrate, and so far there were no issues reported. Using a lower standard baudrate affects the time it takes to download the FW, which we are trying to keep strictly under 5 seconds. > > > +#define NXP_V1_FW_REQ_PKT 0xa5 > > +#define NXP_V1_CHIP_VER_PKT 0xaa > > +#define NXP_V3_FW_REQ_PKT 0xa7 > > +#define NXP_V3_CHIP_VER_PKT 0xab > > + > > +#define NXP_ACK_V1 0x5a > > +#define NXP_NAK_V1 0xbf > > +#define NXP_ACK_V3 0x7a > > +#define NXP_NAK_V3 0x7b > > +#define NXP_CRC_ERROR_V3 0x7c > > I assume this was already discussed, but the *_V1 looks just like the existing > Marvell protocol, is it really worth a new driver? I did not check all the details > here, so maybe the answer is just yes. > The 88w8897 was a legacy Marvell chipset, while the newer chipsets we are trying to add here are branded under "NXP". Most of the newer chipset download FW using V3 protocol and few of them use V1 protocol, which is still different from the V1 protocol seen for 8897 chip. Initially we tried to add support for NXP chipsets in hci line-discipline, but Marcel Holtmann advised us to implement this standalone driver based on serdev. Hope this helps! Thanks, Neeraj
