Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2882842pxk; Mon, 28 Sep 2020 02:39:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznoxeVqFKfQZyimLdiIFq6UgVBgqioWIj5b1cyEu0CUf0hsa/1ECckobR1LgTW8CkJHrCd X-Received: by 2002:a17:906:88d:: with SMTP id n13mr799068eje.75.1601285977147; Mon, 28 Sep 2020 02:39:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601285977; cv=none; d=google.com; s=arc-20160816; b=IIb2heqWQ19TM77vxgS3/mmH61vu9ihFihsrnZqJZD9V0fmJM88ww66Wed6X5K6RKx uZ7I8JdqopbGHuPiZHP9wrvB+g65YzXNaC+qcL+fG8aFa3zOzdZS/xag10W1YAGUqKfO PdGPE0Pi4NpLU8fGLprWlmHcH5HzTOrGDG/zdqkzUtxt1kuopj46+wU28R8uSPskDJKv vWCkgCtGEfEcJMOKD383yXNdsfGlM/+ykgVmHRQ0pBlvhUIOcwxuJNAb8GLhiw2CGHSM yzpzQrpxoPTxOafBJ9eSDxuEqG92OlXXGK4ecZ/fuWIKm6kYnK2t4Z4Mm0MPbly0mf8j JwCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=w9RCIYBAEXRFCzwwBcLBG1nDeKntJ+qgNVsD3MJQibk=; b=P3XDASBhh0x6wPPiw9AC40i8KH9Za6Rbb35cnq4wb1KKeH3Q4EK6AIutqFm/9e0jeo XWh79EkYkoT7OchYdspIv1mTVE/SVacrjZWwqn9e9IlhddLPBTxZE3gNndqdWKMqLsfL EK6MMREQtg+B9sBF5wEoPdMrRWHxwZjFU8Sn5mIPUBoWzhqR1HYCvO1tdD/hnBY36JFD 9sYVFjplxv6zySzIJzPtvDGFzozzLEq3TMLv0GeGOUxGhbogvDbh6vvbX6QaCqkMzf4P 7PBT74GgVLjL2v0JKjg/xcSNdhKS7BnaIQs/c8wnougHfUIBwPkMHPMpTOFcb4+Jm4Qr M85g== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k13si202598edh.371.2020.09.28.02.39.14; Mon, 28 Sep 2020 02:39:37 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726681AbgI1Jhr (ORCPT + 99 others); Mon, 28 Sep 2020 05:37:47 -0400 Received: from mga07.intel.com ([134.134.136.100]:57449 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726573AbgI1Jhq (ORCPT ); Mon, 28 Sep 2020 05:37:46 -0400 IronPort-SDR: RzH+KJLeFLsHzISHZ8XxRJrO+YuhijVXafDEa6n2HbJ7ziecep3xqJYvX2oIo/fxm13xXJ/xNH BJZwRIbSssHA== X-IronPort-AV: E=McAfee;i="6000,8403,9757"; a="226115560" X-IronPort-AV: E=Sophos;i="5.77,313,1596524400"; d="scan'208";a="226115560" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 02:37:45 -0700 IronPort-SDR: FmBYh7J3ODuTzBO2WMNYSdVb2e1r18oVHokD32Z5WGhv4Bwoxs9B/oeb5l+FwVbZmjfzdwLSus A2Yq2G+KIpzA== X-IronPort-AV: E=Sophos;i="5.77,313,1596524400"; d="scan'208";a="456755403" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 02:37:40 -0700 Received: by paasikivi.fi.intel.com (Postfix, from userid 1000) id 40DFA207A0; Mon, 28 Sep 2020 12:37:38 +0300 (EEST) Date: Mon, 28 Sep 2020 12:37:38 +0300 From: Sakari Ailus To: Lee Jones Cc: Marek Behun , linux-leds@vger.kernel.org, Pavel Machek , Dan Murphy , =?utf-8?Q?Ond=C5=99ej?= Jirman , linux-kernel@vger.kernel.org, Rob Herring , devicetree@vger.kernel.org, Bartosz Golaszewski , Sean Wang , Matthias Brugger , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Orson Zhai , Baolin Wang , Chunyan Zhang , Thierry Reding , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Liam Girdwood , linux-acpi@vger.kernel.org, Mark Brown , "Rafael J. Wysocki" Subject: Re: [PATCH leds v2 05/50] leds: various: guard of_match_table member value with of_match_ptr Message-ID: <20200928093738.GA26842@paasikivi.fi.intel.com> References: <20200917223338.14164-1-marek.behun@nic.cz> <20200917223338.14164-6-marek.behun@nic.cz> <20200918061500.GD26842@paasikivi.fi.intel.com> <20200918112058.6d3b0d5d@nic.cz> <20200918095759.GG26842@paasikivi.fi.intel.com> <20200928080336.GA4637@dell> <20200928081114.GB4637@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200928081114.GB4637@dell> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lee, On Mon, Sep 28, 2020 at 09:11:14AM +0100, Lee Jones wrote: > On Mon, 28 Sep 2020, Lee Jones wrote: > > > On Fri, 18 Sep 2020, Sakari Ailus wrote: > > > > > On Fri, Sep 18, 2020 at 11:20:58AM +0200, Marek Behun wrote: > > > > On Fri, 18 Sep 2020 09:15:00 +0300 > > > > Sakari Ailus wrote: > > > > > > > > > Hi Marek, > > > > > > > > > > On Fri, Sep 18, 2020 at 12:32:53AM +0200, Marek Beh?n wrote: > > > > > > Change > > > > > > .of_match_table = xxx, > > > > > > to > > > > > > .of_match_table = of_match_ptr(xxx), > > > > > > in various drivers. > > > > > > > > > > > > This should be standard even for drivers that depend on OF. > > > > > > > > > > After this patch, none of these drivers will work on ACPI systems anymore. > > > > > > ^ > > > > > > If CONFIG_OF is disabled, that is. > > > > What? of_match_ptr() is designed to change depending on OF or !OF. > > > > Are you confusing this with acpi_match_table()? > > Okay, I just grepped the kernel and found some OF matching in the ACPI > bus code. This seems odd to be (at first sight at least). I'm not > entirely sure how this is supposed to work, but when you disable OF, > one could reasonably expect any matching utilising OF based tables to > be disabled too. There's really no reason having to enable the entire OF framework just to allow compatible string matching. > > Not using of_match_ptr() on ACPI enabled platforms sounds batty to > me. If this is valid, perhaps the of_match_ptr()semantics should be > changed to include ACPI. That'd be one option, yes. But not all drivers that work on both OF and ACPI rely on the compatible strings on ACPI. Another option could be adding a new macro, to set that table on both OF and ACPI when needed? It could be called e.g. of_acpi_match_ptr(), for instance. Cc also linux-acpi list and Rafael. -- Regards, Sakari Ailus