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: <a2bbdfb4-19ed-461e-a14b-e91a5636cc77@intel.com>
Date: Wed, 18 Dec 2024 17:10:53 +0100
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: WangYuli <wangyuli@...ontech.com>
CC: <nbd@....name>, <lorenzo@...nel.org>, <ryder.lee@...iatek.com>,
	<shayne.chen@...iatek.com>, <sean.wang@...iatek.com>, <kvalo@...nel.org>,
	<matthias.bgg@...il.com>, <angelogioacchino.delregno@...labora.com>,
	<davem@...emloft.net>, <andrew+netdev@...n.ch>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <pabeni@...hat.com>, <alexander.deucher@....com>,
	<gregkh@...uxfoundation.org>, <rodrigo.vivi@...el.com>,
	<linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-mediatek@...ts.infradead.org>,
	<raoxu@...ontech.com>, <guanwentao@...ontech.com>, <zhanjun@...ontech.com>,
	<cug_yangyuancong@...mail.com>, <lorenzo.bianconi@...hat.com>,
	<kvalo@...eaurora.org>, <sidhayn@...il.com>, <lorenzo.bianconi83@...il.com>,
	<sgruszka@...hat.com>, <keescook@...omium.org>, <markus.theil@...ilmenau.de>,
	<gustavoars@...nel.org>, <stf_xl@...pl>, <romain.perier@...il.com>,
	<apais@...ux.microsoft.com>, <mrkiko.rs@...il.com>, <oliver@...kum.org>,
	<woojung.huh@...rochip.com>, <helmut.schaa@...glemail.com>,
	<mailhol.vincent@...adoo.fr>, <dokyungs@...sei.ac.kr>,
	<deren.wu@...iatek.com>, <daniel@...rotopia.org>, <sujuan.chen@...iatek.com>,
	<mikhail.v.gavrilov@...il.com>, <stern@...land.harvard.edu>,
	<linux-usb@...r.kernel.org>, <leitao@...ian.org>, <dsahern@...nel.org>,
	<weiwan@...gle.com>, <netdev@...r.kernel.org>, <horms@...nel.org>,
	<andrew@...n.ch>, <leit@...com>, <wang.zhao@...iatek.com>,
	<chui-hao.chiu@...iatek.com>, <lynxis@...0.eu>, <mingyen.hsieh@...iatek.com>,
	<yn.chen@...iatek.com>, <quan.zhou@...iatek.com>, <dzm91@...t.edu.cn>,
	<gch981213@...il.com>, <git@...nap.io>, <jiefeng_li@...t.edu.cn>,
	<nelson.yu@...iatek.com>, <rong.yan@...iatek.com>, <Bo.Jiao@...iatek.com>,
	<StanleyYP.Wang@...iatek.com>
Subject: Re: [RESEND. PATCH] mt76: mt76u_vendor_request: Do not print error
 messages when -EPROTO

From: Wangyuli <wangyuli@...ontech.com>
Date: Wed, 18 Dec 2024 17:08:33 +0800

> [RESEND. PATCH] mt76: mt76u_vendor_request: Do not print error messages when -EPROTO

Is it a fix or an improvement?
You need to specify the target tree, either 'PATCH net' (fixes) or
'PATCH net-next' (improvements).

The '.' after 'RESEND' is not needed.

> When initializing the network card, unplugging the device will
> trigger an -EPROTO error, resulting in a flood of error messages
> being printed frantically.
> 

If it's a fix, you need to have a 'Fixes:' tag here.

> Co-developed-by: Xu Rao <raoxu@...ontech.com>
> Signed-off-by: Xu Rao <raoxu@...ontech.com>
> Signed-off-by: WangYuli <wangyuli@...ontech.com>
> ---
>  drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
> index 58ff06823389..f9e67b8c3b3c 100644
> --- a/drivers/net/wireless/mediatek/mt76/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> @@ -33,9 +33,9 @@ int __mt76u_vendor_request(struct mt76_dev *dev, u8 req, u8 req_type,
>  
>  		ret = usb_control_msg(udev, pipe, req, req_type, val,
>  				      offset, buf, len, MT_VEND_REQ_TOUT_MS);
> -		if (ret == -ENODEV)
> +		if (ret == -ENODEV || ret == -EPROTO)
>  			set_bit(MT76_REMOVED, &dev->phy.state);
> -		if (ret >= 0 || ret == -ENODEV)
> +		if (ret >= 0 || ret == -ENODEV || ret == -EPROTO)
>  			return ret;
>  		usleep_range(5000, 10000);

How do other drivers handle this?
Can -EPROTO happen in other cases, not only unplugging, which this patch
would break?

Thanks,
Olek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ