| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <871t0uiqn9.fsf@linux.intel.com>
Date: Thu, 08 Sep 2016 14:20:58 +0300
From: Felipe Balbi <balbi@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Peter Chen <hzpeterchen@...il.com>, Leo Li <pku.leo@...il.com>,
Grygorii Strashko <grygorii.strashko@...com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
"linux-usb\@vger.kernel.org" <linux-usb@...r.kernel.org>,
Sekhar Nori <nsekhar@...com>,
lkml <linux-kernel@...r.kernel.org>,
Stuart Yoder <stuart.yoder@....com>,
Scott Wood <oss@...error.net>,
David Fisher <david.fisher1@...opsys.com>,
"Thang Q. Nguyen" <tqnguyen@....com>,
Alan Stern <stern@...land.harvard.edu>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
Hi,
Arnd Bergmann <arnd@...db.de> writes:
> On Thursday, September 8, 2016 2:00:13 PM CEST Felipe Balbi wrote:
>> Arnd Bergmann <arnd@...db.de> writes:
>> > On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
>> >> Arnd Bergmann <arnd@...db.de> writes:
>> >> > That sounds a bit clumsy for the sake of consistency with PCI.
>> >> > The advantage is that xhci can always use the grandparent device
>> >> > as sysdev whenever it isn't probed through PCI or firmware
>> >> > itself, but the purpose of the dwc3-glue is otherwise questionable.
>> >> >
>> >> > How about adding a 'compatible="snps,dwc3-pci"' property for the dwc3
>> >> > device when that is created from the PCI driver and checking for that
>> >> > with the device property interface instead? If it's "snps,dwc3"
>> >> > we use the device itself while for "snps,dwc3-pci", we use the parent?
>> >>
>> >> Any reason why we wouldn't use e.g. dwc3-omap.dev as sysdev?
>> >
>> > That would be incompatible with the USB binding, as the sysdev
>> > is assumed to be a USB host controller with #address-cells=<1>
>> > and #size-cells=<0> in order to hold the child devices, for
>> > example:
>> >
>> > / {
>> > omap_dwc3_1: omap_dwc3_1@...80000 {
>> > compatible = "ti,dwc3";
>> > #address-cells = <1>;
>> > #size-cells = <1>;
>> > ranges;
>> > usb1: usb@...90000 {
>> > compatible = "snps,dwc3";
>> > reg = <0x48890000 0x17000>;
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>> > interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
>> > <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
>> > <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
>> > interrupt-names = "peripheral",
>> > "host",
>> > "otg";
>> > phys = <&usb2_phy1>, <&usb3_phy1>;
>> > phy-names = "usb2-phy", "usb3-phy";
>> >
>> > hub@1 {
>> > compatible = "usb5e3,608";
>> > reg = <1>;
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>> >
>> > ethernet@1 {
>> > compatible = "usb424,ec00";
>> > mac-address = [00 11 22 33 44 55];
>> > reg = <1>;
>> > };
>> > };
>> > };
>> > };
>> >
>> > It's also the node that contains the "phys" properties and
>> > presumably other properties like "otg-rev", "maximum-speed"
>> > etc.
>> >
>> > If we make the sysdev point to the parent, then we can no longer
>> > look up those properties and child devices from the USB core code
>> > by looking at "sysdev->of_node".
>>
>> this also makes things more interesting. I can't of anything other than
>> having some type of flag passed via e.g. device_properties by dwc3-pci.c
>> :-s
>
> Ok.
man, I have been skipping words rather frequently when typing lately. I
meant "I can't THINK of anything other ...."
>> It's quite a hack, though. I still think that inheriting DMA (or
>> manually initializing a child with parent's DMA bits and pieces) is the
>> best way to go. So we're back to of_dma_configure() and
>> acpi_dma_configure(), right?
>
> That won't solve the problems with the DT properties or the
> dma configuration for PCI devices though.
acpi_dma_configure() is supposed to pass along DMA bits from PCI to
child devices, no?
>> But this needs to be done before dwc3_probe() executes. For dwc3-pci
>> that's easy, but for DT devices, seems like it should be in of
>> core. Below is, clearly, not enough but should show the idea:
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index fd5cfad7c403..a54610198946 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -94,8 +94,12 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
>> * setup the correct supported mask.
>> */
>> - if (!dev->coherent_dma_mask)
>> - dev->coherent_dma_mask = DMA_BIT_MASK(32);
>> + if (!dev->coherent_dma_mask) {
>> + if (!dev->parent->coherent_dma_mask)
>> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
>> + else
>> + dev->coherent_dma_mask = dev->parent->coherent_dma_mask;
>> + }
>>
>
> As the comment above that code says, the default 32-bit mask is intentional,
> and you need the driver to ask for the mask it wants using
> dma_set_mask_and_coherent(), while the platform code should be able to use
> dev->of_node to figure out whether that mask is supported.
>
> Just setting the initial mask to something else based on what the parent
> supports will not do the right thing elsewhere.
oh man, it gets more and more complex. Seems like either path we take
will cause problems somewhere :-s
If we make dwc3.ko a library which glue calls directly then all these
problems are solved but we break all current DTs and fall into the trap
of having another MUSB.
If we try to pass DMA bits from parent to child, then we have the fact
that DT ends up, in practice, always having a parent device.
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)
Powered by blists - more mailing lists