| 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
| ||
|
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/
Powered by blists - more mailing lists