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]
Date:   Tue, 9 Feb 2021 09:18:02 +0800
From:   Youling Tang <>
To:     Dan Carpenter <>,
        Sascha Hauer <>
        Greg Kroah-Hartman <>,,,
        Matthias Brugger <>,
Subject: Re: [PATCH] staging: fix ignoring return value warning

Hi, Dan

On 02/09/2021 03:02 AM, Dan Carpenter wrote:
> On Mon, Feb 08, 2021 at 04:06:18PM +0100, Sascha Hauer wrote:
>> Hi Dan,
>> On Mon, Feb 08, 2021 at 04:45:17PM +0300, Dan Carpenter wrote:
>>> On Sun, Feb 07, 2021 at 05:23:28PM +0800, Youling Tang wrote:
>>>> Fix the below ignoring return value warning for device_reset.
>>>> drivers/staging/mt7621-dma/mtk-hsdma.c:685:2: warning: ignoring return value
>>>> of function declared with 'warn_unused_result' attribute [-Wunused-result]
>>>>          device_reset(&pdev->dev);
>>>>          ^~~~~~~~~~~~ ~~~~~~~~~~
>>>> drivers/staging/ralink-gdma/ralink-gdma.c:836:2: warning: ignoring return value
>>>> of function declared with 'warn_unused_result' attribute [-Wunused-result]
>>>>          device_reset(&pdev->dev);
>>>>          ^~~~~~~~~~~~ ~~~~~~~~~~
>>> We can't really do this sort of fix without the hardware to test it.
>>> This could be the correct fix or perhaps switching to device_reset_optional()
>>> is the correct fix.  We can't know unless we have the hardware to test.
>> When device_reset() is the wrong function then adding a return value
>> check will turn this into a runtime error for those who have the
>> hardware which will hopefully trigger them to tell us why reset_device
>> is wrong for them.
>> At least for a staging driver I find this procedure opportune.
> That seems like sort of a jerk move...  What's the rush?  Someone will
> eventually be able to test this if we just wait around for a bit.
> Otherwise if no one has the hardware then eventually the driver will be
> deleted.
> regards,
> dan carpenter
We do not have the relevant hardware to test, this is just to solve a
compile-time warning.


Powered by blists - more mailing lists