mbox series

[v2,0/2] fixes for yt8511 phy driver

Message ID 20210525203314.14681-1-pgwipeout@gmail.com (mailing list archive)
Headers show
Series fixes for yt8511 phy driver | expand

Message

Peter Geis May 25, 2021, 8:33 p.m. UTC 
The Intel clang bot caught a few uninitialized variables in the new
Motorcomm driver. While investigating the issue, it was found that the
driver would have unintended effects when used in an unsupported mode.

Fixed the uninitialized ret variable and abort loading the driver in
unsupported modes.

Thank you to the Intel clang bot for catching these.

Changelog:
V2:
- fix variable order
- add Andrew Lunn's reviewed-by tags

Peter Geis (2):
  net: phy: fix yt8511 clang uninitialized variable warning
  net: phy: abort loading yt8511 driver in unsupported modes

 drivers/net/phy/motorcomm.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

Comments

Jakub Kicinski May 26, 2021, 7:27 p.m. UTC | #1 
On Tue, 25 May 2021 16:33:12 -0400 Peter Geis wrote:
> The Intel clang bot caught a few uninitialized variables in the new
> Motorcomm driver. While investigating the issue, it was found that the
> driver would have unintended effects when used in an unsupported mode.
> 
> Fixed the uninitialized ret variable and abort loading the driver in
> unsupported modes.
> 
> Thank you to the Intel clang bot for catching these.

Fixes tag need work, the hashes don't match the ones in net-next.
Peter Geis May 26, 2021, 8:15 p.m. UTC | #2 
On Wed, May 26, 2021 at 3:27 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 25 May 2021 16:33:12 -0400 Peter Geis wrote:
> > The Intel clang bot caught a few uninitialized variables in the new
> > Motorcomm driver. While investigating the issue, it was found that the
> > driver would have unintended effects when used in an unsupported mode.
> >
> > Fixed the uninitialized ret variable and abort loading the driver in
> > unsupported modes.
> >
> > Thank you to the Intel clang bot for catching these.
>
> Fixes tag need work, the hashes don't match the ones in net-next.

It seems when I asked git for the hash for that patch, it grabbed my
original patch which was against linux-next.
Apologies for the confusion.