Re: [PATCH 2/2] qtnfmac: add support for the new revision of QSR10g chip

From: Kalle Valo <kvalo@codeaurora.org>
To: "linux-wireless\@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
	Mikhail Karpenko <mkarpenko@quantenna.com>
Subject: Re: [PATCH 2/2] qtnfmac: add support for the new revision of QSR10g chip
Date: Wed, 11 Nov 2020 11:04:19 +0200	[thread overview]
Message-ID: <874klwb6y4.fsf@codeaurora.org> (raw)
In-Reply-To: <20200424101707.nbkojo74vaucq55z@bars> (Sergey Matyukevich's message of "Fri, 24 Apr 2020 13:17:08 +0300")

Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> 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@quantenna.com>
>> > > 
>> > > 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