Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1317705ybp; Fri, 11 Oct 2019 12:18:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZHLh9Cn52BY1FQC1vU61M4eccRKBM3OvkIm3Sh9QP16zTBaLaj++eO6//Bg0LOYl8Ixxb X-Received: by 2002:a50:da0f:: with SMTP id z15mr15200467edj.137.1570821486107; Fri, 11 Oct 2019 12:18:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570821486; cv=none; d=google.com; s=arc-20160816; b=L3dEPTqoS9m0ojx/gnvOdTvFRT7RmV+vQgolmZG7VtIZqKK/amJEVcaKHoS/uWanzr YRLwc/y4COsIuiId1c76pihebhV8S/9QGa9NEO5aBrB/l83ifgjNWjE+tym2O4G5cjdT qvSUeAtjWEocCLYX9L/AWkAeZtqIvFTGmT8e2QtYmT8tBnDDxu/2yaa6aB9IEmTK4t7h dHSWl1Qy0Nb3nnZP/hG2LPWkzhNcygco62QjUp+9Wn2zzT0Un0a5gPPwXIilhQqVw7Ru 6f+YKzfbtLe2LfO5uArv8GKnUzi/kLEUbzeNJymeKz9eInypOjee3FECD2iOfPudiQnA cc6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:dkim-signature; bh=wwUIXG8zaTQahpGiWbKYxnh72iiHnCVZCniLVYgkymY=; b=XaCtIAgGjJgbGcxJZURBAYOgsYP60L/9WkaYPeZBU/FHBkB/H0hzNGtT9QPcRnjLcn RJAL8YA5GBkrc7SJgBehsq5whQm/XhzbHkysofi105cn4Dyx0QItaqNkS7XBDp6xgOZD 5cSGF0+99mSZYcQn2h+5egqTXom6sbdTOjN24MdLD7XeU/b0sMJhk+5NA73axlXu/m4G p+fT8b6+ayffjhsIzOEJQWNef6NTU2MhbCjVRK3ZnLhUMydQdrH4z+WzZ2BPQOVgICpq AZAE/NZeb1JT4ynXuMOVQt6gJ0hVAfZr+k3VacnDNxWPODZvbWbjMqRyDxam/BUr0JsW IPRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=SjWuOTsG; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c28si6698082ede.3.2019.10.11.12.17.42; Fri, 11 Oct 2019 12:18:06 -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=@google.com header.s=20161025 header.b=SjWuOTsG; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728985AbfJKTPe (ORCPT + 99 others); Fri, 11 Oct 2019 15:15:34 -0400 Received: from mail-pg1-f202.google.com ([209.85.215.202]:44686 "EHLO mail-pg1-f202.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728977AbfJKTPd (ORCPT ); Fri, 11 Oct 2019 15:15:33 -0400 Received: by mail-pg1-f202.google.com with SMTP id z7so7624962pgk.11 for ; Fri, 11 Oct 2019 12:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=wwUIXG8zaTQahpGiWbKYxnh72iiHnCVZCniLVYgkymY=; b=SjWuOTsGX96zO37k1lrS0YGrpMuH9atVN00vNP8ziHSqCn5t4dh1R8CJorCFIjPdkg WEWKUOZPjx8vnNqtI6YQDXKsRyBAVvql3hBRri2FhH+wJ0084Fb4JXe0niwBFfhvnYmx PRw9piDFj/NQVRK8uguTgpNyFy1hd0f2bGlygLYPWJqEI/bfEIsGC7vIwGn4XrC154Cf CFNI4CQ1F5Bg649N5plNnllxLyf1xvpsBPAYffUiDd8QbDT+JZf0MTjcec0yP+Yh1ELW n845mj7mpnjt67qWFGOA8qyslxjBTS35v/vcpCBs0h0+KtkSBPxWDP/L07tiwi84Xc/Z 2r0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=wwUIXG8zaTQahpGiWbKYxnh72iiHnCVZCniLVYgkymY=; b=saF+mkHT0frBkwbC0ibeCuedPiLnbDuwt+zL8wFbFJC3PtrNoGt9shfc0l5CwAjhja xiu7KpNB8KaVr5t2DswEjb3zaZujUlYbz0ziKZTw4x1SWtBKCE8FKspPB1BpdiVN883c UqwgxcJaPVrT80JcwslDWxlcZSVIhXP5DoTjd/EXwiVEKBM1HS0Yy3+RB9U6Q/+0RjGn PQgASrGHUqu2m+2SSBjEScQW0jqQWfL0uyarAfym1bhkSw/aIOVRBAu18AUyhH6ZCMlx e1lNAy2q5ny2qXplXnDUfrlsWhNct4hMVq7n0rlDPjWgHG3LS1SIh5p4SQXipH3UJMoX 8Xcw== X-Gm-Message-State: APjAAAWdWTDiGZBCwmobLIsvogEQskl0yKjcPEuoOxJXzXu00ETe8cS9 32LAZ74lo5/HuAug0prG4RmiYgLMI7E5/z0= X-Received: by 2002:a63:6a46:: with SMTP id f67mr17738001pgc.87.1570821332209; Fri, 11 Oct 2019 12:15:32 -0700 (PDT) Date: Fri, 11 Oct 2019 12:15:20 -0700 In-Reply-To: <20191011191521.179614-1-saravanak@google.com> Message-Id: <20191011191521.179614-3-saravanak@google.com> Mime-Version: 1.0 References: <20191011191521.179614-1-saravanak@google.com> X-Mailer: git-send-email 2.23.0.700.g56cf767bdb-goog Subject: [PATCH v1 2/3] driver: core: Improve documentation for fwnode_operations.add_links() From: Saravana Kannan To: Jonathan Corbet , Rob Herring , Frank Rowand , "Rafael J. Wysocki" , Len Brown , Greg Kroah-Hartman Cc: Saravana Kannan , Stephen Boyd , kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org 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 The add_links() ops shouldn't return on the first failed device link add. It needs to continue trying to add device links to other suppliers that are available. The documentation didn't explain WHY this behavior is necessary. So, update the documentation with an example that explains why this is necessary. Signed-off-by: Saravana Kannan --- include/linux/fwnode.h | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h index 6ae05b9ce359..97223e2410bd 100644 --- a/include/linux/fwnode.h +++ b/include/linux/fwnode.h @@ -71,8 +71,25 @@ struct fwnode_reference_args { * links to all the suppliers of the device that are available at * the time this function is called. The function must NOT stop * at the first failed device link if other unlinked supplier - * devices are present in the system. If some suppliers are not - * yet available, this function will be called again when other + * devices are present in the system. This is necessary for the + * driver/bus sync_state() callbacks to work correctly. + * + * For example, say Device-C depends on suppliers Device-S1 and + * Device-S2 and the dependency is listed in that order in the + * firmware. Say, S1 gets populated from the firmware after + * late_initcall_sync(). Say S2 is populated and probed way + * before that in device_initcall(). When C is populated, if this + * add_links() function doesn't continue past a "failed linking to + * S1" and continue linking C to S2, then S2 will get a + * sync_state() callback before C is probed. This is because from + * the perspective of S2, C was never a consumer when its + * sync_state() evaluation is done. To avoid this, the add_links() + * function has to go through all available suppliers of the + * device (that corresponds to this fwnode) and link to them + * before returning. + * + * If some suppliers are not yet available (indicated by an error + * return value), this function will be called again when other * devices are added to allow creating device links to any newly * available suppliers. * -- 2.23.0.700.g56cf767bdb-goog