linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Kalle Valo <kvalo@codeaurora.org>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 0/1] rtl8xxxu (mac80211) driver for rtl8188[cr]u/rtl8192cu/rtl8723au
Date: Tue, 08 Sep 2015 17:01:31 -0400	[thread overview]
Message-ID: <wrfjvbbkaams.fsf@redhat.com> (raw)
In-Reply-To: <55EC71DB.7060007@lwfinger.net> (Larry Finger's message of "Sun, 6 Sep 2015 12:03:23 -0500")

Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 09/06/2015 09:43 AM, Kalle Valo wrote:
>> Jes.Sorensen@redhat.com writes:
>>
>>> Per default only devices I have actually tested will be enabled. If
>>> you are interested in trying it out with other 8188cu/8188ru/819[12]cu
>>> dongles, you need to enable CONFIG_RTL8XXXU_UNTESTED. Please report
>>> test results back to me.
>>>
>>> Note if you enable this driver, it may clash with CONFIG_RTL8192U,
>>> CONFIG_R8723AU, and CONFIG_RTL8192CU (rtlwifi). Please pay attention
>>> to which module you load and/or use modprobe blacklists.
>>
>> May clash? So how does this work in practise? Is the clash referring
>> CONFIG_RTL8XXXU_UNTESTED enabled or disabled?
>>
>> I think we should only have one driver automatically supporting certain
>> hardware, and not have a driver randomly chosen and forcing users to use
>> a blacklist.
>
> I agree, in principle, but there will be difficulties in the
> implementation, at least in the short term.
>
> At the moment, the only driver that has a conflict with rtl8xxxu is
> rtl8192cu. Although rtl8xxxu is surprisingly more stable that
> rtl8192cu, the latter has more features, which is may be the reason
> for better stability. Driver rtl8xxxu does not handle any 40 MHz
> channels, nor can it become an AP either with hostapd or with
> NetworkManager. For those reasons, rtl819cu has to remain the standard
> driver for RTL81{88,92}CU devices until rtl8xxxu is improved. Anyone
> that wants to try the new driver will need to use blacklists.

I do not fully agree on this. In my testing I found rtl8192cu rather
unstable, to the point of not being usable. It would lock up for me
after a short while. I have seen this happen with mulitple different
adapters. I suspect this is the reason why drivers/staging/rtl8192u is
still sitting in the kernel tree.

It is true the rtl8xxxu doesn't support 40MHz channels, but reality is
few people actually use them since it's almost impossible to get free
channel access without clashes these days. Now I still intend to add
support for 40MHz, it has just not been on the top of the priority list
so far. Finding a place to test it is kinda hard when you live in the
middle of a city like New York :)

My take is that the majority of users mostly care about station support
and for them rtl8xxxu will be much preferred to rtl8192cu.

Basically I don't think there is a one solution fits all to this.
Whether we like it, we will have to accept that there are going to be
multiple drivers around for these chips for a while.

Cheers,
Jes

  parent reply	other threads:[~2015-09-08 21:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-30 21:02 [PATCH v2 0/1] rtl8xxxu (mac80211) driver for rtl8188[cr]u/rtl8192cu/rtl8723au Jes.Sorensen
2015-08-30 21:02 ` [PATCH 1/1] New driver: rtl8xxxu (mac80211) Jes.Sorensen
2015-09-06 14:59   ` Kalle Valo
2015-09-06 17:06     ` Larry Finger
2015-09-07  1:41       ` Jes Sorensen
2015-09-07  1:40     ` Jes Sorensen
2015-09-07 13:20       ` Kalle Valo
2015-09-07 21:08         ` Jes Sorensen
2015-09-06 14:43 ` [PATCH v2 0/1] rtl8xxxu (mac80211) driver for rtl8188[cr]u/rtl8192cu/rtl8723au Kalle Valo
2015-09-06 17:03   ` Larry Finger
2015-09-07  9:06     ` Kalle Valo
2015-09-07 15:35       ` Larry Finger
2015-09-08 21:04         ` Jes Sorensen
2015-09-08 21:13       ` Jes Sorensen
2015-09-08 21:01     ` Jes Sorensen [this message]
2015-09-09 10:51       ` Bruno Randolf
2015-09-07  1:45   ` Jes Sorensen
2015-09-07  4:24     ` Jes Sorensen
2015-09-07  8:53       ` Kalle Valo
2015-09-07  9:17     ` Kalle Valo
2015-09-08 21:24       ` Jes Sorensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wrfjvbbkaams.fsf@redhat.com \
    --to=jes.sorensen@redhat.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).