From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Ben Greear <greearb@candelatech.com>
Cc: ath10k@lists.infradead.org, Matti Laakso <malaakso@elisanet.fi>
Subject: Re: fetching calibration data from flash
Date: Mon, 16 Jun 2014 15:24:48 +0300 [thread overview]
Message-ID: <87ioo111pr.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <53985C61.5000201@candelatech.com> (Ben Greear's message of "Wed, 11 Jun 2014 06:40:49 -0700")
Ben Greear <greearb@candelatech.com> writes:
> On 06/11/2014 01:38 AM, Kalle Valo wrote:
>> Ben Greear <greearb@candelatech.com> writes:
>>
>>> Another nice feature would be to allow configuring the number of
>>> vdevs, peers, etc per NIC. That way, you could have one NIC
>>> tuned to be one big AP with lots of peers, and a second could
>>> be several small APs with fewer peers and some stations, etc.
>>>
>>> Maybe this could be a separate file, or maybe it would be worth
>>> adding this to a TLV type file with cal.bin being part of the
>>> data?
>>
>> So basically you want a configuration (".ini") file for ath10k, right? I
>> have seen those in out-of-tree drivers, but not in upstream drivers.
>>
>> If I'm guessing right what these configuration items would do in ath10k,
>> I think instead of static configuration it would be much more flexible
>> to have this stuff configurable dynamically. But how, that's the
>> question. A sysfs file to set different profiles (or modes) was the
>> first one which came to my mind, but that's ugly.
>
> You also need this info before you do the initial firmware configuration,
> otherwise you are going to have to restart firmware again later to apply
> the new config (and advertise different interface combinations up the
> stack, etc).
Ok.
> Maybe a kernel module option to point to a file-name would work
> (with some way to give different options to different nics in the
> same system).
Over years I have seen these .ini suggestions few times and I never have
been very fund of the idea. For example, that would mean yet another
layer of configuration and more things to support. I would prefer to
find a more automatic way of doing the same.
And I'm not sure if kernel maintainers would even accept this.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2014-06-16 12:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 7:55 fetching calibration data from flash Sven Schnelle
2014-06-10 8:28 ` Kalle Valo
2014-06-10 8:32 ` Sven Schnelle
2014-06-10 8:36 ` Matti Laakso
2014-06-10 8:54 ` Kalle Valo
2014-06-10 8:59 ` Matti Laakso
2014-06-10 9:03 ` Kalle Valo
2014-06-10 15:56 ` Ben Greear
2014-06-11 8:38 ` Kalle Valo
2014-06-11 13:40 ` Ben Greear
2014-06-16 12:24 ` Kalle Valo [this message]
2014-06-16 14:53 ` Ben Greear
2014-06-16 15:28 ` Kalle Valo
2014-06-16 15:58 ` Ben Greear
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=87ioo111pr.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@qca.qualcomm.com \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--cc=malaakso@elisanet.fi \
/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