Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp5069224ybb; Tue, 24 Mar 2020 10:22:45 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtkrX9wk4wrFWcdURI2x5fycxuybhkDmZoeZXzqcaUnuWZPcL4IB4yK9O49hMpEjSxL99PW X-Received: by 2002:a05:6830:22c3:: with SMTP id q3mr22008695otc.212.1585070565756; Tue, 24 Mar 2020 10:22:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585070565; cv=none; d=google.com; s=arc-20160816; b=V7SjKwjwhNsXw9Gwyt7r5RuN3XfyBlKYhE65r81uB0ky1SGRcgeYApv3G7megVwiLB bSqw2+iGJeLi2/2Zon76nhuYe7szp9X1aFaThobiNumCV45sIE/CZukEhuIvsXiwjh2I deVSfHjx4t3c1SXfgvNWuAQK2FJoyBBdzwVvg/cGwCkFqZdscuaaWkmEXaORF1TxfQ38 Nzyfrfa2qeU/jWbSlmHwoOYuyroLHQaaGUTIp/oW1g1moiokE2s7hUGBlh8EhqeBW0rX N6/i5KeYokrtIcKiV2PkRv1VCJrorv96Al9qe23/t/ExR7hsQJ4KhL5DmUf/IsS3bup4 murQ== 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 :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:ironport-sdr:ironport-sdr; bh=9FaWqUN5+yByWZ5FJ8RHf6GK5e/mmH+miGMAJ2LQTjs=; b=aZp2frQVcB0DZx7fPeKPNK/VgODXySLKMgy1H3fiCu/ah+1k1L/vJCkU3h6z0XebDT oo1zJLPN5TFr2GGzSPFWus6bu/ia+ollj7wykG+P5In5akLIYzOlFXe/We/X7Ii/UgAS 9+9Q7vcTv+Jkzx6DKKT19Qxw8p+y3gXUwmzmi9ss7JsoyxCtcuHHQRCGI24Gq909DPsa idWOCkIzstbzkCzN5UJifrekvLhd8Z+R6cyl3aNHBdxBG6C58dh1B8B1G17dBe2PPWBP oK19mYH5a/cijsYZYE35TzDfVSi6QUYck4oAG87jRiW0JinUGjp9ttvd0T+WwRv80rmq 6B5w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v22si9089099oic.271.2020.03.24.10.22.32; Tue, 24 Mar 2020 10:22:45 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727577AbgCXRUv (ORCPT + 99 others); Tue, 24 Mar 2020 13:20:51 -0400 Received: from mga09.intel.com ([134.134.136.24]:5971 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727267AbgCXRUv (ORCPT ); Tue, 24 Mar 2020 13:20:51 -0400 IronPort-SDR: 4PdgFIVF14SSYOq2jw8ZVHBL2PMalwtc1OEJdKFiVa12mkIdEz8R3eFd5X6GKaYnJ6zeb0qmtK RkENSUZ6F3Cw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2020 10:20:44 -0700 IronPort-SDR: lTjJf7kd7Sdj3CbIltbwAxnUjZtH9FR8UIVGjLYmRCoQtJeTsFicEUboNADGq60Zmx3pxl3usE EzRwB6WgmhEw== X-IronPort-AV: E=Sophos;i="5.72,301,1580803200"; d="scan'208";a="240333667" Received: from spandruv-mobl.amr.corp.intel.com ([10.134.90.138]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2020 10:20:42 -0700 Message-ID: <3166e472e0ef5c0db8da3ab7d846b47795e69057.camel@linux.intel.com> Subject: Re: [PATCH v2] platform: x86: Add ACPI driver for ChromeOS From: Srinivas Pandruvada To: Enric Balletbo i Serra , Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, vbendeb@chromium.org, groeck@chromium.org, bleung@chromium.org, dtor@chromium.org, gwendal@chromium.org, andy@infradead.org, Collabora Kernel ML , Ayman Bagabas , Darren Hart , Dmitry Torokhov , Jeremy Soller , Mattias Jacobsson <2pi@mok.nu>, Mauro Carvalho Chehab , Rajat Jain , Yauhen Kharuzhy , platform-driver-x86@vger.kernel.org Date: Tue, 24 Mar 2020 10:20:41 -0700 In-Reply-To: <3444110c-d6c0-16df-9b5d-12578ed442c5@collabora.com> References: <20200322094334.1872663-1-enric.balletbo@collabora.com> <20200322111022.GA72939@kroah.com> <20200324164956.GE2518746@kroah.com> <3444110c-d6c0-16df-9b5d-12578ed442c5@collabora.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-03-24 at 18:08 +0100, Enric Balletbo i Serra wrote: > Hi Greg, > > On 24/3/20 17:49, Greg Kroah-Hartman wrote: > > On Tue, Mar 24, 2020 at 05:31:10PM +0100, Enric Balletbo i Serra > > wrote: > > > Hi Greg, > > > > > > Many thanks for your quick answer, some comments below. > > > [...] > > Are you sure they aren't already there under > > /sys/firmware/acpi/? I > > thought all tables and methods were exported there with no need to > > do > > anything special. > > > > That's the first I did when I started to forward port this patch from > chromeos > kernel to mainline. > > On my system I get: > > /sys/firmware/acpi/tables# > APIC DSDT FACP FACS HPET MCFG SSDT data dynamic > > (data and dynamic are empty directories) > > I quickly concluded (maybe wrong) that as there is no a MLST entry it > was not > exported, but maybe one of those already contains the info? Or, > should I expect > a MLST entry here? > If the data you are reading doesn't depend on any runtime variable in ACPI tables then you can read from firmware tables as is. You can download acpica tools and run your method on acpi dump using acpiexec tool. Once you can take dump, you can run on any Linux system. If you can get what you need from running on the dump, then you can do by directly reading from /sys/firmware/acpi/tables/ from user space without kernel change. Sometimes it is enough as lots of config data tend to be static. Thanks, Srinivas > > What makes these attributes "special" from any other ACPI method? > > > > I can't answer this question right now. I need to investigate more I > guess ;-) > > Thanks again for your answer, > Enric > > > > > > +static int __init chromeos_acpi_init(void) > > > > > +{ > > > > > + int ret; > > > > > + > > > > > + chromeos_acpi.pdev = > > > > > platform_device_register_simple("chromeos_acpi", > > > > > + PLATFORM_DEVID_ > > > > > NONE, NULL, 0); > > > > > + if (IS_ERR(chromeos_acpi.pdev)) { > > > > > + pr_err("unable to register chromeos_acpi > > > > > platform device\n"); > > > > > + return PTR_ERR(chromeos_acpi.pdev); > > > > > + } > > > > > > > > Only use platform devices and drivers for things that are > > > > actually > > > > platform devices and drivers. That's not what this is, it is > > > > an ACPI > > > > device and driver. Don't abuse the platform interface please. > > > > > > > > > > Ok. The purpose was to not break ChromeOS userspace since is > > > looking for the > > > attributes inside /sys/devices/platform/chromeos_acpi. Not a good > > > reason, I > > > know, and I assume we will need to change userspace instead, and > > > convert this to > > > a ACPI device and driver only, right? > > > > How can any userspace be looking for anything that hasn't been > > submitted > > before? That's nothing to worry about, we don't have to support > > things > > like that :) > > > > > I'll investigate the different places in userspace where this is > > > used and see > > > how difficult it is to do the changes. > > > > Look at /sys/firmware/acpi/ first please. > > > > thanks, > > > > greg k-h > >