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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
