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]
Message-ID: <20110921131637.GF4374@opensource.wolfsonmicro.com>
Date:	Wed, 21 Sep 2011 14:16:38 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Daniel Drake <dsd@...top.org>
Cc:	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 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 type might get into a fight with each
other.

> 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 lot of MFDs (including this one, the
GPIO driver is entirely specific to the parent) it's not clear that we
should be splitting the device up in the device tree in the first place
- our use of MFDs is a Linux implementation detail.  If the child is
specific to the parent it can cooperate with the parent device happily.

My suspicion is that for device tree in cases where the MFD really is
totally independent of the parent we shouldn't need explicit MFD code to
instantiate the child at all any more in the same way that we should be
avoiding this for the SoCs.

> see, platform data is passed to the child in exactly the same way - by
> including it in the mfd_cell definition - see mfd_add_device():

Indeed, I have the same concerns there.  
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ