Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3531855pxu; Tue, 15 Dec 2020 09:06:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJyQmxibmhdDUr93mLRWUxDZPJlTup2DiDKN8aFtPqcm2FJkP5pGGiYxbKdpekxxa3uYAMd2 X-Received: by 2002:a05:6402:1352:: with SMTP id y18mr30416970edw.178.1608052003456; Tue, 15 Dec 2020 09:06:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608052003; cv=none; d=google.com; s=arc-20160816; b=tufbfMSdlq/2D5iiThpoaLSJW/Sl64P4Eal1hkzcgSik/V89N7+eItZ009+3ylZkTw 5Te2TcSquBiu72znYOSQ/E3vj8tWFANo6AhYWM7wdm1t7WVsytj8sPOS/qPhwLb97+oI LoYS33C8VkNR8I0ZgnjrC2qXEu6zjbObLLcceqdPdP2or9B6DNz7SPMBGlsYAAa5SbcO 1yv7/XC5YD39v+V1s2yb2YS10DgB1/k8AZ8yiqdA35se0sL4/WM/a1qGkdNHsMFSMBVj QaTHrDOuywREQE6/VAj1pO8aOD7ArNBbRxxYo/CmIpzzA5PKOYmXxu3nYOcaY8Iq/hls dDHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Js1dzQCkoCyhrVt54h/xMDEDZv/rjcAb58pxbrb1ZP8=; b=yCRr0VCkhX1pVl2PR/peHv96O6TWTqrP8vLq+zyMcnnOp36SiHjVYcHZBehWDDznZc k6XxSNiT6fXyxVKYQ8YTT83vtC2VmWXrOoUSnE+8A9PLBJ+Y3xF1/pLccIwGsPSS2ecK 8BqQVYI3ewKiNyp5nL+yskjUchVJBylYChibLoKlmX5hvA0yQtaJu70/nlkQ7Oh4z7fy v9Xv4HT5+GRBvfph03fF4KwcmhtfvPo4zVOtuZyy9O6leEtCaZqx7+LQFakg3QVMNR55 4n0BsgmSyCfYsGVyD0Q1QiNr9oA0r/n8QVxgL8ERTYhjsEwHDNCw7gaMjTZoJ9iJESHx c/yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b="OMSTgwM/"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p1si1144563ejw.42.2020.12.15.09.06.19; Tue, 15 Dec 2020 09:06:43 -0800 (PST) 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; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b="OMSTgwM/"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730005AbgLORBf (ORCPT + 99 others); Tue, 15 Dec 2020 12:01:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729643AbgLORBU (ORCPT ); Tue, 15 Dec 2020 12:01:20 -0500 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CA11C0617B0; Tue, 15 Dec 2020 09:00:38 -0800 (PST) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id C3062593; Tue, 15 Dec 2020 18:00:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1608051634; bh=TnWF5kCi0eF700zzTEiikZPbUPvjXEDFeGtQD8p6IkQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OMSTgwM/XbekXmteZnkB9KD/8B7dnlyMuXKwrNL+xLTQLLaAk3HrAV1NQuvr8W3yB Jo5tVEVP/SuyeAJLcvhMPpbfsuEtWtAatOk+o73d9ZFEyE5iEzqL9tYtLONci9Jzrr eW2cmnQHN0tJ3SG1XbEQXProGOmNulSWzvxyQnFM= Date: Tue, 15 Dec 2020 19:00:28 +0200 From: Laurent Pinchart To: Calvin Johnson Cc: Grant Likely , "Rafael J . Wysocki" , Jeremy Linton , Andrew Lunn , Andy Shevchenko , Florian Fainelli , Russell King - ARM Linux admin , Cristi Sovaiala , Florin Laurentiu Chiculita , Ioana Ciornei , Madalin Bucur , Heikki Krogerus , Marcin Wojtas , Pieter Jansen Van Vuuren , Jon , linux.cj@gmail.com, Laurentiu Tudor , Diana Madalina Craciun , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, Andy Shevchenko , Bartosz Golaszewski , Greg Kroah-Hartman , Laurent Pinchart , Randy Dunlap Subject: Re: [net-next PATCH v2 10/14] device property: Introduce fwnode_get_id() Message-ID: References: <20201215164315.3666-1-calvin.johnson@oss.nxp.com> <20201215164315.3666-11-calvin.johnson@oss.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201215164315.3666-11-calvin.johnson@oss.nxp.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Calvin, Thank you for the patch. On Tue, Dec 15, 2020 at 10:13:11PM +0530, Calvin Johnson wrote: > Using fwnode_get_id(), get the reg property value for DT node > and get the _ADR object value for ACPI node. > > Signed-off-by: Calvin Johnson > --- > > Changes in v2: None > > drivers/base/property.c | 26 ++++++++++++++++++++++++++ > include/linux/property.h | 1 + > 2 files changed, 27 insertions(+) > > diff --git a/drivers/base/property.c b/drivers/base/property.c > index 4c43d30145c6..1c50e17ae879 100644 > --- a/drivers/base/property.c > +++ b/drivers/base/property.c > @@ -580,6 +580,32 @@ const char *fwnode_get_name_prefix(const struct fwnode_handle *fwnode) > return fwnode_call_ptr_op(fwnode, get_name_prefix); > } > > +/** > + * fwnode_get_id - Get the id of a fwnode. > + * @fwnode: firmware node > + * @id: id of the fwnode > + * Is the concept of fwnode ID documented clearly somewhere ? I think this function should otherwise have more documentation, at least to explain what the ID is. > + * Returns 0 on success or a negative errno. > + */ > +int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id) > +{ > + unsigned long long adr; > + acpi_status status; > + > + if (is_of_node(fwnode)) { > + return of_property_read_u32(to_of_node(fwnode), "reg", id); > + } else if (is_acpi_node(fwnode)) { > + status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode), > + METHOD_NAME__ADR, NULL, &adr); > + if (ACPI_FAILURE(status)) > + return -ENODATA; Would it make sense to standardize error codes ? of_property_read_u32() can return -EINVAL, -ENODATA or -EOVERFLOW. I don't think the caller of this function would be very interested to tell those three cases apart. Maybe we should return -EINVAL in all error cases ? Or maybe different error codes to mean "the backend doesn't support the concept of IDs", and "the device doesn't have an ID" ? > + *id = (u32)adr; > + return 0; > + } > + return -EINVAL; > +} > +EXPORT_SYMBOL_GPL(fwnode_get_id); > + > /** > * fwnode_get_parent - Return parent firwmare node > * @fwnode: Firmware whose parent is retrieved > diff --git a/include/linux/property.h b/include/linux/property.h > index 2d4542629d80..92d405cf2b07 100644 > --- a/include/linux/property.h > +++ b/include/linux/property.h > @@ -82,6 +82,7 @@ struct fwnode_handle *fwnode_find_reference(const struct fwnode_handle *fwnode, > > const char *fwnode_get_name(const struct fwnode_handle *fwnode); > const char *fwnode_get_name_prefix(const struct fwnode_handle *fwnode); > +int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id); > struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle *fwnode); > struct fwnode_handle *fwnode_get_next_parent( > struct fwnode_handle *fwnode); -- Regards, Laurent Pinchart