linux-kernel - Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 3 Oct 2011 13:16:55 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Daniel Drake <dsd@...top.org>
Cc:	Grant Likely <grant.likely@...retlab.ca>, sameo@...ux.intel.com,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	dilinger@...ued.net
Subject: Re: [PATCH 1/3] mfd: allow mfd_cell association with device tree node

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 data
> reuse problem you have described, they can use the kmemdup solution
> you have described.

This seems the wrong way round - we're working

> > To be honest I don't
> > really understand why you're changing the framework at all here, the
> > child driver is entirely specific to the parent as far as I can see.

> Because I'm trying to get devicetree-driven HDD LED support driven,
> and Grant stated that doing it this way is a hard rule:

> "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."

> I also confirmed that extending the mfd_cell layer is exactly what
> Grant was suggesting:
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-September/008480.html

That's in the context of adding a binding for the vx855 GPIO module
that's distinct from the binding for the rest of the chip.  It's not
massively clear to me that this is a good idea.

> So I seem to be stuck between two people giving me conflicting
> requirements for merge of my work (which commenced in July, and has
> already seen several discussions and rounds of patches). Any help
> appreciated - I'm just trying to make a HDD LED blink.

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 should just be able to instantiate the device from the
device tree without using explict code in the core driver).

This all feels like there's some abstraction violation going on.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/