Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp632832imm; Wed, 4 Jul 2018 03:20:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpczO1MUzaW7t7q/xWqzptDqXoXCMYdcD/qOVOKH6CoOWxj0iWwCVCEOMCqfl/EMKMEDFVq4 X-Received: by 2002:a17:902:bf01:: with SMTP id bi1-v6mr1494679plb.43.1530699645272; Wed, 04 Jul 2018 03:20:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530699645; cv=none; d=google.com; s=arc-20160816; b=zVQayWYKBTT4TVE7sX3Nmr1wd2G/0klprkRxA/0PNWNc3qgxeV21mZ2ygnKYSekQI7 YUbpQrmHvw7J3L6x9uAJT4fSA/aEy935tte54fQE1imozgQShtT+R7h1AykCpeeXTNZz euvYGeir7sHvcqWkOEaOvAyf/OKIaU0/Rf4ENK0Q1frQIT3kf7qtZSQ5PnOr+sThd3AN /h8i02BuOmx41IBfryseTC1RmOcSV+lDLWtN3WclMjA+lDyWSX+9Kr3wRPgFyic1gong fwEQNNU5/slH4BDszopnBAtTheKqWguslNsC7j5Y5O97hyv3j7dlSrkZaP3gyhQitqZ3 kt/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=tdBArjcc1matlQ0iR03GHlXgkoI7jKk2Od9X65ZmdpU=; b=GbObkOFf0jKcaMPHO1ALo5RTX/TKokL4FQEN9XNNo6EBH5tdrra7hVnQ0oSGiazgyD bdIp3vpqsD2LSyUj0ZZUlNwd8ogIhn6xbtf46rxtlxQOzG5dFwzUUgmZ215e5cC6/hBE V+Vzbh2ytOB0uOMjwxRJgNOFTxJCHbBrP78neVa9C+Ip4G8gVAN4dWERyRTqJDlZ41IQ 7UbiXrP3sNFJoxiIX3opMK7da1dygE/WdQ4/GtsJ8JZ0Sq6qctGSr2mdKkCTtFd9lUos IAL5roWlU8fHzoq2vwO/DmpSTyEyN4IANYs7HPpCndguBrXV5qvYrEF/oRU1Rkj+JzHH UXbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JpSa0qjT; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z33-v6si3125650pga.197.2018.07.04.03.20.30; Wed, 04 Jul 2018 03:20:45 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JpSa0qjT; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934705AbeGDKTb (ORCPT + 99 others); Wed, 4 Jul 2018 06:19:31 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:33009 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933862AbeGDKT2 (ORCPT ); Wed, 4 Jul 2018 06:19:28 -0400 Received: by mail-ua0-f194.google.com with SMTP id g18-v6so3134740uak.0; Wed, 04 Jul 2018 03:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tdBArjcc1matlQ0iR03GHlXgkoI7jKk2Od9X65ZmdpU=; b=JpSa0qjTipReanSZh/vR6OPuJVNf6se5aHYrWssHmfc7uL58Ac89+glIXSgXnwPTKr dLUF7+gV9naHk7HhtXtdldw3feP9jfiSyNgNk35WPwN/HFR4KRNGJwQXnc2te6nCCdAV VLhGUxcZVHTbEiE8F/YtZs3AE6aMMzjKaDMx1nuewcQCUUd5HyqL3eZ0ah+EyMWkGPSu 6HFnXOmDXg8A0EdiYcWQpv+36MgjiUleMuRttKua63Ys0XRlaDom5gIbjN4YKLD3Ti2+ SWOaupWu063h8fppwe/aIhwJzZQHNJ0wp75HAMIVA92xKhSvCNDH2Z1PwSKHpQngmqYw P+zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tdBArjcc1matlQ0iR03GHlXgkoI7jKk2Od9X65ZmdpU=; b=cflA7xqcu413mYcg525tyMmkq+RLDzIDYCreKwCFU8kY40W8u1/SSwtWB+dtn/BSan uw1fQjl9oOxb2PffSNTI+hqxuAMzVty9w09TRrQyxeMjXZyqerJL5OUnXDrnYukJWJVJ CdH2Xq9fj7pn86oPtEXS0LnELqBAERpnS26hQmvjt3f4zdTwuH/itkCELJTblW0CrHoI 2pUomKNl5ZOaRkNSOj4Ph7BpStq2XDJ8kojQHCxrKNMGkRbR62m8KxrlqAmNK0ns6Qyk kU12J1nB2WsRhvg1ZO5YPKp0UCzTj8pkcSTO2VpH/G7r0sIFfrCeJPruqCDmG57NiHdH TnMQ== X-Gm-Message-State: APt69E1P22P5lY3Lgr5eNxfyb0MV9WMCV0K5GWBDJ4ep27/Cga7o2Ndr DF/7UlQa9mq6nMBAikskqAljxGa/Q48/uB5S3Zg= X-Received: by 2002:ab0:6037:: with SMTP id n23-v6mr776664ual.28.1530699567572; Wed, 04 Jul 2018 03:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:2149:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 03:19:26 -0700 (PDT) In-Reply-To: References: <82c6f53cfa03f9bc7c0adfc423ae65fc986a1d25.1530599660.git.nikolaus.voss@loewensteinmedical.de> From: Andy Shevchenko Date: Wed, 4 Jul 2018 13:19:26 +0300 Message-ID: Subject: Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe() To: Nikolaus Voss , Javier Martinez Canillas Cc: Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Lorenzo Bianconi , Linus Walleij , Xiongfeng Wang , linux-iio@vger.kernel.org, Linux Kernel Mailing List , nv@vosn.de Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Summon Javier to the discussion. For my opinion he is an expert in this topic. On Wed, Jul 4, 2018 at 12:42 PM, Nikolaus Voss wrote: > On Wed, 4 Jul 2018, Andy Shevchenko wrote: >> On Wed, Jul 4, 2018 at 12:09 PM, Nikolaus Voss >> wrote: >>> On Wed, 4 Jul 2018, Andy Shevchenko wrote: >>>> On Wed, Jul 4, 2018 at 9:37 AM, Nikolaus Voss >>>> wrote: >>>>> On Wed, 4 Jul 2018, Andy Shevchenko wrote: >>>>>> On Tue, Jul 3, 2018 at 9:06 AM, Nikolaus Voss >>>>>> wrote: >>>>>>> struct i2c_device_id argument of probe() is not used, so use >>>>>>> probe_new() >>>>>>> instead. >>>>>> This makes... >>>>>> >>>>>>> MODULE_DEVICE_TABLE(i2c, st_accel_id_table); >>>>>> ...this table obsolete IIUC. At least that's what I did when switched >>>>>> to ->probe_new() in some drivers. >>>>>> >>>>>> If I'm mistaken (again? :-) ) I would hear from someone to point me >>>>>> how it can be used after a switch. >>>>> It is still used by the i2c-core in i2c_device_match() if DT and ACPI >>>>> matching fails. >>>>> And it is used to create the corresponding modaliases for >>>>> driver loading. >>>> My question is "How?!" >>>> I don't really see any points to match against it after switching to >>>> ->probe_new(). >>>> >>>> Could you point me to the code path in i2c (or OF?) core for that? >>> As written above in i2c-core-base.c: i2c_device_match() -> >>> i2c_match_id(driver->id_table,... >>> >>> This is used for driver matching before probe() or probe_new() of the >>> device >>> driver can be called. probe_new() actually is a function signature change >>> only. >> Okay, IIUC we got a match. What should we do with it? The table is not >> used in ->probe_new() (in i2c core), so, you can't say which line >> matched there. > The table is not used by the driver, but is necessary to > > a) bind an i2c device declared via i2c_board_info with type field set > to one of the names of the i2c_device_id table to this driver > b) bind an i2c device declared via DT or ACPI but with no match in of_id/ > acpi_id table but an i2c_device_id table match to this driver (fallback > matching) > c) create the right modaliases at compile time for this driver to make > module auto-loading work in case of a) and b) Javier, just a summary of the above. Nikolaus switched one driver to use ->probe_new() hook and left i2c ID table at the same time. My understanding that this table is not anymore in use. But I have to admit I didn't see entire picture of this. Can you shed a light? -- With Best Regards, Andy Shevchenko