From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Stanislaw Gruszka <sgruszka@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 18:16:51 +0100 [thread overview]
Message-ID: <20190116171650.GD2454@localhost.localdomain> (raw)
In-Reply-To: <20190116143905.GA18221@redhat.com>
> On Wed, Jan 16, 2019 at 02:40:46PM +0100, Lorenzo Bianconi wrote:
> > On Jan 16, Stanislaw Gruszka wrote:
> > > 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.
> >
> > probably amd iommu has some constraints on sg buffer layout respect to intel
> > one, not sure
> >
> > >
> > > > Please not I have not received any confirm that this series fixes the reported issue
> > > > yet :)
> > >
> > > What is reported issue ?
> >
> > https://marc.info/?l=linux-wireless&m=154716096506037&w=2
>
> So, this if for AMD IOMMU issue as I thought initally. For the moment I
> thought you are trying to fix some diffrent problem with some
> non-standart usb host controler.
Why not standard? Most of net usb drivers do not use sg :)
>
> I still think not using sg is just workaround for the problem not worth
> to do, since we have already workaround in form of disabling IOMMU.
> Right fix will be fixing AMD IOMMU driver or fix sg usage in mt76-usb
> if it does something wrong.
I agree with you that this is not strictly a fix for IOMMU issue but I think
we could avoid using sg when we are working just with linear skbs.
But first I guess we need some feedbacks from users
Regards,
Lorenzo
>
> Regards
> Stanislaw
next prev parent reply other threads:[~2019-01-16 17:16 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
2019-01-16 13:40 ` Lorenzo Bianconi
2019-01-16 14:39 ` Stanislaw Gruszka
2019-01-16 17:16 ` Lorenzo Bianconi [this message]
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=20190116171650.GD2454@localhost.localdomain \
--to=lorenzo.bianconi@redhat.com \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=rosenp@gmail.com \
--cc=sgruszka@redhat.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.