Re: [PATCH -v6 2/2] IPMI: use ACPI detection mechanism firstly to detect IPMI system interface

[ykzhao <yakui.zhao@intel.com>]

On Wed, 2010-06-09 at 21:08 +0800, Corey Minyard wrote:
> ykzhao wrote:
> > On Tue, 2010-06-08 at 09:34 +0800, Matthew Garrett wrote:
> >   
> >> On Tue, Jun 08, 2010 at 09:28:51AM +0800, ykzhao wrote:
> >>
> >>     
> >>> Does there exist the ACPI detection mechanism on the machines you
> >>> mentioned? If exists, does it detect the same IPMI interface with the
> >>> PCI IPMI detection mechanism?
> >>>       
> >> What is "the same"? It's not using the same ioport space, certainly.
> >>     
> >
> > "The same" means that they will use the same ioport space/address.
> > If they use the different ioport space/address, they will be regarded as
> > the different IPMI device.
> >
> >   
> >>> If the two mechanisms will detect the same IPMI interface, I agree with
> >>> what you are concerned.  Do you have an idea/thought to set up the
> >>> relationship between ACPI and IPMI interface? In order to enable that
> >>> AML code can access the IPMI, it should know which IPMI interface will
> >>> be accessed and create the corresponding user interface. If ACPI
> >>> mechanism will fail to register the IPMI interface, maybe it is
> >>> difficult to create the correct user interface.
> >>>       
> >> Well, right now if you change the ordering then the PCI interface will 
> >> never be exposed. It would be preferable to only expose the ACPI 
> >> interface as a user-visible device if there's no prior device - if there 
> >> is, I think the ideal solution would be for it to be an in-kernel only 
> >> device without a corresponding UI.
> >>     
> >
> > Sorry that I don't explain it clearly. The concept of "user interface"
> > in IPMI interface is only a channel that can be used to communicate with
> > the IPMI controller. It has no relationship with whether the IPMI
> > interface should be exposed to user space. If one driver wants to
> > communicate with one IPMI interface, we should create one "user
> > interface" firstly and send the corresponding IPMI message by using the
> > "user interface".
> >
> > If one IPMI interface(controller) is already detected by PCI mechanism,
> > then ACPI will fail to detect the same IPMI interface. In such case it
> > is difficult for ACPI to know which IPMI interface should be accessed
> > when the ACPI AML code need to communicate with the IPMI interface.
> >   
> This may all be true, but the IPMI specification clearly gives the 
> detection order.  It's not a good idea to deviate from that without a 
> very good reason.  I'm not sure this is a good enough reason.

Sorry that I don't pay attention to the discovery order. I relook at the
IPMI spec and find that I am wrong.

> 
> Also, the bulk of this code clearly has nothing to do with the system 
> interface itself and should be in its own file.  And is there any reason 
> to tie this to the SMI code, anyway?  There are plenty of systems with 
> IPMI and ACPI that use I2C or serial ports.  Can they not use this ACPI 
> function (even though their drivers are not in the mainstream kernel)?

My first thought is to put the ACPI-IPMI opregion handler into ACPI
subsystem. But Bjorn suggests that it can be put into the smi code. Then
I follow his suggestion.

OK. I will rewrite the code and don't tie the ACPI-IPMI opregion handler
to the smi code.
    
> 
> Can you look and see if there is some other way to detect the ACPI 
> function on a BMC with some other mechanism?  I think that would be 
> better all around.  If it's the same BMC, the I can't imagine it matters 
> if you send the messages via the PCI-detected or ACPI-detected mechanisms.

OK. I will think about it again and try to figure out one solution that
identify the same BMC via PCI-detected or ACPI-detected and avoids
adjusting the discovery order. 

Thanks for your idea.


> 
> -corey

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html