From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753439AbcIAWOc (ORCPT ); Thu, 1 Sep 2016 18:14:32 -0400 Received: from mail-vk0-f66.google.com ([209.85.213.66]:36185 "EHLO mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038AbcIAWO3 (ORCPT ); Thu, 1 Sep 2016 18:14:29 -0400 MIME-Version: 1.0 In-Reply-To: <87vb31kdvh.fsf@intel.com> References: <87y47ykzmz.fsf@intel.com> <20160428141611.GK19428@n2100.arm.linux.org.uk> <2806018.GHhm6tEuKR@wuerfel> <87vb31kdvh.fsf@intel.com> From: Leo Li Date: Thu, 1 Sep 2016 17:14:28 -0500 Message-ID: Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev To: Felipe Balbi Cc: Arnd Bergmann , Russell King - ARM Linux , Grygorii Strashko , Catalin Marinas , Yoshihiro Shimoda , "linux-usb@vger.kernel.org" , Sekhar Nori , lkml , David Fisher , "Thang Q. Nguyen" , Alan Stern , Greg Kroah-Hartman , "linux-arm-kernel@lists.infradead.org" , Stuart Yoder , Scott Wood Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 28, 2016 at 9:27 AM, Felipe Balbi wrote: > > Hi, > > Arnd Bergmann writes: >> On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote: >>> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote: >>> > >>> > Hi, >>> > >>> > Arnd Bergmann writes: >>> > > pointer and pass that in platform_data. This is really easy, it's >>> > >>> > Sorry but passing a struct device pointer in platform_data is >>> > ridiculous. Not to mention that, as I said before, we can't assume which >>> > device to pass to xhci_plat in the first place. It might be dwc->dev and >>> > it might be dwc->dev->parent. >>> >>> +1. Passing an unref-counted struct device through platform data is >>> totally mad, Arnd you're off your rocker if you think that's a good >>> idea. What's more is that there's no way to properly refcount the >>> thing. >> >> It's the parent device (or NULL), there is no way it can ever go away as >> it's already refcounted through the device subsystem by the creation >> of the child device. > > you're assuming that based on what we have today. We could get into a > situation where we need to use a completely unrelated device and the > problem exists again. > >> I do realize that it's a hack, but the idea is to get rid of that >> as soon as possibly by fixing the way the xhci device is probe so >> we no longer need to fake a platform_device as the child here and >> can just use the device itself. > > okay, let me try to be extra clear here: > > We will *not* remove the extra platform_device because it actually > *does* exist and helps me hide/abstract a bunch of details and make > assumptions about order of certain events. We have already gone through > that in the past when I explained why I wrote dwc3 the way it is; if you > need a refresher, there are mailing list archives for that. > > Moreover, this same problem exists for anything under drivers/mfd. It > just so happens that they're usually some i2c or spi device which don't > do DMA by themselves. Hi Felipe and Arnd, It has been a while since the last response to this discussion, but we haven't reached an agreement yet! Can we get to a conclusion on if it is valid to create child platform device for abstraction purpose? If yes, can this child device do DMA by itself? - Leo From mboxrd@z Thu Jan 1 00:00:00 1970 From: pku.leo@gmail.com (Leo Li) Date: Thu, 1 Sep 2016 17:14:28 -0500 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <87vb31kdvh.fsf@intel.com> References: <87y47ykzmz.fsf@intel.com> <20160428141611.GK19428@n2100.arm.linux.org.uk> <2806018.GHhm6tEuKR@wuerfel> <87vb31kdvh.fsf@intel.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Apr 28, 2016 at 9:27 AM, Felipe Balbi wrote: > > Hi, > > Arnd Bergmann writes: >> On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote: >>> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote: >>> > >>> > Hi, >>> > >>> > Arnd Bergmann writes: >>> > > pointer and pass that in platform_data. This is really easy, it's >>> > >>> > Sorry but passing a struct device pointer in platform_data is >>> > ridiculous. Not to mention that, as I said before, we can't assume which >>> > device to pass to xhci_plat in the first place. It might be dwc->dev and >>> > it might be dwc->dev->parent. >>> >>> +1. Passing an unref-counted struct device through platform data is >>> totally mad, Arnd you're off your rocker if you think that's a good >>> idea. What's more is that there's no way to properly refcount the >>> thing. >> >> It's the parent device (or NULL), there is no way it can ever go away as >> it's already refcounted through the device subsystem by the creation >> of the child device. > > you're assuming that based on what we have today. We could get into a > situation where we need to use a completely unrelated device and the > problem exists again. > >> I do realize that it's a hack, but the idea is to get rid of that >> as soon as possibly by fixing the way the xhci device is probe so >> we no longer need to fake a platform_device as the child here and >> can just use the device itself. > > okay, let me try to be extra clear here: > > We will *not* remove the extra platform_device because it actually > *does* exist and helps me hide/abstract a bunch of details and make > assumptions about order of certain events. We have already gone through > that in the past when I explained why I wrote dwc3 the way it is; if you > need a refresher, there are mailing list archives for that. > > Moreover, this same problem exists for anything under drivers/mfd. It > just so happens that they're usually some i2c or spi device which don't > do DMA by themselves. Hi Felipe and Arnd, It has been a while since the last response to this discussion, but we haven't reached an agreement yet! Can we get to a conclusion on if it is valid to create child platform device for abstraction purpose? If yes, can this child device do DMA by itself? - Leo