Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3794857imu; Sat, 24 Nov 2018 11:07:41 -0800 (PST) X-Google-Smtp-Source: AFSGD/UuHgkqJV3pcW5qldoPL3UuwDfk+puBk50VuUazd7STPmEy0CFrE0LKnyTUV8UHRHoaUkgT X-Received: by 2002:a63:d5e:: with SMTP id 30mr18826593pgn.54.1543086461680; Sat, 24 Nov 2018 11:07:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543086461; cv=none; d=google.com; s=arc-20160816; b=OMx5cv0V6HjbV8m/icTmtYsZUWRlZRUwnHShLg0JfHLytPG5A4tncGZAmBMIVJYusX FinBLU7ndWC//uE/ojYqjQLNmJ/6gDTIV7syRo+oJB1wsJokna+sYwaz4Gx/bSUYMQq2 +BKdvUVJ6mfrKipL/tvGWgL5Vs2OHfP0vl2y1wsjS+o32uY6DdxNMJc/xbCMJIhPRG/J Oj75nTs0aJKicFRddrhz1Sjjbm5yv6C1u6IC2QLve/HapxMACJQKQSPAp5fAJU7bEvJ6 h4ep8eZZcvREu7nYpCVQxTSgCM44FX6XH3Ub47QpCz9Zqbyb5D8PSc3VmlRxLGpe4qZ3 JDxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=KFHkz1V1Uqx6uImt6SM643Y5/294MZvrNs85IMUOYls=; b=HBGPKMswOPRbruWlmcunQ7nQwrkUD41SrfUqBDmB6fOnL/d212j2TQQj96ANqQUj9Q wFcrQgp2J1r8OLs5p3/7G3R15bncxL770s5Uiw1wuWSl3DLx/MjmJdrh6Fkr7ey7JOxW oGBvyIHJDunua1O2KqR7W4ilB0z4h1uhmYEGncpJfFW4/3kjzFKi6cac4Zt+ZWeoyLHq H8OcLB8ixMj1EDZS05qgsUzKu8rVKsxfAbToha7H6Cs5MreIUYXGxv6VxLIvrYIMJqmu YuMp1KHCGPtsJiurJ6nxds0qPqC6CZqjD+faePFbDvV0TZiO5dO4XDq6vmEo8I8jjGVp dmyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=iki.fi Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b7si22030323plk.206.2018.11.24.11.07.26; Sat, 24 Nov 2018 11:07:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=iki.fi Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726119AbeKYFzz (ORCPT + 99 others); Sun, 25 Nov 2018 00:55:55 -0500 Received: from emh03.mail.saunalahti.fi ([62.142.5.109]:37514 "EHLO emh03.mail.saunalahti.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725738AbeKYFzz (ORCPT ); Sun, 25 Nov 2018 00:55:55 -0500 Received: from darkstar.musicnaut.iki.fi (85-76-84-147-nat.elisa-mobile.fi [85.76.84.147]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 2470B40018; Sat, 24 Nov 2018 21:06:49 +0200 (EET) Date: Sat, 24 Nov 2018 21:06:48 +0200 From: Aaro Koskinen To: Russell King - ARM Linux Cc: Greg KH , Peter Ujfalusi , vkoul@kernel.org, dan.j.williams@intel.com, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, tony@atomide.com, linux-omap@vger.kernel.org, Felipe Balbi Subject: Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1 Message-ID: <20181124190648.GB3416@darkstar.musicnaut.iki.fi> References: <20181119104040.12885-1-peter.ujfalusi@ti.com> <20181119184649.GE16897@darkstar.musicnaut.iki.fi> <6af8c6e7-bf5c-5555-161b-5d3fb7ecae43@ti.com> <20181120210406.GB24888@darkstar.musicnaut.iki.fi> <4eb3b03e-0a97-6195-f162-e03e32705fe0@ti.com> <20181122220114.GB11423@darkstar.musicnaut.iki.fi> <20181124001740.GI12912@darkstar.musicnaut.iki.fi> <20181124174823.GQ6920@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181124174823.GQ6920@n2100.armlinux.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Sat, Nov 24, 2018 at 05:48:23PM +0000, Russell King - ARM Linux wrote: > Hmm, there's more questionable stuff in this driver, and the gadget > layer. [...] > So, whatever way I look at this, the code in the removal path both > in omap_udc and the gadget removal code higher up looks very wrong > and broken to me. Yes, week ago I saw omap_udc crashing on both probe failure and module removal and sent some fixes for the most obvious failures (see https://marc.info/?l=linux-usb&m=154258778316932&w=2). Is there any good driver that uses usb_add_gadget_udc_release() correctly? Looking at fsl_qe_udc.c and fsl_udc_core.c they should also crash if usb_add_gadget_udc_release() fails. A.