devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Rob Herring <robh@kernel.org>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	"mika.westerberg@linux.intel.com"
	<mika.westerberg@linux.intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mark Brown <broonie@kernel.org>, Al Stone <ahs3@redhat.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>
Subject: Re: [PATCH v7 2/6] device property: Move FW type specific functionality to FW specific files
Date: Mon, 12 Jun 2017 16:53:11 +0300	[thread overview]
Message-ID: <c3a10325-05a0-b383-0140-09962ea6cced@linux.intel.com> (raw)
In-Reply-To: <CAL_JsqKqW42pTOsw=1iTrCyHgF5E0WZqBC0k9QwVQ2uW5RFutA@mail.gmail.com>

Hi Rob,

Rob Herring wrote:
> On Tue, Jun 6, 2017 at 4:37 AM, Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
>> The device and fwnode property API supports Devicetree, ACPI and pset
>> properties. The implementation of this functionality for each firmware
>> type was embedded in the fwnode property core. Move it out to firmware
>> type specific locations, making it easier to maintain.
>>
>> Depends-on: ("of: Move OF property and graph API from base.c to property.c")
>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>> ---
>>  drivers/acpi/property.c |  68 ++++++++++++++++
>>  drivers/acpi/scan.c     |   1 +
>>  drivers/base/property.c | 208 +++++++++++++++++++-----------------------------
>>  drivers/of/property.c   |  90 +++++++++++++++++++++
>>  include/linux/acpi.h    |   4 +
>>  include/linux/fwnode.h  |  54 +++++++++++++
>>  include/linux/of.h      |   2 +
>>  7 files changed, 302 insertions(+), 125 deletions(-)
>>
>> diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
>> index 9364398..14013f6 100644
>> --- a/drivers/acpi/property.c
>> +++ b/drivers/acpi/property.c
>> @@ -57,6 +57,7 @@ static bool acpi_nondev_subnode_extract(const union acpi_object *desc,
>>
>>         dn->name = link->package.elements[0].string.pointer;
>>         dn->fwnode.type = FWNODE_ACPI_DATA;
>> +       dn->fwnode.ops = &acpi_fwnode_ops;
>
> Mainly in interest of not growing fwnode_handle, we could remove .type
> and just have checks like "ops == &acpi_fwnode_ops".
>
> Otherwise, for patches 2,3,4:
>
> Acked-by: Rob Herring <robh@kernel.org>

Thanks for the ack!

The ops field is currently not unique for all types of fwnodes:

type			ops
---------------------------------------
FWNODE_ACPI_STATIC	acpi_fwnode_ops
FWNODE_ACPI_DATA	acpi_fwnode_ops
FWNODE_ACPI		acpi_fwnode_ops
FWNODE_OF		of_fwnode_ops
FWNODE_PSET		pset_fwnode_ops
FWNODE_IRQCHIP		NULL

We could define three more ops for fwnodes (ACPI_STATIC, ACPI_DATA and 
IRQCHIP). I presume the effect on the total memory consumption is still 
a positive one. Especially it does not increase as much with the number 
of fwnodes.

I have a patch but I'll test it still a little before submitting it.

-- 
Kind regards,

Sakari Ailus
sakari.ailus@linux.intel.com

  reply	other threads:[~2017-06-12 13:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-06  9:37 [PATCH v7 0/6] Move firmware specific code to firmware specific locations Sakari Ailus
2017-06-06  9:37 ` [PATCH v7 1/6] ACPI: Constify argument to acpi_device_is_present() Sakari Ailus
     [not found] ` <1496741861-8240-1-git-send-email-sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-06  9:37   ` [PATCH v7 2/6] device property: Move FW type specific functionality to FW specific files Sakari Ailus
2017-06-09 20:21     ` Rob Herring
2017-06-12 13:53       ` Sakari Ailus [this message]
2017-06-06  9:37 ` [PATCH v7 3/6] device property: Move fwnode graph ops to firmware specific locations Sakari Ailus
2017-06-06  9:37 ` [PATCH v7 4/6] device property: Introduce fwnode_device_is_available() Sakari Ailus
2017-06-06  9:37 ` [PATCH v7 5/6] device property: Add FW type agnostic fwnode_graph_get_remote_node Sakari Ailus
2017-06-06  9:37 ` [PATCH v7 6/6] device property: Add fwnode_graph_get_port_parent Sakari Ailus
2017-06-13 11:49 ` [PATCH v7.1 7/7] device property: Get rid of struct fwnode_handle type field Sakari Ailus
2017-06-18  6:58   ` Mika Westerberg
2017-06-20  8:51     ` Sakari Ailus
2017-06-20  8:49   ` [PATCH v7.2 " Sakari Ailus
2017-06-20 12:03     ` Mika Westerberg
2017-06-20 14:14     ` Lorenzo Pieralisi
2017-06-22  0:57       ` Rafael J. Wysocki
2017-06-22 10:29       ` Sakari Ailus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3a10325-05a0-b383-0140-09962ea6cced@linux.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=ahs3@redhat.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).