public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: "Durairaj, Sundarapandian" <sundarapandian.durairaj@intel.com>
Cc: linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	torvalds@osdl.org, alan@lxorguk.ukuu.org.uk, greg@kroah.com,
	ak@colin2.muc.de, vladimir.kondratiev@intel.com,
	harinarayanan.seshadri@intel.com,
	sundarapandian.durairaj@intel.com
Subject: Re: [patch] PCI Express Enhanced Config Patch - 2.6.0-test11
Date: Thu, 22 Jan 2004 02:44:56 -0800	[thread overview]
Message-ID: <20040122024456.38e07c49.akpm@osdl.org> (raw)
In-Reply-To: <6B09584CC3D2124DB45C3B592414FA83011A3357@bgsmsx402.gar.corp.intel.com>

"Durairaj, Sundarapandian" <sundarapandian.durairaj@intel.com> wrote:
>
> This is the patch on PCI Express Enhanced configuration for 2.6.0 test11
> ...
> Please review this and send in your comments.

A bit of triviata:

> diff -Naur linux-2.6.0/arch/i386/Kconfig
> linux_pciexpress/arch/i386/Kconfig
> --- linux-2.6.0/arch/i386/Kconfig	2003-12-18 08:28:16.000000000
> +0530

Your mailer wordwrapped it.  This seems to be a favourite pastime at Intel
;) You need to struggle with your email client for a while, or give up and
use attachments.

> +++ linux_pciexpress/arch/i386/kernel/acpi/boot.c	2004-01-12
> 14:14:22.000000000 +0530
> @@ -93,6 +93,29 @@
>  	return ((unsigned char *) base + offset);
>  }
>  
> +#ifdef CONFIG_PCI_EXPRESS
> +extern u32 mmcfg_base_address;

extern declarations should go in .h files, not in .c.

> +static int __init acpi_parse_mcfg
> +			 (unsigned long phys_addr, unsigned long size)
> +{
> +	struct acpi_table_mcfg	*mcfg = NULL;
> +
> +	if (!phys_addr || !size)
> +		return -EINVAL;
> +
> +	mcfg = (struct acpi_table_mcfg *) __acpi_map_table
> +						(phys_addr, size);
> +	if (!mcfg) {
> +		printk(KERN_WARNING PREFIX "Unable to map MCFG\n");
> +		return -ENODEV;
> +	}
> +	if (mcfg->base_address)
> +		mmcfg_base_address = (u32)mcfg->base_address;

Is it OK to chop this u64 down to u32?  If so, why was it u64?

> +#ifdef CONFIG_PCI_EXPRESS
> +	else if (!strcmp(str, "no_pcie")) {
> +		pci_probe &= !PCI_PROBE_ENHANCED;
> +		return NULL;
> +	}

should that be a `!' operator?  Or `~'?

>  /*
> + *We map full Page size on each request. Incidently that's the size we
> + *have for config space too.
> + */

Conventionally we put a space after the "*" in comments.


> +/*
> + *Variable used to store the virtual  address of fixed PTE
> + */
> +char * mmcfg_virt_addr;

But we don't put spaces after this sort of asterisk.

> +
> +static int pci_express_conf_read(int seg, int bus,
> +		int devfn, int reg, int len, u32 *value)
> +{
> +	if (!value || ((u32)bus > 255) || ((u32)devfn > 255) 
> +		|| ((u32)reg > 4095)){

If you're casting these so as to catch negative ints the cast should be to
`unsigned', not `u32'.  Or, better, make this function simply take unsigned
args if negative values are nonsensical.


> +	/* Shoot misalligned transaction now */

Spellling error here.

> +	if (reg & (len-1)){

Space before the {

> +		printk(KERN_ERR "pci_express_conf_read: \
> +					misalligned transaction\n");

This string has a bunch of tabs in the middle.

Remove the `\' and do

		printk(KERN_ERR "pci_express_conf_read: "
				"misalligned transaction\n");


> +static int pci_express_conf_write(int seg, int bus, 
> +			int devfn, int reg, int len, u32 value)
> +{
> +	if (((u32)bus > 255) || ((u32)devfn > 255) 
> +		|| ((u32)reg > 4095)){

See above.

> +		printk(KERN_ERR "pci_express_conf_write: \
> +					Invalid Parameter\n");

tabs

> +	/* Shoot misalligned transaction now */

spelling

> +	if (reg & (len-1)){
> +		printk(KERN_ERR "pci_express_conf_write: \
> +					misalligned transaction\n");

tabs

> +	if (mmcfg_base_address == 0){

space

> +		printk(KERN_INFO 
> +		      "MCFG table entry is not found in ACPI
> tables....\n \
> +		       PCI Express not supported in this platform....\n
> \
> +		       Not enabling Enhanced Configuration....\n");

Use compile-time string concatentation here as well.

>  static int proc_initialized;	/* = 0 */

The comment here isn't really needed: initalisaton of BSS is kernel
folklore.

>  
> +static int pci_cfg_space_size (struct pci_dev *dev)

No space before the opening parenthesis.

> + 		size = pci_cfg_space_size (dev);

Ditto

> +extern u32 mmcfg_base_address;
> +extern spinlock_t pci_config_lock;
> +extern char * mmcfg_virt_addr;

These should all be in header files.

> +
> +static __inline__ void pci_exp_set_dev_base (int bus, int devfn)
> +static __inline__ void pci_express_read(int bus, int devfn, int reg, 

`inline', not __inline__

> +		int len, u32 *value)
> +{
> +	unsigned long flags;
> +	spin_lock_irqsave(&pci_config_lock, flags);
> +	pci_exp_set_dev_base(bus, devfn);
> + 	switch (len) {
> +        case 1:
> +		*value = (u8)readb((unsigned long) mmcfg_virt_addr +
> reg);
> +		break;
> +        case 2:
> +		*value = (u16)readw((unsigned long) mmcfg_virt_addr +
> reg);
> +		break;
> +        case 4:
> +		*value = (u32)readl((unsigned long) mmcfg_virt_addr +
> reg);

Are these casts needed?

> +static __inline__ void pci_express_write(int bus, int devfn, int reg, 

inline

> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&pci_config_lock, flags);
> +	pci_exp_set_dev_base(bus, devfn);
> +	switch (len) {
> +		case 1:
> +			writeb(value,(unsigned long)mmcfg_virt_addr +
> reg);
> +			break;
> +		case 2:
> +			writew(value,(unsigned long)mmcfg_virt_addr +
> reg);
> +			break;
> +	        case 4:
> +			writel(value,(unsigned long)mmcfg_virt_addr +
> reg);
> +	                break;
> +     	}

Are these casts needed?


  reply	other threads:[~2004-01-22 10:44 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-22 10:21 [patch] PCI Express Enhanced Config Patch - 2.6.0-test11 Durairaj, Sundarapandian
2004-01-22 10:44 ` Andrew Morton [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2004-01-30 16:58 Nakajima, Jun
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-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
     [not found] <183UK-2Re-11@gated-at.bofh.it>
2003-12-29 19:12 ` Andi Kleen
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=20040122024456.38e07c49.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@colin2.muc.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=harinarayanan.seshadri@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=sundarapandian.durairaj@intel.com \
    --cc=torvalds@osdl.org \
    --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