All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains
Date: Wed, 8 Jan 2014 08:14:52 +0000	[thread overview]
Message-ID: <20140108081452.GC19974@lee--X1> (raw)
In-Reply-To: <20140107195412.GC14405@codeaurora.org>

On Tue, 07 Jan 2014, Stephen Boyd wrote:

> On 01/07, Lee Jones wrote:
> > > >> +	return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > >> +}
> > > > Can't you use the MFD core instead?
> > > >
> > > 
> > > Are you suggesting using mfd_add_devices()? At first glance it looks
> > > like that would require an array of mfd_cell structures that do nothing
> > > besides match compatible strings in the DT. Using of_platform_populate()
> > > achieves the same goal and doesn't require an array of mfd_cell
> > > structures for each different pm8xxx chip that comes along, meaning
> > > simpler code.
> > 
> > I'm inclined to agree, but playing Devil's advocate here, as a device
> > using the MFD subsystem it's often clearer to readers and other people
> > looking for examples if the MFD core functionality is used. For
> > instance, I now have no idea what devices the PM8xxx encompasses
> > without looking at the DTS file. A small cell structure is a small
> > price to pay for code clarity IMHO.
> > 
> 
> Why not just put that information in the binding document? And
> how is this different from adding a bunch of C files to match a
> set of compatible strings that a dts file has just so that we can
> add all the devices on a board (think board files for an SoC).
> Sure it documents the devices on a board, but we've been moving
> away from that by using of_platform_populate().
> 
> IMHO the code is clear. I want to add all subnodes of this
> device's node as children struct devices. Using
> of_platform_populate() says that, whereas mfd_add_devices() says
> I want to add these specific subnodes of this device's node.
> 
> Also, as more drivers are written and more bindings are ratified
> this platform driver will need to be updated with more cells and
> more compatible strings, causing more inter-tree dependencies and
> more patches. Please, let's avoid this if we can.

Okay, that's fine. There are a few discussions floating around about
this. If I find some time, I'll have to have a think about the pros
and cons of either approach. This is okay for now.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains
Date: Wed, 8 Jan 2014 08:14:52 +0000	[thread overview]
Message-ID: <20140108081452.GC19974@lee--X1> (raw)
In-Reply-To: <20140107195412.GC14405@codeaurora.org>

On Tue, 07 Jan 2014, Stephen Boyd wrote:

> On 01/07, Lee Jones wrote:
> > > >> +	return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > >> +}
> > > > Can't you use the MFD core instead?
> > > >
> > > 
> > > Are you suggesting using mfd_add_devices()? At first glance it looks
> > > like that would require an array of mfd_cell structures that do nothing
> > > besides match compatible strings in the DT. Using of_platform_populate()
> > > achieves the same goal and doesn't require an array of mfd_cell
> > > structures for each different pm8xxx chip that comes along, meaning
> > > simpler code.
> > 
> > I'm inclined to agree, but playing Devil's advocate here, as a device
> > using the MFD subsystem it's often clearer to readers and other people
> > looking for examples if the MFD core functionality is used. For
> > instance, I now have no idea what devices the PM8xxx encompasses
> > without looking at the DTS file. A small cell structure is a small
> > price to pay for code clarity IMHO.
> > 
> 
> Why not just put that information in the binding document? And
> how is this different from adding a bunch of C files to match a
> set of compatible strings that a dts file has just so that we can
> add all the devices on a board (think board files for an SoC).
> Sure it documents the devices on a board, but we've been moving
> away from that by using of_platform_populate().
> 
> IMHO the code is clear. I want to add all subnodes of this
> device's node as children struct devices. Using
> of_platform_populate() says that, whereas mfd_add_devices() says
> I want to add these specific subnodes of this device's node.
> 
> Also, as more drivers are written and more bindings are ratified
> this platform driver will need to be updated with more cells and
> more compatible strings, causing more inter-tree dependencies and
> more patches. Please, let's avoid this if we can.

Okay, that's fine. There are a few discussions floating around about
this. If I find some time, I'll have to have a think about the pros
and cons of either approach. This is okay for now.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2014-01-08  8:14 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-23 20:45 [PATCH v2 0/7] Modernize pm8921 with irqdomains, regmap, DT Stephen Boyd
2013-12-23 20:45 ` Stephen Boyd
2013-12-23 20:45 ` Stephen Boyd
2013-12-23 20:45 ` [PATCH v2 1/7] mfd: Move pm8xxx-irq.c contents into only driver that uses it Stephen Boyd
2013-12-23 20:45   ` Stephen Boyd
2014-01-06 14:47   ` Lee Jones
2014-01-06 14:47     ` Lee Jones
2013-12-23 20:45 ` [PATCH v2 2/7] mfd: pm8921: Update for genirq changes Stephen Boyd
2013-12-23 20:45   ` Stephen Boyd
2013-12-23 20:45 ` [PATCH v2 3/7] mfd: pm8921: Migrate to irqdomains Stephen Boyd
2013-12-23 20:45   ` Stephen Boyd
2014-01-06 15:53   ` Lee Jones
2014-01-06 15:53     ` Lee Jones
2014-01-06 20:33     ` Stephen Boyd
2014-01-06 20:33       ` Stephen Boyd
2014-01-07  8:22       ` Lee Jones
2014-01-07  8:22         ` Lee Jones
2014-01-07 19:54         ` Stephen Boyd
2014-01-07 19:54           ` Stephen Boyd
2014-01-08  8:14           ` Lee Jones [this message]
2014-01-08  8:14             ` Lee Jones
2013-12-23 20:46 ` [PATCH v2 4/7] mfd: ssbi: Add regmap read/write helpers Stephen Boyd
2013-12-23 20:46   ` Stephen Boyd
2013-12-24 12:54   ` Mark Brown
2013-12-24 12:54     ` Mark Brown
2013-12-26 19:41     ` Stephen Boyd
2013-12-26 19:41       ` Stephen Boyd
2013-12-28 14:52       ` Mark Brown
2013-12-28 14:52         ` Mark Brown
2013-12-28 14:52         ` Mark Brown
2014-01-06 11:50       ` Lee Jones
2014-01-06 11:50         ` Lee Jones
2014-01-06 22:26         ` Stephen Boyd
2014-01-06 22:26           ` Stephen Boyd
2013-12-23 20:46 ` [PATCH v2 5/7] mfd: pm8921: Use ssbi regmap Stephen Boyd
2013-12-23 20:46   ` Stephen Boyd
2013-12-30 12:34   ` Mark Brown
2013-12-30 12:34     ` Mark Brown
2013-12-23 20:46 ` [PATCH v2 6/7] mfd: pm8921: Add DT match table Stephen Boyd
2013-12-23 20:46   ` Stephen Boyd
2014-01-06 11:52   ` Lee Jones
2014-01-06 11:52     ` Lee Jones
2014-01-06 18:03     ` Stephen Boyd
2014-01-06 18:03       ` Stephen Boyd
     [not found] ` <1387831563-13535-1-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-12-23 20:46   ` [PATCH v2 7/7] devicetree: bindings: Document PM8921/8058 PMICs Stephen Boyd
2013-12-23 20:46     ` Stephen Boyd
2013-12-23 20:46     ` Stephen Boyd
2014-01-06 11:53     ` Lee Jones
2014-01-06 11:53       ` Lee Jones

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=20140108081452.GC19974@lee--X1 \
    --to=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=sboyd@codeaurora.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.