From: Felipe Balbi <balbi@kernel.org> To: Arnd Bergmann <arnd@arndb.de> Cc: Peter Chen <hzpeterchen@gmail.com>, Leo Li <pku.leo@gmail.com>, Grygorii Strashko <grygorii.strashko@ti.com>, Russell King - ARM Linux <linux@arm.linux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>, "linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>, Sekhar Nori <nsekhar@ti.com>, lkml <linux-kernel@vger.kernel.org>, Stuart Yoder <stuart.yoder@nxp.com>, Scott Wood <oss@buserror.net>, David Fisher <david.fisher1@synopsys.com>, "Thang Q. Nguyen" <tqnguyen@apm.com>, Alan Stern <stern@rowland.harvard.edu>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "linux-arm-kernel\@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Date: Thu, 08 Sep 2016 11:03:10 +0300 [thread overview] Message-ID: <8737lakedd.fsf@linux.intel.com> (raw) In-Reply-To: <3189648.KnWLgq0lTY@wuerfel> [-- Attachment #1: Type: text/plain, Size: 6170 bytes --] Hi, Arnd Bergmann <arnd@arndb.de> writes: >> Arnd Bergmann <arnd@arndb.de> writes: >> >> [...] >> >> > Regarding the DMA configuration that you mention in ci_hdrc_add_device(), >> > I think we should replace >> > >> > pdev->dev.dma_mask = dev->dma_mask; >> > pdev->dev.dma_parms = dev->dma_parms; >> > dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); >> > >> > with of_dma_configure(), which has the chance to configure more than >> > just those three, as the dma API might look into different aspects: >> > >> > - iommu specific configuration >> > - cache coherency information >> > - bus type >> > - dma offset >> > - dma_map_ops pointer >> > >> > We try to handle everything in of_dma_configure() at configuration >> > time, and that would be the place to add anything else that we might >> > need in the future. >> >> There are a couple problems with this: >> >> 1) won't work for PCI-based systems. >> >> DWC3 is used in production PCI-based HW and also in Synopsys HAPS DX >> platform (FPGA that appears like a PCI card to host PC) > > Right, I was specifically talking about the code in chipidea here, > which I think is never used on the PCI bus, and how the current just look at the history of the file, you'll see that an Intel employee was a maintainer of chipidea driver. Also: $ git ls-files drivers/usb/chipidea/ | grep pci drivers/usb/chipidea/ci_hdrc_pci.c > code is broken. We can probably do better than of_dma_configure() > (see below), but it would be an improvement. > >> 2) not very robust solution >> >> of_dma_configure() will hardcode 32-bit DMA dmask for xhci-plat because >> that's not created by DT. The only reason why this works at all is >> because of the default 32-bit dma mask thing :-) So, how is it any >> different than copying 32-bit dma mask from parent? > > The idea here is that you pass in the parent of_node along with the child > device pointer, so it would behave exactly like the parent already does. > The difference is that it also handles all the other attributes besides the mask. Now we're talking :-) I like that. We just need a matching API for ACPI/PCI-based systems. > However, to summarize the discussion so far, I agree that > of_dma_configure() is not the solution to these problems, and I think > we can do much better: > > Splitting the usb_bus->controller field into the Linux-internal device > (used for the sysfs hierarchy, for printks and for power management) > and a new pointer (used for DMA, DT enumeration and phy lookup) probably > covers all that we really need. > > I've prototyped it below, with the dwc3, xhci and chipidea changes > together with the core changes. I've surely made mistakes there and > don't expect it to work out of the box, but this should give an > idea of how I think this can all be solved in the least invasive > way. > > I noticed that the gadget interface already has a way to handle the > DMA allocation by device, so I added that in as well. yeah, I wanna use that :-) > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index 35d092456bec..08db66c64c66 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -25,6 +25,7 @@ > #include <linux/slab.h> > #include <linux/spinlock.h> > #include <linux/platform_device.h> > +#include <linux/pci.h> actually, we don't want the core to know what it's attached to. > #include <linux/pm_runtime.h> > #include <linux/interrupt.h> > #include <linux/ioport.h> > @@ -178,7 +179,7 @@ static void dwc3_frame_length_adjustment(struct dwc3 *dwc) > static void dwc3_free_one_event_buffer(struct dwc3 *dwc, > struct dwc3_event_buffer *evt) > { > - dma_free_coherent(dwc->dev, evt->length, evt->buf, evt->dma); > + dma_free_coherent(dwc->sysdev, evt->length, evt->buf, evt->dma); how about "dma_dev" instead? Is this used for anything other than DMA? > @@ -846,6 +847,13 @@ static int dwc3_probe(struct platform_device *pdev) > dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); > dwc->mem = mem; > dwc->dev = dev; > +#ifdef CONFIG_PCI > + /* TODO: or some other way of detecting this? */ > + if (dwc->dev->parent && dwc->dev->parent->bus == &pci_bus_type) > + dwc->sysdev = dwc->dev->parent; > + else > +#endif > + dwc->sysdev = dwc->dev; Well, we can remove this ifdef and *always* use the parent. We will just require that dwc3 users provide a glue layer. In that case, your check becomes: if (dwc->dev->parent) dwc->sysdev = dwc->dev->parent; else dev_info(dwc->dev, "Please provide a glue layer!\n"); > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c > index 2f1fb7e7aa54..e27899bb5706 100644 > --- a/drivers/usb/dwc3/dwc3-exynos.c > +++ b/drivers/usb/dwc3/dwc3-exynos.c > @@ -20,7 +20,6 @@ > #include <linux/kernel.h> > #include <linux/slab.h> > #include <linux/platform_device.h> > -#include <linux/dma-mapping.h> > #include <linux/clk.h> > #include <linux/usb/otg.h> > #include <linux/usb/usb_phy_generic.h> > @@ -117,15 +116,6 @@ static int dwc3_exynos_probe(struct platform_device *pdev) > if (!exynos) > return -ENOMEM; > > - /* > - * Right now device-tree probed devices don't get dma_mask set. > - * Since shared usb code relies on it, set it here for now. > - * Once we move to full device tree support this will vanish off. > - */ > - ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > - if (ret) > - return ret; this is a separate patch, right? > diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c > index 89a2f712fdfe..4d7439cb8cd8 100644 > --- a/drivers/usb/dwc3/dwc3-st.c > +++ b/drivers/usb/dwc3/dwc3-st.c > @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev) > if (IS_ERR(regmap)) > return PTR_ERR(regmap); > > - dma_set_coherent_mask(dev, dev->coherent_dma_mask); so is this. All in all, I like where you're going with this, we just need a matching acpi_dma_configure() and problems will be sorted out. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 800 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: balbi@kernel.org (Felipe Balbi) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Date: Thu, 08 Sep 2016 11:03:10 +0300 [thread overview] Message-ID: <8737lakedd.fsf@linux.intel.com> (raw) In-Reply-To: <3189648.KnWLgq0lTY@wuerfel> Hi, Arnd Bergmann <arnd@arndb.de> writes: >> Arnd Bergmann <arnd@arndb.de> writes: >> >> [...] >> >> > Regarding the DMA configuration that you mention in ci_hdrc_add_device(), >> > I think we should replace >> > >> > pdev->dev.dma_mask = dev->dma_mask; >> > pdev->dev.dma_parms = dev->dma_parms; >> > dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask); >> > >> > with of_dma_configure(), which has the chance to configure more than >> > just those three, as the dma API might look into different aspects: >> > >> > - iommu specific configuration >> > - cache coherency information >> > - bus type >> > - dma offset >> > - dma_map_ops pointer >> > >> > We try to handle everything in of_dma_configure() at configuration >> > time, and that would be the place to add anything else that we might >> > need in the future. >> >> There are a couple problems with this: >> >> 1) won't work for PCI-based systems. >> >> DWC3 is used in production PCI-based HW and also in Synopsys HAPS DX >> platform (FPGA that appears like a PCI card to host PC) > > Right, I was specifically talking about the code in chipidea here, > which I think is never used on the PCI bus, and how the current just look at the history of the file, you'll see that an Intel employee was a maintainer of chipidea driver. Also: $ git ls-files drivers/usb/chipidea/ | grep pci drivers/usb/chipidea/ci_hdrc_pci.c > code is broken. We can probably do better than of_dma_configure() > (see below), but it would be an improvement. > >> 2) not very robust solution >> >> of_dma_configure() will hardcode 32-bit DMA dmask for xhci-plat because >> that's not created by DT. The only reason why this works at all is >> because of the default 32-bit dma mask thing :-) So, how is it any >> different than copying 32-bit dma mask from parent? > > The idea here is that you pass in the parent of_node along with the child > device pointer, so it would behave exactly like the parent already does. > The difference is that it also handles all the other attributes besides the mask. Now we're talking :-) I like that. We just need a matching API for ACPI/PCI-based systems. > However, to summarize the discussion so far, I agree that > of_dma_configure() is not the solution to these problems, and I think > we can do much better: > > Splitting the usb_bus->controller field into the Linux-internal device > (used for the sysfs hierarchy, for printks and for power management) > and a new pointer (used for DMA, DT enumeration and phy lookup) probably > covers all that we really need. > > I've prototyped it below, with the dwc3, xhci and chipidea changes > together with the core changes. I've surely made mistakes there and > don't expect it to work out of the box, but this should give an > idea of how I think this can all be solved in the least invasive > way. > > I noticed that the gadget interface already has a way to handle the > DMA allocation by device, so I added that in as well. yeah, I wanna use that :-) > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index 35d092456bec..08db66c64c66 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -25,6 +25,7 @@ > #include <linux/slab.h> > #include <linux/spinlock.h> > #include <linux/platform_device.h> > +#include <linux/pci.h> actually, we don't want the core to know what it's attached to. > #include <linux/pm_runtime.h> > #include <linux/interrupt.h> > #include <linux/ioport.h> > @@ -178,7 +179,7 @@ static void dwc3_frame_length_adjustment(struct dwc3 *dwc) > static void dwc3_free_one_event_buffer(struct dwc3 *dwc, > struct dwc3_event_buffer *evt) > { > - dma_free_coherent(dwc->dev, evt->length, evt->buf, evt->dma); > + dma_free_coherent(dwc->sysdev, evt->length, evt->buf, evt->dma); how about "dma_dev" instead? Is this used for anything other than DMA? > @@ -846,6 +847,13 @@ static int dwc3_probe(struct platform_device *pdev) > dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); > dwc->mem = mem; > dwc->dev = dev; > +#ifdef CONFIG_PCI > + /* TODO: or some other way of detecting this? */ > + if (dwc->dev->parent && dwc->dev->parent->bus == &pci_bus_type) > + dwc->sysdev = dwc->dev->parent; > + else > +#endif > + dwc->sysdev = dwc->dev; Well, we can remove this ifdef and *always* use the parent. We will just require that dwc3 users provide a glue layer. In that case, your check becomes: if (dwc->dev->parent) dwc->sysdev = dwc->dev->parent; else dev_info(dwc->dev, "Please provide a glue layer!\n"); > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c > index 2f1fb7e7aa54..e27899bb5706 100644 > --- a/drivers/usb/dwc3/dwc3-exynos.c > +++ b/drivers/usb/dwc3/dwc3-exynos.c > @@ -20,7 +20,6 @@ > #include <linux/kernel.h> > #include <linux/slab.h> > #include <linux/platform_device.h> > -#include <linux/dma-mapping.h> > #include <linux/clk.h> > #include <linux/usb/otg.h> > #include <linux/usb/usb_phy_generic.h> > @@ -117,15 +116,6 @@ static int dwc3_exynos_probe(struct platform_device *pdev) > if (!exynos) > return -ENOMEM; > > - /* > - * Right now device-tree probed devices don't get dma_mask set. > - * Since shared usb code relies on it, set it here for now. > - * Once we move to full device tree support this will vanish off. > - */ > - ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > - if (ret) > - return ret; this is a separate patch, right? > diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c > index 89a2f712fdfe..4d7439cb8cd8 100644 > --- a/drivers/usb/dwc3/dwc3-st.c > +++ b/drivers/usb/dwc3/dwc3-st.c > @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev) > if (IS_ERR(regmap)) > return PTR_ERR(regmap); > > - dma_set_coherent_mask(dev, dev->coherent_dma_mask); so is this. All in all, I like where you're going with this, we just need a matching acpi_dma_configure() and problems will be sorted out. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160908/031d1e45/attachment-0001.sig>
next prev parent reply other threads:[~2016-09-08 8:03 UTC|newest] Thread overview: 182+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-25 19:21 [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Grygorii Strashko 2016-04-25 19:21 ` Grygorii Strashko 2016-04-26 6:17 ` Felipe Balbi 2016-04-26 6:17 ` Felipe Balbi 2016-04-26 8:14 ` Grygorii Strashko 2016-04-26 8:14 ` Grygorii Strashko 2016-04-27 5:41 ` Felipe Balbi 2016-04-27 5:41 ` Felipe Balbi 2016-04-27 11:55 ` Grygorii Strashko 2016-04-27 11:55 ` Grygorii Strashko 2016-04-27 13:59 ` Catalin Marinas 2016-04-27 13:59 ` Catalin Marinas 2016-04-27 14:11 ` Arnd Bergmann 2016-04-27 14:11 ` Arnd Bergmann 2016-04-27 15:50 ` Catalin Marinas 2016-04-27 15:50 ` Catalin Marinas 2016-04-27 16:04 ` Arnd Bergmann 2016-04-27 16:04 ` Arnd Bergmann 2016-04-27 16:53 ` Felipe Balbi 2016-04-27 16:53 ` Felipe Balbi 2016-04-27 17:42 ` Arnd Bergmann 2016-04-27 17:42 ` Arnd Bergmann 2016-04-27 17:59 ` Alan Stern 2016-04-27 17:59 ` Alan Stern 2016-04-27 18:08 ` Arnd Bergmann 2016-04-27 18:08 ` Arnd Bergmann 2016-04-27 20:05 ` Felipe Balbi 2016-04-27 20:05 ` Felipe Balbi 2016-04-27 21:05 ` Arnd Bergmann 2016-04-27 21:05 ` Arnd Bergmann 2016-04-28 6:37 ` Felipe Balbi 2016-04-28 6:37 ` Felipe Balbi 2016-04-28 14:16 ` Russell King - ARM Linux 2016-04-28 14:16 ` Russell King - ARM Linux 2016-04-28 14:23 ` Arnd Bergmann 2016-04-28 14:23 ` Arnd Bergmann 2016-04-28 14:27 ` Felipe Balbi 2016-04-28 14:27 ` Felipe Balbi 2016-09-01 22:14 ` Leo Li 2016-09-01 22:14 ` Leo Li 2016-09-02 10:43 ` Arnd Bergmann 2016-09-02 10:43 ` Arnd Bergmann 2016-09-02 10:47 ` Russell King - ARM Linux 2016-09-02 10:47 ` Russell King - ARM Linux 2016-09-02 11:08 ` Felipe Balbi 2016-09-02 11:08 ` Felipe Balbi 2016-09-02 14:11 ` Felipe Balbi 2016-09-02 14:11 ` Felipe Balbi 2016-09-02 14:21 ` Alan Stern 2016-09-02 14:21 ` Alan Stern 2016-09-02 15:51 ` Arnd Bergmann 2016-09-02 15:51 ` Arnd Bergmann 2016-09-07 7:17 ` Roger Quadros 2016-09-07 7:17 ` Roger Quadros 2016-09-07 8:29 ` Arnd Bergmann 2016-09-07 8:29 ` Arnd Bergmann 2016-09-07 13:04 ` Roger Quadros 2016-09-07 13:04 ` Roger Quadros 2016-09-07 14:38 ` Arnd Bergmann 2016-09-07 14:38 ` Arnd Bergmann 2016-09-02 16:23 ` Grygorii Strashko 2016-09-02 16:23 ` Grygorii Strashko 2016-09-02 10:53 ` Felipe Balbi 2016-09-02 10:53 ` Felipe Balbi 2016-09-02 11:55 ` Robin Murphy 2016-09-02 11:55 ` Robin Murphy 2016-09-02 12:56 ` Felipe Balbi 2016-09-02 12:56 ` Felipe Balbi 2016-09-02 13:10 ` Arnd Bergmann 2016-09-02 13:10 ` Arnd Bergmann 2016-09-02 22:16 ` Leo Li 2016-09-02 22:16 ` Leo Li 2016-09-05 15:39 ` Arnd Bergmann 2016-09-05 15:39 ` Arnd Bergmann 2016-09-06 6:35 ` Peter Chen 2016-09-06 6:35 ` Peter Chen 2016-09-06 6:40 ` Felipe Balbi 2016-09-06 6:40 ` Felipe Balbi 2016-09-06 10:46 ` Arnd Bergmann 2016-09-06 10:46 ` Arnd Bergmann 2016-09-06 10:50 ` Felipe Balbi 2016-09-06 10:50 ` Felipe Balbi 2016-09-06 13:27 ` Arnd Bergmann 2016-09-06 13:27 ` Arnd Bergmann 2016-09-07 6:51 ` Felipe Balbi 2016-09-07 6:51 ` Felipe Balbi 2016-09-07 7:44 ` Peter Chen 2016-09-07 7:44 ` Peter Chen 2016-09-07 8:52 ` Arnd Bergmann 2016-09-07 8:52 ` Arnd Bergmann 2016-09-07 9:29 ` Peter Chen 2016-09-07 9:29 ` Peter Chen 2016-09-07 9:35 ` Russell King - ARM Linux 2016-09-07 9:35 ` Russell King - ARM Linux 2016-09-07 10:18 ` Felipe Balbi 2016-09-07 10:18 ` Felipe Balbi 2016-09-06 10:38 ` Arnd Bergmann 2016-09-06 10:38 ` Arnd Bergmann 2016-09-07 6:33 ` Peter Chen 2016-09-07 6:33 ` Peter Chen 2016-09-07 8:48 ` Arnd Bergmann 2016-09-07 8:48 ` Arnd Bergmann 2016-09-07 9:55 ` Peter Chen 2016-09-07 9:55 ` Peter Chen 2016-09-07 10:33 ` Robin Murphy 2016-09-07 10:33 ` Robin Murphy 2016-09-07 10:47 ` Felipe Balbi 2016-09-07 10:47 ` Felipe Balbi 2016-09-14 16:31 ` Lorenzo Pieralisi 2016-09-14 16:31 ` Lorenzo Pieralisi 2016-09-14 21:50 ` Arnd Bergmann 2016-09-14 21:50 ` Arnd Bergmann 2016-09-07 10:24 ` Felipe Balbi 2016-09-07 10:24 ` Felipe Balbi 2016-09-07 15:24 ` Arnd Bergmann 2016-09-07 15:24 ` Arnd Bergmann 2016-09-07 16:08 ` Alan Stern 2016-09-07 16:08 ` Alan Stern 2016-09-07 19:45 ` Arnd Bergmann 2016-09-07 19:45 ` Arnd Bergmann 2016-09-08 1:15 ` Peter Chen 2016-09-08 1:15 ` Peter Chen 2016-09-08 8:02 ` Arnd Bergmann 2016-09-08 8:02 ` Arnd Bergmann 2016-09-08 8:03 ` Felipe Balbi [this message] 2016-09-08 8:03 ` Felipe Balbi 2016-09-08 8:26 ` Arnd Bergmann 2016-09-08 8:26 ` Arnd Bergmann 2016-09-08 8:29 ` Felipe Balbi 2016-09-08 8:29 ` Felipe Balbi 2016-09-08 8:45 ` Arnd Bergmann 2016-09-08 8:45 ` Arnd Bergmann 2016-09-08 9:43 ` Felipe Balbi 2016-09-08 9:43 ` Felipe Balbi 2016-09-08 10:17 ` Arnd Bergmann 2016-09-08 10:17 ` Arnd Bergmann 2016-09-08 11:00 ` Felipe Balbi 2016-09-08 11:00 ` Felipe Balbi 2016-09-08 11:11 ` Arnd Bergmann 2016-09-08 11:11 ` Arnd Bergmann 2016-09-08 11:20 ` Felipe Balbi 2016-09-08 11:20 ` Felipe Balbi 2016-09-08 11:39 ` Arnd Bergmann 2016-09-08 11:39 ` Arnd Bergmann 2016-09-08 11:52 ` Felipe Balbi 2016-09-08 11:52 ` Felipe Balbi 2016-09-08 12:46 ` Arnd Bergmann 2016-09-08 12:46 ` Arnd Bergmann 2016-09-08 12:02 ` Grygorii Strashko 2016-09-08 12:02 ` Grygorii Strashko 2016-09-08 12:14 ` Arnd Bergmann 2016-09-08 12:14 ` Arnd Bergmann 2016-09-08 12:28 ` Peter Chen 2016-09-08 12:28 ` Peter Chen 2016-09-08 12:52 ` Arnd Bergmann 2016-09-08 12:52 ` Arnd Bergmann 2016-09-09 1:37 ` Peter Chen 2016-09-09 1:37 ` Peter Chen 2016-09-08 12:59 ` Grygorii Strashko 2016-09-08 12:59 ` Grygorii Strashko 2016-09-09 1:52 ` Peter Chen 2016-09-09 1:52 ` Peter Chen 2016-09-21 11:06 ` Sriram Dash 2016-09-21 11:06 ` Sriram Dash 2016-09-21 11:31 ` Arnd Bergmann 2016-09-21 11:31 ` Arnd Bergmann 2016-09-21 11:43 ` Sriram Dash 2016-09-21 11:43 ` Sriram Dash 2016-09-21 12:48 ` Arnd Bergmann 2016-09-21 12:48 ` Arnd Bergmann 2016-09-22 5:02 ` Sriram Dash 2016-09-22 5:02 ` Sriram Dash 2016-10-07 22:46 ` Leo Li 2016-10-07 22:46 ` Leo Li 2016-09-21 17:14 ` [PATCH] usb: xhci: Fix the patch inherit dma configuration from kbuild test robot 2016-09-21 17:14 ` kbuild test robot 2016-04-27 20:57 ` [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi 2016-04-27 20:57 ` Felipe Balbi 2016-04-27 14:14 ` Grygorii Strashko 2016-04-27 14:14 ` Grygorii Strashko 2016-05-05 17:07 ` Brian Norris 2016-05-05 17:07 ` Brian Norris
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8737lakedd.fsf@linux.intel.com \ --to=balbi@kernel.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=david.fisher1@synopsys.com \ --cc=gregkh@linuxfoundation.org \ --cc=grygorii.strashko@ti.com \ --cc=hzpeterchen@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=nsekhar@ti.com \ --cc=oss@buserror.net \ --cc=pku.leo@gmail.com \ --cc=stern@rowland.harvard.edu \ --cc=stuart.yoder@nxp.com \ --cc=tqnguyen@apm.com \ --cc=yoshihiro.shimoda.uh@renesas.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.