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,URIBL_BLOCKED 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 2A1F9C433E0 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 DE81223120 for ; Tue, 12 Jan 2021 18:03:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729128AbhALSDd (ORCPT ); Tue, 12 Jan 2021 13:03:33 -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-acpi@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 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, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 C8AB1C433E0 for ; Tue, 12 Jan 2021 18:04:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 734E622DFA for ; Tue, 12 Jan 2021 18:04:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 734E622DFA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1sPK1V4aeSazVxsrfVNOtU+eLYobSRmmY1Og6q4HwVY=; b=l/hCMMci/czeQ9mOkEI4wc2+h 96srMRCdknzjVT/A9ckrhwH7dzqEU49iZUzvvkRHoBPOIK8MnUcHB3RdHN6Kw7DoyJSz6PP0dq/wN IEaDWQeaBDf26gMZKpSjDewTQrA5df0iYmQaXyY1Fyo1Cb0zedOFJqLGl/VqTqohXPgcROyvqtwrZ YJmSrmd4ipxu3Ic7rLJvixUIvSrq/zZjLx/lsQd87lHX0rr3dgsh6p2Z+e+aIr+p+sREub7FBDwWF 8BUoTHAV6It7vce9XZcWQLEQ6pFAxXaOGHp7QO6zXT2x4olRLER3Qvi7IH62LfBjYL5d+G8v1r2Yf aLoOoOScQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kzO0P-0007VG-G3; Tue, 12 Jan 2021 18:02:57 +0000 Received: from mga09.intel.com ([134.134.136.24]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kzO0M-0007U1-Ax for linux-arm-kernel@lists.infradead.org; Tue, 12 Jan 2021 18:02:55 +0000 IronPort-SDR: OEFDKcpLBDDZNd7f9E4kJYlhu98n7M0myp2q2g0eiUQ/NMpM5F0MyEy8QNU5JUuJdmvlc2QRH+ EfV+TJCb1B7g== X-IronPort-AV: E=McAfee;i="6000,8403,9862"; a="178232701" X-IronPort-AV: E=Sophos;i="5.79,342,1602572400"; d="scan'208";a="178232701" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 10:02:52 -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 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-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210112_130254_578933_416BA5A6 X-CRM114-Status: GOOD ( 21.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Heikki Krogerus , "Rafael J . Wysocki" , Grant Likely , Calvin Johnson , Ioana Ciornei , Florian Fainelli , Bartosz Golaszewski , Jon , Russell King - ARM Linux admin , Diana Madalina Craciun , ACPI Devel Maling List , Florin Laurentiu Chiculita , Madalin Bucur , Pieter Jansen Van Vuuren , Laurent Pinchart , Marcin Wojtas , linux-arm-kernel , Laurentiu Tudor , netdev@vger.kernel.org, Randy Dunlap , LKML , Jeremy Linton , Cristi Sovaiala , linux.cj@gmail.com, Greg Kroah-Hartman Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel