* Re: [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices [not found] ` <CAGb2v67za+5yW3RE0pwBWk-NdTUSm-JkKE+j9NLjbBkE_Fc1hQ@mail.gmail.com> @ 2014-03-30 8:56 ` Arend van Spriel [not found] ` <1397165245229-838046.post@n7.nabble.com> 0 siblings, 1 reply; 2+ messages in thread From: Arend van Spriel @ 2014-03-30 8:56 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Tomasz Figa, Rob Herring, devicetree, linux-kernel, linux-mmc On 02/13/14 10:28, Chen-Yu Tsai wrote: > Hi, > > On Thu, Feb 13, 2014 at 5:13 PM, Tomasz Figa<tomasz.figa@gmail.com> wrote: >> Hi Arend, >> >> >> On 10.02.2014 20:17, Arend van Spriel wrote: [...] >>> + >>> +Example: >>> + >>> +mmc3: mmc@01c20000 { >>> + pinctrl-0 =<&mmc3_pins>; >>> + pinctrl-1 =<&wifi_host_wake>; >> >> >> WLAN_HOST_WAKE pin (aka the OOB interrupt) is specific to the WLAN chip, so >> this should be rather configured in a pinctrl state of the WLAN chip itself. Hi Chen-Yu, picking up this thread. > AFAIK, the pinctrl in tied to the device node, and is selected when the device > is registered. The MMC subsystem currently does not register child nodes, so > this would be useless. So if MMC does not register child nodes, brcmfmac will not be probed with of_node set? Have there been patches submitted for this in mmc subsystem recently. > brcmfmac actually has to walk the whole DT to find the node with the right > compatible. Is it just me or should this be avoided? What if there are multiple entries? Regards, Arend ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <1397165245229-838046.post@n7.nabble.com>]
* Re: [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices [not found] ` <1397165245229-838046.post@n7.nabble.com> @ 2014-04-11 8:06 ` Arend van Spriel 0 siblings, 0 replies; 2+ messages in thread From: Arend van Spriel @ 2014-04-11 8:06 UTC (permalink / raw) To: Jörg Krause, linux-kernel, linux-mmc@vger.kernel.org, Sascha Hauer On 10/04/14 23:27, Jörg Krause wrote: > On 02/13/14 10:28, Chen-Yu Tsai wrote: >> Hi, >> >> On Thu, Feb 13, 2014 at 5:13 PM, Tomasz Figa<tomasz.figa@> wrote: >>> Hi Arend, >>> >>> >>> On 10.02.2014 20:17, Arend van Spriel wrote: > > [...] > > Hi Chen-Yu, > > picking up this thread. > >> AFAIK, the pinctrl in tied to the device node, and is selected when the >> device >> is registered. The MMC subsystem currently does not register child nodes, >> so >> this would be useless. > > So if MMC does not register child nodes, brcmfmac will not be probed > with of_node set? Have there been patches submitted for this in mmc > subsystem recently. > > [...] > > > > Sascha Hauer submitted a patch a week ago. Link: > https://lkml.org/lkml/2014/4/3/522 <https://lkml.org/lkml/2014/4/3/522> Thanks, Jörg It is a partial solution, but it seems to conflict with my change. So thanks for the heads up. I am not convinced whether the GPIO and clock should be bound to the function. They seem more a property of the card/device inserted. Regards, Arend > -- > View this message in context: http://linux-kernel.2935.n7.nabble.com/RFC-dt-bindings-add-bindings-for-Broadcom-bcm43xx-sdio-devices-tp801976p838046.html > Sent from the Linux Kernel mailing list archive at Nabble.com. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-04-11 8:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1392059868-8782-1-git-send-email-arend@broadcom.com>
[not found] ` <52FC8CB3.4090305@gmail.com>
[not found] ` <CAGb2v67za+5yW3RE0pwBWk-NdTUSm-JkKE+j9NLjbBkE_Fc1hQ@mail.gmail.com>
2014-03-30 8:56 ` [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices Arend van Spriel
[not found] ` <1397165245229-838046.post@n7.nabble.com>
2014-04-11 8:06 ` Arend van Spriel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).