On Thu, 2007-12-20 at 22:50 +0300, Ivan Kokshaysky wrote:
Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
is to avoid touching BARs with mmconfig.
Ivan.
I've tried Ivan's suggestion, and it works.
The patch is appended below.
My question is, do we want to
, Greg KH wrote:
On Mon, Jan 07, 2008 at 10:20:23PM -0500, Tony Camuso wrote:
Greg,
Have you given this patch-set any more consideration?
Which patch-set, there have been a number of them :)
I've submitted the changes you requested.
Care to respin them all so I'm not confused
Thanks, Greg.
Have a safe flight!
On Tue, 2008-01-08 at 05:36 -0800, Greg KH wrote:
On Tue, Jan 08, 2008 at 08:14:22AM -0500, Tony Camuso wrote:
I'll respin the whole kit with [PATCH ?/5][V2]PCI: x86 MMCONFIG *
in the subject line, where the ? is replaced by the number of the
patch within
access to buses serving these devices
while allowing other buses in the system to continue to use
of every device discovered during the PCI probing sequence.
MMCONFIG.
The patch was also tested on non-x86 platforms to assure that
there were no build problems or regressions.
Signed-off-by: Tony
Greg,
Any thoughts?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sorry,
Meant to press reply/all.
Forwarded Message
From: Tony Camuso [EMAIL PROTECTED]
To: Greg KH [EMAIL PROTECTED]
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a
driver opt-in
Date: Fri, 11 Jan 2008 20:58:52 -0500
Greg KH wrote:
Ivan, you posted one
Thanks, Arjan.
The problem we have been experiencing has to do with Northbridges,
not with devices.
As far as the device is concerned, after the Northbridge translates
the config access into PCI bus cycles, the device has no idea what
mechanism drove the Northbridge to the translation.
That is
Arjan van de Ven wrote:
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Just about NOBODY has devices that need the extended config space. At all.
The PCI express spec requires the platform to provide access to this space
for express-compliance. More devices
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's not
going away, and especially not in x86 land where Port IO is built-in
to the CPU.
again sadly you're wrong.
As someone gently pointed out to me, you are in a position to know this,
so I probably am
To all ...
Well, here is what I perceive we've got so far.
. Some PCI Northbridges do not work with MMCONFIG.
. Some PCI BARs can overlap the MMCONFIG area during bus sizing.
It is hoped that new BIOSes will locate MMCONFIG in an area
safely out of the way of bus sizing code, but there can
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque
Arjan van de Ven wrote:
it's not pci_enable_mmconf(), it's pci_enable_extended_config_space... it's
independent of the mechanism!
Arjan, you would be foisting this call on device drivers running on
arches that don't need any such distinction between extended config
space and 256 bytes.
I
Greg KH wrote:
Please do not respond privately, please respond back on the list so that
everyone can see. That way I will respond, to do otherwise is rude to
the rest of the community...
thanks,
greg k-h
I'm very sorry.
It is certainly not my intention to be rude.
--
To unsubscribe from
.
Original Message
Subject: Re: [PATCH 1/5]PCI: x86 MMCONFIG: introduce PCI_USING_MMCONF
Date: Wed, 19 Dec 2007 18:58:45 -0500
From: Tony Camuso [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Greg KH [EMAIL PROTECTED]
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Greg
Original Message
Subject: Re: [PATCH 2/5]PCI: x86 MMCONFIG: add legacy pci conf functions
Date: Wed, 19 Dec 2007 19:07:27 -0500
From: Tony Camuso [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Greg KH [EMAIL PROTECTED]
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL
Original Message
Subject: Re: [PATCH 4/5]PCI: x86 MMCONFIG: introduce pcibios_fix_bus_scan()
Date: Wed, 19 Dec 2007 19:17:42 -0500
From: Tony Camuso [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Greg KH [EMAIL PROTECTED]
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED
Original Message
Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
Date: Wed, 19 Dec 2007 19:33:45 -0500
From: Tony Camuso [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Greg KH [EMAIL PROTECTED]
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Greg KH wrote:
On Wed, Dec 19
Original Message
Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
Date: Wed, 19 Dec 2007 19:44:13 -0500
From: Tony Camuso [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Robert Hancock [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Robert
Tony Camuso wrote:
Greg KH wrote:
On Wed, Dec 19, 2007 at 05:17:51PM -0500, [EMAIL PROTECTED] wrote:
+extern struct pci_ops pci_legacy_ops; /* direct.c */
This isn't needed in this patch at all, and might make the compiler
confused if you were to build with only this patch present
Greg KH wrote:
Sure, but you do not reference it in this patch, right? So it's not
needed until you actually use it, so just include it in the patch that
you are needing it in.
thanks,
greg k-h
Will do.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Greg KH wrote:
Ah, sorry, I was thinking you were using dev_info(), which is what you
should be using instead anyway :)
I found it in include/linux/device.h
#define dev_info(dev, format, arg...) \
dev_printk(KERN_INFO , dev , format , ## arg)
The info I'm trying to print
Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 09:22:05AM -0800, Greg KH wrote:
I can't imagine there are too many machines with MMCONFIG and an i830
chipset. The laptop I'm currently typing on is an i830 ... and its
BIOS is from 2002, well predating the specification of MMCONFIG. If I
didn't
.
Original Message
Subject: Re: [PATCH 4/5]PCI: x86 MMCONFIG: introduce pcibios_fix_bus_scan()
Date: Wed, 19 Dec 2007 19:17:42 -0500
From: Tony Camuso [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Greg KH [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED
Greg KH wrote:
Why haven't we gotten reports about this before if this is a common
problem?
And why hasn't the vendor fixed the bios on these to work properly?
I can't really answer either of these questions. All I know is the
problem exists, and we need to deal with it.
That's why the
Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
0x, we could look
Loic Prylli wrote:
Always using type 1 for accesses below 256 bytes looks like a very very
attractive solution
I know we had a lot of older kernels over the last two years that we
patched like that (we needed MMCONFIG for our own device development
purposes, but we also needed our machines to
Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
0x, we could look
Matthew Wilcox wrote:
Here's how BARs work ... when you write 0x to the BAR, it
ignores all the set bits that are less than the size of the BAR. So,
assuming this is a 256MB BAR (like my G33 is), what ends up written to
this BAR is 0xf000. Now, because this is graphics, apparently
Ivan Kokshaysky wrote:
On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
Does anybody see a down side to this?
It'll be slower than it would be if we used mmconfig directly. Now yes,
nobody should be using pci config
Ivan Kokshaysky wrote:
Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
is to avoid touching BARs with mmconfig.
Ivan.
Re-thinking this ...
The problem I see with this approach is that it does not help devices
that are mmconfig-unfriendly and will not work above the
Greg KH wrote:
On Thu, Dec 20, 2007 at 01:25:57PM -0500, Tony Camuso wrote:
Any reason why these changes were never submitted to the upstream kernel
versions? Or do you all just want to keep patching your newer releases
with this information forever? :)
I really don't know why these changes
Greg KH wrote:
Sure, I realize this, but it solves the problem in one way for broken
hardware, such that it at least allows it to work, right? It also
provides a better incentive for the manufacturer to fix their bios,
which as you are on-site at HP, it would seem odd that they would just
not
Robert Hancock wrote:
First off, I would like to see confirmation from the horses's mouths
here (namely AMD, ServerWorks/Broadcom, and whoever else) that there is
no other way to get around this problem than disabling MMCONFIG for
accesses behind those chips.
I happen to have this one
Robert Hancock wrote:
First off, I would like to see confirmation from the horses's mouths
here (namely AMD, ServerWorks/Broadcom, and whoever else) that there
is no other way to get around this problem than disabling MMCONFIG for
accesses behind those chips.
And here are the excerpts
Robert Hancock wrote:
The case of the device built into the K8 northbridge that's unreachable
by MMCONFIG kind of makes sense, since the northbridge is what's
translating the MMCONFIG memory access into config accesses. It seems
bizarre to me that a bridge chip could possibly have such a
Robert Hancock wrote:
I have to wonder why certain system
designers then didn't follow their strong recommendation..
I don't think I want to go there.
I used to be a hardware/firmware guy.
:D :D
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Loic Prylli wrote:
Just curious, do you know of any system where that recommendation was
not followed? On all motherboards where I have seen a AMD-8131 or a
AMD-8132, they were alone on their hypertransport link, and other
northbridges (more precisely hypertransport to pci-express or
Some corrections to the preamble.
The large amount of text is due to the nature of the
problem and the discussion it engendered on the lkml.
Should say:
The large amount of text in the explanation below is due to
the nature of the problem and the discussion engendered on
lkml by my first
I need to resubmit this patch.
Resubmission will be in my next email.
It was a minor problem whereby the patch would advise the user
If a device isn't working, try pci=nommconf.
even when pci=mmconf was used at the command line.
One additional line of logic fixed it, but I would like
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 10:15:45 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
specific to legacy x86 hardware is, IMNSHO, a kludge.
in addition to pci_enable(), pci_enable_msi(), pci_enable_busmaster() they
already need to do
to enable various features?
These calls
Greg KH wrote:
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
I'm more optimistic because we've so severely restricted the use of
mmconf after these patches that it's unlikely to cause problems. I also
hear Vista is now using mmconf, so fewer implementations are going to
be
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Greg,
The problem with Arjan's patch, if I understand it correctly, is that
it requires drivers to make a call to access extended PCI config
space.
And, IIRC, Arjan's patch encumbers drivers
Matthew Wilcox wrote:
On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
Right now, that isn't a lot of people in x86 land, but your patch
encumbers drivers for non-x86 archs with an additional call to access
space that they've never had a problem with.
lets say s/x86/x86, IA64
I agree with Matthew.
My preference is Ivan's patch using Loic's proposal.
My patch would have tested MMCONFIG before using it, but it didn't
fix the problem where the decode of large displacement devices can
overlap the MMCONFIG region.
Ivan's patch fixes that, and the problem of Northbridges
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the MMCONFIG issues discussed in this thread are going
to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
rather have the upstream patch implemented, whatever it is.
Grant Grundler
proceeds
according to the kernel default.
Tested-by: Jim Paradis jpara...@redhat.com
Signed-off-by: Robert Evans robert.ev...@stratus.com
Signed-off-by: Jim Paradis jpara...@redhat.com
Signed-off-by: Tony Camuso tcam...@redhat.com
---
drivers/char/ipmi/ipmi_si_intf.c | 28
RHEL builds the ipmi_si into the kernel by default, rather than as a
module, because it is required early in order to be available for ACPI
opregion access. However, it appears that some of our customers have
custom ipmi drivers, and this gets in their way.
Stratus is currently evaluating your
on both ACPI namespace and SMBIOS table.
ipmi_pnp_probe() should call add_smi() instead of try_smi_init()
For reference, see upstream commit ...
2407d77a1a013b88ee3b817f2b934e420e5376f5
Signed-off-by: Tony Camuso tcam...@redhat.com
---
drivers/char/ipmi/ipmi_si_intf.c |2 +-
1 files changed
Rescinding.
This hunk is already upstream.
On 01/08/2013 03:12 PM, Tony Camuso wrote:
Upstream commit 9e368fa0 added function ipmi_pnp_probe(), which
calls try_smi_init() directly.
try_smi_init() allocates resources for IPMI driver. However
try_smi_init() can be called again
.
Reported-by: Tony Camuso tcam...@redhat.com
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
James, can you please take this one directly and push it to next please?
As it causes a build failure on ppc
drivers/char/tpm/tpm.c | 2 +-
drivers/char/tpm/tpm.h | 1 +
2 files changed, 2 insertions
From: tcam...@redhat.com
From: Tony Camuso tcam...@redhat.com
We were getting occasional Scheduling while atomic call traces
during boot on some systems. Problem was first seen on a Cisco C210
but we were able to reproduce it on a Cisco c220m3. Setting
CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y
and regressions with netperf
and DEBUG_LOCKDEP and DEBUG_SPINLOCK enabled.
Signed-off-by: Tony Camuso tcam...@redhat.com
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
and softirq contexts.
This patch was tested for functionality and regressions with netperf
and DEBUG_LOCKDEP and DEBUG_SPINLOCK enabled.
Signed-off-by: Tony Camuso tcam...@redhat.com
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Signed-off-by: Jan Stancek <jstan...@redhat.com>
Signed-off-by: Tony Camuso <tcam...@redhat.com>
---
drivers/char/ipmi/ipmi_si_intf.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 55f
On 06/20/2016 04:57 PM, Corey Minyard wrote:
On 06/20/2016 01:26 PM, Tony Camuso wrote:
Port I/O space does not exist in ARM64 and is not mapped. Attempts to
access it on ARM systems cause stack traces and worse.
At this point, I think it is best to just completely pull out all concept
egressions and functionality on x86_64 and ARM64.
Signed-off-by: Tony Camuso <tcam...@redhat.com>
---
drivers/char/ipmi/ipmi_si_intf.c | 73
1 file changed, 73 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf
Port I/O space does not exist in ARM64 and is not mapped. Attempts to
access it on ARM systems cause stack traces and worse.
Signed-off-by: Tony Camuso <tcam...@redhat.com>
---
drivers/char/ipmi/ipmi_si_intf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/cha
On 06/22/2016 01:22 PM, Tony Camuso wrote:
Parameter trydefaults=1 causes the ipmi_init to initialize ipmi through
the legacy port io space that was designated for ipmi. Architectures
that do not map legacy port io can panic when trydefaults=1.
Rather than implement build-time conditional
On 06/28/2016 08:11 AM, Corey Minyard wrote:
On 06/28/2016 05:14 AM, Tony Camuso wrote:
On 06/27/2016 09:34 PM, Corey Minyard wrote:
Queued for 2.18, if that is ok.
Thanks,
-corey
Yes, as long as there's enough time to shake it out before it's merged
with Linus. I've done some testing
ace in dmesg.
To correct the problem, simply use smi_num instead of the hard-coded
value of zero.
Tested on a lenovo x3950.
Signed-off-by: Tony Camuso <tcam...@redhat.com>
---
drivers/char/ipmi/ipmi_si_intf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
On 04/10/2017 01:43 PM, miny...@acm.org wrote:
From: Tony Camuso <tcam...@redhat.com>
Commit 1abf71e moved the creation of new_smi->dev to earlier in the init
sequence in order to provide infrastructure for log printing.
However, the init_name was created with a hard-coded valu
On 04/10/2017 01:43 PM, miny...@acm.org wrote:
From: Tony Camuso <tcam...@redhat.com>
Commit 1abf71e moved the creation of new_smi->dev to earlier in the init
sequence in order to provide infrastructure for log printing.
However, the init_name was created with a hard-coded valu
On 04/10/2017 01:43 PM, miny...@acm.org wrote:
From: Tony Camuso <tcam...@redhat.com>
Commit 1abf71e moved the creation of new_smi->dev to earlier in the init
sequence in order to provide infrastructure for log printing.
However, the init_name was created with a hard-coded valu
On 06/19/2017 09:31 AM, Corey Minyard wrote:
On 06/16/2017 07:15 AM, Corey Minyard wrote:
On 06/15/2017 10:54 AM, Corey Minyard wrote:
On 06/13/2017 09:54 AM, Tony Camuso wrote:
A vendor with a system having more than 128 CPUs occasionally encounters a
crash during shutdown
On 06/19/2017 10:32 AM, Corey Minyard wrote:
On 06/19/2017 09:29 AM, Tony Camuso wrote:
On 06/19/2017 09:31 AM, Corey Minyard wrote:
On 06/16/2017 07:15 AM, Corey Minyard wrote:
On 06/15/2017 10:54 AM, Corey Minyard wrote:
On 06/13/2017 09:54 AM, Tony Camuso wrote:
A vendor with a system
On 06/19/2017 01:17 PM, Tony Camuso wrote:
A vendor with a system having more than 128 CPUs occasionally encounters
the following crash during shutdown. This is not an easily reproduceable
event, but the vendor was able to provide the following analysis of the
crash, which exhibits the same
.
A note below
On 06/19/2017 12:17 PM, Tony Camuso wrote:
A vendor with a system having more than 128 CPUs occasionally encounters
the following crash during shutdown. This is not an easily reproduceable
event, but the vendor was able to provide the following analysis of the
crash, which
X
880859df4070: 0001 880859df4078 x@.Y
If we regards it as struct ipmi_smi in shutdown process
it looks consistent.
The remedy for this apparent race is affixed below.
Signed-off-by: Tony Camuso <tcam...@redhat.com>
---
drivers/char/ipmi/ipmi_msghandler.c
070: 0001 880859df4078 x@.Y
If we regards it as struct ipmi_smi in shutdown process
it looks consistent.
The remedy for this apparent race is affixed below.
Signed-off-by: Tony Camuso <tcam...@redhat.com>
---
drivers/char/ipmi/ipmi_msghandler.c | 9
On 06/16/2017 08:15 AM, Corey Minyard wrote:
On 06/15/2017 10:54 AM, Corey Minyard wrote:
On 06/13/2017 09:54 AM, Tony Camuso wrote:
A vendor with a system having more than 128 CPUs occasionally encounters a
crash during shutdown. This is not an easily reproduceable event, but the
vendor
From: tcam...@redhat.com
From: Tony Camuso
We were getting occasional "Scheduling while atomic" call traces
during boot on some systems. Problem was first seen on a Cisco C210
but we were able to reproduce it on a Cisco c220m3. Setting
CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed
n about it anymore.
>
> Reported-by: Tony Camuso
> Signed-off-by: Peter Huewe
> ---
> James, can you please take this one directly and push it to next please?
> As it causes a build failure on ppc
>
> drivers/char/tpm/tpm.c | 2 +-
> drivers/char/tpm/tpm.h | 1 +
&g
on both ACPI namespace and SMBIOS table.
ipmi_pnp_probe() should call add_smi() instead of try_smi_init()
For reference, see upstream commit ...
2407d77a1a013b88ee3b817f2b934e420e5376f5
Signed-off-by: Tony Camuso
---
drivers/char/ipmi/ipmi_si_intf.c |2 +-
1 files changed, 1 insertions
Rescinding.
This hunk is already upstream.
On 01/08/2013 03:12 PM, Tony Camuso wrote:
Upstream commit 9e368fa0 added function ipmi_pnp_probe(), which
calls try_smi_init() directly.
try_smi_init() allocates resources for IPMI driver. However
try_smi_init() can be called again
Greg,
Have you given this patch-set any more consideration?
I've submitted the changes you requested.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 2007-12-20 at 22:50 +0300, Ivan Kokshaysky wrote:
> Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
> is to avoid touching BARs with mmconfig.
>
> Ivan.
I've tried Ivan's suggestion, and it works.
The patch is appended below.
My question is, do we want to
, Greg KH wrote:
> On Mon, Jan 07, 2008 at 10:20:23PM -0500, Tony Camuso wrote:
> > Greg,
> >
> > Have you given this patch-set any more consideration?
>
> Which patch-set, there have been a number of them :)
>
> > I've submitted the changes you requested.
Thanks, Greg.
Have a safe flight!
On Tue, 2008-01-08 at 05:36 -0800, Greg KH wrote:
> On Tue, Jan 08, 2008 at 08:14:22AM -0500, Tony Camuso wrote:
> > I'll respin the whole kit with [PATCH ?/5][V2]PCI: x86 MMCONFIG *
> > in the subject line, where the ? is replaced by the number o
blems or regressions.
Signed-off-by: Tony Camuso <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg,
Any thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sorry,
Meant to press reply/all.
Forwarded Message
From: Tony Camuso <[EMAIL PROTECTED]>
To: Greg KH <[EMAIL PROTECTED]>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a
driver opt-in
Date: Fri, 11 Jan 2008 20:58:52 -0500
Greg KH wrote:
> I
Arjan,
I have not seen your MMCONFIG patch.
Would you mind sending me a copy?
Thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Thanks, Arjan.
The problem we have been experiencing has to do with Northbridges,
not with devices.
As far as the device is concerned, after the Northbridge translates
the config access into PCI bus cycles, the device has no idea what
mechanism drove the Northbridge to the translation.
That is
Arjan van de Ven wrote:
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
Just about NOBODY has devices that need the extended config space. At all.
The PCI express spec requires the platform to provide access to this space
for express-compliance. More d
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's not
going away, and especially not in x86 land where Port IO is built-in
to the CPU.
again sadly you're wrong.
As someone gently pointed out to me, you are in a position to know this,
so I probably am
To all ...
Well, here is what I perceive we've got so far.
. Some PCI Northbridges do not work with MMCONFIG.
. Some PCI BARs can overlap the MMCONFIG area during bus sizing.
It is hoped that new BIOSes will locate MMCONFIG in an area
safely out of the way of bus sizing code, but there can
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is
Arjan van de Ven wrote:
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
>>
If we're going to differentiate MMCONFIG from
some other access mechanism, it only needs to be done at the
Northbridge level. Devices are electrically ignorant of the protocol
used
Arjan van de Ven wrote:
it's not pci_enable_mmconf(), it's pci_enable_extended_config_space... it's
independent of the mechanism!
Arjan, you would be foisting this call on device drivers running on
arches that don't need any such distinction between extended config
space and < 256 bytes.
I
I agree with Matthew.
My preference is Ivan's patch using Loic's proposal.
My patch would have tested MMCONFIG before using it, but it didn't
fix the problem where the decode of large displacement devices can
overlap the MMCONFIG region.
Ivan's patch fixes that, and the problem of Northbridges
Greg KH wrote:
Please do not respond privately, please respond back on the list so that
everyone can see. That way I will respond, to do otherwise is rude to
the rest of the community...
thanks,
greg k-h
I'm very sorry.
It is certainly not my intention to be rude.
--
To unsubscribe from
.
Original Message
Subject: Re: [PATCH 1/5]PCI: x86 MMCONFIG: introduce PCI_USING_MMCONF
Date: Wed, 19 Dec 2007 18:58:45 -0500
From: Tony Camuso <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Greg KH <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
<[EMAIL
Original Message
Subject: Re: [PATCH 2/5]PCI: x86 MMCONFIG: add legacy pci conf functions
Date: Wed, 19 Dec 2007 19:07:27 -0500
From: Tony Camuso <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Greg KH <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
Original Message
Subject: Re: [PATCH 4/5]PCI: x86 MMCONFIG: introduce pcibios_fix_bus_scan()
Date: Wed, 19 Dec 2007 19:17:42 -0500
From: Tony Camuso <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Greg KH <[EMAIL PROTECTED]>
References:
<[EMAIL PROTE
Original Message
Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
Date: Wed, 19 Dec 2007 19:33:45 -0500
From: Tony Camuso <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Greg KH <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Original Message
Subject: Re: [PATCH 0/5]PCI: x86 MMCONFIG
Date: Wed, 19 Dec 2007 19:44:13 -0500
From: Tony Camuso <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Robert Hancock <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTE
Tony Camuso wrote:
Greg KH wrote:
On Wed, Dec 19, 2007 at 05:17:51PM -0500, [EMAIL PROTECTED] wrote:
+extern struct pci_ops pci_legacy_ops; /* direct.c */
This isn't needed in this patch at all, and might make the compiler
confused if you were to build with only this patch present
Greg KH wrote:
Sure, but you do not reference it in this patch, right? So it's not
needed until you actually use it, so just include it in the patch that
you are needing it in.
thanks,
greg k-h
Will do.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Greg KH wrote:
Ah, sorry, I was thinking you were using dev_info(), which is what you
should be using instead anyway :)
I found it in include/linux/device.h
#define dev_info(dev, format, arg...) \
dev_printk(KERN_INFO , dev , format , ## arg)
The info I'm trying to print
Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 09:22:05AM -0800, Greg KH wrote:
I can't imagine there are too many machines with MMCONFIG and an i830
chipset. The laptop I'm currently typing on is an i830 ... and its
BIOS is from 2002, well predating the specification of MMCONFIG. If I
didn't
1 - 100 of 150 matches
Mail list logo
