Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp903701pxu; Mon, 23 Nov 2020 07:02:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJzcGvzSJI9iAR2aqJEpovLimrI/mF7OUCPaBPyFnHHfzt5gZ6x4AjUcYxwY3599vQiL1zHW X-Received: by 2002:a05:6402:1d82:: with SMTP id dk2mr25789290edb.366.1606143736343; Mon, 23 Nov 2020 07:02:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606143736; cv=none; d=google.com; s=arc-20160816; b=tzP0hM/aU+x3ndWSlAjFG3F0weeWHE4xaG8rtl9BXjEoRJ/hNQBZjYQvgG6+8H3X7b wJqLLclVFYTB8g8uM/QpcuHuyD9CVR/jCNPN4OLkfRoPOX8QNUmPeBXyg4h82m9WEvXN A1ZhHY/lD8Yqq9zujgz5yovnzZnZSX2zi24am/mGvTEJ5gfPrB/Zh6uToH2QagJKtIyX ehz6jhJKbysafNCAefX8Ufez2T3kJXWrsHFp+1gw8Y0gl+gd8K1Gj7h1HwDyMj5zsMOl xuhwwOGKdm2UgBOLpQ+lIzGeqKlWFrspkp2WlCFrkUz6+nv0dHB7XoPOIoC8Fj1FomHM myeA== 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; bh=8PYxqUct+Q9mNYdM8wqPvnUwdPo92AiSu9RZ/r3u+qk=; b=CoJl/AJBXrN7d/yCWr0UzWoR5JYt6hf3sLv8jLTo1qYYfUPt4SGKgdfNoLU3iIjKj7 PKp1H2XgTqQDOPgwYOUgroX+QPiPeEpLMrx5zLrN+KX9Ygn5sVij2Uptdadlt3yKcxz4 XaxKqJBRQBl6lNwrQMOlRP5gcqfv7rDvSN/mhoC/THzoJ7sSpR6R878yRG86e1g4niO9 aVpDdrrqPHuB+OBkRxBszBxaeSAY+Xly0bghk1TjlOhR5dMQx/AmqGNegMUWYmuIJNe6 GbwUBAV2/VGTWSU3QoZ7V37ITVNGDKW7zbXx9yeu9urukM9oB2KA+KMR8DN3wTgp0su9 i50g== 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p25si7079509edq.230.2020.11.23.07.01.47; Mon, 23 Nov 2020 07:02:16 -0800 (PST) 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729110AbgKWO6i (ORCPT + 99 others); Mon, 23 Nov 2020 09:58:38 -0500 Received: from mail-ed1-f65.google.com ([209.85.208.65]:33579 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727444AbgKWO6g (ORCPT ); Mon, 23 Nov 2020 09:58:36 -0500 Received: by mail-ed1-f65.google.com with SMTP id k4so17419614edl.0 for ; Mon, 23 Nov 2020 06:58:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8PYxqUct+Q9mNYdM8wqPvnUwdPo92AiSu9RZ/r3u+qk=; b=puJ85wHvZF/FWf9t8ZVzkRkvuicst9wtdiRZyviQM9xvujsJuzJ5N5I2OjlQh5Ymwo FkWDY+e8w2QLKTrejfmI1vy93hPip3tx0yZxTGBHrllUcvYi1QKZQ4+A2zlkeVXf9lKb g+A2CRRSnAFyKimHYVD0Jd2DVbzbzRSGAmI+xvtGtTDA/M3VWZeQrpXTlkCbX+TwfuBe kZ+w2VgmF+t/jbmo9hh2InQkqpT15pV9kQmhmwsf2i8c8ZrV7R5od/2aZHOYhBVc6mBO /semlGO/yxJ815xOQ6DSA2Vkv98GlBA8Vi5XDZ4470PgLkBICC90Px/7R63ALJd5pEf0 tDaw== X-Gm-Message-State: AOAM532oRvxkpKSmwK30KMpps8LYz3R63Zk6Xy2279CnA1Yc02u33wY2 qrrEIkiZ7BWQjPpAXbrubC4= X-Received: by 2002:a50:a40f:: with SMTP id u15mr48456599edb.307.1606143514524; Mon, 23 Nov 2020 06:58:34 -0800 (PST) Received: from kozik-lap (adsl-84-226-167-205.adslplus.ch. [84.226.167.205]) by smtp.googlemail.com with ESMTPSA id g20sm5224076ejk.3.2020.11.23.06.58.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Nov 2020 06:58:32 -0800 (PST) Date: Mon, 23 Nov 2020 15:58:31 +0100 From: Krzysztof Kozlowski To: Mark Brown Cc: Andy Shevchenko , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Liam Girdwood , alsa-devel@alsa-project.org, Jaroslav Kysela , Takashi Iwai , Shengjiu Wang Subject: Re: [PATCH 01/38] ASoC: ak5558: drop of_match_ptr from of_device_id table Message-ID: <20201123145831.GA202597@kozik-lap> References: <20201120161653.445521-1-krzk@kernel.org> <20201120165202.GG6751@sirena.org.uk> <20201120194245.GA2925@kozik-lap> <20201120200429.GJ6751@sirena.org.uk> <20201122105813.GA3780@kozik-lap> <20201123104832.GY4077@smile.fi.intel.com> <20201123123731.GA6322@sirena.org.uk> <20201123124129.GA170000@kozik-lap> <20201123135006.GE6322@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201123135006.GE6322@sirena.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 23, 2020 at 01:50:06PM +0000, Mark Brown wrote: > On Mon, Nov 23, 2020 at 01:41:29PM +0100, Krzysztof Kozlowski wrote: > > On Mon, Nov 23, 2020 at 12:37:31PM +0000, Mark Brown wrote: > > > > That feels like something that should be done with Kconfig dependencies > > > like a direct OF dependency (possibly a !PRP0001 dependency?) for the > > > driver or possibly with having a variant of_match_ptr() for things that > > > really don't want to support PRP0001. Just removing all the use of > > > of_match_ptr() is both noisy and confusing in that it looks like it's > > > creating issues to fix, it makes it hard to understand when and why one > > > should use the macro. > > > For the OF-only drivers (without other ID table), there is no point to > > use the macro. Driver can bind only with DT, so what is the point of > > of_match_ptr? To skip the OF table when building without OF? Driver > > won't be usable at all in such case. So maybe for compile testing? > > There is no need to remove OF table for simple build tests. > > If nothing else it means you don't have to check if the driver is OF > only or not. I can see not bothering to add it but actively going round > removing some instances of it doesn't seem great, and it seems like > people will constantly be adding new uses on the basis that it's just > such an obviously correct thing to do. If my patch was not changing anything, I would agree that it might be just a churn. But the patch fixes a real warning. The other way of fixing warning is the one you proposed at beginning - adding maybe_unused. Here we go to the second reason: Having these of_match_ptr() for OF-only drivers is not the correct way but rather something which is copied from existing drivers into new ones. This is another reason for removing them - people will stop copying this code all over again. Best regards, Krzysztof