All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: nbd@nbd.name, linux-wireless@vger.kernel.org, rosenp@gmail.com
Subject: Re: [RFC 0/4] do not use sg if not properly supported by usb controller
Date: Wed, 16 Jan 2019 13:21:46 +0100	[thread overview]
Message-ID: <20190116122145.GA7472@redhat.com> (raw)
In-Reply-To: <20190116114432.GA2454@localhost.localdomain>

On Wed, Jan 16, 2019 at 12:44:33PM +0100, Lorenzo Bianconi wrote:
> > On Tue, Jan 15, 2019 at 04:47:47PM +0100, Lorenzo Bianconi wrote:
> > > Hi Stanislaw,
> > 
> > Hi :-)
> > 
> > > > Not sure what is the problem , but this patch set look like a workaround
> > > > not fix. If this an issue with IOMMU and sg, seems there is something wrong
> > > > in sg page mappings eigher on mt76 dirver or IOMMU driver.
> > > 
> > > The main point here I guess is we do not need sg if fragment number is one (e.g
> > > usb2.0). Moreover this can fix IOMMU reported issues.
> > 
> > So there if diffrence for USB host driver when we have one usb->sg
> > sengment and if we just pass the buffer via urb->transfer_buf . I think
> > most USB host drivers behave the same in such cases. For what USB
> > hardware/driver this is needed ? Perhaps simpler fix could be done
> > in USB host driver?
> 
> According to https://github.com/torvalds/linux/blob/master/drivers/usb/core/hcd.c#L1557
> single sg urb and urb with a configured transfer_buf are managed in a different way.

But this should not make any difference for underlying low level USB
host driver, since we map 1 buffer of the same size, just by using
different routines for that.

> Please not I have not received any confirm that this series fixes the reported issue
> yet :)

What is reported issue ?

Thanks
Stanislaw

  reply	other threads:[~2019-01-16 12:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 12:33 [RFC 0/4] do not use sg if not properly supported by usb controller Lorenzo Bianconi
2019-01-15 12:33 ` [RFC 1/4] mt76: usb: move mt76u_check_sg in usb.c Lorenzo Bianconi
2019-01-15 12:33 ` [RFC 2/4] mt76: usb: do not use sg buffer for fw upload Lorenzo Bianconi
2019-01-15 12:33 ` [RFC 3/4] mt76: usb: use a linear buffer for tx/rx datapath if sg is not supported Lorenzo Bianconi
2019-01-15 12:33 ` [RFC 4/4] mt76: usb: introduce disable_usb_sg parameter Lorenzo Bianconi
2019-01-15 15:35 ` [RFC 0/4] do not use sg if not properly supported by usb controller Stanislaw Gruszka
2019-01-15 15:47   ` Lorenzo Bianconi
2019-01-16 11:19     ` Stanislaw Gruszka
2019-01-16 11:44       ` Lorenzo Bianconi
2019-01-16 12:21         ` Stanislaw Gruszka [this message]
2019-01-16 13:40           ` Lorenzo Bianconi
2019-01-16 14:39             ` Stanislaw Gruszka
2019-01-16 17:16               ` Lorenzo Bianconi
2019-01-16 17:40     ` Rosen Penev

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=20190116122145.GA7472@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=nbd@nbd.name \
    --cc=rosenp@gmail.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: 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.