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::22e; helo=mail-it0-x22e.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 27AFF21B00DC1 for ; Tue, 21 Nov 2017 01:34:04 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id x13so1256830iti.4 for ; Tue, 21 Nov 2017 01:38:20 -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=cG8zwwTf/tNnELM16bmlTAcyPLG9HomEJ/Zu3VV+hOM=; b=hMOHQksCep2XGTNALOO5rq/jEoWtBBMEwFQNMIN45naRn9B3mQRT9QUNia7wogJKpK ibrWytl4jUNDbd9YtPETtXrIfeKfrKmsVb2mgzHpH7SFu4VQ64T9Kz0C+2njBQuQ9Pgj DCYmbkX4fLJXRVoBdMQhMbzjPudZIfSUYXd20= 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=cG8zwwTf/tNnELM16bmlTAcyPLG9HomEJ/Zu3VV+hOM=; b=GYSaBzOs+AU1VKAYI49NYlEjDpnOxFCCtVUZ1IGrnQIcWaGJj4fqPcu3JYbwmlRpGE AwYgJQOut531/lIcAKP1I0NISFUsGSUpHVbVvZL5xQx4MjIbrrmHo7kmfheqcscyC3FE 3n+GD7Fd48bBrldSil53AFUxQsx+DcO0e0ITESbRCh/ewxnQHggZ9/LI4dhu4ICRRqqB kyGVUirL28hvpdWfAbt+Rk8iMgetYVPHETosFmYbNtavxRqpizK+hZU4NZJIwQMVmlkQ 3/QOCQnrrDSTHpJsVk8u8q+68LGIERmxTzkpjja31ZWErEX65PCxuYDM1ldhicUfdXCq L8Kw== X-Gm-Message-State: AJaThX6PLTN+GnjMSxZNQ3pJLSykwM+e5IjeiJ1d/z0r+twBXHu//fhc X2icqTIVShRSlrm0ZYztY7s/7MXsb3/tOHLEHE+PzA== X-Google-Smtp-Source: AGs4zMYPe6rUDxnjUn8tvytaJxnFMp5MT1ohn6EcfVpMFAxCpEt3hJnIKiBCDU+F4NVLqlFNIxgH2HkS2rpMFuS0+QM= X-Received: by 10.36.48.4 with SMTP id q4mr1092443itq.34.1511257099261; Tue, 21 Nov 2017 01:38:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.16 with HTTP; Tue, 21 Nov 2017 01:38:18 -0800 (PST) In-Reply-To: References: From: Ard Biesheuvel Date: Tue, 21 Nov 2017 09:38:18 +0000 Message-ID: To: Udit Kumar Cc: Leif Lindholm , "edk2-devel@lists.01.org" , Varun Sethi , Daniel Thompson , 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: Tue, 21 Nov 2017 09:34:05 -0000 Content-Type: text/plain; charset="UTF-8" On 21 November 2017 at 09:19, Udit Kumar wrote: > Hi, > > I am enabling ACPI on NXP platform , In order to do minimal changes in Linux > driver for device-driver binding. > > I want to use PRP0001 device as CID and HID as actual (NXP allocated HID). > > So that Linux can bind with PRP0001 and compatible field, where as other OS > (Window etc) can rely on HID. > > Below is sample, ACPI table for SPI controller and its slave device. > > > > Hope this approach is ok ? > No, it is not. Architecting an ACPI platform is not a matter of taking a device tree and converting each node into an ACPI device. Linux/DT makes no assumptions about the presence of firmware. This means most device drivers have to manage clocks, regulators etc because they will not be in a known state. Also, the OS can own all devices in the system. Linux/ACPI relies on the firmware to set up clocks and regulators, and uses abstract firmware methods to manage power states etc. Also, due to the dependency on UEFI, things like the RTC and NOR flash are not exposed to the OS via device nodes, but via UEFI runtime services. In a nutshell, the difference between ACPI and DT is that the handoff point between the OS and the firmware is at a different abstraction level. So no, it is not ok to use PRP0001 + compatible for everything. It may be acceptable in some exceptional cases, but you will have to explain why. Everything else should use proper ACPI bindings. -- Ard.