From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::231; helo=mail-it0-x231.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1C3B62034C5D9 for ; Wed, 22 Nov 2017 11:35:29 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id 187so7700186iti.1 for ; Wed, 22 Nov 2017 11:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0aOQPETTiS37InzgjxhqF4EWpDBYbHMtQhpI/Rq5bx4=; b=MoRCSywvPBq8UPEreo2X4EdtaCZOkliJ7NXrCCzdQ/oF4qfsibYj6x0p+iva5b5S5W 6tA3xvjr+9ifQs65LHVRJIdORnOfUgX+xwNI9+xjGGafs/P9yA7EQ1NRE6+Vd38EupcC OhsmGoerNT919Lp7RxWRc3nZg8VSm7mJaPiCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0aOQPETTiS37InzgjxhqF4EWpDBYbHMtQhpI/Rq5bx4=; b=qEl22/KRHGijE2Gf7ouHnKVdMD8Qzua9CRvZ/q6SsTegYZRh/1H9nyEIIz/URvh5hm pafOw4Jzt4vDIP/GBbcVsyjpo/d2X397qpcPJ2jpbaOFmxFgkqfRtLS843ThU2PACXme TQ4ixswdRKxfl1emwGj9/AR90shBWK2WlHQePdm3Vl3X1n4It5WHAUrIlbI/kZtyKpor QPk9FsUuWTl+oa6EHJmW09hKOKEYh3D0mABMMnL+JPPZMJyvh6oI8Su7UNUU9hS0rBoC lebrUtFO3J4OKEu/WL7a3HLz5g9FIahEh4pXibYBNH6q/iM2WVld3b+UmjPPWLCrt2m0 oARg== X-Gm-Message-State: AJaThX5TuVlxYVI8XRuddi6tcKyEINYw04tW0V/K4iNT87Zi5R71HiHS RXJNNk3PzKcxSpX7huAMOn2rmAT4bE7cxarAIpOfWw== X-Google-Smtp-Source: AGs4zMbs1VOOJHS9EGcoR+fdofxfJHD4BiblFpehtM874+xDgYBwRSBIziCrRMrnl8qTlsba4/beddaegGX/hCBqfGE= X-Received: by 10.36.31.212 with SMTP id d203mr7998140itd.48.1511379585513; Wed, 22 Nov 2017 11:39:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.16 with HTTP; Wed, 22 Nov 2017 11:39:44 -0800 (PST) In-Reply-To: References: From: Ard Biesheuvel Date: Wed, 22 Nov 2017 19:39:44 +0000 Message-ID: To: Daniel Thompson Cc: Udit Kumar , Leif Lindholm , "edk2-devel@lists.01.org" , Varun Sethi , Graeme Gregory Subject: Re: [RFC] ACPI table HID/CID allocation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 19:35:30 -0000 Content-Type: text/plain; charset="UTF-8" On 22 November 2017 at 11:30, Daniel Thompson wrote: > On 21/11/17 18:10, Udit Kumar wrote: >> >> Thanks Ard, >> For internal SOC devices, this is perfectly ok to drop PRP0001 from CID. >> >>> This could be a valid reason to use PRP0001 + compatible, for things like >>> I2C >>> slaves that are external to the SoC >> >> >> For external devices (for which HID is not available), you suggest to go >> with PRP0001 + compatible or that device driver needs add ACPI HID >> support. > > > I don't think internal or external to the SoC would be any kind of deciding > factor in how to best to bind, simply because I don't understand why there > is no HID available. > PRP0001 + compatible was invented to avoid the need to allocate a _HID for each and every component in existence that can already be identified by a DT compatible string (and little else except, e.g., a I2C slave address) and is not deeply engrained in the SoC in terms of clock tree, power states etc. So while internal/external may not be the most accurate distinction, it is still a useful one IMHO.