Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp4381405ybh; Tue, 6 Aug 2019 10:40:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqwIs4j4g3MPSZc7MQowj8T0QGLq3bM6LWIBd0boa2m1QHOLlEFmfNNRYfFCO3Fc/ZyD1QtH X-Received: by 2002:a17:90a:d996:: with SMTP id d22mr4396785pjv.86.1565113254811; Tue, 06 Aug 2019 10:40:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565113254; cv=none; d=google.com; s=arc-20160816; b=pqBJChG1dJLcKC20XQ1hnW/ASX+niCyD6Fu+igC8B33BT+ig00YLw4aLUTTjn4zk4H rpJ+Qx+ZaHj2f6cchTAbapSxBnLMcpVMnmywoZpUOW6kWRETz9/kbjwJ8WN08sgBdcxd 8bbkEA95/8ymaTNKEdk/vCQG4shDNa2b19GV1I/N39cHjSoiHMAvWC6fpyz3xmrkEUZh DunK5MdG7FuMfEWbokGm2sErmPaJZ90KdkROl92OdNJVLuUPriaIQNmu3qz9OrKaAG4d 0wbZVOhuagSxzp9qAuF36N5zVe1v5/oHvEhmXlgnUa2SGWYK3f7zRgw5EehWm0s5ft6z KhBQ== 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=+GYAfSOb8TtiZxSa6IuLwHMy8VxqimVP3LYovrx/inM=; b=Qqi2L5rXB8izBwY+2iVpzcUVWYdJvt8+YrjPaV0u6sZlnfFlPv5vKm642w0w8ehaE8 qIQnLZWxr7tq0E9uqFTD/Mt5vV9xJOgpxWv9wyR+iGmYFcZTQEYA7EM9k+7BEn4py0eQ C/pxn+SiFgJGirR91MGjROYk0b7pajpbQQYVfy8aYCVowfQB8heWTepF0sXp1KBXgXJI 42f2VcmLulJDQk3nNV+94rRtjE2nuq3eOt+1OedMAjw9GHl+e2fVTaWV21nIp1wtqT+3 Nu+eB2W4rM1uVrpbJ9hZkaUXiBj9GNqOLHrIsOPwgxT7aQ5tFbB0QQs3wHKeVpPwXtJ/ QRUg== 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 s6si44604933plp.229.2019.08.06.10.40.39; Tue, 06 Aug 2019 10:40:54 -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 S2387799AbfHFRkB (ORCPT + 99 others); Tue, 6 Aug 2019 13:40:01 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:35729 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387741AbfHFRj7 (ORCPT ); Tue, 6 Aug 2019 13:39:59 -0400 Received: by mail-wm1-f66.google.com with SMTP id l2so77262124wmg.0 for ; Tue, 06 Aug 2019 10:39:58 -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=+GYAfSOb8TtiZxSa6IuLwHMy8VxqimVP3LYovrx/inM=; b=blRoZsZA63axN/2Rx2rXctQ0zWGMB6P/JsIpD84Yf1Lf4PdBqDav12tRAQCGZodSJk PXLeEhDT/YnlDteds/JqN0aeNoabi+lS47CX27002BaeuQ16M8KbbJEv3wDfH++cYDme dGo9ZmPNuriQujlzUj8XZY7hW4BV18zIwUZspZJvijuR26EcRWKKJcfmpR5P711NekZN M3YLQ8cilPXhWtOijZEBNfQB7q4MZUJBXrGt91Z+z7fXsjDiwqfdyCWMaAXRMKPOXRI2 h53h5zdEg4gUtlqep1yX6ZBCp5yoOygam4H2xS+rAY4w2/OEyo2k4SVVTr7zERS6Ad8z 56iQ== X-Gm-Message-State: APjAAAXeORToeKqyKyBfraviSOcUsvjFmRtD5zJvamPhOJ0CLXkrwPdz aqyvj7sSsPLtgv9PxCGm1lnmqg== X-Received: by 2002:a1c:dc46:: with SMTP id t67mr5378480wmg.159.1565113197551; Tue, 06 Aug 2019 10:39:57 -0700 (PDT) Received: from [192.168.0.24] ([181.120.177.224]) by smtp.gmail.com with ESMTPSA id x18sm80979493wmi.12.2019.08.06.10.39.52 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 10:39:56 -0700 (PDT) Subject: Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables To: Geert Uytterhoeven Cc: Masahiro Yamada , Wolfram Sang , Kieran Bingham , Michal Marek , Linux Kbuild mailing list , open list , Linux-Renesas , Lee Jones , Alexandre Belloni , Andy Shevchenko , Mark Brown References: <20190710193918.31135-1-kieran.bingham+renesas@ideasonboard.com> <0e1b6e0b-1c94-4b00-7fda-c2a303ee3816@redhat.com> <20190731194419.GB4084@kunai> <2567a74d-738e-6fed-d91c-cc70743e116d@redhat.com> From: Javier Martinez Canillas Message-ID: <8df8133c-60c6-d9b5-2594-d7a5715e907a@redhat.com> Date: Tue, 6 Aug 2019 19:39:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: 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 Geert, On 8/6/19 9:30 AM, Geert Uytterhoeven wrote: > On Tue, Aug 6, 2019 at 12:48 AM Javier Martinez Canillas > wrote: >> On 8/1/19 4:17 AM, Masahiro Yamada wrote: >> So I think that we should either: >> >> a) take Kieran's patch or b) remove the i2c_of_match_device_sysfs() fallback >> for OF and require an I2C device table for sysfs instantiation and matching. >> >>> If a driver supports DT and devices are instantiated via DT, >>> in which situation is this useful? >> >> Is useful if you don't have all the I2C devices described in the DT. For example >> a daughterboard with an I2C device is connected to a board through an expansion >> slot or an I2C device connected directly to I2C pins exposed in a machine. >> >> In these cases your I2C devices won't be static so users might want to use the >> sysfs user-space interface to instantiate the I2C devices, i.e: >> >> # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device >> >> as explained in https://github.com/torvalds/linux/blob/master/Documentation/i2c/instantiating-devices#L207 > > Does this actually work with DT names, too? E.g. > > # echo atmel,24c02 > /sys/bus/i2c/devices/i2c-3/new_device > My understanding is that it does. If I'm reading the code correctly the i2c_of_match_device_sysfs() function first attempts to match using both the vendor and device part of the compatible string and if that fails, it strips the vendor part and try to match only using the device part. So you could use any of the following: # echo 24c02 0x50 > /sys/bus/i2c/devices/i2c-3/new_device # echo atmel,24c02 0x50 > /sys/bus/i2c/devices/i2c-3/new_device Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat