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] [day] [month] [year] [list]
Date:   Thu, 29 Mar 2018 10:45:06 +0300
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Ramon Fried <rfried@...eaurora.org>
Cc:     loic.poulain@...aro.org, wcn36xx@...ts.infradead.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        bjorn.andersson@...aro.org
Subject: Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

(really adding Bjorn)

Ramon Fried <rfried@...eaurora.org> writes:

> (adding Bjorn Andersson)
>
>
> On 3/29/2018 10:15 AM, Kalle Valo wrote:
>> (adding devicetree list)
>>
>> Ramon Fried <rfried@...eaurora.org> writes:
>>
>>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>>> If wcn36xx digital block is associated with an external IRIS
>>> RF module, retrieve the id and disable 5GHz band in case of
>>> wcn3610 id.
>>>
>>> Signed-off-by: Ramon Fried <rfried@...eaurora.org>
>>> ---
>>> v2: fixed wrong assignment, which is logically introduces the 
>>> 	same behaviour, but for correctness.
>>>
>>>  drivers/net/wireless/ath/wcn36xx/main.c    | 4 +++-
>>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
>>> index ab5be6d2c691..833531a68c95 100644
>>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>>>  		BIT(NL80211_IFTYPE_MESH_POINT);
>>>  
>>>  	wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = &wcn_band_2ghz;
>>> -	if (wcn->rf_id != RF_IRIS_WCN3620)
>>> +	if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>>>  		wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = &wcn_band_5ghz;
>>>  
>>>  	wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
>>>  	if (iris_node) {
>>>  		if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>>>  			wcn->rf_id = RF_IRIS_WCN3620;
>>> +		else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>>> +			wcn->rf_id = RF_IRIS_WCN3610;
>>>  		of_node_put(iris_node);
>>>  	}
>> Should we document qcom,wcn3610 just like wcn3620 is:
>>
>> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt:
>> "qcom,wcn3620",
>
> IMHO the mentioned bindings is related to the PIL (peripheral image
> loaded) which is just the firmware part and has
> nothing to do with wifi frontend(IRIS).

Should we then have a bindings document for wcn36xx or is it ok to use
compatible strings like this without any docs? I'm not very familiar
with the devicetree stuff.

-- 
Kalle Valo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ