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]
Date:	Tue, 9 Sep 2014 18:50:13 -0400
From:	Murali Karicheri <m-karicheri2@...com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	<linux-arm-kernel@...ts.infradead.org>, <robh+dt@...nel.org>,
	<pawel.moll@....com>, <mark.rutland@....com>,
	<ijc+devicetree@...lion.org.uk>, <galak@...eaurora.org>,
	<bhelgaas@...gle.com>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] PCI: keystone: update to support multiple pci
 ports

On 09/09/2014 05:52 PM, Arnd Bergmann wrote:
> On Tuesday 09 September 2014 17:49:19 Murali Karicheri wrote:
>> Actually this is an inteded. The vendor ID is in a register indicated by
>> reg offset and as per the device spec, it needs to be read and updated
>> by the software. Now since multiple instances of PCI device needs to be
>> read the same register, the reading happens in the probe() and same is
>> unmapped after that.
>>
>> +       ks_pcie->device_id = readl(reg_p)>>  16;
>> +       devm_iounmap(dev, reg_p);
>> +       devm_release_mem_region(dev, res->start, resource_size(res));
>>
>> Afetr that in ks_pcie_host_init(), it update the device_id in the RC's
>> config space.
>
> I'm not sure I understand the purpose of this. Do you mean you read
> the vendor/device ID of whichever device happens to get probed first
> and then program the same ID into all other devices as well?

My mistake. It is the device ID, not vendor ID. The PCI driver supports 
PCI h/w on K2HK, K2E and K2L SoCs for which PCI device IDs are assigned as

+#define PCIE_RC_K2HK		0xb008
+#define PCIE_RC_K2E		0xb009
+#define PCIE_RC_K2L		0xb00a
+

and the same driver code runs on all these h/w. The device ID is not 
filled in by default by the h/w, in the config space of the RC at offset 
1000h "VENDOR_DEVICE_ID Vendor and Device Identification Register". 
Same is available in a seperate SoC register whose offset is specified 
by index 2. This is read by driver and updated in the config space. The 
Vendor ID is however set by default.

There is a mrrs PCI quirk required for Keystone PCI which depends on 
this vendor ID to be filled correctly as it match vendor id/ device id 
of the bridge device to apply the quirk.

Hope this clarify your question.

Murali

>
> What if the order changes between two boots? Why does the vendor/device
> ID of the host bridge even matter at all?
>
> 	Arnd

--
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