rtl8192ce

rtl8192ce

[Lobachevskii Vitalii]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

Hello,

The RTL8192CE device seems to work fine without any firmware, so you may
make it fully optional, removing dependency on FW_LOADER. Of course that
require some patching, but if I understood the driver internals
correctly, simple complete(&rtlpriv->firmware_loading_complete); would
be enough when firmware loading machinery is unavailable, that is, when
request_firmware_nowait returns -EINVAL (currently that may only happen
in improperly configured or patched kernels, like Linux-libre; see
attached messages for more information)

Of course I will try to fix Linux-libre “deblobbing” technique, as it
should never break anything that may work without a firmware. But
anyway, if a device and its driver may work without a certain kernel
feature, that feature should not be selected, I think.

Lobachevskii Vitalii


[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 1320 bytes --]

From: number Zero <silverunicorn2011@yandex.ru>
To: linux-libre@fsfla.org
Subject: Inaccurate deblobbing breaks rtl8192ce
Date: Sun, 14 Aug 2016 01:16:48 +0300
Message-ID: <321381b3-5dea-f16a-56cb-11120d4a38ef@yandex.ru>

The rtl8192ce driver as present in linux-libre don’t work for me at all.
However, after I made it to ignore the EINVAL error from the
reject_firmware_nowait function (in
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c), it works fine.
I could send you the patch, but don’t think that’s the right solution.
Really, are there any reasons for reject_firmware_nowait to return
-EINVAL? Original function, request_firmware_nowait, returns non-zero
only in extreme conditions, like out-of-memory or module being unloaded.
Unlike request_firmware, it doesn’t fail when firmware is absent. So
shouldn’t the reject_firmware_nowait function behave as if the requested
firmware merely absent?


[-- Attachment #3: Attached Message --]
[-- Type: message/rfc822, Size: 3507 bytes --]

From: Alexandre Oliva <lxoliva@fsfla.org>
To: number Zero <silverunicorn2011@yandex.ru>
Cc: linux-libre@fsfla.org
Subject: Re: Inaccurate deblobbing breaks rtl8192ce
Date: Thu, 18 Aug 2016 16:14:01 -0300
Message-ID: <ortwehao06.fsf@livre.home>

Hi,

Thanks for your report!

On Aug 13, 2016, number Zero <silverunicorn2011@yandex.ru> wrote:

> However, after I made it to ignore the EINVAL error from the
> reject_firmware_nowait function (in
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c), it works fine.

Interesting.  Can you check that this remains true even after a full
power cycle, as in, that it's not a blob loaded by a previous blobbed
kernel that remains it to work in your setting?  (if you never had the
blob around, or never used a blobbed kernel, just say so, and I'll be
happy enough about the conclusion ;-)

> Really, are there any reasons for reject_firmware_nowait to return
> -EINVAL?

Yes.  It the error code to indicate to the caller that the firmware
loading functionality is not avaialble.  It indicates the callback
supplied by the caller will not be called, so the caller itself should
take care of e.g. returning any temporary memory the callback would have
released.

If the driver works even if request_firmware_nowait returns such an
error, then it ought to tolerate this return code.

> So shouldn’t the reject_firmware_nowait function behave as if the
> requested firmware merely absent?

Given the multiple cases in which drivers were "surprised" by this
return code, I guess we could try to rework reject_firmware_nowait so as
to actually call the callback, signalling the unsuccessful completion of
the request.  Would you like to give that a try?

Or perhaps you'd prefer to report the bug to the rtl8192ce maintainers,
so that they could fix their driver so as to work (as it should) even
when the firmware loading configuration option is disabled?

Thanks,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: rtl8192ce

[Jes Sorensen]

Lobachevskii Vitalii <silverunicorn2011@yandex.ru> writes:
> Hello,
>
> The RTL8192CE device seems to work fine without any firmware, so you may
> make it fully optional, removing dependency on FW_LOADER. Of course that
> require some patching, but if I understood the driver internals
> correctly, simple complete(&rtlpriv->firmware_loading_complete); would
> be enough when firmware loading machinery is unavailable, that is, when
> request_firmware_nowait returns -EINVAL (currently that may only happen
> in improperly configured or patched kernels, like Linux-libre; see
> attached messages for more information)
>
> Of course I will try to fix Linux-libre “deblobbing” technique, as it
> should never break anything that may work without a firmware. But
> anyway, if a device and its driver may work without a certain kernel
> feature, that feature should not be selected, I think.

The realtek devices all require firmwere to operate correctly,
including the 8192c series. There are a bunch of commands flying back
and forth between the driver and the firmware.

If your device happens to work without loading the firmware then you
have an old firmware blob loaded.

At least this is the case for the USB version of the device, and I find
it highly unlikely the PCIe version is any different.

Trying to remove the firmware loading error is just plain silly.

Jes

Re: rtl8192ce

[Larry Finger]

On 08/25/2016 08:17 AM, Jes Sorensen wrote:
> Lobachevskii Vitalii <silverunicorn2011@yandex.ru> writes:
>> Hello,
>>
>> The RTL8192CE device seems to work fine without any firmware, so you may
>> make it fully optional, removing dependency on FW_LOADER. Of course that
>> require some patching, but if I understood the driver internals
>> correctly, simple complete(&rtlpriv->firmware_loading_complete); would
>> be enough when firmware loading machinery is unavailable, that is, when
>> request_firmware_nowait returns -EINVAL (currently that may only happen
>> in improperly configured or patched kernels, like Linux-libre; see
>> attached messages for more information)
>>
>> Of course I will try to fix Linux-libre “deblobbing” technique, as it
>> should never break anything that may work without a firmware. But
>> anyway, if a device and its driver may work without a certain kernel
>> feature, that feature should not be selected, I think.
>
> The realtek devices all require firmwere to operate correctly,
> including the 8192c series. There are a bunch of commands flying back
> and forth between the driver and the firmware.
>
> If your device happens to work without loading the firmware then you
> have an old firmware blob loaded.
>
> At least this is the case for the USB version of the device, and I find
> it highly unlikely the PCIe version is any different.
>
> Trying to remove the firmware loading error is just plain silly.

I have not bothered my Realtek contacts with such a question, but I have a 
plausible explanation. If an RTL8192CE functions without loading external 
firmware, it is because the device has minimal function built in the default 
firmware. Mostly this rudimentary firmware is used to boot the device and to 
download the firmware for complex wireless communication. Rudimentary wifi 
functions would be needed for wake-on-lan operations. The fact that Realtek has 
never implemented WOL for the 8192C chips is highly suggestive that they do not 
function very well in that capacity.

If the RTL8192CE actually runs without loading external firmware, then I am 
quite sure that it will be restricted to 802.11g at the most, and more likely 
802.11b. If it handles any 802.11n capabilities, then that firmware will 
certainly not have any of the bug fixes applied to the firmware since the 
earliest release.

You are certainly allowed to configure your system any way you want, but please 
do not send any such "fixes" to the kernel sources. They will NEVER be accepted!

Configuring a kernel without firmware loading capacity is indeed silly.

Larry

Re: rtl8192ce

[Jes Sorensen]

Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 08/25/2016 08:17 AM, Jes Sorensen wrote:
>> Lobachevskii Vitalii <silverunicorn2011@yandex.ru> writes:
>> The realtek devices all require firmwere to operate correctly,
>> including the 8192c series. There are a bunch of commands flying back
>> and forth between the driver and the firmware.
>>
>> If your device happens to work without loading the firmware then you
>> have an old firmware blob loaded.
>>
>> At least this is the case for the USB version of the device, and I find
>> it highly unlikely the PCIe version is any different.
>>
>> Trying to remove the firmware loading error is just plain silly.
>
> I have not bothered my Realtek contacts with such a question, but I
> have a plausible explanation. If an RTL8192CE functions without
> loading external firmware, it is because the device has minimal
> function built in the default firmware. Mostly this rudimentary
> firmware is used to boot the device and to download the firmware for
> complex wireless communication. Rudimentary wifi functions would be
> needed for wake-on-lan operations. The fact that Realtek has never
> implemented WOL for the 8192C chips is highly suggestive that they do
> not function very well in that capacity.
>
> If the RTL8192CE actually runs without loading external firmware, then
> I am quite sure that it will be restricted to 802.11g at the most, and
> more likely 802.11b. If it handles any 802.11n capabilities, then that
> firmware will certainly not have any of the bug fixes applied to the
> firmware since the earliest release.
>
> You are certainly allowed to configure your system any way you want,
> but please do not send any such "fixes" to the kernel sources. They
> will NEVER be accepted!
>
> Configuring a kernel without firmware loading capacity is indeed silly.

Makes perfect sense, but as you also correctly point out, it means the
device actually is running some firmware, but we have no idea what state
or version it is. Trying to run a device with this level of firmware is
both risky and makes it hard to rely on correct operation.

Of course it also makes this whole ostrich process even more pointless,
since the device is in fact running firmware - pretending it isn't is
just silly.

One more thing, yes you can apply this patch to your own degraded
kernel, but if you ship it, kindle remove ALL email addresses of any
driver authors in it. None of us wants to waste our time on bug reports
because of this.

If you truly want to run your system without firmware, I hear there are
great bargains for NE2000 and 3c501 cards on ebay :)

Jes