Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7051339ybi; Mon, 22 Jul 2019 06:20:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqhmr5Bz8F2EafsSlrSc1mNJfChmA36IEQLrZXfmkDeq5Ors5P9XnIVAUQjQOs3scCl9qr X-Received: by 2002:a63:c751:: with SMTP id v17mr56141238pgg.264.1563801638270; Mon, 22 Jul 2019 06:20:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563801638; cv=none; d=google.com; s=arc-20160816; b=yIyLFp2vjWxbYJGY2KnR8b6kDxq34O6fTVIxLikhlK6rINZQ5b9AzFfS5ZkJbN49nI itlYZVdu+xdH8eUJihOULYzECJsg/o7cEYjWfjBVhU/kNVG9YxV4YZkAv5G2oynLrHAe JG6fFHFQHCRzVgmzSqWq1gPSo7unZCVFnuRo08L/6Of8NJuzBqlHRyn9nWpKptatTunR fwh6D44c9QV9viFkNMwNKBrAvudAlWlKQaZPWq6fgV23WxA0bHpe7Q+x61xc5n+y3NfO TvzxNRf289EIXchVSsshWktEIRX+Q++nLToSVM6ZBMYRmgfsaDvv7d6R/LE21/9D4AVo yLsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=z0qoHRf6gBg774SquOndxWjyxuQj7ytfuhU1dKVmZIc=; b=cdl+YxJlOS1C/woKCcEU/44hUMfhoMD2mgFpL5p8yW8Mh0EostzjtziklK9WNNo9ID fEgp+dD2FBi3CsgUUSRW6zqAQEjVZGGKU+qrJhUQF+I3ae7S9Vx+5mboorKjPUDoIV5T /NaJwl9ss+uV7+uM/r2XD5ERmU3cq5Zwnw0x+3snN/yTXg1yrW5gGjNrllkJnfwcvLKE bY1t4lTAgfPXNGMGgr3XDKb3djcBq+T0LhbD4tRyYepet7Gff8Tz+COaxqvwKbi1nMu2 gr4N9y1Z1gvi0MkoYwx8A1hJtXd8T8e+HB6VGuLarghhsBtCharr4Jub/nzCqAkgU9ke PmdA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u18si8280198plq.311.2019.07.22.06.20.22; Mon, 22 Jul 2019 06:20:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728924AbfGVNDb (ORCPT + 99 others); Mon, 22 Jul 2019 09:03:31 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:37189 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730172AbfGVNDa (ORCPT ); Mon, 22 Jul 2019 09:03:30 -0400 Received: by mail-wm1-f67.google.com with SMTP id f17so35237835wme.2 for ; Mon, 22 Jul 2019 06:03:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z0qoHRf6gBg774SquOndxWjyxuQj7ytfuhU1dKVmZIc=; b=Tcrobu/0XhlllqYwY+s7scjKIWvTX/ZuAY42gpIPLmEkXCWVRTSp1YoIrRo2gOTSny tvjGMOAULbQz3rr+qJQgyH+zQ8XGJX8cfqxS0PueYM3Vph2BrjNPnPruAbrA9Z/pZuPF Mbi8A5IUVPxHZRS7n5DYZyMls5lWwPka4TzEeR83R7pMSTNxgPWcyY1acINpcOPGwN+m 2JZjjuiuU/EaOsEGk1uEV9WnGQeCDME9sgFtRvzrvqX89wj9IuoK2FxLL0EDVBHLUHKP P8sUg5m3ftGIQ/n2sjwK52JKqxJWrT7BGMYZv+UVGuaq+uDCqYXqIravbdGiq1esX7ac Q2oQ== X-Gm-Message-State: APjAAAXpfdv9uZzTXETXEwXRfrT4W5ScyHAxkEcgRLQqg2yYotQ5AEXP T4uOc7iVClff4sHkGkfvwpGyIg== X-Received: by 2002:a1c:9a4b:: with SMTP id c72mr38257114wme.102.1563800608945; Mon, 22 Jul 2019 06:03:28 -0700 (PDT) Received: from [192.168.1.13] ([90.168.169.92]) by smtp.gmail.com with ESMTPSA id j17sm58257486wrb.35.2019.07.22.06.03.27 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:03:28 -0700 (PDT) Subject: Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables To: Kieran Bingham , Wolfram Sang , Masahiro Yamada , Michal Marek , linux-kbuild@vger.kernel.org, open list Cc: linux-renesas-soc@vger.kernel.org, Lee Jones , Alexandre Belloni , Andy Shevchenko , Mark Brown References: <20190710193918.31135-1-kieran.bingham+renesas@ideasonboard.com> From: Javier Martinez Canillas Message-ID: <0e1b6e0b-1c94-4b00-7fda-c2a303ee3816@redhat.com> Date: Mon, 22 Jul 2019 15:03:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190710193918.31135-1-kieran.bingham+renesas@ideasonboard.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Kieran, On 7/10/19 9:39 PM, Kieran Bingham wrote: > I2C drivers match against an I2C ID table, an OF table, and an ACPI > table. It is now also possible to match against an OF table entry > without the vendor prefix to support backwards compatibility, and allow > simplification of the i2c probe functions. > > As part of this matching, the probe function is being converted to > remove the need to specify the i2c_device_id table, but to support > module aliasing, we still require to have the MODULE_DEVICE_TABLE entry. > My opinion on this is that I2C drivers should register the tables of the firmware interfaces that support. That is, if a driver is only used in a platform that supports OF then it should only require an OF device table. But if the driver supports devices that can also be present in platforms that use ACPI, then should also require to have an ACPI device ID table. So there should be consistency about what table is used for both matching a device with a driver and reporting a modalias to user-space for module auto-loading. If a I2C device was instantiated by OF, then the OF table should be used for both reporting a modalias uevent and matching a driver. Now, the i2c_of_match_device() function attempts to match by first calling of_match_device() and if fails fallbacks to i2c_of_match_device_sysfs(). The latter attempts to match the I2C device by striping the vendor prefix of the compatible strings on the OF device ID table. That means that you could instantiate an I2C device ID through the sysfs interface and the OF table would be used to match the driver. But i2c_device_uevent() would had reported an I2C modalias and not an OF modalias (since the registered device won't have an associated of_node) so there's inconsistency in that case since a table is used to match but no to report modaliases. > Facilitate generating the I2C aliases directly from the of_device_id > tables, by stripping the vendor prefix prefix from the compatible string > and using that as an alias just as the i2c-core supports. > I see two ways to solve this issue. One is with $SUBJECT since we can argue that if a OF-only driver is able to match devices that were instantiated through the sysfs interface that only have a device name, then a modalias of the form i2c: is needed. Since the compatible strings without the vendor prefix is used to match, then I think that makes sense to also use them without the vendor prefix to populate I2C modaliases as $SUBJECT does. The other option is to remove i2c_of_match_device() and don't make OF match to fallback to i2c_of_match_device_sysfs(). This is what happens in the ACPI case, since i2c_device_match() just calls acpi_driver_match_device() directly and doesn't have a wrapper function that fallbacks to sysfs matching. In this case an I2C device ID table would be required if the devices have to be instantiated through sysfs. That way the I2C table would be used both for auto-loading and also to match the device when it doesn't have an of_node. If the former is the correct way to solve this then the patch looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat