| Message ID | 20190415151857.25531-1-pierre-louis.bossart@linux.intel.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | ACPI / device_sysfs: change _ADR representation to 64 bits | expand |
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... > > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > --- > drivers/acpi/device_sysfs.c | 3 +-- > include/acpi/acpi_bus.h | 2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c > index 8940054d6250..f8d73ae42529 100644 > --- a/drivers/acpi/device_sysfs.c > +++ b/drivers/acpi/device_sysfs.c > @@ -428,8 +428,7 @@ static ssize_t acpi_device_adr_show(struct device *dev, > { > struct acpi_device *acpi_dev = to_acpi_device(dev); > > - return sprintf(buf, "0x%08x\n", > - (unsigned int)(acpi_dev->pnp.bus_address)); > + return sprintf(buf, "0x%016llx\n", acpi_dev->pnp.bus_address); > } > static DEVICE_ATTR(adr, 0444, acpi_device_adr_show, NULL); > > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h > index f7981751ac77..9075e28ea60a 100644 > --- a/include/acpi/acpi_bus.h > +++ b/include/acpi/acpi_bus.h > @@ -230,7 +230,7 @@ struct acpi_device_dir { > /* Plug and Play */ > > typedef char acpi_bus_id[8]; > -typedef unsigned long acpi_bus_address; > +typedef u64 acpi_bus_address; > typedef char acpi_device_name[40]; > typedef char acpi_device_class[20]; > > -- > 2.17.1
On Tue, Apr 16, 2019 at 5:29 AM Vinod Koul <vkoul@kernel.org> 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?
On 16-04-19, 10:09, Rafael J. Wysocki wrote: > On Tue, Apr 16, 2019 at 5:29 AM Vinod Koul <vkoul@kernel.org> 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? Yeah that should do :)
On 4/16/19 3:09 AM, Rafael J. Wysocki wrote: > On Tue, Apr 16, 2019 at 5:29 AM Vinod Koul <vkoul@kernel.org> 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. 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? w/ value-dependent format: /sys/bus/acpi/devices# cat */*/adr 0x00160000 0x00140003 0x000d0000 0x000d0002 0x000d0003 0x00070000 0x00070001 0x00070002 0x00070003 0x000010025d070100 0x000110025d070100 0x000210025d070100 0x000310025d070100 0x000010025d070000 0x000110025d070000 0x000210025d070000 0x000310025d070000 0x00000000 w/ 0x08 only: 0x00160000 0x00140003 0x000d0000 0x000d0002 0x000d0003 0x00070000 0x00070001 0x00070002 0x00070003 0x10025d070100 0x110025d070100 0x210025d070100 0x310025d070100 0x10025d070000 0x110025d070000 0x210025d070000 0x310025d070000 0x00000000 0x00000000
On Tue, Apr 30, 2019 at 8:23 PM Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote: > > > > On 4/16/19 3:09 AM, Rafael J. Wysocki wrote: > > On Tue, Apr 16, 2019 at 5:29 AM Vinod Koul <vkoul@kernel.org> 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.
diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c index 8940054d6250..f8d73ae42529 100644 --- a/drivers/acpi/device_sysfs.c +++ b/drivers/acpi/device_sysfs.c @@ -428,8 +428,7 @@ static ssize_t acpi_device_adr_show(struct device *dev, { struct acpi_device *acpi_dev = to_acpi_device(dev); - return sprintf(buf, "0x%08x\n", - (unsigned int)(acpi_dev->pnp.bus_address)); + return sprintf(buf, "0x%016llx\n", acpi_dev->pnp.bus_address); } static DEVICE_ATTR(adr, 0444, acpi_device_adr_show, NULL); diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index f7981751ac77..9075e28ea60a 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -230,7 +230,7 @@ struct acpi_device_dir { /* Plug and Play */ typedef char acpi_bus_id[8]; -typedef unsigned long acpi_bus_address; +typedef u64 acpi_bus_address; typedef char acpi_device_name[40]; typedef char acpi_device_class[20];
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 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> --- drivers/acpi/device_sysfs.c | 3 +-- include/acpi/acpi_bus.h | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-)