On 12/23/2015 04:43 AM, jung wrote: > > > 2015-12-15 0:44 GMT+08:00 Corey Minyard <[email protected] > <mailto:[email protected]>>: > > On 11/25/2015 07:00 AM, jung wrote: > > > 2015-11-16 20:37 GMT+08:00 Corey Minyard <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>: > > On 11/16/2015 12:29 AM, jung wrote: > > 2015-11-16 10:18 GMT+08:00, Corey Minyard > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>: > > >> On 11/14/2015 09:59 PM, jung wrote: > >>> Hi,all > >>> In X86 platform, host communication with BMC > controller > through BT > >>> protocol, and the underlayer of BT is LPC (Low Pin Count), > usually we > >>> use LPC in a tranparent mode, if we want to write an > 0xa5 to > LPC slave > >>> addr 0x2f8, just call outb(0xa5, 0x2f8). > Unfortunately, The > >>> recent platform we are developing for has a different > case, we > have > >>> wrote a lpc driver for it, to complete the same function I > must call > >>> verderspecific_lpc_write(0xa5, 0x2f8), thus, the ipmi > driver > is not > >>> compatiable with our platform. Can you give me some > sugguestions, can > >>> ipmi export some symbol for vendors to register their > own lpc > methold. > >>> > >> It should be easy enough to add a a new setup type. If you > search for > >> io_setup in ipmi_si_intf.c, you will find either mem or > port > setup. You > >> could easy add a third that has your vendor-specific I/O. > > As your said, it is easy to add a new setup type. > > case IPMI_MEM_ADDR_SPACE: > > info->io_setup = mem_setup; > > info->io.addr_type = IPMI_MEM_ADDR_SPACE; > > break; > > case IPMI_IO_ADDR_SPACE: > > info->io_setup = port_setup; > > info->io.addr_type = IPMI_IO_ADDR_SPACE; > > break; > > case IPMI_VENDOR_ADDR_SPACE: > > info->io_setup = vendor_specific_setup; > > info->io.addr_type = IPMI_VENDOR_ADDR_SPACE; > > break; > > my question is: I want to submit this code to to kernel. > Do you mind > > a vendor-specific function in the general ipmi driver ? > Although > I will > > use #ifdef for it > > . > > An ifdef is not required, though there needs to be some > way to detect > this. You don't need IPMI_VENDOR_ADDR_SPACE, necessarily, but > you need some automatic way to detect that this is your > hardware and > it needs special handling. > > I can detect CPU type by decoding DMI, but how can i use my > special handling. > There are 2 ways: > > 1) Ipmi_si.ko call vender_specific_inb()/ > vender_specific_outb() which is in vender_specific_io.ko. > and the ipmi_si.ko depend on vender_specific_io.ko > > 2) Interface "register_third_party_io" is exported from > ipmi_si.ko and is called in > verder_specific_io.ko, However, ipmi_si must run in > built-in mode rather than .ko mode. > The symbol "register_third_party_io" can be found whenever > verder_specific_io.ko runs. > > Is there any way else? > > > > Sorry, I missed this earlier. > > You may be able to use the "System Information" or "Base Board > Information" in DMI. I'm not sure how to get to this information, > though. > > You can also use ACPI, it does seem to support passing some > vendor-specific information in the IPMI device control method. I > think you can set _HID to something custom and set _CID to IPI0001. > > It's going to take some digging, I think. > > > > > I found a better way, I am going to hook the lpc_inb and lpc_outb to > inb and outb; > > Implement as follows: > > inb(port) > { > is(port < 0x1000) > { > lpc_inb(port); > } > else > { > //use the common inb defined in asm/io.h > } > } > > So ipmi_si_intf.c need no modifications. I will commit the detail > implmention later. >
Ok, that works, too, and it covers any other devices that need it, too, I suppose. -corey > > -corey > > > >> However, my big question is: How you are going to > discover the > >> interface? IPMI has a lot of ways to be discovered > (ACPI, DMI, > >> hardcoded, hot-add, openfirmware, and a few others). > > I can use DMI or DT. > > DT on x86 is a little unusual, I guess, but not unheard of. > > -corey > > >> -corey > >> > >>> reguards. > >>> > >>> jung > >> > > > > 2015-11-16 10:18 GMT+08:00, Corey Minyard > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>: > > >> On 11/14/2015 09:59 PM, jung wrote: > >>> Hi,all > >>> In X86 platform, host communication with BMC > controller > through BT > >>> protocol, and the underlayer of BT is LPC (Low Pin Count), > usually we > >>> use LPC in a tranparent mode, if we want to write an > 0xa5 to > LPC slave > >>> addr 0x2f8, just call outb(0xa5, 0x2f8). > Unfortunately, The > >>> recent platform we are developing for has a different > case, we > have > >>> wrote a lpc driver for it, to complete the same function I > must call > >>> verderspecific_lpc_write(0xa5, 0x2f8), thus, the ipmi > driver > is not > >>> compatiable with our platform. Can you give me some > sugguestions, can > >>> ipmi export some symbol for vendors to register their > own lpc > methold. > >>> > >> It should be easy enough to add a a new setup type. If you > search for > >> io_setup in ipmi_si_intf.c, you will find either mem or > port > setup. You > >> could easy add a third that has your vendor-specific I/O. > >> > >> However, my big question is: How you are going to > discover the > >> interface? IPMI has a lot of ways to be discovered > (ACPI, DMI, > >> hardcoded, hot-add, openfirmware, and a few others). > >> > >> -corey > >> > >>> reguards. > >>> > >>> jung > >> > > > > > > ------------------------------------------------------------------------------ _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
