All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc: "hch@lst.de" <hch@lst.de>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"marex@denx.de" <marex@denx.de>, Leo Li <leoyang.li@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"noring@nocrew.org" <noring@nocrew.org>,
	"JuergenUrban@gmx.de" <JuergenUrban@gmx.de>
Subject: Re: [PATCH v4 1/3] USB: use genalloc for USB HCs with local memory
Date: Tue, 21 May 2019 13:15:51 +0200	[thread overview]
Message-ID: <20190521111551.GA24591@kroah.com> (raw)
In-Reply-To: <e71c7f9d-2299-827d-821f-591e134f4a8f@nxp.com>

On Tue, May 21, 2019 at 11:04:12AM +0000, Laurentiu Tudor wrote:
> 
> 
> On 21.05.2019 11:16, Greg KH wrote:
> > On Thu, May 16, 2019 at 02:47:19PM +0300, laurentiu.tudor@nxp.com wrote:
> >> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> >>
> >> For HCs that have local memory, replace the current DMA API usage
> >> with a genalloc generic allocator to manage the mappings for these
> >> devices.
> >> This is in preparation for dropping the existing "coherent" dma
> >> mem declaration APIs. Current implementation was relying on a short
> >> circuit in the DMA API that in the end, was acting as an allocator
> >> for these type of devices.
> >>
> >> For context, see thread here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F4%2F22%2F357&amp;data=02%7C01%7Claurentiu.tudor%40nxp.com%7Cf5242fb28d154ff9653208d6ddc4b41c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636940234237524499&amp;sdata=KEEUP1KH%2BaraWcVKogeYBzrauh%2FFTzGjSxjk%2BuNozjA%3D&amp;reserved=0
> >>
> >> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> >> ---
> >>   drivers/usb/core/buffer.c   | 15 +++++++++++----
> >>   drivers/usb/host/ohci-hcd.c | 23 ++++++++++++++++++-----
> >>   include/linux/usb/hcd.h     |  3 +++
> >>   3 files changed, 32 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
> >> index f641342cdec0..22a8f3f5679b 100644
> >> --- a/drivers/usb/core/buffer.c
> >> +++ b/drivers/usb/core/buffer.c
> >> @@ -16,6 +16,7 @@
> >>   #include <linux/io.h>
> >>   #include <linux/dma-mapping.h>
> >>   #include <linux/dmapool.h>
> >> +#include <linux/genalloc.h>
> >>   #include <linux/usb.h>
> >>   #include <linux/usb/hcd.h>
> >>   
> >> @@ -124,10 +125,12 @@ void *hcd_buffer_alloc(
> >>   	if (size == 0)
> >>   		return NULL;
> >>   
> >> +	if (hcd->driver->flags & HCD_LOCAL_MEM)
> >> +		return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
> > 
> > Does this patch now break things?  hcd->localmem_pool at this point in
> > time is NULL, so this call will fail.  There's no chance for any host
> > controller driver to actually set up this pool in this patch, so is
> > bisection broken?
> 
> Unfortunately, yes. I could lump the patches together but I think 
> Christoph suggestion is much better.

I do too, can you redo these patches to work in that manner please?

thanks,

greg k-h

  reply	other threads:[~2019-05-21 11:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 11:47 [PATCH v4 0/3] prerequisites for device reserved local mem rework laurentiu.tudor
2019-05-16 11:47 ` [PATCH v4 1/3] USB: use genalloc for USB HCs with local memory laurentiu.tudor
2019-05-21  8:16   ` Greg KH
2019-05-21 10:28     ` Christoph Hellwig
2019-05-21 11:04     ` Laurentiu Tudor
2019-05-21 11:15       ` Greg KH [this message]
2019-05-16 11:47 ` [PATCH v4 2/3] usb: host: ohci-sm501: init genalloc for " laurentiu.tudor
2019-05-21 10:39   ` Christoph Hellwig
2019-05-21 11:08     ` Laurentiu Tudor
2019-05-16 11:47 ` [PATCH v4 3/3] usb: host: ohci-tmio: " laurentiu.tudor

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=20190521111551.GA24591@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=JuergenUrban@gmx.de \
    --cc=hch@lst.de \
    --cc=laurentiu.tudor@nxp.com \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=noring@nocrew.org \
    --cc=robin.murphy@arm.com \
    --cc=stern@rowland.harvard.edu \
    /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: link
Be 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.