From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Stone Subject: Re: [RFC 00/15] ACPI graph support Date: Thu, 6 Oct 2016 14:54:12 -0600 Message-ID: <45366ada-5e91-c822-4176-9e46252a8707@redhat.com> References: <1475621148-21427-1-git-send-email-sakari.ailus@linux.intel.com> <20161005092215.GA20248@red-moon> <20161005114129.GI1765@lahna.fi.intel.com> <788f4bcd-605f-2694-5df5-ec7ef1bde233@arm.com> <0e56c5b2-0042-28e5-7445-6fe8422c728e@arm.com> <8999b937-4c06-6d82-aef5-6b7700a2a10c@arm.com> <590ed0a0-544d-a320-e6e0-ce1ab89d485e@redhat.com> <20161006201422.q566ckb4qzbbt7s2@sirena.org.uk> Reply-To: ahs3@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-it0-f48.google.com ([209.85.214.48]:37949 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933429AbcJFUzM (ORCPT ); Thu, 6 Oct 2016 16:55:12 -0400 Received: by mail-it0-f48.google.com with SMTP id o19so41905278ito.1 for ; Thu, 06 Oct 2016 13:54:14 -0700 (PDT) In-Reply-To: <20161006201422.q566ckb4qzbbt7s2@sirena.org.uk> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Mark Brown Cc: Sudeep Holla , "Rafael J. Wysocki" , Mika Westerberg , Lorenzo Pieralisi , Sakari Ailus , ACPI Devel Maling List , Mark Rutland , Rob Herring On 10/06/2016 02:14 PM, Mark Brown wrote: > On Thu, Oct 06, 2016 at 11:20:49AM -0600, Al Stone wrote: > >> So where does this leave us? What I take away from the discussion is >> this: > >> a) each use of _DSD device properties in the kernel is to be evaluated on >> a case-by-case basis. Therefore, Rafael and/or driver maintainers have >> the final say on acceptance in the Linux kernel. > > Are we talking about pure _DSD here or are we not talking about something > definitely ACPI specific? I was under the impression from the thread title > that there's something involving inter-node links going on here since I > thought it wasn't possible to represent that in _DSD alone. I might be > missing something here, I was copied in part way through the thread. My intent was pure _DSD. I have to wonder if inter-node links shouldn't be handled more directly in ASL; that may be harder than using device properties, but it might be the right long term solution. >> e) Windows and Linux are already diverging in their use of _DSD. > > I'm concerned we're seeing this outside of just _DSD. Well, since I have not been appointed Emperor, I'm not sure it can be prevented. >> If I didn't, then it seems a mechanism external to the Linux kernel to >> document device properties is completely redundant, especially given item >> (e) -- they will either be documented in DT, or documented by the driver. >> And if that's the case, then the dsd@acpica.org mailing list is >> irrelevant, or what's worse, makes for duplicated work, and should just >> go away. > >> I'm fine with that, if that's what we're saying (it's less for me to do >> :), but let's say it explicitly instead of re-hashing it every time _DSD >> is used. The above list is nice and simple and personally I'd rather >> have simple than a full blown registration process. > > Like I've said before having some effort to try to pull the ACPI community > together so they're talking to each other and trying to come up with best > practices seems like a good idea. > I agree it seems like a good idea. As a practical matter, however, if it is just going to be ignored, there's no real point, is there? That also begs the question, though: if the idea is to re-use DT bindings as is, why not just use DT directly and not bother with ACPI? Wouldn't that be easier on everyone? If arm64 can use ACPI *or* DT, surely any other architecture can. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com -----------------------------------