[PATCH] ARM: exynos_defconfig: add options to make wifi usable

[PATCH] ARM: exynos_defconfig: add options to make wifi usable

[Michal Suchanek]

The Exynos defconfig includes mwifiex sdio support which is present on
some of the Exynos boards.

For the WiFi to be usable two extra options are needed. Usermode
firmware helper to load out-of-kernel firmware and wireless extensions
so the interface can be configured with wireless-tools.

Signed-off-by: Michal Suchanek <hramrach@gmail.com>
---
 arch/arm/configs/exynos_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index d034c96..5d4ee83f 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -42,6 +42,7 @@ CONFIG_IP_PNP_BOOTP=y
 CONFIG_IP_PNP_RARP=y
 CONFIG_WIRELESS=y
 CONFIG_CFG80211=y
+CONFIG_CFG80211_WEXT=y
 CONFIG_MWIFIEX=y
 CONFIG_MWIFIEX_SDIO=y
 CONFIG_RFKILL_REGULATOR=y
@@ -49,6 +50,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_PROC_DEVICETREE=y
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
 CONFIG_DMA_CMA=y
 CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_BLK_DEV_LOOP=y
-- 
2.1.4

Re: [PATCH] ARM: exynos_defconfig: add options to make wifi usable

[Javier Martinez Canillas]

Hello Michal,

On 05/11/2015 12:22 PM, Michal Suchanek wrote:
> The Exynos defconfig includes mwifiex sdio support which is present on
> some of the Exynos boards.
> 
> For the WiFi to be usable two extra options are needed. Usermode

Your subject line and the commit message are somehow misleading since
these options are needed to make the WiFi usable with your current setup.

> firmware helper to load out-of-kernel firmware and wireless extensions

For example, this is only needed if the in-kernel fw loader is not
able to find the firmware but isn't needed if the fw is for example
in an initial ramdisk and the kernel is able to load it, built in the
kernel or if the mwifiex driver is built as a module.

> so the interface can be configured with wireless-tools.
>

And wireless extensions is deprecated AFAIK and is only needed for old
user-space since most tools should had been converted to use the netlink
based CONFIG_CFG80211 interface instead.

I'm booting a debian jessie and have WiFi working without CFG80211_WEXT
for example.

That doesn't mean that I'm against your patch (I'm always happy to enable
more config options if that makes the defconfig more useful) but the commit
message should be accurate about why a change has to be done.

> Signed-off-by: Michal Suchanek <hramrach@gmail.com>
> ---

Best regards,
Javier

Re: [PATCH] ARM: exynos_defconfig: add options to make wifi usable

[Michal Suchanek]

On 11 May 2015 at 13:25, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Michal,
>
> On 05/11/2015 12:22 PM, Michal Suchanek wrote:
>> The Exynos defconfig includes mwifiex sdio support which is present on
>> some of the Exynos boards.
>>
>> For the WiFi to be usable two extra options are needed. Usermode
>
> Your subject line and the commit message are somehow misleading since
> these options are needed to make the WiFi usable with your current setup.
>
>> firmware helper to load out-of-kernel firmware and wireless extensions
>
> For example, this is only needed if the in-kernel fw loader is not
> able to find the firmware but isn't needed if the fw is for example
> in an initial ramdisk and the kernel is able to load it, built in the
> kernel or if the mwifiex driver is built as a module.

I am not sure how is including the firmware in a ramdisk going to
improve things over including it in my root filesystem. As far as I am
aware it does not make any difference for the kernel.

The firmware is not included in the kernel tree nor configured as
extra firmware option in the defconfig, either. Otherwise the firmware
loader would supposedly find the firmware and we would not have this
discussion.

The mwifiex driver is configured as built-in in the defconfig so what
happens when the driver is built as a module is not relevant for this
defconfig.

>
>> so the interface can be configured with wireless-tools.
>>
>
> And wireless extensions is deprecated AFAIK and is only needed for old
> user-space since most tools should had been converted to use the netlink
> based CONFIG_CFG80211 interface instead.
>
> I'm booting a debian jessie and have WiFi working without CFG80211_WEXT
> for example.

I'm booting Debian Jessie as well and for me WiFi is not working
without CFG80211_WEXT for another example.

So it might be that some tools have migrated to another interface but
at first glance I have no idea what those tools might be in Debian so
for me the WiFi is unusable without wireless extensions.

>
> That doesn't mean that I'm against your patch (I'm always happy to enable
> more config options if that makes the defconfig more useful) but the commit
> message should be accurate about why a change has to be done.

Do you have some specific suggestions about improvements to the commit message?

Thanks

Michal

Re: [PATCH] ARM: exynos_defconfig: add options to make wifi usable

[Javier Martinez Canillas]

On 05/11/2015 02:23 PM, Michal Suchanek wrote:
> On 11 May 2015 at 13:25, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> Hello Michal,
>>
>> On 05/11/2015 12:22 PM, Michal Suchanek wrote:
>>> The Exynos defconfig includes mwifiex sdio support which is present on
>>> some of the Exynos boards.
>>>
>>> For the WiFi to be usable two extra options are needed. Usermode
>>
>> Your subject line and the commit message are somehow misleading since
>> these options are needed to make the WiFi usable with your current setup.
>>
>>> firmware helper to load out-of-kernel firmware and wireless extensions
>>
>> For example, this is only needed if the in-kernel fw loader is not
>> able to find the firmware but isn't needed if the fw is for example
>> in an initial ramdisk and the kernel is able to load it, built in the
>> kernel or if the mwifiex driver is built as a module.
> 
> I am not sure how is including the firmware in a ramdisk going to
> improve things over including it in my root filesystem. As far as I am
> aware it does not make any difference for the kernel.
> 

My understanding is that an initial ramdisk is mounted very early in the
kernel boot process so even a module-less initamfs that only contains a
set of firmwares is enough to make the request_firmware() of built in
drivers to succeed.

While having those in your root filesystem located in a storage media,
will make the request_firmware() to fail since the rootfs is mounted much
later after built in drivers' probe functions have already been executed.

But now you make me doubt if I'm wrong on my assumptions and I should
check if that's the case.

> The firmware is not included in the kernel tree nor configured as
> extra firmware option in the defconfig, either. Otherwise the firmware
> loader would supposedly find the firmware and we would not have this
> discussion.
> 
> The mwifiex driver is configured as built-in in the defconfig so what
> happens when the driver is built as a module is not relevant for this
> defconfig.
>

Yes, these two (fw built-in the kernel and driver as a module) were just
other examples of setups that don't require the fallback user-mode helper.

At least I would mention in the commit message that given the driver is
built-in, no fw is built-in the kernel couldn't be assumed that a initram
fs will be used, it is better to enable the user-space fw loading fallback.

>>
>>> so the interface can be configured with wireless-tools.
>>>
>>
>> And wireless extensions is deprecated AFAIK and is only needed for old
>> user-space since most tools should had been converted to use the netlink
>> based CONFIG_CFG80211 interface instead.
>>
>> I'm booting a debian jessie and have WiFi working without CFG80211_WEXT
>> for example.
> 
> I'm booting Debian Jessie as well and for me WiFi is not working
> without CFG80211_WEXT for another example.
> 
> So it might be that some tools have migrated to another interface but
> at first glance I have no idea what those tools might be in Debian so
> for me the WiFi is unusable without wireless extensions.
>

I'm using the iw package [0] which according to the package description:

"will become the canonical command line tool for wireless configuration
and iwconfig/wireless-tools will no longer be required"

So I guess iw uses the new netlink based interface while wireless-tools
is still using the old ioctl based API.

That's something that could also be mentioned in the commit message.

>>
>> That doesn't mean that I'm against your patch (I'm always happy to enable
>> more config options if that makes the defconfig more useful) but the commit
>> message should be accurate about why a change has to be done.
> 
> Do you have some specific suggestions about improvements to the commit message?
>

I already mentioned them above. My point is that the subject and commit message
said that WiFi is unusable without these options and that's not the case for all
the setups.

> Thanks
> 
> Michal
>

Best regards,
Javier

[0]: https://packages.debian.org/jessie/iw

Re: [PATCH] ARM: exynos_defconfig: add options to make wifi usable

[Michal Suchanek]

Hello,

On 11 May 2015 at 15:28, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> On 05/11/2015 02:23 PM, Michal Suchanek wrote:
>> On 11 May 2015 at 13:25, Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk> wrote:
>>> Hello Michal,
>>>
>>> On 05/11/2015 12:22 PM, Michal Suchanek wrote:
>>>> The Exynos defconfig includes mwifiex sdio support which is present on
>>>> some of the Exynos boards.
>>>>
>>>> For the WiFi to be usable two extra options are needed. Usermode
>>>
>>> Your subject line and the commit message are somehow misleading since
>>> these options are needed to make the WiFi usable with your current setup.
>>>
>>>> firmware helper to load out-of-kernel firmware and wireless extensions
>>>
>>> For example, this is only needed if the in-kernel fw loader is not
>>> able to find the firmware but isn't needed if the fw is for example
>>> in an initial ramdisk and the kernel is able to load it, built in the
>>> kernel or if the mwifiex driver is built as a module.
>>
>> I am not sure how is including the firmware in a ramdisk going to
>> improve things over including it in my root filesystem. As far as I am
>> aware it does not make any difference for the kernel.
>>
>
> My understanding is that an initial ramdisk is mounted very early in the
> kernel boot process so even a module-less initamfs that only contains a
> set of firmwares is enough to make the request_firmware() of built in
> drivers to succeed.
>
> While having those in your root filesystem located in a storage media,
> will make the request_firmware() to fail since the rootfs is mounted much
> later after built in drivers' probe functions have already been executed.
>
> But now you make me doubt if I'm wrong on my assumptions and I should
> check if that's the case.

I cannot try this myself because u-boot either does not like the
initramfs generated by Debian or the initramfs does not fit in the
reserved space and is corrupted by subsequently loaded device tree.

>
>> The firmware is not included in the kernel tree nor configured as
>> extra firmware option in the defconfig, either. Otherwise the firmware
>> loader would supposedly find the firmware and we would not have this
>> discussion.
>>
>> The mwifiex driver is configured as built-in in the defconfig so what
>> happens when the driver is built as a module is not relevant for this
>> defconfig.
>>
>
> Yes, these two (fw built-in the kernel and driver as a module) were just
> other examples of setups that don't require the fallback user-mode helper.
>
> At least I would mention in the commit message that given the driver is
> built-in, no fw is built-in the kernel couldn't be assumed that a initram
> fs will be used, it is better to enable the user-space fw loading fallback.

ok

>
>>>
>>>> so the interface can be configured with wireless-tools.
>>>>
>>>
>>> And wireless extensions is deprecated AFAIK and is only needed for old
>>> user-space since most tools should had been converted to use the netlink
>>> based CONFIG_CFG80211 interface instead.
>>>
>>> I'm booting a debian jessie and have WiFi working without CFG80211_WEXT
>>> for example.
>>
>> I'm booting Debian Jessie as well and for me WiFi is not working
>> without CFG80211_WEXT for another example.
>>
>> So it might be that some tools have migrated to another interface but
>> at first glance I have no idea what those tools might be in Debian so
>> for me the WiFi is unusable without wireless extensions.
>>
>
> I'm using the iw package [0] which according to the package description:
>
> "will become the canonical command line tool for wireless configuration
> and iwconfig/wireless-tools will no longer be required"

Notice the future tense. It's not the case for Jessie. So as far as
Debian is concerned wireless extensions are going to be the standard
interface for some years to come.

>
> So I guess iw uses the new netlink based interface while wireless-tools
> is still using the old ioctl based API.
>
> That's something that could also be mentioned in the commit message.

The commit message does mention wireless-tools.

I tried to install the wi tool and it indeed does work. However, when
managing baroque wireless settings a connection manager is pretty much
a requirement. I use wicd which can only use wireless extensions as
kernel interface. wpa_supplicant itself can use netlink but the
management functions like network listing are done over wext.

I also tried installing network-manager because it supposedly works
with the new netlink interface. Unfortunately, it does not support
connecting to the network I use which uses wpa-enterprise
authentication, at least using the nmtui frontend.

>
>>>
>>> That doesn't mean that I'm against your patch (I'm always happy to enable
>>> more config options if that makes the defconfig more useful) but the commit
>>> message should be accurate about why a change has to be done.
>>
>> Do you have some specific suggestions about improvements to the commit message?
>>
>
> I already mentioned them above. My point is that the subject and commit message
> said that WiFi is unusable without these options and that's not the case for all
> the setups.
>

And the point is that that with the defconfig as is the wifi is indeed
unusable due to lack of the userspace firmware helper and nearly so
due to lack of wireless extensions. It might be possible to connect to
some networks with just netlink but it's not quite obvious it would
work out of the box these days, still.

Given the limited length of the commit title this is the best one I
came up with.

Thanks

Michal

Re: [PATCH] ARM: exynos_defconfig: add options to make wifi usable

[Krzysztof Kozlowski]

2015-05-11 19:22 GMT+09:00 Michal Suchanek <hramrach@gmail.com>:
>
> The Exynos defconfig includes mwifiex sdio support which is present on
> some of the Exynos boards.
>
> For the WiFi to be usable two extra options are needed. Usermode
> firmware helper to load out-of-kernel firmware and wireless extensions
> so the interface can be configured with wireless-tools.
>
> Signed-off-by: Michal Suchanek <hramrach@gmail.com>
> ---
>  arch/arm/configs/exynos_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index d034c96..5d4ee83f 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -42,6 +42,7 @@ CONFIG_IP_PNP_BOOTP=y
>  CONFIG_IP_PNP_RARP=y
>  CONFIG_WIRELESS=y
>  CONFIG_CFG80211=y
> +CONFIG_CFG80211_WEXT=y

Hi,

No, the CFG80211_WEXT is the old interface. I think there were some
plans to mark it deprecated. Anyway it should not be enabled by
default and almost none of configs enable it.

>  CONFIG_MWIFIEX=y
>  CONFIG_MWIFIEX_SDIO=y
>  CONFIG_RFKILL_REGULATOR=y
> @@ -49,6 +50,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
>  CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_PROC_DEVICETREE=y
> +CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y

It is an fallback, not usual way of loading firmware. In typical cases
this should not be needed. Why Exynos defconfig should be exceptional
here?

Best regards,
Krzysztof