Hi, Jonathan.
On 2015/09/09 23:02, Jonathan A. Kollasch wrote:
On Tue, Sep 08, 2015 at 12:58:31PM +0900, MAEKAWA Masahide wrote:
On 2015/09/08 0:59, Jonathan A. Kollasch wrote:
- abuse of the pcitag_t (I have patches that fix this.)
Your patches? Where? your local?
Attached. This has been successfully tested on a machine that uses
Mode 2 configuration access. Mode 2 is very rare nowadays, and is being
misdetected more often now that firmware is placing IO ports up in the
0xC000ish range. The Mode 2 tag is incapable of representing a complete
PCI Bus,Device,Function tuple, and thus has no place being a generic
representation of a BDF for use by any configuration access method.
This patch makes the x86 pcitag_t a simple BDF.
Thanks. Why you haven't committed that change? I think it's OK to commit.
- pci_conf_size() is unnecessary
Why?
Because there's no need to care. We already support extended
configuration space on some evbmips/arm, and haven't needed it yet.
Just read back 0xffffffff and ignore writes if extended configuration is
inaccessible. No need to bloat the API and kernel.
You mean the range check should be modified in all MD part?
And also, MI driver should check the ability of accessing extended
configuration area with:
a) the return value of pci_get_ext_capability()
or
b) write code in each driver
Only small number of driver will be required to use b), so it might
be OK to provide MI function to do it now.
And,
- too much ACPI dependence, there's nothing that says you have to use
ACPI MCFG to get this information
I think updated patch solved the prolbem (see below)
- possibility of too much KVA usage on 32-bit kernels
- on-demand bus mapping may happen in inappropriate (interrupt) context
In old patch, all bus area which was accessed were mapped and never unmapped.
In updated patch, configuration areas are mapped when a pci bus are attached (pci<n>).
And then, if there is no any devices in the bus, it's unmapped. Is it OK?
- x86 bus_space_read/write functions do not use the %eax/ax/al register,
as required by the AMD documentation for Family 10h's (and others) extended
configuration space access.
We have not known it. Thanks. It's fixed in the new patch.
http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/tmp/20150911-nbsd-pci-extconf-support.diff
Could you check again?
And, I suspect that you have other diffs locally, could we share your diff?
Jonathan Kollasch