On Wed, 2018-02-28 at 19:14 +0100, Lukas Wunner wrote: > On Wed, Feb 28, 2018 at 07:25:59PM +0200, Andy Shevchenko wrote: > > Instead of mapping to built-in device properties, implement a full > > property provider. > > > > This is needed due to an architectural differences between built-in > > device property data structures and ones that are used on Apple > > machines. > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > > --- > > > > Hi, Lukas. > > > > This is a skeleton of proof-of-concept conversion of apple- > > properties to > > be a full featured property provider. > > I'm struggling to understand what the problem is with the existing > code > that necessitates these changes. In a prior e-mail there was the > question what type these Mac EFI properties have and I said it's just > a raw byte array. Thus, always assuming an array of type DEV_PROP_U8 > would seem to be sufficient. That's also the type I used to retrieve > the "ThunderboltDROM" property in drivers/thunderbolt/eeprom.c. > Would that not work? (Sorry if I'm sounding really ignorant.) If you go to include/linux/property.h and do s/union/struct/g (for struct property_entry definition) It will simple not work. That's called "union aliasing" (google it) and must be avoided. Moreover, Apple properties does NOT have a type of value, thus they can NOT use struct property_entry. You must had not used it in the first place, but this is my mistake. Now it's a time to do right things right. -- 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
