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: Thu, 11 Dec 2014 11:49:54 +0100 From: Andrzej Hajda <a.hajda@...sung.com> To: Mark Brown <broonie@...nel.org> Cc: open list <linux-kernel@...r.kernel.org>, Marek Szyprowski <m.szyprowski@...sung.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Mike Turquette <mturquette@...aro.org>, Russell King <linux@....linux.org.uk>, Linus Walleij <linus.walleij@...aro.org>, Alexandre Courbot <gnurou@...il.com>, Thierry Reding <thierry.reding@...il.com>, Inki Dae <inki.dae@...sung.com>, Kishon Vijay Abraham I <kishon@...com>, Liam Girdwood <lgirdwood@...il.com>, Grant Likely <grant.likely@...aro.org>, Rob Herring <robh+dt@...nel.org>, "moderated list:ARM/CLKDEV SUPPORT" <linux-arm-kernel@...ts.infradead.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>, "open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>, "moderated list:ARM/S5P EXYNOS AR..." <linux-samsung-soc@...r.kernel.org>, "open list:OPEN FIRMWARE AND..." <devicetree@...r.kernel.org>, boris.brezillon@...e-electrons.com Subject: Re: [RFC 04/15] regulator: add restrack support Hi Mark, On 12/10/2014 05:07 PM, Mark Brown wrote: > On Wed, Dec 10, 2014 at 04:48:22PM +0100, Andrzej Hajda wrote: >> Regulators supports various methods of lookup. >> The patch adds restrack support only to DT based regulators. > Why, what does this mean and how might one use it? I've not looked at > the code since I don't know what it's supposed to accomplish... Looking at this patch makes no sense without looking at cover letter or at the patch adding restrack framework. In short adding restrack support to regulators will allow to: - proper handle regulator provider unbind/re-bind, currently it results in oopses, crashes and hangs, - avoid late probe due to deferred probing, currently if probe is deferred, re-probe occurs in late initcall, - track appearance of resources which can alter behavior of the driver if present but they are not required, I am not sure if there are use cases for it in case of regulators, but other resources have such use cases, - as a bonus we can have simpler allocation of various resources, please look at cover letter for example. > > One very high level thing is that anything that only works for DT only > seems to be a non-starter, the API should be hiding details of the > firmware interface. I agree, but as this is RFC, not everything is finished. It seems I have forgotten to mention it clearly in cover letter. Anyway it seems I should adjust patchset and move matching code from restrack/track core to specific frameworks. This way any current or future lookup method should be supported. But the main purpose of this patchset is to get opinions, if the main ideas are OK. And if the patchset can be eventually accepted. Regards Andrzej -- 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