From: Ben Greear <greearb@candelatech.com>
To: ath10k <ath10k@lists.infradead.org>
Subject: Per radio configuration
Date: Thu, 4 Feb 2016 13:04:48 -0800 [thread overview]
Message-ID: <56B3BCF0.7070408@candelatech.com> (raw)
Hello!
I'm considering a case where I have multiple ath10k NICs in
a system, possibly not all the same chipset.
I may want to have one optimized for smaller number of vdevs and more
peers, and another many vdevs, fewer peers, etc. Some chipsets
Module options are not optimal for this since there is no easy way to
have different options for different NICs.
I'm thinking about making a loadable 'firmware' file that has
text-based config, something like:
# First radio
Device=05:00.0
vdev_count=8
peer_count=128
firmware_name=firmware-5-b.bin
firmware_ver=5
# Second radio
Device=06:00.0
vdev_count=4
peer_count=200
firmware_name=firmware-2.bin
firmware_ver=2
# End of file
When parsing, Lines starting with # would be ignored.
Any un-known tokens would be ignored, for backwards/forwards compatibility.
This file would be loaded and parsed before loading other firmware images
so that we can use particular firmware images per radio. This further lets one
optimize one radio for one thing, one for another. For instance, if someone
requires IBSS and wants to use stock QCA firmware, they can use the 'main' firmware
for that radio, and the most recent one for another radio that needs to be a stable AP.
In addition to this, we would need to store the vdev combinations
in RAM in the 'ar' struct, so we could get rid of all of the static,
hard-coded members and set the capabilities to match the requested
values.
Any opinions on this? Something that might be worthwhile for upstream?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next reply other threads:[~2016-02-04 21:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 21:04 Ben Greear [this message]
2016-03-03 15:35 ` Per radio configuration Valo, Kalle
2016-03-03 16:41 ` Ben Greear
2016-03-03 17:39 ` Valo, Kalle
[not found] ` <CAGyitvNf8ZvrZnQfmNimeJvWcTmAtZLwQ-qae62SB9iQEwXQzQ@mail.gmail.com>
2016-03-03 19:36 ` Valo, Kalle
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=56B3BCF0.7070408@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.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