linux-kernel - Re: Regulator supplies when using Device Tree

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:	Thu, 29 Mar 2012 18:18:44 -0700
From:	Michael Bohan <mbohan@...eaurora.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	rnayak@...com, lrg@...com, LKML <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: Regulator supplies when using Device Tree

On 3/29/2012 4:11 AM, Mark Brown wrote:
> On Wed, Mar 28, 2012 at 05:06:48PM -0700, Michael Bohan wrote:
>
>> Are you aware of any other examples of submitted drivers with Device
>> Tree support that implement regulator devices that optionally have
>> an upstream supply? I looked at your tree recently and couldn't see
>> any such cases.
>
> No, pretty much any drivers which optionally have an upstream supply
> would be buggy and should therefore run into trouble during review.

Can you please elaborate on why this is a bad design? We have always 
used this model in the past, and the regulator framework is happy to 
support it.

We have identical hardware blocks that can be positioned to take a 
supply or not. So are you proposing we copy / paste our driver so that 
in one case rdesc->supply_name is NULL and the other case a valid supply 
name? I'm guessing you aren't implying this, but what alternatives do 
you suggest to support such a model?

In the thread mentioned by Rajendra, part of the motivation for putting 
the supply_name in the driver struct was 'no code changes in the 
individual drivers'. But that's exactly what we have here.

http://www.spinics.net/lists/linux-omap/msg58673.html

I was hoping that we could continue to treat regulator supplies as 
normal supplies, but somehow allow the framework to determine whether a 
regulator supply exists or not in the Device Tree configuration so the 
driver doesn't have to.

Thanks,
Mike

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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/