On Tue, Dec 6, 2011 at 12:22 AM, Chen Gong <gong.chen@xxxxxxxxxxxxxxx> wrote: > I don't think one knows how to set *vendor_flags* correctly if no any > instructions. Agreed - more documentation would help here - but I suspect that it needs to come from a vendor implementing an extension for specifics ... but for general how to use this - see more comments below. > need explanation in the document how to set error type in ACPI 5.0. > > In the spec it doesn't say this bit field is filled by the user, from > the codes I have following conclusion: one can set error type as 0x2, > 0x4, 0x8 etc. or 0x80000002, 0x80000004, 0x80000008 etc, right? The spec is pretty vague here - I'm assuming that as soon as the 0x80000000 bit is seen, the rest of the bits are fair game for the vendor to do anything they like. So I provided a way to set the error_type because I don't think there is any association between bits and error type. E.g. one vendor could use 0x80000001 for some special memory operation - so expect a memory address and mask, while another vendor could use the same 0x80000001 for a PCIe operation, so want to see a segment/bus/device/function. So I tried to be flexible. I'd expect that an application trying to use this would look at the contents of the /sys/kernel/debug/apei/einj/vendor to know that they were on the right platform, with the device/rev_id to use whatever vendor extension they want. But this needs more (some :-) ) Documentation Of course there is still some vendor defined memory at the very end of the structure that I have absolutely no idea what to do with. I've ignored it for now, but if some vendor does do something with it, we will need another vendor_blob interface to allow arbitrary bytes to be written to (and read from?) that area (just checking the size). The whole vendor extension part is very speculative on my part as I don't have any solid examples to test. I do have a platform that provides the structure. But I don't know whether it actually implements any extended operations. -Tony -- 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
