All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
To: Kalle Valo <kvalo@codeaurora.org>
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, 15 Oct 2018 19:46:44 +0000	[thread overview]
Message-ID: <20181015194636.7ydshvuo2ykqyp3d@bars> (raw)
In-Reply-To: <87murioxft.fsf@purkki.adurom.net>

> > +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.

Thanks,
Sergey

  reply	other threads:[~2018-10-15 19:46 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 [this message]
2018-10-29 14:56       ` Kalle Valo

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=20181015194636.7ydshvuo2ykqyp3d@bars \
    --to=sergey.matyukevich.os@quantenna.com \
    --cc=ashevchenko@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.