[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <918342.94228.qm@web50101.mail.re2.yahoo.com>
Date: Wed, 11 Mar 2009 11:55:36 -0700 (PDT)
From: Doug Thompson <norsk5@...oo.com>
To: Harry Ciao <qingtao.cao@...driver.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, bluesmoke-devel@...ts.sourceforge.net
Subject: Re: [v1 PATCH 3/8] EDAC: AMD8111 driver source file
--- On Tue, 3/10/09, Andrew Morton <akpm@...ux-foundation.org> wrote:
> From: Andrew Morton <akpm@...ux-foundation.org>
> Subject: Re: [v1 PATCH 3/8] EDAC: AMD8111 driver source file
> To: "Harry Ciao" <qingtao.cao@...driver.com>
> Cc: linux-kernel@...r.kernel.org, bluesmoke-devel@...ts.sourceforge.net
> Date: Tuesday, March 10, 2009, 2:46 PM
> On Mon, 9 Mar 2009 16:08:12
> +0800
> Harry Ciao <qingtao.cao@...driver.com>
> wrote:
<snip>
> > +static void edac_pci_write_dword(struct pci_dev *dev,
> int reg, u32 val32)
> > +{
> > + int ret;
> > +
> > + ret = pci_write_config_dword(dev,
> reg, val32);
> > + if (ret > 0)
> > + printk(KERN_ERR
> AMD8111_EDAC_MOD_STR
> > +
> " PCI Access Write Error at 0x%x\n",
> reg);
> > +}
> > +
> > +static void edac_pci_write_byte(struct pci_dev *dev,
> int reg, u8 val8)
> > +{
> > + int ret;
> > +
> > + ret = pci_write_config_byte(dev,
> reg, val8);
> > + if (ret > 0)
> > + printk(KERN_ERR
> AMD8111_EDAC_MOD_STR
> > +
> " PCI Access Write Error at 0x%x\n",
> reg);
> > +}
>
>
> <spends a while trying to work out what the return value
> of
> pci_read_config_dword() means>
>
> <gets frustrated and gives up>
>
> Is it correct that all of these functions treat a +ve
> return value as
> an error?
Yes, the config APIs do return an error code on an operation error. I found that before and during the transition to the AMD IOCF8 IO-Space config transition - the 12 bits of config space vs the 8 bits of config space and where AMD started using the PCI reserved bits to access the their extended config space.
The yet to be pushed upstream AMD64 EDAC driver required the extended config space access for the Family 10h CPUs
Now, I bracketed such error processing with #DEFINE DEBUG printouts to provide some type of signal during development of an error. This is not in the kernel yet.
I suppose these lines here are similar to provide some useless notice of an error
doug t
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists