On Wed, 2005-02-02 at 11:05 +0100, Arnd Bergmann wrote:
> How about something along the lines of this patch? Instead of adding a
> pointer to the pci data from the device node, it embeds the node inside
> a new struct pci_device_node. The patch is not complete and therefore
> not expected to work
On Dinsdag 01 Februar 2005 05:57, Benjamin Herrenschmidt wrote:
> BTW. I'm thinking about moving all those PCI/VIO related fields out of
> struct device_node to their own structure and keep only a pointer to
> that structure in device_node. That way, we avoid the bloat for every
> single non-pci no
Matthew Wilcox wrote:
On Mon, Jan 31, 2005 at 10:52:29PM -0600, Brian King wrote:
@@ -62,8 +72,11 @@ static int rtas_read_config(struct devic
return PCIBIOS_DEVICE_NOT_FOUND;
if (where & (size - 1))
return PCIBIOS_BAD_REGISTER_NUMBER;
You should probably del
Grant Grundler wrote:
On Mon, Jan 31, 2005 at 01:40:04PM -0600, Brian King wrote:
CC'ing the linux-pci mailing list...
thanks...
This patch adds an arch hook so
that individual archs can indicate if the underlying system supports
expanded config space accesses or not.
@@ -653,6 +653,8 @@ static
On Mon, Jan 31, 2005 at 10:52:29PM -0600, Brian King wrote:
> @@ -62,8 +72,11 @@ static int rtas_read_config(struct devic
> return PCIBIOS_DEVICE_NOT_FOUND;
> if (where & (size - 1))
> return PCIBIOS_BAD_REGISTER_NUMBER;
You should probably delete this redundant t
On Mon, Jan 31, 2005 at 01:40:04PM -0600, Brian King wrote:
> CC'ing the linux-pci mailing list...
thanks...
> > This patch adds an arch hook so
> > that individual archs can indicate if the underlying system supports
> > expanded config space accesses or not.
> >@@ -653,6 +653,8 @@ static int p
On Mon, 2005-01-31 at 22:52 -0600, Brian King wrote:
> Assuming I am reading the spec correctly, this is only a property of the
> PHB, so I could move it into the pci_controller struct instead.
Note that Arnd seems to imply the opposite ...
BTW. I'm thinking about moving all those PCI/VIO relat
Benjamin Herrenschmidt wrote:
On Mon, 2005-01-31 at 16:43 -0600, Brian King wrote:
diff -puN include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg include/asm-ppc64/prom.h
--- linux-2.6.11-rc2-bk9/include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg
2005-01-31 14:32:01.0 -0600
+++ linux-2.6.11-rc2-bk9-
On Mon, 2005-01-31 at 16:43 -0600, Brian King wrote:
> diff -puN include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg
> include/asm-ppc64/prom.h
> --- linux-2.6.11-rc2-bk9/include/asm-ppc64/prom.h~ppc64_pcix_mode2_cfg
> 2005-01-31 14:32:01.0 -0600
> +++ linux-2.6.11-rc2-bk9-bjking1/inclu
Brian King <[EMAIL PROTECTED]> schrieb am 31.01.2005, 23:43:30:
> > Isn't the config space size a property of the PCI device instead of the
> > host bridge? For a PCI device behind a PCIe host bridge, this could
> > still lead to an incorrect config space accesses.
>
> It is a property of both.
Arnd Bergmann wrote:
On Maandag 31 Januar 2005 22:35, Brian King wrote:
Matthew Wilcox wrote:
Basically, ppc64's config ops are broken and need to check the offset
being read. Here's i386:
static int pci_conf1_write (int seg, int bus, int devfn, int reg, int len, u32 v
alue)
{
unsigned long
On Mon, Jan 31, 2005 at 10:56:44PM +0100, Arnd Bergmann wrote:
> PS: I got a permanent fatal error from <[EMAIL PROTECTED]>, does
> that list actually exist?
No, that is not the email address for the linux-pci mailing list. I
don't know who put that in this thread, but next time, someone might
wa
On Maandag 31 Januar 2005 22:35, Brian King wrote:
> Matthew Wilcox wrote:
> > Basically, ppc64's config ops are broken and need to check the offset
> > being read. Here's i386:
> >
> > static int pci_conf1_write (int seg, int bus, int devfn, int reg, int len,
> > u32 v
> > alue)
> > {
> >
Matthew Wilcox wrote:
Basically, ppc64's config ops are broken and need to check the offset
being read. Here's i386:
static int pci_conf1_write (int seg, int bus, int devfn, int reg, int len, u32 v
alue)
{
unsigned long flags;
if ((bus > 255) || (devfn > 255) || (reg > 255))
On Maandag 31 Januar 2005 20:29, Matthew Wilcox wrote:
> Thanks for copying linux-pci. I hate this patch.
>
> Basically, ppc64's config ops are broken and need to check the offset
> being read.
To make things worse, simply allowing the larger config space will
silently access the wrong device.
Brian King wrote:
Greg KH wrote:
On Fri, Jan 28, 2005 at 06:52:34PM +, Christoph Hellwig wrote:
+int __attribute__ ((weak)) pcibios_exp_cfg_space(struct pci_dev
*dev) { return 1; }
- prototypes belong to headers
- weak linkage is the perfect way for total obsfucation
please make this a regula
On Mon, Jan 31, 2005 at 01:10:46PM -0600, Brian King wrote:
> Greg KH wrote:
> >On Fri, Jan 28, 2005 at 06:52:34PM +, Christoph Hellwig wrote:
> >
> >>>+int __attribute__ ((weak)) pcibios_exp_cfg_space(struct pci_dev *dev) {
> >>>return 1; }
> >>
> >>- prototypes belong to headers
> >>- weak l
On Mon, Jan 31, 2005 at 01:10:46PM -0600, Brian King wrote:
> +int pcibios_exp_cfg_space(struct pci_dev *dev) { return 1; }
> +
Kernel functions traditionally return 0 for success and -ESOMETHING for
error. Care to fix this up to match that convention?
thanks,
greg k-h
Greg KH wrote:
On Fri, Jan 28, 2005 at 06:52:34PM +, Christoph Hellwig wrote:
+int __attribute__ ((weak)) pcibios_exp_cfg_space(struct pci_dev *dev) { return 1; }
- prototypes belong to headers
- weak linkage is the perfect way for total obsfucation
please make this a regular arch hook
I agree
On Fri, Jan 28, 2005 at 06:52:34PM +, Christoph Hellwig wrote:
> > +int __attribute__ ((weak)) pcibios_exp_cfg_space(struct pci_dev *dev) {
> > return 1; }
>
> - prototypes belong to headers
> - weak linkage is the perfect way for total obsfucation
>
> please make this a regular arch hook
> +int __attribute__ ((weak)) pcibios_exp_cfg_space(struct pci_dev *dev) {
> return 1; }
- prototypes belong to headers
- weak linkage is the perfect way for total obsfucation
please make this a regular arch hook
> Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
-
To uns
When working with a PCI-X Mode 2 adapter on a PCI-X Mode 1 PPC64
system, the current code used to determine the config space size
of a device results in a PCI Master abort and an EEH error, resulting
in the device being taken offline. This patch adds the ability for
arch specific code to override
22 matches
Mail list logo
