Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp575279pxv; Wed, 14 Jul 2021 10:19:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxlJPxwBr+vdVwOUrsEiBAE1izNaQRdDW9B/3bTk1+R+ERK0MM19hhMTbeTBTDQunwR2FLd X-Received: by 2002:a17:907:62a1:: with SMTP id nd33mr13251516ejc.303.1626283189018; Wed, 14 Jul 2021 10:19:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626283188; cv=none; d=google.com; s=arc-20160816; b=qET2aT6BxqqxvCy9NWtvXXFAMCUvFQ12szy8zflwkU+3mADXUQYtzAM+jL6bHqPmNr BGPEIGp4hirjbyTu/MxzH7jl5knhgt8fqopILzaGIpSJhYvJ5kuid5mKMmfX/EcdVBU/ YWnslXX3Z8U/ien7y4sMqSA2NnjXUJpgDPB5zrwAtFxomsMsPMVLYzKZKkilAUIusI7r qOeiSofDyA0yshvFy8gYOpjajJ5qcfPJXQg8nFI9ac9HXaV/RtXD7ufgT8tHrKwHg3rI IASW7PzXzADCim44lcyfHXXpZsuwU8D6UQPGg9/y3zYJlmAQySr7miY48416ztMwjkFO WdMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/897xD7m/8VVZ5GUfQK12gVnx/mcrfygyHeLfSqksnA=; b=rCX6r9zdsKz7NVtmEnjgVVCUqUBfHZd1absEoeI38tA4pdKoYvlua3jbYoW+1G4YtW 3vOU/NaJgDFUMwaYEJ8oBeBt9a3Pd5i2WJcZ4CEx/FILWdZsyMcP6cbxZay8N/t8Z3wg MrSPYpov7NbJtdJnjEud9K5Nmz4i7sFbcqjQQGj7eZBLf3tCBT9dwFWyjobYrJkbVhqx g8rknNqybsMFtyCyHOtkku0Q4E939KmuydSNC+/z47CBu1053voxqci0k27s6yG8zjq2 yObyd6IYjbXXu/1fGcZw9FjXawSzbc3UhikHn5nu9arvIagocBH2QE9BzibG3xLeVrCr duHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=go82Ez75; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gw26si3169622ejb.161.2021.07.14.10.19.24; Wed, 14 Jul 2021 10:19:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=go82Ez75; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237314AbhGNRVI (ORCPT + 99 others); Wed, 14 Jul 2021 13:21:08 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:56190 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229669AbhGNRVI (ORCPT ); Wed, 14 Jul 2021 13:21:08 -0400 Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id D3FC8CC; Wed, 14 Jul 2021 19:18:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1626283095; bh=ZGkMV8sDWIogo+fVef+xYu8TVBeuYIR2zPF/V59CSjI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=go82Ez756GWFpyWT00c5spMYfJOmtnUfukPm4ZLdDiKOvOnpm9Tkop0iNqrgxZHJU KBHONmJDj9W+P2wc5QKBEkBNerVZbZl3G0+qYnjAHobS73E9aGNqnPudvN9o+uNC1L k300l/44mowdcYgFdBpaUmngm5cSlVsjod6gWZpI= Date: Wed, 14 Jul 2021 20:18:13 +0300 From: Laurent Pinchart To: Mark Brown Cc: Andy Shevchenko , Daniel Scally , Linux Kernel Mailing List , Platform Driver , Hans de Goede , Mark Gross , Maximilian Luz , Liam Girdwood , kieran.bingham@ideasonboard.com Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework Message-ID: References: <20210712133428.GD4435@sirena.org.uk> <20210712170120.GG4435@sirena.org.uk> <20210713152454.GC4098@sirena.org.uk> <20210713181837.GE4098@sirena.org.uk> <20210714165948.GG4719@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210714165948.GG4719@sirena.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 14, 2021 at 05:59:48PM +0100, Mark Brown wrote: > On Wed, Jul 14, 2021 at 10:25:02AM +0300, Laurent Pinchart wrote: > > On Tue, Jul 13, 2021 at 07:18:37PM +0100, Mark Brown wrote: > > > > Like I said in the other mail fwnode is a nice hack for systems that are > > > using ACPI but have hardware that's doing something totally outside the > > > ACPI model to allow them to reuse work that's been done for DT, it's not > > > a universal solution to the lack of appropriate support for describing > > > modern systems in ACPI. > > > fwnode, as an abstraction of ACPI and OF, is quite useful for camera > > sensor drivers for instance. They need to read firmware properties (for > > instance to identify whether a camera is located on the front or back of > > the device, or to what port of the SoC it's connected), and being able > > to do so without duplicating OF and ACPI code in drivers is useful. > > I'd still say that's a bit of a hack, it's the sort of area where ACPI > just has absolutely no handling at all and so picking up the DT bindings > will work effectively although it results in something that's really not > at all idiomatic for ACPI since idiomatic DT and idiomatic ACPI don't > really look like each other and AIUI this stuff isn't getting adopted > for actual firmware (as opposed to swnodes) outside of the embedded x86 > space. It's only one data point, but we're seeing adoption of the ACPI DT-in-DSD for camera. It's still not pretty of course. > > swnode, on the other hand, is indeed more of a workaround for a > > more-often-than-not broken ACPI implementation. It's ironic to think > > that x86 ACPI-based systems, touted as being superior to ARM, are now in > > a worst state than OF-based systems. > > The unfortunate thing is that ACPI is super limited in what systems it > models, making assumptions that only really work for fairly simple > server class systems. Outside of that the models it's offering just > can't cope with actual hardware yet people still insist on building > those systems with ACPI system descriptions so you end up with huge > piles of platform quirks. Audio support for modern x86 laptops is just > an endless procession of quirks :( I feel your pain. On the camera side, we have a case of an I2C controller that has a PCI driver in the kernel used when dealing with the camera sensor, and an AML "driver" used by an I2C GPIO expander, completely modelled in the DSDT. Both poke the same PCI registers of the I2C controller. I tried to get information from Intel on how this was meant to be handled, but I think the people responsible for the design have been exfiltrated to Guantanamo, or are expiating their sins in a monastery lost in a mountain. Once travel will be easier again, we'll plot a take over of the world in a bar. Dealing with ACPI requires lots of whisky :-) -- Regards, Laurent Pinchart