On Fri, Sep 11, 2015 at 01:35:36PM +0100, Tomasz Nowicki wrote:
On 11.09.2015 13:20, Lorenzo Pieralisi wrote:
[...]
With that in place using raw_pci_write/read or the generic accessors becomes almost identical, with code requiring the pci_bus to be created using the generic accessors and ACPICA using the raw version.
I might be missing something, so apologies if that's the case.
Actually, I think you showed me the right direction :) Here are some conclusions/comments/concerns. Please correct me if I am wrong:
- We need raw_pci_write/read accessors (based on ECAM) for ARM64 too
but only up to the point where buses are enumerated. From that point on, we should reuse generic accessors from access.c file, right?
Well, I still have not figured out whether on arm64 the raw accessors required by ACPICA make sense.
So either arm64 relies on the generic MCFG based raw read and writes or we define the global raw read and writes as empty (ie x86 overrides them anyway).
I will get back to you on this.
- For ARM64 ACPI PCI, we can use generic accessors right away, .map_bus
would call common code part (pci_dev_base()). The only thing that worry me is fact that MCFG regions are RCU list so it needs rcu_read_lock() for the .map_bus (mcfg lookup) *and* read/write operation.
Do you mean the address look-up and the mmio operation should be carried out atomically right ?
Yes.
We can wrap the calls pci_generic_read/write() within a function and add rcu_read_lock()/unlock() around them, eg:
int pci_generic_config_read_rcu() { rcu_read_lock(); pci_generic_config_read(...); rcu_read_unlock(); }
Honestly it seems the RCU API is needed just because config space can be also accessed by raw_ accessors in ACPICA code, that's the only reason I see to protect the config structs against config space removal (basically config entries are removed only when the host bridge is released if I read the code correctly, and the only way this can happen concurrently is having ACPICA code reusing the same config space but accessing it with no pci_bus struct attached to it, by just using the (segment, bus, dev, fn) tuple).
Lorenzo