From: Kalle Valo <kvalo@codeaurora.org>
To: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Cc: "linux-wireless\@vger.kernel.org"
<linux-wireless@vger.kernel.org>,
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
Andrey Shevchenko <ashevchenko@quantenna.com>
Subject: Re: [PATCH 5/5] qtnfmac: add support for Topaz chipsets
Date: Mon, 29 Oct 2018 16:56:25 +0200 [thread overview]
Message-ID: <87k1m0er8m.fsf@qca.qualcomm.com> (raw)
In-Reply-To: <20181015194636.7ydshvuo2ykqyp3d@bars> (Sergey Matyukevich's message of "Mon, 15 Oct 2018 19:46:44 +0000")
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:
>> > +config QTNFMAC_TOPAZ_PCIE
>> > + tristate "Quantenna QSR1000/QSR2000 PCIe support"
>> > + default n
>> > + depends on PCI && CFG80211
>> > + select QTNFMAC
>> > + select FW_LOADER
>> > + select CRC32
>> > + help
>> > + This option adds support for wireless adapters based on Quantenna
>> > + 802.11ac QSR1000/QSR2000 (aka Topaz) FullMAC chipset
>> > + running over PCIe.
>> > +
>> > + If you choose to build it as a module, two modules will be built:
>> > + qtnfmac.ko and qtnfmac_pcie.ko.
>
>> I'm not really fond of adding a Kconfig option for every supported
>> hardware version unless there are very good reasons (memory savings
>> etc). So is this really needed?
>
> Yes, the idea was to save some memory building pcie backend for
> the requested chip family only.
>
>> A much better approach would be to have a generic QTNFMAC_PCIE option
>> which can be used to include or exclude all PCI code.
>
> Ok, sounds reasonable. Three Kconfig options for the single qtnfmac_pcie
> module is way too much. We will drop chipset specific Kconfig knobs in
> v2, keeping single Kconfig option for qtnfmac_pcie backend as a whole.
Great, thanks.
--
Kalle Valo
prev parent reply other threads:[~2018-10-29 14:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-08 9:55 [PATCH 0/5] qtnfmac: add support for QSR1000/QSR2000 (aka Topaz) chipsets Sergey Matyukevich
2018-10-08 9:56 ` [PATCH 1/5] qtnfmac: use 'help' in Kconfig Sergey Matyukevich
2018-10-13 17:05 ` Kalle Valo
2018-10-08 9:56 ` [PATCH 2/5] qtnfmac: use SPDX identifier for pcie bus layer files Sergey Matyukevich
2018-10-08 9:56 ` [PATCH 3/5] qtnfmac_pcie: cleanup Pearl platform headers Sergey Matyukevich
2018-10-08 9:56 ` [PATCH 4/5] qtnfmac_pcie: use single PCIe driver for all platforms Sergey Matyukevich
2018-10-08 9:56 ` [PATCH 5/5] qtnfmac: add support for Topaz chipsets Sergey Matyukevich
2018-10-08 11:36 ` Kalle Valo
2018-10-08 13:36 ` Sergey Matyukevich
2018-10-13 12:14 ` Kalle Valo
2018-10-15 19:46 ` Sergey Matyukevich
2018-10-29 14:56 ` Kalle Valo [this message]
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=87k1m0er8m.fsf@qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=ashevchenko@quantenna.com \
--cc=igor.mitsyanko.os@quantenna.com \
--cc=linux-wireless@vger.kernel.org \
--cc=sergey.matyukevich.os@quantenna.com \
/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).