Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp3275151ybh; Mon, 5 Aug 2019 15:26:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqzBX0ZiP/Iax+jzcfYEQdY5D0WzVJuNYbbtyOUDqeoS2OoHL6QCEyN75Rm7WfVhgToU5DQo X-Received: by 2002:a65:50c5:: with SMTP id s5mr139408pgp.368.1565043997135; Mon, 05 Aug 2019 15:26:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565043997; cv=none; d=google.com; s=arc-20160816; b=GnoQraCNM64uwMzBPyYkxm+oWBoIVGRLXylV2jg3QWFijBwQKi1lPFOcmN2obl2leb +MiH8mH+1vGlh95HaqA8Wved3haeTYyjqxkuubtFR97MbI21PeIilJ6som5FdMYvJmOx SjIsjXT0Fj1IDPUhSHEsJGfvkXTZ4W5/nZp03PU6R26J8e+RlhN9uPinOxid1NtGhmti mAazhrxOoKgMd7TSx0O5W59zkO/lGUpMAlTU2CMs6nrYUbqN5Rp6j86/EsRUXVyACYSM Y8CunUS6yzRxsoqnvJmPaVrRs5ur12YAkEVY6x985MmpQjzET6rQ4idtTmJ8BjToNbtv 9H5A== 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=v3ukfwq9sao2HM0nnFsoZLetdOCEK73QpJzj1XGgANk=; b=QxQ+MMTYpQfrOonE7kAcZd+NCwEecgt/1kliinp8LU7me4fBaXqD6qDUOSAFPaPRuc ziNCvXR5HmV0tfVy9tcJhO/f//uKhLzGcyc4u7w4YsFkh6+zijjutHRDgii0CANQaNaG i86fV3EOe6W7dNuS9lV5dFC17HZlxnCQQq1fpt1apIpHEPIyiKL16zT1QoFxUStq9Zzt GGrScGtzlE1bVOiiHr8Gn7iCdSNjdeXpeomhdMgacInE/a0/TzwYQHXtUIDwJg/t/F2u XlH8HCFRlXy0vJ12ARTTBIKgyTuYwVWkzcngdiuv+Qs+IZk5Z4gWVNLH2lnzFShm6lQ0 VNrA== 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 f12si47697435pfq.187.2019.08.05.15.26.21; Mon, 05 Aug 2019 15:26:37 -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 S1730809AbfHEWZp (ORCPT + 99 others); Mon, 5 Aug 2019 18:25:45 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:45639 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729999AbfHEWZp (ORCPT ); Mon, 5 Aug 2019 18:25:45 -0400 Received: by mail-wr1-f65.google.com with SMTP id f9so6979742wre.12 for ; Mon, 05 Aug 2019 15:25:43 -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=v3ukfwq9sao2HM0nnFsoZLetdOCEK73QpJzj1XGgANk=; b=CsJ1It6FqMV+vbiAJEqNTy6e9itTD60wiiACXOZs/UAwMKbjVZ7oZsDWdOeTOei98O 0y/a53odJRC3ROPcWXKX9VVR9ZAdUjTr+FaIj305Hz5zEtPEasojczQaTlTfcZN2Xsjo k5pNiNvxR0jXxgkawDuRB5vVZM+TZHsdC2ysJRu4jLxksgDtftvC+zztWkIpI0L4E2y8 /+Ar0D28Slmp7stK485adGlFjvixilnukInzBHEKpA7Y/yn4to6RtAxkGoXbtRL3HiEO edF6TfKgTZOegylJJIvzcidsgbMqEKMA3zFhehZZciz/45u7Imw/HTQk5NK4OqwthkwB S3rw== X-Gm-Message-State: APjAAAXYSkrk1+3lNmQkq6zSjs6r82/2fk7N2COvAS6HSkkkn5/Um77R k3KiWBlVgnRzeM2obl2qmwMp/Q== X-Received: by 2002:adf:f088:: with SMTP id n8mr245425wro.58.1565043942911; Mon, 05 Aug 2019 15:25:42 -0700 (PDT) Received: from [192.168.0.24] ([181.120.177.224]) by smtp.gmail.com with ESMTPSA id t185sm78372904wma.11.2019.08.05.15.25.38 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 15:25:42 -0700 (PDT) Subject: Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables To: Wolfram Sang Cc: Kieran Bingham , Masahiro Yamada , Michal Marek , linux-kbuild@vger.kernel.org, open list , linux-renesas-soc@vger.kernel.org, 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> From: Javier Martinez Canillas Message-ID: Date: Tue, 6 Aug 2019 00:25:34 +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: <20190731194419.GB4084@kunai> Content-Type: text/plain; charset=windows-1252 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 Wolfram, On 7/31/19 9:44 PM, Wolfram Sang wrote: > Hi Javier, > > thank you for providing the extra information. > > (And Kieran, thanks for the patch!) > >> 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. > > That would probably mean that only a minority of drivers will not add an I2C > device ID table because it is easy to add an you get the sysfs feature? > I believe so yes. > Then we are back again with the situation that most drivers will have > multiple tables. With the minor change that the I2C device id table is > not required anymore by the core, but it will be just very useful to > have? Or? > Yes, it won't be needed anymore if you are only instantiating all your devices from your firmware interface (e.g: OF, ACPI). >> If the former is the correct way to solve this then the patch looks good to me. >> >> Reviewed-by: Javier Martinez Canillas > > For this actual patch from Kieran, I'd like to hear an opinion from the > people maintaining modpost. The aproach looks okay to me, yet I can't > tell how "easy" we are with adding new types like 'i2c_of'. > As Masahiro-san mentioned, this approach will still require to add a new macro MODULE_DEVICE_TABLE(i2c_of, bar_of_match) so the OF device table is used twice. One to expose the "of:N*T*Cfoo,bar" and another one to expose it as "i2c:bar". I expect that many developers would miss adding this macro for new drivers that are DT-only and so sysfs instantiation would not work there. So whatever is the approach taken we should clearly document all this so drivers authors are aware. > Thanks everyone, > > Wolfram > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat