Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp630645pxu; Fri, 23 Oct 2020 09:21:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMi3+EY+etDB+DDwunzWvvNUw+n/EzO8sNvFi0Yf0k2ArkwBIZTD8JQVkpBckYUPFEEL9K X-Received: by 2002:a05:6402:c6:: with SMTP id i6mr2971976edu.363.1603470086970; Fri, 23 Oct 2020 09:21:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603470086; cv=none; d=google.com; s=arc-20160816; b=gRDQbeOG+MomSDuSRBCkHtZ61jPhIbjoaCYwwGhBFuvkUkCUkbHrH+WY3yExsygx2f GvQG8ySooRk9U3PFBH6+NjxPNsaSvtgBmgkJFRk/x1OAczbrUQ9fGrwdE8yzn3n9MiTa 4TexVP4OPSpq4gGinGgmRbonsus4NG9wgz+wPOpai43au8lnRA9mq0cIgGmog/euAU9g I16TLwJSEyBeTQ2QumAHz7Fz9d+xBRtHKOeWYRiK40JVVEhyovEgRb+LnyHazLXCbGXw u5GBDWgYgrrcG5fzxylimNGsnv0VEqav2ZyjVHm9BEfmzAiP288TGLDMUh5D6B4jVQNY mTRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:subject:from; bh=pHcXzxAd5ciyVmgm5+8IfkSlsuSPtwZbYnxs8/Fo8k4=; b=RwCnJ8Iv6GTsFOC0ny/bSLciLX1vbqCHGZc+m+ToWVnnfnDMk2PCEVGRnfXmYmomTI orKcQ+Y5e7WLqOWoeGr6hwZwBbfs+fiUxfLDyMFvQQtLII3YExt+/Okec541lhUWcL1A 20MV7l/TGMgZS7chy1pDDg0kFiUEvEOR3erGjVsCd9mrQaLSn4I0CRhhWYpkfdffmaTH Q/ee/lk8nfB6/Ti06TCHxcEYTQnib4nnQz1tMreaZL+ziDPlqqJ3dIVCjDhTNibQExEx bfNhDO3e7D9tJOFU7mfTefl6oDBxsfxzrRdgrEEBKt7Wut7LxJHQoGXMR1bRC5DggXMF L1cw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o24si1079623edr.567.2020.10.23.09.21.03; Fri, 23 Oct 2020 09:21:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750397AbgJWOQY (ORCPT + 99 others); Fri, 23 Oct 2020 10:16:24 -0400 Received: from smtp.radex.nl ([178.250.146.7]:59095 "EHLO radex-web.radex.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750392AbgJWOQY (ORCPT ); Fri, 23 Oct 2020 10:16:24 -0400 Received: from [192.168.1.158] (cust-178-250-146-69.breedbanddelft.nl [178.250.146.69]) by radex-web.radex.nl (Postfix) with ESMTPS id C172724065; Fri, 23 Oct 2020 16:16:21 +0200 (CEST) From: Ferry Toth Subject: Re: [PATCH v1 1/2] device property: Keep secondary firmware node secondary by type To: Heikki Krogerus , Andy Shevchenko Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Saravana Kannan , linux-acpi@vger.kernel.org, "Rafael J. Wysocki" References: <20201022184100.71659-1-andriy.shevchenko@linux.intel.com> <20201023123412.GA614478@kuha.fi.intel.com> Message-ID: Date: Fri, 23 Oct 2020 16:16:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201023123412.GA614478@kuha.fi.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Op 23-10-2020 om 14:34 schreef Heikki Krogerus: > On Thu, Oct 22, 2020 at 09:40:59PM +0300, Andy Shevchenko wrote: >> Behind primary and secondary we understand the type of the nodes >> which might define their ordering. However, if primary node gone, >> we can't maintain the ordering by definition of the linked list. >> Thus, by ordering secondary node becomes first in the list. >> But in this case the meaning of it is still secondary (or auxiliary). >> The type of the node is maintained by the secondary pointer in it: >> >> secondary pointer Meaning >> NULL or valid primary node >> ERR_PTR(-ENODEV) secondary node >> >> So, if by some reason we do the following sequence of calls >> >> set_primary_fwnode(dev, NULL); >> set_primary_fwnode(dev, primary); >> >> we should preserve secondary node. >> >> This concept is supported by the description of set_primary_fwnode() >> along with implementation of set_secondary_fwnode(). Hence, fix >> the commit c15e1bdda436 to follow this as well. >> >> Fixes: c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") >> Cc: Ferry Toth >> Signed-off-by: Andy Shevchenko > FWIW: > > Reviewed-by: Heikki Krogerus > Tested-by: Ferry Toth >> --- >> drivers/base/core.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/base/core.c b/drivers/base/core.c >> index c852f16c111b..41feab679fa1 100644 >> --- a/drivers/base/core.c >> +++ b/drivers/base/core.c >> @@ -4278,7 +4278,7 @@ void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode) >> } else { >> if (fwnode_is_primary(fn)) { >> dev->fwnode = fn->secondary; >> - fn->secondary = NULL; >> + fn->secondary = ERR_PTR(-ENODEV); >> } else { >> dev->fwnode = NULL; >> } >> -- >> 2.28.0