public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: "Durairaj, Sundarapandian" <sundarapandian.durairaj@intel.com>
Cc: "Seshadri, Harinarayanan" <harinarayanan.seshadri@intel.com>,
	"Kondratiev, Vladimir" <vladimir.kondratiev@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [patch] PCI Express Enhanced Config Patch - 2.6.0-test11
Date: Mon, 29 Dec 2003 20:12:39 +0100	[thread overview]
Message-ID: <m3hdzjxwt4.fsf@averell.firstfloor.org> (raw)
In-Reply-To: <183UK-2Re-11@gated-at.bofh.it> ("Durairaj, Sundarapandian"'s message of "Mon, 29 Dec 2003 12:40:10 +0100")

"Durairaj, Sundarapandian" <sundarapandian.durairaj@intel.com> writes:

> +u32 pcie_last_accessed_device;
> +
> +unsigned long pci_exp_set_dev_base (int bus, int dev, int fn)
> +{
> +	u32 dev_base = 
> +		mmcfg_base_address | (bus << 20) | ((PCI_DEVFN (dev,fn))
> <<12);
> +	if (dev_base != pcie_last_accessed_device){
> +		pcie_last_accessed_device = dev_base;
> +		set_fixmap (FIX_PCIE_MCFG, dev_base);
> +	}

Can you please put the details on how the fixmap is managed into
an asm-i386/* file. x86-64 shares the i386 PCI subsystem and I would
like to use a different implement a different method there (just mapping 
everything statically) 

> +}
> +
> +static int pci_express_conf_read(int seg, int bus, int devfn, int reg,
> int len, u32 *value)
> +{
> +	 unsigned long flags;
> +	 unsigned long base_address;
> +	 char * virt_addr;
> +	 int dev = PCI_SLOT (devfn);
> +	 int fn  = PCI_FUNC (devfn);
> + 
> +  if (!value || ((u32)bus > 255) || ((u32)dev > 31) || ((u32)fn > 7) ||
> ((u32)reg > 4095))
> +  	return -EINVAL;
> +
> +	/* Shoot misalligned transaction now */
> +	if (reg & (len-1))
> +  	return -EINVAL;

It would be better to printk here because nobody will check the return
value of this function

Same for _write.

> +			writew(value,(unsigned long)virt_addr+reg);
> +       		        break;
> +	        case 4:
> +			writel(value,(unsigned long)virt_addr+reg);
> +	                break;
> +     	}
> + 	/* Dummy read to flush PCI write */
> +	readl (virt_addr);

I thought the consensus was that reading the same address is dangerous
because some registers react when they are only read.
Also you cannot readl on a w or b registers, if you do that you would
need to use the same size.

Also are you sure that the old port based config read/write functions
actually flushed their writes? I don't think they did.  It probably
would be best to just drop that read.

Otherwise it should read some save register in the same mapping.


> +	 if( is_pci_exp_platform() != 0){

Shouldn't there a pci_probe option for this here?

It would be probably better to add some way to turn this off at runtime,
since it's still experimental and most drivers will probably work
with the old methods for now.

>  
>  	if (capable(CAP_SYS_ADMIN))
> -		size = PCI_CFG_SPACE_SIZE;
> +#ifdef CONFIG_PCI_EXP_ENHANCED
> +		if (pci_find_capability(dev,PCI_CAP_ID_EXP))
> +			size = PCI_CFG_SPACE_EXP_SIZE;
> +		else
> +#endif /*CONFIG_PCI_EXP_ENHANCED */
> + 		size = PCI_CFG_SPACE_SIZE;

This would be somewhat cleaner in an standard function that returns
the cfg space size for a device, especially since this code is often duplicated
in your patch.


> +#ifdef CONFIG_PCI_EXP_ENHANCED
> +struct acpi_table_mcfg {
> +	struct acpi_table_header 	header;
> +	u8	reserved[8];
> +	u64	base_address;
> +} __attribute__ ((packed));
> +#endif

Declarations don't need to be #ifdefed.

-Andi

       reply	other threads:[~2004-01-01 13:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <183UK-2Re-11@gated-at.bofh.it>
2003-12-29 19:12 ` Andi Kleen [this message]
2004-01-30 16:58 [patch] PCI Express Enhanced Config Patch - 2.6.0-test11 Nakajima, Jun
  -- strict thread matches above, loose matches on Subject: below --
2004-01-29 11:32 Durairaj, Sundarapandian
2004-01-29 15:09 ` Matthew Wilcox
2004-01-29 15:59   ` Matthew Wilcox
2004-01-29 16:05     ` Linus Torvalds
2004-01-29 16:42       ` Matthew Wilcox
2004-01-29 16:52         ` Linus Torvalds
2004-01-31 21:57         ` Eric W. Biederman
2004-02-01  4:41           ` Grant Grundler
2004-02-01  5:10           ` Matthew Wilcox
2004-02-01 11:00             ` Eric W. Biederman
2004-02-01 15:18               ` Matthew Wilcox
2004-02-01 18:28                 ` Eric W. Biederman
2004-02-01 20:11                   ` Matthew Wilcox
2004-02-01 21:35                     ` Eric W. Biederman
2004-02-01 11:10             ` Eric W. Biederman
2004-01-29 18:09       ` Greg KH
2004-01-30 16:33         ` Greg KH
2004-01-28  9:38 Durairaj, Sundarapandian
2004-01-28 14:42 ` Vladimir Kondratiev
2004-01-28 14:54   ` Christoph Hellwig
2004-01-28 15:00   ` Martin Mares
2004-01-28 15:18 ` Matthew Wilcox
2004-01-22 10:21 Durairaj, Sundarapandian
2004-01-22 10:44 ` Andrew Morton
2004-01-22 11:09 ` Martin Mares
2004-01-22 13:12 ` Andi Kleen
2004-01-22 18:21   ` Alan Cox
2004-01-22 19:40     ` Randy.Dunlap
2004-01-23 19:19       ` Pavel Machek
2004-01-23 19:31         ` Martin Mares
2004-01-23 20:08           ` Stefan Smietanowski
2004-01-22 16:40 ` Grant Grundler
2004-01-22 17:00 ` Greg KH
2004-01-07 16:44 Nakajima, Jun
2004-01-07 12:59 Durairaj, Sundarapandian
2004-01-07 14:08 ` Meelis Roos
2004-01-07 17:34 ` Vladimir Kondratiev
2003-12-29 11:32 Durairaj, Sundarapandian
2003-12-29 11:53 ` Arjan van de Ven
2003-12-29 11:55 ` Christoph Hellwig
2003-12-29 12:51   ` Johan Sjoholm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3hdzjxwt4.fsf@averell.firstfloor.org \
    --to=ak@muc.de \
    --cc=harinarayanan.seshadri@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sundarapandian.durairaj@intel.com \
    --cc=vladimir.kondratiev@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox