tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PCI extended configuration support



On 2015/09/11 19:44, Masanobu SAITOH wrote:
  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


Updated patch:

http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/tmp/20150925-nbsd-pci-extconf-support.diff

More machines support the extended configuration area than before.

 Is it OK to commit?

--
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)



Home | Main Index | Thread Index | Old Index