On Wed, Jul 18, 2012 at 08:06:17PM +0200, Sedat Dilek wrote:
> On Tue, Jul 17, 2012 at 7:41 AM, Stephen Rothwell
> wrote:
> > Hi all,
> >
> > Changes since 20120716:
> >
>
> Not sure what the root cause of this issue is.
>
> I see the following call-trace in linux-next (next-20120717).
>
> [
Hello,
We have lot of "clear_halt for a busy endpoint" warnings reported.
[ 546.758270] WARNING: at drivers/usb/host/ehci-hcd.c:1051
ehci_endpoint_reset+0x113/0x120()
[ 546.758272] clear_halt for a busy endpoint
...
[ 546.758352] [] warn_slowpath_fmt+0x4c/0x50
[ 546.758355] [] ehci_endpoin
On Thu, Feb 13, 2014 at 11:45:16AM -0500, Alan Stern wrote:
> @@ -1074,6 +1089,7 @@ static int proc_clearhalt(struct dev_sta
> ret = checkintf(ps, ret);
> if (ret)
> return ret;
> + check_reset_of_active_ep(ps->dev, ep, "CLEAR_HALT");
> if (ep & USB_DIR_IN)
>
On Fri, Feb 14, 2014 at 10:31:20AM -0500, Alan Stern wrote:
> On Fri, 14 Feb 2014, Stanislaw Gruszka wrote:
>
> > On Thu, Feb 13, 2014 at 11:45:16AM -0500, Alan Stern wrote:
> > > @@ -1074,6 +1089,7 @@ static int proc_clearhalt(struct dev_sta
> > > ret = check
is quite reproducible for
me, as I can not boot system with threadirqs option, when some USB
device is connected. Patch marks USB irq routines with IRQF_NO_THREAD
to prevent forced threading.
Signed-off-by: Stanislaw Gruszka
---
drivers/usb/core/hcd-pci.c | 4 ++--
1 file changed, 2 insertions(+)
On Mon, Feb 17, 2014 at 09:48:14AM -0500, Alan Stern wrote:
> On Mon, 17 Feb 2014, Stanislaw Gruszka wrote:
>
> > There is threadirqs kenel boot option which allow to force interrupt
> > routines to be performed as thread.
> >
> > USB irq routines use spin_lo
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().
This change can be reverted when hrtimer callbacks become threaded.
Signed-off-by: Stanislaw Gruszka
---
drivers/usb/host/ehci-hcd.c |
On Sat, Feb 09, 2019 at 07:46:37PM +0100, Lorenzo Bianconi wrote:
> > as already reported here [1], that there are probing issues of mt76 using
> > TP-Link Archer T2UH (wifi USB dongle) on Raspberry Pi 3 B+.
> >
> > I retested it with recent linux-next 20190208 (aarch64 defconfig + enabling
> > m
probe error
(and possibly also address AMD IOMMU issue). We seems do not correctly
set URB transfer length smaller than sg buffer length. Attached patch
should correct that.
Stanislaw
>From bc09bc7fa604019a5ef90184390e7c2a3899869d Mon Sep 17 00:00:00 2001
From: Stanislaw Gruszka
Date: Su
On Sun, Feb 10, 2019 at 11:22:25AM +0100, Lorenzo Bianconi wrote:
> > On Sat, Feb 09, 2019 at 09:29:05PM +0100, Stefan Wahren wrote:
> > > > could you please test the following series:
> > > > https://patchwork.kernel.org/cover/10764453/
> > >
> > > yeah this fixed the probing timeout and the drive
On Sun, Feb 10, 2019 at 05:52:30PM +0100, Lorenzo Bianconi wrote:
> Anyway we will need to avoid SG since dwc_otg controller does not support it
What does it mean the dwc_otg does not support SG ? Please be more specific.
Stanislaw
On Mon, Feb 11, 2019 at 04:27:40PM +0100, Stefan Wahren wrote:
> >> All my results refers to the mainline kernel we all should talk about. I
> >> started a gist which try to describe the mainline variant:
> >> https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75
> > So to summarize:
On Mon, Feb 11, 2019 at 10:12:57AM -0500, Alan Stern wrote:
> On Mon, 11 Feb 2019, Lorenzo Bianconi wrote:
>
> > Here it is a different issue respect to the AMD IOMMU one, dwc2 host driver
> > does not implement SG I/O so probing fails. I guess it is still useful to
> > implement a 'legacy' mode t
On Tue, Feb 12, 2019 at 01:06:00AM +0100, Lorenzo Bianconi wrote:
> >
> > On Mon, 11 Feb 2019, Stanislaw Gruszka wrote:
> >
> > > On Mon, Feb 11, 2019 at 10:12:57AM -0500, Alan Stern wrote:
> > > > On Mon, 11 Feb 2019, Lorenzo Bianconi wrote:
> > >
On Tue, Feb 12, 2019 at 12:58:43PM +0100, Lorenzo Bianconi wrote:
> > + usb_fill_bulk_urb(buf->urb, udev, pipe, NULL, buf->len, complete_fn,
> > + context);
> > +
> > + if (udev->bus->sg_tablesize > 0) {
> > + buf->urb->num_sgs = buf->num_sgs;
> > + } else {
> >
On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
> Hi Stanislaw,
>
> > Stanislaw Gruszka hat am 12. Februar 2019 um 10:30
> > geschrieben:
> >
> >
> >
> > In usb_sg_init() urb->num_sgs is set 0 for sg_tablesize = 0 controllers.
>
On Thu, Feb 14, 2019 at 10:48:15AM +0100, Stefan Wahren wrote:
> Hi Stanislaw,
>
> Am 14.02.19 um 10:25 schrieb Stanislaw Gruszka:
> > On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
> >> Hi Stanislaw,
> >>
> >>> Stanis
On Thu, Feb 14, 2019 at 10:48:15AM +0100, Stefan Wahren wrote:
> Hi Stanislaw,
>
> Am 14.02.19 um 10:25 schrieb Stanislaw Gruszka:
> > On Thu, Feb 14, 2019 at 07:49:57AM +0100, Stefan Wahren wrote:
> >> Hi Stanislaw,
> >>
> >>> Stanis
this, plese test, thanks in advance.
> Btw i can confirm a regression was introduced after 4.19, because in 4.19
> there was no firmware timeout but even no working wifi:
You ment 'no working wifi' or 'working wifi'?
Stanislaw
>From 35dadd09bd3193b33b10f56e0210da680c
d8fd761d2fcfedee5701487
Author: Lorenzo Bianconi
Date: Fri Sep 7 23:13:12 2018 +0200
mt76x0: run vco calibration for each channel configuration
It's possible that without this vco calibration fix, MT7610U device
does not see AP if it's signal is weak.
Stanislaw
>From d4
On Mon, Feb 18, 2019 at 03:25:28PM +0100, Lorenzo Bianconi wrote:
> > commit 0d9813319b40399a0d8fd761d2fcfedee5701487
> > Author: Lorenzo Bianconi
> > Date: Fri Sep 7 23:13:12 2018 +0200
>
> [...]
>
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
> > b/drivers/net/wireless/
On Mon, Feb 18, 2019 at 03:43:26PM +0100, Felix Fietkau wrote:
> On 2019-02-18 14:52, Stanislaw Gruszka wrote:
> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
> >> this is a misunderstanding. The warning is about memory alignment to 32
> >> bi
On Mon, Feb 18, 2019 at 07:52:27PM +0100, Felix Fietkau wrote:
> On 2019-02-18 16:03, Stanislaw Gruszka wrote:
> > On Mon, Feb 18, 2019 at 03:43:26PM +0100, Felix Fietkau wrote:
> >> On 2019-02-18 14:52, Stanislaw Gruszka wrote:
> >> > On Sat, Feb 16, 2019 at 08:17:0
On Mon, Feb 18, 2019 at 11:19:40PM +0100, Stefan Wahren wrote:
> Hi,
>
> > Stanislaw Gruszka hat am 18. Februar 2019 um 14:52
> > geschrieben:
> >
> >
> > On Sat, Feb 16, 2019 at 08:17:07PM +0100, Stefan Wahren wrote:
> > > this is a misunderstand
On Tue, Feb 19, 2019 at 10:40:47AM -0500, Alan Stern wrote:
> On Tue, 19 Feb 2019, Stanislaw Gruszka wrote:
>
> > It would be interesting why urb->num_sgs = 0 & urb->sg cause
> > the troubles. This is how usb_sg_init() submit urbs for sg_tablesize = 0
> > control
ow
related code is now tangled.
Would be ok to send this patch with proper changelog as fix for RPI
against wireless-drivers and cc:stable (assuming it works and really
fix things on RPI) and revert Lorenzo's patches in -next ?
Stanislaw
>From 4f8d7d3f4031b0a97b3bb147cb7e52533886e7cc M
On Wed, Feb 20, 2019 at 02:22:08PM +0100, Lorenzo Bianconi wrote:
> > On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > > >> >> The way I see it, we have two choices.
> > > >> >> 1. Fix dwc2 to do its alignment quirk for the urb->sg != NULL case
> > > >> >> 2. Rely on urb->transfer
On Wed, Feb 20, 2019 at 05:22:18PM +0100, Lorenzo Bianconi wrote:
> > On Wed, Feb 20, 2019 at 02:22:08PM +0100, Lorenzo Bianconi wrote:
> > > > On Tue, Feb 19, 2019 at 01:19:26PM +0100, Felix Fietkau wrote:
> > > > > >> >> The way I see it, we have two choices.
> > > > > >> >> 1. Fix dwc2 to do its
28 matches
Mail list logo
