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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 01 Nov 2017 12:27:40 -0500
From:   "Gustavo A. R. Silva" <garsilva@...eddedor.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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

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.

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.

Thanks
--
Gustavo A. R. Silva