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:c06::230; helo=mail-io0-x230.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 044DD2034711E for ; Tue, 21 Nov 2017 02:09:33 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id q101so18855350ioi.1 for ; Tue, 21 Nov 2017 02:13:48 -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=xhrxeeAIhKoPE9t2qEJnwg6IYjE55vXbQgTgdjBgVdA=; b=FKRPtZQ9Bw6mihWgIN1g/cUrKeom5NJunVFmwo6eKPFtAoc+ki1QGKlNyG0vceAyhQ 0YPwGMDJmQBFJkUiAR1xCPw8HupNQb0EYoAVBwO8hwM/CKFLfu+TtAwyQiKGxItppIcY wi3IVhnE6xQOCxknUCVehaJ+LvfeOOthLnY/M= 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=xhrxeeAIhKoPE9t2qEJnwg6IYjE55vXbQgTgdjBgVdA=; b=t3C+tl5sX/CjFR2y1rCjx+gJQ5AYCovUIb3oXgqKk5DeLxd2PP3MDXwRYXZY/+8TAC VZoz5Zok9n8J/rOTF4z5eNcAtCM8wwK/lHpSPoD1qk5O61uuHHuKhIeeWaczhNEeCz3T Fs+swWwBA0LDcRTWXqmliTryr0xh2Y4nEAeo3vRcT45P0tOonQ2H6NVZ5XkHnuLzMlF3 Rkv0SRN64IlPBp+KrBqmB3lTrlDARiEEmda9+eTzkQM3WXBUQo2Xwxms4TyhIhv4RqZM NSmo394VSQsLSiamulJhc1xRoWcY9JtlctUEJZsP06ggygDaxQJdb8768xPqDdKzvryX UNQQ== X-Gm-Message-State: AJaThX52C4fehrIGLbls0VW+eM1ZF+VbjM6JAoZy/8lHoD/tclrr8Cub U4HjWVFlNcdAHAXHJPwU0BrEOWY4WFzTlDY+YcjlaQ== X-Google-Smtp-Source: AGs4zMY9+pnVXu2D8jXj6ERjcKqAIIh1dE1iucl9avRXFhGxCtUTZsWABGrdfz9AMRyyPiyRn8Jdxx3VzB0/JNDdQBA= X-Received: by 10.107.178.145 with SMTP id b139mr17532873iof.52.1511259228026; Tue, 21 Nov 2017 02:13:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.16 with HTTP; Tue, 21 Nov 2017 02:13:47 -0800 (PST) In-Reply-To: References: From: Ard Biesheuvel Date: Tue, 21 Nov 2017 10:13:47 +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 10:09:34 -0000 Content-Type: text/plain; charset="UTF-8" On 21 November 2017 at 09:59, Udit Kumar wrote: > Thanks Ard. > Below table was for example. I am not converting whole DT to ACPI tables :) > My idea is to reduce Linux patches for probing as possible. > Also keeping firmware and OS separately then > Let firmware expose both way (HID and PRP00001) and Linux to decide binding No. You are still assuming ACPI and DT device drivers bind at the same level, and they don't. An ACPI device has AML methods to manage power state and perform other device related low-level tasks. The device driver has no knowledge of the hardware beyond what it needs to invoke those abstract methods. A DT device describes everything in detail, and requires clock and regulator drivers and other bits and pieces that are tightly coupled to details of the hardware. So now, you have the worst of both worlds: - you need to implement all of this in firmware so ACPI can support it, - you have to expose the internals to the OS so DT can support it. The result is that you lose *all* of the benefits of ACPI, because the power of the abstraction is that you can modify the low-level implementation on the firmware side without the need for modifying the OS. *That* is the value proposition of ACPI, the ability to run last year's OS on this year's hardware. Implementing ACPI in the way you propose is absolutely pointless, sorry to be harsh about it. -- Ard. > Please see inline as well > > Regards > Udit > >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> Sent: Tuesday, November 21, 2017 3:08 PM >> 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 >> >> 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. > > No , no, Here I am not converting everything from DT to ACPI > >> 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. > > Thanks to Linux documentation , I noted this, During hand off ACPI > firmware needs to ensure proper clocking. > >> 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. > > Agreed, RTC and NOR (containing firmware) should not exposed to Linux or OS. > >> 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. > > HID is not going away , I am keeping with PRP0001 + compatible > and let linux driver to decide what to use. > > If PRP0001 + compatible is restricted or meant for limited use > then I can assign HID for NXP devices or say driver managed by NXP. > For other vendors, will this be accepted to have HID something like NXP00xx ?? > >> -- >> Ard.