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