linux-kernel - Re: [PATCH 6/9] usb: host: isp1362-hcd: mark expected switch fall-through

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171101173851.GA23225@kroah.com>
Date:   Wed, 1 Nov 2017 18:38:51 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     "Gustavo A. R. Silva" <garsilva@...eddedor.com>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/9] usb: host: isp1362-hcd: mark expected switch
 fall-through

On Wed, Nov 01, 2017 at 12:27:40PM -0500, Gustavo A. R. Silva wrote:
> 
> Quoting Greg Kroah-Hartman <gregkh@...uxfoundation.org>:
> 
> > On Wed, Oct 25, 2017 at 02:05:05PM -0500, Gustavo A. R. Silva wrote:
> > > Greg,
> > > 
> > > Quoting "Gustavo A. R. Silva" <garsilva@...eddedor.com>:
> > > 
> > > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > > > where we are expecting to fall through.
> > > >
> > > > Signed-off-by: Gustavo A. R. Silva <garsilva@...eddedor.com>
> > > > ---
> > > >  drivers/usb/host/isp1362-hcd.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/usb/host/isp1362-hcd.c
> > > b/drivers/usb/host/isp1362-hcd.c
> > > > index 9b7e307..753d576 100644
> > > > --- a/drivers/usb/host/isp1362-hcd.c
> > > > +++ b/drivers/usb/host/isp1362-hcd.c
> > > > @@ -1578,6 +1578,7 @@ static int isp1362_hub_control(struct usb_hcd
> > > > *hcd, u16 typeReq, u16 wValue,
> > > >  			spin_lock_irqsave(&isp1362_hcd->lock, flags);
> > > >  			isp1362_write_reg32(isp1362_hcd, HCRHSTATUS, RH_HS_OCIC);
> > > >  			spin_unlock_irqrestore(&isp1362_hcd->lock, flags);
> > > > +			/* fall through */
> > > 
> > > I'm suspicious this should be a 'break' instead.
> > > 
> > > What do you think?
> > 
> > Yeah, this should be a 'break', care to make that patch up instead?
> > 
> 
> Sure thing.
> 
> Just some questions about the process to follow:
> 
> Should I send a v2 replying to this particular thread only? like [PATCH v2
> 6/9]
> or should I send just a new patch separated from this patch series? I guess
> this is the case.

Brand new patch is fine, this is gone from my patch queue.

> Some maintainers have told me that in cases where a particular patch in the
> series needs an update, the complete patchset should be sent again.
> But I think that depends on the functional impact the patch has over
> the whole patchset.

Yes, it all depends, the rest of these patches are already in my tree.

thanks,

greg k-h