lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b1a64bd66fa25f274af8c018c6fc02f4@codeaurora.org>
Date:   Thu, 08 Nov 2018 10:01:51 +0530
From:   Govind Singh <govinds@...eaurora.org>
To:     Rajkumar Manoharan <rmanohar@...eaurora.org>
Cc:     Brian Norris <briannorris@...omium.org>,
        ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        linux-kernel@...r.kernel.org, Yu Wang <yyuwang@...eaurora.org>,
        Rakesh Pillai <pillair@...eaurora.org>, stable@...r.kernel.org,
        linux-wireless-owner@...r.kernel.org
Subject: Re: [PATCH REGRESSION] Revert "ath10k: add quiet mode support for
 QCA6174/QCA9377"

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

This regression is found while we switched from 4.18 + WCN3990 
back-ports to 4.19.

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

> -Rajkumar

BR,
Govind

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ