On 10/10/2017 01:38, Bjorn Helgaas wrote:
> On Mon, Oct 09, 2017 at 10:45:39PM +0200, Mason wrote:
>> On 09/10/2017 19:01, Bjorn Helgaas wrote:
>> ...
>
>>> In that thread, Mason reported a regression that looks similar, but as
>>> far as I can tell, we never
On 09/10/2017 19:01, Bjorn Helgaas wrote:
> [+cc linux-pci, linux-usb, Mason, Mathias, Lukas, Greg, Felipe, Alan]
>
> - Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
>>
>> Date: Sun, 08 Oct 2017 13:28:13 +
>> From: bugzilla-dae...@bugzilla
On 30/08/2017 11:06, Greg Kroah-Hartman wrote:
> On Wed, Aug 30, 2017 at 10:55:37AM +0200, Mason wrote:
>
>> On 30/08/2017 08:02, Greg Kroah-Hartman wrote:
>>
>>> To get back to the original issue here, the hardware seems to have died,
>>> the driver stops
On 30/08/2017 11:37, Mason wrote:
> On 30/08/2017 11:07, Ard Biesheuvel wrote:
>
>> Please don't forget to mention that this is quirky hardware that
>> depends on BROKEN because it multiplexes MMIO and config space
>> accesses in the same memory window without any
On 30/08/2017 11:07, Ard Biesheuvel wrote:
> Please don't forget to mention that this is quirky hardware that
> depends on BROKEN because it multiplexes MMIO and config space
> accesses in the same memory window without any locking whatsoever
> (which would be difficult to do in the first place be
On 30/08/2017 08:02, Greg Kroah-Hartman wrote:
> To get back to the original issue here, the hardware seems to have died,
> the driver stops talking to it, and all is good. The "regression" here
> is that we now properly can determine that the hardware is crap.
Before 4.12, when I unplugged my U
On 28/08/2017 10:39, Mathias Nyman wrote:
> Could you take a log with the following added debug, without
> your extra delays, It should show a bit more about the state
> of the controller when we read 0x
I applied the following patch on top of v4.12-rc1
diff --git a/drivers/usb/host/xhci
On 23/08/2017 14:41, Mason wrote:
> I compiled a minimal kernel, with lots of irrelevant drivers and
> frameworks left out, including power management. I still get the
> "xHCI host controller not responding, assume dead" issue.
The problem seems to have a timing-related aspec
On 23/08/2017 13:54, Mason wrote:
> On 23/08/2017 13:11, Mathias Nyman wrote:
>
>> In this case we read the register when hub thread asks to clear port feature.
>>
>> why portsc returns 0x is a another question, could the hub thread be
>> running while xhci
On 23/08/2017 13:11, Mathias Nyman wrote:
> On 23.08.2017 12:31, Mason wrote:
>
>> [ 46.525247] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
>> [ 46.565496] usb-storage 2-2:1.0: USB Mass Storage device detected
>> [ 46.571934] scsi host0: usb-storage
On 23/08/2017 09:51, Mathias Nyman wrote:
> very likely cause is the more aggressive detection of pci removed xhci hosts
>
> See commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b
> xhci: Rework how we handle unresponsive or hoptlug removed hosts
>
> It checks if a xhci register reads returns
On 23/08/2017 09:51, Mathias Nyman wrote:
> very likely cause is the more aggressive detection of pci removed xhci hosts
>
> See commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b
> xhci: Rework how we handle unresponsive or hoptlug removed hosts
>
> It checks if a xhci register reads returns
On 23/08/2017 09:51, Mathias Nyman wrote:
> On 23.08.2017 09:07, Felipe Balbi wrote:
>
>> Mason writes:
>>
>>> Any idea what could have changed between 4.9 and 4.13 ?
>>
>> Quite a bit:
>>
>> $ git rev-list --no-merges --count v4.13-rc6 ^v4.9 -
Hello,
The driver for my system's PCIe host bridge landed recently
(in 4.13) but it was developed on 4.9
I tested the PCIe host bridge by plugging a 4-port USB3 adapter
into the PCIe slot (system at rest) and plugging an USB3 Flash
drive into the USB3 adapter (at run-time).
On 4.9, the setup wor
On 14/03/2017 11:23, David Laight wrote:
> Mason wrote:
>
>> I'd like to push support for this PCIe controller upstream.
>>
>> Is the code I posted on the right track?
>> Maybe I can post a RFC patch tomorrow?
>
> I think you need to resolve the problem
On 13/03/2017 22:40, Bjorn Helgaas wrote:
> On Sat, Mar 11, 2017 at 11:57:56AM +0100, Mason wrote:
>
>> On 10/03/2017 18:49, Mason wrote:
>>
>>> static void tango_pcie_bar_quirk(struct pci_dev *dev)
>>> {
>>> struct pci_bus *bus = dev-&g
On 10/03/2017 18:49, Mason wrote:
> And my current code, to work-around the silicon bugs:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> //#define DEBUG_CONFIG
>
> static int tango_config_read(
On 10/03/2017 17:45, Mason wrote:
> Time to clean up a million hacks to be able to discuss the finer points.
Here is my current boot log:
[1.133895] OF: PCI: host bridge /soc/pcie@5000 ranges:
[1.139607] pci_add_resource_offset: res=[bus 00-0f] offset=0x0
[1.145659] OF:
On 10/03/2017 00:43, Mason wrote:
> I think I'm making progress [...]
Yes! I was able to plug a USB3 Flash drive, mount it,
and read its contents. A million thanks, my head was
starting to hurt from too much banging.
Time to clean up a million hacks to be able to discuss
the fine
On 10/03/2017 16:14, David Laight wrote:
> Mason wrote:
>
>> My RC drops packets not targeting its BAR0.
>
> I suspect the fpga/cpld logic supports RC and endpoint modes
> and is using much the same names for the registers (and logic
> implementation).
Your g
On 10/03/2017 15:06, David Laight wrote:
> Robin Murphy wrote:
>
>> On 09/03/17 23:43, Mason wrote:
>>
>>> I think I'm making progress, in that I now have a better
>>> idea of what I don't understand. So I'm able to ask
>>> (hopefully) l
On 10/03/2017 14:15, Robin Murphy wrote:
> On 09/03/17 23:43, Mason wrote:
>> On 08/03/2017 16:17, Bjorn Helgaas wrote:
>> [snip excellent in-depth overview]
>>
>> I think I'm making progress, in that I now have a better
>> idea of what I don't underst
On 08/03/2017 16:17, Bjorn Helgaas wrote:
[snip excellent in-depth overview]
I think I'm making progress, in that I now have a better
idea of what I don't understand. So I'm able to ask
(hopefully) less vague questions.
Take the USB3 PCIe adapter I've been testing with. At some
point during init,
On 07/03/2017 17:47, Mason wrote:
> As suggested by Marc, I'm trying to adapt
> drivers/pci/host/pcie-altera-msi.c
> to my platform.
For my own reference, I have enabled verbose XHCI debug logs.
I have highlighted suspicious output with *
[0.00] Booting Linux on ph
Hello,
As suggested by Marc, I'm trying to adapt
drivers/pci/host/pcie-altera-msi.c
to my platform.
Here are my changes to the existing driver:
diff --git a/drivers/pci/host/pcie-altera-msi.c
b/drivers/pci/host/pcie-altera-msi.c
index 4e5d628e8cd4..914cd26b2a53 100644
--- a/drivers/pci/host/
On 06/03/2017 16:27, David Laight wrote:
> Mason wrote:
>>
>>> So the kernel panics in xhci_find_next_ext_cap()
>>> ( drivers/usb/host/xhci-ext-caps.h:122 )
>>> http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
>>>
>&
On 06/03/2017 15:30, Robin Murphy wrote:
> On 06/03/17 12:42, Mason wrote:
>
>> $ arm-linux-gnueabihf-addr2line -i -e vmlinux c039fe44
>> arch/arm/include/asm/io.h:119
>>
>> In other words, readl()
>> Not as helpful as expected...
>
> I guess your tool
On 06/03/2017 13:42, Mason wrote:
> So the kernel panics in xhci_find_next_ext_cap()
> ( drivers/usb/host/xhci-ext-caps.h:122 )
> http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
>
> Any idea how this can happen?
>
> b
On 03/03/2017 20:02, Robin Murphy wrote:
> On 03/03/17 17:15, Mason wrote:
>
>>>> [1.264893] Unable to handle kernel paging request at virtual address
>>>> d08664f4
>
> Note that that's a reasonable approximation of a vmalloc address
On 04/03/2017 18:16, Ard Biesheuvel wrote:
> After pc, the link register is the most likely to legally point into
> the kernel .text section so it makes sense imo to decode the address
> into a function name plus offset.
Does gcc ever use the link register as a general purpose register?
(In which
On 04/03/2017 09:07, Ard Biesheuvel wrote:
> On 4 March 2017 at 00:24, Mason wrote:
>> On 03/03/2017 20:02, Robin Murphy wrote:
>>
>>> On 03/03/17 17:15, Mason wrote:
>>>
>>>> [1.261813] Unable to handle kernel paging request at virtual address
>
On 03/03/2017 20:02, Robin Murphy wrote:
> On 03/03/17 17:15, Mason wrote:
>
>> [1.261813] Unable to handle kernel paging request at virtual address
>> d08611e4
>> [1.269167] pgd = c0004000
>> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *
On 03/03/2017 20:02, Robin Murphy wrote:
> On 03/03/17 17:15, Mason wrote:
>
>> [1.264893] Unable to handle kernel paging request at virtual address
>> d08664f4
>
> Note that that's a reasonable approximation of a vmalloc address...
>
> ...and that speci
On 03/03/2017 18:10, Mason wrote:
> On 03/03/2017 17:18, Mason wrote:
>> Hello,
>>
>> I'm seeing this panic randomly at boot-time, so I want to throw
>> it out there in case someone recognizes the issue off the top of
>> their head.
>>
>> I&#x
On 03/03/2017 17:18, Mason wrote:
> Hello,
>
> I'm seeing this panic randomly at boot-time, so I want to throw
> it out there in case someone recognizes the issue off the top of
> their head.
>
> I'm on Linux 4.9, using a USB3 PCIe card. I'm actively workin
Hello,
I'm seeing this panic randomly at boot-time, so I want to throw
it out there in case someone recognizes the issue off the top of
their head.
I'm on Linux 4.9, using a USB3 PCIe card. I'm actively working on
the PCIe support, so I may be responsible for the crash by virtue
of something I di
On Mon, Jan 16, 2017 at 2:32 AM, Rafał Miłecki wrote:
> On 21 November 2016 at 16:31, Mathias Nyman
> wrote:
>> On 21.11.2016 09:57, Rafał Miłecki wrote:
>>>
>>> Hi Mathias,
>>>
>>> On 17 October 2016 at 22:30, Rafał Miłecki wrote:
From: Rafał Miłecki
Broadcom's Northstar XH
On 05/12/2016 09:26, Neil Armstrong wrote:
> On 12/02/2016 07:00 PM, Mason wrote:
>
>> On 02/12/2016 14:46, Neil Armstrong wrote:
>>
>>> On 12/02/2016 11:24 AM, Mason wrote:
>>>
>>>> (Sad face) All the documentation I have is in front of me, and
[ Fix incorrect address for Felipe ]
On 02/12/2016 14:46, Neil Armstrong wrote:
> On 12/02/2016 11:24 AM, Mason wrote:
>
>> (Sad face) All the documentation I have is in front of me, and nothing
>> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI
>> c
On 02/12/2016 14:46, Neil Armstrong wrote:
> On 12/02/2016 11:24 AM, Mason wrote:
>
>> (Sad face) All the documentation I have is in front of me, and nothing
>> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI
>> controller + Synopsys PHY.
>&g
On 02/12/2016 11:42, Greg KH wrote:
> On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote:
>
>> # lsusb -v
>> Bus 001 Device 001: ID 1d6b:0002
>> Bus 002 Device 001: ID 1d6b:0003
>>
>> Isn't lsusb verbose supposed to print much more than that?
>
>
On 02/12/2016 10:03, Felipe Balbi wrote:
> Mason wrote:
>
>> I'm trying out a SoC with a brand new USB controller, which is (supposedly)
>> a standard XHCI controller. In theory, I would just need to build the right
>> driver, and everything would auto-magically w
Hello everyone,
I'm trying out a SoC with a brand new USB controller, which is (supposedly)
a standard XHCI controller. In theory, I would just need to build the right
driver, and everything would auto-magically work, right?
So my defconfig contains:
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES
Hello Felipe,
On 30/05/2016 08:58, Felipe Balbi wrote:
> Mason writes:
>
>> I'm working on a SoC which embeds an IP block from GDA Technologies
>> labeled "Pravega USB3 SuperSpeed Controller" (data-sheet is v0.99r
>> dated 2014-01-29). A cursory search r
Hello everyone,
I'm working on a SoC which embeds an IP block from GDA Technologies
labeled "Pravega USB3 SuperSpeed Controller" (data-sheet is v0.99r
dated 2014-01-29). A cursory search returns:
http://www.sourcing.co.jp/prod_ip.htm
http://www.sourcing.co.jp/prod_ip/usb_host_pb.pdf
In the compl
On 21/12/2015 10:19, Ajay Khandelwal wrote:
> Hello Peter/Balbi,
>
> Any framework for Type-c connector available in Linux.
>
> Thanks and Regards,
> Ajay
Ajay,
Please follow the standard list etiquette, specifically:
Start a new thread with a proper and relevant subject, don't hijack
a loosel
Hello,
I was about to post this, and I noticed it has been discussed recently.
http://thread.gmane.org/gmane.linux.kernel/2087677/
[PATCH] USB: USB_OTG does not depend on PM
My SoC provides a Chipidea dual-port OTG USB 2.0 controller.
My .config contains:
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON
Mason wrote:
> I'm testing an embedded system, which is running a somewhat dated
> (May 2009) 2.6.28.10 kernel.
>
> When I plug this cheap 2-GB USB drive, I get the following message:
>
> usb-storage: This device (058f,6387,0104 S 06 P 50) has unneeded SubClass and
Hello,
I'm testing an embedded system, which is running a somewhat dated
(May 2009) 2.6.28.10 kernel.
When I plug this cheap 2-GB USB drive, I get the following message:
hub_port_init 1
Plug in USB Port3
udev->speed: 3
usb 3-1: configuration #1 chosen from 1 choice
usb-storage: This device (058f
49 matches
Mail list logo
