From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FE89C433DB for ; Tue, 12 Jan 2021 18:03:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B55A423117 for ; Tue, 12 Jan 2021 18:03:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405446AbhALSDe (ORCPT ); Tue, 12 Jan 2021 13:03:34 -0500 Received: from mga11.intel.com ([192.55.52.93]:8871 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727622AbhALSDd (ORCPT ); Tue, 12 Jan 2021 13:03:33 -0500 IronPort-SDR: /y30fUKi3fy0PsP2L6ib52cAaLwmhepf9j/3kGS0lU2T9cnRGtSV6RHKJGu2EJnnBkwftkJkYH w1Xr2Cvs+MQQ== X-IronPort-AV: E=McAfee;i="6000,8403,9862"; a="174575798" X-IronPort-AV: E=Sophos;i="5.79,342,1602572400"; d="scan'208";a="174575798" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 10:02:50 -0800 IronPort-SDR: IghNfaeOKkLonEtFV3SlDC2GPc2G7LVoov8V38TT6EAGjGeBDykr49C+0uZnWOi1b/HJT0NDd6 FpQAlxctiuGQ== X-IronPort-AV: E=Sophos;i="5.79,342,1602572400"; d="scan'208";a="404557273" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 10:02:42 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1kzO19-00C00S-FU; Tue, 12 Jan 2021 20:03:43 +0200 Date: Tue, 12 Jan 2021 20:03:43 +0200 From: Andy Shevchenko To: Saravana Kannan Cc: Calvin Johnson , Grant Likely , "Rafael J . Wysocki" , Jeremy Linton , Andrew Lunn , 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 , Diana Madalina Craciun , LKML , netdev@vger.kernel.org, Laurentiu Tudor , ACPI Devel Maling List , linux.cj@gmail.com, linux-arm-kernel , Bartosz Golaszewski , Greg Kroah-Hartman , Laurent Pinchart , Randy Dunlap Subject: Re: [net-next PATCH v3 09/15] device property: Introduce fwnode_get_id() Message-ID: <20210112180343.GI4077@smile.fi.intel.com> References: <20210112134054.342-1-calvin.johnson@oss.nxp.com> <20210112134054.342-10-calvin.johnson@oss.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2021 at 09:30:31AM -0800, Saravana Kannan wrote: > On Tue, Jan 12, 2021 at 5:42 AM Calvin Johnson > wrote: > > > > Using fwnode_get_id(), get the reg property value for DT node > > or get the _ADR object value for ACPI node. ... > > +/** > > + * fwnode_get_id - Get the id of a fwnode. > > + * @fwnode: firmware node > > + * @id: id of the fwnode > > + * > > + * This function provides the id of a fwnode which can be either > > + * DT or ACPI node. For ACPI, "reg" property value, if present will > > + * be provided or else _ADR value will be provided. > > + * Returns 0 on success or a negative errno. > > + */ > > +int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id) > > +{ > > +#ifdef CONFIG_ACPI > > + unsigned long long adr; > > + acpi_status status; > > +#endif > > + int ret; > > + > > + ret = fwnode_property_read_u32(fwnode, "reg", id); > > + if (!(ret && is_acpi_node(fwnode))) > > + return ret; > > + > > +#ifdef CONFIG_ACPI > > + status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode), > > + METHOD_NAME__ADR, NULL, &adr); > > + if (ACPI_FAILURE(status)) > > + return -EINVAL; > > + *id = (u32)adr; > > +#endif > > + return 0; > > +} > > +EXPORT_SYMBOL_GPL(fwnode_get_id); > Please don't do it this way. The whole point of fwnode_operations is > to avoid conditional stuff at the fwnode level. Not fully true. We have non-POD getters that are conditional. Moreover, we have additional layer of Primary / Secondary fwnodes on top of that. The caller of fwnode API is indeed agnostic, but under the hood it differs by the definition (obviously due to natural differences between ACPI and DT and whatever else might come in the future. > Also ACPI and DT > aren't mutually exclusive if I'm not mistaken. That's why we try 'reg' property for both cases first. is_acpi_fwnode() conditional is that what I don't like though. ... > fwnode is lower level that the device-driver framework. Agree. > Making > it aware of busses like mdio, etc doesn't sound right. Disagree. Conceptually resource providers can be quite different and fwnode API *is* LCM for them. -- With Best Regards, Andy Shevchenko