linux-kernel - Re: [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFpU=nQAgfjMm6KNRAEKwChAx_SxFMC-pLbq8yis2mgB=Q@mail.gmail.com>
Date:	Mon, 31 Mar 2014 10:24:00 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Mark Brown <broonie@...nel.org>, Tomasz Figa <t.figa@...sung.com>
Cc:	Arend van Spriel <arend@...adcom.com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Chen-Yu Tsai <wens@...e.org>
Subject: Re: [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices

On 13 February 2014 17:22, Mark Brown <broonie@...nel.org> wrote:
> On Thu, Feb 13, 2014 at 01:35:41PM +0100, Tomasz Figa wrote:
>> On 13.02.2014 13:07, Arend van Spriel wrote:
>> >On 02/13/2014 10:13 AM, Tomasz Figa wrote:
>
>> >>The BCM43xx WLAN chips I used to work always have been controlled by a
>> >>simple power enable GPIO of the chip itself. Has this changed in newer
>> >>chips?
>
>> >>If you need to simply toggle a GPIO to control the power, you don't need
>> >>to use the regulator API at all, controlling the GPIO directly.
>
>> >Not sure I understand. Do you really mean 'chip' or 'wifi module' here.
>> >The chip needs to be powered and for that it is hooked up to a
>> >host/module provided GPIO (at least that is my understanding).
>
>> Your binding asks for a regulator, not a simple GPIO, which is all I
>> believe you need for BCM43xx power handling.
>
>> Mark (added to Cc), could we get your opinion on this?
>
> If it's a GPIO connected directly to the device it should be using
> gpiolib, the fact that it happens to have an effect on power rather than
> (say) just being a reset isn't terribly relevant to anything outside the
> driver.  If it's an external regulator that happens to be controlled
> using a GPIO on the current system then a regulator is better since
> another system might use a regulator with a different control interface.

>From an SDIO point of view, we need to find the corresponding OCR mask
the mmc host driver supports. The OCR mask gives the voltage levels
the host supports and it's being used during SDIO initialization while
negotiating the voltage level with the SDIO card.

Using a gpio regulator would simplify here, since the driver don't
need specific "SDIO hacks" but can use the mmc_regulator_get_supply()
API, which calculates the OCR mask, based upon the regulator's
supported voltages.

Kind regards
Ulf Hansson
--
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/