lkml.org 
[lkml]   [2016]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
On Thu, Apr 28, 2016 at 9:27 AM, Felipe Balbi <balbi@kernel.org> wrote:
>
> Hi,
>
> Arnd Bergmann <arnd@arndb.de> 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 <arnd@arndb.de> 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

\
 
 \ /
  Last update: 2016-09-17 09:58    [W:1.116 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site