lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51968994.5030408@wwwdotorg.org>
Date:	Fri, 17 May 2013 13:48:36 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Jay Agarwal <jagarwal@...dia.com>
CC:	"'thierry.reding@...onic-design.de'" 
	<thierry.reding@...onic-design.de>,
	"'linux@....linux.org.uk'" <linux@....linux.org.uk>,
	"'bhelgaas@...gle.com'" <bhelgaas@...gle.com>,
	"'olof@...om.net'" <olof@...om.net>,
	"'mturquette@...aro.org'" <mturquette@...aro.org>,
	"'linux-arm-kernel@...ts.infradead.org'" 
	<linux-arm-kernel@...ts.infradead.org>,
	"'linux-tegra@...r.kernel.org'" <linux-tegra@...r.kernel.org>,
	"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	"'linux-pci@...r.kernel.org'" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 4/4] ARM: tegra: pcie: Enable PCIe controller on Cardhu

On 05/17/2013 10:51 AM, Jay Agarwal wrote:
>>> On 05/08/2013 04:57 AM, Jay Agarwal wrote:
>>>> - Enable PCIe controller on Cardhu
>>>> - Only port 2 is connected on this board
>>>> - Add regulators required for Tegra30
>>>> - Patch is based on remotes/gitorious_thierryreding_linux/tegra/next
>>>> - and should be applied on top of this.
...
>>> So, if I apply this series, I do see the PCIe bridge and Ethernet
>>> device get enumerated, but I don't see the USB3 controller get
>>> enumerated. I believe that is a PCIe device behind the same bridge on the
>>> same Tegra PCIe port.
>>> Shouldn't this device show up?
>>
>> I have also reproduced this problem. I see somehow no non-
>> prefetchable memory is assigned to any of pcie devices.
>> Probably that is the reason for USB3 (pci 0000:04:00.0) not getting
>> enumerated since it uses only non-prefetchable memory.
> 
> 1. Bus4(on which usb3 device resides) always return 0xffffffff from it's config space. which means device is not present?
> 2. That's why it is not assigned any resources and hence no usb3 probe happens.
> 3. But same bus does return valid info like vendor/device id etc from it's config space in downstream kernel and hence usb3 probe does happen.
> 
> Thierry, Stephen,
> 4. Any idea why bus4 should return 0xffffffff values in upstream kernel? Anything missing?

Is there some reset/enable GPIO or regulator that needs to be programmed
to enable the PCIe USB3 controller? Take a look at the schematic. If you
can make it work by tweaking those GPIOs/... manually, then we can
ignore this issue and fix it up later, since it's not directly related
to the PCIe controller driver patches. It's more important to get this
Ethernet working than USB, I think.

> 5. Also, how config space of all pcie devices are mapped? I mean if I change the config space offset in dts file, then also I find correct vendor/device id etc for bus0/device0/fun0.
>     So how this mapping happens that even after changing the config space offset in PCIe address space, it always finds correct vendor/device id.

Can you please word-wrap your email less than 80 columns? It's quite
hard to read.

I don't quite understand your question. The PCIe driver implements the
functions that access config space. I don't recall that being influenced
by anything much in the device tree, except for the 3rd entry in the
top-level PCIe controller's reg property:

        pcie-controller {
                compatible = "nvidia,tegra30-pcie";
                device_type = "pci";
                reg = <0x00003000 0x00000800   /* PADS registers */
                       0x00003800 0x00000200   /* AFI registers */
                       0x10000000 0x10000000>; /* configuration space */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ