tree 69cd1a89abf938f2225e592a2b30ade56b81e254
parent 36d159b91cdd7215cbba0ed63846a6873765b2de
author Krishna Rao <kcrao@codeaurora.org> 1484224502 +0530
committer qcabuildsw <qcabuildsw@localhost> 1486560734 -0800

qcacmn: Add WMI Host PHY mode values for 11ax

Add WMI_HOST_WLAN_PHY_MODE enum values for 802.11ax. These values
correspond to the WLAN_PHY_MODE enum values defined in the host-FW
interface.

Note that the new values for WMI_HOST_MODE_UNKNOWN and
WMI_HOST_MODE_MAX will not necessarily correspond to the MODE_UNKNOWN*
and MODE_MAX*/PHY_MODE_MAX* values in FW header files for all
chipsets/architecture families. This is because:
1) The 'unknown' PHY mode should not be used in host-FW interactions.
2) WMI_HOST_MODE_MAX is not currently used for host-FW interactions.
3) MODE_MAX*/PHY_MODE_MAX* values in FW header files can have varying
   values at compile time depending on compile flags such as
   SUPPORT_11AX, which in turn depend on the chipset/architecture
   family.  However the WMI_HOST_WLAN_PHY_MODE enum is exposed to
   chipset/arch independent higher layers within host which utilize WMI
   layer services. Hence WMI_HOST_WLAN_PHY_MODE enum values should not
   vary.

In case the max mode value needs to be used in host-FW interaction in
the future for some reason, this should be translated separately by
the arch dependent (and if ever required, chipset dependent) WMI layer
code into the enum value directly exposed by the relevant FW header
file version for that arch/chipset. Similarly, if the arch/chipset
dependent max mode value needs to be used in-within host code in the
future for some reason, a separate variable should be dynamically
populated by the WMI layer at attach time.

Later, it might also be preferable to convert even other
WMI_HOST_WLAN_PHY_MODE enum values into values directly exposed by FW
header files in the manner noted above.

Testing:
Tested basic AP bring-up on M2M Platform with 11ACVHT80 and 11AHE20

Change-Id: I64c7a1d7491d2213c740568c3e9e2f035c82746e
CRs-Fixed: 1106923