| 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, 19 Jun 2012 11:29:44 -0600 From: Stephen Warren <swarren@...dotorg.org> To: Laxman Dewangan <ldewangan@...dia.com> CC: broonie@...nsource.wolfsonmicro.com, grant.likely@...retlab.ca, rob.herring@...xeda.com, arnd@...db.de, linus.walleij@...aro.org, lrg@...com, lee.jones@...aro.org, devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH V2 3/3] ARM: dts: db8500: add node property "regulator-compatible" regulator node On 06/19/2012 08:28 AM, Laxman Dewangan wrote: > Device's regulator matches their hardware counterparts with the > property "regulator-compatible" of each child regulator node in > place of the child node. > Add the property "regulator-compatible" for each regulator with > their name. In order to prevent "git bisect" failures, don't you need to squash this patch into patch 1/3, so that there is no point in git history where the code expects the regulator-compatible property to exist, yet the .dtsi file doesn't have it? Or you could do this: patch 1: add register-compatible property to db8500.dtsi patch 2: adjust the code to use register-compatible property patch 3: rename nodes in db8500.dtsi but I'm not sure there's any advantage to having multiple patches (except for patch statistics counters, but we certainly don't want to have legitimate allegations of patch padding!) -- 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