From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753965AbdDCPX2 (ORCPT ); Mon, 3 Apr 2017 11:23:28 -0400 Received: from mga07.intel.com ([134.134.136.100]:36293 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752377AbdDCPX1 (ORCPT ); Mon, 3 Apr 2017 11:23:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,270,1486454400"; d="scan'208";a="1114888595" Message-ID: <1491233004.708.112.camel@linux.intel.com> Subject: Re: [PATCH v1] reset: Make optional stuff optional for all users From: Andy Shevchenko To: Philipp Zabel Cc: "mika.westerberg@linux.intel.com" , "linux-kernel@vger.kernel.org" , "Ramiro.Oliveira@synopsys.com" Date: Mon, 03 Apr 2017 18:23:24 +0300 In-Reply-To: <1491232187.2378.90.camel@pengutronix.de> References: <20170403122638.88263-1-andriy.shevchenko@linux.intel.com> <1491229671.2378.73.camel@pengutronix.de> <1491229885.708.106.camel@linux.intel.com> <1491230017.708.108.camel@intel.com> <1491232187.2378.90.camel@pengutronix.de> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-04-03 at 17:09 +0200, Philipp Zabel wrote: > On Mon, 2017-04-03 at 14:33 +0000, Shevchenko, Andriy wrote: > > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote: > > > On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote: > > > > > > > > >   int rstc_id; > > > > >   int ret; > > > > >   > > > > > - if (!node) > > > > > - return ERR_PTR(-EINVAL); > > > > > - > > > > > > > > This should be > > > > > > > > if (!node) > > > > return optional ? NULL : ERR_PTR(-EINVAL); > > > > > > > > instead. Can you confirm this works for Intel boards with DW > > > > UART? I > > > > can > > > > fix it up when applying if you agree. > > > > > > I don't think it worth to change. I specifically checked all of_* > > > calls > > > in that function and they cope pretty nice with node == NULL. > > __of_reset_control_get called with id != NULL calls > of_property_match_string first, which then returns -EINVAL if > node == NULL, which makes __of_reset_control_get return NULL if > optional > or -ENOENT otherwise, even though the correct return value would be > -EINVAL in the DT case. Error handling mess as usual. :-) > > __of_reset_control_get called with id == NULL calls > of_parse_phandle_with_args first, which calls > __of_parse_phandle_with_args, which returns an undefined value if > np == NULL, as far as I can tell: > of_for_each_phandle first calls of_phandle_iterator_init, which, when > called with np == NULL clears the iterator structure returns -ENOENT. > The return value is ignored in the of_for_each_phandle macro, and > of_phandle_iterator_next is then called and returns -ENOENT because > it->cur == NULL, ending the loop without ever assigning a value to rc. > __of_parse_phandle_with_args then returns the uninitialized value. It returns -ENOENT. Error value is kept in function variable rc. > > The point being, instead of having to regularly forage through a > number > of of_ API functions to make sure my expectations are still met, I'd > prefer to keep the check in place. I would not insist, I already shared my view on this. I really don't like ping-ponging of the code. Perhaps you would fix it once for the best now? > > > > > > > So, I rather to go with my initial change. > > > > > > > Hit Enter before closing another thought. > > > > When you come with solution where this __of_reset_control_get() will > > be > > called only for node != NULL case you will not need that check > > either. > > __of_reset_control_get is public API (via of_reset_control_get), so I > can't guarantee node != NULL even in the DT case. Yes, and that's why other callees will return some error codes there. > > > So, I would go my solution because of two benefits: > > - it fixes bug > > True. > > > - if will not bring ping-ponging code > > Unfortunately not. Fortunately yes, if someone will fix DT error code mess in the first place. -- Andy Shevchenko Intel Finland Oy