have a respun version ready, but I'd really like to hear some
> comments from usb developers about the approach before spamming
> everyone again..
I didn't see any problems with your approach at first glance; it looked
like a good idea.
Alan Stern
_
56 bytes?
Yes, we can. In fact, the SCSI core doesn't handle devices with block
size < 512.
> In any case, I am looking into adding SG support vhci-hci at the moment.
>
> Looks like the following is the repo, I should be working with?
>
> git://git.infradead.org/users/hch/misc.git
It doesn't matter. Your work should end up being independent of
Christoph's, so you can base it on any repo.
Alan Stern
e in plan
> to drop virt_boundary_mask stuff?
Not yet. But since it doesn't do what we want anyway, this should be
fixed quickly.
Alan Stern
On Thu, 13 Jun 2019, Christoph Hellwig wrote:
> On Wed, Jun 12, 2019 at 10:43:11AM -0400, Alan Stern wrote:
> > Would it be okay to rely on the assumption that USB block devices never
> > have block size < 512? (We could even add code to the driver to
> > enforce
occasional error.)
As I mentioned before, the only HCD that sometimes ends up with
maxpacket = 1024 but is unable to do full SG is vhci-hcd, and that one
shouldn't be too hard to fix.
Alan Stern
e2(): us->pusb_dev->bus->sysdev.
>From uas_probe(): udev->bus->sysdev.
The ->sysdev field points to the device used for DMA mapping. It is
often the same as ->controller, but sometimes it is
->controller->parent because of the peculiarities of some platforms.
Alan Stern
gs of the block layer. If you can suggest a better way to
express our requirement, that would be great.
Alan Stern
PS: There _is_ a flag saying whether an HCD supports SG. But what it
means is that the driver can handle an SG list that meets the
requirement above; it doesn't mean that the d
t controllers?
As far as I know, the other host controller drivers don't really care
how this is done. xHCI is the only technology where the hardware has
to verify the bandwidth requirements. (Maybe some other SuperSpeed
controller design also cares, but if so then this change is unlikely to
hurt.
n for the new altsetting to be
performed before the old altsetting has been disabled, and the xHCI
hardware can't do this.
We may need to change the core so that the old endpoints are disabled
before the bandwidth check is done, instead of after. Of course, this
leads to an awkward situation if th
On Tue, 17 Jul 2018, Sudip Mukherjee wrote:
> On Tue, Jul 17, 2018 at 03:40:22PM +0100, Sudip Mukherjee wrote:
> > Hi Alan,
> >
> > On Tue, Jul 17, 2018 at 10:28:14AM -0400, Alan Stern wrote:
> > > On Tue, 17 Jul 2018, Sudip Mukherjee wrote:
> > >
&g
to...
> + */
> + return 0;
> + }
> +
> /* Make sure we have enough bandwidth for this alternate interface.
>* Remove the current alt setting and add the new alt setting.
> */
No, neither of these is right. It's possible to use
usb_set_inte
lthough a comment refers to it.
Maybe this is the real problem?
Alan Stern
> But then usb_set_interface() continues and
> calls usb_disable_interface() -> usb_hcd_flush_endpoint()->unlink1()->
> xhci_urb_dequeue() which at the end gives the command to stop endpoint.
>
>
On Sun, 4 Mar 2018, Fredrik Noring wrote:
> Hi Alan Stern,
>
> > > Alan, can dma_free_coherent be delayed to a point when IRQs are enabled?
> >
> > Yes, subject to the usual concerns about not being delayed for too
> > long. Also, some HCDs are highly
lso, some HCDs are highly memory-constrained. I don't know if
they use this API, but if they do then delaying a free could result in
not enough memory being available when an allocation is needed.
Alan Stern
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
mailing lists.
Alan Stern
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
15 matches
Mail list logo