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: <CAGb2v66ib=6NK1OpYct_5Cs6V-89PNHpk69J++e6ph85etF6sw@mail.gmail.com>
Date:	Thu, 13 Feb 2014 15:41:25 +0800
From:	Chen-Yu Tsai <wens@...e.org>
To:	Arend van Spriel <arend@...adcom.com>
Cc:	Rob Herring <robh+dt@...nel.org>,
	devicetree <devicetree@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tomasz Figa <tomasz.figa@...il.com>
Subject: Re: [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices

On Tue, Feb 11, 2014 at 3:17 AM, Arend van Spriel <arend@...adcom.com> wrote:
> The Broadcom bcm43xx sdio devices are fullmac devices that may be
> integrated in ARM platforms. Currently, the brcmfmac driver for
> these devices support use of platform data. This patch specifies
> the bindings that allow this platform data to be expressed in the
> devicetree.
>
> Cc: Chen-Yu Tsai <wens@...e.org>
> Cc: Tomasz Figa <tomasz.figa@...il.com>
> Reviewed-by: Hante Meuleman <meuleman@...adcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieterpg@...adcom.com>
> Signed-off-by: Arend van Spriel <arend@...adcom.com>
> ---
> This devicetree binding proposal is intended for platforms with
> Broadcom wireless device in MMC sdio slot. These devices may
> have their own interrupt and power line. Also the SDIO drive
> strength is often hardware dependent and expressed in this
> binding.

Hi,

I believe the interrupts and drive-strength properties are Ok.
However, letting the platform driver power up the wifi chip does
not guarantee proper ordering, does it? I mean, what if the MMC
bus was probed before the (non-removable) chip was switched on?

Being able to tie that to the mmc controller would be better IMO.
I think this was discussed in Olof's "mmc: add support for
power-on sequencing through DT" thread.


Thanks!
ChenYu

>
> Not sure if this should go in staging or not. Feel free to
> comment on this proposal.
>
> Regards,
> Arend
--
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/