* Re: [PATCH 4.10-rc3 08/13] net: emac: fix build errors when linux/phy*.h is removed from net/dsa.h
From: Timur Tabi @ 2017-01-31 20:15 UTC (permalink / raw)
To: Russell King, linux-mips, linux-nfs, linux-scsi, linux-usb,
linux-wireless, netdev, target-devel
Cc: David S. Miller, Florian Fainelli
In-Reply-To: <E1cYdxI-0000Wk-5w@rmk-PC.armlinux.org.uk>
On 01/31/2017 01:19 PM, Russell King wrote:
> drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:58:12: error: dereferencing pointer to incomplete type 'struct phy_device'
>
> Add linux/phy.h to emac-sgmii.c
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 1 +
The version of emac-sgmii.c on net-next does not need this fixed. I already
removed all references to phy_device in commit "net: qcom/emac: always use
autonegotiation to configure the SGMII link".
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v2] ath10k: add support for controlling tx power to a station
From: kbuild test robot @ 2017-01-31 21:03 UTC (permalink / raw)
To: Ashok Raj Nagarajan
Cc: kbuild-all, ath10k, linux-wireless, arnagara, Ashok Raj Nagarajan
In-Reply-To: <1485888165-23504-1-git-send-email-arnagara@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]
Hi Ashok,
[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.10-rc6 next-20170130]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support-for-controlling-tx-power-to-a-station/20170201-032529
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_set_txpwr':
>> drivers/net/wireless/ath/ath10k/mac.c:5997:13: error: 'struct ieee80211_sta' has no member named 'txpwr'
txpwr = sta->txpwr;
^~
drivers/net/wireless/ath/ath10k/mac.c: At top level:
>> drivers/net/wireless/ath/ath10k/mac.c:7581:2: error: unknown field 'sta_set_txpwr' specified in initializer
.sta_set_txpwr = ath10k_sta_set_txpwr,
^
>> drivers/net/wireless/ath/ath10k/mac.c:7581:21: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.sta_set_txpwr = ath10k_sta_set_txpwr,
^~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/mac.c:7581:21: note: (near initialization for 'ath10k_ops.sta_pre_rcu_remove')
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_register':
>> drivers/net/wireless/ath/ath10k/mac.c:8226:11: error: 'NL80211_EXT_FEATURE_STA_TX_PWR' undeclared (first use in this function)
NL80211_EXT_FEATURE_STA_TX_PWR);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/mac.c:8226:11: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +5997 drivers/net/wireless/ath/ath10k/mac.c
5991 {
5992 struct ath10k *ar = hw->priv;
5993 struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
5994 int ret = 0;
5995 u8 txpwr;
5996
> 5997 txpwr = sta->txpwr;
5998 if (txpwr > ATH10K_TX_POWER_MAX_VAL || txpwr < ATH10K_TX_POWER_MIN_VAL)
5999 return -EINVAL;
6000
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 57943 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ath10k: add support for controlling tx power to a station
From: kbuild test robot @ 2017-01-31 21:54 UTC (permalink / raw)
To: Ashok Raj Nagarajan
Cc: kbuild-all, ath10k, linux-wireless, arnagara, Ashok Raj Nagarajan
In-Reply-To: <1485888165-23504-1-git-send-email-arnagara@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 3320 bytes --]
Hi Ashok,
[auto build test WARNING on ath6kl/ath-next]
[also build test WARNING on v4.10-rc6 next-20170131]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support-for-controlling-tx-power-to-a-station/20170201-032529
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All warnings (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_set_txpwr':
drivers/net/wireless/ath/ath10k/mac.c:5997:13: error: 'struct ieee80211_sta' has no member named 'txpwr'
txpwr = sta->txpwr;
^
drivers/net/wireless/ath/ath10k/mac.c: At top level:
drivers/net/wireless/ath/ath10k/mac.c:7581:2: error: unknown field 'sta_set_txpwr' specified in initializer
.sta_set_txpwr = ath10k_sta_set_txpwr,
^
>> drivers/net/wireless/ath/ath10k/mac.c:7581:2: warning: initialization from incompatible pointer type
drivers/net/wireless/ath/ath10k/mac.c:7581:2: warning: (near initialization for 'ath10k_ops.sta_pre_rcu_remove')
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_register':
drivers/net/wireless/ath/ath10k/mac.c:8226:11: error: 'NL80211_EXT_FEATURE_STA_TX_PWR' undeclared (first use in this function)
NL80211_EXT_FEATURE_STA_TX_PWR);
^
drivers/net/wireless/ath/ath10k/mac.c:8226:11: note: each undeclared identifier is reported only once for each function it appears in
vim +7581 drivers/net/wireless/ath/ath10k/mac.c
7565 static const struct ieee80211_ops ath10k_ops = {
7566 .tx = ath10k_mac_op_tx,
7567 .wake_tx_queue = ath10k_mac_op_wake_tx_queue,
7568 .start = ath10k_start,
7569 .stop = ath10k_stop,
7570 .config = ath10k_config,
7571 .add_interface = ath10k_add_interface,
7572 .remove_interface = ath10k_remove_interface,
7573 .configure_filter = ath10k_configure_filter,
7574 .bss_info_changed = ath10k_bss_info_changed,
7575 .set_coverage_class = ath10k_mac_op_set_coverage_class,
7576 .hw_scan = ath10k_hw_scan,
7577 .cancel_hw_scan = ath10k_cancel_hw_scan,
7578 .set_key = ath10k_set_key,
7579 .set_default_unicast_key = ath10k_set_default_unicast_key,
7580 .sta_state = ath10k_sta_state,
> 7581 .sta_set_txpwr = ath10k_sta_set_txpwr,
7582 .conf_tx = ath10k_conf_tx,
7583 .remain_on_channel = ath10k_remain_on_channel,
7584 .cancel_remain_on_channel = ath10k_cancel_remain_on_channel,
7585 .set_rts_threshold = ath10k_set_rts_threshold,
7586 .set_frag_threshold = ath10k_mac_op_set_frag_threshold,
7587 .flush = ath10k_flush,
7588 .tx_last_beacon = ath10k_tx_last_beacon,
7589 .set_antenna = ath10k_set_antenna,
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 39247 bytes --]
^ permalink raw reply
* Re: [PATCH 4.10-rc3 00/13] net: dsa: remove unnecessary phy.h include
From: Florian Fainelli @ 2017-02-01 2:42 UTC (permalink / raw)
To: Russell King - ARM Linux, linux-mips, linux-nfs, linux-scsi,
linux-usb, linux-wireless, netdev, target-devel
Cc: Andrew Lunn, Anna Schumaker, David S. Miller, Derek Chickles,
Felix Manlunas, J. Bruce Fields, Jeff Layton, Jiri Slaby,
Kalle Valo, Luis R. Rodriguez, Madalin Bucur,
Microchip Linux Driver Support, Nicholas A. Bellinger,
Nick Kossifidis, Nicolas Ferre, Raghu Vatsavayi, Ralf Baechle,
Satanand Burla, Thomas Petazzoni, Timur Tabi, Trond Myklebust,
Vivien Didelot, Woojung Huh
In-Reply-To: <20170131191704.GA8281@n2100.armlinux.org.uk>
On 01/31/2017 11:17 AM, Russell King - ARM Linux wrote:
> Including phy.h and phy_fixed.h into net/dsa.h causes phy*.h to be an
> unnecessary dependency for quite a large amount of the kernel. There's
> very little which actually requires definitions from phy.h in net/dsa.h
> - the include itself only wants the declaration of a couple of
> structures and IFNAMSIZ.
>
> Add linux/if.h for IFNAMSIZ, declarations for the structures, phy.h to
> mv88e6xxx.h as it needs it for phy_interface_t, and remove both phy.h
> and phy_fixed.h from net/dsa.h.
>
> This patch reduces from around 800 files rebuilt to around 40 - even
> with ccache, the time difference is noticable.
>
> In order to make this change, several drivers need to be updated to
> include necessary headers that they were picking up through this
> include. This has resulted in a much larger patch series.
>
> I'm assuming the 0-day builder has had 24 hours with this series, and
> hasn't reported any further issues with it - the last issue was two
> weeks ago (before I became ill) which I fixed over the last weekend.
>
> I'm hoping this doesn't conflict with what's already in net-next...
For the entire series:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks a lot for doing that.
>
> arch/mips/cavium-octeon/octeon-platform.c | 4 ----
> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 1 +
> drivers/net/ethernet/broadcom/bgmac.c | 2 ++
> drivers/net/ethernet/cadence/macb.h | 2 ++
> drivers/net/ethernet/cavium/liquidio/lio_main.c | 1 +
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 1 +
> drivers/net/ethernet/cavium/liquidio/octeon_console.c | 1 +
> drivers/net/ethernet/freescale/fman/fman_memac.c | 1 +
> drivers/net/ethernet/marvell/mvneta.c | 1 +
> drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 1 +
> drivers/net/usb/lan78xx.c | 1 +
> drivers/net/wireless/ath/ath5k/ahb.c | 2 +-
> drivers/target/iscsi/iscsi_target_login.c | 1 +
> include/net/dsa.h | 6 ++++--
> net/core/netprio_cgroup.c | 1 +
> net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 1 +
> 16 files changed, 20 insertions(+), 7 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH 4.10-rc3 12/13] net: ath5k: fix build errors when linux/phy*.h is removed from net/dsa.h
From: Kalle Valo @ 2017-02-01 5:34 UTC (permalink / raw)
To: Russell King
Cc: linux-mips, linux-nfs, linux-scsi, linux-usb, linux-wireless,
netdev, target-devel, David S. Miller, Florian Fainelli,
Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez
In-Reply-To: <E1cYdxc-0000XC-N6@rmk-PC.armlinux.org.uk>
Russell King <rmk+kernel@armlinux.org.uk> writes:
> Fix these errors reported by the 0-day builder by replacing the
> linux/export.h include with linux/module.h.
>
> In file included from include/linux/platform_device.h:14:0,
> from drivers/net/wireless/ath/ath5k/ahb.c:20:
> include/linux/device.h:1463:1: warning: data definition has no type or storage class
> module_init(__driver##_init); \
> ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
> module_driver(__platform_driver, platform_driver_register, \
> ^~~~~~~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver'
> module_platform_driver(ath_ahb_driver);
> ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/device.h:1463:1: error: type defaults to 'int' in declaration of 'module_init' [-Werror=implicit-int]
> module_init(__driver##_init); \
> ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
> module_driver(__platform_driver, platform_driver_register, \
> ^~~~~~~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver'
> module_platform_driver(ath_ahb_driver);
> ^~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without types) in function declaration
> In file included from include/linux/platform_device.h:14:0,
> from drivers/net/wireless/ath/ath5k/ahb.c:20:
> include/linux/device.h:1468:1: warning: data definition has no type or storage class
> module_exit(__driver##_exit);
> ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
> module_driver(__platform_driver, platform_driver_register, \
> ^~~~~~~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver'
> module_platform_driver(ath_ahb_driver);
> ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/device.h:1468:1: error: type defaults to 'int' in declaration of 'module_exit' [-Werror=implicit-int]
> module_exit(__driver##_exit);
> ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
> module_driver(__platform_driver, platform_driver_register, \
> ^~~~~~~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver'
> module_platform_driver(ath_ahb_driver);
> ^~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without types) in function declaration
> In file included from include/linux/platform_device.h:14:0,
> from drivers/net/wireless/ath/ath5k/ahb.c:20:
> drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_exit' defined but not used [-Wunused-function]
> module_platform_driver(ath_ahb_driver);
> ^
> include/linux/device.h:1464:20: note: in definition of macro 'module_driver'
> static void __exit __driver##_exit(void) \
> ^~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver'
> module_platform_driver(ath_ahb_driver);
> ^~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_init' defined but not used [-Wunused-function]
> module_platform_driver(ath_ahb_driver);
> ^
> include/linux/device.h:1459:19: note: in definition of macro 'module_driver'
> static int __init __driver##_init(void) \
> ^~~~~~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 'module_platform_driver'
> module_platform_driver(ath_ahb_driver);
> ^~~~~~~~~~~~~~~~~~~~~~
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Looks good to me:
Acked-by: Kalle Valo <kvalo@codeaurora.org>
I assume Dave will take this so I'll drop the patch from my queue.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-02-01 8:33 UTC (permalink / raw)
To: Tony Lindgren
Cc: Kalle Valo, Pavel Machek, Arend Van Spriel, Ming Lei,
Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt, Michal Kazior,
Daniel Wagner, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170131155918.GD7403@atomide.com>
On Tuesday 31 January 2017 07:59:18 Tony Lindgren wrote:
> * Kalle Valo <kvalo@codeaurora.org> [170130 22:36]:
> > Tony Lindgren <tony@atomide.com> writes:
> >
> > > * Pavel Machek <pavel@ucw.cz> [170127 11:41]:
> > >> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> > >> > Pali Rohár <pali.rohar@gmail.com> writes:
> > >> >
> > >> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> > >> > >> Pali Rohár <pali.rohar@gmail.com> writes:
> > >> > >>
> > >> > >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> > >> > >> > for SSH connection. If real correct data are not available it is better
> > >> > >> > to use at least those example (and probably log warning message) so user
> > >> > >> > can connect via SSH and start investigating where is problem.
> > >> > >>
> > >> > >> I disagree. Allowing default calibration data to be used can be
> > >> > >> unnoticed by user and left her wondering why wifi works so badly.
> > >> > >
> > >> > > So there are only two options:
> > >> > >
> > >> > > 1) Disallow it and so these users will have non-working wifi.
> > >> > >
> > >> > > 2) Allow those data to be used as fallback mechanism.
> > >> > >
> > >> > > And personally I'm against 1) because it will break wifi support for
> > >> > > *all* Nokia N900 devices right now.
> > >> >
> > >> > All two of them? :)
> > >>
> > >> Umm. You clearly want a flock of angry penguins at your doorsteps :-).
> > >
> > > Well this silly issue of symlinking and renaming nvs files in a standard
> > > Linux distro was also hitting me on various devices with wl12xx/wl18xx
> > > trying to use the same rootfs.
> > >
> > > Why don't we just set a custom compatible property for n900 that then
> > > picks up some other nvs file instead of the default?
> >
> > Please don't. An ugly kernel workaround in kernel because of user space
> > problems is a bad idea. wl1251 should just ask for NVS file from user
> > space, it shouldn't care if it's a "default" file or something else.
> > That's a user space policy decision.
>
> Grr I keep forgetting it needs to be for each device manufactured so
> yeah that won't work.
>
> The names of standard distro files are hardcoded into the kernel
> driver so it's also a kernel problem though :p
>
> How about a custom devices tree property saying "needs-custom-firmware"?
How does it help request_firmware() call which automatically loads
firmware file from VFS (if is available)?
> Something that would prevent anything being loaded until user space
> loads the firmware. It could also be set in the driver automatically
> based on the compatible flag if we always want it enabled. And we could
> have some cmdline option to ignore it. Or the other way around whatever
> makes sense.
So you just want to kernel automatically prevent loading firmware file
(based on flag which driver can set). That is similar approach as mine.
> > Why can't you do something like this:
> >
> > * rename the NVS file linux-firmware to wl1251-nvs.bin.example
>
> As that name is hardcoded in the kernel and that file is provided by
> all standard distros, let's assume we just have to deal with that ABI
> forever.
Yes.
> > * before distro updates linux-firmware create yours own deb/rpm/whatever
> > package "wl1251-firmware" which installs your flavor of nvs file (or
> > the user fallback helper if more dynamic functionality is preferred)
>
> And that won't work when using the same file system on other machines.
>
> Think NFSroot for example. At least I'm using the same NFSroot across
> about 15 different machines including one n900 macro board with smc91x
> Ethernet.
Exactly problem which we already discussed in previous emails. You
cannot serve one file (loaded by direct request_firmware) when your
rootfs is readonly, e.g. comes via NFS shared for more devices...
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Michal Kazior @ 2017-02-01 9:35 UTC (permalink / raw)
To: Pali Rohár
Cc: Tony Lindgren, Kalle Valo, Pavel Machek, Arend Van Spriel,
Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Daniel Wagner, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless,
Network Development
In-Reply-To: <20170201083312.GA6609@pali>
On 1 February 2017 at 09:33, Pali Roh=C3=A1r <pali.rohar@gmail.com> wrote:
> On Tuesday 31 January 2017 07:59:18 Tony Lindgren wrote:
>> * Kalle Valo <kvalo@codeaurora.org> [170130 22:36]:
[...]
>> > * before distro updates linux-firmware create yours own deb/rpm/whatev=
er
>> > package "wl1251-firmware" which installs your flavor of nvs file (or
>> > the user fallback helper if more dynamic functionality is preferred)
>>
>> And that won't work when using the same file system on other machines.
>>
>> Think NFSroot for example. At least I'm using the same NFSroot across
>> about 15 different machines including one n900 macro board with smc91x
>> Ethernet.
>
> Exactly problem which we already discussed in previous emails. You
> cannot serve one file (loaded by direct request_firmware) when your
> rootfs is readonly, e.g. comes via NFS shared for more devices...
You can extract the nvs blob, put it in tmpfs and bind-mount (or
symlink) it to /lib/firmware/ via modprobe install hook (or init
scripts).
Micha=C5=82
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-02-01
From: Kalle Valo @ 2017-02-01 9:37 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to 4.11, more details in the signed tag below.
I forgot to mention in the tag that this includes one small change to
include/linux/soc/qcom/smem_state.h which was acked by Andy Gross in
commit 6c0b2e833f14. It was needed to fix a build problem with wcn36xx
using the SMD interface.
Please let me know if you have any problems.
Kalle
The following changes since commit a505e58252715bbc18a0ee1abae23615fe2586db:
packet: pdiag_put_ring() should return TX_RING info for TPACKET_V3 (2017-=
01-10 21:02:42 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2017-02-01
for you to fetch changes up to 7243a1af37a4dc9225004546d9d0756c529ad3ce:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/a=
th.git (2017-01-31 09:50:50 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.11
It's nice to see rt2x00 development has becoming active, for example
adding support for a new chip version. Also wcn36xx has been converted
to use the recently merged QCOM_SMD subsystem. Otherwise new features
and fixes it lots of drivers.
Major changes:
iwlwifi
* some more work in preparation for A000 family support
* add support for radiotap timestamps
* some work on our firmware debugging capabilities
wcn36xx
* convert to a proper QCOM_SMD driver (from the platform_driver interface)
ath10k
* VHT160 support
* dump Copy Engine registers during firmware crash
* search board file extension from SMBIOS
wil6210
* add disable_ap_sme module parameter
rt2x00
* support RT3352 with external PA
* support for RT3352 with 20MHz crystal
* add support for RT5350 WiSoC
brcmfmac
* add support for BCM43455 sdio device
rtl8xxxu
* add support for D-Link DWA-131 rev E1, TP-Link TL-WN822N v4 and others
----------------------------------------------------------------
Amitkumar Karwar (3):
mwifiex: use module_*_driver helper macros
mwifiex: mwifiex_unmap_pci_memory() handling for sleep confirm
mwifiex: use pci_dma_sync_single* APIs
Arend Van Spriel (4):
brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
brcmfmac: fix handling firmware results for wowl netdetect
brcmfmac: allow wowlan support to be per device
brcmfmac: add .update_connect_params() callback
Arnd Bergmann (1):
mwifiex: fix uninitialized variable access in pcie_remove
Axel K=C3=B6llhofer (2):
rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)
rtl8xxxu: Add additional USB IDs for rtl8192eu devices
Bhumika Goyal (1):
wil6210: constify cfg80211_ops structures
Bjorn Andersson (5):
soc: qcom: smem_state: Fix include for ERR_PTR()
wcn36xx: Transition driver to SMD client
wcn36xx: Implement firmware assisted scan
wcn36xx: Implement print_reg indication
wcn36xx: Don't use the destroyed hal_mutex
Brian Norris (5):
mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print
mwifiex: pcie: use posted write to wake up firmware
mwifiex: pcie: don't loop/retry interrupt status checks
mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE()
mwifiex: don't complain about 'unknown event id: 0x63'
Christian Lamparter (2):
ath10k: add accounting for the extended peer statistics
ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS
Colin Ian King (1):
ath9k: fix spelling mistake: "meaurement" -> "measurement"
Daniel Golle (2):
rt2x00: rt2800lib: support for for RT3352 with external PA
rt2x00: rt2800lib: add support for RT3352 with 20MHz crystal
Dedy Lansky (2):
wil6210: add disable_ap_sme module parameter
wil6210: support new WMI-only FW capability
Erik Stromdahl (2):
ath10k: htc: removal of unused struct members
ath10k: htc: simplified credit distribution
Felix Fietkau (2):
ath5k: drop bogus warning on drv_set_key with unsupported cipher
rt2x00: rt2800lib: fix rf id for RT3352
Ganapathi Bhat (1):
mwifiex: move pcie_work and related variables inside card
Gavin Li (1):
brcmfmac: fix incorrect event channel deduction
Guy Mishol (1):
wlcore: print the sdio buffer after reading it
Hamad Kadmany (1):
wil6210: protect against false interrupt during reset sequence
Jes Sorensen (3):
rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested
rtl8xxxu: Add another 8192eu device to the USB list
rtl8xxxu: Update author/maintainer contact info
Johannes Berg (5):
iwlwifi: mvm: expose device timestamp in radiotap
iwlwifi: mvm: accept arbitrary memory dump TLVs
iwlwifi: mvm: make iwl_dump_prph() void
iwlwifi: allow memory debug TLV to specify the memory type
iwlwifi: mvm: properly check for transport data in dump
J=C3=BCrg Billeter (1):
iwlwifi: fix MODULE_FIRMWARE for 6030
Kalle Valo (3):
ath10k: refactor ath10k_peer_assoc_h_phymode()
Merge tag 'iwlwifi-next-for-kalle-2017-01-26' of git://git.kernel.org=
/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Kirtika Ruchandani (3):
iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables
iwlwifi: mvm: rs: Remove unused 'mcs' variable
iwlwifi: pcie: trans: Remove unused 'shift_param'
Larry Finger (7):
rtlwifi: rtl8192de: Remove a pointless goto
rtlwifi: Redo debugging macros RTPRINT and RT_PRINT_DATA
rtlwifi: Convert COMP_XX entries into a proper debugging mask
rtlwifi: Remove debugging entry in sysfs
rtlwifi: Download firmware as bytes rather than as dwords
rtlwifi: rtl8192cu: Calculate descriptor checksum correctly for BE
rtlwifi: rtl8192cu: Convert driver to use common macros
Lazar Alexei (2):
wil6210: support loading dedicated image for sparrow-plus devices
wil6210: remove __func__ from debug printouts
Lior David (5):
wil6210: missing reinit_completion in wmi_call
wil6210: fix for broadcast workaround in PBSS
wil6210: align to latest auto generated wmi.h
wil6210: report association ID (AID) per station in debugfs
wil6210: option to override A-BFT length in start AP/PCP
Luca Coelho (7):
iwlwifi: mvm: don't restart HW if suspend fails with unified image
iwlwifi: mvm: bump max API to 28
iwlwifi: mvm: remove unused variable in iwl_mvm_handle_statistics()
iwlwifi: dvm: make rs_tl_get_load() return void
iwlwifi: mvm: remove unused sta_id variable in iwl_mvm_change_queue_o=
wner()
iwlwifi: dvm: remove unused variable compiler warning in debugfs.c
iwlwifi: mvm: mark ret as maybe_unused in iwl_dbgfs_fw_restart_write()
Mark Rutland (2):
ath9k: ar9002_mac: kill off ACCESS_ONCE()
ath9k: ar9003_mac: kill off ACCESS_ONCE()
Martin Blumenstingl (1):
brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF
Maya Erez (1):
wil6210: convert symbolic permissions to octal permissions
Michael Schenk (1):
rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down
Michal Kazior (1):
ath10k: prevent sta pointer rcu violation
Mohammed Shafi Shajakhan (4):
ath10k: fix wifi connectivity and warning in rx with channel 169
ath10k: fix tx legacy rate reporting
ath10k: fix per station tx bit rate reporting
ath10k: dump Copy Engine registers during firmware crash
Pan Bian (1):
libertas: fix improper return value
Rafa=C5=82 Mi=C5=82ecki (11):
brcmfmac: avoid writing channel out of allocated array
brcmfmac: don't preset all channels as disabled
brcmfmac: setup wiphy bands after registering it first
brcmfmac: make brcmf_of_probe more generic
brcmfmac: drop unneeded function declarations from headers
brcmfmac: move brcmf_c_set_joinpref_default declaration to common.h
brcmfmac: drop brcmf_bus_detach and inline its code
brcmfmac: rename brcmf_bus_start function to brcmf_bus_started
brcmfmac: drop duplicated core selection from brcmf_pcie_attach
bcma: use (get|put)_device when probing/removing device driver
bcma: make OF code more generic (not platform_device specific)
Sara Sharon (10):
iwlwifi: mvm: simplify paging allocation code
iwlwifi: mvm: replace the number of blocks calculation
iwlwifi: enlarge number of ucode sections
iwlwifi: mvm: change iwl_mvm_tx_csum to return value
iwlwifi: mvm: separate rate calculation to a new function
iwlwifi: mvm: support version 2 of stored beacon notification
iwlwifi: pcie: cleanup rfkill checks
iwlwifi: mvm: use mvm_disable_queue instead of sharing logic
iwlwifi: mvm: cleanup redundant assignment
iwlwifi: alloc memory dynamically also for DVM
Sebastian Gottschall (1):
ath10k: add VHT160 support
Serge Vasilugin (2):
rt2x00: rt2800lib: correctly set HT20/HT40 filter
rt2x00: add support for RT5350 WiSoC
Srinivas Kandagatla (3):
ath10k: remove multiple defines of DIAG_TRANSFER_LIMIT
ath10k: use dma_zalloc_coherent()
ath10k: fix typo in addr calculation
Stanislaw Gruszka (12):
rt2800usb: remove watchdog
rt2800: increase TX timeout
rt2x00: save conf settings before reset tuner
rt2800: change default retry settings
rt2800: tune TX_RTS_CFG config
rt2800usb: mark tx failure on timeout
rt2x00: do not flush empty queue
rt2800: set max_psdu to 3 on usb devices
rt2800: remove warning on bcn_num !=3D rt2x00dev->intf_beaconing
rt2x00: add copy of clk for soc devices
rt2x00: fix clk_get call
rt2800: enable rt3290 unconditionally on pci probe
Waldemar Rymarkiewicz (1):
ath10k: Search SMBIOS for OEM board file extension
Wei Yongjun (1):
ath6kl: fix warning for using 0 as NULL
Xinming Hu (12):
mwifiex: don't wait for main_process in shutdown_drv
mwifiex: do not free firmware dump memory in shutdown_drv
mwifiex: get rid of drv_info* adapter variables
mwifiex: wait firmware dump complete during card remove process
mwifiex: code rearrangement in pcie.c and sdio.c
mwifiex: get rid of global user_rmmod flag
mwifiex: get rid of mwifiex_do_flr wrapper
mwifiex: cleanup in PCIe flr code path
mwifiex: sdio card reset enhancement
mwifiex: get rid of __mwifiex_sdio_remove helper
mwifiex: get rid of global save_adapter and sdio_work
mwifiex: remove redundant dma padding in AMSDU
MAINTAINERS | 2 +-
drivers/bcma/main.c | 25 +-
drivers/net/wireless/ath/ath10k/ce.c | 48 +-
drivers/net/wireless/ath/ath10k/ce.h | 4 +-
drivers/net/wireless/ath/ath10k/core.c | 84 +++-
drivers/net/wireless/ath/ath10k/core.h | 36 ++
drivers/net/wireless/ath/ath10k/debug.c | 23 +-
drivers/net/wireless/ath/ath10k/htc.c | 35 +-
drivers/net/wireless/ath/ath10k/htc.h | 3 -
drivers/net/wireless/ath/ath10k/htt_rx.c | 11 +-
drivers/net/wireless/ath/ath10k/hw.h | 3 +
drivers/net/wireless/ath/ath10k/mac.c | 75 ++-
drivers/net/wireless/ath/ath10k/pci.c | 6 +-
drivers/net/wireless/ath/ath10k/pci.h | 5 -
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 +
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 11 +-
drivers/net/wireless/ath/ath10k/wmi.h | 27 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 3 +-
drivers/net/wireless/ath/ath6kl/sdio.c | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 9 +-
drivers/net/wireless/ath/ath9k/Makefile | 5 +-
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 64 +--
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 92 ++--
drivers/net/wireless/ath/ath9k/common-debug.h | 27 ++
drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
drivers/net/wireless/ath/ath9k/common-spectral.h | 23 +
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/wcn36xx/Kconfig | 2 +
drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +-
drivers/net/wireless/ath/wcn36xx/hal.h | 16 +
drivers/net/wireless/ath/wcn36xx/main.c | 146 ++++--
drivers/net/wireless/ath/wcn36xx/smd.c | 69 ++-
drivers/net/wireless/ath/wcn36xx/smd.h | 9 +-
drivers/net/wireless/ath/wcn36xx/txrx.c | 19 +-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 30 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 174 +++++--
drivers/net/wireless/ath/wil6210/debugfs.c | 136 +++---
drivers/net/wireless/ath/wil6210/ethtool.c | 10 +-
drivers/net/wireless/ath/wil6210/fw.c | 7 +-
drivers/net/wireless/ath/wil6210/fw_inc.c | 21 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 30 +-
drivers/net/wireless/ath/wil6210/main.c | 87 ++--
drivers/net/wireless/ath/wil6210/netdev.c | 17 +-
drivers/net/wireless/ath/wil6210/p2p.c | 36 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 60 ++-
drivers/net/wireless/ath/wil6210/pm.c | 17 +-
drivers/net/wireless/ath/wil6210/pmc.c | 79 ++--
drivers/net/wireless/ath/wil6210/rx_reorder.c | 8 +-
drivers/net/wireless/ath/wil6210/txrx.c | 75 +--
drivers/net/wireless/ath/wil6210/wil6210.h | 29 +-
drivers/net/wireless/ath/wil6210/wil_crash_dump.c | 18 +-
drivers/net/wireless/ath/wil6210/wmi.c | 131 ++++--
drivers/net/wireless/ath/wil6210/wmi.h | 67 ++-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 6 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 97 ++--
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 2 -
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 10 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.h | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 1 -
.../net/wireless/broadcom/brcm80211/brcmfmac/of.c | 7 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/of.h | 6 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 3 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 11 +-
drivers/net/wireless/intel/iwlwifi/dvm/ucode.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-6000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 124 +++--
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 24 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw.h | 7 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 13 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 123 +++--
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 69 +--
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 10 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 2 -
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 31 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 107 +++--
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 14 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 51 +--
drivers/net/wireless/marvell/libertas/cmd.c | 2 +-
drivers/net/wireless/marvell/mwifiex/11n_aggr.c | 19 +-
drivers/net/wireless/marvell/mwifiex/debugfs.c | 3 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/init.c | 38 +-
drivers/net/wireless/marvell/mwifiex/main.c | 137 ++----
drivers/net/wireless/marvell/mwifiex/main.h | 15 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 332 ++++++--------
drivers/net/wireless/marvell/mwifiex/pcie.h | 3 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 508 ++++++++++-------=
----
drivers/net/wireless/marvell/mwifiex/sdio.h | 4 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 +
drivers/net/wireless/marvell/mwifiex/usb.c | 41 +-
drivers/net/wireless/marvell/mwifiex/util.c | 15 -
drivers/net/wireless/ralink/rt2x00/rt2800.h | 27 ++
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 278 +++++++++--
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 49 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 7 +
drivers/net/wireless/ralink/rt2x00/rt2x00config.c | 32 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 3 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00soc.c | 4 +
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 2 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 2 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 2 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 2 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 18 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 59 ---
drivers/net/wireless/realtek/rtlwifi/base.h | 1 -
drivers/net/wireless/realtek/rtlwifi/debug.c | 61 +--
drivers/net/wireless/realtek/rtlwifi/debug.h | 35 +-
drivers/net/wireless/realtek/rtlwifi/efuse.c | 45 ++
drivers/net/wireless/realtek/rtlwifi/efuse.h | 4 +
drivers/net/wireless/realtek/rtlwifi/pci.c | 18 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 67 +--
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 11 +-
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 70 +--
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.h | 272 +++++------
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 71 +--
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 68 +--
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 11 +-
.../realtek/rtlwifi/rtl8723com/fw_common.c | 69 +--
.../realtek/rtlwifi/rtl8723com/fw_common.h | 6 -
.../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 67 +--
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 11 +-
drivers/net/wireless/realtek/rtlwifi/usb.c | 19 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 38 +-
drivers/net/wireless/ti/wlcore/sdio.c | 14 +-
include/linux/mmc/sdio_ids.h | 1 +
include/linux/soc/qcom/smem_state.h | 2 +-
156 files changed, 2847 insertions(+), 2526 deletions(-)
^ permalink raw reply
* Re: [PATCH 4.10-rc3 03/13] net: macb: fix build errors when linux/phy*.h is removed from net/dsa.h
From: Nicolas Ferre @ 2017-02-01 9:40 UTC (permalink / raw)
To: Russell King, linux-mips, linux-nfs, linux-scsi, linux-usb,
linux-wireless, netdev, target-devel
Cc: David S. Miller, Florian Fainelli
In-Reply-To: <E1cYdws-0000W9-GV@rmk-PC.armlinux.org.uk>
Le 31/01/2017 à 20:18, Russell King a écrit :
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: expected ; at end of declaration
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: Expected } at end of struct-union-enum-specifier
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: got phy_interface
> drivers/net/ethernet/cadence/macb.h:877:1: sparse: Expected ; at the end of type declaration
> drivers/net/ethernet/cadence/macb.h:877:1: sparse: got }
> In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0:
> drivers/net/ethernet/cadence/macb.h:862:2: error: unknown type name 'phy_interface_t'
> phy_interface_t phy_interface;
> ^~~~~~~~~~~~~~~
>
> Add linux/phy.h to macb.h
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index d67adad67be1..383da8cf5f6d 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -10,6 +10,8 @@
> #ifndef _MACB_H
> #define _MACB_H
>
> +#include <linux/phy.h>
> +
> #define MACB_GREGS_NBR 16
> #define MACB_GREGS_VERSION 2
> #define MACB_MAX_QUEUES 8
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 4.10-rc3 07/13] net: mvneta: fix build errors when linux/phy*.h is removed from net/dsa.h
From: Thomas Petazzoni @ 2017-02-01 10:27 UTC (permalink / raw)
To: Russell King
Cc: linux-mips, linux-nfs, linux-scsi, linux-usb, linux-wireless,
netdev, target-devel, David S. Miller, Florian Fainelli
In-Reply-To: <E1cYdxD-0000Wd-1D@rmk-PC.armlinux.org.uk>
Hello,
On Tue, 31 Jan 2017 19:18:59 +0000, Russell King wrote:
> drivers/net/ethernet/marvell/mvneta.c:2694:26: error: storage size of 'status' isn't known
> drivers/net/ethernet/marvell/mvneta.c:2695:26: error: storage size of 'changed' isn't known
> drivers/net/ethernet/marvell/mvneta.c:2695:9: error: variable 'changed' has initializer but incomplete type
> drivers/net/ethernet/marvell/mvneta.c:2709:2: error: implicit declaration of function 'fixed_phy_update_state' [-Werror=implicit-function-declaration]
>
> Add linux/phy_fixed.h to mvneta.c
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4.10-rc3 05/13] net: bgmac: fix build errors when linux/phy*.h is removed from net/dsa.h
From: Rafał Miłecki @ 2017-02-01 9:55 UTC (permalink / raw)
To: Russell King, linux-mips, linux-nfs, linux-scsi, linux-usb,
linux-wireless, netdev, target-devel
Cc: David S. Miller, Florian Fainelli
In-Reply-To: <E1cYdx2-0000WP-Ot@rmk-PC.armlinux.org.uk>
On 01/31/2017 08:18 PM, Russell King wrote:
> drivers/net/ethernet/broadcom/bgmac.c:1015:17: error: dereferencing pointer to incomplete type 'struct mii_bus'
> drivers/net/ethernet/broadcom/bgmac.c:1185:2: error: implicit declaration of function 'phy_start' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/broadcom/bgmac.c:1198:2: error: implicit declaration of function 'phy_stop' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/broadcom/bgmac.c:1239:9: error: implicit declaration of function 'phy_mii_ioctl' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/broadcom/bgmac.c:1389:28: error: 'phy_ethtool_get_link_ksettings' undeclared here (not in a function)
> drivers/net/ethernet/broadcom/bgmac.c:1390:28: error: 'phy_ethtool_set_link_ksettings' undeclared here (not in a function)
> drivers/net/ethernet/broadcom/bgmac.c:1403:13: error: dereferencing pointer to incomplete type 'struct phy_device'
> drivers/net/ethernet/broadcom/bgmac.c:1417:3: error: implicit declaration of function 'phy_print_status' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/broadcom/bgmac.c:1424:26: error: storage size of 'fphy_status' isn't known
> drivers/net/ethernet/broadcom/bgmac.c:1424:9: error: variable 'fphy_status' has initializer but incomplete type
> drivers/net/ethernet/broadcom/bgmac.c:1425:11: warning: excess elements in struct initializer
> drivers/net/ethernet/broadcom/bgmac.c:1425:3: error: unknown field 'link' specified in initializer
> drivers/net/ethernet/broadcom/bgmac.c:1426:12: note: in expansion of macro 'SPEED_1000'
> drivers/net/ethernet/broadcom/bgmac.c:1426:3: error: unknown field 'speed' specified in initializer
> drivers/net/ethernet/broadcom/bgmac.c:1427:13: note: in expansion of macro 'DUPLEX_FULL'
> drivers/net/ethernet/broadcom/bgmac.c:1427:3: error: unknown field 'duplex' specified in initializer
> drivers/net/ethernet/broadcom/bgmac.c:1432:12: error: implicit declaration of function 'fixed_phy_register' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/broadcom/bgmac.c:1432:31: error: 'PHY_POLL' undeclared (first use in this function)
> drivers/net/ethernet/broadcom/bgmac.c:1438:8: error: implicit declaration of function 'phy_connect_direct' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/broadcom/bgmac.c:1439:6: error: 'PHY_INTERFACE_MODE_MII' undeclared (first use in this function)
> drivers/net/ethernet/broadcom/bgmac.c:1521:2: error: implicit declaration of function 'phy_disconnect' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/broadcom/bgmac.c:1541:15: error: expected declaration specifiers or '...' before string constant
>
> Add linux/phy.h to bgmac.c
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Rafał Miłecki <rafal@milecki.pl>
^ permalink raw reply
* Changing of WMM queue parameters forbidden for IBSS interfaces
From: Jörg Pommnitz @ 2017-02-01 14:24 UTC (permalink / raw)
To: linux-wireless
Hello all,
I'm trying to change the WMM parameters for an IBSS network. I'm
adding a command to set txq_params to iw. Sadly the current kernel
code explicitly denies this for interfaces other than AP and P2P (see
http://lxr.free-electrons.com/source/net/wireless/nl80211.c#L2279).
Is there a reason why this should not be done for IBSS interfaces?
Thanks in advance
Joerg
^ permalink raw reply
* Re: Changing of WMM queue parameters forbidden for IBSS interfaces
From: Jörg Pommnitz @ 2017-02-01 14:29 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAEvAWuH-HkC1VNbtLZdjtNQehcE2CR+k0RP=24xMx3TTxzFdUg@mail.gmail.com>
Sorry, wrong line in the link, the correct line is:
http://lxr.free-electrons.com/source/net/wireless/nl80211.c#L2289
regards
Joerg
2017-02-01 15:24 GMT+01:00 J=C3=B6rg Pommnitz <j.pommnitz@gmail.com>:
> Hello all,
>
> I'm trying to change the WMM parameters for an IBSS network. I'm
> adding a command to set txq_params to iw. Sadly the current kernel
> code explicitly denies this for interfaces other than AP and P2P (see
> http://lxr.free-electrons.com/source/net/wireless/nl80211.c#L2279).
>
> Is there a reason why this should not be done for IBSS interfaces?
>
>
> Thanks in advance
> Joerg
^ permalink raw reply
* Re: [PATCH v3] rt2x00: avoid introducing a USB dependency in the
From: Felix Fietkau @ 2017-02-01 16:33 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: Helmut Schaa, Vishal Thanki
In-Reply-To: <1485863050-24895-1-git-send-email-sgruszka@redhat.com>
On 2017-01-31 12:44, Stanislaw Gruszka wrote:
> As reported by Felix:
>
> Though protected by an ifdef, introducing an usb symbol dependency in
> the rt2x00lib module is a major inconvenience for distributions that
> package kernel modules split into individual packages.
>
> Get rid of this unnecessary dependency by calling the usb related
> function from a more suitable place.
>
> Cc: Vishal Thanki <vishalthanki@gmail.com>
> Reported-by: Felix Fietkau <nbd@nbd.name>
> Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> v1 -> v2 do not break shutdown sequence
> v2 -> v3 update patch to current kernel version
What happened to the subject? It ends mid-sentence.
- Felix
^ permalink raw reply
* Re: [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
From: Ashok Raj Nagarajan @ 2017-02-01 17:27 UTC (permalink / raw)
To: Ben Greear; +Cc: Ashok Raj Nagarajan, linux-wireless, johannes, ath10k
In-Reply-To: <12efc3d8-2274-a6e8-6d74-c06bf89762fb@candelatech.com>
On 2017-02-01 00:36, Ben Greear wrote:
> On 01/31/2017 10:41 AM, Ashok Raj Nagarajan wrote:
>> This patch adds support to set transmit power setting type and
>> transmit
>> power level attributes to NL80211_CMD_SET_STATION in order to
>> facilitate
>> adjusting the transmit power level of a station associated to the AP.
>>
>> The added attributes allow selection of automatic and limited transmit
>> power level, with the level defined in mBm format.
>>
>> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
>> ---
>> v2:
>> - refactor the shared code
>> - "keep what you had" using STATION_PARAM_APPLY_* BIT
>> - feature flag to let the user know if this feature is supported or
>> not (Johannes)
>>
>> include/net/cfg80211.h | 6 ++++++
>> include/uapi/linux/nl80211.h | 15 +++++++++++++
>> net/wireless/nl80211.c | 50
>> ++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 71 insertions(+)
>>
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index 814be4b..c989fbd 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -808,6 +808,7 @@ enum station_parameters_apply_mask {
>> STATION_PARAM_APPLY_UAPSD = BIT(0),
>> STATION_PARAM_APPLY_CAPABILITY = BIT(1),
>> STATION_PARAM_APPLY_PLINK_STATE = BIT(2),
>> + STATION_PARAM_APPLY_STA_TXPOWER = BIT(3),
>> };
>>
>> /**
>> @@ -849,6 +850,10 @@ enum station_parameters_apply_mask {
>> * @opmode_notif: operating mode field from Operating Mode
>> Notification
>> * @opmode_notif_used: information if operating mode field is used
>> * @support_p2p_ps: information if station supports P2P PS mechanism
>> + * @txpwr: tx power (in mBm) to be used for sending data traffic. If
>> tx power
>> + * is not provided, the default per-interface tx power setting will
>> be
>> + * overriding. Driver should be picking up the lowest tx power,
>> either tx
>> + * power per-interface or per-station.
>> */
>> struct station_parameters {
>> const u8 *supported_rates;
>> @@ -876,6 +881,7 @@ struct station_parameters {
>> u8 opmode_notif;
>> bool opmode_notif_used;
>> int support_p2p_ps;
>> + unsigned int txpwr;
>> };
>>
>> /**
>> diff --git a/include/uapi/linux/nl80211.h
>> b/include/uapi/linux/nl80211.h
>> index 6b76e3b..de2f72c 100644
>> --- a/include/uapi/linux/nl80211.h
>> +++ b/include/uapi/linux/nl80211.h
>> @@ -1980,6 +1980,15 @@ enum nl80211_commands {
>> * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that
>> %NL80211_ATTR_MAC is also
>> * used in various commands/events for specifying the BSSID.
>> *
>> + * @NL80211_ATTR_STA_TX_POWER_SETTING: Transmit power setting type
>> (u32) for
>> + * station associated with the AP. See &enum nl80211_tx_power_setting
>> for
>> + * possible values.
>> + * @NL80211_ATTR_STA_TX_POWER: Transmit power level (u32) in mBm
>> units. This
>> + * allows to set Tx power for a station. If this attribute is not
>> included,
>> + * the default per-interface tx power setting will be overriding.
>> Driver
>> + * should be picking up the lowest tx power, either tx power
>> per-interface
>> + * or per-station.
>> + *
>> * @NUM_NL80211_ATTR: total number of nl80211_attrs available
>> * @NL80211_ATTR_MAX: highest attribute number currently defined
>> * @__NL80211_ATTR_AFTER_LAST: internal use
>> @@ -2386,6 +2395,9 @@ enum nl80211_attrs {
>>
>> NL80211_ATTR_BSSID,
>>
>> + NL80211_ATTR_STA_TX_POWER_SETTING,
>> + NL80211_ATTR_STA_TX_POWER,
>> +
>> /* add attributes here, update the policy in nl80211.c */
>>
>> __NL80211_ATTR_AFTER_LAST,
>> @@ -4697,6 +4709,8 @@ enum nl80211_feature_flags {
>> * configuration (AP/mesh) with VHT rates.
>> * @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial
>> Link Setup
>> * with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
>> + * @NL80211_EXT_FEATURE_STA_TX_PWR: This driver supports controlling
>> tx power
>> + * to a station.
>> *
>> * @NUM_NL80211_EXT_FEATURES: number of extended features.
>> * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
>> @@ -4712,6 +4726,7 @@ enum nl80211_ext_feature_index {
>> NL80211_EXT_FEATURE_BEACON_RATE_HT,
>> NL80211_EXT_FEATURE_BEACON_RATE_VHT,
>> NL80211_EXT_FEATURE_FILS_STA,
>> + NL80211_EXT_FEATURE_STA_TX_PWR,
>>
>> /* add new features before the definition below */
>> NUM_NL80211_EXT_FEATURES,
>> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>> index ef5eff93..ace87de 100644
>> --- a/net/wireless/nl80211.c
>> +++ b/net/wireless/nl80211.c
>> @@ -246,6 +246,8 @@ enum nl80211_multicast_groups {
>> [NL80211_ATTR_STA_SUPPORTED_RATES] = { .type = NLA_BINARY,
>> .len = NL80211_MAX_SUPP_RATES },
>> [NL80211_ATTR_STA_PLINK_ACTION] = { .type = NLA_U8 },
>> + [NL80211_ATTR_STA_TX_POWER_SETTING] = { .type = NLA_U32 },
>> + [NL80211_ATTR_STA_TX_POWER] = { .type = NLA_U32 },
>> [NL80211_ATTR_STA_VLAN] = { .type = NLA_U32 },
>> [NL80211_ATTR_MNTR_FLAGS] = { /* NLA_NESTED can't be empty */ },
>> [NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
>> @@ -4548,6 +4550,8 @@ int cfg80211_check_station_change(struct wiphy
>> *wiphy,
>> return -EINVAL;
>> if (params->sta_modify_mask & STATION_PARAM_APPLY_CAPABILITY)
>> return -EINVAL;
>> + if (params->sta_modify_mask & STATION_PARAM_APPLY_STA_TXPOWER)
>> + return -EINVAL;
>
> Does this mean that we cannot change the tx-power after the station is
> associated?
>
> Seems like that would be a good limitation to remove if possible!
>
>
Ben, that is a good catch! We don't want to have that limitation and
would remove in the next version.
>
>> if (params->supported_rates)
>> return -EINVAL;
>> if (params->ext_capab || params->ht_capa || params->vht_capa)
>> @@ -4755,6 +4759,40 @@ static int nl80211_set_station_tdls(struct
>> genl_info *info,
>> return nl80211_parse_sta_wme(info, params);
>> }
>>
>> +static int nl80211_parse_sta_txpower_setting(struct genl_info *info,
>> + struct station_parameters *params)
>> +{
>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> + enum nl80211_tx_power_setting type;
>> + int idx;
>> +
>> + if (!rdev->ops->set_tx_power ||
>> + !wiphy_ext_feature_isset(&rdev->wiphy,
>> + NL80211_EXT_FEATURE_STA_TX_PWR))
>> + return -EOPNOTSUPP;
>
> Maybe always let a user set to default value even if the driver does
> not
> support setting specific values?
>
IMHO, having some default value in place of non-valid values may not be
the right way.
Thanks,
Ashok
> Thanks,
> Ben
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: store tx power value from user to station
From: Ashok Raj Nagarajan @ 2017-02-01 17:29 UTC (permalink / raw)
To: Ben Greear; +Cc: Ashok Raj Nagarajan, linux-wireless, johannes, ath10k
In-Reply-To: <eff562d4-7dd8-4b5a-812c-58f4f690cde3@candelatech.com>
On 2017-02-01 00:30, Ben Greear wrote:
> On 01/31/2017 10:41 AM, Ashok Raj Nagarajan wrote:
>> This patch introduce a new driver callback drv_sta_set_txpwr. This API
>> will
>> copy the transmit power value passed from user space and call the
>> driver
>> callback to set the tx power for the station.
>>
>> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
>> ---
>> include/net/mac80211.h | 6 ++++++
>> net/mac80211/cfg.c | 7 +++++++
>> net/mac80211/driver-ops.c | 21 +++++++++++++++++++++
>> net/mac80211/driver-ops.h | 5 +++++
>> net/mac80211/trace.h | 27 +++++++++++++++++++++++++++
>> 5 files changed, 66 insertions(+)
>>
>> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>> index 5345d35..e059d5a 100644
>> --- a/include/net/mac80211.h
>> +++ b/include/net/mac80211.h
>> @@ -1777,6 +1777,8 @@ struct ieee80211_sta_rates {
>> * This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE
>> 2).
>> * @support_p2p_ps: indicates whether the STA supports P2P PS
>> mechanism or not.
>> * @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by
>> rate control.
>> + * @txpwr: indicates the tx power, in dBm, to be used when sending
>> data frames
>> + * to the STA. Value of 0 means, automatic (default) tx power.
>
> Atheros NICs use 1/2 dBm increments internally, so maybe pass down mBm
> to the driver so you don't
> loose the granularity? (Other NICs may potentially have even finer
> control.)
>
ath10k firmware expects values to be in dBm and the calculations
regarding 1/2 dBm is taken care in firmware.
Thanks,
Ashok
> Thanks,
> Ben
^ permalink raw reply
* Re: [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
From: Ben Greear @ 2017-02-01 17:36 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: Ashok Raj Nagarajan, linux-wireless, johannes, ath10k
In-Reply-To: <14f6b3acb8b26d0eb806148c0ee47fb0@codeaurora.org>
On 02/01/2017 09:27 AM, Ashok Raj Nagarajan wrote:
>>> +static int nl80211_parse_sta_txpower_setting(struct genl_info *info,
>>> + struct station_parameters *params)
>>> +{
>>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>>> + enum nl80211_tx_power_setting type;
>>> + int idx;
>>> +
>>> + if (!rdev->ops->set_tx_power ||
>>> + !wiphy_ext_feature_isset(&rdev->wiphy,
>>> + NL80211_EXT_FEATURE_STA_TX_PWR))
>>> + return -EOPNOTSUPP;
>>
>> Maybe always let a user set to default value even if the driver does not
>> support setting specific values?
>>
>
> IMHO, having some default value in place of non-valid values may not be the right way.
If a user or user-space script wants to always be able to initialize things to default
values, it would be nice if it did not have to pay specific attention to whether the
NIC supports STA_TX_PWR feature or not. Since a NIC that does not support this feature will always
have sta TX power set to default by definition, that is why I think you should let
the call succeed in that case.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: store tx power value from user to station
From: Ben Greear @ 2017-02-01 17:32 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: Ashok Raj Nagarajan, linux-wireless, johannes, ath10k
In-Reply-To: <7584a5235b49b7799a2c15f91fb03794@codeaurora.org>
On 02/01/2017 09:29 AM, Ashok Raj Nagarajan wrote:
> On 2017-02-01 00:30, Ben Greear wrote:
>> On 01/31/2017 10:41 AM, Ashok Raj Nagarajan wrote:
>>> This patch introduce a new driver callback drv_sta_set_txpwr. This API will
>>> copy the transmit power value passed from user space and call the driver
>>> callback to set the tx power for the station.
>>>
>>> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
>>> ---
>>> include/net/mac80211.h | 6 ++++++
>>> net/mac80211/cfg.c | 7 +++++++
>>> net/mac80211/driver-ops.c | 21 +++++++++++++++++++++
>>> net/mac80211/driver-ops.h | 5 +++++
>>> net/mac80211/trace.h | 27 +++++++++++++++++++++++++++
>>> 5 files changed, 66 insertions(+)
>>>
>>> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>>> index 5345d35..e059d5a 100644
>>> --- a/include/net/mac80211.h
>>> +++ b/include/net/mac80211.h
>>> @@ -1777,6 +1777,8 @@ struct ieee80211_sta_rates {
>>> * This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
>>> * @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
>>> * @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by rate control.
>>> + * @txpwr: indicates the tx power, in dBm, to be used when sending data frames
>>> + * to the STA. Value of 0 means, automatic (default) tx power.
>>
>> Atheros NICs use 1/2 dBm increments internally, so maybe pass down mBm
>> to the driver so you don't
>> loose the granularity? (Other NICs may potentially have even finer control.)
>>
>
> ath10k firmware expects values to be in dBm and the calculations regarding 1/2 dBm is taken care in firmware.
Other drivers may want more precision, so I still think you should store this in mBm instead
of throwing away precision in the API.
A new and improved ath10k firmware may support 1/2 dBm units directly, for instance.
Thanks,
Ben
>
> Thanks,
> Ashok
>> Thanks,
>> Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] ath10k: add support for controlling tx power to a station
From: Ashok Raj Nagarajan @ 2017-02-01 17:44 UTC (permalink / raw)
To: Ben Greear; +Cc: Ashok Raj Nagarajan, ath10k, linux-wireless
In-Reply-To: <cbb69298-391d-b3d5-5a84-5792fe170f95@candelatech.com>
On 2017-02-01 00:27, Ben Greear wrote:
> On 01/31/2017 10:42 AM, Ashok Raj Nagarajan wrote:
>> This patch will add the support to control the transmit power for
>> traffic
>> to a station associated with the AP. Userspace provide the transmit
>> power
>> value in mBm units and the allowed range is from 0 to 70. Underlying
>> FW
>
> How did you come up with 70 mBm as the limit. This is only 7dBm?
>
> I would expect it to match the range of normal tx-power which is likely
> up to
> 30 dBm or so on some NICs (not counting regulatory limit).
>
I think I will have to re-word the commit log a bit. ath10k driver would
get the value in dBm only and the range is from 0 to 70 dBm. Looking at
the db.txt, I see a max value of 44 dm for a 60GHz channel. SO to be
little future proof having a greater acceptable range from user. The
final tx power will be calculated based on this extra parameter the user
passes on, including the regulatory limit for the channel.
Thanks,
Ashok
> Thanks,
> Ben
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2017-02-01
From: David Miller @ 2017-02-01 17:47 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87efzip7z1.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Wed, 01 Feb 2017 11:37:38 +0200
> here's a pull request to 4.11, more details in the signed tag below.
>
> I forgot to mention in the tag that this includes one small change to
> include/linux/soc/qcom/smem_state.h which was acked by Andy Gross in
> commit 6c0b2e833f14. It was needed to fix a build problem with wcn36xx
> using the SMD interface.
>
> Please let me know if you have any problems.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: store tx power value from user to station
From: Ashok Raj Nagarajan @ 2017-02-01 17:47 UTC (permalink / raw)
To: Ben Greear; +Cc: Ashok Raj Nagarajan, linux-wireless, johannes, ath10k
In-Reply-To: <35c617ff-c07a-b221-5742-b1487618bce7@candelatech.com>
On 2017-02-01 23:02, Ben Greear wrote:
> On 02/01/2017 09:29 AM, Ashok Raj Nagarajan wrote:
>> On 2017-02-01 00:30, Ben Greear wrote:
>>> On 01/31/2017 10:41 AM, Ashok Raj Nagarajan wrote:
>>>> This patch introduce a new driver callback drv_sta_set_txpwr. This
>>>> API will
>>>> copy the transmit power value passed from user space and call the
>>>> driver
>>>> callback to set the tx power for the station.
>>>>
>>>> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
>>>> ---
>>>> include/net/mac80211.h | 6 ++++++
>>>> net/mac80211/cfg.c | 7 +++++++
>>>> net/mac80211/driver-ops.c | 21 +++++++++++++++++++++
>>>> net/mac80211/driver-ops.h | 5 +++++
>>>> net/mac80211/trace.h | 27 +++++++++++++++++++++++++++
>>>> 5 files changed, 66 insertions(+)
>>>>
>>>> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>>>> index 5345d35..e059d5a 100644
>>>> --- a/include/net/mac80211.h
>>>> +++ b/include/net/mac80211.h
>>>> @@ -1777,6 +1777,8 @@ struct ieee80211_sta_rates {
>>>> * This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2
>>>> NOTE 2).
>>>> * @support_p2p_ps: indicates whether the STA supports P2P PS
>>>> mechanism or not.
>>>> * @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by
>>>> rate control.
>>>> + * @txpwr: indicates the tx power, in dBm, to be used when sending
>>>> data frames
>>>> + * to the STA. Value of 0 means, automatic (default) tx power.
>>>
>>> Atheros NICs use 1/2 dBm increments internally, so maybe pass down
>>> mBm
>>> to the driver so you don't
>>> loose the granularity? (Other NICs may potentially have even finer
>>> control.)
>>>
>>
>> ath10k firmware expects values to be in dBm and the calculations
>> regarding 1/2 dBm is taken care in firmware.
>
> Other drivers may want more precision, so I still think you should
> store this in mBm instead
> of throwing away precision in the API.
>
Okay point taken! Instead of having the conversion happening now in API,
I will push it down to the ath10k driver.
> A new and improved ath10k firmware may support 1/2 dBm units directly,
> for instance.
>
> Thanks,
> Ben
>
>>
>> Thanks,
>> Ashok
>>> Thanks,
>>> Ben
>>
^ permalink raw reply
* Re: [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
From: Ashok Raj Nagarajan @ 2017-02-01 17:57 UTC (permalink / raw)
To: Ben Greear; +Cc: Ashok Raj Nagarajan, linux-wireless, johannes, ath10k
In-Reply-To: <2b68dc12-44bf-f510-339a-3d987a88e8b5@candelatech.com>
On 2017-02-01 23:06, Ben Greear wrote:
> On 02/01/2017 09:27 AM, Ashok Raj Nagarajan wrote:
>
>>>> +static int nl80211_parse_sta_txpower_setting(struct genl_info
>>>> *info,
>>>> + struct station_parameters *params)
>>>> +{
>>>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>>>> + enum nl80211_tx_power_setting type;
>>>> + int idx;
>>>> +
>>>> + if (!rdev->ops->set_tx_power ||
>>>> + !wiphy_ext_feature_isset(&rdev->wiphy,
>>>> + NL80211_EXT_FEATURE_STA_TX_PWR))
>>>> + return -EOPNOTSUPP;
>>>
>>> Maybe always let a user set to default value even if the driver does
>>> not
>>> support setting specific values?
>>>
>>
>> IMHO, having some default value in place of non-valid values may not
>> be the right way.
>
> If a user or user-space script wants to always be able to initialize
> things to default
> values, it would be nice if it did not have to pay specific attention
> to whether the
> NIC supports STA_TX_PWR feature or not. Since a NIC that does not
> support this feature will always
> have sta TX power set to default by definition, that is why I think
> you should let
> the call succeed in that case.
>
I think it would be better/easier to handle the error cases in the
user-space scripts than at the driver here, no? NIC that doesn't support
this feature will set the tx power to the station depending on the rate
algorithm in place. So the same NIC and same station will have different
txpower depending on the environment? On the other hand, how do we
decide what constant (?) default value to be sent to userspace?
Thanks,
Ashok
> Thanks,
> Ben
^ permalink raw reply
* Re: [PATCH v2] ath10k: add support for controlling tx power to a station
From: Ben Greear @ 2017-02-01 18:05 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: linux-wireless, Ashok Raj Nagarajan, ath10k
In-Reply-To: <0c8b88d40b3adc0f09ade2780ed1d994@codeaurora.org>
On 02/01/2017 09:44 AM, Ashok Raj Nagarajan wrote:
> On 2017-02-01 00:27, Ben Greear wrote:
>> On 01/31/2017 10:42 AM, Ashok Raj Nagarajan wrote:
>>> This patch will add the support to control the transmit power for traffic
>>> to a station associated with the AP. Userspace provide the transmit power
>>> value in mBm units and the allowed range is from 0 to 70. Underlying FW
>>
>> How did you come up with 70 mBm as the limit. This is only 7dBm?
>>
>> I would expect it to match the range of normal tx-power which is likely up to
>> 30 dBm or so on some NICs (not counting regulatory limit).
>>
>
> I think I will have to re-word the commit log a bit. ath10k driver would get the value in dBm only and the range is from 0 to 70 dBm. Looking at the db.txt, I
> see a max value of 44 dm for a 60GHz channel. SO to be little future proof having a greater acceptable range from user. The final tx power will be calculated
> based on this extra parameter the user passes on, including the regulatory limit for the channel.
Why not just accept any value that fits within the storage (u16, probably). The regulatory logic
and other constraints can already make sure that the tx-power is not out-of-bounds, so the user cannot
really break something by attempting to set a large value.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
From: Ben Greear @ 2017-02-01 18:08 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: Ashok Raj Nagarajan, linux-wireless, johannes, ath10k
In-Reply-To: <1f3a3dec67fbe4f580750eb06f9b628b@codeaurora.org>
On 02/01/2017 09:57 AM, Ashok Raj Nagarajan wrote:
> On 2017-02-01 23:06, Ben Greear wrote:
>> On 02/01/2017 09:27 AM, Ashok Raj Nagarajan wrote:
>>
>>>>> +static int nl80211_parse_sta_txpower_setting(struct genl_info *info,
>>>>> + struct station_parameters *params)
>>>>> +{
>>>>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>>>>> + enum nl80211_tx_power_setting type;
>>>>> + int idx;
>>>>> +
>>>>> + if (!rdev->ops->set_tx_power ||
>>>>> + !wiphy_ext_feature_isset(&rdev->wiphy,
>>>>> + NL80211_EXT_FEATURE_STA_TX_PWR))
>>>>> + return -EOPNOTSUPP;
>>>>
>>>> Maybe always let a user set to default value even if the driver does not
>>>> support setting specific values?
>>>>
>>>
>>> IMHO, having some default value in place of non-valid values may not be the right way.
>>
>> If a user or user-space script wants to always be able to initialize
>> things to default
>> values, it would be nice if it did not have to pay specific attention
>> to whether the
>> NIC supports STA_TX_PWR feature or not. Since a NIC that does not
>> support this feature will always
>> have sta TX power set to default by definition, that is why I think
>> you should let
>> the call succeed in that case.
>>
>
> I think it would be better/easier to handle the error cases in the user-space scripts than at the driver here, no? NIC that doesn't support this feature will
> set the tx power to the station depending on the rate algorithm in place. So the same NIC and same station will have different txpower depending on the
> environment? On the other hand, how do we decide what constant (?) default value to be sent to userspace?
You use value '0' to mean set to default values, as far as I can tell.
So, always let a user set the value to 0, regardless of whether STA_RX_PWR feature exists or not.
If you are querying for a value to show user-space, return '0' in this case.
If user tries to set the value to non-zero, then it should fail with EOPNOTSUPP in case STA_TX_PWR
feature does not exist.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 4.10-rc3 11/13] net: liquidio: fix build errors when linux/phy*.h is removed from net/dsa.h
From: Felix Manlunas @ 2017-02-01 19:07 UTC (permalink / raw)
To: Russell King
Cc: linux-mips, linux-nfs, linux-scsi, linux-usb, linux-wireless,
netdev, target-devel, David S. Miller, Florian Fainelli,
Derek Chickles, Satanand Burla, Felix Manlunas, Raghu Vatsavayi
In-Reply-To: <E1cYdxX-0000X5-Hz@rmk-PC.armlinux.org.uk>
Russell King <rmk+kernel@armlinux.org.uk> wrote on Tue [2017-Jan-31 19:19:19 +0000]:
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: type defaults to 'int' in declaration of 'MODULE_LICENSE'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: type defaults to 'int' in declaration of 'MODULE_VERSION'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:36: error: expected ')' before 'int'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:37: error: expected ')' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: parameter names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: error: type defaults to 'int' in declaration of 'module_init'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: parameter names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: error: type defaults to 'int' in declaration of 'module_exit'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: parameter names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: type defaults to 'int' in declaration of 'MODULE_LICENSE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: type defaults to 'int' in declaration of 'MODULE_VERSION'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:40: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:40: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:40: error: type defaults to 'int' in declaration of 'MODULE_FIRMWARE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:40: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:41: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:41: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:41: error: type defaults to 'int' in declaration of 'MODULE_FIRMWARE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:41: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:42: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:42: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:42: error: type defaults to 'int' in declaration of 'MODULE_FIRMWARE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:42: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:43: error: expected declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:43: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:43: error: type defaults to 'int' in declaration of 'MODULE_FIRMWARE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:43: error: function declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:46: error: expected ')' before 'int'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:48: error: expected ')' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:53: error: expected ')' before 'int'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:54: error: expected ')' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:57: error: expected ')' before 'sizeof'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:58: error: expected ')' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:498: warning: data definitionhas no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:498: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:498: warning: parameter names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_main.c: In function 'octeon_recv_vf_drv_notice':
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4393: error: implicit declaration of function 'try_module_get'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4400: error: implicit declaration of function 'module_put'
> drivers/net/ethernet/cavium/liquidio/lio_main.c: At top level:
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4670: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4670: error: type defaults to 'int' in declaration of 'module_init'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4670: warning: parameter names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4671: warning: data definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4671: error: type defaults to 'int' in declaration of 'module_exit'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:4671: warning: parameter names (without types) in function declaration
>
> Add linux/module.h to both these files.
>
> drivers/net/ethernet/cavium/liquidio/octeon_console.c:40:31: error: expected ')' before 'int'
> drivers/net/ethernet/cavium/liquidio/octeon_console.c:42:4: error: expected ')' before string constant
>
> Add linux/moduleparam.h to this file.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Felix Manlunas <felix.manlunas@cavium.com>
Thank you.
^ 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