DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF1DF20657
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 2BAAA6019F
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
In-Reply-To: <20181015194636.7ydshvuo2ykqyp3d@bars> (Sergey Matyukevich's
        message of "Mon, 15 Oct 2018 19:46:44 +0000")
References: <20181008095551.18651-1-sergey.matyukevich.os@quantenna.com>
        <20181008095551.18651-6-sergey.matyukevich.os@quantenna.com>
        <87murioxft.fsf@purkki.adurom.net>
        <20181015194636.7ydshvuo2ykqyp3d@bars>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Date:   Mon, 29 Oct 2018 16:56:25 +0200
Message-ID: <87k1m0er8m.fsf@qca.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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