On Tue, Apr 30, 2019 at 8:23 PM Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote: > > > > On 4/16/19 3:09 AM, Rafael J. Wysocki wrote: > > On Tue, Apr 16, 2019 at 5:29 AM Vinod Koul <vkoul@xxxxxxxxxx> wrote: > >> > >> On 15-04-19, 10:18, Pierre-Louis Bossart wrote: > >>> Standards such as the MIPI DisCo for SoundWire 1.0 specification > >>> assume the _ADR field is 64 bits. > >>> > >>> _ADR is defined as an "Integer" represented as 64 bits since ACPI 2.0 > >>> released in 2002. The low levels already use _ADR as 64 bits, e.g. in > >>> struct acpi_device_info. > >>> > >>> This patch bumps the representation used for sysfs to 64 bits. > >>> > >>> Example with a SoundWire device, the results show the complete > >>> vendorID and linkID which were omitted before: > >>> > >>> Before: > >>> $ more /sys/bus/acpi/devices/device\:38/adr > >>> 0x5d070000 > >>> After: > >>> $ more /sys/bus/acpi/devices/device\:38/adr > >>> 0x000010025d070000 > >> > >> This looks fine but the sysfs file is an ABI. Not sure if we can modify > >> the value returned this way.. Though it should not cause userspace > >> reading 32bits to break... > > > > Well, IIRC using "08" instead of "016" in the format field would > > preserve the existing behavior for 32-bit values, wouldn't it? > > yes, but it makes the 64-bit address not aligned depending on the number > of leading zeroes, see below. I get a migraine just looking at the results. Well, scripts reading them won't get that, but fair enough. > Maybe add a test to use 08 for values that are below 0xFFFFFFFF and 16 > for addresses who really need the full range, typically because of an > encoding? That would be fine by me. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
