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::243; helo=mail-it0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 0C56921B00DC4 for ; Tue, 21 Nov 2017 04:25:00 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id n134so1788234itg.3 for ; Tue, 21 Nov 2017 04:29:16 -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=zMHJkMB4+nv/DWs0GKJRaZ9C2cAwvsa/qBKrVtfUiJU=; b=ciVFATCQGyhzzOJGTYt4VYiPXIYcA9TZ4cvdseRIPQrdZqdu3vkY2lng24QY+cHdaC aWuznCjvdX0uoXzC7J43m8E9nWfZvcI62d4q9TqddyLU1yA4BbVQdLXWQ817t6PA2AcA 4EGjdjWQKylrqGscMA+khI33jzw7VTSUgPtSM= 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=zMHJkMB4+nv/DWs0GKJRaZ9C2cAwvsa/qBKrVtfUiJU=; b=K620gpegfLxI/ExYWz/lJ74H2Y2zolZpTGnO1WOGFqD1+DvTn6XrBDUwQc1vYoS3ts wdQO8WXVbJ3n3E1UOhDeJa0n2KXUHplW/8e6F3sEDCvzn1DWD+Isx0YSzXfj1t5z6SS1 DEhysS/vbbAhOi+sRqWT/JxHa8Pjjf2mjZY4HwIMJ/UFH7YvOrc2f8x2Vi327tJrl4hJ lY0yXHfTiwmXL1QzDL8JMfBKm+m60+6nUXVCELOUSc4VevKfG33viwmrnYGegxKF2w1f cjuMPlwj3P9pW/EA8S8njRkKqArRsA/dze5Udd95VZcx72wiaP0nIpiTLTZnzVA9vi0z FPrA== X-Gm-Message-State: AJaThX7suTXabr+d/qZY4JKcm39LtAFxaI2SNGpbAO4xZKIW/oclnd72 8Rl7DRfnMWK2FwfIGfeYWhb8ZI4XAoRtIDKIIDdoVw== X-Google-Smtp-Source: AGs4zMYTEMnhqxeNTkezgb1AZQMgSaiiJpqyaMojCtPPUoS29bDrg9uzuf2iwApJQKwKOlslyI7wv4PVOUPRpEcMzwQ= X-Received: by 10.36.31.80 with SMTP id d77mr1585657itd.65.1511267355306; Tue, 21 Nov 2017 04:29:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.16 with HTTP; Tue, 21 Nov 2017 04:29:14 -0800 (PST) In-Reply-To: References: From: Ard Biesheuvel Date: Tue, 21 Nov 2017 12:29:14 +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 12:25:01 -0000 Content-Type: text/plain; charset="UTF-8" On 21 November 2017 at 11:32, Udit Kumar wrote: > >> 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. > > No, my above comments was just limited to binding. Yes, but if you leave it to the OS to decide which binding it uses, you will have to support all of them into eternity. And the more detailed binding you need to support may limit you in the available choices when it comes to making hardware changes, something ACPI allows you to do. > Right, here device driver should know that device is present in system, > I see probe function (device-driver binding) is way to know this. > Then driver can execute AML methods exposed by firmware. > Yes, declaring the presence of the device is the main purpose of describing it both in ACPI and in DT. >> 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. > > You meant, If we need to update driver for AML methods then why not to update binding as well . ? > No. What I am saying is that you should not expose two different bindings, and let the OS choose. > On side track, > With limited search, I got many each driver is having (acpi_id and of_id), > looks, acpi support is added on the top of DT flavored drivers. > and therefore acpi tables are following the same. > Sorry to say, reference I am looking at (edk2-platform) JunoPkg and VExpressPkg, > Has following devices has description similar to Device tree > Device (NET0) { > Device (SREG) { > Device (VIRT) { These were taken from the ACPI tables for an emulator > Device(KMI0) { I have no clue what kind of device this is > Device(ETH0) { This one uses _DSD as intended, to set device properties in a DT compatible fashion, but note that this does *not* include the 'compatible' property, nor anything else that ACPI defines itself (status, dma-coherent, etc) > Where no AML method is exposed. Then I expect OS driver to manage this device. > While grepping over few other edk2-platforms. Looks some of methods > are abstracted, not whole device. > So what is your point? Why does this argue in favor of allowing PRP0001 + compatible? >> 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. > > Yes, for time being or may be longer, DT support needs to be there > along with ACPI introduction. > > Are you suggesting here to abstract whole device details from > OS and expose AML methods to be used by device driver. > And maintain two drivers instead of fitting DT style driver into ACPI world ? > No. You should update the driver so it can support both ACPI and DT bindings. That way, the driver can use the abstractions offered by ACPI when it can, and can invoke the clock and regulator frameworks and other low level infrastructure only when it needs to. Let me try to illustrate this a bit better: imagine a NXP customer that runs a datacenter that has 10,000 NXP servers, and is using RHEL x.y. The business is going well, and at some point, he wants to order another 2,000 servers. Unfortunately, the vendor cannot supply the exact same revision of the hardware, and the latest revision uses some component that is not supported in RHEL x.y. You now have made your customer very unhappy. He invested in RHEL and ACPI based servers precisely to avoid this situation. The cost of adding 2,000 servers now includes the cost of upgrading the other 10,000 servers to a new OS version or the cost of supporting two different OS versions at the same time, for a reason that is not justifiable.