Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp360482imm; Tue, 9 Oct 2018 19:52:52 -0700 (PDT) X-Google-Smtp-Source: ACcGV61m47lOmJbKRbGgdM2KpWnqSVT48970aEPJEn8Sj7+lBYx6WasHY4r/van1nK9iUk+aa5Q6 X-Received: by 2002:a17:902:ac8e:: with SMTP id h14-v6mr30653811plr.300.1539139972717; Tue, 09 Oct 2018 19:52:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539139972; cv=none; d=google.com; s=arc-20160816; b=bHASbeaiongW2DFmfBzdBPeZK63pqkRPc1x04r5SwdREznPVyQOlAIrF4zUWDoDnO3 XsxbLXxLgK+vCi547BFMSsFcvRiVooOFyyEOr89FvYxjQhcFHHSbqzTCB9P+C4QSCwlH oZ0mPrvqoV5ZHb266CcMX9fvkwSU+TY6Nf6uRB5ZkXPexDJ3DJs06Buj8ME/I1YrrKTn DaCGRmFiVsiXRk3i0MTa9SU79GKtUii5he5CqIxFc+R+voC4vkN5GSiFYEcoKOW5GSEs 1+B07qYfvDAF6azrvXk9h3VG8v+z7vF0MI0GY0VoKSFC4Iiv4g7GKmc7dz+ZCk5SixI1 40RQ== 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 :in-reply-to:references:mime-version:dkim-signature; bh=rgrUYw0eHjqpzCTuzq4f1UOL6UvVlEvan1YJ2oBFEt8=; b=uvDZs/3IHz9y+wWDJhXR7Vm2mmQElSVxXdtW8rfZkedveY21Cc09t3L9ptYK+95HsZ JW5LDeEch8siuD2zHLyB1aKmFoPYKQ6pqxSltQT1Hlpm8W32iwSIv4pVARvoUYxze4zr m+/poUcnfPQ4BRdYE6eoT1Jdw1Gi8XtbS9QLfeYZcklKybtP88u6tMSLv6vhgF+z+aus n7Cc2KHG7OjnQYHtEm8wHGOsP+OkHJJe6lmHfbs60HHyMDh9rkusEhOIroZHflDRjJw0 W4GgI7hDMwRe5ntOQMt+6RZ5Wnhh1l93JfBom0KDZIeeYdIFugOLpiz2qUbDytYvYdv3 o9hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mvista-com.20150623.gappssmtp.com header.s=20150623 header.b=oJCjEp8+; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i23-v6si21783671pgl.230.2018.10.09.19.52.38; Tue, 09 Oct 2018 19:52:52 -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=@mvista-com.20150623.gappssmtp.com header.s=20150623 header.b=oJCjEp8+; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727031AbeJJKJS (ORCPT + 99 others); Wed, 10 Oct 2018 06:09:18 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:34635 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726721AbeJJKJR (ORCPT ); Wed, 10 Oct 2018 06:09:17 -0400 Received: by mail-lf1-f66.google.com with SMTP id y10-v6so2824633lfj.1 for ; Tue, 09 Oct 2018 19:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rgrUYw0eHjqpzCTuzq4f1UOL6UvVlEvan1YJ2oBFEt8=; b=oJCjEp8+zzOuzfvRUtNfsec5d/MLseRmsHEsxq9hdNBLgVb2CFuxolv8mkQ0ipxFBH 5TyOyG0NxWToHXEPuhZ4wYWc0L4lF8yG9nZCwu9B4ZFQck9ggkbOZE+M5ZyLFjvkCE6e Tewbm18bc3n7snhnWI3WPIxrKTIPG6M80I6Xn4n177vKe5ihILQ3+EYv04RUykVPi1Pm Mbli/ucb6PbK8gPx36yu3OCqYcJultUKA3C255+p24NVMK8hlXX2LX6KMO/rpH/PBr55 ALbYCtDxQg29bJfni29wiY7tuo1vxmN+I+Yd+s/Eh5mVYGZ0VpusH02yh3xqad1CRx5Y iTFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rgrUYw0eHjqpzCTuzq4f1UOL6UvVlEvan1YJ2oBFEt8=; b=mW4P/wwvEAPxpsHwFAruosUd+N9gKtNpFUNjt4eTU6PQtmYZ8+Ool429RDaiLPK4A3 VcSi8jTXl7YzPucGxHOWrkHSErfITVpUX5zgDfl3UyLvU30aQdqnjbIiI1iWLfXCxzFa DDwtyPY4IR0Oa5wlZxbKv5CDX+ecNuA8pE+BdD7gXLr8H0L43KGOMWCuCypBWNhBhwEB sEb0BmUqNb138Yiqrw5O7YtA2vktHHgE7GMw74Z0nn8Uvh93hwKh/GyHMPhgxbjWCN5t p1nQb41x1D5MkmU94MKhk3pV+OQX6m6FdybPriHJQ9Yrdhn4hQ9PAt0wKaaaKpkwXAzF 8WXA== X-Gm-Message-State: ABuFfohNAnM4zIObuh+Oqs4lQtjBFFOdcXu5ckLqMZ+pH0y0GwscNWsu TB8j490Y7CW7MTB+pFDZ9ebXrpPE6MmQG07gac5BRw== X-Received: by 2002:a19:504e:: with SMTP id z14-v6mr8230487lfj.120.1539139758337; Tue, 09 Oct 2018 19:49:18 -0700 (PDT) MIME-Version: 1.0 References: <1539080245-25818-1-git-send-email-svellattu@mvista.com> <20181009110210.i6xphyuy5jkcfaug@katana> In-Reply-To: <20181009110210.i6xphyuy5jkcfaug@katana> From: Silesh C V Date: Wed, 10 Oct 2018 08:19:06 +0530 Message-ID: Subject: Re: [PATCH v3 1/2] Driver core: add bus_find_device_by_fwnode To: Wolfram Sang Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-rdma@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-spi@vger.kernel.org, Mathieu Poirier , Lijun Ou , "Wei Hu(Xavier)" , Yisen Zhuang , Salil Mehta , Srinivas Kandagatla , Andrew Lunn , Florian Fainelli , Rob Herring , Frank Rowand , Mark Brown , "David S. Miller" 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 Hello Wolfram, On Tue, Oct 9, 2018 at 4:32 PM Wolfram Sang wrote: > > On Tue, Oct 09, 2018 at 03:47:24PM +0530, Silesh C V wrote: > > Some drivers need to find the device on a bus having a specific firmware > > node. Currently, such drivers have their own implementations to do this. > > Provide a helper similar to bus_find_device_by_name so that each driver > > does not have to reinvent this. > > > > Signed-off-by: Silesh C V > > Looks good in general, however: > > We recently had this discussion in I2C world about using the parent if > the (logical) device has a NULL fw_node [1]. I don't know if the other > subsystems you modify use logical devices as well? If no, it seems we > need an additional check for the parent in the I2C core only. If yes, > this might be considered in your patchset? We can add an additional check for dev_fwnode(dev->parent) if match for dev_fwnode(dev) fails in match_fwnode callback. Please correct me if I am wrong. But then, we will be doing these two comparisons for each device (until a match is found) on a bus for a bus_find_device iteration(mostly unnecessarily because I could not find any "match node" callbacks (for bus_find_device) currently doing this). So, wouldn't it be better to add this check in exceptional cases (like in the case of I2C) in the respective subsystems itself ? Thanks, Silesh