<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/net/wireless/rtl818x, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/net/wireless/rtl818x?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/net/wireless/rtl818x?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2015-10-14T10:33:10Z</updated>
<entry>
<title>rtlwifi: rtl818x: Move drivers into new realtek directory</title>
<updated>2015-10-14T10:33:10Z</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2015-09-07T20:59:16Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f1d2b4d338bf090296f67830025228872fd52513'/>
<id>urn:sha1:f1d2b4d338bf090296f67830025228872fd52513</id>
<content type='text'>
Now that a new mac80211-based driver for Realtek devices has been submitted,
it is time to reorganize the directories. Rather than having directories
rtlwifi and rtl818x be in drivers/net/wireless/, they will now be in
drivers/net/wireless/realtek/. This change simplifies the directory
structure, but does not result in any configuration changes that are
visable to the user.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>mac80211: convert HW flags to unsigned long bitmap</title>
<updated>2015-06-10T14:05:36Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-06-02T19:39:54Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=30686bf7f5b3c30831761e188a6e3cb33580fa48'/>
<id>urn:sha1:30686bf7f5b3c30831761e188a6e3cb33580fa48</id>
<content type='text'>
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.

This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.

The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>rtl818x_pci: fix response rate may be incorrect.</title>
<updated>2014-10-07T18:48:37Z</updated>
<author>
<name>Andrea Merello</name>
<email>andrea.merello@gmail.com</email>
</author>
<published>2014-10-06T18:23:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=79ee65659e116a49c81f63480a7672b7cbafa323'/>
<id>urn:sha1:79ee65659e116a49c81f63480a7672b7cbafa323</id>
<content type='text'>
Currently the allowed "respose rate" set (rates for HW generated frames
like ACKs) is the same as the basic rate set.

The HW will use the higher allowed response rate that is lower than the
rate of the received frame.

This is more or less what IEEE80211 mandates, but I missed the fact
that IEEE80211 also says that whenever it happens that for a modulation
class there is no any rate in the basic rates set, then the response rate
set shall include also all the mandatory rates for that modulation class.

This patch adds mandatory OFDM rates to the allowed response rate set if
no OFDM rate is included in the basic rate set.

Depending by the AP, I faced cases in which this patch seems to cause a
noticeable perfomance improvement.

- With my usual test AP there is no particular perfomance difference.
- With a prism54/hostapd AP this patch causes RX thoughput increase from
  about 5Mbps to about 20Mbps.

Hopefully this patch may help people that faced performance regression wrt
the old staging driver.

Signed-off-by: Andrea Merello &lt;andrea.merello@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>rtl818x_pci: add RSSI information for rtl8187SE</title>
<updated>2014-09-26T21:06:51Z</updated>
<author>
<name>andrea.merello</name>
<email>andrea.merello@gmail.com</email>
</author>
<published>2014-09-20T17:45:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8084bb0369b9924ecc775ce1c7050bc75ca016f3'/>
<id>urn:sha1:8084bb0369b9924ecc775ce1c7050bc75ca016f3</id>
<content type='text'>
This patch makes the driver to report signal strength information
to mac80211 for rtl8187se boards.

It differs from my previous RFT patch:
http://marc.info/?l=linux-wireless&amp;m=140155388332534&amp;w=2
because:
- I have now a working rtl8187se card, so I could serve my RFT by myself. :)
- CCK measurement code has changed a bit, but it does basically the same things.
- OFDM measurement method is changed because the older method reported incorrect
  measures, at least for signals stronger than -40dBm).

CCK measurement seems quite good. OFDM seems less accurate, but this is the
same as the "reference" staging driver dose. I wanted not to change things just
to make measures of _one_ (my) card a bit more close to what _I_ (in my setup)
expected..

IMHO results are still good enough to justify reporting signal in dBm rather than in
"unspecified" units, so this is what this patch actually does.

Results of my tests with a working rtl8187se card connected with coaxes and
various RF attenuators to my AP are:

Input (approx) | CCK meas | OFDM meas
--------------------------------------
      -30dBm   |  -32dBm  |  -31dBm
      -40dBm   |  -40dBm  |  -41dBm
      -50dBm   |  -50dBm  |  -55dBm
      -60dBm   |  -59dBm  |  -63dBm
      -70dBm   |  -69dBm  |  -73dBm
      -80dBm   |  -79dBm  |  -83dBm

Also some real-field tests has been done (no coax, packets in the air) for the CCK
measure method, and they resulted in reasonable values.

Thanks-to: Bernhard Schiffner &lt;bernhard@schiffner-limbach.de&gt; [ for real-field tests]
Signed-off-by: andrea.merello &lt;andrea.merello@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>PCI: Remove DEFINE_PCI_DEVICE_TABLE macro use</title>
<updated>2014-08-12T18:15:14Z</updated>
<author>
<name>Benoit Taine</name>
<email>benoit.taine@lip6.fr</email>
</author>
<published>2014-08-08T13:56:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=9baa3c34ac4e27f7e062f266f50cc5dbea26a6c1'/>
<id>urn:sha1:9baa3c34ac4e27f7e062f266f50cc5dbea26a6c1</id>
<content type='text'>
We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to
meet kernel coding style guidelines.  This issue was reported by checkpatch.

A simplified version of the semantic patch that makes this change is as
follows (http://coccinelle.lip6.fr/):

// &lt;smpl&gt;

@@
identifier i;
declarer name DEFINE_PCI_DEVICE_TABLE;
initializer z;
@@

- DEFINE_PCI_DEVICE_TABLE(i)
+ const struct pci_device_id i[]
= z;

// &lt;/smpl&gt;

[bhelgaas: add semantic patch]
Signed-off-by: Benoit Taine &lt;benoit.taine@lip6.fr&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</content>
</entry>
<entry>
<title>rtl818x: use pci_zalloc_consistent</title>
<updated>2014-08-08T22:57:29Z</updated>
<author>
<name>Joe Perches</name>
<email>joe@perches.com</email>
</author>
<published>2014-08-08T21:24:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=504e3b4f5a210057419fe7a2ea3a0b5b3bc15aa1'/>
<id>urn:sha1:504e3b4f5a210057419fe7a2ea3a0b5b3bc15aa1</id>
<content type='text'>
Remove the now unnecessary memset too.

Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Cc: "John W. Linville" &lt;linville@tuxdriver.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>rtl818x_pci: fix pci probe returns success when it fails</title>
<updated>2014-07-01T18:26:27Z</updated>
<author>
<name>Andrea Merello</name>
<email>andrea.merello@gmail.com</email>
</author>
<published>2014-06-30T16:19:40Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c1084e026b4fe73fcc54f82d6a6bd26d9372d583'/>
<id>urn:sha1:c1084e026b4fe73fcc54f82d6a6bd26d9372d583</id>
<content type='text'>
There are several exit path from the PCI probe function.
Some of them, that are taken in case of errors, forget to set the "err"
variable, that is returned by the probe function.
This can lead to the kernel thinking the probe function succeeds while it
didn't, and this in turn causes extra calls to the "remove" function.

This patch fix this problem by ensuring "err" variable is assigned to a proper
non-zero value in each exit path.

Signed-off-by: Andrea Merello &lt;andrea.merello@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>rtl818x_pci: handle broken PIO mapping</title>
<updated>2014-07-01T18:26:27Z</updated>
<author>
<name>Andrea Merello</name>
<email>andrea.merello@gmail.com</email>
</author>
<published>2014-06-30T16:19:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f4cf628781f802ecf5efa0ceb5e81a2f80dea5b8'/>
<id>urn:sha1:f4cf628781f802ecf5efa0ceb5e81a2f80dea5b8</id>
<content type='text'>
All boards supported by this driver could work using PIO or MMIO for accessing
registers.
This driver tries to access HW by using MMIO, and, if this fails for somewhat
reason, the driver tries to fall back to PIO mode.

MMIO-mode is straightforward on all boards.
PIO-mode is straightforward on rtl8180 only.

On rtl8185 and rtl8187se boards not all registers are directly available in PIO
mode (they are paged).

On rtl8185 there are two pages and it is known how to switch page.
PIO mode works, except for only one access to a register out of default page,
recently added by me in the initialization code with patch:
rtl818x_pci: Fix rtl8185 excessive IFS after CTS-to-self
This can be easily fixed to work in both cases (MMIO and PIO).

On rtl8187se, for a number of reasons, there is much more work to do to fix PIO
access.
PIO access is currently broken on rtl8187se, and it never worked.

This patch fixes the said register write for rtl8185 and makes the driver to
fail cleanly if PIO mode is attempted with rtl8187se boards.

While doing this, I converted also a couple of printk(KERN_ERR) to dev_err(), in
order to make checkpatch happy.

Signed-off-by: Andrea Merello &lt;andrea.merello@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>rtl8180: disable buggy rate fallback mechanism</title>
<updated>2014-07-01T18:26:27Z</updated>
<author>
<name>Andrea Merello</name>
<email>andrea.merello@gmail.com</email>
</author>
<published>2014-06-30T16:19:10Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=fe67bcd4c8407f12664cf45cc4bbd86d951515f2'/>
<id>urn:sha1:fe67bcd4c8407f12664cf45cc4bbd86d951515f2</id>
<content type='text'>
Currently the driver configures mac80211 to provide two rates for each TX frame:
One initial rate and one alternate fallback rate, each one with its retry count.

HW does not support fully this: rtl8180 doesn't have support for rate scaling at
all, and rtl8185/rtl8187SE supports it in a way that does not fit with mac80211:
The HW does automatically fall back to the next lower rate, and only a lower
limit can be specified, so the HW may TX also on rates in between the two rates
specified by mac80211.  Furthermore only the total TX retry count can be
specified for each packet, while the number of TX attempts before scaling rate
can be configured only globally (not per each packet).

Currently the driver sets the HW auto rate fallback mechanism to quickly scale
rate after a couple of retries, and it uses the alternate rate requested by
mac80211 as fallback limit rate (and it does this even wrongly).

The HW indeed will behave differently than what mac80211 mandates, that is
probably undesirable, and the reported TX retry count may not refer to what
mac80211 thinks, and this could fool mac80211.

This patch makes the driver to declare to mac80211 to support only one rate
configuration for each packet, and it does disable the HW auto rate fallback
mechanism, relying only on SW and letting mac80211 to do all by itself.

This should ensure correct operation and fairness respect to mac80211.
Indeed here tests with iperf do not show significant performance differences.

Signed-off-by: Andrea Merello &lt;andrea.merello@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
<entry>
<title>rtl8180: fix incorrect TX retry.</title>
<updated>2014-07-01T18:26:27Z</updated>
<author>
<name>Andrea Merello</name>
<email>andrea.merello@gmail.com</email>
</author>
<published>2014-06-30T16:18:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=81129fce7e4fc60fce616c53510699b093d87e26'/>
<id>urn:sha1:81129fce7e4fc60fce616c53510699b093d87e26</id>
<content type='text'>
HW is programmed with wrong retry count value for TX:

Mac80211 passes to driver the number of times the TX should be attempted.
The HW, instead, wants the number of time the TX should be retried if it fails
the first time (assuming we have to TX it at least one time).

This patch correct this.

Signed-off-by: Andrea Merello &lt;andrea.merello@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
</feed>
