* Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: Scott Wood @ 2016-08-02 19:57 UTC (permalink / raw)
To: arvind Yadav, Arnd Bergmann, linuxppc-dev@lists.ozlabs.org
Cc: qiang.zhao@freescale.com, viresh.kumar@linaro.org,
zajec5@gmail.com, linux-wireless@vger.kernel.org,
David.Laight@aculab.com, netdev@vger.kernel.org,
scottwood@freescale.com, akpm@linux-foundation.org,
davem@davemloft.net, linux@roeck-us.net, Li Yang
In-Reply-To: <57A0BD8E.9050305@gmail.com>
On 08/02/2016 10:34 AM, arvind Yadav wrote:
>
>
> On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:
>> On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
>>> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
>>>>> diff --git a/include/linux/err.h b/include/linux/err.h
>>>>> index 1e35588..c2a2789 100644
>>>>> --- a/include/linux/err.h
>>>>> +++ b/include/linux/err.h
>>>>> @@ -18,7 +18,17 @@
>>>>>
>>>>> #ifndef __ASSEMBLY__
>>>>>
>>>>> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
>>>>> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
>>>>> +
>>>>> +static inline int is_error_check(unsigned long error)
>>>> Please leave the existing macro alone. I think you were looking for
>>>> something specific to the return code of qe_muram_alloc() function,
>>>> so please add a helper in that subsystem if you need it, not in
>>>> the generic header files.
>>> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long. The
>>> problem is certain callers that store the return value in a u32. Why
>>> not just fix those callers to store it in unsigned long (at least until
>>> error checking is done)?
>>>
>> Yes, that would also address another problem with code like
>>
>> kfree((void *)ugeth->tx_bd_ring_offset[i]);
>>
>> which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
>> that also holds the return value of qe_muram_alloc.
Well, hopefully it doesn't hold a return of qe_muram_alloc() when it's
being passed to kfree()...
There's also the code that casts kmalloc()'s return to u32, etc.
ucc_geth is not 64-bit clean in general.
>>
>> Arnd
> Yes, we will fix caller. Caller api is not safe on 64bit.
The API is fine (or at least, I haven't seen a valid issue pointed out
yet). The problem is the ucc_geth driver.
> Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
> but it should be unsigned long.
cpm_muram_addr takes unsigned long as a parameter, not that it matters
since you can't pass errors into it and a muram offset should never
exceed 32 bits.
-Scott
^ permalink raw reply
* [PATCH 1/1 v2] rtlwifi: remove superfluous condition
From: Heinrich Schuchardt @ 2016-08-02 19:26 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Heinrich Schuchardt
In-Reply-To: <4e6de16f-b42c-920a-60a2-fcc88e282dc0@lwfinger.net>
If sta == NULL, the changed line will not be reached.
So no need to check that sta != NULL here.
v2:
fix typo
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index 41f77f8..7aee5ebb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1135,7 +1135,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
mac->mode = WIRELESS_MODE_AC_24G;
}
- if (vif->type == NL80211_IFTYPE_STATION && sta)
+ if (vif->type == NL80211_IFTYPE_STATION)
rtlpriv->cfg->ops->update_rate_tbl(hw, sta, 0);
rcu_read_unlock();
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 0768/1285] Replace numeric parameter like 0444 with macro
From: Arend van Spriel @ 2016-08-02 18:34 UTC (permalink / raw)
To: Kalle Valo, Baole Ni; +Cc: linux-wireless
In-Reply-To: <87k2fz5a9c.fsf@kamboji.qca.qualcomm.com>
On 02-08-16 19:52, Kalle Valo wrote:
> (Trimming CC)
>
> Baole Ni <baolex.ni@intel.com> writes:
>
>> I find that the developers often just specified the numeric value
>> when calling a macro which is defined with a parameter for access permission.
>> As we know, these numeric value for access permission have had the corresponding macro,
>> and that using macro can improve the robustness and readability of the code,
>> thus, I suggest replacing the numeric parameter with the macro.
>>
>> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
>> Signed-off-by: Baole Ni <baolex.ni@intel.com>
>> ---
>> drivers/net/wireless/ath/wcn36xx/main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Over 1000 patches? It's totally inapproriate to spam people's inboxes
> (including mine) like this. PLEASE first study how kernel development
> works and then start with something small, not like this.
>
> I'm dropping all patches from this patchset.
And this type of change has been tried before and burned by Linus as
everybody with a bit of *nix background knows the meaning of the
numerical access permissions.
Regards,
Arend
^ permalink raw reply
* [PATCH] Staging: rtl8723au: rtw_xmit: Fixed operators spacing style issues
From: Shiva Kerdel @ 2016-08-02 18:05 UTC (permalink / raw)
To: Larry.Finger
Cc: Jes.Sorensen, gregkh, geliangtang, linux-wireless, devel,
linux-kernel, Shiva Kerdel
Fixed spaces around operators to fix their coding style issues.
Signed-off-by: Shiva Kerdel <shiva@exdev.nl>
---
drivers/staging/rtl8723au/core/rtw_xmit.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_xmit.c b/drivers/staging/rtl8723au/core/rtw_xmit.c
index 3de40cf..56228a5 100644
--- a/drivers/staging/rtl8723au/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723au/core/rtw_xmit.c
@@ -174,7 +174,7 @@ int _rtw_init_xmit_priv23a(struct xmit_priv *pxmitpriv,
rtw_alloc_hwxmits23a(padapter);
rtw_init_hwxmits23a(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
- for (i = 0; i < 4; i ++)
+ for (i = 0; i < 4; i++)
pxmitpriv->wmm_para_seq[i] = i;
sema_init(&pxmitpriv->tx_retevt, 0);
@@ -421,7 +421,7 @@ static int update_attrib(struct rtw_adapter *padapter,
struct security_priv *psecuritypriv = &padapter->securitypriv;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
int res = _SUCCESS;
- struct ethhdr *ehdr = (struct ethhdr *) skb->data;
+ struct ethhdr *ehdr = (struct ethhdr *)skb->data;
pattrib->ether_type = ntohs(ehdr->h_proto);
@@ -640,7 +640,7 @@ static int xmitframe_addmic(struct rtw_adapter *padapter,
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
int curfragnum, length;
u8 *pframe, *payload, mic[8];
- u8 priority[4]= {0x0, 0x0, 0x0, 0x0};
+ u8 priority[4] = {0x0, 0x0, 0x0, 0x0};
u8 hw_hdr_offset = 0;
int bmcst = is_multicast_ether_addr(pattrib->ra);
@@ -667,10 +667,10 @@ static int xmitframe_addmic(struct rtw_adapter *padapter,
if (pattrib->encrypt == WLAN_CIPHER_SUITE_TKIP) {
/* encode mic code */
if (stainfo) {
- u8 null_key[16]={0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0};
+ u8 null_key[16] = {0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0,
+ 0x0, 0x0, 0x0, 0x0};
pframe = pxmitframe->buf_addr + hw_hdr_offset;
@@ -961,11 +961,11 @@ static int rtw_make_wlanhdr(struct rtw_adapter *padapter, u8 *hdr,
/* DBG_8723A("tx ampdu seqnum(%d) < tx_seq(%d)\n", pattrib->seqnum, tx_seq); */
pattrib->ampdu_en = false;/* AGG BK */
} else if (SN_EQUAL(pattrib->seqnum, tx_seq)) {
- psta->BA_starting_seqctrl[pattrib->priority & 0x0f] = (tx_seq+1)&0xfff;
+ psta->BA_starting_seqctrl[pattrib->priority & 0x0f] = (tx_seq + 1)&0xfff;
pattrib->ampdu_en = true;/* AGG EN */
} else {
/* DBG_8723A("tx ampdu over run\n"); */
- psta->BA_starting_seqctrl[pattrib->priority & 0x0f] = (pattrib->seqnum+1)&0xfff;
+ psta->BA_starting_seqctrl[pattrib->priority & 0x0f] = (pattrib->seqnum + 1)&0xfff;
pattrib->ampdu_en = true;/* AGG EN */
}
}
@@ -1164,8 +1164,8 @@ int rtw_xmitframe_coalesce23a(struct rtw_adapter *padapter, struct sk_buff *skb,
RT_TRACE(_module_rtl871x_xmit_c_, _drv_notice_,
"rtw_xmiaframe_coalesce23a: keyid =%d pattrib->iv[3]=%.2x pframe =%.2x %.2x %.2x %.2x\n",
padapter->securitypriv.dot11PrivacyKeyIndex,
- pattrib->iv[3], *pframe, *(pframe+1),
- *(pframe+2), *(pframe+3));
+ pattrib->iv[3], *pframe, *(pframe + 1),
+ *(pframe + 2), *(pframe + 3));
pframe += pattrib->iv_len;
mpdu_len -= pattrib->iv_len;
}
@@ -1190,7 +1190,7 @@ int rtw_xmitframe_coalesce23a(struct rtw_adapter *padapter, struct sk_buff *skb,
pdata += mem_sz;
data_len -= mem_sz;
- if ((pattrib->icv_len >0) && (pattrib->bswenc)) {
+ if ((pattrib->icv_len > 0) && (pattrib->bswenc)) {
memcpy(pframe, pattrib->icv, pattrib->icv_len);
pframe += pattrib->icv_len;
}
--
2.9.2
^ permalink raw reply related
* Re: [PATCH] Staging: rtl8723au: rtw_xmit: fixed coding style issues
From: Jes Sorensen @ 2016-08-02 18:03 UTC (permalink / raw)
To: Shiva Kerdel
Cc: Larry.Finger, gregkh, geliangtang, linux-wireless, devel,
linux-kernel
In-Reply-To: <20160802175721.2453-1-shiva@exdev.nl>
Shiva Kerdel <shiva@exdev.nl> writes:
> Fixed some coding style issues that were detected as errors.
>
> Signed-off-by: Shiva Kerdel <shiva@exdev.nl>
You have already been told this once by Greg. Describe what you are
fixing in the commit message, and don't fix more than one type of bug
per commit.
Jes
> ---
> drivers/staging/rtl8723au/core/rtw_xmit.c | 26 ++++++++++----------------
> 1 file changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/core/rtw_xmit.c b/drivers/staging/rtl8723au/core/rtw_xmit.c
> index 3de40cf..4ea7c5f 100644
> --- a/drivers/staging/rtl8723au/core/rtw_xmit.c
> +++ b/drivers/staging/rtl8723au/core/rtw_xmit.c
> @@ -174,7 +174,7 @@ int _rtw_init_xmit_priv23a(struct xmit_priv *pxmitpriv,
> rtw_alloc_hwxmits23a(padapter);
> rtw_init_hwxmits23a(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
>
> - for (i = 0; i < 4; i ++)
> + for (i = 0; i < 4; i++)
> pxmitpriv->wmm_para_seq[i] = i;
>
> sema_init(&pxmitpriv->tx_retevt, 0);
> @@ -640,7 +640,7 @@ static int xmitframe_addmic(struct rtw_adapter *padapter,
> struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
> int curfragnum, length;
> u8 *pframe, *payload, mic[8];
> - u8 priority[4]= {0x0, 0x0, 0x0, 0x0};
> + u8 priority[4] = {0x0, 0x0, 0x0, 0x0};
> u8 hw_hdr_offset = 0;
> int bmcst = is_multicast_ether_addr(pattrib->ra);
>
> @@ -667,10 +667,10 @@ static int xmitframe_addmic(struct rtw_adapter *padapter,
> if (pattrib->encrypt == WLAN_CIPHER_SUITE_TKIP) {
> /* encode mic code */
> if (stainfo) {
> - u8 null_key[16]={0x0, 0x0, 0x0, 0x0,
> - 0x0, 0x0, 0x0, 0x0,
> - 0x0, 0x0, 0x0, 0x0,
> - 0x0, 0x0, 0x0, 0x0};
> + u8 null_key[16] = {0x0, 0x0, 0x0, 0x0,
> + 0x0, 0x0, 0x0, 0x0,
> + 0x0, 0x0, 0x0, 0x0,
> + 0x0, 0x0, 0x0, 0x0};
>
> pframe = pxmitframe->buf_addr + hw_hdr_offset;
>
> @@ -902,8 +902,7 @@ static int rtw_make_wlanhdr(struct rtw_adapter *padapter, u8 *hdr,
>
> if (psta->qos_option)
> qos_option = true;
> - }
> - else {
> + } else {
> RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_,
> "fw_state:%x is not allowed to xmit frame\n",
> get_fwstate(pmlmepriv));
> @@ -1190,7 +1189,7 @@ int rtw_xmitframe_coalesce23a(struct rtw_adapter *padapter, struct sk_buff *skb,
> pdata += mem_sz;
> data_len -= mem_sz;
>
> - if ((pattrib->icv_len >0) && (pattrib->bswenc)) {
> + if ((pattrib->icv_len > 0) && (pattrib->bswenc)) {
> memcpy(pframe, pattrib->icv, pattrib->icv_len);
> pframe += pattrib->icv_len;
> }
> @@ -1766,7 +1765,6 @@ void rtw_alloc_hwxmits23a(struct rtw_adapter *padapter)
> hwxmits[4] .sta_queue = &pxmitpriv->be_pending;
>
> } else if (pxmitpriv->hwxmit_entry == 4) {
> -
> /* pxmitpriv->vo_txqueue.head = 0; */
> /* hwxmits[0] .phwtxqueue = &pxmitpriv->vo_txqueue; */
> hwxmits[0] .sta_queue = &pxmitpriv->vo_pending;
> @@ -1952,18 +1950,16 @@ int xmitframe_enqueue_for_sleeping_sta23a(struct rtw_adapter *padapter, struct x
> /* spin_unlock_bh(&psta->sleep_q.lock); */
>
> ret = true;
> -
> }
>
> spin_unlock_bh(&psta->sleep_q.lock);
>
> return ret;
> -
> }
>
> spin_lock_bh(&psta->sleep_q.lock);
>
> - if (psta->state&WIFI_SLEEP_STATE) {
> + if (psta->state & WIFI_SLEEP_STATE) {
> u8 wmmps_ac = 0;
>
> if (pstapriv->sta_dz_bitmap & CHKBIT(psta->aid)) {
> @@ -2017,9 +2013,7 @@ int xmitframe_enqueue_for_sleeping_sta23a(struct rtw_adapter *padapter, struct x
> /* */
>
> ret = true;
> -
> }
> -
> }
>
> spin_unlock_bh(&psta->sleep_q.lock);
> @@ -2159,7 +2153,7 @@ void wakeup_sta_to_xmit23a(struct rtw_adapter *padapter, struct sta_info *psta)
> /* update BCN for TIM IE */
> update_mask = BIT(0);
>
> - if (psta->state&WIFI_SLEEP_STATE)
> + if (psta->state & WIFI_SLEEP_STATE)
> psta->state ^= WIFI_SLEEP_STATE;
>
> if (psta->state & WIFI_STA_ALIVE_CHK_STATE) {
^ permalink raw reply
* Re: [PATCH 0768/1285] Replace numeric parameter like 0444 with macro
From: Kalle Valo @ 2016-08-02 17:52 UTC (permalink / raw)
To: Baole Ni; +Cc: linux-wireless
In-Reply-To: <20160802114428.860-1-baolex.ni@intel.com>
(Trimming CC)
Baole Ni <baolex.ni@intel.com> writes:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the corresponding macro,
> and that using macro can improve the robustness and readability of the code,
> thus, I suggest replacing the numeric parameter with the macro.
>
> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> Signed-off-by: Baole Ni <baolex.ni@intel.com>
> ---
> drivers/net/wireless/ath/wcn36xx/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Over 1000 patches? It's totally inapproriate to spam people's inboxes
(including mine) like this. PLEASE first study how kernel development
works and then start with something small, not like this.
I'm dropping all patches from this patchset.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0786/1285] Replace numeric parameter like 0444 with macro
From: Shanker Wang @ 2016-08-02 15:50 UTC (permalink / raw)
To: Baole Ni
Cc: kvalo, luciano.coelho, linuxwifi, m.chehab, pawel, m.szyprowski,
kyungmin.park, k.kozlowski, libertas-dev, linux-wireless, netdev,
LKML, chuansheng.liu
In-Reply-To: <20160802114618.2152-1-baolex.ni@intel.com>
I don’t think macros is clearer, and the meaning of those so called
“magic numbers” like 0644 is clear enough. People are used to that.
As a result, it is not meaningful to replace them with macro.
> 在 2016年8月2日，19:46，Baole Ni <baolex.ni@intel.com> 写道：
>
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the corresponding macro,
> and that using macro can improve the robustness and readability of the code,
> thus, I suggest replacing the numeric parameter with the macro.
>
> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> Signed-off-by: Baole Ni <baolex.ni@intel.com>
> ---
> drivers/net/wireless/marvell/libertas/mesh.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c b/drivers/net/wireless/marvell/libertas/mesh.c
> index d0c881d..ae4f0a5 100644
> --- a/drivers/net/wireless/marvell/libertas/mesh.c
> +++ b/drivers/net/wireless/marvell/libertas/mesh.c
> @@ -297,19 +297,19 @@ static ssize_t lbs_mesh_set(struct device *dev,
> * lbs_mesh attribute to be exported per ethX interface
> * through sysfs (/sys/class/net/ethX/lbs_mesh)
> */
> -static DEVICE_ATTR(lbs_mesh, 0644, lbs_mesh_get, lbs_mesh_set);
> +static DEVICE_ATTR(lbs_mesh, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, lbs_mesh_get, lbs_mesh_set);
>
> /*
> * anycast_mask attribute to be exported per mshX interface
> * through sysfs (/sys/class/net/mshX/anycast_mask)
> */
> -static DEVICE_ATTR(anycast_mask, 0644, lbs_anycast_get, lbs_anycast_set);
> +static DEVICE_ATTR(anycast_mask, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, lbs_anycast_get, lbs_anycast_set);
>
> /*
> * prb_rsp_limit attribute to be exported per mshX interface
> * through sysfs (/sys/class/net/mshX/prb_rsp_limit)
> */
> -static DEVICE_ATTR(prb_rsp_limit, 0644, lbs_prb_rsp_limit_get,
> +static DEVICE_ATTR(prb_rsp_limit, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, lbs_prb_rsp_limit_get,
> lbs_prb_rsp_limit_set);
>
> static struct attribute *lbs_mesh_sysfs_entries[] = {
> @@ -764,13 +764,13 @@ static ssize_t capability_set(struct device *dev, struct device_attribute *attr,
> }
>
>
> -static DEVICE_ATTR(bootflag, 0644, bootflag_get, bootflag_set);
> -static DEVICE_ATTR(boottime, 0644, boottime_get, boottime_set);
> -static DEVICE_ATTR(channel, 0644, channel_get, channel_set);
> -static DEVICE_ATTR(mesh_id, 0644, mesh_id_get, mesh_id_set);
> -static DEVICE_ATTR(protocol_id, 0644, protocol_id_get, protocol_id_set);
> -static DEVICE_ATTR(metric_id, 0644, metric_id_get, metric_id_set);
> -static DEVICE_ATTR(capability, 0644, capability_get, capability_set);
> +static DEVICE_ATTR(bootflag, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, bootflag_get, bootflag_set);
> +static DEVICE_ATTR(boottime, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, boottime_get, boottime_set);
> +static DEVICE_ATTR(channel, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, channel_get, channel_set);
> +static DEVICE_ATTR(mesh_id, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, mesh_id_get, mesh_id_set);
> +static DEVICE_ATTR(protocol_id, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, protocol_id_get, protocol_id_set);
> +static DEVICE_ATTR(metric_id, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, metric_id_get, metric_id_set);
> +static DEVICE_ATTR(capability, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, capability_get, capability_set);
>
> static struct attribute *boot_opts_attrs[] = {
> &dev_attr_bootflag.attr,
> --
> 2.9.2
>
^ permalink raw reply
* Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: arvind Yadav @ 2016-08-02 15:48 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
Cc: Scott Wood, qiang.zhao@freescale.com, viresh.kumar@linaro.org,
zajec5@gmail.com, linux-wireless@vger.kernel.org,
David.Laight@aculab.com, netdev@vger.kernel.org,
scottwood@freescale.com, akpm@linux-foundation.org,
davem@davemloft.net, linux@roeck-us.net
In-Reply-To: <2484583.95xFmO7xir@wuerfel>
On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:
> On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
>> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
>>>> diff --git a/include/linux/err.h b/include/linux/err.h
>>>> index 1e35588..c2a2789 100644
>>>> --- a/include/linux/err.h
>>>> +++ b/include/linux/err.h
>>>> @@ -18,7 +18,17 @@
>>>>
>>>> #ifndef __ASSEMBLY__
>>>>
>>>> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
>>>> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
>>>> +
>>>> +static inline int is_error_check(unsigned long error)
>>> Please leave the existing macro alone. I think you were looking for
>>> something specific to the return code of qe_muram_alloc() function,
>>> so please add a helper in that subsystem if you need it, not in
>>> the generic header files.
>> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long. The
>> problem is certain callers that store the return value in a u32. Why
>> not just fix those callers to store it in unsigned long (at least until
>> error checking is done)?
>>
> Yes, that would also address another problem with code like
>
> kfree((void *)ugeth->tx_bd_ring_offset[i]);
>
> which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
> that also holds the return value of qe_muram_alloc.
>
> Arnd
Yes, we will fix caller. Caller api is not safe on 64bit.
Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
but it should be unsigned long. Need to work on it.
Arvind
^ permalink raw reply
* Wireless Workshop accepted into the 2016 Linux Kernel Summit and Linux Plumbers Conference
From: Jake Edge @ 2016-08-02 14:45 UTC (permalink / raw)
To: lpc-announce; +Cc: linux-wireless
It might well be that wireless networking recently made the transition
from an ubiquitous networking technology to the dominant networking
technology, at least from the viewpoint of end-user devices. Part of
this trend is the use of wireless in automobiles, and this workshop
will look at Wireless Access in Vehicular Environments (WAVE),
also know as IEEE 802.11p. In addition, the bufferbloat problem [1]
is starting to focus on the more difficult wireless environment, and to
that end, this workshop will discuss FQ/Codel [2] integration, testing,
and development. As usual, the workshop will encompass the full 802.11
stack, not just the kernel portions, and therefore wpa_supplicant [3]
will also be on the agenda.
Please join us for a timely and important discussion [4]!
KS [5] will be held October 31-November 1 and LPC [6] will be held
November 1-4, both in Santa Fe, New Mexico, US.
[1] https://en.wikipedia.org/wiki/Bufferbloat
[2] https://en.wikipedia.org/wiki/CoDel
[3] https://w1.fi/wpa_supplicant/
[4] http://wiki.linuxplumbersconf.org/2016:wireless
[5] https://events.linuxfoundation.org/events/linux-kernel-summit
[6] http://www.linuxplumbersconf.org/2016/
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Luis R. Rodriguez @ 2016-08-02 14:16 UTC (permalink / raw)
To: Valo, Kalle
Cc: Luis R. Rodriguez, Stanislaw Gruszka, Prarit Bhargava,
Arend Van Spriel, Greg Kroah-Hartman, Ming Lei, linux-wireless,
ath10k, mmarek@suse.com, michal.kazior@tieto.com,
Arend van Spriel, Emmanuel Grumbach
In-Reply-To: <874m738m02.fsf@kamboji.qca.qualcomm.com>
On Tue, Aug 02, 2016 at 11:10:22AM +0000, Valo, Kalle wrote:
> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>
> > I was considering this as a future extension to the firmware API
> > through the new extensible firmware API, the sysdata API.
>
> I think Linus mentioned this already, but I want to reiterate anyway.
> The name "sysdata" is horrible, I didn't have any idea what it means
> until I read your description. Please continue to use the term
> "firmware", anyone already know what it means.
We've gone well past using the firmware API for firmware though, if
we use it for 802.11 to replace CRDA for instance its really odd to
be calling it firmware. But sure... I will rebrand again to firmware...
Luis
^ permalink raw reply
* [PATCH 1113/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 12:17 UTC (permalink / raw)
To: johannes, davem, jmorris, yoshfuji, kaber, m.szyprowski,
kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni,
aarcange, aryabinin
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
net/mac80211/rate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 206698b..43bd119 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -25,7 +25,7 @@ static LIST_HEAD(rate_ctrl_algs);
static DEFINE_MUTEX(rate_ctrl_mutex);
static char *ieee80211_default_rc_algo = CONFIG_MAC80211_RC_DEFAULT;
-module_param(ieee80211_default_rc_algo, charp, 0644);
+module_param(ieee80211_default_rc_algo, charp, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(ieee80211_default_rc_algo,
"Default rate control algorithm for mac80211 to use");
--
2.9.2
^ permalink raw reply related
* [PATCH 1142/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 12:20 UTC (permalink / raw)
To: johannes, davem, linux-wimax, anna.schumaker, kadlec,
m.szyprowski, kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni,
arnd, aryabinin
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
net/wireless/reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..1435e1b 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -261,7 +261,7 @@ static const struct ieee80211_regdomain *cfg80211_world_regdom =
static char *ieee80211_regdom = "00";
static char user_alpha2[2];
-module_param(ieee80211_regdom, charp, 0444);
+module_param(ieee80211_regdom, charp, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(ieee80211_regdom, "IEEE 802.11 regulatory domain code");
static void reg_free_request(struct regulatory_request *request)
--
2.9.2
^ permalink raw reply related
* [PATCH 1141/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 12:19 UTC (permalink / raw)
To: johannes, davem, linux-wimax, anna.schumaker, kadlec,
m.szyprowski, kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni,
arnd, aryabinin
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
net/wireless/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index ecca389..711ab8c 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -48,7 +48,7 @@ static struct dentry *ieee80211_debugfs_dir;
struct workqueue_struct *cfg80211_wq;
static bool cfg80211_disable_40mhz_24ghz;
-module_param(cfg80211_disable_40mhz_24ghz, bool, 0644);
+module_param(cfg80211_disable_40mhz_24ghz, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(cfg80211_disable_40mhz_24ghz,
"Disable 40MHz support in the 2.4GHz band");
--
2.9.2
^ permalink raw reply related
* [PATCH 1114/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 12:17 UTC (permalink / raw)
To: johannes, davem, jmorris, yoshfuji, kaber, m.szyprowski,
kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni,
aarcange, aryabinin
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
net/mac80211/rc80211_minstrel_ht.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 30fbabf..1b9d495 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -138,7 +138,7 @@
#ifdef CONFIG_MAC80211_RC_MINSTREL_VHT
static bool minstrel_vht_only = true;
-module_param(minstrel_vht_only, bool, 0644);
+module_param(minstrel_vht_only, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(minstrel_vht_only,
"Use only VHT rates when VHT is supported by sta.");
#endif
--
2.9.2
^ permalink raw reply related
* [PATCH 1112/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 12:17 UTC (permalink / raw)
To: johannes, davem, jmorris, yoshfuji, kaber, m.szyprowski,
kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni,
aarcange, aryabinin
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
net/mac80211/mlme.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 8d426f6..ca2f846 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -42,12 +42,12 @@
#define IEEE80211_ASSOC_MAX_TRIES 3
static int max_nullfunc_tries = 2;
-module_param(max_nullfunc_tries, int, 0644);
+module_param(max_nullfunc_tries, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(max_nullfunc_tries,
"Maximum nullfunc tx tries before disconnecting (reason 4).");
static int max_probe_tries = 5;
-module_param(max_probe_tries, int, 0644);
+module_param(max_probe_tries, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(max_probe_tries,
"Maximum probe tries before disconnecting (reason 4).");
@@ -60,7 +60,7 @@ MODULE_PARM_DESC(max_probe_tries,
* default to what we want.
*/
static int beacon_loss_count = 7;
-module_param(beacon_loss_count, int, 0644);
+module_param(beacon_loss_count, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(beacon_loss_count,
"Number of beacon intervals before we decide beacon was lost.");
@@ -75,7 +75,7 @@ MODULE_PARM_DESC(beacon_loss_count,
* checking the connection still works.
*/
static int probe_wait_ms = 500;
-module_param(probe_wait_ms, int, 0644);
+module_param(probe_wait_ms, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(probe_wait_ms,
"Maximum time(ms) to wait for probe response"
" before disconnecting (reason 4).");
--
2.9.2
^ permalink raw reply related
* [PATCH 1133/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 12:19 UTC (permalink / raw)
To: johannes, davem, kadlec, kaber, m.szyprowski, kyungmin.park,
k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni,
aryabinin
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
net/rfkill/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 884027f..53bf4f9 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -114,7 +114,7 @@ static DEFINE_MUTEX(rfkill_global_mutex);
static LIST_HEAD(rfkill_fds); /* list of open fds of /dev/rfkill */
static unsigned int rfkill_default_state = 1;
-module_param_named(default_state, rfkill_default_state, uint, 0444);
+module_param_named(default_state, rfkill_default_state, uint, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(default_state,
"Default initial state for all radio types, 0 = radio off");
--
2.9.2
^ permalink raw reply related
* [PATCH 0954/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 12:02 UTC (permalink / raw)
To: Larry.Finger, Jes.Sorensen, gregkh, m.chehab, m.szyprowski,
kyungmin.park, k.kozlowski
Cc: linux-wireless, devel, linux-kernel, chuansheng.liu, baolex.ni,
shivanib134, punitvara, joseph.bisch, bhaktipriya96
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/staging/rtl8723au/os_dep/os_intfs.c | 66 ++++++++++++++---------------
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/rtl8723au/os_dep/os_intfs.c b/drivers/staging/rtl8723au/os_dep/os_intfs.c
index b8848c2..eac8edc 100644
--- a/drivers/staging/rtl8723au/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8723au/os_dep/os_intfs.c
@@ -53,7 +53,7 @@ static int rtw_ips_mode = IPS_NORMAL;
static int rtw_smart_ps = 2;
-module_param(rtw_ips_mode, int, 0644);
+module_param(rtw_ips_mode, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(rtw_ips_mode, "The default IPS mode");
static int rtw_long_retry_lmt = 7;
@@ -112,62 +112,62 @@ static int rtw_80211d;
static int rtw_regulatory_id = 0xff;/* Regulatory tab id, 0xff = follow efuse's setting */
-module_param(rtw_regulatory_id, int, 0644);
+module_param(rtw_regulatory_id, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
static char *ifname = "wlan%d";
-module_param(ifname, charp, 0644);
+module_param(ifname, charp, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(ifname, "The default name to allocate for first interface");
static char *if2name = "wlan%d";
-module_param(if2name, charp, 0644);
+module_param(if2name, charp, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(if2name, "The default name to allocate for second interface");
-module_param(rtw_channel_plan, int, 0644);
-module_param(rtw_chip_version, int, 0644);
-module_param(rtw_rfintfs, int, 0644);
-module_param(rtw_channel, int, 0644);
-module_param(rtw_wmm_enable, int, 0644);
-module_param(rtw_vrtl_carrier_sense, int, 0644);
-module_param(rtw_vcs_type, int, 0644);
-module_param(rtw_busy_thresh, int, 0644);
-module_param(rtw_ht_enable, int, 0644);
-module_param(rtw_cbw40_enable, int, 0644);
-module_param(rtw_ampdu_enable, int, 0644);
-module_param(rtw_rx_stbc, int, 0644);
-module_param(rtw_ampdu_amsdu, int, 0644);
+module_param(rtw_channel_plan, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_chip_version, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_rfintfs, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_channel, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_wmm_enable, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_vrtl_carrier_sense, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_vcs_type, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_busy_thresh, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_ht_enable, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_cbw40_enable, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_ampdu_enable, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_rx_stbc, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_ampdu_amsdu, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
-module_param(rtw_lowrate_two_xmit, int, 0644);
+module_param(rtw_lowrate_two_xmit, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
-module_param(rtw_rf_config, int, 0644);
-module_param(rtw_power_mgnt, int, 0644);
-module_param(rtw_smart_ps, int, 0644);
-module_param(rtw_low_power, int, 0644);
-module_param(rtw_wifi_spec, int, 0644);
+module_param(rtw_rf_config, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_power_mgnt, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_smart_ps, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_low_power, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_wifi_spec, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
-module_param(rtw_antdiv_cfg, int, 0644);
+module_param(rtw_antdiv_cfg, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
-module_param(rtw_enusbss, int, 0644);
-module_param(rtw_hwpdn_mode, int, 0644);
-module_param(rtw_hwpwrp_detect, int, 0644);
+module_param(rtw_enusbss, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_hwpdn_mode, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+module_param(rtw_hwpwrp_detect, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
-module_param(rtw_hw_wps_pbc, int, 0644);
+module_param(rtw_hw_wps_pbc, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
static uint rtw_max_roaming_times = 2;
-module_param(rtw_max_roaming_times, uint, 0644);
+module_param(rtw_max_roaming_times, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(rtw_max_roaming_times, "The max roaming times to try");
-module_param(rtw_80211d, int, 0644);
+module_param(rtw_80211d, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(rtw_80211d, "Enable 802.11d mechanism");
#ifdef CONFIG_8723AU_BT_COEXIST
-module_param(rtw_btcoex_enable, int, 0644);
+module_param(rtw_btcoex_enable, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(rtw_btcoex_enable, "Enable BT co-existence mechanism");
#endif
static uint rtw_notch_filter;
-module_param(rtw_notch_filter, uint, 0644);
+module_param(rtw_notch_filter, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(rtw_notch_filter, "0:Disable, 1:Enable, 2:Enable only for P2P");
-module_param_named(debug, rtw_debug, int, 0444);
+module_param_named(debug, rtw_debug, int, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(debug, "Set debug level (1-9) (default 1)");
static int netdev_close(struct net_device *pnetdev);
--
2.9.2
^ permalink raw reply related
* [PATCH 0921/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 11:58 UTC (permalink / raw)
To: m, jejb, martin.petersen, m.chehab, pawel, m.szyprowski,
kyungmin.park, k.kozlowski
Cc: linux-wireless, linux-kernel, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/ssb/pcmcia.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ssb/pcmcia.c b/drivers/ssb/pcmcia.c
index f03422b..e69296a 100644
--- a/drivers/ssb/pcmcia.c
+++ b/drivers/ssb/pcmcia.c
@@ -764,7 +764,7 @@ static ssize_t ssb_pcmcia_attr_sprom_store(struct device *pcmciadev,
ssb_pcmcia_sprom_write_all);
}
-static DEVICE_ATTR(ssb_sprom, 0600,
+static DEVICE_ATTR(ssb_sprom, S_IRUSR | S_IWUSR,
ssb_pcmcia_attr_sprom_show,
ssb_pcmcia_attr_sprom_store);
--
2.9.2
^ permalink raw reply related
* [PATCH 0920/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 11:58 UTC (permalink / raw)
To: m, jejb, martin.petersen, m.chehab, pawel, m.szyprowski,
kyungmin.park, k.kozlowski
Cc: linux-wireless, linux-kernel, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/ssb/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
index 0f28c08..84622d2 100644
--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -1155,7 +1155,7 @@ static ssize_t ssb_pci_attr_sprom_store(struct device *pcidev,
sprom_check_crc, sprom_do_write);
}
-static DEVICE_ATTR(ssb_sprom, 0600,
+static DEVICE_ATTR(ssb_sprom, S_IRUSR | S_IWUSR,
ssb_pci_attr_sprom_show,
ssb_pci_attr_sprom_store);
--
2.9.2
^ permalink raw reply related
* [PATCH v2] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command
From: Masashi Honma @ 2016-08-02 11:41 UTC (permalink / raw)
To: honma, johannes; +Cc: linux-wireless, j, me, Masashi Honma
In-Reply-To: <1468927556-4703-1-git-send-email-masashi.honma@gmail.com>
Previously, NL80211_MESHCONF_HT_OPMODE rejected correct flag
combination, ex) IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED |
IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT.
This was caused by simple comparison with value 16. This causes setting
non-existent flag (like 0x08) and invalid flag combinations. So this
commit implements some checks based on IEEE 802.11 2012 8.4.2.59 HT
Operation element.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/wireless/nl80211.c | 42 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46417f9..b2af600 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5471,9 +5471,49 @@ do { \
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, rssi_threshold, -255, 0,
mask, NL80211_MESHCONF_RSSI_THRESHOLD,
nl80211_check_s32);
- FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0, 16,
+ FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0,
+ IEEE80211_HT_OP_MODE_PROTECTION |
+ IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT |
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT,
mask, NL80211_MESHCONF_HT_OPMODE,
nl80211_check_u16);
+ if (tb[NL80211_MESHCONF_HT_OPMODE]) {
+ /*
+ * Check HT operation mode based on IEEE 802.11 2012 8.4.2.59
+ * HT Operation element.
+ */
+ if (cfg->ht_opmode & (~(IEEE80211_HT_OP_MODE_PROTECTION |
+ IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT |
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT)))
+ return -EINVAL;
+
+ if ((cfg->ht_opmode & IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT) &&
+ (cfg->ht_opmode & IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT))
+ return -EINVAL;
+
+ switch (cfg->ht_opmode & IEEE80211_HT_OP_MODE_PROTECTION) {
+ case IEEE80211_HT_OP_MODE_PROTECTION_NONE:
+ if (cfg->ht_opmode &
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT)
+ return -EINVAL;
+ break;
+ case IEEE80211_HT_OP_MODE_PROTECTION_NONMEMBER:
+ if (!(cfg->ht_opmode &
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT))
+ return -EINVAL;
+ break;
+ case IEEE80211_HT_OP_MODE_PROTECTION_20MHZ:
+ if (cfg->ht_opmode &
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT)
+ return -EINVAL;
+ break;
+ case IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED:
+ if (!(cfg->ht_opmode &
+ IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT))
+ return -EINVAL;
+ break;
+ }
+ }
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshHWMPactivePathToRootTimeout,
1, 65535, mask,
NL80211_MESHCONF_HWMP_PATH_TO_ROOT_TIMEOUT,
--
2.7.4
^ permalink raw reply related
* [PATCH 0796/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 11:47 UTC (permalink / raw)
To: Larry.Finger, chaoming_li, kvalo, linuxwifi, m.chehab, pawel,
m.szyprowski, kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
index c6e09a1..162f60a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
@@ -369,11 +369,11 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Realtek 8192DE 802.11n Dual Mac PCI wireless");
MODULE_FIRMWARE("rtlwifi/rtl8192defw.bin");
-module_param_named(swenc, rtl92de_mod_params.sw_crypto, bool, 0444);
-module_param_named(debug, rtl92de_mod_params.debug, int, 0444);
-module_param_named(ips, rtl92de_mod_params.inactiveps, bool, 0444);
-module_param_named(swlps, rtl92de_mod_params.swctrl_lps, bool, 0444);
-module_param_named(fwlps, rtl92de_mod_params.fwctrl_lps, bool, 0444);
+module_param_named(swenc, rtl92de_mod_params.sw_crypto, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(debug, rtl92de_mod_params.debug, int, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(ips, rtl92de_mod_params.inactiveps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(swlps, rtl92de_mod_params.swctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(fwlps, rtl92de_mod_params.fwctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 1)\n");
--
2.9.2
^ permalink raw reply related
* [PATCH 0798/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 11:47 UTC (permalink / raw)
To: Larry.Finger, chaoming_li, kvalo, linuxwifi, m.chehab, pawel,
m.szyprowski, kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
index 31baca41..d543a78 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
@@ -420,11 +420,11 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Realtek 8192S/8191S 802.11n PCI wireless");
MODULE_FIRMWARE("rtlwifi/rtl8192sefw.bin");
-module_param_named(swenc, rtl92se_mod_params.sw_crypto, bool, 0444);
-module_param_named(debug, rtl92se_mod_params.debug, int, 0444);
-module_param_named(ips, rtl92se_mod_params.inactiveps, bool, 0444);
-module_param_named(swlps, rtl92se_mod_params.swctrl_lps, bool, 0444);
-module_param_named(fwlps, rtl92se_mod_params.fwctrl_lps, bool, 0444);
+module_param_named(swenc, rtl92se_mod_params.sw_crypto, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(debug, rtl92se_mod_params.debug, int, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(ips, rtl92se_mod_params.inactiveps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(swlps, rtl92se_mod_params.swctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(fwlps, rtl92se_mod_params.fwctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 1)\n");
--
2.9.2
^ permalink raw reply related
* [PATCH 0797/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 11:47 UTC (permalink / raw)
To: Larry.Finger, chaoming_li, kvalo, linuxwifi, m.chehab, pawel,
m.szyprowski, kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
index c31c6bf..581af83 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
@@ -369,14 +369,14 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Realtek 8192EE 802.11n PCI wireless");
MODULE_FIRMWARE("rtlwifi/rtl8192eefw.bin");
-module_param_named(swenc, rtl92ee_mod_params.sw_crypto, bool, 0444);
-module_param_named(debug, rtl92ee_mod_params.debug, int, 0444);
-module_param_named(ips, rtl92ee_mod_params.inactiveps, bool, 0444);
-module_param_named(swlps, rtl92ee_mod_params.swctrl_lps, bool, 0444);
-module_param_named(fwlps, rtl92ee_mod_params.fwctrl_lps, bool, 0444);
-module_param_named(msi, rtl92ee_mod_params.msi_support, bool, 0444);
+module_param_named(swenc, rtl92ee_mod_params.sw_crypto, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(debug, rtl92ee_mod_params.debug, int, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(ips, rtl92ee_mod_params.inactiveps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(swlps, rtl92ee_mod_params.swctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(fwlps, rtl92ee_mod_params.fwctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(msi, rtl92ee_mod_params.msi_support, bool, S_IRUSR | S_IRGRP | S_IROTH);
module_param_named(disable_watchdog, rtl92ee_mod_params.disable_watchdog,
- bool, 0444);
+ bool, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
--
2.9.2
^ permalink raw reply related
* [PATCH 0799/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 11:47 UTC (permalink / raw)
To: Larry.Finger, chaoming_li, kvalo, linuxwifi, m.chehab, pawel,
m.szyprowski, kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
index ff49a8c..8d7f581 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
@@ -385,14 +385,14 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Realtek 8723E 802.11n PCI wireless");
MODULE_FIRMWARE("rtlwifi/rtl8723efw.bin");
-module_param_named(swenc, rtl8723e_mod_params.sw_crypto, bool, 0444);
-module_param_named(debug, rtl8723e_mod_params.debug, int, 0444);
-module_param_named(ips, rtl8723e_mod_params.inactiveps, bool, 0444);
-module_param_named(swlps, rtl8723e_mod_params.swctrl_lps, bool, 0444);
-module_param_named(fwlps, rtl8723e_mod_params.fwctrl_lps, bool, 0444);
-module_param_named(msi, rtl8723e_mod_params.msi_support, bool, 0444);
+module_param_named(swenc, rtl8723e_mod_params.sw_crypto, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(debug, rtl8723e_mod_params.debug, int, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(ips, rtl8723e_mod_params.inactiveps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(swlps, rtl8723e_mod_params.swctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(fwlps, rtl8723e_mod_params.fwctrl_lps, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(msi, rtl8723e_mod_params.msi_support, bool, S_IRUSR | S_IRGRP | S_IROTH);
module_param_named(disable_watchdog, rtl8723e_mod_params.disable_watchdog,
- bool, 0444);
+ bool, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
--
2.9.2
^ permalink raw reply related
* [PATCH 0795/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 11:47 UTC (permalink / raw)
To: Larry.Finger, chaoming_li, kvalo, linuxwifi, m.chehab, pawel,
m.szyprowski, kyungmin.park, k.kozlowski
Cc: linux-wireless, netdev, linux-kernel, adrien+dev, chuansheng.liu,
baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 7c6f7f0..d704e18 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -164,8 +164,8 @@ static struct rtl_mod_params rtl92cu_mod_params = {
.debug = DBG_EMERG,
};
-module_param_named(swenc, rtl92cu_mod_params.sw_crypto, bool, 0444);
-module_param_named(debug, rtl92cu_mod_params.debug, int, 0444);
+module_param_named(swenc, rtl92cu_mod_params.sw_crypto, bool, S_IRUSR | S_IRGRP | S_IROTH);
+module_param_named(debug, rtl92cu_mod_params.debug, int, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
MODULE_PARM_DESC(debug, "Set debug level (0-5) (default 0)");
--
2.9.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox