linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: linux-wireless@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: Support for RTL8188FU
Date: Tue, 10 Mar 2020 15:48:09 +0100	[thread overview]
Message-ID: <20200310144809.se2oqvlnnh55fhfd@linutronix.de> (raw)
In-Reply-To: <9c6717de-5ffc-47dc-6db7-7e070cbc41b9@lwfinger.net>

On 2020-03-04 12:16:54 [-0600], Larry Finger wrote:
> 
> I have no further advice. There are quite likely a number of routines that
> will differ as the 8188FU chip is quite likely a lot different from the
> 8188EU, even though both are 802.11n devices.

That is more complicated than I assumed. Even the "generic" hal layer is
different. Sometimes there are additional bits, sometimes the bits are
moved (to/from the HW-specific hal layer), sometimes the bits the are
different (like BIT0|BIT1 vs BIT1). Without having any kind of
documentation I can't even tell how essential the difference is.

Right now I went function by function and compared the code and *hoped*
that I didn't miss anything. I get USB errors later and I can't tell if
there is something that I missed/did wrong _or_ did not yet modify. I'm
worried that by the time I'm done, I did something wrong and no idea
where to look for the bug.

I stumbled over the version define:
The driver on github is
|include/rtw_version.h:#define DRIVERVERSION "v5.2.2.4_25483.20171222"

and mine is
|include/rtw_version.h:#define DRIVERVERSION "v5.7.4_33085.20190419"

Going by the date, they are more than a year apart. (Side note: the
driver in staging is from 2013.)

Is it possible to obtain a more recent version of the 8188EU driver from
realtek? That should ease the integration of the "two" drivers since the
generic bits should be the same…

What would be the challenges to get the 8188f Realtek driver upstream?
Looking at the todo list for the staging driver, it is mostly clean up
and checkpatch kind of thing. The more difficult/non mechanic task is to
convince the driver to use lib80211/mac80211 layer.

> Larry

Sebastian

  reply	other threads:[~2020-03-10 14:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01 16:03 Support for RTL8188FU Sebastian Andrzej Siewior
2019-10-01 16:47 ` Larry Finger
2019-10-01 17:46   ` Sebastian Andrzej Siewior
2019-10-01 18:52     ` Larry Finger
2019-10-01 20:48       ` Sebastian Andrzej Siewior
2020-03-04 10:21       ` Sebastian Andrzej Siewior
2020-03-04 18:16         ` Larry Finger
2020-03-10 14:48           ` Sebastian Andrzej Siewior [this message]
2020-03-10 14:54             ` Greg Kroah-Hartman

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=20200310144809.se2oqvlnnh55fhfd@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=Larry.Finger@lwfinger.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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).