Hi!
In preparation to be submitted upstream I started to clean up a huge
pile of patches for rt2x00 we have been carrying along for quite a
while (some for more than half a decade!).
Some of them are fixes, most importantly Serge Vasilugin fixed setting
the HT20/HT40 filter which got us much closer to the expected
performance when using HT40 modes.
And also a lot of new added hardware support:
Gabor Juhos wrote code for Rt3883 WiSoC.
Daniel Golle implemented support for Rt3352 by designs with external PA
as well as for boards using a 20MHz crystal instead of the usual 40MHz.
Serge Vasilugin contributed support for the Rt5350 WiSoC.
Michel Stempin, Felix Fietkau and John Crispin have been helping with
cleaning up things and putting away legal doubts.
Please review and comment, so we can get those patches merged!
Cheers
Daniel
The following changes since commit cc75c577806a53893122829d91cb122b51643a2d:
mwifiex: get rid of global save_adapter and sdio_work (2017-01-12 16:49:18 +0200)
are available in the git repository at:
https://github.com/dangowrt/linux.git rt2x00-from-openwrt
for you to fetch changes up to fb8832d1896475059c964c75ab4baaf94199143c:
rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable bit (2017-01-13 04:17:57 +0100)
----------------------------------------------------------------
Claudio Mignanti (1):
rt2x00: rt2x00pci: set PCI MWI only if supported
Daniel Golle (2):
rt2x00: support for for RT3352 with external PA
rt2x00: add support for RT3352 with 20MHz crystal
Felix Fietkau (1):
rt2x00: fix rf id for RT3352
Gabor Juhos (34):
rt2x00: rt2800lib: move rt2800_drv_data declaration into rt2800lib.h
rt2x00: rt2800lib: introduce RT2800_HAS_HIGH_SHARED_MEM flag
rt2x00: rt2800: serialize shared memory access
rt2x00: rt2800lib: fix beacon generation on RT3593
rt2x00: rt2800lib: add hw_beacon_count field to struct rt2800_drv_data
rt2x00: rt2800lib: init additional beacon offset registers
rt2x00: rt2800lib: fix max supported beacon count for RT3593
rt2x00: allow to build rt2800soc module for RT3883
rt2x00: rt2800lib: enable support for RT3883
rt2x00: rt2800lib: add rf_vals for RF3853
rt2x00: rt2800lib: enable VCO calibration for RF3853
rt2x00: rt2800lib: add channel configuration function for RF3853
rt2x00: rt2800lib: enable RF3853 support
rt2x00: rt2800lib: add MAC register initialization for RT3883
rt2x00: rt2800soc: fix rt2800soc_disable_radio for RT3883
rt2x00: rt2800lib: add BBP register initialization for RT3883
rt2x00: rt2800lib: add RFCSR initialization for RT3883
rt2x00: rt2800lib: use the extended EEPROM map for RT3883
rt2x00: rt2800lib: force rf type to RF3853 on RT3883
rt2x00: rt2800lib: add channel configuration code for RT3883
rt2x00: rt2800lib: fix txpower_to_dev function for RT3883
rt2x00: rt2800lib: use correct txpower calculation function for RT3883
rt2x00: rt2800lib: hardcode txmixer gain values to zero for RT3883
rt2x00: rt2800lib: use correct [RT]XWI size for RT3883
rt2x00: rt2800lib: use correct beacon base for RT3883
rt2x00: rt2800lib: use correct beacon count for RT3883
rt2x00: rt2800lib: fix antenna configuration for RT3883
rt2x00: rt2800lib: fix LNA gain configuration for RT3883
rt2x00: rt2800lib: fix VGC setup for RT3883
rt2x00: rt2800lib: fix EEPROM LNA validation for RT3883
rt2x00: rt2800lib: fix txpower compensation for RT3883
rt2x00: rt2800lib: enable RT2800_HAS_HIGH_SHARED_MEM for RT3883
rt2x00: rt2800lib: use high memory for beacons on RT3883
rt2x00: rt2800mmio: add a workaround for spurious TX_FIFO_STATUS interrupts
Michel Stempin (1):
rt2x00: add support for RT5350 WiSoC
Serge Vasilugin (1):
rt2x00 correctly set ht20/ht40 filter
evaxige (1):
rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable bit
drivers/net/wireless/ralink/rt2x00/Kconfig | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800.h | 79 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 1006 ++++++++++++++++++++++-
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 63 ++
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 98 ++-
drivers/net/wireless/ralink/rt2x00/rt2800mmio.h | 4 +
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 14 +
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 12 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 31 +
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 10 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 7 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 8 +-
drivers/net/wireless/ralink/rt2x00/rt2x00pci.c | 2 +
13 files changed, 1254 insertions(+), 82 deletions(-)
On Fri, Jan 13, 2017 at 05:17:23PM +0100, Daniel Golle wrote:
> On Fri, Jan 13, 2017 at 04:59:59PM +0100, Johannes Berg wrote:
> >
> > > The advantage of pull requests is that author information can be
> > > preserved more easily. Running git format-patch results in most
> > > patches
> > > having wrong SMTP sender information due to the assumption that the
> > > patch author is the same person also submitting the patch.
> > > So in practise, this would either require changing the From: (and
> > > thus
> > > Author) to myself or having most mails eaten by anti-spam measures
> > > due
> > > to non-matching SPF which prohibits my SMTP to send mail on behalf of
> > > the original authors of the patches.
> > >
> >
> > This is completely untrue. If the first line of the *body* of the email
> > is "From: ..." then this is preserved as the author information by git
> > am, and doing so is also the default in git format-patch/send-email
> > when the author doesn't match the email configuration.
>
> Thanks for the clarification, I'll then submit the patches via
> git format-patch.
I posted all patches on the mailing list and bundled them up on
patchwork.
https://patchwork.kernel.org/bundle/dangole/rt2x00-from-openwrt/
Cheers
Daniel
Hi Kalle,
On Fri, Jan 13, 2017 at 12:46:56PM +0200, Kalle Valo wrote:
> Daniel Golle <[email protected]> writes:
> > ...
> > Please review and comment, so we can get those patches merged!
>
> No pull requests, please. Instead send these as patches, easier to
> review and actually also easier for me to merge.
The advantage of pull requests is that author information can be
preserved more easily. Running git format-patch results in most patches
having wrong SMTP sender information due to the assumption that the
patch author is the same person also submitting the patch.
So in practise, this would either require changing the From: (and thus
Author) to myself or having most mails eaten by anti-spam measures due
to non-matching SPF which prohibits my SMTP to send mail on behalf of
the original authors of the patches.
How do you suggest to handle this situation?
Cheers
Daniel
On Fri, Jan 13, 2017 at 04:59:59PM +0100, Johannes Berg wrote:
>
> > The advantage of pull requests is that author information can be
> > preserved more easily. Running git format-patch results in most
> > patches
> > having wrong SMTP sender information due to the assumption that the
> > patch author is the same person also submitting the patch.
> > So in practise, this would either require changing the From: (and
> > thus
> > Author) to myself or having most mails eaten by anti-spam measures
> > due
> > to non-matching SPF which prohibits my SMTP to send mail on behalf of
> > the original authors of the patches.
> >
>
> This is completely untrue. If the first line of the *body* of the email
> is "From: ..." then this is preserved as the author information by git
> am, and doing so is also the default in git format-patch/send-email
> when the author doesn't match the email configuration.
Thanks for the clarification, I'll then submit the patches via
git format-patch.
Cheers
Daniel
Hi
On Fri, Jan 13, 2017 at 04:50:32AM +0100, Daniel Golle wrote:
> Please review and comment, so we can get those patches merged!
As already pointed by Kalle posting patches to mailing list is better
way for review. Posing patches is easy with git-format-patch and
git-send-email. Ideally patch series should not be long, let say no more
than 30 patches - I suggest to split this into two series: second one
for RT3853 support and first one for other patches.
> evaxige (1):
> rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable bit
I think I would prefer to remove:
WARN_ON_ONCE(bcn_num != rt2x00dev->intf_beaconing);
line instead of this patch. Other patches looks ok after quick glance.
I think you can post them as normal PATCH in the topic (not as RFC).
Thanks
Stanislaw
Stanislaw Gruszka <[email protected]> writes:
> Hi
>
> On Fri, Jan 13, 2017 at 04:50:32AM +0100, Daniel Golle wrote:
>> Please review and comment, so we can get those patches merged!
>
> As already pointed by Kalle posting patches to mailing list is better
> way for review. Posing patches is easy with git-format-patch and
> git-send-email. Ideally patch series should not be long, let say no more
> than 30 patches - I suggest to split this into two series: second one
> for RT3853 support and first one for other patches.
Even 30 patches in a set is quite a lot. I think the pain point is
somewhere about 10-12 patches, anything longer than that and most people
lost interest looking at the patches in detail.
--
Kalle Valo
On Friday, January 13, 2017 4:46:30 PM CET Daniel Golle wrote:
> On Fri, Jan 13, 2017 at 12:46:56PM +0200, Kalle Valo wrote:
> > Daniel Golle <[email protected]> writes:
> > > ...
> > > Please review and comment, so we can get those patches merged!
> >
> > No pull requests, please. Instead send these as patches, easier to
> > review and actually also easier for me to merge.
>
> The advantage of pull requests is that author information can be
> preserved more easily. Running git format-patch results in most patches
> having wrong SMTP sender information due to the assumption that the
> patch author is the same person also submitting the patch.
> So in practise, this would either require changing the From: (and thus
> Author) to myself or having most mails eaten by anti-spam measures due
> to non-matching SPF which prohibits my SMTP to send mail on behalf of
> the original authors of the patches.
>
> How do you suggest to handle this situation?
>
>From what I know, git format-patch and send-email [0] will add a second
FROM: in the email's body with the author of the commit automatically
(if author isn't you). This is what it did, when I posted the apm821xx
patches on lede-dev [1] (Look at the additional "FROM: Chris Blake ..."
line in these patches. Whereas the mail came from my address).
The MTA (MDA, ...) will use the first FROM: (your address) whereas git will
use the FROM in the mail body (so the patch will be correctly attributed to
the original patch author). If you don't want to bother the original
authors, you can look at the --suppress-cc=author option and enable --dry-run
on git send-email.
I would say, just give it a "dry".
(Sadly, I didn't find any documentation for this feature.
But I know it worked back then and it should be fine with SPF.)
Regards,
Christian
[0] <https://git-scm.com/docs/git-send-email>
[1] <http://lists.infradead.org/pipermail/lede-dev/2016-July/001865.html>
> The advantage of pull requests is that author information can be
> preserved more easily. Running git format-patch results in most
> patches
> having wrong SMTP sender information due to the assumption that the
> patch author is the same person also submitting the patch.
> So in practise, this would either require changing the From: (and
> thus
> Author) to myself or having most mails eaten by anti-spam measures
> due
> to non-matching SPF which prohibits my SMTP to send mail on behalf of
> the original authors of the patches.
>
This is completely untrue. If the first line of the *body* of the email
is "From: ..." then this is preserved as the author information by git
am, and doing so is also the default in git format-patch/send-email
when the author doesn't match the email configuration.
johannes
Daniel Golle <[email protected]> writes:
> In preparation to be submitted upstream I started to clean up a huge
> pile of patches for rt2x00 we have been carrying along for quite a
> while (some for more than half a decade!).
> Some of them are fixes, most importantly Serge Vasilugin fixed setting
> the HT20/HT40 filter which got us much closer to the expected
> performance when using HT40 modes.
>
> And also a lot of new added hardware support:
> Gabor Juhos wrote code for Rt3883 WiSoC.
> Daniel Golle implemented support for Rt3352 by designs with external PA
> as well as for boards using a 20MHz crystal instead of the usual 40MHz.
> Serge Vasilugin contributed support for the Rt5350 WiSoC.
> Michel Stempin, Felix Fietkau and John Crispin have been helping with
> cleaning up things and putting away legal doubts.
>
> Please review and comment, so we can get those patches merged!
No pull requests, please. Instead send these as patches, easier to
review and actually also easier for me to merge.
--
Kalle Valo