Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6826313yba; Tue, 14 May 2019 14:31:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqxQE38Q8cJmajotd3hP+1WkNpZEaSv95thik0ONtyG8P1yurHTZ9jojciTMvyfjISWjWaDh X-Received: by 2002:a63:6fcf:: with SMTP id k198mr39814347pgc.158.1557869510160; Tue, 14 May 2019 14:31:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557869510; cv=none; d=google.com; s=arc-20160816; b=az65LpsO/NEwTyFxmFV9C5RYveJwVpuyuc/ZwAIi1O1EKFyFjTU+OVVGSo5jk+0FpA 4Z+po+0U2OKLNR/5pYaHr5HoLZueJIpZGlLyNoszb5xhOabcCS83IgIvvIVpbxt6FtdA CSCA24YaYj/liYOvO5/3u0bNO4A1VFnKOEFguDbj2Nbh/Aevz4H5iyL55/i2VTAdAjHe kcl7IbVgBQppziUNe0yyQUa+B8oQHIW2K3qGwLFu77AYWWxZpPoeQ7nJId9OVBeq+1nH bmqiklRRHShZ+Jn+KSAk1Tk74lCWQPJu8lGugcK7JSqLEFsXBKOdZfDFa+H81a0B9dmL 4mdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=rrSJOtyWWFWrGyb+Ln712R8KB23QXYsUdJ/SCIR4B78=; b=qIBT5Ztm4TxQHYvl2gPOaGkA8WtmHl00uJnGQZc1buFCbkDahvw6YX2VZWCXSkjUY2 2BjTAl7PLPo+q6MbvLASPAb/+Hq4KA3rzG+WY8ta+mKEWvu825IzYBL+uw4mTi29ZTjK +glPNMFLE980Hz7cjyZ9+wQUgCxtnj9S6O/Kj7kZNPNGYcd4AaCwN9r0hWO8S49RDtHU 9HjdZ4TOldxBPC57gtylmyKJSCR5BsjRdqOJ62MNewY03AfmhX0mjLKr1DXRyAX8ccQS E3lBy66gUHmddvb2VvL81pZQS19X5cTQDrX3p0Qk4fxxtEIO/nvQ5fJppHcg1mk2uO6G w/DQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k71si21543949pgd.530.2019.05.14.14.31.34; Tue, 14 May 2019 14:31:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726622AbfENV3W (ORCPT + 99 others); Tue, 14 May 2019 17:29:22 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:42388 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726089AbfENV3V (ORCPT ); Tue, 14 May 2019 17:29:21 -0400 Received: from 79.184.255.148.ipv4.supernova.orange.pl (79.184.255.148) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.213) id bc0f4377005ba3a1; Tue, 14 May 2019 23:29:19 +0200 From: "Rafael J. Wysocki" To: Pierre-Louis Bossart Cc: Vinod Koul , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , Linux Kernel Mailing List , Takashi Iwai , Mark Brown , Greg Kroah-Hartman , Liam Girdwood , jank@cadence.com, Joe Perches , Srini Kandagatla , Len Brown , Robert Moore , Erik Schmauss , "open list:ACPI" , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" Subject: Re: [PATCH v2] ACPI / device_sysfs: change _ADR representation to 64 bits Date: Tue, 14 May 2019 23:29:18 +0200 Message-ID: <1683867.ro8ObbCUgW@kreacher> In-Reply-To: References: <20190501125322.23791-1-pierre-louis.bossart@linux.intel.com> <20190502045817.GZ3845@vkoul-mobl.Dlink> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, May 6, 2019 10:36:22 AM CEST Rafael J. Wysocki wrote: > On Thu, May 2, 2019 at 6:58 AM Vinod Koul wrote: > > > > On 01-05-19, 07:53, 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. To > > > avoid any compatibility/ABI issues, the printf format is only extended > > > to 16 characters when the actual _ADR value exceeds the 32 bit > > > maximum. > > > > > > 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 > > > --- > > > v2: only use 64 bits when required to avoid compatibility issues > > > (feedback from Vinod and Rafael) > > > > > > drivers/acpi/device_sysfs.c | 6 ++++-- > > > include/acpi/acpi_bus.h | 2 +- > > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c > > > index 8940054d6250..7dda0ee05cd1 100644 > > > --- a/drivers/acpi/device_sysfs.c > > > +++ b/drivers/acpi/device_sysfs.c > > > @@ -428,8 +428,10 @@ 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)); > > > + if (acpi_dev->pnp.bus_address > 0xFFFFFFFF) > > > > Would prefer to use U32_MAX instead of 0xFFFFFFFF > > I would. > I have made that change manually and applied the patch. Thanks!