On Wed, Nov 7, 2018 at 8:32 PM Govind Singh govinds@codeaurora.org wrote:
On 2018-11-08 03:00, Rajkumar Manoharan wrote:
On 2018-11-07 10:56, Brian Norris wrote:
This reverts commit cfb353c0dc058bc1619cc226d3cbbda1f360bdd3.
WCN3990 firmware does not yet implement this feature, and so it crashes like this:
fatal error received: err_qdi.c:456:EX:wlan_process:1:WLAN RT:207a:PC=b001b4f0
This feature can be re-implemented with a proper service bitmap or other feature-discovery mechanism in the future. But it should not break working boards.
Brian,
The change "ath10k: add quiet mode support for QCA6174/QCA9377" was merged even before full WCN3990 device support was added in ath10k. How come it could be regression for WCN3990. I know both are sharing same WMI-TLV interface but reverting this will break QCA6174/QCA9377. no?
I don't see how the revert would "break" QCA6174 -- QCA6174 worked just fine without this feature and should continue to do so.
This regression is found while we switched from 4.18 + WCN3990 back-ports to 4.19.
^^ What Govind said. WCN3990 support has been trickling in over a few releases, and it doesn't seem kosher to allow people to submit regressions in the midst of that.
I would prefer to handle this within WMI callback or upper layer.
IMO, we should use (WMI_SERVICE_THERMAL_MGMT | WMI_SERVICE_THERM_THROT ) service bitmap check and call ath10k_thermal_set_throttling only if fw supports THERMAL THROTTLE feature. But we need to ensure all available ath10k fw's are reporting this service.
And the above notes from Govind highlight this -- if the feature was not protected by the appropriate service flags, then we can't be sure that you didn't break a bunch of other firmware releases out there. Linux should not break for everyone just because you spun a firmware release.
Of course, I'll leave it up to Kalle as to how he wants to mediate this. And if you come up with a solid patch soon that can fix this without dropping the feature, then so be it.
Brian