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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 20 Jan 2015 19:56:34 +0800
From:	Hanjun Guo <hanjun.guo@...aro.org>
To:	Catalin Marinas <catalin.marinas@....com>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
	Mark Rutland <Mark.Rutland@....com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Will Deacon <Will.Deacon@....com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	"graeme.gregory@...aro.org" <graeme.gregory@...aro.org>,
	Sudeep Holla <Sudeep.Holla@....com>,
	"jcm@...hat.com" <jcm@...hat.com>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Robert Richter <rric@...nel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>,
	"phoenix.liyi@...wei.com" <phoenix.liyi@...wei.com>,
	Timur Tabi <timur@...eaurora.org>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	"wangyijing@...wei.com" <wangyijing@...wei.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>
Subject: Re: [PATCH v7 06/17] ARM64 / ACPI: Make PCI optional for ACPI on
 ARM64

On 2015年01月20日 19:00, Catalin Marinas wrote:
> On Tue, Jan 20, 2015 at 02:39:16AM +0000, Hanjun Guo wrote:
>> On 2015年01月19日 18:42, Catalin Marinas wrote:
>>> On Sun, Jan 18, 2015 at 06:25:53AM +0000, Hanjun Guo wrote:
>>>> On 2015年01月16日 17:49, Catalin Marinas wrote:
>>>>> On Wed, Jan 14, 2015 at 03:04:54PM +0000, Hanjun Guo wrote:
>>>>>> --- a/arch/arm64/kernel/pci.c
>>>>>> +++ b/arch/arm64/kernel/pci.c
>>>>>> @@ -10,6 +10,7 @@
>>>>>>      *
>>>>>>      */
>>>>>>
>>>>>> +#include <linux/acpi.h>
>>>>>>     #include <linux/init.h>
>>>>>>     #include <linux/io.h>
>>>>>>     #include <linux/kernel.h>
>>>>>> @@ -68,3 +69,30 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
>>>>>>     	bus->domain_nr = domain;
>>>>>>     }
>>>>>>     #endif
>>>>>> +
>>>>>> +/*
>>>>>> + * raw_pci_read/write - Platform-specific PCI config space access.
>>>>>> + *
>>>>>> + * Default empty implementation.  Replace with an architecture-specific setup
>>>>>> + * routine, if necessary.
>>>>>> + */
>>>>>> +int raw_pci_read(unsigned int domain, unsigned int bus,
>>>>>> +		  unsigned int devfn, int reg, int len, u32 *val)
>>>>>> +{
>>>>>> +	return -EINVAL;
>>>>>> +}
>>>>>> +
>>>>>> +int raw_pci_write(unsigned int domain, unsigned int bus,
>>>>>> +		unsigned int devfn, int reg, int len, u32 val)
>>>>>> +{
>>>>>> +	return -EINVAL;
>>>>>> +}
>>>>>> +
>>>>>> +#ifdef CONFIG_ACPI
>>>>>> +/* Root bridge scanning */
>>>>>> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>>>>>> +{
>>>>>> +	/* TODO: Should be revisited when implementing PCI on ACPI */
>>>>>> +	return NULL;
>>>>>> +}
>>>>>> +#endif
>>> [...]
>>>>> When PCI is enabled and the above functions are compiled in, do they
>>>>> need to return any useful data or just -EINVAL. Are they ever called?
>>>>
>>>> They will be called if PCI root bridge is defined in DSDT, should I
>>>> print some warning message before it is implemented?
>>>
>>> My point: do they need to return real data when a PCI root bridge is
>>> defined in DSDT or you always expect them to always return some -E*? Can
>>> you explain why?
>>
>> Not always return -E* or NULL;
>>
>> For raw_pci_read/write(), they are needed to access the PCI config space
>> before the PCI root bus is created. so they will return 0 if access to
>> PCI config space is ok; pci_acpi_scan_root() will return root bus
>> pointer if it is successfully created.
>
> OK. So what's the plan for implementing these functions properly. For

We were planing to add the ACPI PCI support in later patch set, and
actually Tomasz already prepared the RFC patch for this [1].

> the raw_pci_read/write, the comment states "replace with an
> architecture-specific setup routine". What does this mean?

Sorry, this comment should be removed for misleadings.

>
> For pci_acpi_scan_root(), at least the comment states a "TODO". Is there
> anyone working on this or we don't expect servers with PCIe soon?

Yes, we already have RFC patches [2], but need some clean up and
update, we plan to post PCI patches again when ACPI core patches are
merged.

[1]: https://lkml.org/lkml/2014/11/19/437
[2]: http://www.spinics.net/lists/linux-acpi/msg54053.html

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