* [PATCH 0/9] rsi: code clean-up
From: Prameela Rani Garnepudi @ 2016-09-12 9:38 UTC (permalink / raw)
To: linux-wireless, kvalo, johannes.berg, hofrat
Cc: prameela.j04cs, prameela.garnepudi
*** BLURB HERE ***
Prameela Rani Garnepudi (9):
rsi: cleanup and added debug prints in file rsi_91x_core.c
rsi: Spelling and code format corrections in rsi_91x_debugfs.c
rsi: Added freeing of allocated buffers (sbands and dfsentry)
Cleanup (spelling mistakes, code format corrections,
empty lines after declaration)
rsi: code clean up in file rsi_91x_main.c
rsi: code cleanup in file rsi_91x_mgmt.c
rsi: code cleanup (spelling mistakes and new line after declaration)
in file rsi_91x_sdio.c Added developer name
rsi: zone changed for debug message and cleanup in file
rsi_91x_sdio_ops.c
rsi: code clean up and replaced ctrl message timeouts with macros in
file rsi_91x_usb.c
rsi: code cleanup in file rsi_91x_usb_ops.c
drivers/net/wireless/rsi/rsi_91x_core.c | 24 +++++++++++++----
drivers/net/wireless/rsi/rsi_91x_debugfs.c | 13 ++++-----
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 24 ++++++++++++-----
drivers/net/wireless/rsi/rsi_91x_main.c | 16 +++++------
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 30 +++++++++++----------
drivers/net/wireless/rsi/rsi_91x_sdio.c | 16 +++++------
drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 6 ++---
drivers/net/wireless/rsi/rsi_91x_usb.c | 42 ++++++++++++++++-------------
drivers/net/wireless/rsi/rsi_91x_usb_ops.c | 9 +++----
9 files changed, 104 insertions(+), 76 deletions(-)
--
2.4.11
^ permalink raw reply
* Re: [PATCH 1/3 v3] mac80211: RX BA support for sta max_rx_aggregation_subframes
From: Johannes Berg @ 2016-09-12 9:38 UTC (permalink / raw)
To: Maxim Altshul, linux-wireless; +Cc: kvalo
In-Reply-To: <1473673046.27358.0.camel@sipsolutions.net>
On Mon, 2016-09-12 at 11:37 +0200, Johannes Berg wrote:
>
> I fixed the indentation of the commit message, please note for the
> future.
>
Err, what? No, the *debug* message of course.
johannes
^ permalink raw reply
* Re: [PATCH 1/3 v3] mac80211: RX BA support for sta max_rx_aggregation_subframes
From: Johannes Berg @ 2016-09-12 9:37 UTC (permalink / raw)
To: Maxim Altshul, linux-wireless; +Cc: kvalo
In-Reply-To: <20160822141404.12814-1-maxim.altshul@ti.com>
On Mon, 2016-08-22 at 17:14 +0300, Maxim Altshul wrote:
> The ability to change the max_rx_aggregation frames is useful
> in cases of IOP.
>
> There exist some devices (latest mobile phones and some AP's)
> that tend to not respect a BA sessions maximum size (in Kbps).
> These devices won't respect the AMPDU size that was negotiated during
> associasion (even though they do respect the maximal number of
> packets).
>
> This violation is characterized by a valid number of packets in
> a single AMPDU. Even so, the total size will exceed the size
> negotiated
> during association.
>
> Eventually, this will cause some undefined behavior, which in turn
> causes the hw to drop packets, causing the throughput to plummet.
>
> This patch will make the subframe limitation to be held by each
> station,
> instead of being held only by hw.
>
> Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
>
Applied.
I fixed the indentation of the commit message, please note for the
future.
johannes
^ permalink raw reply
* Support of rtl8723bs
From: Hanno Zulla @ 2016-09-12 9:20 UTC (permalink / raw)
To: linux-wireless, Jes.Sorensen; +Cc: Larry.Finger, Bastien Nocera, anthony.wong
Hi Jes,
hello linux-wireless,
I'd like to know more about the current progress of rtl8723bs support
for Linux.
Googling and reading the mailing list archives found an older vendor driver
https://github.com/hadess/rtl8723bs
plus patches at
https://github.com/lwfinger/rtl8723bs
which both aren't ready for Linux according to
https://github.com/hadess/rtl8723bs/issues/96
According to
https://github.com/hadess/rtl8723bs/issues/98
there is a newer vendor driver from Realtek at
https://github.com/anthonywong/rtl8723bs
which Anthony wants to get ready for inclusion to the Ubuntu kernel.
But after reading
https://marc.info/?l=linux-wireless&m=146902477024130&w=2
it appears that even that newer vendor driver isn't ready for Jes's work.
Anyway, as an owner of such a device, I'd like to help somehow, and be
it as a guinea pig to test on my hardware. The newer vendor driver
crashed on Ubuntu' 4.4 sources and doesn't compile yet on Ubuntu 4.8-rc
sources.
https://github.com/anthonywong/rtl8723bs/issues/1
Kind regards,
Hanno
^ permalink raw reply
* Re: [PATCH v2] mac80211: Re-structure aqm debugfs output and include CoDel drops
From: Johannes Berg @ 2016-09-12 9:27 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <20160811151156.6485-1-toke@toke.dk>
> --- a/net/mac80211/debugfs_sta.c
> +++ b/net/mac80211/debugfs_sta.c
> @@ -109,6 +109,48 @@ static ssize_t sta_last_seq_ctrl_read(struct
> file *file, char __user *userbuf,
> }
> STA_OPS(last_seq_ctrl);
>
> +#define AQM_TXQ_ENTRY_LEN 130
> +
> +static ssize_t sta_aqm_read(struct file *file, char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct sta_info *sta = file->private_data;
> + struct ieee80211_local *local = sta->local;
> + char buf[AQM_TXQ_ENTRY_LEN*(IEEE80211_NUM_TIDS+1)], *p =
> buf;
>
This is very large, I think you should dynamically allocate it.
johannes
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Remove deprecated create_singlethread_workqueue
From: Johannes Berg @ 2016-09-12 9:21 UTC (permalink / raw)
To: Bhaktipriya Shridhar, David S. Miller
Cc: Tejun Heo, linux-wireless, netdev, linux-kernel
In-Reply-To: <20160830190507.GA11493@Karyakshetra>
On Wed, 2016-08-31 at 00:35 +0530, Bhaktipriya Shridhar wrote:
> The workqueue "cfg80211_wq" is involved in cleanup, scan and event
> related
> works. It queues multiple work items &rdev->event_work,
> &rdev->dfs_update_channels_wk,
> &wiphy_to_rdev(request->wiphy)->scan_done_wk,
> &wiphy_to_rdev(wiphy)->sched_scan_results_wk, which require strict
> execution ordering.
> Hence, an ordered dedicated workqueue has been used.
>
> Since it's a wireless driver, WQ_MEM_RECLAIM has been set to ensure
> forward progress under memory pressure.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-12 8:54 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Julia Lawall, linux-renesas-soc, joe, kernel-janitors,
Sergei Shtylyov, linux-pm, platform-driver-x86, linux-media,
linux-can, Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail,
Chien Tin Tung, linux-rdma, netdev, devel, alsa-devel,
linux-kernel, linux-fbdev, linux-wireless, Jason Gunthorpe,
tpmdd-devel, linux-scsi, linux-spi, linux-usb, linux-acpi
In-Reply-To: <20160911172105.GB5493@intel.com>
On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > Constify local structures.
> >
> > The semantic patch that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
>
> Just my two cents but:
>
> 1. You *can* use a static analysis too to find bugs or other issues.
> 2. However, you should manually do the commits and proper commit
> messages to subsystems based on your findings. And I generally think
> that if one contributes code one should also at least smoke test changes
> somehow.
>
> I don't know if I'm alone with my opinion. I just think that one should
> also do the analysis part and not blindly create and submit patches.
All of the patches are compile tested. And the individual patches are
submitted to the relevant maintainers. The individual commit messages
give a more detailed explanation of the strategy used to decide that the
structure was constifiable. It seemed redundant to put that in the cover
letter, which will not be committed anyway.
julia
>
> Anyway, I'll apply the TPM change at some point. As I said they were
> for better. Thanks.
>
> /Jarkko
>
> > // <smpl>
> > // The first rule ignores some cases that posed problems
> > @r disable optional_qualifier@
> > identifier s != {peri_clk_data,threshold_attr,tracer_flags,tracer};
> > identifier i != {s5k5baf_cis_rect,smtcfb_fix};
> > position p;
> > @@
> > static struct s i@p = { ... };
> >
> > @lstruct@
> > identifier r.s;
> > @@
> > struct s { ... };
> >
> > @used depends on lstruct@
> > identifier r.i;
> > @@
> > i
> >
> > @bad1@
> > expression e;
> > identifier r.i;
> > assignment operator a;
> > @@
> > (<+...i...+>) a e
> >
> > @bad2@
> > identifier r.i;
> > @@
> > &(<+...i...+>)
> >
> > @bad3@
> > identifier r.i;
> > declarer d;
> > @@
> > d(...,<+...i...+>,...);
> >
> > @bad4@
> > identifier r.i;
> > type T;
> > T[] e;
> > identifier f;
> > position p;
> > @@
> >
> > f@p(...,
> > (
> > (<+...i...+>)
> > &
> > e
> > )
> > ,...)
> >
> > @bad4a@
> > identifier r.i;
> > type T;
> > T *e;
> > identifier f;
> > position p;
> > @@
> >
> > f@p(...,
> > (
> > (<+...i...+>)
> > &
> > e
> > )
> > ,...)
> >
> > @ok5@
> > expression *e;
> > identifier r.i;
> > position p;
> > @@
> > e =@p i
> >
> > @bad5@
> > expression *e;
> > identifier r.i;
> > position p != ok5.p;
> > @@
> > e =@p (<+...i...+>)
> >
> > @rr depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5@
> > identifier s,r.i;
> > position r.p;
> > @@
> >
> > static
> > +const
> > struct s i@p = { ... };
> >
> > @depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5
> > disable optional_qualifier@
> > identifier rr.s,r.i;
> > @@
> >
> > static
> > +const
> > struct s i;
> > // </smpl>
> >
> > ---
> >
> > drivers/acpi/acpi_apd.c | 8 +++---
> > drivers/char/tpm/tpm-interface.c | 10 ++++----
> > drivers/char/tpm/tpm-sysfs.c | 2 -
> > drivers/cpufreq/intel_pstate.c | 8 +++---
> > drivers/infiniband/hw/i40iw/i40iw_uk.c | 6 ++---
> > drivers/media/i2c/tvp514x.c | 2 -
> > drivers/media/pci/ddbridge/ddbridge-core.c | 18 +++++++--------
> > drivers/media/pci/ngene/ngene-cards.c | 14 ++++++------
> > drivers/media/pci/smipcie/smipcie-main.c | 8 +++---
> > drivers/misc/sgi-xp/xpc_uv.c | 2 -
> > drivers/net/arcnet/com20020-pci.c | 10 ++++----
> > drivers/net/can/c_can/c_can_pci.c | 4 +--
> > drivers/net/can/sja1000/plx_pci.c | 20 ++++++++---------
> > drivers/net/ethernet/mellanox/mlx4/main.c | 4 +--
> > drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 -
> > drivers/net/ethernet/renesas/sh_eth.c | 14 ++++++------
> > drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 -
> > drivers/net/wireless/ath/dfs_pattern_detector.c | 2 -
> > drivers/net/wireless/intel/iwlegacy/3945.c | 4 +--
> > drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 2 -
> > drivers/platform/chrome/chromeos_laptop.c | 22 +++++++++----------
> > drivers/platform/x86/intel_scu_ipc.c | 6 ++---
> > drivers/platform/x86/intel_telemetry_debugfs.c | 2 -
> > drivers/scsi/esas2r/esas2r_flash.c | 2 -
> > drivers/scsi/hptiop.c | 6 ++---
> > drivers/spi/spi-dw-pci.c | 4 +--
> > drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 2 -
> > drivers/usb/misc/ezusb.c | 2 -
> > drivers/video/fbdev/matrox/matroxfb_g450.c | 2 -
> > lib/crc64_ecma.c | 2 -
> > sound/pci/ctxfi/ctatc.c | 2 -
> > sound/pci/hda/patch_ca0132.c | 10 ++++----
> > sound/pci/riptide/riptide.c | 2 -
> > 40 files changed, 110 insertions(+), 110 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 1/6] rtl8723au: remove declaration of unimplemented functions
From: Greg Kroah-Hartman @ 2016-09-12 8:14 UTC (permalink / raw)
To: Luca Ceresoli
Cc: devel, Jes Sorensen, linux-wireless, linux-kernel, Larry Finger
In-Reply-To: <1472821069-5437-1-git-send-email-luca@lucaceresoli.net>
On Fri, Sep 02, 2016 at 02:57:44PM +0200, Luca Ceresoli wrote:
> These functions have been declared without any implementation since
> the first commit (364e30ebd2dbaccba430c603da03e68746eb932a) and there
> has been no mention of them in following commits.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: devel@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Changes v1 -> v2:
> - improve the commit message.
> ---
> drivers/staging/rtl8723au/include/recv_osdep.h | 3 ---
> 1 file changed, 3 deletions(-)
File is no longer in my tree.
^ permalink raw reply
* Re: [PATCH v3 1/6] staging: rtl8723au: remove unimplemented functions declaration
From: Greg Kroah-Hartman @ 2016-09-12 8:14 UTC (permalink / raw)
To: Luca Ceresoli
Cc: devel, Jes Sorensen, linux-wireless, linux-kernel, Larry Finger
In-Reply-To: <1473179817-7277-1-git-send-email-luca@lucaceresoli.net>
On Tue, Sep 06, 2016 at 06:36:52PM +0200, Luca Ceresoli wrote:
> These functions have been declared without any implementation since
> the first commit (364e30ebd2dbaccba430c603da03e68746eb932a) and there
> has been no mention of them in following commits.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: devel@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
>
> Changes v2 -> v3:
> - add "staging: " prefix to commit message title.
>
> Changes v1 -> v2:
> - improve the commit message.
> ---
> drivers/staging/rtl8723au/include/recv_osdep.h | 3 ---
File is no longer in my tree :(
^ permalink raw reply
* Re: [PATCH] rtlbt: Add RTL8822BE Bluetooth device
From: Marcel Holtmann @ 2016-09-12 7:27 UTC (permalink / raw)
To: Larry Finger
Cc: Kalle Valo, devel, linux-wireless, linux-bluetooth,
陆朱伟
In-Reply-To: <1473433325-25311-1-git-send-email-Larry.Finger@lwfinger.net>
Hi Larry,
> The RTL8822BE is a new Realtek wifi and BT device. Support for the BT
> part is hereby added.
>
> As this device is similar to most of the other Realtek BT devices, the
> changes are minimal. The main difference is that the 8822BE needs a
> configuration file for enabling and disabling features. Thus code is
> added to select and load this configuration file. Although not needed
> at the moment, hooks are added for the other devices that might need
> such configuration files.
>
> One additional change is to the routine that tests that the project
> ID contained in the firmware matches the hardware. As the project IDs
> are not sequential, continuing to use the position in the array as the
> expected value of the ID would require adding extra unused entries in
> the table, and any subsequant rearrangment of the array would break the
> code. To fix these problems, the array elements now contain both the
> hardware ID and the expected value for the project ID.
>
> Signed-off-by: 陆朱伟 <alex_lu@realsil.com.cn>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/bluetooth/btrtl.c | 104 ++++++++++++++++++++++++++++++++++++++++------
> drivers/bluetooth/btrtl.h | 5 +++
> 2 files changed, 97 insertions(+), 12 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: support for QCA9377 SDIO (ath10k or ath6kl)
From: Valo, Kalle @ 2016-09-12 7:18 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath10k@lists.infradead.org, ath6kl@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <CAFBinCCObRokj=1rja7nZ6DKMgFWDZAtoWMBJrxmsuq0mLUxkg@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> is QCA planning to add SDIO support to ath10k or would this have to be
> done by a community developer?
I cannot really comment about company plans.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Johannes Berg @ 2016-09-12 6:43 UTC (permalink / raw)
To: Pedersen, Thomas, Ben Greear, linux-wireless
In-Reply-To: <38049c4f-da5b-a6ec-bcc4-c803197abcd7@qca.qualcomm.com>
On Wed, 2016-09-07 at 18:20 +0000, Pedersen, Thomas wrote:
> On 09/06/2016 12:07 PM, Ben Greear wrote:
> >
> > On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
> > >
> > > Some drivers (ath10k) report MCS 9 @ 20MHz, which
> > > technically isn't allowed. To get more meaningful value
> > > than 0 out of this however, just cap the bitrate for 20MHz
> > > to MCS 8.
> >
> > If it is actually reporting MCS9, why lie about it? Report it up
> > the stack as a proper value instead of hiding the issue?
>
> Good point, will send a v2 extrapolating the value to 86.5Mb/s.
That makes no sense either, IMHO.
Are you saying that ath10k actually somehow manages to use an invalid
bitrate over the air?!
It seems more likely that it's actually just misreporting what it's
doing, and thus the issue should be fixed in ath10k.
johannes
^ permalink raw reply
* Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
From: Johannes Berg @ 2016-09-12 6:41 UTC (permalink / raw)
To: Ben Greear, Valo, Kalle
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <57D2CB92.3020407@candelatech.com>
> > > - rcu_read_unlock();
> > > spin_unlock_bh(&ar->txqs_lock);
> > > + rcu_read_unlock();
> >
> > I'm no RCU expert but this isn't making any sense. Maybe it changes
> > timings on your kernel so that it hides the real problem?
>
> I'm not sure this fixed anything or not, it just seemed weird so I
> changed it.
>
> I was hoping someone that understood rcu locking would comment...
>
RCU is no "locking". The sooner you get over that notion, the better.
This therefore make no sense whatsoever.
In fact, you want to keep the RCU protected section *small*, so having
the spinlock inside hurts overall system performance.
johannes
^ permalink raw reply
* Request for brcmfmac4366c-pcie.bin
From: Rafał Miłecki @ 2016-09-12 5:22 UTC (permalink / raw)
To: Hante Meuleman, Arend Van Spriel, bcm-kernel-feedback-list
Cc: linux-wireless@vger.kernel.org, Hauke Mehrtens, Nathan Grennan
Hi,
Few months ago Hante added support for 4366c0 to the brcmfmac. There
are already few devices with this chipset on the market. We even have
some related bug report at kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=3D135321
Unfortunately the firmware for this chipset is still missing. Can you
build it and submit to linux-firmware.git, please?
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-11 19:11 UTC (permalink / raw)
To: Joe Perches
Cc: Julia Lawall, linux-renesas-soc, kernel-janitors, Sergei Shtylyov,
linux-pm, platform-driver-x86, linux-media, linux-can,
Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail, Chien Tin Tung,
linux-rdma, netdev, devel, alsa-devel, linux-kernel, linux-fbdev,
linux-wireless, Jason Gunthorpe, tpmdd-devel, linux-scsi,
linux-spi, linux-usb, linux-acpi
In-Reply-To: <1473616576.19464.10.camel@perches.com>
On Sun, 11 Sep 2016, Joe Perches wrote:
> On Sun, 2016-09-11 at 15:05 +0200, Julia Lawall wrote:
> > Constify local structures.
>
> Thanks Julia.
>
> A few suggestions & questions:
>
> Perhaps the script should go into scripts/coccinelle/
> so that future cases could be caught by the robot
> and commit message referenced by the patch instances.
OK.
> Can you please compile the files modified using the
> appropriate defconfig/allyesconfig and show the
I currently send patches for this issue only for files that compile using
the x86 allyesconfig.
> movement from data to const by using
> $ size <object>.new/old
> and include that in the changelogs (maybe next time)?
OK, thanks for the suggestion.
> Is it possible for a rule to trace the instances where
> an address of a struct or struct member is taken by
> locally defined and declared function call where the
> callee does not modify any dereferenced object?
>
> ie:
>
> struct foo {
> int bar;
> char *baz;
> };
>
> struct foo qux[] = {
> { 1, "description 1" },
> { 2, "dewcription 2" },
> [ n, "etc" ]...,
> };
>
> void message(struct foo *msg)
> {
> printk("%d %s\n", msg->bar, msg->baz);
> }
>
> where some code uses
>
> message(qux[index]);
>
> So could a coccinelle script change:
>
> struct foo qux[] = { to const struct foo quz[] = {
>
> and
>
> void message(struct foo *msg) to void message(const struct foo *msg)
Yes, this could be possible too.
Thanks for the feedback.
julia
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Joe Perches @ 2016-09-11 17:56 UTC (permalink / raw)
To: Julia Lawall, linux-renesas-soc
Cc: kernel-janitors, Sergei Shtylyov, linux-pm, platform-driver-x86,
linux-media, linux-can, Tatyana Nikolova, Shiraz Saleem,
Mustafa Ismail, Chien Tin Tung, linux-rdma, netdev, devel,
alsa-devel, linux-kernel, linux-fbdev, linux-wireless,
Jason Gunthorpe, tpmdd-devel, linux-scsi, linux-spi, linux-usb,
linux-acpi
In-Reply-To: <1473599168-30561-1-git-send-email-Julia.Lawall@lip6.fr>
On Sun, 2016-09-11 at 15:05 +0200, Julia Lawall wrote:
> Constify local structures.
Thanks Julia.
A few suggestions & questions:
Perhaps the script should go into scripts/coccinelle/
so that future cases could be caught by the robot
and commit message referenced by the patch instances.
Can you please compile the files modified using the
appropriate defconfig/allyesconfig and show the
movement from data to const by using
$ size <object>.new/old
and include that in the changelogs (maybe next time)?
Is it possible for a rule to trace the instances where
an address of a struct or struct member is taken by
locally defined and declared function call where the
callee does not modify any dereferenced object?
ie:
struct foo {
int bar;
char *baz;
};
struct foo qux[] = {
{ 1, "description 1" },
{ 2, "dewcription 2" },
[ n, "etc" ]...,
};
void message(struct foo *msg)
{
printk("%d %s\n", msg->bar, msg->baz);
}
where some code uses
message(qux[index]);
So could a coccinelle script change:
struct foo qux[] = { to const struct foo quz[] = {
and
void message(struct foo *msg) to void message(const struct foo *msg)
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Jarkko Sakkinen @ 2016-09-11 17:21 UTC (permalink / raw)
To: Julia Lawall
Cc: linux-renesas-soc, joe, kernel-janitors, Sergei Shtylyov,
linux-pm, platform-driver-x86, linux-media, linux-can,
Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail, Chien Tin Tung,
linux-rdma, netdev, devel, alsa-devel, linux-kernel, linux-fbdev,
linux-wireless, Jason Gunthorpe, tpmdd-devel, linux-scsi,
linux-spi, linux-usb, linux-acpi
In-Reply-To: <1473599168-30561-1-git-send-email-Julia.Lawall@lip6.fr>
On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> Constify local structures.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
Just my two cents but:
1. You *can* use a static analysis too to find bugs or other issues.
2. However, you should manually do the commits and proper commit
messages to subsystems based on your findings. And I generally think
that if one contributes code one should also at least smoke test changes
somehow.
I don't know if I'm alone with my opinion. I just think that one should
also do the analysis part and not blindly create and submit patches.
Anyway, I'll apply the TPM change at some point. As I said they were
for better. Thanks.
/Jarkko
> // <smpl>
> // The first rule ignores some cases that posed problems
> @r disable optional_qualifier@
> identifier s != {peri_clk_data,threshold_attr,tracer_flags,tracer};
> identifier i != {s5k5baf_cis_rect,smtcfb_fix};
> position p;
> @@
> static struct s i@p = { ... };
>
> @lstruct@
> identifier r.s;
> @@
> struct s { ... };
>
> @used depends on lstruct@
> identifier r.i;
> @@
> i
>
> @bad1@
> expression e;
> identifier r.i;
> assignment operator a;
> @@
> (<+...i...+>) a e
>
> @bad2@
> identifier r.i;
> @@
> &(<+...i...+>)
>
> @bad3@
> identifier r.i;
> declarer d;
> @@
> d(...,<+...i...+>,...);
>
> @bad4@
> identifier r.i;
> type T;
> T[] e;
> identifier f;
> position p;
> @@
>
> f@p(...,
> (
> (<+...i...+>)
> &
> e
> )
> ,...)
>
> @bad4a@
> identifier r.i;
> type T;
> T *e;
> identifier f;
> position p;
> @@
>
> f@p(...,
> (
> (<+...i...+>)
> &
> e
> )
> ,...)
>
> @ok5@
> expression *e;
> identifier r.i;
> position p;
> @@
> e =@p i
>
> @bad5@
> expression *e;
> identifier r.i;
> position p != ok5.p;
> @@
> e =@p (<+...i...+>)
>
> @rr depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5@
> identifier s,r.i;
> position r.p;
> @@
>
> static
> +const
> struct s i@p = { ... };
>
> @depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5
> disable optional_qualifier@
> identifier rr.s,r.i;
> @@
>
> static
> +const
> struct s i;
> // </smpl>
>
> ---
>
> drivers/acpi/acpi_apd.c | 8 +++---
> drivers/char/tpm/tpm-interface.c | 10 ++++----
> drivers/char/tpm/tpm-sysfs.c | 2 -
> drivers/cpufreq/intel_pstate.c | 8 +++---
> drivers/infiniband/hw/i40iw/i40iw_uk.c | 6 ++---
> drivers/media/i2c/tvp514x.c | 2 -
> drivers/media/pci/ddbridge/ddbridge-core.c | 18 +++++++--------
> drivers/media/pci/ngene/ngene-cards.c | 14 ++++++------
> drivers/media/pci/smipcie/smipcie-main.c | 8 +++---
> drivers/misc/sgi-xp/xpc_uv.c | 2 -
> drivers/net/arcnet/com20020-pci.c | 10 ++++----
> drivers/net/can/c_can/c_can_pci.c | 4 +--
> drivers/net/can/sja1000/plx_pci.c | 20 ++++++++---------
> drivers/net/ethernet/mellanox/mlx4/main.c | 4 +--
> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 -
> drivers/net/ethernet/renesas/sh_eth.c | 14 ++++++------
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 -
> drivers/net/wireless/ath/dfs_pattern_detector.c | 2 -
> drivers/net/wireless/intel/iwlegacy/3945.c | 4 +--
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 2 -
> drivers/platform/chrome/chromeos_laptop.c | 22 +++++++++----------
> drivers/platform/x86/intel_scu_ipc.c | 6 ++---
> drivers/platform/x86/intel_telemetry_debugfs.c | 2 -
> drivers/scsi/esas2r/esas2r_flash.c | 2 -
> drivers/scsi/hptiop.c | 6 ++---
> drivers/spi/spi-dw-pci.c | 4 +--
> drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 2 -
> drivers/usb/misc/ezusb.c | 2 -
> drivers/video/fbdev/matrox/matroxfb_g450.c | 2 -
> lib/crc64_ecma.c | 2 -
> sound/pci/ctxfi/ctatc.c | 2 -
> sound/pci/hda/patch_ca0132.c | 10 ++++----
> sound/pci/riptide/riptide.c | 2 -
> 40 files changed, 110 insertions(+), 110 deletions(-)
^ permalink raw reply
* [PATCH 21/26] rtlwifi: rtl818x: constify local structures
From: Julia Lawall @ 2016-09-11 13:06 UTC (permalink / raw)
To: Larry Finger
Cc: joe, kernel-janitors, Chaoming Li, Kalle Valo, linux-wireless,
netdev, linux-kernel
In-Reply-To: <1473599168-30561-1-git-send-email-Julia.Lawall@lip6.fr>
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches <joe@perches.com>.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
The semantic patch seems too long for a commit log, but is in the cover
letter.
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
index 47e32cb..e7b11b4 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
@@ -280,7 +280,7 @@ static struct rtl_mod_params rtl88ee_mod_params = {
.debug = DBG_EMERG,
};
-static struct rtl_hal_cfg rtl88ee_hal_cfg = {
+static const struct rtl_hal_cfg rtl88ee_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl88e_pci",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
index 4780bdc..87aa209 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
@@ -258,7 +258,7 @@ static struct rtl_mod_params rtl92ce_mod_params = {
.debug = DBG_EMERG,
};
-static struct rtl_hal_cfg rtl92ce_hal_cfg = {
+static const struct rtl_hal_cfg rtl92ce_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl92c_pci",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
index c6e09a1..0538a4d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
@@ -262,7 +262,7 @@ static struct rtl_mod_params rtl92de_mod_params = {
.debug = DBG_EMERG,
};
-static struct rtl_hal_cfg rtl92de_hal_cfg = {
+static const struct rtl_hal_cfg rtl92de_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8192de",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
index c31c6bf..ac299cb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c
@@ -262,7 +262,7 @@ static struct rtl_mod_params rtl92ee_mod_params = {
.debug = DBG_EMERG,
};
-static struct rtl_hal_cfg rtl92ee_hal_cfg = {
+static const struct rtl_hal_cfg rtl92ee_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl92ee_pci",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
index 31baca41..5e8e02d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
@@ -306,7 +306,7 @@ static struct rtl_mod_params rtl92se_mod_params = {
/* Because memory R/W bursting will cause system hang/crash
* for 92se, so we don't read back after every write action */
-static struct rtl_hal_cfg rtl92se_hal_cfg = {
+static const struct rtl_hal_cfg rtl92se_hal_cfg = {
.bar_id = 1,
.write_readback = false,
.name = "rtl92s_pci",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
index ff49a8c..89c828a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
@@ -276,7 +276,7 @@ static struct rtl_mod_params rtl8723e_mod_params = {
.disable_watchdog = false,
};
-static struct rtl_hal_cfg rtl8723e_hal_cfg = {
+static const struct rtl_hal_cfg rtl8723e_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8723e_pci",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
index 2101793..20b53f0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
@@ -276,7 +276,7 @@ static struct rtl_mod_params rtl8723be_mod_params = {
.ant_sel = 0,
};
-static struct rtl_hal_cfg rtl8723be_hal_cfg = {
+static const struct rtl_hal_cfg rtl8723be_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8723be_pci",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
index 4159f9b..22f687b1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
@@ -316,7 +316,7 @@ static struct rtl_mod_params rtl8821ae_mod_params = {
.disable_watchdog = 0,
};
-static struct rtl_hal_cfg rtl8821ae_hal_cfg = {
+static const struct rtl_hal_cfg rtl8821ae_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8821ae_pci",
^ permalink raw reply related
* [PATCH 08/26] iwlegacy: constify local structures
From: Julia Lawall @ 2016-09-11 13:05 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: joe, kernel-janitors, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1473599168-30561-1-git-send-email-Julia.Lawall@lip6.fr>
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches <joe@perches.com>.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
The semantic patch seems too long for a commit log, but is in the cover
letter.
drivers/net/wireless/intel/iwlegacy/3945.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/3945.c b/drivers/net/wireless/intel/iwlegacy/3945.c
index 209dc99..4db327a 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945.c
@@ -2671,7 +2671,7 @@ const struct il_ops il3945_ops = {
.send_led_cmd = il3945_send_led_cmd,
};
-static struct il_cfg il3945_bg_cfg = {
+static const struct il_cfg il3945_bg_cfg = {
.name = "3945BG",
.fw_name_pre = IL3945_FW_PRE,
.ucode_api_max = IL3945_UCODE_API_MAX,
@@ -2700,7 +2700,7 @@ static struct il_cfg il3945_bg_cfg = {
},
};
-static struct il_cfg il3945_abg_cfg = {
+static const struct il_cfg il3945_abg_cfg = {
.name = "3945ABG",
.fw_name_pre = IL3945_FW_PRE,
.ucode_api_max = IL3945_UCODE_API_MAX,
^ permalink raw reply related
* [PATCH 06/26] ath: constify local structures
From: Julia Lawall @ 2016-09-11 13:05 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: joe, kernel-janitors, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1473599168-30561-1-git-send-email-Julia.Lawall@lip6.fr>
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches <joe@perches.com>.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
The semantic patch seems too long for a commit log, but is in the cover
letter.
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 2f8136d..4100ffd 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -338,7 +338,7 @@ static bool dpd_set_domain(struct dfs_pattern_detector *dpd,
return true;
}
-static struct dfs_pattern_detector default_dpd = {
+static const struct dfs_pattern_detector default_dpd = {
.exit = dpd_exit,
.set_dfs_domain = dpd_set_domain,
.add_pulse = dpd_add_pulse,
^ permalink raw reply related
* [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-11 13:05 UTC (permalink / raw)
To: linux-renesas-soc
Cc: joe, kernel-janitors, Sergei Shtylyov, linux-pm,
platform-driver-x86, linux-media, linux-can, Tatyana Nikolova,
Shiraz Saleem, Mustafa Ismail, Chien Tin Tung, linux-rdma, netdev,
devel, alsa-devel, linux-kernel, linux-fbdev, linux-wireless,
Jason Gunthorpe, tpmdd-devel, linux-scsi, linux-spi, linux-usb,
linux-acpi
Constify local structures.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
// The first rule ignores some cases that posed problems
@r disable optional_qualifier@
identifier s != {peri_clk_data,threshold_attr,tracer_flags,tracer};
identifier i != {s5k5baf_cis_rect,smtcfb_fix};
position p;
@@
static struct s i@p = { ... };
@lstruct@
identifier r.s;
@@
struct s { ... };
@used depends on lstruct@
identifier r.i;
@@
i
@bad1@
expression e;
identifier r.i;
assignment operator a;
@@
(<+...i...+>) a e
@bad2@
identifier r.i;
@@
&(<+...i...+>)
@bad3@
identifier r.i;
declarer d;
@@
d(...,<+...i...+>,...);
@bad4@
identifier r.i;
type T;
T[] e;
identifier f;
position p;
@@
f@p(...,
(
(<+...i...+>)
&
e
)
,...)
@bad4a@
identifier r.i;
type T;
T *e;
identifier f;
position p;
@@
f@p(...,
(
(<+...i...+>)
&
e
)
,...)
@ok5@
expression *e;
identifier r.i;
position p;
@@
e =@p i
@bad5@
expression *e;
identifier r.i;
position p != ok5.p;
@@
e =@p (<+...i...+>)
@rr depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5@
identifier s,r.i;
position r.p;
@@
static
+const
struct s i@p = { ... };
@depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5
disable optional_qualifier@
identifier rr.s,r.i;
@@
static
+const
struct s i;
// </smpl>
---
drivers/acpi/acpi_apd.c | 8 +++---
drivers/char/tpm/tpm-interface.c | 10 ++++----
drivers/char/tpm/tpm-sysfs.c | 2 -
drivers/cpufreq/intel_pstate.c | 8 +++---
drivers/infiniband/hw/i40iw/i40iw_uk.c | 6 ++---
drivers/media/i2c/tvp514x.c | 2 -
drivers/media/pci/ddbridge/ddbridge-core.c | 18 +++++++--------
drivers/media/pci/ngene/ngene-cards.c | 14 ++++++------
drivers/media/pci/smipcie/smipcie-main.c | 8 +++---
drivers/misc/sgi-xp/xpc_uv.c | 2 -
drivers/net/arcnet/com20020-pci.c | 10 ++++----
drivers/net/can/c_can/c_can_pci.c | 4 +--
drivers/net/can/sja1000/plx_pci.c | 20 ++++++++---------
drivers/net/ethernet/mellanox/mlx4/main.c | 4 +--
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 -
drivers/net/ethernet/renesas/sh_eth.c | 14 ++++++------
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 -
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 -
drivers/net/wireless/intel/iwlegacy/3945.c | 4 +--
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 -
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 -
drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 2 -
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 2 -
drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 2 -
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 2 -
drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 2 -
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 2 -
drivers/platform/chrome/chromeos_laptop.c | 22 +++++++++----------
drivers/platform/x86/intel_scu_ipc.c | 6 ++---
drivers/platform/x86/intel_telemetry_debugfs.c | 2 -
drivers/scsi/esas2r/esas2r_flash.c | 2 -
drivers/scsi/hptiop.c | 6 ++---
drivers/spi/spi-dw-pci.c | 4 +--
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 2 -
drivers/usb/misc/ezusb.c | 2 -
drivers/video/fbdev/matrox/matroxfb_g450.c | 2 -
lib/crc64_ecma.c | 2 -
sound/pci/ctxfi/ctatc.c | 2 -
sound/pci/hda/patch_ca0132.c | 10 ++++----
sound/pci/riptide/riptide.c | 2 -
40 files changed, 110 insertions(+), 110 deletions(-)
^ permalink raw reply
* [PATCH v2] cfg80211: add bitrate for 20MHz MCS 9
From: Thomas Pedersen @ 2016-09-11 6:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, greearb, Thomas Pedersen
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't defined. To get more meaningful value
than 0 out of this however, just extrapolate a bitrate
from ratio of MCS 7 and 9 in channels where it is allowed.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
v2: add MCS 9 bitrate instead of capping at MCS 8
---
net/wireless/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index b7d1592..3e83170 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1157,7 +1157,7 @@ static u32 cfg80211_calculate_bitrate_vht(struct rate_info *rate)
58500000,
65000000,
78000000,
- 0,
+ 86500000,
},
{ 13500000,
27000000,
--
2.1.4
^ permalink raw reply related
* Re: [Make-wifi-fast] [PATCH] mac80211: Dynamically set CoDel parameters per station.
From: Loganaden Velvindron @ 2016-09-11 3:16 UTC (permalink / raw)
To: Jim Gettys
Cc: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless,
Felix Fietkau
In-Reply-To: <CAGhGL2D8Hfed0VTsinnCbkK31dGTc=bYjzpPfrcLRnp+x6O3sA@mail.gmail.com>
On Sat, Sep 10, 2016 at 11:54 PM, Jim Gettys <jg@freedesktop.org> wrote:
>
>
> On Sat, Sep 10, 2016 at 3:33 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@t=
oke.dk>
> wrote:
>>
>> CoDel can be too aggressive if a station sends at a very low rate,
>> leading to starvation. This gets worse the more stations are present, as
>> each station gets more bursty the longer the round-robin scheduling
>> between stations takes.
>>
>> This adds dynamic adjustment of CoDel parameters per station. It uses
>> the rate selection information to estimate throughput and sets more
>> lenient CoDel parameters if the estimated throughput is below a
>> threshold. To not change parameters too often, a hysteresis of two
>> seconds is added.
>
>
> Where is this 2 second constant coming from? I'd expect it should be of
> order the maximum RTT (or a small constant factor of that, which for
> intercontinental connections should be 200-300ms.
>
Indeed, from Mauritius (Africa) to remote countries like Australia, or
parts of the US, we see latencies of up to 500-600ms.
^ permalink raw reply
* Re: [PATCH] mac80211: Dynamically set CoDel parameters per station.
From: kbuild test robot @ 2016-09-11 0:09 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: kbuild-all, make-wifi-fast, linux-wireless,
Toke Høiland-Jørgensen, Michal Kazior, Felix Fietkau
In-Reply-To: <20160910193315.30738-1-toke@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 3725 bytes --]
Hi Toke,
[auto build test WARNING on ]
url: https://github.com/0day-ci/linux/commits/Toke-H-iland-J-rgensen/mac80211-Dynamically-set-CoDel-parameters-per-station/20160911-033626
base:
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
>> include/net/mac80211.h:4106: warning: No description found for parameter 'pubsta'
>> include/net/mac80211.h:4106: warning: Excess function parameter 'sta' description in 'ieee80211_sta_set_expected_throughput'
vim +/pubsta +4106 include/net/mac80211.h
4090
4091 /**
4092 * ieee80211_sta_set_expected_throughput - set the expected throughput for a
4093 * station
4094 *
4095 * Call this function to notify mac80211 about a change in expected throughput
4096 * to a station. A driver for a device that does rate control in firmware can
4097 * call this function when the expected throughput estimate towards a station
4098 * changes. The information is used to tune the CoDel AQM applied to traffic
4099 * going towards that station (which can otherwise be too aggressive and cause
4100 * slow stations to starve).
4101 *
4102 * @sta: the station to set throughput for.
4103 * @thr: the current expected throughput in kbps.
4104 */
4105 void ieee80211_sta_set_expected_throughput(struct ieee80211_sta *pubsta,
> 4106 u32 thr);
4107
4108 /**
4109 * ieee80211_tx_status - transmit status callback
4110 *
4111 * Call this function for all transmitted frames after they have been
4112 * transmitted. It is permissible to not call this function for
4113 * multicast frames but this can affect statistics.
4114 *
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 6422 bytes --]
^ permalink raw reply
* Re: [Make-wifi-fast] [PATCH] mac80211: Dynamically set CoDel parameters per station.
From: Toke Høiland-Jørgensen @ 2016-09-10 20:09 UTC (permalink / raw)
To: Jim Gettys; +Cc: make-wifi-fast, linux-wireless, Felix Fietkau
In-Reply-To: <CAGhGL2D8Hfed0VTsinnCbkK31dGTc=bYjzpPfrcLRnp+x6O3sA@mail.gmail.com>
Jim Gettys <jg@freedesktop.org> writes:
>> On Sat, Sep 10, 2016 at 3:33 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@=
toke.dk> wrote:
>>
>> CoDel can be too aggressive if a station sends at a very low rate,
>> leading to starvation. This gets worse the more stations are present, as
>> each station gets more bursty the longer the round-robin scheduling
>> between stations takes.
>>
>> This adds dynamic adjustment of CoDel parameters per station. It uses
>> the rate selection information to estimate throughput and sets more
>> lenient CoDel parameters if the estimated throughput is below a
>> threshold. To not change parameters too often, a hysteresis of two
>> seconds is added.
>
> =E2=80=8BWhere is this 2 second constant coming from? I'd expect it shoul=
d be
> of order the maximum RTT (or a small constant factor of that, which
> for intercontinental connections should be 200-300ms.
Well, in most cases a station is either going to be squarely below or
squarely above the threshold. The hysteresis is there to deal with the
exception to this, where a station's rate oscillates around the
threshold. I picked two seconds as something that is far enough above
the CoDel interval to hopefully let it do its thing.
> More interestingly, maybe the adjustment should be related to the # of
> active stations.
There is no doubt the algorithm can be improved. This is just a stopgap
measure to avoid starving slow stations. The CoDel parameters for slow
stations could be set smarter as well, or they could be scaled with the
rate instead of being threshold based. But since we have FQ, being
lenient can work without affecting latency too much.
> Basically, I'm pushing back about an arbitrary number apparently
> picked out of thin air... ;-).
You're very welcome to contribute to coming up with a better solution ;)
-Toke
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox