linux-kernel - Re: linux-next: manual merge of the usb tree with the usb.current tree

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]

Message-ID: <20180423084108.GA19889@kroah.com>
Date:   Mon, 23 Apr 2018 10:41:08 +0200
From:   Greg KH <greg@...ah.com>
To:     Johan Hovold <johan@...nel.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Subject: Re: linux-next: manual merge of the usb tree with the usb.current
 tree

On Mon, Apr 23, 2018 at 10:30:11AM +0200, Johan Hovold wrote:
> On Mon, Apr 23, 2018 at 01:04:44PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the usb tree got a conflict in:
> > 
> >   drivers/usb/core/hcd.c
> > 
> > between commit:
> > 
> >   63cb03f5c11e ("usb: core: split usb_phy_roothub_{init,alloc}")
> > 
> > from the usb.current tree and commit:
> > 
> >   bc40f5341741 ("USB: core: hcd: drop support for legacy phys")
> > 
> > from the usb tree.
> > 
> > I fixed it up (see below - though I am not sure what happens to the
> > phy_roothub allocation when usb_phy_roothub_init fails) and can carry
> > the fix as necessary.
> 
> The resolution looks correct to me. The allocations done by
> usb_phy_roothub_alloc() are device managed and would be freed on probe
> failures (or unbind) so not explicit dealloc is needed. It might be a
> good idea to indicate that in the function name however (i.e. to add a
> devm_ prefix).

I'll take this same resolution when the branches get merged, thanks.

And yes, being more explicit would be a good idea for the function
name...

thanks,

greg k-h