linux-kernel - Re: [PATCH] [RFC PATCH v2] power:reset: Add defer reset object to send board specific reset

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: <CAL8JtxByA0t+Nr-h1W6BZEobO9Gfqtm+7UUpp=yUBO67WRLSDg@mail.gmail.com>
Date:	Tue, 17 Jun 2014 23:44:20 +0800
From:	Houcheng Lin <houcheng@...il.com>
To:	Sebastian Reichel <sre@...nel.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH] [RFC PATCH v2] power:reset: Add defer reset object to
 send board specific reset

Hi,

2014-06-15 17:09 GMT+08:00 Sebastian Reichel <sre@...nel.org>:
>
> I think this belongs to drivers/reset and not to drivers/power/reset.
> The drivers in drivers/power/reset are about board reboot / shutdown.
> This driver seems to be used for periphals.

Yes, this driver is for pherphials and I think it is reasonble
to placed it at drivers/reset. I'll moved it in next release.

> Alternatively you could do this via the duration. An infinite long
> reset signal basically means, that the line is never changed back.
>
> To give a few examples for the above comments:
>
> /* keep "gpx3 5" low for 5ms, change back to high afterwards */
> defer_reset_vbus {
>     compatible = "defer-reset";
>     reset-gpios = <&gpx3 5 GPIO_ACTIVE_LOW>;
>     duration = <5>;
> };
>
> /* keep "gpx3 5" high for 5ms, change back to low afterwards */
> defer_reset_vbus {
>     compatible = "defer-reset";
>     reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
>     duration = <5>;
> };
>
> /* keep "gpx3 5" low */
> defer_reset_vbus {
>     compatible = "defer-reset";
>     reset-gpios = <&gpx3 5 GPIO_ACTIVE_LOW>;
>     duration = <0>;

These DT properties looks simpler and better: Use of GPIO_ACTIVE_HIGH
and GPIO_ACTIVE_LOW increase readability for HW/SW developer, use
of <0> to indicate holding the reset signal. I'll updated code according
on this. Thanks for your comments.

-- 
Best regards,
Houcheng Lin
--
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/