On Tue, 2018-02-27 at 06:20 +0100, Lukas Wunner wrote: > On Mon, Feb 26, 2018 at 11:32:48PM +0200, Andy Shevchenko wrote: > > There is as far as we know no type field in the struct dev_header > > provided. Thus, assume that values of all properties are type of > > u32. > > There is no type field, but the value can be something else than u32. > > See here for sample properties: > https://gist.github.com/l1k/d58ff1e24976118d24f2bf550253a507 > > E.g. the "ThunderboltDROM" property is a raw 256 byte array which is > consumed by thunderbolt.ko. It's up to the drivers to make sense of > the properties and assume a certain type. In that case it can't use built-in device properties at all. Or somehow you need to supply a type. (I though about some kind of heuristics, but it might not work on some corner cases) Or completely rework built-in device property interface (which I think absolutely no go). > > Deterministic type of property values is required to avoid union > > aliasing in the code. > > - the union aliasing fix for built-in device properties will be sent > > during > > next cycle, though I can share through one of my temporary branches > > if needed > > Sharing that might be helpful in understanding what you're trying to > fix, > right now I'm clueless, sorry. :) https://bitbucket.org/andy-shev/linux/branch/topic/eds-acpi (Last 5 commits WRT the topic) -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
