linux-kernel - Re: Regulator enable/disable delay based on board design: How to handle?

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] [day] [month] [year] [list]

Message-ID: <4F3A4436.4090007@nvidia.com>
Date:	Tue, 14 Feb 2012 16:53:34 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Regulator enable/disable delay based on board design: How to
 handle?

On Tuesday 14 February 2012 06:39 AM, Mark Brown wrote:
> This is part of the reason why the driver_data field is present in the
> constraints - the driver can take that and use it as a pdata within
> pdata structure.  It's not terribly nice to do that but it's possible.
Ok, I was thinking that driver data is specific to machine file and 
driver will pass this information to the function regulator_init() at 
the time of call.
But I think it is fine to use this for driver specific data for my case.
Thanks lot for suggestion,
> A standard parameter might cause too much complexity as drivers try to
> implement it even if they don't really need to (for example, due to
> having soft control of this stuff already).

I was thinking that this will be taken care by core if board files 
override the value (non-zero). So if it is zero then just ignore this 
parameters otherwise take this value and ignore what driver is returning.
Hence option will be as per data sheet (what driver is returning) or as 
per board designs (if some more delay is require than specified in 
datasheet).

Thanks,
Laxman

--
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/