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  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:	Thu, 19 Sep 2013 12:55:01 +0100
From:	Mark Brown <>
To:	Lee Jones <>
Cc:	Laxman Dewangan <>,,,,,,,,,,
Subject: Re: [PATCH] mfd: core: introduce of_node_name for mfd sub devices

On Thu, Sep 19, 2013 at 09:30:50AM +0100, Lee Jones wrote:

> I'm not entirely sure this is what Mark was saying. I think he was
> complaining about the existence of the sub-nodes rather than how the
> MFD Core assigns their of_node. My take is that the chip is really a
> single device which provides different bits of functionality. To break
> that functionality up and disperse the drivers into various subsystems
> is a Linuxisum. By providing each functional block with its own node
> you're describing how we do things in Linux, rather than specifying a
> single node for the AS3722 which would probably be the norm.

Yes, that's exactly what I was thinking of.

> Do the sub-nodes have their own properties? If so, it would be worth
> breaking them up as other OSes could reuse the specifics. If they do,
> then you need so put them in the binding. If they don't, then you do
> not require sub-nodes. The MFD core will ensure the sub-devices are
> probed and there is no requirement for the of_node to be assigned.

You do see some reusable IP blocks (like the regualtors on the wm831x
PMICs for example, they're repeated blocks) which can be reused but
generally they have a register base as part of the binding.  Personally
if it's just a property or two I'd probably just put them on the root
node for the device.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists