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.
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)? 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. -corey ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
