On Mon, Oct 3, 2011 at 1:40 PM, Mark Brown
wrote:
> So, I made two suggestions above and it sounds like you want the second
> one but you've only responded to the first one without commenting on the
> second. My second suggestion was that if the block is sufficiently
> isoltated from the core we
On Mon, Oct 03, 2011 at 01:30:15PM +0100, Daniel Drake wrote:
> On Mon, Oct 3, 2011 at 1:16 PM, Mark Brown
> > It seems to me like either the IP block is heavily dependant on the core
> > and shouldn't be split out in the device tree at all (but should instead
> > be part of the core node) or the
On Mon, Oct 3, 2011 at 1:16 PM, Mark Brown
wrote:
> It seems to me like either the IP block is heavily dependant on the core
> and shouldn't be split out in the device tree at all (but should instead
> be part of the core node) or the IP block is very isolated from the core
> (in which case we sho
On Mon, Oct 03, 2011 at 11:39:47AM +0100, Daniel Drake wrote:
> On Mon, Oct 3, 2011 at 11:28 AM, Mark Brown
> > I'd really expect that if we're adding stuff to the framework then it
> > should be suitable for random drivers to use.
> It is suitable. If other drivers would otherwise run into the d
On Mon, Oct 3, 2011 at 11:28 AM, Mark Brown
wrote:
> I'd really expect that if we're adding stuff to the framework then it
> should be suitable for random drivers to use.
It is suitable. If other drivers would otherwise run into the data
reuse problem you have described, they can use the kmemdup
On Mon, Oct 03, 2011 at 09:40:10AM +0100, Daniel Drake wrote:
> On Wed, Sep 28, 2011 at 1:31 PM, Mark Brown
> > Right, but your modification was to the MFD core so it's going to affect
> > other devices...
> But only when they start using the newly added functionality. At this
> point, it affects
On Wed, Sep 28, 2011 at 1:31 PM, Mark Brown
wrote:
> Right, but your modification was to the MFD core so it's going to affect
> other devices...
But only when they start using the newly added functionality. At this
point, it affects nobody except vx855.
Grant, any chance I could have your commen
On Wed, Sep 28, 2011 at 10:07:43AM +0100, Daniel Drake wrote:
> On Tue, Sep 27, 2011 at 7:38 PM, Mark Brown
> > You're modifying global data which should really be const and is shared
> > between multiple devices in place. Probably you'll not notice any
> > practical effects, especially if you do
This allows a mfd_cell to be linked with a device tree node, which
then allows child drivers to have easy access to that handle.
Signed-off-by: Daniel Drake
---
drivers/mfd/mfd-core.c |1 +
include/linux/mfd/core.h |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a
On Tue, Sep 27, 2011 at 7:38 PM, Mark Brown
wrote:
> You're modifying global data which should really be const and is shared
> between multiple devices in place. Probably you'll not notice any
> practical effects, especially if you don't happen to have multiple
> devices in the same system.
I se
On Tue, Sep 27, 2011 at 07:28:40PM +0100, Daniel Drake wrote:
> On Tue, Sep 27, 2011 at 7:26 PM, Mark Brown
> > That seems like a bug that just happened to get noticed while reviewing
> > this change, though...
> Sorry if I'm missing something obvious but I'm not seeing the issue.
> What exactly
On Tue, Sep 27, 2011 at 7:26 PM, Mark Brown
wrote:
> That seems like a bug that just happened to get noticed while reviewing
> this change, though...
Sorry if I'm missing something obvious but I'm not seeing the issue.
What exactly is this bug and what effects could it cause?
Thanks,
Daniel
On Tue, Sep 27, 2011 at 07:25:03PM +0100, Daniel Drake wrote:
> On Tue, Sep 27, 2011 at 7:14 PM, Mark Brown
> > Why not just kmemdup() the template you're using rather than modifying
> > it in place?
> Could do, but is there any point in this case? I'm not seeing it. The
> "template" is already b
On Tue, Sep 27, 2011 at 7:14 PM, Mark Brown
wrote:
> On Tue, Sep 27, 2011 at 05:44:04PM +0100, Daniel Drake wrote:
>
>> However, it does take Mark's suggestion into account that the mfd
>> should have some clear representation in the device tree. For us it
>> already did have (naturally), but this
On Tue, Sep 27, 2011 at 05:44:04PM +0100, Daniel Drake wrote:
> However, it does take Mark's suggestion into account that the mfd
> should have some clear representation in the device tree. For us it
> already did have (naturally), but this wasn't reflected in my earlier
> patch. It is now - the l
On Tue, Sep 27, 2011 at 4:05 PM, Grant Likely wrote:
> What is a hard rule is that the code creating the children needs to
> know what the binding is and populate the child's of_node
> appropriately. Similarly, the child driver needs to know something
> about the kinds of nodes it will be passed
On Tue, Sep 27, 2011 at 09:05:55AM -0600, Grant Likely wrote:
> On Tue, Sep 27, 2011 at 03:44:56PM +0100, Daniel Drake wrote:
> > On Wed, Sep 21, 2011 at 2:16 PM, Mark Brown
> > > My suspicion is that for device tree in cases where the MFD really is
> > > totally independent of the parent we shoul
On Tue, Sep 27, 2011 at 03:44:56PM +0100, Daniel Drake wrote:
> On Wed, Sep 21, 2011 at 2:16 PM, Mark Brown
> wrote:
> >> Not sure how the MFD cells could get at the OF node by using the
> >> parent device - if the parent device had a OF node, wouldn't this
> >> correspond to the parent instead of
On Wed, Sep 21, 2011 at 2:16 PM, Mark Brown
wrote:
>> Not sure how the MFD cells could get at the OF node by using the
>> parent device - if the parent device had a OF node, wouldn't this
>> correspond to the parent instead of the child? Also, as far as I can
>
> Well, obviously. But then with a
On Wed, Sep 21, 2011 at 02:02:43PM +0100, Daniel Drake wrote:
> Thanks for reviewing.
> The data can still be static, not needing allocation, it just has to
> be modified at runtime. See patch 2.
Right, but that means that you need to take a copy before using it
otherwise two devices of the same
On Wed, Sep 21, 2011 at 1:49 PM, Mark Brown
wrote:
> On Wed, Sep 21, 2011 at 01:01:48PM +0100, Daniel Drake wrote:
>
>> @@ -37,6 +38,9 @@ struct mfd_cell {
>> void *platform_data;
>> size_t pdata_size;
>>
>> + /* association with device tree node
On Wed, Sep 21, 2011 at 01:01:48PM +0100, Daniel Drake wrote:
> @@ -37,6 +38,9 @@ struct mfd_cell {
> void*platform_data;
> size_t pdata_size;
>
> + /* association with device tree node (optional) */
> + struct device_node *of_node;
>
This allows a mfd_cell to be linked with a device tree node, which
then allows child drivers to have easy access to that handle.
Signed-off-by: Daniel Drake
---
drivers/mfd/mfd-core.c |1 +
include/linux/mfd/core.h |4
2 files changed, 5 insertions(+), 0 deletions(-)
I think this
23 matches
Mail list logo
