Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Larry.Finger@lwfinger.net, phil@philpotter.co.uk,
        gregkh@linuxfoundation.org, straube.linux@gmail.com,
        Pavel Skripkin <paskripkin@gmail.com>
Cc:     linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
        Pavel Skripkin <paskripkin@gmail.com>
Subject: Re: [PATCH v3 3/6] staging: r8188eu: add error handling of rtw_read8
Date:   Thu, 26 Aug 2021 01:45:47 +0200
Message-ID: <3591772.nrefL38gfN@localhost.localdomain>
In-Reply-To: <c59d5d850bf9aab208704182c83086609289cb9c.1629789580.git.paskripkin@gmail.com>
References: <cover.1629789580.git.paskripkin@gmail.com> <c59d5d850bf9aab208704182c83086609289cb9c.1629789580.git.paskripkin@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Precedence: bulk

On Tuesday, August 24, 2021 9:27:27 AM CEST Pavel Skripkin wrote:
> _rtw_read8 function can fail in case of usb transfer failure. But
> previous function prototype wasn't designed to return an error to
> caller. It can cause a lot uninit value bugs all across the driver code,
> since rtw_read8() returns local stack variable to caller.
>=20
> Fix it by changing the prototype of this function. Now it returns an
> int: 0 on success, negative error value on failure and callers should pass
> the pointer to storage location for register value.
>=20
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>

Dear Pavel,

I have to inform you that building patch v3 3/6 with gcc (version 11.1.1 20=
210721=20
[revision 076930b9690ac3564638636f6b13bbb6bc608aea] (SUSE Linux)), gives
the following warning:

drivers/staging/r8188eu/os_dep/ioctl_linux.c:2258:13: warning: variable =E2=
=80=98error=E2=80=99 set but not used [-Wunused-but-set-variable]
 2258 |         int error;
      |             ^~~~~

I'm sorry, but I guess that for some reason previously I had only built v2 =
of your patch=20
which had no warnings at all.=20

Unfortunately, introducing warnings is not allowed.

While we are at this, I can also confirm that GCC 11.1.1 _does_ _not_ emit =
the warning=20
that has been reported by the kernel test robot.=20

Regards,

=46abio

=20