-
Andy Shevchenko authored
Commit 318a1971 (device property: refactor built-in properties support) went way too far and brought a union aliasing. Partially revert it here to get rid of union aliasing. Note, all Apple properties are considered as u8 arrays. To get a value of any of them the caller must use device_property_read_u8_array(). What's union aliasing? ~~~~~~~~~~~~~~~~~~~~~~ The C99 standard in section 6.2.5 paragraph 20 defines union type as "an overlapping nonempty set of member objects". It also states in section 6.7.2.1 paragraph 14 that "the value of at most one of the members can be stored in a union object at any time'. Union aliasing is a type punning mechanism using union members to store as one type and read back as another. Why it's not good? ~~~~~~~~~~~~~~~~~~ Section 6.2.6.1 paragraph 6 says that a union object may not be a trap representation, although its member objects may be. Meanwhile annex J.1 says that "the value of a union member other than the last one stored into" is unspecified [removed in C11]. In TC3, a footnote is added which specifies that accessing a member of a union other than the last one stored causes "the object representation" to be re-interpreted in the new type and specifically refers to this as "type punning". This conflicts to some degree with Annex J.1. While it's working in Linux with GCC, the use of union members to do type punning is not clear area in the C standard and might lead to unspecified behaviour. More information is available in this [1] blog post. [1]: https://davmac.wordpress.com/2010/02/26/c99-revisited/Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
63dcc709