All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>,
	Bela Lubkin <blubkin@vmware.com>,
	linux-acpi@vger.kernel.org, Myron Stowe <myron.stowe@hp.com>,
	openipmi-developer@lists.sourceforge.net,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v1 3/5] ipmi: remove unused PCI probe coded
Date: Wed, 02 Dec 2009 15:34:38 -0600	[thread overview]
Message-ID: <4B16DD6E.90101@acm.org> (raw)
In-Reply-To: <200912021253.00726.bjorn.helgaas@hp.com>

Bjorn Helgaas wrote:
> I guess you're referring to b0defcdbd2b7d?
>
> Prior to that commit, we did this:
>
> 	int              fe_rmc = 0;
> 	...
>               if (pci_dev && (pci_dev->subsystem_vendor == PCI_HP_VENDOR_ID))
>                       fe_rmc = 1;
> 	...
>         if (! fe_rmc)
>               /* Data register starts at base address + 1 in eRMC */
>               ++base_addr;
> 	...
> 	if (! is_new_interface(-1, IPMI_IO_ADDR_SPACE, base_addr)) {
>
> Your patch above reverses the sense of this adjustment -- the old code
> increments the base for everything *except* HP, while the new code
> increments the base for *only* HP.
>   
You are correct.

> The original 5-patch series leaves the PCI base address alone.  That's
> the same as the old behavior for HP devices, and we verified that it
> works on an HP DL380G6 by disabling SMBIOS/SMPI/PNP detection.  (We
> also verified that, as you would expect, it did NOT work if we increment
> the base address).
>   
Ok, then your patch is fine as stands.

> Using the address straight from the PCI BAR, we located the IPMI interface
> correctly, and we were able to exercise it with ipmitool:
>
>     ipmi message handler version 39.2
>     ipmi device interface
>     IPMI System Interface driver.
>     ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 10
>     PCI: setting IRQ 10 as level-triggered
>     ipmi_si 0000:01:04.6: PCI INT A -> Link[LNKF] -> GSI 10 (level, low) -> IRQ 10
>     ipmi_si: Trying PCI-specified kcs state machine at mem address 0xf1ef0000, slave address 0x0, irq 10
>     IRQ 10/ipmi_si: IRQF_DISABLED is not guaranteed on shared IRQs
>       Using irq 10
>     ipmi: Found new BMC (man_id: 0x00000b,  prod_id: 0x0000, dev_id: 0x11)
>     IPMI kcs interface initialized
>
>     dl380g6a:~# ipmitool sensor
>     UID Light        | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na
>     Sys. Health LED  | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na
>     ...
>
> So the question is what to do about non-HP PCI IPMI interfaces.  The
> pre-b0defcdbd2b7d code increments the base address, but that's been
> gone for several years.  Since we've had no complaints, and we don't
> know about any non-HP PCI interfaces, I propose that we just remove
> that HP-specific adjustment completely, i.e., use this series as-is.
>   
To tell you the truth, I don't think there are any.  If there are, no 
one has complained.

So I'm happy with your original patch.

-corey

  parent reply	other threads:[~2009-12-02 21:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-18  0:05 [PATCH v1 0/5] IPMI devices from ACPI namespace Bjorn Helgaas
2009-11-18  0:05 ` [PATCH v1 1/5] PNPACPI: save struct acpi_device, not just acpi_handle Bjorn Helgaas
2009-11-18  0:05 ` [PATCH v1 2/5] PNP: add interface to retrieve ACPI device from a PNPACPI device Bjorn Helgaas
2009-11-18  0:05 ` [PATCH v1 3/5] ipmi: remove unused PCI probe code Bjorn Helgaas
2009-12-01 23:18   ` [PATCH v1 3/5] ipmi: remove unused PCI probe coded Corey Minyard
2009-12-02 19:53     ` Bjorn Helgaas
2009-12-02 21:04       ` Bela Lubkin
2009-12-02 21:36         ` Corey Minyard
2009-12-02 21:42         ` Bjorn Helgaas
2009-12-16 20:53         ` Bjorn Helgaas
2009-12-02 21:34       ` Corey Minyard [this message]
2009-11-18  0:05 ` [PATCH v1 4/5] ipmi: refer to table as "SPMI", not "ACPI" Bjorn Helgaas
2009-11-18  0:05 ` [PATCH v1 5/5] ipmi: add PNP discovery (ACPI namespace via PNPACPI) Bjorn Helgaas
2009-11-27  7:50   ` ykzhao
2009-11-18  2:29 ` [PATCH v1 0/5] IPMI devices from ACPI namespace ykzhao
2009-11-18 16:29   ` Bjorn Helgaas
2009-12-01 21:40 ` Bjorn Helgaas
2009-12-11  6:29 ` Len Brown
2009-12-11 13:36   ` Corey Minyard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B16DD6E.90101@acm.org \
    --to=minyard@acm.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=blubkin@vmware.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=myron.stowe@hp.com \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=yakui.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.