Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp209523imu; Wed, 7 Nov 2018 15:49:15 -0800 (PST) X-Google-Smtp-Source: AJdET5ctzWwpU0zhuNtQyjIdm96zvfwkneiTdP6R76WH2qOryowq7uxn5So6KG1XHFSmG8HX56oM X-Received: by 2002:a63:3287:: with SMTP id y129mr1984896pgy.337.1541634554949; Wed, 07 Nov 2018 15:49:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541634554; cv=none; d=google.com; s=arc-20160816; b=idzKg6oiywabMnUMY+rr7Qa/t6WFXuOQyxfoKSsz3m/Dg+1mFyN/IkcGhNqaNP7gWG z5KjjLfrup9xUpiK7Jq7Ad6EmzU0fuPZf2JJZohPV7stZTKCuxkRHuN2vGTP6nTxdlV5 iBvHG2ClWTaAmGOuqL7DGCGMnWcl0M/Ova+9o6KeK1thVDGOoYjeU23mbGxjmS0V+G6F TWVGGBBz+Yl0LtnF3giEA/hmIOAs+lXHc8JVHogc157GwjtGKtmvaGtv0NpfooEqg86x DVQpCAeyjOp9UhR5LMWBXICmQaOfry7utV/CupzY0xzV5at3DDkuUIIxgl5cvv2IpZqo gnBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=3OS4WFngmv4Tw+TbrYI/ac9sqZ6bkUevtNVUQzByFpc=; b=gwJRVcODDd7YpOOHqMG2da6Grbf9vGUqsYxnBtA7hYpnMeUj3J/BuApRGWBANKZEaR XnwfOsWNnm1fIrv9l5mz97Xgv1isd6g8eO2lnq45NnUju/xf67nQsam0fT8EEloFBkH0 7xAHVV9bQGsYlLMvL4K136f59D5xaPa9gZKx/PgE/ytQXTIwRU8+5fa51MpN1ZdzPpVc MuSUVTrM4kHjCjbarODBf4zHlEmMooqDVdPce9QxIyo9bEA/JKVL0L7XIVp8Ii/KnQNw TeLBhUHgN9s1564YJhc0XPLp8DDwOTmXHg5vyRYpnlWksmJRCi9EeUv2ylXpVOjgQuuQ amEA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s26-v6si1889737pgl.584.2018.11.07.15.48.58; Wed, 07 Nov 2018 15:49:14 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727861AbeKHJVV (ORCPT + 99 others); Thu, 8 Nov 2018 04:21:21 -0500 Received: from ozlabs.org ([203.11.71.1]:37023 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726191AbeKHJVV (ORCPT ); Thu, 8 Nov 2018 04:21:21 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 42r35Y1Ttbz9s9G; Thu, 8 Nov 2018 10:48:33 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Frank Rowand , Rob Herring , Pantelis Antoniou , Benjamin Herrenschmidt , Paul Mackerras , Alan Tull , Moritz Fischer Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, devicetree@vger.kernel.org, linux-fpga@vger.kernel.org, nfont@linux.vnet.ibm.com, Tyrel Datwyler Subject: Re: [PATCH v6 07/18] of: dynamic: change type of of_{at,de}tach_node() to void In-Reply-To: <6bc78502-7587-eb9c-237f-d3f031979d42@gmail.com> References: <1541431515-25197-1-git-send-email-frowand.list@gmail.com> <1541431515-25197-8-git-send-email-frowand.list@gmail.com> <87tvktqedf.fsf@concordia.ellerman.id.au> <6bc78502-7587-eb9c-237f-d3f031979d42@gmail.com> Date: Thu, 08 Nov 2018 10:48:33 +1100 Message-ID: <87h8gsqwj2.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Frank Rowand writes: > On 11/7/18 4:08 AM, Michael Ellerman wrote: >> frowand.list@gmail.com writes: >> >>> From: Frank Rowand >>> >>> of_attach_node() and of_detach_node() always return zero, so >>> their return value is meaningless. >> >> But should they always return zero? >> >> At least __of_attach_node_sysfs() can fail in several ways. > > Sigh. And of_reconfig_notify() can fail. And at one point in the > history the return value of of_reconfig_notify() was returned by > of_attach_node() if of_reconfig_notify() failed. > >> And there's also this in __of_detach_node() which should probably be >> returning an error: >> >> if (WARN_ON(of_node_check_flag(np, OF_DETACHED))) >> return; >> >> >> Seems to me we should instead be fixing these to propagate errors, >> rather than hiding them? > > The history of how of_attach_node() stopped propagating errors is > a bit more complex than I want to dig into at the moment. So I'll > drop this patch from the series and add investigating this onto > my todo list. I suspect that the result of investigating will be > that error return values should not be ignored in of_attach_node() > and of_detach_node(), but should instead be propagated to the > callers, as you suggest. Thanks. cheers