Sergey Matyukevich <sergey.matyukevich.os@xxxxxxxxxxxxx> writes: >> > > > Add support for the new minor revision of QSR10g chip. Major changes from >> > > > the driver perspective include PCIe data path modifications. Setup is now >> > > > more complicated, but finally more things have been offloaded to hardware. >> > > > As a result, less driver boilerplate operations are needed after Tx/Rx >> > > > descriptors queues have been configured. Besides, restrictions on >> > > > descriptors queue lengths have been relaxed. >> > > > >> > > > Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@xxxxxxxxxxxxx> >> > > >> > > What about the firmware, is that available for this new revision? >> > >> > Hello Kalle, >> > >> > There are two drivers: pearl_qtnfmac for QSR10G and topaz_qtnfmac for >> > QSR1000. Firmware for QSR1000 chips has a higher priority since those >> > devices have been in production for quite a while now and there are >> > multiple products available. From the engineering perspective we are >> > ready to release firmware and SDK for QSR1000/QSR2000 devices. Now we >> > are waiting for the ACK from legal team. This was delayed by the >> > acquisition of Quantenna by On Semiconductor. >> > >> > As for the latest QSR10G chips, we are not yet ready to release SDK. >> > The main reason is that platform is under active development. >> >> Hello Kalle, >> >> I noticed that you marked these two patches as deferred in patchwork. >> Is there anything else I have to do here ? >> >> Regards, >> Sergey > > Hello Kalle, > > Could you please clarify your expectations regarding this functionality. > Am I correct assuming that you implicitly tie acceptance of these patches > with the promised release of firmware and SDK for QSR1000/2000 family ? Sorry for the delay, I wanted to check the qtnfmac firmware status before responding. And it didn't look good. The wiki page[1] mentions nothing about the firmware, neither does Kconfig and even a quick google search didn't make me any wiser. So I have no clue what's the current situation with the firmware. I don't like this at all. All upstream drivers are supposed to be used by _anyone_ and the firmware should be publically available, with a very strong preference having the firmware in linux-firmware repo. I made an exception with qtnfmac and didn't require it to be in linux-firmware, IIRC the reason being there were some problems with the firmware license (something related to GPL?). Upstream drivers need to have the firmware available. If Quantenna does not want to release the firmware I'm not willing to accept patches to new hardware either. I will accept patches for hardware already in upstream, but any patches adding new hardware support will be automatically rejected until the firmware issue is resolved. [1] https://wireless.wiki.kernel.org/en/users/drivers/qtnfmac -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
