| 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
| ||
|
Message-ID: <4F38D55A.5020208@nvidia.com> Date: Mon, 13 Feb 2012 14:48:18 +0530 From: Laxman Dewangan <ldewangan@...dia.com> To: Mark Brown <broonie@...nsource.wolfsonmicro.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Regulator enable/disable delay based on board design: How to handle? Hi Mark, We observed that some of the rail enable/disable settling time depends on the board design specially based on external capacitor connected on rails. This is observed mainly on VBUS regulator rail where difference on the capacitance value which is connected on rail makes the on/off time to vary. Currently none of regulator driver support such board related delay. My question is: - Should we add board delay as part of platform data for regulator and handle in regulator driver? Or, - Push this delay parameter to respective client driver and let them to handle. Not a good idea as it is mainly related to rail on/off. Or, - Should we add one more parameter in regulator_init_data as rail_delay and push this change to core driver of regulator i.e. if it is non-zero then take this value from this field otherwise take from <xxx>-regulator driver? I can also work towards If there is any other good options and acceptable to linux community. 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