Re: [PATCH] PCI: restore 2 missing pci ids

Re: [PATCH] PCI: restore 2 missing pci ids

[Jeff Garzik]

Linux Kernel Mailing List wrote:
> tree e425ac74afc0b89f3a513290a2dd5e503d974906
> parent 654143ee3a73b2793350b039a135d9cd3101147b
> author Mark Rustad <MRustad@mac.com> Fri, 06 Jan 2006 14:47:29 -0800
> committer Greg Kroah-Hartman <gregkh@suse.de> Wed, 01 Feb 2006 10:00:11 -0800
> 
> [PATCH] PCI: restore 2 missing pci ids
> 
> Somewhere between 2.6.14 and 2.6.15-rc3, some PCI ids were apparently
> removed.  The ecc.c module, which is not a part of the kernel.org tree, but
> included in some distributions, fails to compile.
> 
> Signed-off-by: Mark Rustad <mrustad@mac.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
>  include/linux/pci_ids.h |    2 ++
>  1 files changed, 2 insertions(+)

Why was this applied?  We could apply these patches all day, and get 
nothing else done.  If it's not in the kernel tree, we shouldn't be 
worrying about it.  Let the distros patch it in.

	Jeff

Re: [PATCH] PCI: restore 2 missing pci ids

[Mark Rustad]

Jeff,

On Feb 1, 2006, at 12:00 PM, Jeff Garzik wrote:

> Linux Kernel Mailing List wrote:
>> tree e425ac74afc0b89f3a513290a2dd5e503d974906
>> parent 654143ee3a73b2793350b039a135d9cd3101147b
>> author Mark Rustad <MRustad@mac.com> Fri, 06 Jan 2006 14:47:29 -0800
>> committer Greg Kroah-Hartman <gregkh@suse.de> Wed, 01 Feb 2006  
>> 10:00:11 -0800
>> [PATCH] PCI: restore 2 missing pci ids
>> Somewhere between 2.6.14 and 2.6.15-rc3, some PCI ids were apparently
>> removed.  The ecc.c module, which is not a part of the kernel.org  
>> tree, but
>> included in some distributions, fails to compile.
>> Signed-off-by: Mark Rustad <mrustad@mac.com>
>> Signed-off-by: Andrew Morton <akpm@osdl.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>>  include/linux/pci_ids.h |    2 ++
>>  1 files changed, 2 insertions(+)
>
> Why was this applied?  We could apply these patches all day, and  
> get nothing else done.  If it's not in the kernel tree, we  
> shouldn't be worrying about it.  Let the distros patch it in.

Well, I offered the patch because I found that I suddenly needed it.  
I did not know why the ids had been removed, but it looks to me like  
edac is coming right along and will need the ids itself, so I sent  
the patch off.

Frankly, I was surprised that the patch was so quickly accepted. I  
perceive some difference of opinion on how PCI ids should be handled.  
Is there a consensus on a better way to handle ids? Why were the ids  
removed in the first place? THAT was worse than wasted effort.

-- 
Mark Rustad, MRustad@mac.com

Re: [PATCH] PCI: restore 2 missing pci ids

[Lee Revell]

On Wed, 2006-02-01 at 23:11 -0600, Mark Rustad wrote:
> Why were the ids  
> removed in the first place? 

Because they weren't used by anything in the tree.

Lee

Re: [PATCH] PCI: restore 2 missing pci ids

[Kyle Moffett]

On Feb 02, 2006, at 00:19, Lee Revell wrote:
> On Wed, 2006-02-01 at 23:11 -0600, Mark Rustad wrote:
>> Why were the ids removed in the first place?
>
> Because they weren't used by anything in the tree.

Also, the new PCI-ID policy is to put the defines in the driver  
itself, near where it is used, instead of collecting them in a single  
file.  The goal is to minimize the number of unused PCI IDs in the  
tree by keeping the definition near the usage.

Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/ 
philosophy/) software stuff and not get a real job. Charles Schulz  
had the best answer:

"Why do musicians compose symphonies and poets write poems? They do  
it because life wouldn't have any meaning for them if they didn't.  
That's why I draw cartoons. It's my life."
   -- Charles Schulz

Re: [PATCH] PCI: restore 2 missing pci ids

[Jeff Garzik]

Kyle Moffett wrote:
> On Feb 02, 2006, at 00:19, Lee Revell wrote:
> 
>> On Wed, 2006-02-01 at 23:11 -0600, Mark Rustad wrote:
>>
>>> Why were the ids removed in the first place?
>>
>>
>> Because they weren't used by anything in the tree.
> 
> 
> Also, the new PCI-ID policy is to put the defines in the driver  itself, 
> near where it is used, instead of collecting them in a single  file.  
> The goal is to minimize the number of unused PCI IDs in the  tree by 
> keeping the definition near the usage.

No, if you do create a constant for a PCI ID, it still should go into 
include/linux/pci_ids.h.

Putting them in the driver will result in highly variable naming 
policies, which in turn means the constants are less grep-able than today.

Device IDs simply do not need an associated constant, if they are used 
only in a PCI ID table.  Device IDs are arbitrary numbers that are 
normally only used once in a source file.

Vendor IDs are used repeatedly, and definitely belong in pci_ids.h. 
Device IDs make sense in pci_ids.h if they are used more than once.

	Jeff

Re: [PATCH] PCI: restore 2 missing pci ids

[Mark Rustad]

On Feb 2, 2006, at 1:28 AM, Jeff Garzik wrote:

> Kyle Moffett wrote:
>> On Feb 02, 2006, at 00:19, Lee Revell wrote:
>>> On Wed, 2006-02-01 at 23:11 -0600, Mark Rustad wrote:
>>>
>>>> Why were the ids removed in the first place?
>>>
>>> Because they weren't used by anything in the tree.
>> Also, the new PCI-ID policy is to put the defines in the driver   
>> itself, near where it is used, instead of collecting them in a  
>> single  file.  The goal is to minimize the number of unused PCI  
>> IDs in the  tree by keeping the definition near the usage.
>
> No, if you do create a constant for a PCI ID, it still should go  
> into include/linux/pci_ids.h.
>
> Putting them in the driver will result in highly variable naming  
> policies, which in turn means the constants are less grep-able than  
> today.
>
> Device IDs simply do not need an associated constant, if they are  
> used only in a PCI ID table.  Device IDs are arbitrary numbers that  
> are normally only used once in a source file.
>
> Vendor IDs are used repeatedly, and definitely belong in pci_ids.h.  
> Device IDs make sense in pci_ids.h if they are used more than once.

Thank you for explaining the policy. In this particular case, there  
was only one use of the ID in the file in question, so it could have  
simply been a hex constant, I guess. Of course my instinct is to  
avoid weird constants like this in source code, but I can learn to  
make an exception for this kind of thing.

-- 
Mark Rustad, MRustad@mac.com

[PATCH] PCI Hotplug: shpchp: AMD POGO errata fix

[Greg KH]

[PATCH] PCI Hotplug: shpchp: AMD POGO errata fix

This patch fixes the AMD POGO errata on the hotplug controller where the
platform will lock up or reboot if PERR/SERR generation is enabled and a
slot is sent an enable command.  This fix disables PERR/SERR generation
before a slot is sent the enable command by first saving related
registers, turning off SERR/PERR generation, enabling the slot, then
restoring the registers.

Signed-off-by: David Keck <david.keck@amd.com>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
commit 74fe8a7679336ce8229401b13f7af364694818b1
tree 7e81db557f6d91a08ef8bcea60c4910fd7de1d86
parent 40ae159c997fbabbf864283dda902850d136d5aa
author Keck, David <david.keck@amd.com> Mon, 16 Jan 2006 15:22:36 -0600
committer Greg Kroah-Hartman <gregkh@suse.de> Fri, 20 Jan 2006 10:29:34 -0800

 drivers/pci/hotplug/shpchp.h      |   94 +++++++++++++++++++++++++++++++++++++
 drivers/pci/hotplug/shpchp_ctrl.c |   12 ++++-
 2 files changed, 105 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/hotplug/shpchp.h b/drivers/pci/hotplug/shpchp.h
index ce0e9b6..7d6f521 100644
--- a/drivers/pci/hotplug/shpchp.h
+++ b/drivers/pci/hotplug/shpchp.h
@@ -95,6 +95,7 @@ struct controller {
 	u8 function;
 	u8 slot_device_offset;
 	u8 add_support;
+	u32 pcix_misc2_reg;	/* for amd pogo errata */
 	enum pci_bus_speed speed;
 	u32 first_slot;		/* First physical slot number */
 	u8 slot_bus;		/* Bus where the slots handled by this controller sit */
@@ -113,6 +114,26 @@ struct hotplug_params {
 
 /* Define AMD SHPC ID  */
 #define PCI_DEVICE_ID_AMD_GOLAM_7450	0x7450 
+#define PCI_DEVICE_ID_AMD_POGO_7458	0x7458
+
+/* AMD PCIX bridge registers */
+
+#define PCIX_MEM_BASE_LIMIT_OFFSET	0x1C
+#define PCIX_MISCII_OFFSET		0x48
+#define PCIX_MISC_BRIDGE_ERRORS_OFFSET	0x80
+
+/* AMD PCIX_MISCII masks and offsets */
+#define PERRNONFATALENABLE_MASK		0x00040000
+#define PERRFATALENABLE_MASK		0x00080000
+#define PERRFLOODENABLE_MASK		0x00100000
+#define SERRNONFATALENABLE_MASK		0x00200000
+#define SERRFATALENABLE_MASK		0x00400000
+
+/* AMD PCIX_MISC_BRIDGE_ERRORS masks and offsets */
+#define PERR_OBSERVED_MASK		0x00000001
+
+/* AMD PCIX_MEM_BASE_LIMIT masks */
+#define RSE_MASK			0x40000000
 
 #define INT_BUTTON_IGNORE		0
 #define INT_PRESENCE_ON			1
@@ -333,6 +354,79 @@ static inline int wait_for_ctrl_irq (str
 	return retval;
 }
 
+static inline void amd_pogo_errata_save_misc_reg(struct slot *p_slot)
+{
+	u32 pcix_misc2_temp;
+
+	/* save MiscII register */
+	pci_read_config_dword(p_slot->ctrl->pci_dev, PCIX_MISCII_OFFSET, &pcix_misc2_temp);
+
+	p_slot->ctrl->pcix_misc2_reg = pcix_misc2_temp;
+
+	/* clear SERR/PERR enable bits */
+	pcix_misc2_temp &= ~SERRFATALENABLE_MASK;
+	pcix_misc2_temp &= ~SERRNONFATALENABLE_MASK;
+	pcix_misc2_temp &= ~PERRFLOODENABLE_MASK;
+	pcix_misc2_temp &= ~PERRFATALENABLE_MASK;
+	pcix_misc2_temp &= ~PERRNONFATALENABLE_MASK;
+	pci_write_config_dword(p_slot->ctrl->pci_dev, PCIX_MISCII_OFFSET, pcix_misc2_temp);
+}
+
+static inline void amd_pogo_errata_restore_misc_reg(struct slot *p_slot)
+{
+	u32 pcix_misc2_temp;
+	u32 pcix_bridge_errors_reg;
+	u32 pcix_mem_base_reg;
+	u8  perr_set;
+	u8  rse_set;
+
+	/* write-one-to-clear Bridge_Errors[ PERR_OBSERVED ] */
+	pci_read_config_dword(p_slot->ctrl->pci_dev, PCIX_MISC_BRIDGE_ERRORS_OFFSET, &pcix_bridge_errors_reg);
+	perr_set = pcix_bridge_errors_reg & PERR_OBSERVED_MASK;
+	if (perr_set) {
+		dbg ("%s  W1C: Bridge_Errors[ PERR_OBSERVED = %08X]\n",__FUNCTION__ , perr_set);
+
+		pci_write_config_dword(p_slot->ctrl->pci_dev, PCIX_MISC_BRIDGE_ERRORS_OFFSET, perr_set);
+	}
+
+	/* write-one-to-clear Memory_Base_Limit[ RSE ] */
+	pci_read_config_dword(p_slot->ctrl->pci_dev, PCIX_MEM_BASE_LIMIT_OFFSET, &pcix_mem_base_reg);
+	rse_set = pcix_mem_base_reg & RSE_MASK;
+	if (rse_set) {
+		dbg ("%s  W1C: Memory_Base_Limit[ RSE ]\n",__FUNCTION__ );
+
+		pci_write_config_dword(p_slot->ctrl->pci_dev, PCIX_MEM_BASE_LIMIT_OFFSET, rse_set);
+	}
+	/* restore MiscII register */
+	pci_read_config_dword( p_slot->ctrl->pci_dev, PCIX_MISCII_OFFSET, &pcix_misc2_temp );
+
+	if (p_slot->ctrl->pcix_misc2_reg & SERRFATALENABLE_MASK)
+		pcix_misc2_temp |= SERRFATALENABLE_MASK;
+	else
+		pcix_misc2_temp &= ~SERRFATALENABLE_MASK;
+
+	if (p_slot->ctrl->pcix_misc2_reg & SERRNONFATALENABLE_MASK)
+		pcix_misc2_temp |= SERRNONFATALENABLE_MASK;
+	else
+		pcix_misc2_temp &= ~SERRNONFATALENABLE_MASK;
+
+	if (p_slot->ctrl->pcix_misc2_reg & PERRFLOODENABLE_MASK)
+		pcix_misc2_temp |= PERRFLOODENABLE_MASK;
+	else
+		pcix_misc2_temp &= ~PERRFLOODENABLE_MASK;
+
+	if (p_slot->ctrl->pcix_misc2_reg & PERRFATALENABLE_MASK)
+		pcix_misc2_temp |= PERRFATALENABLE_MASK;
+	else
+		pcix_misc2_temp &= ~PERRFATALENABLE_MASK;
+
+	if (p_slot->ctrl->pcix_misc2_reg & PERRNONFATALENABLE_MASK)
+		pcix_misc2_temp |= PERRNONFATALENABLE_MASK;
+	else
+		pcix_misc2_temp &= ~PERRNONFATALENABLE_MASK;
+	pci_write_config_dword(p_slot->ctrl->pci_dev, PCIX_MISCII_OFFSET, pcix_misc2_temp);
+}
+
 #define SLOT_NAME_SIZE 10
 
 static inline void make_slot_name(char *buffer, int buffer_size, struct slot *slot)
diff --git a/drivers/pci/hotplug/shpchp_ctrl.c b/drivers/pci/hotplug/shpchp_ctrl.c
index 25ccb0e..643252d 100644
--- a/drivers/pci/hotplug/shpchp_ctrl.c
+++ b/drivers/pci/hotplug/shpchp_ctrl.c
@@ -894,7 +894,17 @@ int shpchp_enable_slot (struct slot *p_s
 	dbg("%s: p_slot->pwr_save %x\n", __FUNCTION__, p_slot->pwr_save);
 	p_slot->hpc_ops->get_latch_status(p_slot, &getstatus);
 
-	rc = board_added(p_slot);
+	if(((p_slot->ctrl->pci_dev->vendor == PCI_VENDOR_ID_AMD) ||
+	    (p_slot->ctrl->pci_dev->device == PCI_DEVICE_ID_AMD_POGO_7458))
+	     && p_slot->ctrl->num_slots == 1) {
+		/* handle amd pogo errata; this must be done before enable  */
+		amd_pogo_errata_save_misc_reg(p_slot);
+		rc = board_added(p_slot);
+		/* handle amd pogo errata; this must be done after enable  */
+		amd_pogo_errata_restore_misc_reg(p_slot);
+	} else
+		rc = board_added(p_slot);
+
 	if (rc) {
 		p_slot->hpc_ops->get_adapter_status(p_slot,
 				&(p_slot->presence_save));

[PATCH] PCI: restore 2 missing pci ids

[Greg KH]

[PATCH] PCI: restore 2 missing pci ids

Somewhere between 2.6.14 and 2.6.15-rc3, some PCI ids were apparently
removed.  The ecc.c module, which is not a part of the kernel.org tree, but
included in some distributions, fails to compile.

Signed-off-by: Mark Rustad <mrustad@mac.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
commit 9b88de850747ab8ff39ce31ca6ff788210f9441a
tree a9ba9136f00c3434c6adf741b9b3f9308af42d73
parent d181278c96e0b59478bef909ec2476c40169e7ba
author Mark Rustad <MRustad@mac.com> Thu, 05 Jan 2006 22:47:29 -0800
committer Greg Kroah-Hartman <gregkh@suse.de> Fri, 20 Jan 2006 10:29:34 -0800

 include/linux/pci_ids.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 117e023..560b26a 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2065,6 +2065,7 @@
 #define PCI_DEVICE_ID_INTEL_82801EB_5	0x24d5
 #define PCI_DEVICE_ID_INTEL_82801EB_6	0x24d6
 #define PCI_DEVICE_ID_INTEL_82801EB_11	0x24db
+#define PCI_DEVICE_ID_INTEL_82801EB_13	0x24dd
 #define PCI_DEVICE_ID_INTEL_ESB_1	0x25a1
 #define PCI_DEVICE_ID_INTEL_ESB_2	0x25a2
 #define PCI_DEVICE_ID_INTEL_ESB_4	0x25a4
@@ -2154,6 +2155,7 @@
 #define PCI_DEVICE_ID_INTEL_82443GX_2	0x71a2
 #define PCI_DEVICE_ID_INTEL_82372FB_1	0x7601
 #define PCI_DEVICE_ID_INTEL_82454GX	0x84c4
+#define PCI_DEVICE_ID_INTEL_82450GX	0x84c5
 #define PCI_DEVICE_ID_INTEL_82451NX	0x84ca
 #define PCI_DEVICE_ID_INTEL_82454NX     0x84cb
 #define PCI_DEVICE_ID_INTEL_84460GX	0x84ea