From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org,
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
Avinash Patil <avinashp@quantenna.com>
Subject: Re: [PATCH 02/10] qtnfmac: pass complete channel data between driver and firmware
Date: Mon, 15 Jan 2018 12:56:47 +0300 [thread overview]
Message-ID: <20180115095646.wvx4ekoqkvvapiyn@bars> (raw)
In-Reply-To: <876087s4lz.fsf@kamboji.qca.qualcomm.com>
Hello Kalle,
> >> > +/**
> >> > * struct qlink_chandef - qlink channel definition
> >> > *
> >> > + * @chan: primary channel definition
> >> > * @center_freq1: center frequency of first segment
> >> > * @center_freq2: center frequency of second segment (80+80 only)
> >> > * @width: channel width, one of @enum qlink_channel_width
> >> > */
> >> > struct qlink_chandef {
> >> > + struct qlink_channel chan;
> >> > __le16 center_freq1;
> >> > __le16 center_freq2;
> >> > u8 width;
> >> > - u8 rsvd[3];
> >> > + u8 rsvd;
> >> > } __packed;
> >>
> >> Doesn't this break backwards compatibility with the older firmware? The
> >> basic princinple is that old firmware images continue to work with newer
> >> driver (or there will be a firmware image with new name, eg. fw-2.bin).
> >> You can check how iwlwifi does that.
> >
> > Yes, it breaks. That is why we increment qlink protocol version in each
> > change affecting backwards compatibility. So driver is going to work only
> > with matching firmware. This is a very simplistic approach, but it looks
> > reasonable for current stage of development since we keep adding features.
>
> Everyone are always adding new features, that's no excuse to break
> backwards compatibility with user space. In the future you really need
> to come up a way to handle the firmware interface breaks gracefully,
> just like iwlwifi does.
>
> Related to this, any progress on getting the firmware image to
> linux-firmware?
Here is a brief status. In our case, one of the SoC cores runs Linux, so we
have to accompany firmware image with SDK containing all the GPL components.
SDK is not appropriate for linux-firmware repository. That is why the plan
is to make SDK accessible via Quantenna github or website, and then
to get the firmware image to linux-firmware repository. Actually, firmware
image can be submitted any time. But our understanding is that SDK should be
released prior to the next attempt to submit firmware image. So currently
the work is ongoing on making SDK fully GPL compliant, e.g. sorting out
licensing of 3rd party modules.
Regards,
Sergey
next prev parent reply other threads:[~2018-01-15 9:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 10:28 [PATCH 0/10] qtnfmac: regular portion of features and fixes Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 01/10] qtnfmac: check that MAC exists in regulatory notifier Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 02/10] qtnfmac: pass complete channel data between driver and firmware Sergey Matyukevich
2017-12-04 14:46 ` Kalle Valo
2017-12-05 16:24 ` Sergey Matyukevich
2018-01-12 11:23 ` Kalle Valo
2018-01-15 9:56 ` Sergey Matyukevich [this message]
2017-11-13 10:28 ` [PATCH 03/10] qtnfmac: add support for radar detection and CAC Sergey Matyukevich
2017-12-04 14:49 ` Kalle Valo
2017-12-04 14:52 ` Kalle Valo
2017-12-05 16:27 ` Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 04/10] qtnfmac: change default interface mode from AP to STA Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 05/10] qtnfmac: check for passed channel being NULL in MGMT_TX command Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 06/10] qtnfmac: fix rssi data passed to wireless core Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 07/10] qtnfmac: fill wiphy's extended capabilities Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 08/10] qtnfmac: modify GET_STA_STATS cmd format for back/forward compatibility Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 09/10] qtnfmac: keeping track of "generation" for STA info Sergey Matyukevich
2017-11-13 10:28 ` [PATCH 10/10] qtnfmac: support MAC address based access control Sergey Matyukevich
2017-12-04 15:01 ` Kalle Valo
2017-12-05 16:00 ` Sergey Matyukevich
2017-12-18 12:43 ` Sergey Matyukevich
2017-12-18 14:01 ` Kalle Valo
2017-12-18 16:18 ` Sergey Matyukevich
2017-12-19 9:38 ` Johannes Berg
2017-12-19 10:29 ` Sergey Matyukevich
2017-12-19 10:35 ` Johannes Berg
2017-12-19 10:42 ` Sergey Matyukevich
2017-12-19 10:59 ` Johannes Berg
2017-12-19 11:19 ` Sergey Matyukevich
2017-12-19 12:37 ` Arend van Spriel
2017-12-19 16:58 ` Johannes Berg
2017-12-19 22:13 ` Arend Van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180115095646.wvx4ekoqkvvapiyn@bars \
--to=sergey.matyukevich.os@quantenna.com \
--cc=avinashp@quantenna.com \
--cc=igor.mitsyanko.os@quantenna.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).