From: Christoph Hellwig <hch@lst.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: laurentiu.tudor@nxp.com, hch@lst.de, stern@rowland.harvard.edu,
linux-usb@vger.kernel.org, marex@denx.de, leoyang.li@nxp.com,
linux-kernel@vger.kernel.org, robin.murphy@arm.com,
noring@nocrew.org, JuergenUrban@gmx.de
Subject: Re: [PATCH v4 1/3] USB: use genalloc for USB HCs with local memory
Date: Tue, 21 May 2019 12:28:35 +0200 [thread overview]
Message-ID: <20190521102835.GA1973@lst.de> (raw)
In-Reply-To: <20190521081657.GA10639@kroah.com>
On Tue, May 21, 2019 at 10:16:57AM +0200, Greg KH wrote:
> > + 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?
>
> I think you fix this up in later patches, right?
>
> And if so, why do we even need HCD_LOCAL_MEM anymore? Can't we just
> test for the presence of hcd->localmem_pool in order to determine which
> allocation method to use?
True. And that also sound like a good bisectability strategy:
- first add hcd->localmem_pool and test for it
- convert drivers over to it
- remove HCD_LOCAL_MEM
next prev parent reply other threads:[~2019-05-21 10:29 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 [this message]
2019-05-21 11:04 ` Laurentiu Tudor
2019-05-21 11:15 ` Greg KH
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=20190521102835.GA1973@lst.de \
--to=hch@lst.de \
--cc=JuergenUrban@gmx.de \
--cc=gregkh@linuxfoundation.org \
--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.