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
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 node
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 as
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
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
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 test
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
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
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
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
+++
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
> +++
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
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
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
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
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
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
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
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 linkage is the perfect
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
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. The
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 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
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
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. Accessing
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
+++
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
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
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
want
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
+++
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
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
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
+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
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
44 matches
Mail list logo
