linux-kernel - Re: [PATCH v2 06/12] mmc: pwrseq: add support for power-on sequencing through DT

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: <5698B8A9.9040002@gmail.com>
Date:	Fri, 15 Jan 2016 17:15:21 +0800
From:	Caesar Wang <caesar.upstream@...il.com>
To:	Javier Martinez Canillas <javier@....samsung.com>
Cc:	Heiko Stuebner <heiko@...ech.de>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-rockchip@...ts.infradead.org, leecam@...gle.com,
	keescook@...gle.com, NeilBrown <neil@...wn.name>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Alexandre Courbot <acourbot@...dia.com>, leozwang@...gle.com,
	Caesar Wang <wxt@...k-chips.com>
Subject: Re: [PATCH v2 06/12] mmc: pwrseq: add support for power-on sequencing
 through DT

Hi Javier,

在 2016年01月12日 00:02, Javier Martinez Canillas 写道:
> Hello Heiko,
>
> On 01/08/2016 11:42 PM, Heiko Stuebner wrote:
>> Am Freitag, 8. Januar 2016, 09:22:31 schrieb Javier Martinez Canillas:
>>>> For example:
>>>> we need enable wifi module power to via the WL_REG_ON
>>>> pin, we need enable it as the regulator if this pin is connected to
>>>> the gpio of cpu.
>>> This part confuses me, so does your chip have an actual regulator that
>>> needs to be enabled or is just a fake regulator whose gpio property is
>>> used not to enable the regulator but to toggle the WL_REG_ON pin of
>>> the WiFi chip?
>> another option would be to use the reset-gpio-handles. rk3288-veyron and I
>> think some Exynos as well use it that way.
>>
> Yes I know, my point was that the reset-gpios property should be used
> instead of a fake regulator if what's needed is to toggle a chip pin.
>
>>>> Maybe, someone will say that can pull up/down from dts.
>>>> Unfortunately some SoCs can't support pinctrl pull up/down in
>>>> internal.
>>> Can you please elaborate on this? AFAIU this limitation is the reason
>>> why you went with the regulator approach so I think it deserve a more
>>> deep explanation.
>> On the rk3036 each pin has an individual unchangable pull direction. So it's
>> either no bias or pulling in the predefined direction (the pin_default bias
>> option).
>>
> I think each change has to be justified on its own so I would say that
> having a regulator enabled as a part of a SDIO chip's power sequencing
> is something needed for many platforms, and that this provider should
> be extended to support that (something like commit msg in patch 05/12).
>
> And then in the kylin DTS change (patch 08/12), I would explain why a
> chained regulators approach is used/needed instead of the reset-gpios
> due any platform limitations.

Okay,
I 'm agreed with your points in here.

The reset-gpios/pwrsq can meet the demand of some wlan chips trigger 
condition.
No matter whatever is the BT_EN or WL_EN  triggers pin.

>> Heiko
>>
> Best regards,


-- 
Thanks,
Caesar