New options enabled:
* WIRELESS: (dependency)
* CFG80211: (dependency)
* WLAN: (dependency)
* BRCMFMAC: wlan driver, enable as module.

Signed-off-by: Wei Ni <wni@nvidia.com>
---
arch/arm/configs/tegra_defconfig | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 4be9c1e..c0aa6d9 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -67,7 +67,8 @@ CONFIG_INET6_IPCOMP=y
CONFIG_IPV6_MIP6=y
CONFIG_IPV6_TUNNEL=y
CONFIG_IPV6_MULTIPLE_TABLES=y
-# CONFIG_WIRELESS is not set
+CONFIG_WIRELESS=y
+CONFIG_CFG80211=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
@@ -87,7 +88,8 @@ CONFIG_USB_PEGASUS=y
CONFIG_USB_USBNET=y
CONFIG_USB_NET_SMSC75XX=y
CONFIG_USB_NET_SMSC95XX=y
-# CONFIG_WLAN is not set
+CONFIG_WLAN=y
+CONFIG_BRCMFMAC=m
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MPU3050=y
--
1.7.1

--
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 [vger.kernel.org]
Please read the FAQ at [www.tux.org]

On 07/04/2012 03:34 AM, Wei Ni wrote:
> New options enabled:
> * WIRELESS: (dependency)
> * CFG80211: (dependency)
> * WLAN: (dependency)
> * BRCMFMAC: wlan driver, enable as module.

> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig

> +CONFIG_BRCMFMAC=m

Why does this need to be a module? Everything else in tegra_defconfig is
built-in, and it'd be nice to be consistent here. Built-in makes
net-booting new kernels from U-Boot much easier, since there aren't any
modules to copy.

When I built a kernel with this series, I observed the following:

CONFIG_BRCMFMAC=m

* Neither Cardhu nor Ventana auto-load the module. When the module is
manually modprobe'd, I still see no wireless device being created.

CONFIG_BRCMFMAC=y

* Cardhu: No wireless device created. I do see some kernel spew such as
"mmc1: queuing unknown CIS tuple 0x80" which I believe is the SDIO
device being probed, but I don't see any Linux device being created.

* Ventana: There's a 60s hang during boot, I believe related to the BRCM
driver, since the hang doesn't occur without the series.

In summary, this series doesn't work at all for me. Can you please
explain what you tested and how? Are there any differences between the
various Cardhu and Ventana board revisions and/or the 2 different
wireless cards possible on Cardhu that'd explain this?

Thanks.
--
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 [vger.kernel.org]
Please read the FAQ at [www.tux.org]

On Thursday 05 July 2012 13:59:11 Stephen Warren wrote:
> On 07/04/2012 03:34 AM, Wei Ni wrote:
> > New options enabled:
> > * WIRELESS: (dependency)
> > * CFG80211: (dependency)
> > * WLAN: (dependency)
> > * BRCMFMAC: wlan driver, enable as module.
> >
> > diff --git a/arch/arm/configs/tegra_defconfig
> > b/arch/arm/configs/tegra_defconfig
> >
> > +CONFIG_BRCMFMAC=m
>
> Why does this need to be a module? Everything else in tegra_defconfig is
> built-in, and it'd be nice to be consistent here. Built-in makes
> net-booting new kernels from U-Boot much easier, since there aren't any
> modules to copy.

network drivers (especially wifi) are often modules because they need firmwares.
I'm not sure if the kernel can compile them in every case. Our RT2x00 is an
example (which also needs a defconfig entry btw) but brcmfmac also needs it as
modinfo shows. Beside that, I don't think you want to netboot using wifi and u-
boot because this needs a huge wireless framework which u-boot doesn't have.

Marc

> When I built a kernel with this series, I observed the following:
>
> CONFIG_BRCMFMAC=m
>
> * Neither Cardhu nor Ventana auto-load the module. When the module is
> manually modprobe'd, I still see no wireless device being created.
>
> CONFIG_BRCMFMAC=y
>
> * Cardhu: No wireless device created. I do see some kernel spew such as
> "mmc1: queuing unknown CIS tuple 0x80" which I believe is the SDIO
> device being probed, but I don't see any Linux device being created.
>
> * Ventana: There's a 60s hang during boot, I believe related to the BRCM
> driver, since the hang doesn't occur without the series.
>
> In summary, this series doesn't work at all for me. Can you please
> explain what you tested and how? Are there any differences between the
> various Cardhu and Ventana board revisions and/or the 2 different
> wireless cards possible on Cardhu that'd explain this?
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at [vger.kernel.org]
--
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 [vger.kernel.org]
Please read the FAQ at [www.tux.org]

On 07/05/2012 02:35 PM, Marc Dietrich wrote:
> On Thursday 05 July 2012 13:59:11 Stephen Warren wrote:
>> On 07/04/2012 03:34 AM, Wei Ni wrote:
>>> New options enabled:
>>> * WIRELESS: (dependency)
>>> * CFG80211: (dependency)
>>> * WLAN: (dependency)
>>> * BRCMFMAC: wlan driver, enable as module.
>>>
>>> diff --git a/arch/arm/configs/tegra_defconfig
>>> b/arch/arm/configs/tegra_defconfig
>>>
>>> +CONFIG_BRCMFMAC=m
>>
>> Why does this need to be a module? Everything else in tegra_defconfig is
>> built-in, and it'd be nice to be consistent here. Built-in makes
>> net-booting new kernels from U-Boot much easier, since there aren't any
>> modules to copy.
>
> network drivers (especially wifi) are often modules because they need firmwares.

So I certainly see that WiFi modules may need firmware.

But I don't see why that should imply they must be modules; they should
be able to defer their firmware loading until the firmware is available.

> I'm not sure if the kernel can compile them in every case. Our RT2x00 is an
> example (which also needs a defconfig entry btw) but brcmfmac also needs it as
> modinfo shows. Beside that, I don't think you want to netboot using wifi and u-
> boot because this needs a huge wireless framework which u-boot doesn't have.

I net-boot using a USB wired Ethernet adapter. The issue isn't that I
want to use wireless from U-Boot, but rather than it's easy to download
the zImage and .dtb using U-Boot since they're just copied to RAM, but
getting a bunch of modules into a filesystem on the target before
booting the kernel is more painful.
--
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 [vger.kernel.org]
Please read the FAQ at [www.tux.org]

On Fri, 2012-07-06 at 03:59 +0800, Stephen Warren wrote:
> On 07/04/2012 03:34 AM, Wei Ni wrote:
> > New options enabled:
> > * WIRELESS: (dependency)
> > * CFG80211: (dependency)
> > * WLAN: (dependency)
> > * BRCMFMAC: wlan driver, enable as module.
>
> > diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
>
> > +CONFIG_BRCMFMAC=m
>
> Why does this need to be a module? Everything else in tegra_defconfig is
> built-in, and it'd be nice to be consistent here. Built-in makes
> net-booting new kernels from U-Boot much easier, since there aren't any
> modules to copy.
>
> When I built a kernel with this series, I observed the following:
>
> CONFIG_BRCMFMAC=m
>
> * Neither Cardhu nor Ventana auto-load the module. When the module is
> manually modprobe'd, I still see no wireless device being created.
>
> CONFIG_BRCMFMAC=y
>
> * Cardhu: No wireless device created. I do see some kernel spew such as
> "mmc1: queuing unknown CIS tuple 0x80" which I believe is the SDIO
> device being probed, but I don't see any Linux device being created.
>
> * Ventana: There's a 60s hang during boot, I believe related to the BRCM
> driver, since the hang doesn't occur without the series.
>
> In summary, this series doesn't work at all for me. Can you please
> explain what you tested and how? Are there any differences between the
> various Cardhu and Ventana board revisions and/or the 2 different
> wireless cards possible on Cardhu that'd explain this?

I have verified this patch, it can work on these boards.
The t30/t20 version on my Cardhu and Ventana is A02, the wireless chip
is bcm4329. I didn't test on other boards, and I'm not sure if the
bcm4330 can work.
When you test, you need to copy the latest brcmfmac firmware to the
filesystem.
Please get it from:
[linuxwireless.org]

You can run "ifconfig -a" to show the "wlan0" device.

>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at [vger.kernel.org]


--
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 [vger.kernel.org]
Please read the FAQ at [www.tux.org]

On Fri, 2012-07-06 at 04:42 +0800, Stephen Warren wrote:
> On 07/05/2012 02:35 PM, Marc Dietrich wrote:
> > On Thursday 05 July 2012 13:59:11 Stephen Warren wrote:
> >> On 07/04/2012 03:34 AM, Wei Ni wrote:
> >>> New options enabled:
> >>> * WIRELESS: (dependency)
> >>> * CFG80211: (dependency)
> >>> * WLAN: (dependency)
> >>> * BRCMFMAC: wlan driver, enable as module.
> >>>
> >>> diff --git a/arch/arm/configs/tegra_defconfig
> >>> b/arch/arm/configs/tegra_defconfig
> >>>
> >>> +CONFIG_BRCMFMAC=m
> >>
> >> Why does this need to be a module? Everything else in tegra_defconfig is
> >> built-in, and it'd be nice to be consistent here. Built-in makes
> >> net-booting new kernels from U-Boot much easier, since there aren't any
> >> modules to copy.
> >
> > network drivers (especially wifi) are often modules because they need firmwares.
>
> So I certainly see that WiFi modules may need firmware.
>
> But I don't see why that should imply they must be modules; they should
> be able to defer their firmware loading until the firmware is available.

The wifi driver will try to load the firmware form the filesystem in its
initialization. In some board, the filesystem is on the SD/MMC card, and
if the wifi card is initialized before that SD/MMC card, it can't read
the filesystem and can't get the firmware, since the SD/MMC card doesn't
be initialized yet. then the wifi driver's initialization will be
failed.
So the wifi driver are often built as modules.

>
> > I'm not sure if the kernel can compile them in every case. Our RT2x00 is an
> > example (which also needs a defconfig entry btw) but brcmfmac also needs it as
> > modinfo shows. Beside that, I don't think you want to netboot using wifi and u-
> > boot because this needs a huge wireless framework which u-boot doesn't have.
>
> I net-boot using a USB wired Ethernet adapter. The issue isn't that I
> want to use wireless from U-Boot, but rather than it's easy to download
> the zImage and .dtb using U-Boot since they're just copied to RAM, but
> getting a bunch of modules into a filesystem on the target before
> booting the kernel is more painful.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at [vger.kernel.org]


--
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 [vger.kernel.org]
Please read the FAQ at [www.tux.org]

On 07/05/2012 09:08 PM, Wei Ni wrote:
> On Fri, 2012-07-06 at 03:59 +0800, Stephen Warren wrote:
>> On 07/04/2012 03:34 AM, Wei Ni wrote:
>>> New options enabled:
>>> * WIRELESS: (dependency)
>>> * CFG80211: (dependency)
>>> * WLAN: (dependency)
>>> * BRCMFMAC: wlan driver, enable as module.
>>
>>> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
>>
>>> +CONFIG_BRCMFMAC=m
>>
>> Why does this need to be a module? Everything else in tegra_defconfig is
>> built-in, and it'd be nice to be consistent here. Built-in makes
>> net-booting new kernels from U-Boot much easier, since there aren't any
>> modules to copy.
>>
>> When I built a kernel with this series, I observed the following:
>>
>> CONFIG_BRCMFMAC=m
>>
>> * Neither Cardhu nor Ventana auto-load the module. When the module is
>> manually modprobe'd, I still see no wireless device being created.
>>
>> CONFIG_BRCMFMAC=y
>>
>> * Cardhu: No wireless device created. I do see some kernel spew such as
>> "mmc1: queuing unknown CIS tuple 0x80" which I believe is the SDIO
>> device being probed, but I don't see any Linux device being created.
>>
>> * Ventana: There's a 60s hang during boot, I believe related to the BRCM
>> driver, since the hang doesn't occur without the series.
>>
>> In summary, this series doesn't work at all for me. Can you please
>> explain what you tested and how? Are there any differences between the
>> various Cardhu and Ventana board revisions and/or the 2 different
>> wireless cards possible on Cardhu that'd explain this?
>
> I have verified this patch, it can work on these boards.
> The t30/t20 version on my Cardhu and Ventana is A02, the wireless chip
> is bcm4329. I didn't test on other boards, and I'm not sure if the
> bcm4330 can work.
> When you test, you need to copy the latest brcmfmac firmware to the
> filesystem.
> Please get it from:
> [linuxwireless.org]
>
> You can run "ifconfig -a" to show the "wlan0" device.

Yes, I realized this after Marc mentioned the firmware loading.

I did copy the firmware from our Linux4Tegra releases, but that made no
difference. I'll try again with the different firmware version you
emailed me downstream (although I'm not sure why there are multiple
versions of the firmware...)
--
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 [vger.kernel.org]
Please read the FAQ at [www.tux.org]