[{"id":1769417,"web_url":"http://patchwork.ozlabs.org/comment/1769417/","msgid":"<CAL_JsqKZVN+X0F3Z8s6Qv+ioh8LBDjNe277MAw30T3CXXTUV1Q@mail.gmail.com>","list_archive_url":null,"date":"2017-09-15T19:57:35","subject":"Re: [RFC 0/5] Align and document return values of phandle and\n\treference parsing for OF and ACPI","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Thu, Sep 14, 2017 at 7:29 AM, Sakari Ailus\n<sakari.ailus@linux.intel.com> wrote:\n> Hi everyone,\n>\n> I recently came across a difference in behaviour of OF phandle parsing and\n> ACPI reference parsing, both of which can soon be accessed using\n> fwnode_property_get_reference_args.\n>\n> The main change in this proposal touches OF, and specifically the change\n> is about using -ENODATA to tell that the phandle reference list entry that\n> was accessed does not exist. -ENOENT was used previously, but the same\n> error code was also used to tell that a phandle was empty, making it\n> impossible for the caller to figure out which of the two was the case.\n>\n> I'm sending the set as RFC. In my limited testing I have found no ill\n> effects.\n>\n> These patches are on top of linux-next.\n>\n> Comments on the approach and the changes themselves would be most welcome.\n\nIt's not really valid to both have a variable count (and hence need to\nretrieve it) and use blank phandle entries. The whole point of blank\nentries is to have a fixed length and know what each index corresponds\ntoo. Do you have an example where we hit this?\n\nRob\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at  http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"<devicetree-owner@vger.kernel.org>","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=<UNKNOWN>)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=robh@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xv5mR1xqGz9s7g\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tSat, 16 Sep 2017 05:57:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751594AbdIOT55 (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tFri, 15 Sep 2017 15:57:57 -0400","from mail.kernel.org ([198.145.29.99]:55234 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751584AbdIOT55 (ORCPT <rfc822;devicetree@vger.kernel.org>);\n\tFri, 15 Sep 2017 15:57:57 -0400","from mail-qk0-f180.google.com (mail-qk0-f180.google.com\n\t[209.85.220.180])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 9898822A73;\n\tFri, 15 Sep 2017 19:57:56 +0000 (UTC)","by mail-qk0-f180.google.com with SMTP id j5so3046298qkd.0;\n\tFri, 15 Sep 2017 12:57:56 -0700 (PDT)","by 10.12.209.75 with HTTP; Fri, 15 Sep 2017 12:57:35 -0700 (PDT)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 9898822A73","X-Gm-Message-State":"AHPjjUin5UhlbQ1xejcIBIlTHaLvQBtXc5sUcqa07VH3C4kGYmkjRhzb\n\tpBqbCfUgDGxn8xOzJnSWWtgJ8RB/75grgKfwVw==","X-Google-Smtp-Source":"AOwi7QANHyd6Zg7km+5BMPRAjI54E+YEhOtmWzFgWAdhQYk/bNBQe+Q/kKO1b90Z0vniUFGP9cr9yf+0zilNO8sEW38=","X-Received":"by 10.55.17.73 with SMTP id b70mr9285789qkh.270.1505505475747;\n\tFri, 15 Sep 2017 12:57:55 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170914122914.14122-1-sakari.ailus@linux.intel.com>","References":"<20170914122914.14122-1-sakari.ailus@linux.intel.com>","From":"Rob Herring <robh@kernel.org>","Date":"Fri, 15 Sep 2017 14:57:35 -0500","X-Gmail-Original-Message-ID":"<CAL_JsqKZVN+X0F3Z8s6Qv+ioh8LBDjNe277MAw30T3CXXTUV1Q@mail.gmail.com>","Message-ID":"<CAL_JsqKZVN+X0F3Z8s6Qv+ioh8LBDjNe277MAw30T3CXXTUV1Q@mail.gmail.com>","Subject":"Re: [RFC 0/5] Align and document return values of phandle and\n\treference parsing for OF and ACPI","To":"Sakari Ailus <sakari.ailus@linux.intel.com>","Cc":"\"devicetree@vger.kernel.org\" <devicetree@vger.kernel.org>,\n\t\"linux-acpi@vger.kernel.org\" <linux-acpi@vger.kernel.org>,\n\t\"Rafael J. Wysocki\" <rafael@kernel.org>,\n\t\"mika.westerberg@linux.intel.com\" <mika.westerberg@linux.intel.com>, \n\tFrank Rowand <frowand.list@gmail.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1771443,"web_url":"http://patchwork.ozlabs.org/comment/1771443/","msgid":"<20170919230125.l7fexsdrzbmwd6yp@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-19T23:01:25","subject":"Re: [RFC 0/5] Align and document return values of phandle and\n\treference parsing for OF and ACPI","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"Hi Rob,\n\nThanks for the review.\n\nOn Fri, Sep 15, 2017 at 02:57:35PM -0500, Rob Herring wrote:\n> On Thu, Sep 14, 2017 at 7:29 AM, Sakari Ailus\n> <sakari.ailus@linux.intel.com> wrote:\n> > Hi everyone,\n> >\n> > I recently came across a difference in behaviour of OF phandle parsing and\n> > ACPI reference parsing, both of which can soon be accessed using\n> > fwnode_property_get_reference_args.\n> >\n> > The main change in this proposal touches OF, and specifically the change\n> > is about using -ENODATA to tell that the phandle reference list entry that\n> > was accessed does not exist. -ENOENT was used previously, but the same\n> > error code was also used to tell that a phandle was empty, making it\n> > impossible for the caller to figure out which of the two was the case.\n> >\n> > I'm sending the set as RFC. In my limited testing I have found no ill\n> > effects.\n> >\n> > These patches are on top of linux-next.\n> >\n> > Comments on the approach and the changes themselves would be most welcome.\n> \n> It's not really valid to both have a variable count (and hence need to\n> retrieve it) and use blank phandle entries. The whole point of blank\n> entries is to have a fixed length and know what each index corresponds\n> too. Do you have an example where we hit this?\n\nWell, the above is true. I think I'd still use different error codes to\ntell about different situations.\n\nThe alternative is that the fwnode counterpart error codes are changed to\nto -ENOENT.","headers":{"Return-Path":"<devicetree-owner@vger.kernel.org>","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxdfK7007z9sPr\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tWed, 20 Sep 2017 09:01:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751597AbdISXB2 (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tTue, 19 Sep 2017 19:01:28 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:39818 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751575AbdISXB1 (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Tue, 19 Sep 2017 19:01:27 -0400","from valkosipuli.localdomain (valkosipuli.retiisi.org.uk\n\t[IPv6:2001:1bc8:1a6:d3d5::80:2])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id 0A8446010C;\n\tWed, 20 Sep 2017 02:01:26 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from <sakke@valkosipuli.retiisi.org.uk>)\n\tid 1duRW9-0005FH-Kz; Wed, 20 Sep 2017 02:01:25 +0300"],"Date":"Wed, 20 Sep 2017 02:01:25 +0300","From":"Sakari Ailus <sakari.ailus@iki.fi>","To":"Rob Herring <robh@kernel.org>","Cc":"Sakari Ailus <sakari.ailus@linux.intel.com>,\n\t\"devicetree@vger.kernel.org\" <devicetree@vger.kernel.org>,\n\t\"linux-acpi@vger.kernel.org\" <linux-acpi@vger.kernel.org>,\n\t\"Rafael J. Wysocki\" <rafael@kernel.org>,\n\t\"mika.westerberg@linux.intel.com\" <mika.westerberg@linux.intel.com>, \n\tFrank Rowand <frowand.list@gmail.com>","Subject":"Re: [RFC 0/5] Align and document return values of phandle and\n\treference parsing for OF and ACPI","Message-ID":"<20170919230125.l7fexsdrzbmwd6yp@valkosipuli.retiisi.org.uk>","References":"<20170914122914.14122-1-sakari.ailus@linux.intel.com>\n\t<CAL_JsqKZVN+X0F3Z8s6Qv+ioh8LBDjNe277MAw30T3CXXTUV1Q@mail.gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<CAL_JsqKZVN+X0F3Z8s6Qv+ioh8LBDjNe277MAw30T3CXXTUV1Q@mail.gmail.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1775286,"web_url":"http://patchwork.ozlabs.org/comment/1775286/","msgid":"<20170926090201.wcpv4fty5yi5ea6z@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-26T09:02:01","subject":"Re: [RFC 0/5] Align and document return values of phandle and\n\treference parsing for OF and ACPI","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"On Wed, Sep 20, 2017 at 02:01:25AM +0300, Sakari Ailus wrote:\n> Hi Rob,\n> \n> Thanks for the review.\n> \n> On Fri, Sep 15, 2017 at 02:57:35PM -0500, Rob Herring wrote:\n> > On Thu, Sep 14, 2017 at 7:29 AM, Sakari Ailus\n> > <sakari.ailus@linux.intel.com> wrote:\n> > > Hi everyone,\n> > >\n> > > I recently came across a difference in behaviour of OF phandle parsing and\n> > > ACPI reference parsing, both of which can soon be accessed using\n> > > fwnode_property_get_reference_args.\n> > >\n> > > The main change in this proposal touches OF, and specifically the change\n> > > is about using -ENODATA to tell that the phandle reference list entry that\n> > > was accessed does not exist. -ENOENT was used previously, but the same\n> > > error code was also used to tell that a phandle was empty, making it\n> > > impossible for the caller to figure out which of the two was the case.\n> > >\n> > > I'm sending the set as RFC. In my limited testing I have found no ill\n> > > effects.\n> > >\n> > > These patches are on top of linux-next.\n> > >\n> > > Comments on the approach and the changes themselves would be most welcome.\n> > \n> > It's not really valid to both have a variable count (and hence need to\n> > retrieve it) and use blank phandle entries. The whole point of blank\n> > entries is to have a fixed length and know what each index corresponds\n> > too. Do you have an example where we hit this?\n> \n> Well, the above is true. I think I'd still use different error codes to\n> tell about different situations.\n> \n> The alternative is that the fwnode counterpart error codes are changed to\n> to -ENOENT.\n\nI'll post a patch implemeting switching the fwnode variant to use -ENOENT,\ncc'ing you. I think the first patch of the set is still relevant, it's\nrather a bugfix.","headers":{"Return-Path":"<devicetree-owner@vger.kernel.org>","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1Zhd1S7vz9t49\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tTue, 26 Sep 2017 19:02:09 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754068AbdIZJCH (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tTue, 26 Sep 2017 05:02:07 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:55902 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751840AbdIZJCF (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Tue, 26 Sep 2017 05:02:05 -0400","from valkosipuli.localdomain (valkosipuli.retiisi.org.uk\n\t[IPv6:2001:1bc8:1a6:d3d5::80:2])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id E07AE600EF;\n\tTue, 26 Sep 2017 12:02:02 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from <sakke@valkosipuli.retiisi.org.uk>)\n\tid 1dwlkg-0007EV-8g; Tue, 26 Sep 2017 12:02:02 +0300"],"Date":"Tue, 26 Sep 2017 12:02:01 +0300","From":"Sakari Ailus <sakari.ailus@iki.fi>","To":"Rob Herring <robh@kernel.org>","Cc":"Sakari Ailus <sakari.ailus@linux.intel.com>,\n\t\"devicetree@vger.kernel.org\" <devicetree@vger.kernel.org>,\n\t\"linux-acpi@vger.kernel.org\" <linux-acpi@vger.kernel.org>,\n\t\"Rafael J. Wysocki\" <rafael@kernel.org>,\n\t\"mika.westerberg@linux.intel.com\" <mika.westerberg@linux.intel.com>, \n\tFrank Rowand <frowand.list@gmail.com>","Subject":"Re: [RFC 0/5] Align and document return values of phandle and\n\treference parsing for OF and ACPI","Message-ID":"<20170926090201.wcpv4fty5yi5ea6z@valkosipuli.retiisi.org.uk>","References":"<20170914122914.14122-1-sakari.ailus@linux.intel.com>\n\t<CAL_JsqKZVN+X0F3Z8s6Qv+ioh8LBDjNe277MAw30T3CXXTUV1Q@mail.gmail.com>\n\t<20170919230125.l7fexsdrzbmwd6yp@valkosipuli.retiisi.org.uk>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170919230125.l7fexsdrzbmwd6yp@valkosipuli.retiisi.org.uk>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}}]