The following patch series is aimed at improving the stability
of the rtl8192ce driver, with a bit of cleanup thrown in.
thanks,
Mike
Mike McCormack (8):
rtlwifi: Synchronize IRQ after disabling it
rtlwifi: Remove set_rfpowerstate_inprogress
rtlwifi: Store loop index in local variable
rtlwifi: Run IPS leave work in a tasklet
rtlwifi: Don't block interrupts in spinlocks
rtlwifi: Assign rx buffer ownership to hardware last
rtlwifi: Use write barrier when assigning ownership
rtlwifi: Fix logic in rx_interrupt
drivers/net/wireless/rtlwifi/pci.c | 41 ++++++++++++++----------
drivers/net/wireless/rtlwifi/ps.c | 45 +++++++++++---------------
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 12 ++----
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 2 +
drivers/net/wireless/rtlwifi/rtl8192cu/phy.c | 2 -
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 14 ++------
drivers/net/wireless/rtlwifi/wifi.h | 2 +-
8 files changed, 55 insertions(+), 64 deletions(-)
--
1.7.4.1
On 24 May 2011 01:49, Larry Finger <[email protected]> wrote:
> Are you using wireless-testing for your patches? There are some patches
> pending in John's queue, but your patches got offsets and fuzz in files that
> those patches do not touch. Everything seemed to apply despite the fuzz and
> everything compiled, but I always get nervous about patches with anything
> more serious than offsets.
I originally developed these patches against the staging-next tree, then
ported them over to the wireless-testing tree. They are on top of this commit:
commit 1e4541b73b33f9918255f36a60bdeacfae4fdb9d
Author: John W. Linville <[email protected]>
Date: Thu May 19 13:54:47 2011 -0400
Revert "mac80211_hwsim driver support userspace frame tx/rx"
This reverts commit 444c7896bf5b0c613fd58c8f08e60a8714eb7f05.
I have done a fair bit of work on the rtl8192e driver in Greg KH's staging-next,
and reused ideas from work I've done there in this series.
Do you think it would be worthwhile to merge rtl8192e support into rtlwifi
or is there something critical that will prevent that from working well?
> Patches 3, 4, 6 and 8 do modify driver rtlwifi, but patches 1 and 7 change
> driver rtl8192ce. Similarly, #2 changes rtl8192ce, rtl8192cu, and rtl8192se,
> and #5 changes rtl8192ce and rtl8192se. The subject line for the patch
> should indicate the driver that gets modified. I usually do it as "rtlwifi:
> rtl8192ce: blah-blah", etc. The rtlwifi is included even though it does not
> get changed by the patch.
OK, I'll try follow your convention with the next series.
> I do not see anything serious in the body of the patches and I expect that I
> will be giving them an ACK, but I want to test first.
Great. Should I resend with your Acked-by: ?
thanks,
Mike
On 05/24/2011 08:35 AM, Mike McCormack wrote:
> On 24 May 2011 01:49, Larry Finger<[email protected]> wrote:
>
>> Are you using wireless-testing for your patches? There are some patches
>> pending in John's queue, but your patches got offsets and fuzz in files that
>> those patches do not touch. Everything seemed to apply despite the fuzz and
>> everything compiled, but I always get nervous about patches with anything
>> more serious than offsets.
>
> I originally developed these patches against the staging-next tree, then
> ported them over to the wireless-testing tree. They are on top of this commit:
>
> commit 1e4541b73b33f9918255f36a60bdeacfae4fdb9d
> Author: John W. Linville<[email protected]>
> Date: Thu May 19 13:54:47 2011 -0400
>
> Revert "mac80211_hwsim driver support userspace frame tx/rx"
>
> This reverts commit 444c7896bf5b0c613fd58c8f08e60a8714eb7f05.
>
> I have done a fair bit of work on the rtl8192e driver in Greg KH's staging-next,
> and reused ideas from work I've done there in this series.
>
> Do you think it would be worthwhile to merge rtl8192e support into rtlwifi
> or is there something critical that will prevent that from working well?
>
>> Patches 3, 4, 6 and 8 do modify driver rtlwifi, but patches 1 and 7 change
>> driver rtl8192ce. Similarly, #2 changes rtl8192ce, rtl8192cu, and rtl8192se,
>> and #5 changes rtl8192ce and rtl8192se. The subject line for the patch
>> should indicate the driver that gets modified. I usually do it as "rtlwifi:
>> rtl8192ce: blah-blah", etc. The rtlwifi is included even though it does not
>> get changed by the patch.
>
> OK, I'll try follow your convention with the next series.
>
>> I do not see anything serious in the body of the patches and I expect that I
>> will be giving them an ACK, but I want to test first.
>
> Great. Should I resend with your Acked-by: ?
Yes, an ACKed-by: would be fine. You should also mark them with a Cc for stable,
particularly the ones that change the interrupt locking. All of the patches are
OK, and I have submitted the equivalent ones for rtl8192se. In addition, similar
changes were folded into the rtl8192de driver that will be submitted soon.
I have not really looked at the driver for the RTL8192E device, other to note
that rtl8192e and rtl8192se both claim PCI ID 10ec:8192, but different drivers
are needed. It seems that the only way to distinguish them is from byte 8
(revisionid) in PCI configuration space. As I just received that information
this morning, I have not finished thinking it through; however, I expect that we
will need a shim driver something like b43-pci-bridge (part of ssb) to get the
proper driver loaded for that ID. Please advise me of any other technique to
resolve the conflict. I need to fix that for 2.6.40.
As rtl8192e will be needed for some time, we should be looking at two things:
(1) using rtlwifi for its PCI operations, and (2) switching it from its own
softmac code to mac80211 so that it can be moved to mainline. Both of these
tasks will have relatively low priority for me.
I do not have an RTL8192E chip at the moment, but I will get one soon as they
are ~$10 on E-bay.
Larry
On 05/23/2011 08:53 AM, Mike McCormack wrote:
> The following patch series is aimed at improving the stability
> of the rtl8192ce driver, with a bit of cleanup thrown in.
>
> thanks,
>
> Mike
>
> Mike McCormack (8):
> rtlwifi: Synchronize IRQ after disabling it
> rtlwifi: Remove set_rfpowerstate_inprogress
> rtlwifi: Store loop index in local variable
> rtlwifi: Run IPS leave work in a tasklet
> rtlwifi: Don't block interrupts in spinlocks
> rtlwifi: Assign rx buffer ownership to hardware last
> rtlwifi: Use write barrier when assigning ownership
> rtlwifi: Fix logic in rx_interrupt
>
> drivers/net/wireless/rtlwifi/pci.c | 41 ++++++++++++++----------
> drivers/net/wireless/rtlwifi/ps.c | 45 +++++++++++---------------
> drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 1 +
> drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 12 ++----
> drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 2 +
> drivers/net/wireless/rtlwifi/rtl8192cu/phy.c | 2 -
> drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 14 ++------
> drivers/net/wireless/rtlwifi/wifi.h | 2 +-
> 8 files changed, 55 insertions(+), 64 deletions(-)
Thanks for your changes. I have not yet tested them, but I noticed a few points
that I want you to address.
Are you using wireless-testing for your patches? There are some patches pending
in John's queue, but your patches got offsets and fuzz in files that those
patches do not touch. Everything seemed to apply despite the fuzz and everything
compiled, but I always get nervous about patches with anything more serious than
offsets.
Patches 3, 4, 6 and 8 do modify driver rtlwifi, but patches 1 and 7 change
driver rtl8192ce. Similarly, #2 changes rtl8192ce, rtl8192cu, and rtl8192se, and
#5 changes rtl8192ce and rtl8192se. The subject line for the patch should
indicate the driver that gets modified. I usually do it as "rtlwifi: rtl8192ce:
blah-blah", etc. The rtlwifi is included even though it does not get changed by
the patch.
I do not see anything serious in the body of the patches and I expect that I
will be giving them an ACK, but I want to test first.
Thanks,
Larry