Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1474745 > unrolled thread

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Leo Li <pku.leo@gmail.com> - 2016-09-02 00:20 +0200
    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-02 12:50 +0200
      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-09-02 13:00 +0200
        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-02 13:20 +0200
          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-02 16:20 +0200
          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Alan Stern <stern@rowland.harvard.edu> - 2016-09-02 16:30 +0200
            Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-02 18:00 +0200
              Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Roger Quadros <rogerq@ti.com> - 2016-09-07 09:20 +0200
                Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-07 10:30 +0200
                  Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Roger Quadros <rogerq@ti.com> - 2016-09-07 15:10 +0200
                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-07 16:40 +0200
          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Grygorii Strashko <grygorii.strashko@ti.com> - 2016-09-02 18:30 +0200
      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-02 13:00 +0200
        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Robin Murphy <robin.murphy@arm.com> - 2016-09-02 14:00 +0200
          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-02 15:00 +0200
          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-02 15:20 +0200
      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Leo Li <pku.leo@gmail.com> - 2016-09-03 00:20 +0200
        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-05 17:50 +0200
          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-06 08:40 +0200
            Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-06 08:50 +0200
              Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-06 12:50 +0200
                Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-06 13:00 +0200
                  Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-06 15:30 +0200
                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-07 09:00 +0200
                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-07 09:50 +0200
                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-07 11:00 +0200
                        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-07 11:30 +0200
                          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-09-07 11:40 +0200
                            Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-07 12:20 +0200
            Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-06 12:40 +0200
              Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-07 08:40 +0200
                Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-07 10:50 +0200
                  Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-07 12:00 +0200
                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Robin Murphy <robin.murphy@arm.com> - 2016-09-07 12:40 +0200
                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-07 12:50 +0200
                  Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-07 12:30 +0200
                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-07 17:30 +0200
                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Alan Stern <stern@rowland.harvard.edu> - 2016-09-07 18:10 +0200
                        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-07 21:50 +0200
                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-08 03:20 +0200
                        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 10:10 +0200
                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-08 10:10 +0200
                        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 10:30 +0200
                          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-08 10:40 +0200
                            Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 10:50 +0200
                              Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-08 11:50 +0200
                                Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 12:20 +0200
                                  Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-08 13:10 +0200
                                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 13:20 +0200
                                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-08 13:30 +0200
                                        Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 13:50 +0200
                                          Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi <balbi@kernel.org> - 2016-09-08 14:00 +0200
                                            Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 14:50 +0200
                                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Grygorii Strashko <grygorii.strashko@ti.com> - 2016-09-08 14:10 +0200
                                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 14:20 +0200
                                  Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-08 14:30 +0200
                                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Arnd Bergmann <arnd@arndb.de> - 2016-09-08 15:00 +0200
                                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-09 03:40 +0200
                                    Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Grygorii Strashko <grygorii.strashko@ti.com> - 2016-09-08 15:10 +0200
                                      Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent  dev Peter Chen <hzpeterchen@gmail.com> - 2016-09-09 04:00 +0200

Page 1 of 3  [1] 2 3  Next page →

#1474745 — Re: [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

[toc] | [next] | [standalone]

#1475020

On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> 
> 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?

I'd say it's no problem for a driver to create child devices in order
to represent different aspects of a device, but you should not rely on
those devices working when used with the dma-mapping interfaces.

This used to be simpler back when we could configure the kernel for
only one SoC platform at a time, and the platforms could provide their
own overrides for the dma-mapping interfaces. These days, we rely on
firmware or bootloader to describe various aspects of how DMA is done,
so you can't assume that passing a device without an of_node pointer
or ACPI data into those functions will do the right thing.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1475022 — Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> > 
> > 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?
> 
> I'd say it's no problem for a driver to create child devices in order
> to represent different aspects of a device, but you should not rely on
> those devices working when used with the dma-mapping interfaces.

That's absolutely right.  Consider the USB model - only the USB host
controller can perform DMA, not the USB devices themselves.  All DMA
mappings need to be mapped using the USB host controller device struct
not the USB device struct.

The same _should_ be true everywhere else: the struct device representing
the device performing DMA must be the one used to map the transfer.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1475044

[Multipart message — attachments visible in raw view] — view raw

Hi,

Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>> > 
>> > 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?
>> 
>> I'd say it's no problem for a driver to create child devices in order
>> to represent different aspects of a device, but you should not rely on
>> those devices working when used with the dma-mapping interfaces.
>
> That's absolutely right.  Consider the USB model - only the USB host
> controller can perform DMA, not the USB devices themselves.  All DMA
> mappings need to be mapped using the USB host controller device struct
> not the USB device struct.
>
> The same _should_ be true everywhere else: the struct device representing
> the device performing DMA must be the one used to map the transfer.

How do we fix dwc3 in dual-role, then?

Peripheral-side dwc3 is easy, we just require a glue-layer to be present
and use dwc3.ko's parent device (which will be the PCI device or OF
device). But for host side dwc3, the problem is slightly more complex
because we're using xhci-plat.ko by just instantiating a xhci-platform
device so xhci-plat can probe.

xhci core has no means to know if its own device or the parent of its
parent should be used for DMA. Any ideas?

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1475191

Hi,

Felipe Balbi <balbi@kernel.org> writes:
> Hi,
>
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>> > 
>>> > 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?
>>> 
>>> I'd say it's no problem for a driver to create child devices in order
>>> to represent different aspects of a device, but you should not rely on
>>> those devices working when used with the dma-mapping interfaces.
>>
>> That's absolutely right.  Consider the USB model - only the USB host
>> controller can perform DMA, not the USB devices themselves.  All DMA
>> mappings need to be mapped using the USB host controller device struct
>> not the USB device struct.
>>
>> The same _should_ be true everywhere else: the struct device representing
>> the device performing DMA must be the one used to map the transfer.
>
> How do we fix dwc3 in dual-role, then?
>
> Peripheral-side dwc3 is easy, we just require a glue-layer to be present
> and use dwc3.ko's parent device (which will be the PCI device or OF
> device). But for host side dwc3, the problem is slightly more complex
> because we're using xhci-plat.ko by just instantiating a xhci-platform
> device so xhci-plat can probe.
>
> xhci core has no means to know if its own device or the parent of its
> parent should be used for DMA. Any ideas?

another thing to consider is that dwc3 only works on omap because DT
defaults to 32-bit DMA mask for anything described in DT that doesn't
provide dma-ranges. Isn't that somewhat odd as well?

Based on your reply, Russell, dwc3-omap should be the DMA device, but
dwc3 works just as well because of the whole 32-bit default.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1475194 — Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Fri, 2 Sep 2016, Felipe Balbi wrote:

> Hi,
> 
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> >> > 
> >> > 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?
> >> 
> >> I'd say it's no problem for a driver to create child devices in order
> >> to represent different aspects of a device, but you should not rely on
> >> those devices working when used with the dma-mapping interfaces.
> >
> > That's absolutely right.  Consider the USB model - only the USB host
> > controller can perform DMA, not the USB devices themselves.  All DMA
> > mappings need to be mapped using the USB host controller device struct
> > not the USB device struct.
> >
> > The same _should_ be true everywhere else: the struct device representing
> > the device performing DMA must be the one used to map the transfer.
> 
> How do we fix dwc3 in dual-role, then?
> 
> Peripheral-side dwc3 is easy, we just require a glue-layer to be present
> and use dwc3.ko's parent device (which will be the PCI device or OF
> device). But for host side dwc3, the problem is slightly more complex
> because we're using xhci-plat.ko by just instantiating a xhci-platform
> device so xhci-plat can probe.
> 
> xhci core has no means to know if its own device or the parent of its
> parent should be used for DMA. Any ideas?

In theory, you can store a flag somewhere in the platform device,
something that would tell xhci-hcd that it has to use the parent's
parent for DMA purposes.

I know it would be somewhat of a hack, but ought to work.

Alan Stern

[toc] | [prev] | [next] | [standalone]

#1475297

On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
> 
> > Hi,
> > 
> > Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> > > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> > >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> > >> > 
> > >> > 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?
> > >> 
> > >> I'd say it's no problem for a driver to create child devices in order
> > >> to represent different aspects of a device, but you should not rely on
> > >> those devices working when used with the dma-mapping interfaces.
> > >
> > > That's absolutely right.  Consider the USB model - only the USB host
> > > controller can perform DMA, not the USB devices themselves.  All DMA
> > > mappings need to be mapped using the USB host controller device struct
> > > not the USB device struct.
> > >
> > > The same _should_ be true everywhere else: the struct device representing
> > > the device performing DMA must be the one used to map the transfer.
> > 
> > How do we fix dwc3 in dual-role, then?
> > 
> > Peripheral-side dwc3 is easy, we just require a glue-layer to be present
> > and use dwc3.ko's parent device (which will be the PCI device or OF
> > device). But for host side dwc3, the problem is slightly more complex
> > because we're using xhci-plat.ko by just instantiating a xhci-platform
> > device so xhci-plat can probe.
> > 
> > xhci core has no means to know if its own device or the parent of its
> > parent should be used for DMA. Any ideas?
> 
> In theory, you can store a flag somewhere in the platform device,
> something that would tell xhci-hcd that it has to use the parent's
> parent for DMA purposes.
> 
> I know it would be somewhat of a hack, but ought to work.

Speaking of that flag, I suppose we need the same logic to know where
to look for USB devices attached to a dwc3 host when we need to describe
them in DT. By default we look for child device nodes under the
node of the HCD device node, but that would be wrong here too.

	Arnd 

[toc] | [prev] | [next] | [standalone]

#1478012 — Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

Hi Arnd,

On 02/09/16 18:51, Arnd Bergmann wrote:
> On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote:
>> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>>
>>> Hi,
>>>
>>> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>>>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>>>>>
>>>>>> 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?
>>>>>
>>>>> I'd say it's no problem for a driver to create child devices in order
>>>>> to represent different aspects of a device, but you should not rely on
>>>>> those devices working when used with the dma-mapping interfaces.
>>>>
>>>> That's absolutely right.  Consider the USB model - only the USB host
>>>> controller can perform DMA, not the USB devices themselves.  All DMA
>>>> mappings need to be mapped using the USB host controller device struct
>>>> not the USB device struct.
>>>>
>>>> The same _should_ be true everywhere else: the struct device representing
>>>> the device performing DMA must be the one used to map the transfer.
>>>
>>> How do we fix dwc3 in dual-role, then?
>>>
>>> Peripheral-side dwc3 is easy, we just require a glue-layer to be present
>>> and use dwc3.ko's parent device (which will be the PCI device or OF
>>> device). But for host side dwc3, the problem is slightly more complex
>>> because we're using xhci-plat.ko by just instantiating a xhci-platform
>>> device so xhci-plat can probe.
>>>
>>> xhci core has no means to know if its own device or the parent of its
>>> parent should be used for DMA. Any ideas?
>>
>> In theory, you can store a flag somewhere in the platform device,
>> something that would tell xhci-hcd that it has to use the parent's
>> parent for DMA purposes.
>>
>> I know it would be somewhat of a hack, but ought to work.
> 
> Speaking of that flag, I suppose we need the same logic to know where
> to look for USB devices attached to a dwc3 host when we need to describe
> them in DT. By default we look for child device nodes under the
> node of the HCD device node, but that would be wrong here too.

I didn't get this part. Information about USB devices attached to a USB host
is never provided in DT because they are always dynamically created via
usb_new_device(), whether they are hard-wired on the board or hot-plugged.

These USB devices inherit their DMA masks in the usb_alloc_dev() routine
whereas each interface within the USB device inherits its DMA mask in
usb_set_configuration().

There is a bug  in the USB core because of which the ISB device and interfaces
do not inherit dma_pfn_offset correctly for which I've sent a patch
https://lkml.org/lkml/2016/8/17/275

cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1478073

On Wednesday, September 7, 2016 10:17:31 AM CEST Roger Quadros wrote:
> > 
> > Speaking of that flag, I suppose we need the same logic to know where
> > to look for USB devices attached to a dwc3 host when we need to describe
> > them in DT. By default we look for child device nodes under the
> > node of the HCD device node, but that would be wrong here too.
> 
> I didn't get this part. Information about USB devices attached to a USB host
> is never provided in DT because they are always dynamically created via
> usb_new_device(), whether they are hard-wired on the board or hot-plugged.
> 
> These USB devices inherit their DMA masks in the usb_alloc_dev() routine
> whereas each interface within the USB device inherits its DMA mask in
> usb_set_configuration().

We had talked about adding support for this for at least six years (probably
much more), but Peter Chen finally added it this year in commit 69bec72598
("USB: core: let USB device know device node").

The main use for it is to let you specify a MAC address for on-board
ethernet devices that lack an EPROM, but any other information can be
added that way too.

> There is a bug  in the USB core because of which the ISB device and interfaces
> do not inherit dma_pfn_offset correctly for which I've sent a patch
> https://lkml.org/lkml/2016/8/17/275

I'm a bit skeptical about this. Clearly if we set the dma_mask, we should
also set the dma_pfn_offset, but what exactly is this used for in USB
devices?

As I understand it, the dma_mask/dma_pfn_offset etc is used for the DMA
mapping interface, but that can't really be used on USB devices, which
I assume use usb_alloc_coherent() and the URB interfaces for passing data
between a USB driver and the HCD. My knowledge of USB device drivers
is a bit lacking, so it's possible I'm misunderstanding things here.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1478278 — Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On 07/09/16 11:29, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 10:17:31 AM CEST Roger Quadros wrote:
>>>
>>> Speaking of that flag, I suppose we need the same logic to know where
>>> to look for USB devices attached to a dwc3 host when we need to describe
>>> them in DT. By default we look for child device nodes under the
>>> node of the HCD device node, but that would be wrong here too.
>>
>> I didn't get this part. Information about USB devices attached to a USB host
>> is never provided in DT because they are always dynamically created via
>> usb_new_device(), whether they are hard-wired on the board or hot-plugged.
>>
>> These USB devices inherit their DMA masks in the usb_alloc_dev() routine
>> whereas each interface within the USB device inherits its DMA mask in
>> usb_set_configuration().
> 
> We had talked about adding support for this for at least six years (probably
> much more), but Peter Chen finally added it this year in commit 69bec72598
> ("USB: core: let USB device know device node").

OK. Thanks for this pointer.
> 
> The main use for it is to let you specify a MAC address for on-board
> ethernet devices that lack an EPROM, but any other information can be
> added that way too.
> 
>> There is a bug  in the USB core because of which the ISB device and interfaces
>> do not inherit dma_pfn_offset correctly for which I've sent a patch
>> https://lkml.org/lkml/2016/8/17/275
> 
> I'm a bit skeptical about this. Clearly if we set the dma_mask, we should
> also set the dma_pfn_offset, but what exactly is this used for in USB
> devices?

Consider the mass storage device case.
USB storage driver creates a scsi host for the mass storage interface in
drivers/usb/storage/usb.c
The scsi host parent device is nothing but the the USB interface device.

Now, __scsi_init_queue() calls scsi_calculate_bounce_limit() to find out
and set the block layer bounce limit.

scsi_calculate_bounce_limit() uses dma_max_pfn(host_dev) to get the bounce_limit.

host_dev is nothing but the device representing the mass storage interface.

If that device doesn't have the right dma_pfn_offset, then dma_max_pfn()
is messed up and the bounce buffer limit is wrong.

> 
> As I understand it, the dma_mask/dma_pfn_offset etc is used for the DMA
> mapping interface, but that can't really be used on USB devices, which
> I assume use usb_alloc_coherent() and the URB interfaces for passing data
> between a USB driver and the HCD. My knowledge of USB device drivers
> is a bit lacking, so it's possible I'm misunderstanding things here.
> 

cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1478338

On Wednesday, September 7, 2016 4:04:52 PM CEST Roger Quadros wrote:
> > The main use for it is to let you specify a MAC address for on-board
> > ethernet devices that lack an EPROM, but any other information can be
> > added that way too.
> > 
> >> There is a bug  in the USB core because of which the ISB device and interfaces
> >> do not inherit dma_pfn_offset correctly for which I've sent a patch
> >> https://lkml.org/lkml/2016/8/17/275
> > 
> > I'm a bit skeptical about this. Clearly if we set the dma_mask, we should
> > also set the dma_pfn_offset, but what exactly is this used for in USB
> > devices?
> 
> Consider the mass storage device case.
> USB storage driver creates a scsi host for the mass storage interface in
> drivers/usb/storage/usb.c
> The scsi host parent device is nothing but the the USB interface device.
> 
> Now, __scsi_init_queue() calls scsi_calculate_bounce_limit() to find out
> and set the block layer bounce limit.
> 
> scsi_calculate_bounce_limit() uses dma_max_pfn(host_dev) to get the bounce_limit.
> 
> host_dev is nothing but the device representing the mass storage interface.
> 
> If that device doesn't have the right dma_pfn_offset, then dma_max_pfn()
> is messed up and the bounce buffer limit is wrong.

I see. The same thing probably happens in the network and mmc subsystems,
which have similar code.

This shows the inconsistencies we have in the handling for bounce buffers
in the kernel, which are sometimes handled by subsystems but sometimes
rely on swiotlb instead. I don't have any better idea than your patch
here, but maybe we should add a comment explaining that next to the
code.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1475334 — Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On 09/02/2016 02:08 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Russell King - ARM Linux <linux@armlinux.org.uk> writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>>>
>>>> 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?
>>>
>>> I'd say it's no problem for a driver to create child devices in order
>>> to represent different aspects of a device, but you should not rely on
>>> those devices working when used with the dma-mapping interfaces.
>>
>> That's absolutely right.  Consider the USB model - only the USB host
>> controller can perform DMA, not the USB devices themselves.  All DMA
>> mappings need to be mapped using the USB host controller device struct
>> not the USB device struct.
>>
>> The same _should_ be true everywhere else: the struct device representing
>> the device performing DMA must be the one used to map the transfer.
> 
> How do we fix dwc3 in dual-role, then?
> 
> Peripheral-side dwc3 is easy, we just require a glue-layer to be present
> and use dwc3.ko's parent device (which will be the PCI device or OF
> device). But for host side dwc3, the problem is slightly more complex
> because we're using xhci-plat.ko by just instantiating a xhci-platform
> device so xhci-plat can probe.
> 
> xhci core has no means to know if its own device or the parent of its
> parent should be used for DMA. Any ideas?
> 

Wouldn't be possible to use dma_mask for such purposes?
Like, case 1:
 dwc3-omap (dma_mask=X) -> dwc3 (dma_mask = NULL) -> xhci-plat (NULL)
and then it might be possible to find proper parent by traversing DD
hierarchy.

or :
dwc3 (dma_mask = X) -> xhci-plat (NULL)

or :
xhci-plat (dma_mask = X)

of course, it might be needed to skip DMA configuration for devices
which parents have been configured for dma already (easy for xhci-plat,
but can be not easy for dwc3).

just thinking..

Also, I'd like to note that problem become more complex when scsi layer is used
on top USB ;(

-- 
regards,
-grygorii

[toc] | [prev] | [next] | [standalone]

#1475032

[Multipart message — attachments visible in raw view] — view raw

Hi,

Arnd Bergmann <arnd@arndb.de> writes:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>> 
>> 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?
>
> I'd say it's no problem for a driver to create child devices in order
> to represent different aspects of a device, but you should not rely on
> those devices working when used with the dma-mapping interfaces.

heh, that looks like an excuse to me :-)

This will always be a problem for e.g. MFD, for example. Are you saying
MFD child-devices shouldn't be allowed to do DMA? It becomes silly when
you read it that way, right?

> This used to be simpler back when we could configure the kernel for
> only one SoC platform at a time, and the platforms could provide their
> own overrides for the dma-mapping interfaces. These days, we rely on

right, so we have a very old regression that just took a complex driver
such as dwc3 to trigger ;-)

> firmware or bootloader to describe various aspects of how DMA is done,

there's no DMA description in DT. Every OF device gets the same 32-bit
DMA mask and that is, itself, wrong for several devices.

> so you can't assume that passing a device without an of_node pointer
> or ACPI data into those functions will do the right thing.

That's not the problem, however. We can very easily pass along
ACPI_COMPANION() to any platform_device we want, but that's not enough
because DMA-related bits are passed along with archdata; but archdata
isn't generic in any way. Some arches (like x86) _do_ use it for DMA,
but some don't.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1475078 — Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On 02/09/16 11:53, Felipe Balbi wrote:
> 
> Hi,
> 
> Arnd Bergmann <arnd@arndb.de> writes:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>>
>>> 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?
>>
>> I'd say it's no problem for a driver to create child devices in order
>> to represent different aspects of a device, but you should not rely on
>> those devices working when used with the dma-mapping interfaces.
> 
> heh, that looks like an excuse to me :-)
> 
> This will always be a problem for e.g. MFD, for example. Are you saying
> MFD child-devices shouldn't be allowed to do DMA? It becomes silly when
> you read it that way, right?
> 
>> This used to be simpler back when we could configure the kernel for
>> only one SoC platform at a time, and the platforms could provide their
>> own overrides for the dma-mapping interfaces. These days, we rely on
> 
> right, so we have a very old regression that just took a complex driver
> such as dwc3 to trigger ;-)
> 
>> firmware or bootloader to describe various aspects of how DMA is done,
> 
> there's no DMA description in DT. Every OF device gets the same 32-bit
> DMA mask and that is, itself, wrong for several devices.

Huh? There's only no DMA description in DT if the device can be assumed
to be happy with the defaults. Anything else should be using
"dma-ranges", "dma-coherent", etc. to describe non-default integration
aspects. For devices with an inherent fixed addressing capability !=32
bits, then it's down to the driver to call dma_set_mask() appropriately
to override the default 32-bit mask (which is not unique to OF-probed
devices either).

Sure, it's by no means a perfect API, but you're railing against
untruths here.

Robin.

>> so you can't assume that passing a device without an of_node pointer
>> or ACPI data into those functions will do the right thing.
> 
> That's not the problem, however. We can very easily pass along
> ACPI_COMPANION() to any platform_device we want, but that's not enough
> because DMA-related bits are passed along with archdata; but archdata
> isn't generic in any way. Some arches (like x86) _do_ use it for DMA,
> but some don't.
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[toc] | [prev] | [next] | [standalone]

#1475136

[Multipart message — attachments visible in raw view] — view raw

Hi,

Robin Murphy <robin.murphy@arm.com> writes:
>>>> 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?
>>>
>>> I'd say it's no problem for a driver to create child devices in order
>>> to represent different aspects of a device, but you should not rely on
>>> those devices working when used with the dma-mapping interfaces.
>> 
>> heh, that looks like an excuse to me :-)
>> 
>> This will always be a problem for e.g. MFD, for example. Are you saying
>> MFD child-devices shouldn't be allowed to do DMA? It becomes silly when
>> you read it that way, right?
>> 
>>> This used to be simpler back when we could configure the kernel for
>>> only one SoC platform at a time, and the platforms could provide their
>>> own overrides for the dma-mapping interfaces. These days, we rely on
>> 
>> right, so we have a very old regression that just took a complex driver
>> such as dwc3 to trigger ;-)
>> 
>>> firmware or bootloader to describe various aspects of how DMA is done,
>> 
>> there's no DMA description in DT. Every OF device gets the same 32-bit
>> DMA mask and that is, itself, wrong for several devices.
>
> Huh? There's only no DMA description in DT if the device can be assumed
> to be happy with the defaults. Anything else should be using
> "dma-ranges", "dma-coherent", etc. to describe non-default integration

heh, guilty as charged. I never noticed we had dma-ranges or
dma-coherent.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1475143

On Friday, September 2, 2016 12:55:33 PM CEST Robin Murphy wrote:
> 
> Huh? There's only no DMA description in DT if the device can be assumed
> to be happy with the defaults. Anything else should be using
> "dma-ranges", "dma-coherent", etc. to describe non-default integration
> aspects. For devices with an inherent fixed addressing capability !=32
> bits, then it's down to the driver to call dma_set_mask() appropriately
> to override the default 32-bit mask (which is not unique to OF-probed
> devices either).

The iommu configuration would be the main other one worth mentioning.

Note that there is a known bug with dma_set_mask(), which always succeeds
at the moment, even if the dma-ranges limit the possible addresses
in a way that should fail.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1475480

On Fri, Sep 2, 2016 at 5:43 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>
>> 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?
>
> I'd say it's no problem for a driver to create child devices in order
> to represent different aspects of a device, but you should not rely on
> those devices working when used with the dma-mapping interfaces.
>
> This used to be simpler back when we could configure the kernel for
> only one SoC platform at a time, and the platforms could provide their
> own overrides for the dma-mapping interfaces. These days, we rely on
> firmware or bootloader to describe various aspects of how DMA is done,
> so you can't assume that passing a device without an of_node pointer
> or ACPI data into those functions will do the right thing.

Can we use the firmware or bootloader information to provide the
default dma-mapping attributes for devices that doesn't have an
of_node pointer or ACPI data?  This will at least restore what we had
previously provided .  I'm concerned that changing all the drivers
that are creating child device will be a big effort.  Like I mentioned
in another thread, there are many instances of platform_device_add()
under the drivers/ directory.

- Leo

[toc] | [prev] | [next] | [standalone]

#1476577

On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
> 
> Can we use the firmware or bootloader information to provide the
> default dma-mapping attributes for devices that doesn't have an
> of_node pointer or ACPI data?  This will at least restore what we had
> previously provided .  I'm concerned that changing all the drivers
> that are creating child device will be a big effort.  Like I mentioned
> in another thread, there are many instances of platform_device_add()
> under the drivers/ directory.

Fortunately, there are not too many drivers that call platform_device_add
*and* try to set up a dma mask for the child device:

git grep -wl dma_mask drivers | xargs grep -wl 'platform_device_\(add\|register\)'

drivers/base/platform.c
drivers/bcma/main.c
drivers/eisa/virtual_root.c
drivers/mfd/mfd-core.c
drivers/mfd/omap-usb-host.c
drivers/misc/mic/card/mic_x100.c
drivers/platform/goldfish/pdev_bus.c
drivers/ssb/main.c
drivers/usb/chipidea/core.c
drivers/usb/dwc3/dwc3-exynos.c
drivers/usb/dwc3/host.c
drivers/usb/gadget/udc/bdc/bdc_pci.c
drivers/usb/host/bcma-hcd.c
drivers/usb/host/fsl-mph-dr-of.c
drivers/usb/host/ssb-hcd.c
drivers/usb/misc/ftdi-elan.c
drivers/usb/musb/blackfin.c
drivers/usb/musb/musb_dsps.c
drivers/usb/musb/omap2430.c
drivers/usb/musb/ux500.c

Most of these are probably never used with any nonstandard
DMA settings (IOMMU, cache coherency, offset, ...).

One thing we could possibly do is to go through these and
replace the hardcoded dma mask setup with of_dma_configure()
in all cases in which we actually use DT for probing, which
should cover the interesting cases.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1477099 — Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
> On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
> > 
> > Can we use the firmware or bootloader information to provide the
> > default dma-mapping attributes for devices that doesn't have an
> > of_node pointer or ACPI data?  This will at least restore what we had
> > previously provided .  I'm concerned that changing all the drivers
> > that are creating child device will be a big effort.  Like I mentioned
> > in another thread, there are many instances of platform_device_add()
> > under the drivers/ directory.
> 
> Fortunately, there are not too many drivers that call platform_device_add
> *and* try to set up a dma mask for the child device:
> 
> git grep -wl dma_mask drivers | xargs grep -wl 'platform_device_\(add\|register\)'
> 
> drivers/base/platform.c
> drivers/bcma/main.c
> drivers/eisa/virtual_root.c
> drivers/mfd/mfd-core.c
> drivers/mfd/omap-usb-host.c
> drivers/misc/mic/card/mic_x100.c
> drivers/platform/goldfish/pdev_bus.c
> drivers/ssb/main.c
> drivers/usb/chipidea/core.c
> drivers/usb/dwc3/dwc3-exynos.c
> drivers/usb/dwc3/host.c
> drivers/usb/gadget/udc/bdc/bdc_pci.c
> drivers/usb/host/bcma-hcd.c
> drivers/usb/host/fsl-mph-dr-of.c
> drivers/usb/host/ssb-hcd.c
> drivers/usb/misc/ftdi-elan.c
> drivers/usb/musb/blackfin.c
> drivers/usb/musb/musb_dsps.c
> drivers/usb/musb/omap2430.c
> drivers/usb/musb/ux500.c
> 
> Most of these are probably never used with any nonstandard
> DMA settings (IOMMU, cache coherency, offset, ...).
> 
> One thing we could possibly do is to go through these and
> replace the hardcoded dma mask setup with of_dma_configure()
> in all cases in which we actually use DT for probing, which
> should cover the interesting cases.
> 

One case I am going to work is to let USB chipidea driver support iommu,
the chipidea core device is no of_node, and created by
platform_add_device on the runtime. Using of_dma_configure with parent
of_node is a solution from my point, like [1].

https://lkml.org/lkml/2016/2/22/7

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1477104

[Multipart message — attachments visible in raw view] — view raw

Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
> On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
>> On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
>> > 
>> > Can we use the firmware or bootloader information to provide the
>> > default dma-mapping attributes for devices that doesn't have an
>> > of_node pointer or ACPI data?  This will at least restore what we had
>> > previously provided .  I'm concerned that changing all the drivers
>> > that are creating child device will be a big effort.  Like I mentioned
>> > in another thread, there are many instances of platform_device_add()
>> > under the drivers/ directory.
>> 
>> Fortunately, there are not too many drivers that call platform_device_add
>> *and* try to set up a dma mask for the child device:
>> 
>> git grep -wl dma_mask drivers | xargs grep -wl 'platform_device_\(add\|register\)'
>> 
>> drivers/base/platform.c
>> drivers/bcma/main.c
>> drivers/eisa/virtual_root.c
>> drivers/mfd/mfd-core.c
>> drivers/mfd/omap-usb-host.c
>> drivers/misc/mic/card/mic_x100.c
>> drivers/platform/goldfish/pdev_bus.c
>> drivers/ssb/main.c
>> drivers/usb/chipidea/core.c
>> drivers/usb/dwc3/dwc3-exynos.c
>> drivers/usb/dwc3/host.c
>> drivers/usb/gadget/udc/bdc/bdc_pci.c
>> drivers/usb/host/bcma-hcd.c
>> drivers/usb/host/fsl-mph-dr-of.c
>> drivers/usb/host/ssb-hcd.c
>> drivers/usb/misc/ftdi-elan.c
>> drivers/usb/musb/blackfin.c
>> drivers/usb/musb/musb_dsps.c
>> drivers/usb/musb/omap2430.c
>> drivers/usb/musb/ux500.c
>> 
>> Most of these are probably never used with any nonstandard
>> DMA settings (IOMMU, cache coherency, offset, ...).
>> 
>> One thing we could possibly do is to go through these and
>> replace the hardcoded dma mask setup with of_dma_configure()
>> in all cases in which we actually use DT for probing, which
>> should cover the interesting cases.
>> 
>
> One case I am going to work is to let USB chipidea driver support iommu,
> the chipidea core device is no of_node, and created by
> platform_add_device on the runtime. Using of_dma_configure with parent
> of_node is a solution from my point, like [1].
>
> https://lkml.org/lkml/2016/2/22/7

this only solves the problem for DT devices. Legacy devices and
PCI-based systems will still suffer from the same problem. At least for
dwc3, I will only be taking patches that solve the problem for all
users, not a subset of them.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web