From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753507AbbGWSAc (ORCPT ); Thu, 23 Jul 2015 14:00:32 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:59467 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923AbbGWSAa (ORCPT ); Thu, 23 Jul 2015 14:00:30 -0400 Date: Thu, 23 Jul 2015 11:00:29 -0700 From: Greg Kroah-Hartman To: Felipe Balbi Cc: Heikki Krogerus , ChengYi He , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: ulpi: call put_device if device_register fails Message-ID: <20150723180029.GA29213@kroah.com> References: <20150618171236.GA18007@chengyihe-ThinkCentre-M82> <20150623105738.GD1296@kuha.fi.intel.com> <20150722213934.GA10425@kroah.com> <20150723020440.GB16806@saruman.tx.rr.com> <20150723031446.GA10588@kroah.com> <20150723050240.GA18430@saruman.tx.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150723050240.GA18430@saruman.tx.rr.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 23, 2015 at 12:02:40AM -0500, Felipe Balbi wrote: > Hi, > > On Wed, Jul 22, 2015 at 08:14:46PM -0700, Greg Kroah-Hartman wrote: > > On Wed, Jul 22, 2015 at 09:04:40PM -0500, Felipe Balbi wrote: > > > On Wed, Jul 22, 2015 at 02:39:34PM -0700, Greg Kroah-Hartman wrote: > > > > On Tue, Jun 23, 2015 at 01:57:38PM +0300, Heikki Krogerus wrote: > > > > > On Fri, Jun 19, 2015 at 01:12:36AM +0800, ChengYi He wrote: > > > > > > put_device is required to release the last reference to the device. > > > > > > > > > > > > Signed-off-by: ChengYi He > > > > > > --- > > > > > > drivers/usb/common/ulpi.c | 4 +++- > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c > > > > > > index 0e6f968..bd25bdb 100644 > > > > > > --- a/drivers/usb/common/ulpi.c > > > > > > +++ b/drivers/usb/common/ulpi.c > > > > > > @@ -184,8 +184,10 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi) > > > > > > request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product); > > > > > > > > > > > > ret = device_register(&ulpi->dev); > > > > > > - if (ret) > > > > > > + if (ret) { > > > > > > + put_device(&ulpi->dev); > > > > > > > > > > If device_register returns failure, put_device has already been > > > > > called. Check device_add in drivers/base/core.c. > > > > > > > > Yes, please read the function, which says: > > > > * NOTE: _Never_ directly free @dev after calling this function, even > > > > * if it returned an error! Always use put_device() to give up your > > > > * reference instead. > > > > > > > > But, the problem is that the ulpi core doesn't "own" that struct device. > > > > It comes from elsewhere. It comes from somewhere deep down in the dw3 > > > > core, which is where I lost the path. Something needs to be fixed in > > > > dwc3_probe() to properly clean up the device if it fails, which is not > > > > happening right now. > > > > > > > > So this patch would actually cause much bigger problems than fixing > > > > anything, so it's wrong, but for a different reason than you are talking > > > > about here. > > > > > > > > And ugh, the ulpi and dwc code binding together, what a mess, horrid... > > > > > > any suggestions ? DWC *is* the one implementing the bus. If there's a > > > better way, we can certainly shuffle code around. > > > > As dwc is the only thing using the bus, why is it drivers/usb/core/ ? > > musb also has a SW-accessible ULPI bus. And, IIRC, so does DWC2 ;-) But they aren't calling ulpi_register(), so how can they be using this code? > > And the error path here is broken, the bus should be creating the device > > (i.e. no subsystem should ever be registering a device it did not > > create), so that it can properly clean things up when stuff goes wrong. > > > > The whole subsys_init() is also a bad feeling that it's not architected > > correctly, that shouldn't be needed, which is why I never took that > > patch. Just noticed it came in through yours, I wanted it "broken" so > > it would be fixed "properly" and not papered over like this. > > I just felt it would be better to 'fix' it for the -rc until it can be > fixed *properly*. A follow up fix should incur no visible changes to > drivers anyway. I don't like fixes like this because no one now has any pressure to fix it "properly". Are you doing that work? If not, who is? thanks, greg k-h