From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Ben Greear <greearb@candelatech.com>
Cc: ath10k@lists.infradead.org
Subject: Re: WMI version handling
Date: Fri, 5 Sep 2014 16:23:08 +0300 [thread overview]
Message-ID: <871trqgq0z.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <54072D19.7010809@candelatech.com> (Ben Greear's message of "Wed, 3 Sep 2014 08:00:41 -0700")
Ben Greear <greearb@candelatech.com> writes:
>> Also I have been thinking that using firmware feature bits (for example
>> ATH10K_FW_FEATURE_WMI_10_2 and ATH10K_FW_FEATURE_WMI_10X) for WMI
>> version is not the best way. I think it's easier to manage all this if
>> we have a u32 FW IE to provide WMI version. IIRC Ben was suggesting this
>> at some point.
>>
>> Example:
>>
>> enum ath10k_fw_wmi_version {
>> ATH10K_FW_WMI_VERSION_MAIN = 0,
>> ATH10K_FW_WMI_VERSION_10_1 = 1,
>> ATH10K_FW_WMI_VERSION_10_2 = 2,
>> }
>>
>> And then wmi.c would set correct interface based on this version.
>
> I am happy with the current flags, it seems to work well enough.
Yeah, there's no problem at the moment. But if we start adding more
interfaces handling them through feature flags will become more
difficult. That's why I think adding a separate enum will be better in
the long run.
> I'd leave policy out of the IEs as much as possible, as normal users
> cannot modify it, and certainly it would be a problem if you wanted
> different policy with different NICs in same system. IEs should
> describe the minimum needed for the ath10k to enforce policy as best
> as it can.
The firmware IEs are not about policy. They are about advertising the
capabilities of the firmware image so that ath10k can know how to
configure the firmare.
> We have to assume that users tweaking station and peer count can deal
> with fw crashes until they get the settings right.
No way. In no circumstances ath10k should configure firmware out of
bounds. If we do that, it's a bug in ath10k.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2014-09-05 13:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-05 17:58 [PATCH] ath10k: Support 32+ stations greearb
2014-09-03 6:14 ` WMI version handling Kalle Valo
2014-09-03 15:00 ` Ben Greear
2014-09-04 6:56 ` Michal Kazior
2014-09-04 14:04 ` Ben Greear
2014-09-05 13:32 ` Kalle Valo
2014-09-05 13:23 ` Kalle Valo [this message]
2014-09-05 15:46 ` 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=871trqgq0z.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@qca.qualcomm.com \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
/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