Re: [PATCH 0/4] ethtool: implement Energy Detect Powerdown support via phy-tunable
On Tue, Sep 03, 2019 at 07:06:22PM +0300, Alexandru Ardelean wrote: > This patch series is actually 2 series in 1. > > First 2 patches implement the kernel support for controlling Energy Detect > Powerdown support via phy-tunable, and the next 2 patches implement the > ethtool user-space control. > Hopefully, this combination of 2 series is an acceptable approach; if not, > I am fine to re-update it based on feedback. I understand your reasoning, but do keep in mind that userland ethtool and the kernel are managed in different git trees. Seperate patchsets would be preferable in general, although in some cases having an initial userland implementation to show against proposed kernel changes could be helpful. It would not be unusual for someone to ask for changes on the kernel patches. If that happens, just repost the kernel changes until you get a final merge. Once that happens, then repost the userland patches as a seperate patchset. But I'll keep an eye here -- if Dave merges the existing kernel patches as-is, I can take the already posted patchs (unless problems are found in code review). John > The `phy_tunable_id` has been named `ETHTOOL_PHY_EDPD` since it looks like > this feature is common across other PHYs (like EEE), and defining > `ETHTOOL_PHY_ENERGY_DETECT_POWER_DOWN` seems too long. > > The way EDPD works, is that the RX block is put to a lower power mode, > except for link-pulse detection circuits. The TX block is also put to low > power mode, but the PHY wakes-up periodically to send link pulses, to avoid > lock-ups in case the other side is also in EDPD mode. > > Currently, there are 2 PHY drivers that look like they could use this new > PHY tunable feature: the `adin` && `micrel` PHYs. > > This series updates only the `adin` PHY driver to support this new feature, > as this chip has been tested. A change for `micrel` can be proposed after a > discussion of the PHY-tunable API is resolved. > > -- > 2.20.1 > > -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: [PATCH] rtlwifi: rtl818x: fix indentation issue
On Thu, Jan 17, 2019 at 03:28:59PM +, Colin King wrote: > From: Colin Ian King > > There is a statement that is indented too deeply. Fix this. > > Signed-off-by: Colin Ian King Acked-by: John W. Linville -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)
to know what mode "xyz" is and if it exists and is > supported > > Unresolved questions/tasks: > > - allow dumps for "get" type requests, e.g. listing EEE settings for all > interfaces in current netns > > - find reasonable format for data transfers (e.g. eeprom dump or flash) > > - while the netlink interface allows easy future extensions, ethtool_ops > interface does not; some settings could be implemented using tunables and > accessed via relevant netlink messages (as well as tunables) from > userspace but in the long term, something better will be needed > > - it would be nice if driver could provide useful error/warning messages to > be passed to userspace via extended ACK; example: while testing, I found > a driver which only allows values 0, 1, 3 and 1 for certain parameter > but the only way poor user can find out is either by trying all values or > by checking driver source > > Michal Kubecek (9): > netlink: introduce nla_put_bitfield32() > ethtool: introduce ethtool netlink interface > ethtool: helper functions for netlink interface > ethtool: netlink bitset handling > ethtool: implement GET_DRVINFO message > ethtool: implement GET_SETTINGS message > ethtool: implement SET_SETTINGS message > ethtool: implement GET_PARAMS message > ethtool: implement SET_PARAMS message > > Documentation/networking/ethtool-netlink.txt | 466 ++ > include/linux/ethtool_netlink.h | 12 + > include/linux/netdevice.h|2 + > include/net/netlink.h| 15 + > include/uapi/linux/ethtool.h |3 + > include/uapi/linux/ethtool_netlink.h | 239 +++ > net/Kconfig |7 + > net/core/Makefile|3 +- > net/core/ethtool.c | 150 +- > net/core/ethtool_common.c| 158 ++ > net/core/ethtool_common.h| 19 + > net/core/ethtool_netlink.c | 2323 > ++ > 12 files changed, 3260 insertions(+), 137 deletions(-) > create mode 100644 Documentation/networking/ethtool-netlink.txt > create mode 100644 include/linux/ethtool_netlink.h > create mode 100644 include/uapi/linux/ethtool_netlink.h > create mode 100644 net/core/ethtool_common.c > create mode 100644 net/core/ethtool_common.h > create mode 100644 net/core/ethtool_netlink.c > > -- > 2.15.1 > > -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)
to know what mode "xyz" is and if it exists and is > supported > > Unresolved questions/tasks: > > - allow dumps for "get" type requests, e.g. listing EEE settings for all > interfaces in current netns > > - find reasonable format for data transfers (e.g. eeprom dump or flash) > > - while the netlink interface allows easy future extensions, ethtool_ops > interface does not; some settings could be implemented using tunables and > accessed via relevant netlink messages (as well as tunables) from > userspace but in the long term, something better will be needed > > - it would be nice if driver could provide useful error/warning messages to > be passed to userspace via extended ACK; example: while testing, I found > a driver which only allows values 0, 1, 3 and 1 for certain parameter > but the only way poor user can find out is either by trying all values or > by checking driver source > > Michal Kubecek (9): > netlink: introduce nla_put_bitfield32() > ethtool: introduce ethtool netlink interface > ethtool: helper functions for netlink interface > ethtool: netlink bitset handling > ethtool: implement GET_DRVINFO message > ethtool: implement GET_SETTINGS message > ethtool: implement SET_SETTINGS message > ethtool: implement GET_PARAMS message > ethtool: implement SET_PARAMS message > > Documentation/networking/ethtool-netlink.txt | 466 ++ > include/linux/ethtool_netlink.h | 12 + > include/linux/netdevice.h|2 + > include/net/netlink.h| 15 + > include/uapi/linux/ethtool.h |3 + > include/uapi/linux/ethtool_netlink.h | 239 +++ > net/Kconfig |7 + > net/core/Makefile|3 +- > net/core/ethtool.c | 150 +- > net/core/ethtool_common.c| 158 ++ > net/core/ethtool_common.h| 19 + > net/core/ethtool_netlink.c | 2323 > ++ > 12 files changed, 3260 insertions(+), 137 deletions(-) > create mode 100644 Documentation/networking/ethtool-netlink.txt > create mode 100644 include/linux/ethtool_netlink.h > create mode 100644 include/uapi/linux/ethtool_netlink.h > create mode 100644 net/core/ethtool_common.c > create mode 100644 net/core/ethtool_common.h > create mode 100644 net/core/ethtool_netlink.c > > -- > 2.15.1 > > -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
[PATCH] nbd: fix incorrect unlock of nbd->sock_lock in sock_shutdown
Commit 0eadf37afc250 ("nbd: allow block mq to deal with timeouts")
changed normal usage of nbd->sock_lock to use spin_lock/spin_unlock
rather than the *_irq variants, but it missed this unlock in an
error path.
Found by Coverity, CID 1373871.
Signed-off-by: John W. Linville <linvi...@tuxdriver.com>
Cc: Josef Bacik <jba...@fb.com>
Cc: Jens Axboe <ax...@fb.com>
Cc: Markus Pargmann <m...@pengutronix.de>
Fixes: 0eadf37afc250 ("nbd: allow block mq to deal with timeouts")
---
By inspection (i.e. compile tested only)...
drivers/block/nbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index ba405b55329f..19a16b2dbb91 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -164,7 +164,7 @@ static void sock_shutdown(struct nbd_device *nbd)
spin_lock(>sock_lock);
if (!nbd->sock) {
- spin_unlock_irq(>sock_lock);
+ spin_unlock(>sock_lock);
return;
}
--
2.7.4
[PATCH] nbd: fix incorrect unlock of nbd->sock_lock in sock_shutdown
Commit 0eadf37afc250 ("nbd: allow block mq to deal with timeouts")
changed normal usage of nbd->sock_lock to use spin_lock/spin_unlock
rather than the *_irq variants, but it missed this unlock in an
error path.
Found by Coverity, CID 1373871.
Signed-off-by: John W. Linville
Cc: Josef Bacik
Cc: Jens Axboe
Cc: Markus Pargmann
Fixes: 0eadf37afc250 ("nbd: allow block mq to deal with timeouts")
---
By inspection (i.e. compile tested only)...
drivers/block/nbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index ba405b55329f..19a16b2dbb91 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -164,7 +164,7 @@ static void sock_shutdown(struct nbd_device *nbd)
spin_lock(>sock_lock);
if (!nbd->sock) {
- spin_unlock_irq(>sock_lock);
+ spin_unlock(>sock_lock);
return;
}
--
2.7.4
Re: Anyone have a clone of wireless-legacy.git?
On Fri, Jun 03, 2016 at 09:06:23AM +0200, Johannes Berg wrote: > > > http://www.filewatcher.com/_/?q=wireless-legacy.git, maybe ? > > > > Seems to work - both have the same branches: > > adm8211 72c942ed694e [PATCH] adm8211: fix build breakage > from skb->mac.raw > at76279f8592e428 cfg80211: keep track of supported > interface modes (at76) > ath5k 8584ac94e3bb [PATCH] ath5k: Internalize Atheros > Turbo modes > ath5k-2008-01-215b8ca29e11b5 ath5k: remove duplicate bssid variable > mac80211-attic 2bc68d999610 [PATCH] mac80211: remove scan struct > from hostapd_param > mac80211-dungeonad097a32e9ad [PATCH] mac80211 [HT] 802.11 code > compiles under CONFIG_MAC80211_HT > prism54usb 101e59f5e18a prism54usb: more fix for wireless > Kconfig changes > rtl8180-2008-01-21 55fc0e806a93 rtl8180: remove calibration error > message for rtl8225z2 > tiacx d6a6811c508b [PATCH] TI acx100/acx111: Make debug > level selectable in configuration > wireless-dev-2007-08-10 ca29ec8f05c1 Merge ../wireless-dev-legacy into > wireless-dev-2007-08-10 > wireless-dev-2007-09-24 cd799e167394 Merge branch 'p54' into everything > > johannes I got them both from the two FTP sites, and both git repos appear to be identical. It would be best if someone had an actual record of the commit hash values, but this might be the best I/we can do...? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: Anyone have a clone of wireless-legacy.git?
On Fri, Jun 03, 2016 at 09:06:23AM +0200, Johannes Berg wrote: > > > http://www.filewatcher.com/_/?q=wireless-legacy.git, maybe ? > > > > Seems to work - both have the same branches: > > adm8211 72c942ed694e [PATCH] adm8211: fix build breakage > from skb->mac.raw > at76279f8592e428 cfg80211: keep track of supported > interface modes (at76) > ath5k 8584ac94e3bb [PATCH] ath5k: Internalize Atheros > Turbo modes > ath5k-2008-01-215b8ca29e11b5 ath5k: remove duplicate bssid variable > mac80211-attic 2bc68d999610 [PATCH] mac80211: remove scan struct > from hostapd_param > mac80211-dungeonad097a32e9ad [PATCH] mac80211 [HT] 802.11 code > compiles under CONFIG_MAC80211_HT > prism54usb 101e59f5e18a prism54usb: more fix for wireless > Kconfig changes > rtl8180-2008-01-21 55fc0e806a93 rtl8180: remove calibration error > message for rtl8225z2 > tiacx d6a6811c508b [PATCH] TI acx100/acx111: Make debug > level selectable in configuration > wireless-dev-2007-08-10 ca29ec8f05c1 Merge ../wireless-dev-legacy into > wireless-dev-2007-08-10 > wireless-dev-2007-09-24 cd799e167394 Merge branch 'p54' into everything > > johannes I got them both from the two FTP sites, and both git repos appear to be identical. It would be best if someone had an actual record of the commit hash values, but this might be the best I/we can do...? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: Anyone have a clone of wireless-legacy.git?
On Thu, Jun 02, 2016 at 06:18:27PM -0700, Guenter Roeck wrote: > On Thu, Jun 02, 2016 at 02:38:04PM -0400, John W. Linville wrote: > > It has recently come to my attention that the old wireless-legacy.git > > tree is no longer available on kernel.org. I honestly have no idea > > what happened to it -- for all I know I fat-fingered it some time > > ago or whatever. Anyway, apparently there are some references in it > > "out there" and it would be good if we had a copy available somewhere > > public. > > > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE > > IT! Please let me know that you've got it and I will arrange to get > > a copy of it from you in order to make it available publicly again. > > > > I appreciate your support! > > > http://www.filewatcher.com/_/?q=wireless-legacy.git, maybe ? Awesome...thanks for the tip! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: Anyone have a clone of wireless-legacy.git?
On Thu, Jun 02, 2016 at 06:18:27PM -0700, Guenter Roeck wrote: > On Thu, Jun 02, 2016 at 02:38:04PM -0400, John W. Linville wrote: > > It has recently come to my attention that the old wireless-legacy.git > > tree is no longer available on kernel.org. I honestly have no idea > > what happened to it -- for all I know I fat-fingered it some time > > ago or whatever. Anyway, apparently there are some references in it > > "out there" and it would be good if we had a copy available somewhere > > public. > > > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE > > IT! Please let me know that you've got it and I will arrange to get > > a copy of it from you in order to make it available publicly again. > > > > I appreciate your support! > > > http://www.filewatcher.com/_/?q=wireless-legacy.git, maybe ? Awesome...thanks for the tip! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: Anyone have a clone of wireless-legacy.git?
On Thu, Jun 02, 2016 at 08:48:08PM +0100, One Thousand Gnomes wrote: > On Thu, 2 Jun 2016 14:38:04 -0400 > "John W. Linville" <linvi...@tuxdriver.com> wrote: > > > It has recently come to my attention that the old wireless-legacy.git > > tree is no longer available on kernel.org. I honestly have no idea > > what happened to it -- for all I know I fat-fingered it some time > > ago or whatever. Anyway, apparently there are some references in it > > "out there" and it would be good if we had a copy available somewhere > > public. > > > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE > > IT! Please let me know that you've got it and I will arrange to get > > a copy of it from you in order to make it available publicly again. > > Before you do that please make sure you get multiple copies from > unconnected sources and confirm none of them are trojanned. I will endeavour to ensurance provenance, certainly. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: Anyone have a clone of wireless-legacy.git?
On Thu, Jun 02, 2016 at 08:48:08PM +0100, One Thousand Gnomes wrote: > On Thu, 2 Jun 2016 14:38:04 -0400 > "John W. Linville" wrote: > > > It has recently come to my attention that the old wireless-legacy.git > > tree is no longer available on kernel.org. I honestly have no idea > > what happened to it -- for all I know I fat-fingered it some time > > ago or whatever. Anyway, apparently there are some references in it > > "out there" and it would be good if we had a copy available somewhere > > public. > > > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE > > IT! Please let me know that you've got it and I will arrange to get > > a copy of it from you in order to make it available publicly again. > > Before you do that please make sure you get multiple copies from > unconnected sources and confirm none of them are trojanned. I will endeavour to ensurance provenance, certainly. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Anyone have a clone of wireless-legacy.git?
It has recently come to my attention that the old wireless-legacy.git tree is no longer available on kernel.org. I honestly have no idea what happened to it -- for all I know I fat-fingered it some time ago or whatever. Anyway, apparently there are some references in it "out there" and it would be good if we had a copy available somewhere public. If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE IT! Please let me know that you've got it and I will arrange to get a copy of it from you in order to make it available publicly again. I appreciate your support! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Anyone have a clone of wireless-legacy.git?
It has recently come to my attention that the old wireless-legacy.git tree is no longer available on kernel.org. I honestly have no idea what happened to it -- for all I know I fat-fingered it some time ago or whatever. Anyway, apparently there are some references in it "out there" and it would be good if we had a copy available somewhere public. If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE IT! Please let me know that you've got it and I will arrange to get a copy of it from you in order to make it available publicly again. I appreciate your support! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: wireless-drivers: random cleanup patches piling up
On Fri, Jan 22, 2016 at 02:21:20PM +0200, Kalle Valo wrote: > Joe Perches writes: > > > On Thu, 2016-01-21 at 16:58 +0200, Kalle Valo wrote: > >> Hi, > >> > >> I have quite a lot of random cleanup patches from new developers waiting > >> in my queue: > >> > >> https://patchwork.kernel.org/project/linux-wireless/list/?state=10=25621=date > >> > >> (Not all of them are cleanup patches, there are also few patches > >> deferred due to other reasons, but you get the idea.) > >> > >> These cleanup patches usually take quite a lot of my time and I'm > >> starting to doubt the benefit, compared to the time needed to dig > >> through them and figuring out what to apply. And this is of course time > >> away from other patches, so it's slowing down "real" development. > >> > >> I really don't know what to do. Part of me is saying that I just should > >> drop them unless it's reviewed by a more experienced developer but on > >> the other hand this is a good way get new developers onboard. > >> > >> What others think? Are these kind of patches useful? > > > > Some yes, mostly not really. > > > > While whitespace style patches have some small value, > > very few of the new contributors that use tools like > > "scripts/checkpatch.pl -f" on various kernel files > > actually continue on to submit actual defect fixing > > or optimization or code clarity patches. > > That's also my experience from maintaining wireless-drivers for a year, > this seems to be a "hit and run" type of phenomenon. Should we be looking for someone to run a "wireless-driver-cleanups" tree? They could handle the cleanups and trivial stuff, and send you a pull request a couple of times per release...? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: wireless-drivers: random cleanup patches piling up
On Fri, Jan 22, 2016 at 02:21:20PM +0200, Kalle Valo wrote: > Joe Perches <j...@perches.com> writes: > > > On Thu, 2016-01-21 at 16:58 +0200, Kalle Valo wrote: > >> Hi, > >> > >> I have quite a lot of random cleanup patches from new developers waiting > >> in my queue: > >> > >> https://patchwork.kernel.org/project/linux-wireless/list/?state=10=25621=date > >> > >> (Not all of them are cleanup patches, there are also few patches > >> deferred due to other reasons, but you get the idea.) > >> > >> These cleanup patches usually take quite a lot of my time and I'm > >> starting to doubt the benefit, compared to the time needed to dig > >> through them and figuring out what to apply. And this is of course time > >> away from other patches, so it's slowing down "real" development. > >> > >> I really don't know what to do. Part of me is saying that I just should > >> drop them unless it's reviewed by a more experienced developer but on > >> the other hand this is a good way get new developers onboard. > >> > >> What others think? Are these kind of patches useful? > > > > Some yes, mostly not really. > > > > While whitespace style patches have some small value, > > very few of the new contributors that use tools like > > "scripts/checkpatch.pl -f" on various kernel files > > actually continue on to submit actual defect fixing > > or optimization or code clarity patches. > > That's also my experience from maintaining wireless-drivers for a year, > this seems to be a "hit and run" type of phenomenon. Should we be looking for someone to run a "wireless-driver-cleanups" tree? They could handle the cleanups and trivial stuff, and send you a pull request a couple of times per release...? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready.
Re: [Tech-board] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process
Good write-up! We should archive this for reference in future years! John On Sat, Oct 24, 2015 at 11:28:19AM +0100, Grant Likely wrote: > [Including Rafael who also asked about what being a TAB member means] > > On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart wrote: > > On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote: > > Is there a good description of what is expected of a TAB member? How much > > time > > is involved? What makes a great TAB member? > > > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > > > I've read the charter and scanned some of the minutes, but I'd still like to > > hear from some of the "incumbants". Specifically, what makes you successful > > as a > > member of the TAB? > > I've been asked several versions of the same question, and also the > annual "what does the TAB actually do?" question, so I'm going to try > and answer them all in one email: > > As the name implies, the primary job of the TAB is to advise the Linux > Foundation board of directors on technical, social and political > issues regarding Linux and Open Source. Our job is to represent the > views of Linux developers and to foster constructive communication > between the Linux Foundation leadership and our community. > > A natural by-product of this is that the TAB also acts in the > background to identify and resolve issues for the Linux community > before they become a problem. The TAB tends to be composed of well > respected individuals with good connections throughout our community, > and so we're in a good place to recognize who to talk to when an issue > is raised. > > Finally, there are a few projects that the TAB is directly responsible > for. We make sure there is a planning committee for the Linux Plumbers > conference every year. We run a 'buddy' program to help new Linux > Foundation member companies learn how to be fine upstanding Linux > citizens. We are the response team for any issues of harassment or > abuse within the kernel community. In past years we coordinated the > response to UEFI Secure Boot to ensure that Linux would not be locked > out of the consumer PC market, and been active in helping member > companies understand and be comfortable with the licencing obligations > associated with Linux. > > A good TAB member is well respected by the community, is a ready > listener, is comfortable discussing both technical and social issues, > and has a good understanding of how the Linux community works. Since > the TAB deals with a wide range of issues, the ideal TAB candidate > should be prepared to consider issues outside of their own area of > expertise. Sometime the most important characteristic of a TAB member > is recognizing when an issue is beyond their depth and go looking for > the right person to consult. > > Time commitment wise, The TAB meets once a month for a conference > call, plus any additional time required to deal with TAB business. > Once a year (6 months after the TAB general election) the TAB elects > one member to serve as the chair, and the chair of the TAB is proposed > to the Linux Foundation to serve as a Linux Foundation Director which > has additional time requirements. > > One last point, some issues addressed by the TAB are highly sensitive > and any member can request a topic to be kept strictly confidential. > We do this to protect the working relationship we have with industry > bodies, and to protect the companies and individuals involved. Any > prospective TAB member must be comfortable abiding by our > confidentiality rules. > > I hope this answers your questions. > > g. > ___ > Tech-board mailing list > tech-bo...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/tech-board > -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Tech-board] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process
Good write-up! We should archive this for reference in future years! John On Sat, Oct 24, 2015 at 11:28:19AM +0100, Grant Likely wrote: > [Including Rafael who also asked about what being a TAB member means] > > On Thu, Oct 22, 2015 at 10:03 PM, Darren Hart <dvh...@infradead.org> wrote: > > On Tue, Oct 06, 2015 at 11:06:47AM +0100, Grant Likely wrote: > > Is there a good description of what is expected of a TAB member? How much > > time > > is involved? What makes a great TAB member? > > > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > > > I've read the charter and scanned some of the minutes, but I'd still like to > > hear from some of the "incumbants". Specifically, what makes you successful > > as a > > member of the TAB? > > I've been asked several versions of the same question, and also the > annual "what does the TAB actually do?" question, so I'm going to try > and answer them all in one email: > > As the name implies, the primary job of the TAB is to advise the Linux > Foundation board of directors on technical, social and political > issues regarding Linux and Open Source. Our job is to represent the > views of Linux developers and to foster constructive communication > between the Linux Foundation leadership and our community. > > A natural by-product of this is that the TAB also acts in the > background to identify and resolve issues for the Linux community > before they become a problem. The TAB tends to be composed of well > respected individuals with good connections throughout our community, > and so we're in a good place to recognize who to talk to when an issue > is raised. > > Finally, there are a few projects that the TAB is directly responsible > for. We make sure there is a planning committee for the Linux Plumbers > conference every year. We run a 'buddy' program to help new Linux > Foundation member companies learn how to be fine upstanding Linux > citizens. We are the response team for any issues of harassment or > abuse within the kernel community. In past years we coordinated the > response to UEFI Secure Boot to ensure that Linux would not be locked > out of the consumer PC market, and been active in helping member > companies understand and be comfortable with the licencing obligations > associated with Linux. > > A good TAB member is well respected by the community, is a ready > listener, is comfortable discussing both technical and social issues, > and has a good understanding of how the Linux community works. Since > the TAB deals with a wide range of issues, the ideal TAB candidate > should be prepared to consider issues outside of their own area of > expertise. Sometime the most important characteristic of a TAB member > is recognizing when an issue is beyond their depth and go looking for > the right person to consult. > > Time commitment wise, The TAB meets once a month for a conference > call, plus any additional time required to deal with TAB business. > Once a year (6 months after the TAB general election) the TAB elects > one member to serve as the chair, and the chair of the TAB is proposed > to the Linux Foundation to serve as a Linux Foundation Director which > has additional time requirements. > > One last point, some issues addressed by the TAB are highly sensitive > and any member can request a topic to be kept strictly confidential. > We do this to protect the working relationship we have with industry > bodies, and to protect the companies and individuals involved. Any > prospective TAB member must be comfortable abiding by our > confidentiality rules. > > I hope this answers your questions. > > g. > ___ > Tech-board mailing list > tech-bo...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/tech-board > -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mwl8k: refactor some conditionals for clarity
CC [M] drivers/net/wireless/mwl8k.o
drivers/net/wireless/mwl8k.c: In function ‘mwl8k_bss_info_changed’:
drivers/net/wireless/mwl8k.c:3290:2: warning: ‘ap_mcs_rates’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
memcpy(cmd->mcs_set, mcs_rates, 16);
^
drivers/net/wireless/mwl8k.c:4987:5: note: ‘ap_mcs_rates’ was declared here
u8 ap_mcs_rates[16];
^
The warning was bogus. But the conditionals were rather complicated,
with multiple redundant checks. This consolidates the checking and
makes it more readable IMHO.
Signed-off-by: John W. Linville
---
drivers/net/wireless/mwl8k.c | 49 ++--
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 77361af68b18..9420fc61c2e6 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -5019,35 +5019,36 @@ mwl8k_bss_info_changed_sta(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
memcpy(ap_mcs_rates, ap->ht_cap.mcs.rx_mask, 16);
rcu_read_unlock();
- }
- if ((changed & BSS_CHANGED_ASSOC) && vif->bss_conf.assoc &&
- !priv->ap_fw) {
- rc = mwl8k_cmd_set_rate(hw, vif, ap_legacy_rates, ap_mcs_rates);
- if (rc)
- goto out;
+ if (changed & BSS_CHANGED_ASSOC) {
+ if (!priv->ap_fw) {
+ rc = mwl8k_cmd_set_rate(hw, vif,
+ ap_legacy_rates,
+ ap_mcs_rates);
+ if (rc)
+ goto out;
- rc = mwl8k_cmd_use_fixed_rate_sta(hw);
- if (rc)
- goto out;
- } else {
- if ((changed & BSS_CHANGED_ASSOC) && vif->bss_conf.assoc &&
- priv->ap_fw) {
- int idx;
- int rate;
+ rc = mwl8k_cmd_use_fixed_rate_sta(hw);
+ if (rc)
+ goto out;
+ } else {
+ int idx;
+ int rate;
- /* Use AP firmware specific rate command.
-*/
- idx = ffs(vif->bss_conf.basic_rates);
- if (idx)
- idx--;
+ /* Use AP firmware specific rate command.
+*/
+ idx = ffs(vif->bss_conf.basic_rates);
+ if (idx)
+ idx--;
- if (hw->conf.chandef.chan->band == IEEE80211_BAND_2GHZ)
- rate = mwl8k_rates_24[idx].hw_value;
- else
- rate = mwl8k_rates_50[idx].hw_value;
+ if (hw->conf.chandef.chan->band ==
+ IEEE80211_BAND_2GHZ)
+ rate = mwl8k_rates_24[idx].hw_value;
+ else
+ rate = mwl8k_rates_50[idx].hw_value;
- mwl8k_cmd_use_fixed_rate_ap(hw, rate, rate);
+ mwl8k_cmd_use_fixed_rate_ap(hw, rate, rate);
+ }
}
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mwl8k: refactor some conditionals for clarity
CC [M] drivers/net/wireless/mwl8k.o
drivers/net/wireless/mwl8k.c: In function ‘mwl8k_bss_info_changed’:
drivers/net/wireless/mwl8k.c:3290:2: warning: ‘ap_mcs_rates’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
memcpy(cmd-mcs_set, mcs_rates, 16);
^
drivers/net/wireless/mwl8k.c:4987:5: note: ‘ap_mcs_rates’ was declared here
u8 ap_mcs_rates[16];
^
The warning was bogus. But the conditionals were rather complicated,
with multiple redundant checks. This consolidates the checking and
makes it more readable IMHO.
Signed-off-by: John W. Linville linvi...@tuxdriver.com
---
drivers/net/wireless/mwl8k.c | 49 ++--
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 77361af68b18..9420fc61c2e6 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -5019,35 +5019,36 @@ mwl8k_bss_info_changed_sta(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
memcpy(ap_mcs_rates, ap-ht_cap.mcs.rx_mask, 16);
rcu_read_unlock();
- }
- if ((changed BSS_CHANGED_ASSOC) vif-bss_conf.assoc
- !priv-ap_fw) {
- rc = mwl8k_cmd_set_rate(hw, vif, ap_legacy_rates, ap_mcs_rates);
- if (rc)
- goto out;
+ if (changed BSS_CHANGED_ASSOC) {
+ if (!priv-ap_fw) {
+ rc = mwl8k_cmd_set_rate(hw, vif,
+ ap_legacy_rates,
+ ap_mcs_rates);
+ if (rc)
+ goto out;
- rc = mwl8k_cmd_use_fixed_rate_sta(hw);
- if (rc)
- goto out;
- } else {
- if ((changed BSS_CHANGED_ASSOC) vif-bss_conf.assoc
- priv-ap_fw) {
- int idx;
- int rate;
+ rc = mwl8k_cmd_use_fixed_rate_sta(hw);
+ if (rc)
+ goto out;
+ } else {
+ int idx;
+ int rate;
- /* Use AP firmware specific rate command.
-*/
- idx = ffs(vif-bss_conf.basic_rates);
- if (idx)
- idx--;
+ /* Use AP firmware specific rate command.
+*/
+ idx = ffs(vif-bss_conf.basic_rates);
+ if (idx)
+ idx--;
- if (hw-conf.chandef.chan-band == IEEE80211_BAND_2GHZ)
- rate = mwl8k_rates_24[idx].hw_value;
- else
- rate = mwl8k_rates_50[idx].hw_value;
+ if (hw-conf.chandef.chan-band ==
+ IEEE80211_BAND_2GHZ)
+ rate = mwl8k_rates_24[idx].hw_value;
+ else
+ rate = mwl8k_rates_50[idx].hw_value;
- mwl8k_cmd_use_fixed_rate_ap(hw, rate, rate);
+ mwl8k_cmd_use_fixed_rate_ap(hw, rate, rate);
+ }
}
}
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-12-16
Dave,
Please pull this batch of fixes intended for the 3.19 stream!
For the Bluetooth bits, Johan says:
"The patches consist of:
- Coccinelle warning fix
- hci_dev_lock/unlock fixes
- Fixes for pending mgmt command handling
- Fixes for properly following the force_lesc_support switch
- Fix for a Microsoft branded Broadcom adapter
- New device id for Atheros AR3012
- Fix for BR/EDR Secure Connections enabling"
Along with that...
Brian Norris avoids leaking some kernel memory contents via printk in brcmsmac.
Julia Lawall corrects some misspellings in a few drivers.
Larry Finger gives us one more rtlwifi fix to correct a porting oversight.
Wei Yongjun fixes a sparse warning in rtlwifi.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 67e2c3883828b39548cee2091b36656787775d95:
Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
(2014-12-14 20:36:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-12-15
for you to fetch changes up to 9a1dce3a059111a7289680f4b8c0ec4f8736b6ee:
rtlwifi: rtl8192ce: Set fw_ready flag (2014-12-15 13:46:20 -0500)
Brian Norris (1):
brcmsmac: don't leak kernel memory via printk()
Fengguang Wu (1):
Bluetooth: fix err_cast.cocci warnings
Jaganath Kanakkassery (2):
Bluetooth: Fix missing hci_dev_lock/unlock in mgmt req_complete()
Bluetooth: Fix missing hci_dev_lock/unlock in hci_event
Janne Heikkinen (1):
Bluetooth: Add USB device 04ca:3010 as Atheros AR3012
Johan Hedberg (5):
Bluetooth: Fix calling hci_conn_put too early
Bluetooth: Fix incorrect pending cmd removal in pairing_complete()
Bluetooth: Fix notifying mgmt power off before flushing connection list
Bluetooth: Fix enabling BR/EDR SC when powering on
Bluetooth: Fix mgmt response status when removing adapter
John W. Linville (1):
Merge branch 'for-upstream' of
git://git.kernel.org/.../bluetooth/bluetooth-next
Julia Lawall (3):
zd1211rw: fix misspelling of current function in string
hostap_cs: fix misspelling of current function in string
rtlwifi: rtl8821ae: fix misspelling of current function in string
Larry Finger (1):
rtlwifi: rtl8192ce: Set fw_ready flag
Marcel Holtmann (4):
Bluetooth: Check for force_lesc_support when enabling SMP over BR/EDR
Bluetooth: Check for force_lesc_support before rejecting SMP over BR/EDR
Bluetooth: Fix generation of non-resolvable private addresses
Bluetooth: Fix check for support for page scan related commands
Wei Yongjun (1):
rtlwifi: rtl8192cu: Fix sparse non static symbol warning
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/btusb.c | 1 +
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/hostap/hostap_cs.c| 15 ++---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c| 2 +
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c| 2 +-
drivers/net/wireless/rtlwifi/rtl8821ae/dm.c| 11 ++--
drivers/net/wireless/zd1211rw/zd_chip.c| 6 +-
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/hci_core.c | 60 ++
net/bluetooth/hci_event.c | 20 ++
net/bluetooth/l2cap_core.c | 5 +-
net/bluetooth/mgmt.c | 85 ++
net/bluetooth/smp.c| 5 +-
14 files changed, 143 insertions(+), 75 deletions(-)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index fce758896280..1ee27ac18de0 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -87,6 +87,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3007) },
{ USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x04CA, 0x300b) },
+ { USB_DEVICE(0x04CA, 0x3010) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0930, 0x0220) },
{ USB_DEVICE(0x0930, 0x0227) },
@@ -140,6 +141,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 31dd24ac9926..19cf2cf22e87 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -16
pull request: wireless 2014-12-16
Dave,
Please pull this batch of fixes intended for the 3.19 stream!
For the Bluetooth bits, Johan says:
The patches consist of:
- Coccinelle warning fix
- hci_dev_lock/unlock fixes
- Fixes for pending mgmt command handling
- Fixes for properly following the force_lesc_support switch
- Fix for a Microsoft branded Broadcom adapter
- New device id for Atheros AR3012
- Fix for BR/EDR Secure Connections enabling
Along with that...
Brian Norris avoids leaking some kernel memory contents via printk in brcmsmac.
Julia Lawall corrects some misspellings in a few drivers.
Larry Finger gives us one more rtlwifi fix to correct a porting oversight.
Wei Yongjun fixes a sparse warning in rtlwifi.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 67e2c3883828b39548cee2091b36656787775d95:
Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
(2014-12-14 20:36:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-12-15
for you to fetch changes up to 9a1dce3a059111a7289680f4b8c0ec4f8736b6ee:
rtlwifi: rtl8192ce: Set fw_ready flag (2014-12-15 13:46:20 -0500)
Brian Norris (1):
brcmsmac: don't leak kernel memory via printk()
Fengguang Wu (1):
Bluetooth: fix err_cast.cocci warnings
Jaganath Kanakkassery (2):
Bluetooth: Fix missing hci_dev_lock/unlock in mgmt req_complete()
Bluetooth: Fix missing hci_dev_lock/unlock in hci_event
Janne Heikkinen (1):
Bluetooth: Add USB device 04ca:3010 as Atheros AR3012
Johan Hedberg (5):
Bluetooth: Fix calling hci_conn_put too early
Bluetooth: Fix incorrect pending cmd removal in pairing_complete()
Bluetooth: Fix notifying mgmt power off before flushing connection list
Bluetooth: Fix enabling BR/EDR SC when powering on
Bluetooth: Fix mgmt response status when removing adapter
John W. Linville (1):
Merge branch 'for-upstream' of
git://git.kernel.org/.../bluetooth/bluetooth-next
Julia Lawall (3):
zd1211rw: fix misspelling of current function in string
hostap_cs: fix misspelling of current function in string
rtlwifi: rtl8821ae: fix misspelling of current function in string
Larry Finger (1):
rtlwifi: rtl8192ce: Set fw_ready flag
Marcel Holtmann (4):
Bluetooth: Check for force_lesc_support when enabling SMP over BR/EDR
Bluetooth: Check for force_lesc_support before rejecting SMP over BR/EDR
Bluetooth: Fix generation of non-resolvable private addresses
Bluetooth: Fix check for support for page scan related commands
Wei Yongjun (1):
rtlwifi: rtl8192cu: Fix sparse non static symbol warning
drivers/bluetooth/ath3k.c | 2 +
drivers/bluetooth/btusb.c | 1 +
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/hostap/hostap_cs.c| 15 ++---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c| 2 +
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c| 2 +-
drivers/net/wireless/rtlwifi/rtl8821ae/dm.c| 11 ++--
drivers/net/wireless/zd1211rw/zd_chip.c| 6 +-
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/hci_core.c | 60 ++
net/bluetooth/hci_event.c | 20 ++
net/bluetooth/l2cap_core.c | 5 +-
net/bluetooth/mgmt.c | 85 ++
net/bluetooth/smp.c| 5 +-
14 files changed, 143 insertions(+), 75 deletions(-)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index fce758896280..1ee27ac18de0 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -87,6 +87,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3007) },
{ USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x04CA, 0x300b) },
+ { USB_DEVICE(0x04CA, 0x3010) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0930, 0x0220) },
{ USB_DEVICE(0x0930, 0x0227) },
@@ -140,6 +141,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 31dd24ac9926..19cf2cf22e87 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -167,6 +167,7 @@ static
Re: pull request: bluetooth 2014-12-12
On Fri, Dec 12, 2014 at 07:44:35PM +0200, Johan Hedberg wrote: > Hi John, > > These fixes are intended for 3.19, note that the tree to pull from is > bluetooth-next (unlike the subject implies). I'd have normally done a > pull request from bluetooth.git, but since these fixes for 3.19 is all > we have so far I thought it's simpler if you just pull from our -next > tree. The patches consist of: > > - Coccinelle warning fix > - hci_dev_lock/unlock fixes > - Fixes for pending mgmt command handling > - Fixes for properly following the force_lesc_support switch > - Fix for a Microsoft branded Broadcom adapter > - New device id for Atheros AR3012 > - Fix for BR/EDR Secure Connections enabling > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 5a34bd5f5d8119def4feb1d2b4e3906b71059416: > > Bluetooth: Enable events for P-256 Public Key and DHKey commands > (2014-12-05 18:17:49 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to 9845904fd489288bcf693642c1b31cc463c0b660: > > Bluetooth: Fix mgmt response status when removing adapter (2014-12-12 > 13:20:12 +0100) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth 2014-12-12
On Fri, Dec 12, 2014 at 07:44:35PM +0200, Johan Hedberg wrote: Hi John, These fixes are intended for 3.19, note that the tree to pull from is bluetooth-next (unlike the subject implies). I'd have normally done a pull request from bluetooth.git, but since these fixes for 3.19 is all we have so far I thought it's simpler if you just pull from our -next tree. The patches consist of: - Coccinelle warning fix - hci_dev_lock/unlock fixes - Fixes for pending mgmt command handling - Fixes for properly following the force_lesc_support switch - Fix for a Microsoft branded Broadcom adapter - New device id for Atheros AR3012 - Fix for BR/EDR Secure Connections enabling Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 5a34bd5f5d8119def4feb1d2b4e3906b71059416: Bluetooth: Enable events for P-256 Public Key and DHKey commands (2014-12-05 18:17:49 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 9845904fd489288bcf693642c1b31cc463c0b660: Bluetooth: Fix mgmt response status when removing adapter (2014-12-12 13:20:12 +0100) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-12-05
On Fri, Dec 05, 2014 at 06:41:49PM +0200, Johan Hedberg wrote: > Hi John, > > Marcel had a couple more patches that were supposed to be in the pull > request, so here's a new one that supersedes the one I made earlier > today. > > In addition to the previous one this contains two more cleanups to > mac802154 as well as support for some new HCI features from the > Bluetooth 4.2 specification. > > From the original request: > > "Here's what should be the last bluetooth-next pull request for 3.19. > It's rather large but the majority of it is the Low Energy Secure > Connections feature that's part of the Bluetooth 4.2 specification. The > specification went public only this week so we couldn't publish the > corresponding code before that. The code itself can nevertheless be > considered fairly mature as it's been in development for over 6 months > and gone through several interoperability test events. > > Besides LE SC the pull request contains an important fix for command > complete events for mgmt sockets which also fixes some leaks of hci_conn > objects when powering off or unplugging Bluetooth adapters. > > A smaller feature that's part of the pull request is service discovery > support. This is like normal device discovery except that devices not > matching specific UUIDs or strong enough RSSI are filtered out. > > Other changes that the pull request contains are firmware dump support > to the btmrvl driver, firmware download support for Broadcom BCM20702A0 > variants, as well as some coding style cleanups in 6lowpan & > ieee802154/mac802154 code." > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit f6af675ef5489c69fc3d4faf8c6f477df3cbf8b9: > > Bluetooth: Automatically flushable packets aren't allowed on LE links > (2014-11-27 12:12:27 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to 5a34bd5f5d8119def4feb1d2b4e3906b71059416: > > Bluetooth: Enable events for P-256 Public Key and DHKey commands > (2014-12-05 18:17:49 +0200) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-12-05
On Fri, Dec 05, 2014 at 06:41:49PM +0200, Johan Hedberg wrote: Hi John, Marcel had a couple more patches that were supposed to be in the pull request, so here's a new one that supersedes the one I made earlier today. In addition to the previous one this contains two more cleanups to mac802154 as well as support for some new HCI features from the Bluetooth 4.2 specification. From the original request: Here's what should be the last bluetooth-next pull request for 3.19. It's rather large but the majority of it is the Low Energy Secure Connections feature that's part of the Bluetooth 4.2 specification. The specification went public only this week so we couldn't publish the corresponding code before that. The code itself can nevertheless be considered fairly mature as it's been in development for over 6 months and gone through several interoperability test events. Besides LE SC the pull request contains an important fix for command complete events for mgmt sockets which also fixes some leaks of hci_conn objects when powering off or unplugging Bluetooth adapters. A smaller feature that's part of the pull request is service discovery support. This is like normal device discovery except that devices not matching specific UUIDs or strong enough RSSI are filtered out. Other changes that the pull request contains are firmware dump support to the btmrvl driver, firmware download support for Broadcom BCM20702A0 variants, as well as some coding style cleanups in 6lowpan ieee802154/mac802154 code. Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit f6af675ef5489c69fc3d4faf8c6f477df3cbf8b9: Bluetooth: Automatically flushable packets aren't allowed on LE links (2014-11-27 12:12:27 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 5a34bd5f5d8119def4feb1d2b4e3906b71059416: Bluetooth: Enable events for P-256 Public Key and DHKey commands (2014-12-05 18:17:49 +0200) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-12-03
u8 *)(>desc[ring->idx]);
+ u8 own = (u8)rtl92ce_get_desc(entry, true, HW_DESC_OWN);
+
+ /*beacon packet will only use the first
+*descriptor defautly,and the own may not
+*be cleared by the hardware
+*/
+ if (own)
+ return false;
+ return true;
+}
+
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
index 9a39ec4204dd..4bec4b07e3e0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
@@ -723,6 +723,8 @@ bool rtl92ce_rx_query_desc(struct ieee80211_hw *hw,
void rtl92ce_set_desc(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name, u8 *val);
u32 rtl92ce_get_desc(u8 *pdesc, bool istx, u8 desc_name);
+bool rtl92ce_is_tx_desc_closed(struct ieee80211_hw *hw,
+ u8 hw_queue, u16 index);
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue);
void rtl92ce_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 *pdesc,
bool b_firstseg, bool b_lastseg,
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
pgpaNBWl4jnsc.pgp
Description: PGP signature
Re: [PATCH] SSB / B44: fix WOL for BCM4401
On Wed, Dec 03, 2014 at 04:18:55PM +0100, Michael Büsch wrote: > On Tue, 02 Dec 2014 16:23:49 -0600 > Larry Finger wrote: > > > On 12/02/2014 02:12 PM, Michael Büsch wrote: > > > On Tue, 2 Dec 2014 23:01:29 +0300 > > > Andrey Skvortsov wrote: > > > > > >> On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote: > > >>> On Mon, 1 Dec 2014 23:46:38 +0300 > > >>> Andrey Skvortsov wrote: > > >>> > > >>>> Wake On Lan was not working on laptop DELL Vostro 1500. > > >>>> If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs > > >>>> blinked. > > >>>> But the laptop could not be woken up with the Magic Packet. The reason > > >>>> for > > >>>> that was that PCIE was not enabled as a system wakeup source and > > >>>> therefore the host PCI bridge was not powered up in suspend mode. > > >>>> PCIE was not enabled in suspend by PM because no child devices were > > >>>> registered as wakeup source during suspend process. > > >>>> On laptop BCM4401 is connected through the SSB bus, that is connected > > >>>> to the > > >>>> PCI-Express bus. SSB and B44 did not use standard PM wakeup functions > > >>>> and did not forward wakeup settings to their parents. > > >>>> To fix that B44 driver enables PM wakeup and registers new wakeup > > >>>> source > > >>>> using device_set_wakeup_enable(). Wakeup is automatically reported to > > >>>> the parent SSB > > >>>> bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI > > >>>> bridge, if there is any > > >>>> child devices with enabled wakeup functionality. All other steps are > > >>>> done by PM core code. > > >>> > > >>> Thanks, this looks good. > > >>> I assume you tested this (I currently don't have a device to test this). > > >> > > >> Sure, I've tested it. WOL from suspend is working and after resume from > > >> hibernate Ethernet is working too. > > > > > > That sounds good, indeed. > > > I'd still prefer, if someone with b43 (wireless) would test it, too. > > > > I did a partial test with my PowerBook G4. With the patch installed, it > > would > > both suspend and hibernate, but WOL would be impossible. This computer uses > > a > > PCMCIA version of the BCM4318, and power is turned off to the PCMCIA card > > when > > suspended or hibernating. > > Thanks for testing. > > John, can you take this one? Or do we need to split the b44 part out? > I added my Signed-off. Um, sure...3.19 is OK I presume? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SSB / B44: fix WOL for BCM4401
On Wed, Dec 03, 2014 at 04:18:55PM +0100, Michael Büsch wrote: On Tue, 02 Dec 2014 16:23:49 -0600 Larry Finger larry.fin...@lwfinger.net wrote: On 12/02/2014 02:12 PM, Michael Büsch wrote: On Tue, 2 Dec 2014 23:01:29 +0300 Andrey Skvortsov andrej.skvort...@gmail.com wrote: On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote: On Mon, 1 Dec 2014 23:46:38 +0300 Andrey Skvortsov andrej.skvort...@gmail.com wrote: Wake On Lan was not working on laptop DELL Vostro 1500. If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked. But the laptop could not be woken up with the Magic Packet. The reason for that was that PCIE was not enabled as a system wakeup source and therefore the host PCI bridge was not powered up in suspend mode. PCIE was not enabled in suspend by PM because no child devices were registered as wakeup source during suspend process. On laptop BCM4401 is connected through the SSB bus, that is connected to the PCI-Express bus. SSB and B44 did not use standard PM wakeup functions and did not forward wakeup settings to their parents. To fix that B44 driver enables PM wakeup and registers new wakeup source using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any child devices with enabled wakeup functionality. All other steps are done by PM core code. Thanks, this looks good. I assume you tested this (I currently don't have a device to test this). Sure, I've tested it. WOL from suspend is working and after resume from hibernate Ethernet is working too. That sounds good, indeed. I'd still prefer, if someone with b43 (wireless) would test it, too. I did a partial test with my PowerBook G4. With the patch installed, it would both suspend and hibernate, but WOL would be impossible. This computer uses a PCMCIA version of the BCM4318, and power is turned off to the PCMCIA card when suspended or hibernating. Thanks for testing. John, can you take this one? Or do we need to split the b44 part out? I added my Signed-off. Um, sure...3.19 is OK I presume? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-12-03
= (u8)rtl92ce_get_desc(entry, true, HW_DESC_OWN);
+
+ /*beacon packet will only use the first
+*descriptor defautly,and the own may not
+*be cleared by the hardware
+*/
+ if (own)
+ return false;
+ return true;
+}
+
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
index 9a39ec4204dd..4bec4b07e3e0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/trx.h
@@ -723,6 +723,8 @@ bool rtl92ce_rx_query_desc(struct ieee80211_hw *hw,
void rtl92ce_set_desc(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name, u8 *val);
u32 rtl92ce_get_desc(u8 *pdesc, bool istx, u8 desc_name);
+bool rtl92ce_is_tx_desc_closed(struct ieee80211_hw *hw,
+ u8 hw_queue, u16 index);
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue);
void rtl92ce_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 *pdesc,
bool b_firstseg, bool b_lastseg,
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
pgpaNBWl4jnsc.pgp
Description: PGP signature
Re: pull request: bluetooth-next 2014-11-27
On Thu, Nov 27, 2014 at 12:36:06PM +0200, Johan Hedberg wrote: > Hi John, > > Here's one more bluetooth-next pull request for 3.19: > > - Minor cleanups for ieee802154 & mac802154 > - Fix for the kernel warning with !TASK_RUNNING reported by Kirill A. >Shutemov > - Support for another ath3k device > - Fix for tracking link key based security level > - Device tree bindings for btmrvl + a state update fix > - Fix for wrong ACL flags on LE links > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit a86c02ea38c53b695209b1181f9e2e18d73eb4e8: > > Bluetooth: Add support for Broadcom BCM20702A1 variant (2014-11-18 08:32:14 > +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to f6af675ef5489c69fc3d4faf8c6f477df3cbf8b9: > > Bluetooth: Automatically flushable packets aren't allowed on LE links > (2014-11-27 12:12:27 +0200) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wireless/p54: Remove duplicated net2280 header
Did you check the wireless-next tree's git logs?
commit a831f20b6d6460640b83644d1c1df6e7e8ca9f68
Author: Ricardo Ribalda Delgado
Date: Mon Nov 24 11:19:51 2014 +0100
wireless/p54: Remove duplicated net2280 header
The usb gadget driver net2280 has exported a header file with the
register definition of the net2280 chip.
Remove the custom/duplicated header file in favor of that header file
in include/linux
Signed-off-by: Ricardo Ribalda Delgado
Signed-off-by: John W. Linville
On Mon, Dec 01, 2014 at 11:46:43AM +0100, Ricardo Ribalda Delgado wrote:
> David Miller has marked the patch as "Awaiting Upstream", which I
> think means that it should be merged through the wireless tree.
>
> Any comment from there?
>
> On Mon, Nov 24, 2014 at 11:19 AM, Ricardo Ribalda Delgado
> wrote:
> > The usb gadget driver net2280 has exported a header file with the
> > register definition of the net2280 chip.
> >
> > Remove the custom/duplicated header file in favor of that header file
> > in include/linux
> >
> > Signed-off-by: Ricardo Ribalda Delgado
> > ---
> > drivers/net/wireless/p54/net2280.h | 451
> > -
> > drivers/net/wireless/p54/p54usb.h | 13 +-
> > 2 files changed, 12 insertions(+), 452 deletions(-)
> > delete mode 100644 drivers/net/wireless/p54/net2280.h
> >
> > diff --git a/drivers/net/wireless/p54/net2280.h
> > b/drivers/net/wireless/p54/net2280.h
> > deleted file mode 100644
> > index aedfaf2..000
> > --- a/drivers/net/wireless/p54/net2280.h
> > +++ /dev/null
> > @@ -1,451 +0,0 @@
> > -#ifndef NET2280_H
> > -#define NET2280_H
> > -/*
> > - * NetChip 2280 high/full speed USB device controller.
> > - * Unlike many such controllers, this one talks PCI.
> > - */
> > -
> > -/*
> > - * Copyright (C) 2002 NetChip Technology, Inc. (http://www.netchip.com)
> > - * Copyright (C) 2003 David Brownell
> > - *
> > - * This program is free software; you can redistribute it and/or modify
> > - * it under the terms of the GNU General Public License as published by
> > - * the Free Software Foundation; either version 2 of the License, or
> > - * (at your option) any later version.
> > - *
> > - * This program is distributed in the hope that it will be useful,
> > - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > - * GNU General Public License for more details.
> > - *
> > - * You should have received a copy of the GNU General Public License
> > - * along with this program; if not, see <http://www.gnu.org/licenses/>.
> > - */
> > -
> > -/*-*/
> > -
> > -/* NET2280 MEMORY MAPPED REGISTERS
> > - *
> > - * The register layout came from the chip documentation, and the bit
> > - * number definitions were extracted from chip specification.
> > - *
> > - * Use the shift operator ('<<') to build bit masks, with readl/writel
> > - * to access the registers through PCI.
> > - */
> > -
> > -/* main registers, BAR0 + 0x */
> > -struct net2280_regs {
> > - /* offset 0x */
> > - __le32 devinit;
> > -#define LOCAL_CLOCK_FREQUENCY 8
> > -#define FORCE_PCI_RESET7
> > -#define PCI_ID 6
> > -#define PCI_ENABLE 5
> > -#define FIFO_SOFT_RESET4
> > -#define CFG_SOFT_RESET 3
> > -#define PCI_SOFT_RESET 2
> > -#define USB_SOFT_RESET 1
> > -#define M8051_RESET0
> > - __le32 eectl;
> > -#define EEPROM_ADDRESS_WIDTH 23
> > -#define EEPROM_CHIP_SELECT_ACTIVE 22
> > -#define EEPROM_PRESENT 21
> > -#define EEPROM_VALID 20
> > -#define EEPROM_BUSY19
> > -#define EEPROM_CHIP_SELECT_ENABLE 18
> > -#define EEPROM_BYTE_READ_START 17
> > -#define EEPROM_BYTE_WRITE_START
Re: [PATCH] wireless/p54: Remove duplicated net2280 header
Did you check the wireless-next tree's git logs?
commit a831f20b6d6460640b83644d1c1df6e7e8ca9f68
Author: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
Date: Mon Nov 24 11:19:51 2014 +0100
wireless/p54: Remove duplicated net2280 header
The usb gadget driver net2280 has exported a header file with the
register definition of the net2280 chip.
Remove the custom/duplicated header file in favor of that header file
in include/linux
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
On Mon, Dec 01, 2014 at 11:46:43AM +0100, Ricardo Ribalda Delgado wrote:
David Miller has marked the patch as Awaiting Upstream, which I
think means that it should be merged through the wireless tree.
Any comment from there?
On Mon, Nov 24, 2014 at 11:19 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
The usb gadget driver net2280 has exported a header file with the
register definition of the net2280 chip.
Remove the custom/duplicated header file in favor of that header file
in include/linux
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
drivers/net/wireless/p54/net2280.h | 451
-
drivers/net/wireless/p54/p54usb.h | 13 +-
2 files changed, 12 insertions(+), 452 deletions(-)
delete mode 100644 drivers/net/wireless/p54/net2280.h
diff --git a/drivers/net/wireless/p54/net2280.h
b/drivers/net/wireless/p54/net2280.h
deleted file mode 100644
index aedfaf2..000
--- a/drivers/net/wireless/p54/net2280.h
+++ /dev/null
@@ -1,451 +0,0 @@
-#ifndef NET2280_H
-#define NET2280_H
-/*
- * NetChip 2280 high/full speed USB device controller.
- * Unlike many such controllers, this one talks PCI.
- */
-
-/*
- * Copyright (C) 2002 NetChip Technology, Inc. (http://www.netchip.com)
- * Copyright (C) 2003 David Brownell
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see http://www.gnu.org/licenses/.
- */
-
-/*-*/
-
-/* NET2280 MEMORY MAPPED REGISTERS
- *
- * The register layout came from the chip documentation, and the bit
- * number definitions were extracted from chip specification.
- *
- * Use the shift operator ('') to build bit masks, with readl/writel
- * to access the registers through PCI.
- */
-
-/* main registers, BAR0 + 0x */
-struct net2280_regs {
- /* offset 0x */
- __le32 devinit;
-#define LOCAL_CLOCK_FREQUENCY 8
-#define FORCE_PCI_RESET7
-#define PCI_ID 6
-#define PCI_ENABLE 5
-#define FIFO_SOFT_RESET4
-#define CFG_SOFT_RESET 3
-#define PCI_SOFT_RESET 2
-#define USB_SOFT_RESET 1
-#define M8051_RESET0
- __le32 eectl;
-#define EEPROM_ADDRESS_WIDTH 23
-#define EEPROM_CHIP_SELECT_ACTIVE 22
-#define EEPROM_PRESENT 21
-#define EEPROM_VALID 20
-#define EEPROM_BUSY19
-#define EEPROM_CHIP_SELECT_ENABLE 18
-#define EEPROM_BYTE_READ_START 17
-#define EEPROM_BYTE_WRITE_START16
-#define EEPROM_READ_DATA 8
-#define EEPROM_WRITE_DATA 0
- __le32 eeclkfreq;
- u32 _unused0;
- /* offset 0x0010 */
-
- __le32 pciirqenb0; /* interrupt PCI master ...
*/
-#define SETUP_PACKET_INTERRUPT_ENABLE 7
-#define ENDPOINT_F_INTERRUPT_ENABLE6
-#define ENDPOINT_E_INTERRUPT_ENABLE5
-#define
Re: pull request: bluetooth-next 2014-11-27
On Thu, Nov 27, 2014 at 12:36:06PM +0200, Johan Hedberg wrote: Hi John, Here's one more bluetooth-next pull request for 3.19: - Minor cleanups for ieee802154 mac802154 - Fix for the kernel warning with !TASK_RUNNING reported by Kirill A. Shutemov - Support for another ath3k device - Fix for tracking link key based security level - Device tree bindings for btmrvl + a state update fix - Fix for wrong ACL flags on LE links Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit a86c02ea38c53b695209b1181f9e2e18d73eb4e8: Bluetooth: Add support for Broadcom BCM20702A1 variant (2014-11-18 08:32:14 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to f6af675ef5489c69fc3d4faf8c6f477df3cbf8b9: Bluetooth: Automatically flushable packets aren't allowed on LE links (2014-11-27 12:12:27 +0200) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-11-26
Dave,
Please pull this little batch of fixes intended for the 3.18 stream...
For the iwlwifi one, Emmanuel says:
"Not all the firmware know how to handle the HOT_SPOT_CMD.
Make sure that the firmware will know this command before
sending it. This avoids a firmware crash."
Along with that, Larry sends a pair of rtlwifi fixes to address some
discrepancies from moving drivers out of staging. Larry says:
"These two patches are needed to fix a regression introduced when
driver rtl8821ae was moved from staging to the regular wireless tree."
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit a1d69c60c44134f64945bbf6a6dfda22eaf4a214:
brcmfmac: don't include linux/unaligned/access_ok.h (2014-11-20 14:46:45
-0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-25
for you to fetch changes up to 7d63a5f9b25ba6b130da8eb2d32a72b1462d0249:
rtlwifi: Change order in device startup (2014-11-25 14:22:22 -0500)
--------
John W. Linville (1):
Merge tag 'iwlwifi-for-john-2014-11-23' of
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Larry Finger (2):
rtlwifi: rtl8821ae: Fix 5G detection problem
rtlwifi: Change order in device startup
Luciano Coelho (1):
iwlwifi: mvm: check TLV flag before trying to use hotspot firmware
commands
drivers/net/wireless/iwlwifi/iwl-fw.h | 2 ++
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 +---
drivers/net/wireless/rtlwifi/pci.c | 20 ++--
drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
4 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw.h
b/drivers/net/wireless/iwlwifi/iwl-fw.h
index 4f6e66892acc..b894a84e8393 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw.h
@@ -155,6 +155,7 @@ enum iwl_ucode_tlv_api {
* @IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT: supports Quiet Period requests
* @IWL_UCODE_TLV_CAPA_DQA_SUPPORT: supports dynamic queue allocation (DQA),
* which also implies support for the scheduler configuration command
+ * @IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT: supports Hot Spot Command
*/
enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_D0I3_SUPPORT = BIT(0),
@@ -163,6 +164,7 @@ enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_WFA_TPC_REP_IE_SUPPORT = BIT(10),
IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT = BIT(11),
IWL_UCODE_TLV_CAPA_DQA_SUPPORT = BIT(12),
+ IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT = BIT(18),
};
/* The default calibrate table size if not specified by firmware file */
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index b62405865b25..b6d2683da3a9 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -2448,9 +2448,15 @@ static int iwl_mvm_roc(struct ieee80211_hw *hw,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
- /* Use aux roc framework (HS20) */
- ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
- vif, duration);
+ if (mvm->fw->ucode_capa.capa[0] &
+ IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT) {
+ /* Use aux roc framework (HS20) */
+ ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
+ vif, duration);
+ goto out_unlock;
+ }
+ IWL_ERR(mvm, "hotspot not supported\n");
+ ret = -EINVAL;
goto out_unlock;
case NL80211_IFTYPE_P2P_DEVICE:
/* handle below */
diff --git a/drivers/net/wireless/rtlwifi/pci.c
b/drivers/net/wireless/rtlwifi/pci.c
index 61f5d36eca6a..846a2e6e34d8 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -2249,6 +2249,16 @@ int rtl_pci_probe(struct pci_dev *pdev,
/*like read eeprom and so on */
rtlpriv->cfg->ops->read_eeprom_info(hw);
+ if (rtlpriv->cfg->ops->init_sw_vars(hw)) {
+ RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Can't init_sw_vars\n");
+ err = -ENODEV;
+ goto fail3;
+ }
+ rtlpriv->cfg->ops->init_sw_leds(hw);
+
+ /*aspm */
+ rtl_pci_init_aspm(hw);
+
/* Init mac80211 sw */
err = rtl_init_core(hw);
if (err) {
@@ -2264,16 +2274,6 @@ int rtl_pci_probe(struct pci_dev *pdev,
goto fail3;
}
- if (rtlpriv->cfg->ops->init_sw_vars(hw)) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Can't init_sw_vars\
pull request: wireless 2014-11-26
Dave,
Please pull this little batch of fixes intended for the 3.18 stream...
For the iwlwifi one, Emmanuel says:
Not all the firmware know how to handle the HOT_SPOT_CMD.
Make sure that the firmware will know this command before
sending it. This avoids a firmware crash.
Along with that, Larry sends a pair of rtlwifi fixes to address some
discrepancies from moving drivers out of staging. Larry says:
These two patches are needed to fix a regression introduced when
driver rtl8821ae was moved from staging to the regular wireless tree.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit a1d69c60c44134f64945bbf6a6dfda22eaf4a214:
brcmfmac: don't include linux/unaligned/access_ok.h (2014-11-20 14:46:45
-0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-25
for you to fetch changes up to 7d63a5f9b25ba6b130da8eb2d32a72b1462d0249:
rtlwifi: Change order in device startup (2014-11-25 14:22:22 -0500)
John W. Linville (1):
Merge tag 'iwlwifi-for-john-2014-11-23' of
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Larry Finger (2):
rtlwifi: rtl8821ae: Fix 5G detection problem
rtlwifi: Change order in device startup
Luciano Coelho (1):
iwlwifi: mvm: check TLV flag before trying to use hotspot firmware
commands
drivers/net/wireless/iwlwifi/iwl-fw.h | 2 ++
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 +---
drivers/net/wireless/rtlwifi/pci.c | 20 ++--
drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
4 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw.h
b/drivers/net/wireless/iwlwifi/iwl-fw.h
index 4f6e66892acc..b894a84e8393 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw.h
@@ -155,6 +155,7 @@ enum iwl_ucode_tlv_api {
* @IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT: supports Quiet Period requests
* @IWL_UCODE_TLV_CAPA_DQA_SUPPORT: supports dynamic queue allocation (DQA),
* which also implies support for the scheduler configuration command
+ * @IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT: supports Hot Spot Command
*/
enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_D0I3_SUPPORT = BIT(0),
@@ -163,6 +164,7 @@ enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_WFA_TPC_REP_IE_SUPPORT = BIT(10),
IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT = BIT(11),
IWL_UCODE_TLV_CAPA_DQA_SUPPORT = BIT(12),
+ IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT = BIT(18),
};
/* The default calibrate table size if not specified by firmware file */
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index b62405865b25..b6d2683da3a9 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -2448,9 +2448,15 @@ static int iwl_mvm_roc(struct ieee80211_hw *hw,
switch (vif-type) {
case NL80211_IFTYPE_STATION:
- /* Use aux roc framework (HS20) */
- ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
- vif, duration);
+ if (mvm-fw-ucode_capa.capa[0]
+ IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT) {
+ /* Use aux roc framework (HS20) */
+ ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
+ vif, duration);
+ goto out_unlock;
+ }
+ IWL_ERR(mvm, hotspot not supported\n);
+ ret = -EINVAL;
goto out_unlock;
case NL80211_IFTYPE_P2P_DEVICE:
/* handle below */
diff --git a/drivers/net/wireless/rtlwifi/pci.c
b/drivers/net/wireless/rtlwifi/pci.c
index 61f5d36eca6a..846a2e6e34d8 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -2249,6 +2249,16 @@ int rtl_pci_probe(struct pci_dev *pdev,
/*like read eeprom and so on */
rtlpriv-cfg-ops-read_eeprom_info(hw);
+ if (rtlpriv-cfg-ops-init_sw_vars(hw)) {
+ RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, Can't init_sw_vars\n);
+ err = -ENODEV;
+ goto fail3;
+ }
+ rtlpriv-cfg-ops-init_sw_leds(hw);
+
+ /*aspm */
+ rtl_pci_init_aspm(hw);
+
/* Init mac80211 sw */
err = rtl_init_core(hw);
if (err) {
@@ -2264,16 +2274,6 @@ int rtl_pci_probe(struct pci_dev *pdev,
goto fail3;
}
- if (rtlpriv-cfg-ops-init_sw_vars(hw)) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, Can't init_sw_vars\n);
- err = -ENODEV;
- goto fail3;
- }
- rtlpriv-cfg-ops-init_sw_leds(hw
pull request: wireless 2014-11-20
Dave,
Please full this little batch of fixes intended for the 3.18 stream!
For the mac80211 patch, Johannes says:
"Here's another last minute fix, for minstrel HT crashing
depending on the value of some uninitialised stack."
On top of that...
Ben Greear fixes an ath9k regression in which a BSSID mask is
miscalculated.
Dmitry Torokhov corrects an error handling routing in brcmfmac which
was checking an unsigned variable for a negative value.
Johannes Berg avoids a build problem in brcmfmac for arches where
linux/unaligned/access_ok.h and asm/unaligned.h conflict.
Mathy Vanhoef addresses another brcmfmac issue so as to eliminate a
use-after-free of the URB transfer buffer if a timeout occurs.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9:
ath9k: Fix RTC_DERIVED_CLK usage (2014-11-11 16:24:18 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-20
for you to fetch changes up to a1d69c60c44134f64945bbf6a6dfda22eaf4a214:
brcmfmac: don't include linux/unaligned/access_ok.h (2014-11-20 14:46:45
-0500)
Ben Greear (1):
ath9k: fix regression in bssidmask calculation
Dmitry Torokhov (1):
brcmfmac: fix error handling of irq_of_parse_and_map
Felix Fietkau (1):
mac80211: minstrel_ht: fix a crash in rate sorting
Johannes Berg (1):
brcmfmac: don't include linux/unaligned/access_ok.h
John W. Linville (1):
Merge tag 'mac80211-for-john-2014-11-18' of
git://git.kernel.org/.../jberg/mac80211
Mathy Vanhoef (1):
brcmfmac: kill URB when request timed out
drivers/net/wireless/ath/ath9k/main.c | 9 ++---
drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 ++--
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 6 --
net/mac80211/rc80211_minstrel_ht.c | 15 ++-
5 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 30c66dfcd7a0..4f18a6be0c7d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -974,9 +974,8 @@ void ath9k_calculate_iter_data(struct ath_softc *sc,
struct ath_vif *avp;
/*
-* Pick the MAC address of the first interface as the new hardware
-* MAC address. The hardware will use it together with the BSSID mask
-* when matching addresses.
+* The hardware will use primary station addr together with the
+* BSSID mask when matching addresses.
*/
memset(iter_data, 0, sizeof(*iter_data));
memset(_data->mask, 0xff, ETH_ALEN);
@@ -1205,6 +1204,8 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
list_add_tail(>list, >chanctx->vifs);
}
+ ath9k_calculate_summary_state(sc, avp->chanctx);
+
ath9k_assign_hw_queues(hw, vif);
an->sc = sc;
@@ -1274,6 +1275,8 @@ static void ath9k_remove_interface(struct ieee80211_hw
*hw,
ath_tx_node_cleanup(sc, >mcast_node);
+ ath9k_calculate_summary_state(sc, avp->chanctx);
+
mutex_unlock(>mutex);
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/brcm80211/brcmfmac/of.c
index f05f5270fec1..927bffd5be64 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/of.c
@@ -40,8 +40,8 @@ void brcmf_of_probe(struct brcmf_sdio_dev *sdiodev)
return;
irq = irq_of_parse_and_map(np, 0);
- if (irq < 0) {
- brcmf_err("interrupt could not be mapped: err=%d\n", irq);
+ if (!irq) {
+ brcmf_err("interrupt could not be mapped\n");
devm_kfree(dev, sdiodev->pdata);
return;
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
index 8c0632ec9f7a..16fef3382019 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
@@ -19,10 +19,10 @@
#include
#include
#include
-#include
#include
#include
#include
+#include
#include
#include
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index dc135915470d..875d1142c8b0 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -669,10 +669,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info
*devinfo, u8 cmd,
goto finalize;
}
- if (!brcmf_usb_ioctl_resp_wait(devinfo))
+ if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
+ usb_kill_urb(de
pull request: wireless 2014-11-20
Dave,
Please full this little batch of fixes intended for the 3.18 stream!
For the mac80211 patch, Johannes says:
Here's another last minute fix, for minstrel HT crashing
depending on the value of some uninitialised stack.
On top of that...
Ben Greear fixes an ath9k regression in which a BSSID mask is
miscalculated.
Dmitry Torokhov corrects an error handling routing in brcmfmac which
was checking an unsigned variable for a negative value.
Johannes Berg avoids a build problem in brcmfmac for arches where
linux/unaligned/access_ok.h and asm/unaligned.h conflict.
Mathy Vanhoef addresses another brcmfmac issue so as to eliminate a
use-after-free of the URB transfer buffer if a timeout occurs.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9:
ath9k: Fix RTC_DERIVED_CLK usage (2014-11-11 16:24:18 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-20
for you to fetch changes up to a1d69c60c44134f64945bbf6a6dfda22eaf4a214:
brcmfmac: don't include linux/unaligned/access_ok.h (2014-11-20 14:46:45
-0500)
Ben Greear (1):
ath9k: fix regression in bssidmask calculation
Dmitry Torokhov (1):
brcmfmac: fix error handling of irq_of_parse_and_map
Felix Fietkau (1):
mac80211: minstrel_ht: fix a crash in rate sorting
Johannes Berg (1):
brcmfmac: don't include linux/unaligned/access_ok.h
John W. Linville (1):
Merge tag 'mac80211-for-john-2014-11-18' of
git://git.kernel.org/.../jberg/mac80211
Mathy Vanhoef (1):
brcmfmac: kill URB when request timed out
drivers/net/wireless/ath/ath9k/main.c | 9 ++---
drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 ++--
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 6 --
net/mac80211/rc80211_minstrel_ht.c | 15 ++-
5 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 30c66dfcd7a0..4f18a6be0c7d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -974,9 +974,8 @@ void ath9k_calculate_iter_data(struct ath_softc *sc,
struct ath_vif *avp;
/*
-* Pick the MAC address of the first interface as the new hardware
-* MAC address. The hardware will use it together with the BSSID mask
-* when matching addresses.
+* The hardware will use primary station addr together with the
+* BSSID mask when matching addresses.
*/
memset(iter_data, 0, sizeof(*iter_data));
memset(iter_data-mask, 0xff, ETH_ALEN);
@@ -1205,6 +1204,8 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
list_add_tail(avp-list, avp-chanctx-vifs);
}
+ ath9k_calculate_summary_state(sc, avp-chanctx);
+
ath9k_assign_hw_queues(hw, vif);
an-sc = sc;
@@ -1274,6 +1275,8 @@ static void ath9k_remove_interface(struct ieee80211_hw
*hw,
ath_tx_node_cleanup(sc, avp-mcast_node);
+ ath9k_calculate_summary_state(sc, avp-chanctx);
+
mutex_unlock(sc-mutex);
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/brcm80211/brcmfmac/of.c
index f05f5270fec1..927bffd5be64 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/of.c
@@ -40,8 +40,8 @@ void brcmf_of_probe(struct brcmf_sdio_dev *sdiodev)
return;
irq = irq_of_parse_and_map(np, 0);
- if (irq 0) {
- brcmf_err(interrupt could not be mapped: err=%d\n, irq);
+ if (!irq) {
+ brcmf_err(interrupt could not be mapped\n);
devm_kfree(dev, sdiodev-pdata);
return;
}
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
index 8c0632ec9f7a..16fef3382019 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/pcie.c
@@ -19,10 +19,10 @@
#include linux/pci.h
#include linux/vmalloc.h
#include linux/delay.h
-#include linux/unaligned/access_ok.h
#include linux/interrupt.h
#include linux/bcma/bcma.h
#include linux/sched.h
+#include asm/unaligned.h
#include soc.h
#include chipcommon.h
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index dc135915470d..875d1142c8b0 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -669,10 +669,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info
*devinfo, u8 cmd,
goto finalize;
}
- if (!brcmf_usb_ioctl_resp_wait(devinfo
Re: pull request: bluetooth-next 2014-11-18
On Tue, Nov 18, 2014 at 11:19:52AM +0200, Johan Hedberg wrote: > Hi John, > > Here's another bluetooth-next pull request for 3.19. We've got: > > - Various fixes, cleanups and improvements to ieee802154/mac802154 > - Support for a Broadcom BCM20702A1 variant > - Lots of lockdep fixes > - Fixed handling of LE CoC errors that should trigger SMP > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 56b2c3eea398c772dd895dc62c18cbdd1ba127b1: > > 6lowpan: move skb_free from error paths in decompression (2014-11-06 > 22:09:48 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to a86c02ea38c53b695209b1181f9e2e18d73eb4e8: > > Bluetooth: Add support for Broadcom BCM20702A1 variant (2014-11-18 08:32:14 > +0100) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-11-18
On Tue, Nov 18, 2014 at 11:19:52AM +0200, Johan Hedberg wrote: Hi John, Here's another bluetooth-next pull request for 3.19. We've got: - Various fixes, cleanups and improvements to ieee802154/mac802154 - Support for a Broadcom BCM20702A1 variant - Lots of lockdep fixes - Fixed handling of LE CoC errors that should trigger SMP Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 56b2c3eea398c772dd895dc62c18cbdd1ba127b1: 6lowpan: move skb_free from error paths in decompression (2014-11-06 22:09:48 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to a86c02ea38c53b695209b1181f9e2e18d73eb4e8: Bluetooth: Add support for Broadcom BCM20702A1 variant (2014-11-18 08:32:14 +0100) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] wireless: remove unnecessary sizeof(u8)
On Mon, Nov 17, 2014 at 06:56:27AM +0100, Fabian Frederick wrote: > > > > On 16 November 2014 at 23:33 Julian Calaby wrote: > > > > > > Hi Fabian, > > > > On Sat, Nov 15, 2014 at 7:55 AM, Fabian Frederick wrote: > > > sizeof(u8) is always 1. > > > > I thought that sizeof(*variable) was preferred over sizeof(type), so > > shouldn't these be switched to that format instead? > > > > (I know that this is all no-op, but it should reduce the potential for > > highly unlikely bugs in the future. Also, the extra processing is > > compile-time not run-time.) > > > > Thanks, > > Hi Julian, > > Of course but char/u8/s8... allocations never use it and result would be the > same: > factor 1 multiplication. > > Those rare occurrences (+- 30 in the whole kernel) where we have > sizeof(u8/s8) is ambiguous. > > Having a patch removing it gives a pointer... > If the developer meant something else, he will be able to fix it. > > Regards, > Fabian sizeof(*variable) still seems safer. Are the compilers unable to optimize-away a "multiply by one"? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] wireless: remove unnecessary sizeof(u8)
On Mon, Nov 17, 2014 at 06:56:27AM +0100, Fabian Frederick wrote: On 16 November 2014 at 23:33 Julian Calaby julian.cal...@gmail.com wrote: Hi Fabian, On Sat, Nov 15, 2014 at 7:55 AM, Fabian Frederick f...@skynet.be wrote: sizeof(u8) is always 1. I thought that sizeof(*variable) was preferred over sizeof(type), so shouldn't these be switched to that format instead? (I know that this is all no-op, but it should reduce the potential for highly unlikely bugs in the future. Also, the extra processing is compile-time not run-time.) Thanks, Hi Julian, Of course but char/u8/s8... allocations never use it and result would be the same: factor 1 multiplication. Those rare occurrences (+- 30 in the whole kernel) where we have sizeof(u8/s8) is ambiguous. Having a patch removing it gives a pointer... If the developer meant something else, he will be able to fix it. Regards, Fabian sizeof(*variable) still seems safer. Are the compilers unable to optimize-away a multiply by one? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-11-13
Dave,
Please pull this set of a few more wireless fixes intended for the
3.18 stream...
For the mac80211 bits, Johannes says:
"This has just one fix, for an issue with the CCMP decryption
that can cause a kernel crash. I'm not sure it's remotely
exploitable, but it's an important fix nonetheless."
For the iwlwifi bits, Emmanuel says:
"Two fixes here - we weren't updating mac80211 if a scan
was cut short by RFKILL which confused cfg80211. As a
result, the latter wouldn't allow to run another scan.
Liad fixes a small bug in the firmware dump."
On top of that...
Arend van Spriel corrects a channel width conversion that caused a
WARNING in brcmfmac.
Hauke Mehrtens avoids a NULL pointer dereference in b43.
Larry Finger hits a trio of rtlwifi bugs left over from recent
backporting from the Realtek vendor driver.
Miaoqing Pan fixes a clocking problem in ath9k that could affect
packet timestamps and such.
Stanislaw Gruszka addresses an payload alignment issue that has been
plaguing rt2x00.
Please let me know if there are problems!
John
---
The following changes since commit 0c9a67c8f1d2b71a89f66349362412e9bf6becab:
Merge tag 'mac80211-for-john-2014-11-04' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-11-04
15:56:33 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-11
for you to fetch changes up to 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9:
ath9k: Fix RTC_DERIVED_CLK usage (2014-11-11 16:24:18 -0500)
Arend van Spriel (1):
brcmfmac: fix conversion of channel width 20MHZ_NOHT
Emmanuel Grumbach (1):
iwlwifi: mvm: abort scan upon RFKILL
Hauke Mehrtens (1):
b43: fix NULL pointer dereference in b43_phy_copy()
John W. Linville (2):
Merge tag 'mac80211-for-john-2014-11-10' of
git://git.kernel.org/.../jberg/mac80211
Merge tag 'iwlwifi-for-john-2014-11-10' of
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Larry Finger (3):
rtlwifi: Fix setting of tx descriptor for new trx flow
rtlwifi: Fix errors in descriptor manipulation
rtlwifi: rtl8192se: Fix connection problems
Liad Kaufman (1):
iwlwifi: pcie: fix prph dump length
Miaoqing Pan (1):
ath9k: Fix RTC_DERIVED_CLK usage
Ronald Wahl (1):
mac80211: Fix regression that triggers a kernel BUG with CCMP
Stanislaw Gruszka (1):
rt2x00: do not align payload on modern H/W
drivers/net/wireless/ath/ath9k/ar9003_phy.c| 13 ++
drivers/net/wireless/ath/ath9k/hw.c| 13 --
drivers/net/wireless/b43/phy_common.c | 4 +-
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 6 +++
drivers/net/wireless/iwlwifi/mvm/scan.c| 20 -
drivers/net/wireless/iwlwifi/pcie/trans.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 50 ++
drivers/net/wireless/rtlwifi/pci.c | 19 +---
drivers/net/wireless/rtlwifi/rtl8192se/hw.c| 7 ++-
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 +
drivers/net/wireless/rtlwifi/rtl8192se/sw.c| 16 +++
net/mac80211/aes_ccm.c | 3 ++
12 files changed, 81 insertions(+), 75 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 697c4ae90af0..1e8ea5e4d4ca 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -664,6 +664,19 @@ static void ar9003_hw_override_ini(struct ath_hw *ah)
ah->enabled_cals |= TX_CL_CAL;
else
ah->enabled_cals &= ~TX_CL_CAL;
+
+ if (AR_SREV_9340(ah) || AR_SREV_9531(ah) || AR_SREV_9550(ah)) {
+ if (ah->is_clk_25mhz) {
+ REG_WRITE(ah, AR_RTC_DERIVED_CLK, 0x17c << 1);
+ REG_WRITE(ah, AR_SLP32_MODE, 0x0010f3d7);
+ REG_WRITE(ah, AR_SLP32_INC, 0x0001e7ae);
+ } else {
+ REG_WRITE(ah, AR_RTC_DERIVED_CLK, 0x261 << 1);
+ REG_WRITE(ah, AR_SLP32_MODE, 0x0010f400);
+ REG_WRITE(ah, AR_SLP32_INC, 0x0001e800);
+ }
+ udelay(100);
+ }
}
static void ar9003_hw_prog_ini(struct ath_hw *ah,
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 8be4b1453394..2ad605760e21 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -861,19 +861,6 @@ static void ath9k_hw_init_pll(struct ath_hw *ah,
udelay(RTC_PLL_SETTLE_DELAY);
REG_WRITE(ah, AR_RTC_SLEEP_CLK, AR_RTC_FORCE_DERIVED_CLK);
-
- if (AR_SREV_9340(ah) || AR_SREV_9550(ah)) {
- if (ah->is_clk_25mhz) {
-
pull request: wireless 2014-11-13
Dave,
Please pull this set of a few more wireless fixes intended for the
3.18 stream...
For the mac80211 bits, Johannes says:
This has just one fix, for an issue with the CCMP decryption
that can cause a kernel crash. I'm not sure it's remotely
exploitable, but it's an important fix nonetheless.
For the iwlwifi bits, Emmanuel says:
Two fixes here - we weren't updating mac80211 if a scan
was cut short by RFKILL which confused cfg80211. As a
result, the latter wouldn't allow to run another scan.
Liad fixes a small bug in the firmware dump.
On top of that...
Arend van Spriel corrects a channel width conversion that caused a
WARNING in brcmfmac.
Hauke Mehrtens avoids a NULL pointer dereference in b43.
Larry Finger hits a trio of rtlwifi bugs left over from recent
backporting from the Realtek vendor driver.
Miaoqing Pan fixes a clocking problem in ath9k that could affect
packet timestamps and such.
Stanislaw Gruszka addresses an payload alignment issue that has been
plaguing rt2x00.
Please let me know if there are problems!
John
---
The following changes since commit 0c9a67c8f1d2b71a89f66349362412e9bf6becab:
Merge tag 'mac80211-for-john-2014-11-04' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-11-04
15:56:33 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-11
for you to fetch changes up to 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9:
ath9k: Fix RTC_DERIVED_CLK usage (2014-11-11 16:24:18 -0500)
Arend van Spriel (1):
brcmfmac: fix conversion of channel width 20MHZ_NOHT
Emmanuel Grumbach (1):
iwlwifi: mvm: abort scan upon RFKILL
Hauke Mehrtens (1):
b43: fix NULL pointer dereference in b43_phy_copy()
John W. Linville (2):
Merge tag 'mac80211-for-john-2014-11-10' of
git://git.kernel.org/.../jberg/mac80211
Merge tag 'iwlwifi-for-john-2014-11-10' of
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Larry Finger (3):
rtlwifi: Fix setting of tx descriptor for new trx flow
rtlwifi: Fix errors in descriptor manipulation
rtlwifi: rtl8192se: Fix connection problems
Liad Kaufman (1):
iwlwifi: pcie: fix prph dump length
Miaoqing Pan (1):
ath9k: Fix RTC_DERIVED_CLK usage
Ronald Wahl (1):
mac80211: Fix regression that triggers a kernel BUG with CCMP
Stanislaw Gruszka (1):
rt2x00: do not align payload on modern H/W
drivers/net/wireless/ath/ath9k/ar9003_phy.c| 13 ++
drivers/net/wireless/ath/ath9k/hw.c| 13 --
drivers/net/wireless/b43/phy_common.c | 4 +-
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 6 +++
drivers/net/wireless/iwlwifi/mvm/scan.c| 20 -
drivers/net/wireless/iwlwifi/pcie/trans.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 50 ++
drivers/net/wireless/rtlwifi/pci.c | 19 +---
drivers/net/wireless/rtlwifi/rtl8192se/hw.c| 7 ++-
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 +
drivers/net/wireless/rtlwifi/rtl8192se/sw.c| 16 +++
net/mac80211/aes_ccm.c | 3 ++
12 files changed, 81 insertions(+), 75 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 697c4ae90af0..1e8ea5e4d4ca 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -664,6 +664,19 @@ static void ar9003_hw_override_ini(struct ath_hw *ah)
ah-enabled_cals |= TX_CL_CAL;
else
ah-enabled_cals = ~TX_CL_CAL;
+
+ if (AR_SREV_9340(ah) || AR_SREV_9531(ah) || AR_SREV_9550(ah)) {
+ if (ah-is_clk_25mhz) {
+ REG_WRITE(ah, AR_RTC_DERIVED_CLK, 0x17c 1);
+ REG_WRITE(ah, AR_SLP32_MODE, 0x0010f3d7);
+ REG_WRITE(ah, AR_SLP32_INC, 0x0001e7ae);
+ } else {
+ REG_WRITE(ah, AR_RTC_DERIVED_CLK, 0x261 1);
+ REG_WRITE(ah, AR_SLP32_MODE, 0x0010f400);
+ REG_WRITE(ah, AR_SLP32_INC, 0x0001e800);
+ }
+ udelay(100);
+ }
}
static void ar9003_hw_prog_ini(struct ath_hw *ah,
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 8be4b1453394..2ad605760e21 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -861,19 +861,6 @@ static void ath9k_hw_init_pll(struct ath_hw *ah,
udelay(RTC_PLL_SETTLE_DELAY);
REG_WRITE(ah, AR_RTC_SLEEP_CLK, AR_RTC_FORCE_DERIVED_CLK);
-
- if (AR_SREV_9340(ah) || AR_SREV_9550(ah)) {
- if (ah-is_clk_25mhz) {
- REG_WRITE(ah, AR_RTC_DERIVED_CLK, 0x17c 1);
- REG_WRITE(ah
Re: pull request: bluetooth-next 2014-11-07
On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote: > Hi John > > Here's another set of patches for 3.19. Most of it is again fixes and > cleanups to ieee802154 related code from Alexander Aring. We've also got > better handling of hardware error events along with a proper API for HCI > drivers to notify the HCI core of such situations. There's also a minor > fix for mgmt events as well as a sparse warning fix. The code for > sending HCI commands synchronously also gets a fix where we might loose > the completion event in the case of very fast HW (particularly easily > reproducible with an emulated HCI device). > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 6bc6c49f1e2f3ab1bec05d1c08aad219ab4eb5d0: > > mwifiex: add cfg80211 dump_survey handler (2014-10-31 16:07:49 -0400) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to 56b2c3eea398c772dd895dc62c18cbdd1ba127b1: > > 6lowpan: move skb_free from error paths in decompression (2014-11-06 > 22:09:48 +0100) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-11-07
On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote: Hi John Here's another set of patches for 3.19. Most of it is again fixes and cleanups to ieee802154 related code from Alexander Aring. We've also got better handling of hardware error events along with a proper API for HCI drivers to notify the HCI core of such situations. There's also a minor fix for mgmt events as well as a sparse warning fix. The code for sending HCI commands synchronously also gets a fix where we might loose the completion event in the case of very fast HW (particularly easily reproducible with an emulated HCI device). Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 6bc6c49f1e2f3ab1bec05d1c08aad219ab4eb5d0: mwifiex: add cfg80211 dump_survey handler (2014-10-31 16:07:49 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 56b2c3eea398c772dd895dc62c18cbdd1ba127b1: 6lowpan: move skb_free from error paths in decompression (2014-11-06 22:09:48 +0100) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-11-06
Dave,
Please pull this batch of fixes intended for the 3.18 stream...
For the mac80211 bits, Johannes says:
"This contains another small set of fixes for 3.18, these are all
over the place and most of the bugs are old, one even dates back
to the original mac80211 we merged into the kernel."
For the iwlwifi bits, Emmanuel says:
"I fix here two issues that are related to the firmware
loading flow. A user reported that he couldn't load the
driver because the rfkill line was pulled up while we
were running the calibrations. This was happening while
booting the system: systemd was restoring the "disable
wifi settings" and that raised an RFKILL interrupt during
the calibration. Our driver didn't handle that properly
and this is now fixed."
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 75a916e1944fea8347d2245c62567187e4eff9dd:
rtlwifi: rtl8192se: Fix firmware loading (2014-10-30 15:00:23 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-04
for you to fetch changes up to 0c9a67c8f1d2b71a89f66349362412e9bf6becab:
Merge tag 'mac80211-for-john-2014-11-04' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-11-04
15:56:33 -0500)
Emmanuel Grumbach (2):
iwlwifi: mvm: initialize the cur_ucode upon boot
iwlwifi: fix RFkill while calibrating
Felix Fietkau (1):
mac80211: flush keys for AP mode on ieee80211_do_stop
Johannes Berg (2):
mac80211: properly flush delayed scan work on interface removal
mac80211: fix use-after-free in defragmentation
John W. Linville (2):
Merge tag 'iwlwifi-for-john-2014-11-03' of
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'mac80211-for-john-2014-11-04' of
git://git.kernel.org/.../jberg/mac80211
Junjie Mao (1):
mac80211_hwsim: release driver when ieee80211_register_hw fails
Luciano Coelho (2):
mac80211: use secondary channel offset IE also beacons during CSA
mac80211: schedule the actual switch of the station before CSA count 0
drivers/net/wireless/iwlwifi/mvm/fw.c | 10 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 1 +
drivers/net/wireless/iwlwifi/mvm/mvm.h | 1 +
drivers/net/wireless/iwlwifi/mvm/ops.c | 12 +++-
drivers/net/wireless/iwlwifi/pcie/trans.c | 4 ++--
drivers/net/wireless/mac80211_hwsim.c | 4 +++-
net/mac80211/ibss.c | 2 +-
net/mac80211/ieee80211_i.h | 3 +--
net/mac80211/iface.c| 18 --
net/mac80211/mesh.c | 2 +-
net/mac80211/mlme.c | 5 +++--
net/mac80211/rx.c | 14 +++---
net/mac80211/spectmgmt.c| 18 ++
13 files changed, 58 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw.c
b/drivers/net/wireless/iwlwifi/mvm/fw.c
index e0d9f19650b0..eb03943f8463 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/iwlwifi/mvm/fw.c
@@ -284,7 +284,7 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
lockdep_assert_held(>mutex);
- if (WARN_ON_ONCE(mvm->init_ucode_complete))
+ if (WARN_ON_ONCE(mvm->init_ucode_complete || mvm->calibrating))
return 0;
iwl_init_notification_wait(>notif_wait,
@@ -334,6 +334,8 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
goto out;
}
+ mvm->calibrating = true;
+
/* Send TX valid antennas before triggering calibrations */
ret = iwl_send_tx_ant_cfg(mvm, mvm->fw->valid_tx_ant);
if (ret)
@@ -358,11 +360,17 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
MVM_UCODE_CALIB_TIMEOUT);
if (!ret)
mvm->init_ucode_complete = true;
+
+ if (ret && iwl_mvm_is_radio_killed(mvm)) {
+ IWL_DEBUG_RF_KILL(mvm, "RFKILL while calibrating.\n");
+ ret = 1;
+ }
goto out;
error:
iwl_remove_notification(>notif_wait, _wait);
out:
+ mvm->calibrating = false;
if (iwlmvm_mod_params.init_dbg && !mvm->nvm_data) {
/* we want to debug INIT and we have no NVM - fake */
mvm->nvm_data = kzalloc(sizeof(struct iwl_nvm_data) +
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 585fe5b7100f..b62405865b25 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -788,6 +788,7 @@ static void iwl_mvm_restart_cleanup(struct iwl_mvm *mvm)
mvm->scan_status = IWL_MVM_SCAN_N
pull request: wireless 2014-11-06
Dave,
Please pull this batch of fixes intended for the 3.18 stream...
For the mac80211 bits, Johannes says:
This contains another small set of fixes for 3.18, these are all
over the place and most of the bugs are old, one even dates back
to the original mac80211 we merged into the kernel.
For the iwlwifi bits, Emmanuel says:
I fix here two issues that are related to the firmware
loading flow. A user reported that he couldn't load the
driver because the rfkill line was pulled up while we
were running the calibrations. This was happening while
booting the system: systemd was restoring the disable
wifi settings and that raised an RFKILL interrupt during
the calibration. Our driver didn't handle that properly
and this is now fixed.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 75a916e1944fea8347d2245c62567187e4eff9dd:
rtlwifi: rtl8192se: Fix firmware loading (2014-10-30 15:00:23 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-11-04
for you to fetch changes up to 0c9a67c8f1d2b71a89f66349362412e9bf6becab:
Merge tag 'mac80211-for-john-2014-11-04' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-11-04
15:56:33 -0500)
Emmanuel Grumbach (2):
iwlwifi: mvm: initialize the cur_ucode upon boot
iwlwifi: fix RFkill while calibrating
Felix Fietkau (1):
mac80211: flush keys for AP mode on ieee80211_do_stop
Johannes Berg (2):
mac80211: properly flush delayed scan work on interface removal
mac80211: fix use-after-free in defragmentation
John W. Linville (2):
Merge tag 'iwlwifi-for-john-2014-11-03' of
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'mac80211-for-john-2014-11-04' of
git://git.kernel.org/.../jberg/mac80211
Junjie Mao (1):
mac80211_hwsim: release driver when ieee80211_register_hw fails
Luciano Coelho (2):
mac80211: use secondary channel offset IE also beacons during CSA
mac80211: schedule the actual switch of the station before CSA count 0
drivers/net/wireless/iwlwifi/mvm/fw.c | 10 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 1 +
drivers/net/wireless/iwlwifi/mvm/mvm.h | 1 +
drivers/net/wireless/iwlwifi/mvm/ops.c | 12 +++-
drivers/net/wireless/iwlwifi/pcie/trans.c | 4 ++--
drivers/net/wireless/mac80211_hwsim.c | 4 +++-
net/mac80211/ibss.c | 2 +-
net/mac80211/ieee80211_i.h | 3 +--
net/mac80211/iface.c| 18 --
net/mac80211/mesh.c | 2 +-
net/mac80211/mlme.c | 5 +++--
net/mac80211/rx.c | 14 +++---
net/mac80211/spectmgmt.c| 18 ++
13 files changed, 58 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw.c
b/drivers/net/wireless/iwlwifi/mvm/fw.c
index e0d9f19650b0..eb03943f8463 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/iwlwifi/mvm/fw.c
@@ -284,7 +284,7 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
lockdep_assert_held(mvm-mutex);
- if (WARN_ON_ONCE(mvm-init_ucode_complete))
+ if (WARN_ON_ONCE(mvm-init_ucode_complete || mvm-calibrating))
return 0;
iwl_init_notification_wait(mvm-notif_wait,
@@ -334,6 +334,8 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
goto out;
}
+ mvm-calibrating = true;
+
/* Send TX valid antennas before triggering calibrations */
ret = iwl_send_tx_ant_cfg(mvm, mvm-fw-valid_tx_ant);
if (ret)
@@ -358,11 +360,17 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool
read_nvm)
MVM_UCODE_CALIB_TIMEOUT);
if (!ret)
mvm-init_ucode_complete = true;
+
+ if (ret iwl_mvm_is_radio_killed(mvm)) {
+ IWL_DEBUG_RF_KILL(mvm, RFKILL while calibrating.\n);
+ ret = 1;
+ }
goto out;
error:
iwl_remove_notification(mvm-notif_wait, calib_wait);
out:
+ mvm-calibrating = false;
if (iwlmvm_mod_params.init_dbg !mvm-nvm_data) {
/* we want to debug INIT and we have no NVM - fake */
mvm-nvm_data = kzalloc(sizeof(struct iwl_nvm_data) +
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 585fe5b7100f..b62405865b25 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -788,6 +788,7 @@ static void iwl_mvm_restart_cleanup(struct iwl_mvm *mvm)
mvm-scan_status = IWL_MVM_SCAN_NONE;
mvm-ps_disabled = false;
+ mvm-calibrating = false;
/* just in case one
Re: pull request: bluetooth-next 2014-10-31
On Fri, Oct 31, 2014 at 08:28:03PM +0200, Johan Hedberg wrote: > Hi John, > > Here's the first bluetooth-next pull request for 3.19. The vast majority > of patches are for ieee802154 from Alexander Aring with various fixes > and cleanups. There are also several LE/SMP fixes as well as improved > support for handling LE devices that have lost their pairing information > (the patches from Alfonso). Jukka provides a couple of stability fixes > for 6lowpan and Szymon conformance fixes for RFCOMM. For the HCI drivers > we have one new USB ID for an Acer controller as well as a reset > handling fix for H5. > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 61ed53deb1c6a4386d8710dbbfcee8779c381931: > > Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb (2014-10-19 12:58:22 > -0700) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to b509c02d0f31639dda90f9b7269668b86c9b25ef: > > Bluetooth: HCI H5 peer reset detection (2014-10-31 19:54:34 +0200) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-10-31
@ -112,20 +109,6 @@ static void rtl92se_fw_cb(const struct firmware *firmware,
void *context)
memcpy(pfirmware->sz_fw_tmpbuffer, firmware->data, firmware->size);
pfirmware->sz_fw_tmpbufferlen = firmware->size;
release_firmware(firmware);
-
- err = ieee80211_register_hw(hw);
- if (err) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
-"Can't register mac80211 hw\n");
- return;
- } else {
- rtlpriv->mac80211.mac80211_registered = 1;
- }
- rtlpci->irq_alloc = 1;
- set_bit(RTL_STATUS_INTERFACE_START, >status);
-
- /*init rfkill */
- rtl_init_rfkill(hw);
}
static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
@@ -226,8 +209,8 @@ static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
if (!rtlpriv->rtlhal.pfirmware)
return 1;
- rtlpriv->max_fw_size = RTL8190_MAX_RAW_FIRMWARE_CODE_SIZE;
-
+ rtlpriv->max_fw_size = RTL8190_MAX_FIRMWARE_CODE_SIZE*2 +
+ sizeof(struct fw_hdr);
pr_info("Driver for Realtek RTL8192SE/RTL8191SE\n"
"Loading firmware %s\n", rtlpriv->cfg->fw_name);
/* request fw */
@@ -294,6 +277,7 @@ static struct rtl_hal_ops rtl8192se_hal_ops = {
.set_bbreg = rtl92s_phy_set_bb_reg,
.get_rfreg = rtl92s_phy_query_rf_reg,
.set_rfreg = rtl92s_phy_set_rf_reg,
+ .get_btc_status = rtl_btc_status_false,
};
static struct rtl_mod_params rtl92se_mod_params = {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
index b358ebce8942..672fd3b02835 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -640,6 +640,9 @@ u32 rtl92se_get_desc(u8 *desc, bool istx, u8 desc_name)
case HW_DESC_RXPKT_LEN:
ret = GET_RX_STATUS_DESC_PKT_LEN(desc);
break;
+ case HW_DESC_RXBUFF_ADDR:
+ ret = GET_RX_STATUS_DESC_BUFF_ADDR(desc);
+ break;
default:
RT_ASSERT(false, "ERR rxdesc :%d not process\n",
desc_name);
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
pgpQdeyJCQoe_.pgp
Description: PGP signature
pull request: wireless 2014-10-31
(rtlpriv, COMP_ERR, DBG_EMERG,
-Can't register mac80211 hw\n);
- return;
- } else {
- rtlpriv-mac80211.mac80211_registered = 1;
- }
- rtlpci-irq_alloc = 1;
- set_bit(RTL_STATUS_INTERFACE_START, rtlpriv-status);
-
- /*init rfkill */
- rtl_init_rfkill(hw);
}
static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
@@ -226,8 +209,8 @@ static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
if (!rtlpriv-rtlhal.pfirmware)
return 1;
- rtlpriv-max_fw_size = RTL8190_MAX_RAW_FIRMWARE_CODE_SIZE;
-
+ rtlpriv-max_fw_size = RTL8190_MAX_FIRMWARE_CODE_SIZE*2 +
+ sizeof(struct fw_hdr);
pr_info(Driver for Realtek RTL8192SE/RTL8191SE\n
Loading firmware %s\n, rtlpriv-cfg-fw_name);
/* request fw */
@@ -294,6 +277,7 @@ static struct rtl_hal_ops rtl8192se_hal_ops = {
.set_bbreg = rtl92s_phy_set_bb_reg,
.get_rfreg = rtl92s_phy_query_rf_reg,
.set_rfreg = rtl92s_phy_set_rf_reg,
+ .get_btc_status = rtl_btc_status_false,
};
static struct rtl_mod_params rtl92se_mod_params = {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
index b358ebce8942..672fd3b02835 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -640,6 +640,9 @@ u32 rtl92se_get_desc(u8 *desc, bool istx, u8 desc_name)
case HW_DESC_RXPKT_LEN:
ret = GET_RX_STATUS_DESC_PKT_LEN(desc);
break;
+ case HW_DESC_RXBUFF_ADDR:
+ ret = GET_RX_STATUS_DESC_BUFF_ADDR(desc);
+ break;
default:
RT_ASSERT(false, ERR rxdesc :%d not process\n,
desc_name);
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
pgpQdeyJCQoe_.pgp
Description: PGP signature
Re: pull request: bluetooth-next 2014-10-31
On Fri, Oct 31, 2014 at 08:28:03PM +0200, Johan Hedberg wrote: Hi John, Here's the first bluetooth-next pull request for 3.19. The vast majority of patches are for ieee802154 from Alexander Aring with various fixes and cleanups. There are also several LE/SMP fixes as well as improved support for handling LE devices that have lost their pairing information (the patches from Alfonso). Jukka provides a couple of stability fixes for 6lowpan and Szymon conformance fixes for RFCOMM. For the HCI drivers we have one new USB ID for an Acer controller as well as a reset handling fix for H5. Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 61ed53deb1c6a4386d8710dbbfcee8779c381931: Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb (2014-10-19 12:58:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to b509c02d0f31639dda90f9b7269668b86c9b25ef: Bluetooth: HCI H5 peer reset detection (2014-10-31 19:54:34 +0200) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-10-28
Dave, Please pull this batch of fixes intended for the 3.18 stream! For the mac80211 bits, Johannes says: "Here are a few fixes for the wireless stack: one fixes the RTS rate, one for a debugfs file, one to return the correct channel to userspace, a sanity check for a userspace value and the remaining two are just documentation fixes." For the iwlwifi bits, Emmanuel says: "I revert here a patch that caused interoperability issues. dvm gets a fix for a bug that was reported by many users. Two minor fixes for BT Coex and platform power fix that helps reducing latency when the PCIe link goes to low power states." In addition... Felix Fietkau adds a couple of ath code fixes related to regulatory rule enforcement. Hauke Mehrtens fixes a build break with bcma when CONFIG_OF_ADDRESS is not set. Karsten Wiese provides a trio of minor fixes for rtl8192cu. Kees Cook prevents a potential information leak in rtlwifi. Larry Finger also brings a trio of minor fixes for rtlwifi. Rafał Miłecki adds a device ID to the bcma bus driver. Rickard Strandqvist offers some strn* -> strl* changes in brcmfmac to eliminate non-terminated string issues. Sujith Manoharan avoids some ath9k stalls by enabling HW queue control only for MCC. Please let me know if there are problems... John --- The following changes since commit 61ed53deb1c6a4386d8710dbbfcee8779c381931: Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb (2014-10-19 12:58:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git tags/master-2014-10-27 for you to fetch changes up to 99c814066e75d09e6a38574c6c395f022a04b730: Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-10-27 13:38:15 -0400) Emmanuel Grumbach (6): iwlwifi: configure the LTR iwlwifi: mvm: BT Coex - update the MPLUT Boost register value iwlwifi: mvm: BT coex - fix BT prio for probe requests iwlwifi: dvm: drop non VO frames when flushing Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate" iwlwifi: pcie: fix polling in various places Fabian Frederick (1): net: rfkill: kernel-doc warning fixes Felix Fietkau (2): ath: use CTL region from cfg80211 if unset in EEPROM ath9k_common: always update value in ath9k_cmn_update_txpow Haim Dreyfuss (1): iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss Hauke Mehrtens (1): bcma: fix build when CONFIG_OF_ADDRESS is not set John W. Linville (2): Merge tag 'iwlwifi-for-john-2014-10-23' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/.../jberg/mac80211 Karl Beldan (2): mac80211: fix typo in starting baserate for rts_cts_rate_idx mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats Karsten Wiese (3): rtl8192cu: Fix for rtlwifi's bluetooth coexist functionality rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe rtl8192cu: Prevent Ooops under rtl92c_set_fw_rsvdpagepkt Kees Cook (1): rtlwifi: prevent format string usage from leaking Larry Finger (3): rtlwifi: rtl8192ee: Prevent log spamming for switch statements rtlwifi: rtl8821ae: Fix possible array overrun rtlwifi: Add check for get_btc_status callback Liad Kaufman (2): mac80211: fix warning on htmldocs for last_tdls_pkt_time iwlwifi: 8000: fix string given to MODULE_FIRMWARE Luciano Coelho (2): mac80211: return the vif's chandef in ieee80211_cfg_get_channel() nl80211: sanity check the channel switch counter value Matti Gottlieb (1): iwlwifi: mvm: ROC - bug fixes around time events and locking Rafał Miłecki (1): bcma: add another PCI ID of device with BCM43228 Rickard Strandqvist (1): brcmfmac: dhd_sdio.c: Cleaning up missing null-terminate in conjunction with strncpy Sujith Manoharan (1): ath9k: Enable HW queue control only for MCC drivers/bcma/host_pci.c| 5 +- drivers/bcma/main.c| 2 +- drivers/net/wireless/ath/ath.h | 1 + drivers/net/wireless/ath/ath9k/common.c| 8 ++-- drivers/net/wireless/ath/ath9k/init.c | 55 -- drivers/net/wireless/ath/ath9k/main.c | 3 ++ drivers/net/wireless/ath/ath9k/xmit.c | 10 +++- drivers/net/wireless/ath/regd.c| 14 ++ drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 25 +- drivers/net/wireless/iwlwifi/dvm/mac80211.c| 24 +- drivers/net/wireless/iwlwifi/iwl-8000.c| 3 +- drivers/net/wireless/iwlwifi/iwl-trans.h | 2 + drivers/net/wireless/iwlwifi/mvm/coex.c| 4 +- drivers/net/wireless/i
pull request: wireless 2014-10-28
Dave, Please pull this batch of fixes intended for the 3.18 stream! For the mac80211 bits, Johannes says: Here are a few fixes for the wireless stack: one fixes the RTS rate, one for a debugfs file, one to return the correct channel to userspace, a sanity check for a userspace value and the remaining two are just documentation fixes. For the iwlwifi bits, Emmanuel says: I revert here a patch that caused interoperability issues. dvm gets a fix for a bug that was reported by many users. Two minor fixes for BT Coex and platform power fix that helps reducing latency when the PCIe link goes to low power states. In addition... Felix Fietkau adds a couple of ath code fixes related to regulatory rule enforcement. Hauke Mehrtens fixes a build break with bcma when CONFIG_OF_ADDRESS is not set. Karsten Wiese provides a trio of minor fixes for rtl8192cu. Kees Cook prevents a potential information leak in rtlwifi. Larry Finger also brings a trio of minor fixes for rtlwifi. Rafał Miłecki adds a device ID to the bcma bus driver. Rickard Strandqvist offers some strn* - strl* changes in brcmfmac to eliminate non-terminated string issues. Sujith Manoharan avoids some ath9k stalls by enabling HW queue control only for MCC. Please let me know if there are problems... John --- The following changes since commit 61ed53deb1c6a4386d8710dbbfcee8779c381931: Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb (2014-10-19 12:58:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git tags/master-2014-10-27 for you to fetch changes up to 99c814066e75d09e6a38574c6c395f022a04b730: Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-10-27 13:38:15 -0400) Emmanuel Grumbach (6): iwlwifi: configure the LTR iwlwifi: mvm: BT Coex - update the MPLUT Boost register value iwlwifi: mvm: BT coex - fix BT prio for probe requests iwlwifi: dvm: drop non VO frames when flushing Revert iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate iwlwifi: pcie: fix polling in various places Fabian Frederick (1): net: rfkill: kernel-doc warning fixes Felix Fietkau (2): ath: use CTL region from cfg80211 if unset in EEPROM ath9k_common: always update value in ath9k_cmn_update_txpow Haim Dreyfuss (1): iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss Hauke Mehrtens (1): bcma: fix build when CONFIG_OF_ADDRESS is not set John W. Linville (2): Merge tag 'iwlwifi-for-john-2014-10-23' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/.../jberg/mac80211 Karl Beldan (2): mac80211: fix typo in starting baserate for rts_cts_rate_idx mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats Karsten Wiese (3): rtl8192cu: Fix for rtlwifi's bluetooth coexist functionality rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe rtl8192cu: Prevent Ooops under rtl92c_set_fw_rsvdpagepkt Kees Cook (1): rtlwifi: prevent format string usage from leaking Larry Finger (3): rtlwifi: rtl8192ee: Prevent log spamming for switch statements rtlwifi: rtl8821ae: Fix possible array overrun rtlwifi: Add check for get_btc_status callback Liad Kaufman (2): mac80211: fix warning on htmldocs for last_tdls_pkt_time iwlwifi: 8000: fix string given to MODULE_FIRMWARE Luciano Coelho (2): mac80211: return the vif's chandef in ieee80211_cfg_get_channel() nl80211: sanity check the channel switch counter value Matti Gottlieb (1): iwlwifi: mvm: ROC - bug fixes around time events and locking Rafał Miłecki (1): bcma: add another PCI ID of device with BCM43228 Rickard Strandqvist (1): brcmfmac: dhd_sdio.c: Cleaning up missing null-terminate in conjunction with strncpy Sujith Manoharan (1): ath9k: Enable HW queue control only for MCC drivers/bcma/host_pci.c| 5 +- drivers/bcma/main.c| 2 +- drivers/net/wireless/ath/ath.h | 1 + drivers/net/wireless/ath/ath9k/common.c| 8 ++-- drivers/net/wireless/ath/ath9k/init.c | 55 -- drivers/net/wireless/ath/ath9k/main.c | 3 ++ drivers/net/wireless/ath/ath9k/xmit.c | 10 +++- drivers/net/wireless/ath/regd.c| 14 ++ drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 25 +- drivers/net/wireless/iwlwifi/dvm/mac80211.c| 24 +- drivers/net/wireless/iwlwifi/iwl-8000.c| 3 +- drivers/net/wireless/iwlwifi/iwl-trans.h | 2 + drivers/net/wireless/iwlwifi/mvm/coex.c| 4 +- drivers/net/wireless/iwlwifi/mvm/coex_legacy.c | 4 +- drivers/net
Re: [PATCH] bcma: fix build when CONFIG_OF_ADDRESS is not set
Yes, I have it queued. Things have been delayed due to my recent
travels, etc.
On Sat, Oct 25, 2014 at 01:36:53PM -0700, Guenter Roeck wrote:
> On Thu, Oct 09, 2014 at 11:39:41PM +0200, Hauke Mehrtens wrote:
> > Commit 2101e533f41a ("bcma: register bcma as device tree driver")
> > introduces a hard dependency on OF_ADDRESS into the bcma driver.
> > OF_ADDRESS is specifically disabled for the sparc architecture.
> > This results in the following error when building sparc64:allmodconfig.
> >
> > drivers/bcma/main.c: In function 'bcma_of_find_child_device':
> > drivers/bcma/main.c:150:3: error: implicit declaration of function
> > 'of_translate_address'
> >
> > Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
> > Reported-by: Guenter Roeck
> > Signed-off-by: Hauke Mehrtens
>
> The upstream kernel still does not include this patch, and the sparc64 build
> is still broken.
>
> Is this patch on its way upstream ?
>
> Guenter
>
> > ---
> > drivers/bcma/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> > index d1656c2..1000955 100644
> > --- a/drivers/bcma/main.c
> > +++ b/drivers/bcma/main.c
> > @@ -132,7 +132,7 @@ static bool bcma_is_core_needed_early(u16 core_id)
> > return false;
> > }
> >
> > -#ifdef CONFIG_OF
> > +#if defined(CONFIG_OF) && defined(CONFIG_OF_ADDRESS)
> > static struct device_node *bcma_of_find_child_device(struct
> > platform_device *parent,
> > struct bcma_device *core)
> > {
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: rfkill: gpio: Add default GPIO driver mappings for ACPI
On Mon, Oct 27, 2014 at 12:23:55PM +0100, Johannes Berg wrote: > On Mon, 2014-10-27 at 12:15 +0200, Mika Westerberg wrote: > > The driver uses devm_gpiod_get_index(..., index) so that the index refers > > directly to the GpioIo resource under the ACPI device. The problem with > > this is that if the ordering changes we get wrong GPIOs. > > > > With ACPI 5.1 _DSD we can now use names instead to reference GPIOs > > analogous to Device Tree. However, we still have systems out there that do > > not provide _DSD at all. These systems must be supported as well. > > > > Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide > > mappings for systems where _DSD is not provided and still take advantage of > > _DSD if it exists. > > > > This patch changes the driver to create default GPIO mappings if we are > > running on ACPI system. > > > > While there we can drop the indices completely and use devm_gpiod_get() > > with name instead. > > > > Signed-off-by: Mika Westerberg > > --- > > Hi, > > > > This patch is based on top of linux-pm/device-properties [1] and following > > patch from Rafael [2]. > > > > Johannes, John, > > > > If you are happy with the patch, can you ACK it so that we can merge it > > with the rest of the device-properties patches. Thanks. > > Acked-by: Johannes Berg > Reviewed-by: Johannes Berg Acked-by: John W. Linville -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: rfkill: gpio: Add default GPIO driver mappings for ACPI
On Mon, Oct 27, 2014 at 12:23:55PM +0100, Johannes Berg wrote: On Mon, 2014-10-27 at 12:15 +0200, Mika Westerberg wrote: The driver uses devm_gpiod_get_index(..., index) so that the index refers directly to the GpioIo resource under the ACPI device. The problem with this is that if the ordering changes we get wrong GPIOs. With ACPI 5.1 _DSD we can now use names instead to reference GPIOs analogous to Device Tree. However, we still have systems out there that do not provide _DSD at all. These systems must be supported as well. Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide mappings for systems where _DSD is not provided and still take advantage of _DSD if it exists. This patch changes the driver to create default GPIO mappings if we are running on ACPI system. While there we can drop the indices completely and use devm_gpiod_get() with name instead. Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com --- Hi, This patch is based on top of linux-pm/device-properties [1] and following patch from Rafael [2]. Johannes, John, If you are happy with the patch, can you ACK it so that we can merge it with the rest of the device-properties patches. Thanks. Acked-by: Johannes Berg johan...@sipsolutions.net Reviewed-by: Johannes Berg johan...@sipsolutions.net Acked-by: John W. Linville linvi...@tuxdriver.com -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bcma: fix build when CONFIG_OF_ADDRESS is not set
Yes, I have it queued. Things have been delayed due to my recent
travels, etc.
On Sat, Oct 25, 2014 at 01:36:53PM -0700, Guenter Roeck wrote:
On Thu, Oct 09, 2014 at 11:39:41PM +0200, Hauke Mehrtens wrote:
Commit 2101e533f41a (bcma: register bcma as device tree driver)
introduces a hard dependency on OF_ADDRESS into the bcma driver.
OF_ADDRESS is specifically disabled for the sparc architecture.
This results in the following error when building sparc64:allmodconfig.
drivers/bcma/main.c: In function 'bcma_of_find_child_device':
drivers/bcma/main.c:150:3: error: implicit declaration of function
'of_translate_address'
Fixes: 2101e533f41a (bcma: register bcma as device tree driver)
Reported-by: Guenter Roeck li...@roeck-us.net
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
The upstream kernel still does not include this patch, and the sparc64 build
is still broken.
Is this patch on its way upstream ?
Guenter
---
drivers/bcma/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index d1656c2..1000955 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -132,7 +132,7 @@ static bool bcma_is_core_needed_early(u16 core_id)
return false;
}
-#ifdef CONFIG_OF
+#if defined(CONFIG_OF) defined(CONFIG_OF_ADDRESS)
static struct device_node *bcma_of_find_child_device(struct
platform_device *parent,
struct bcma_device *core)
{
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless-next 2014-10-09
Dave,
Please pull this batch of fixes intended for the 3.18 stream!
Andrea Merello makes rtl818x_pci use a more reasonable transmission
rate for HW generated frames.
Fabian Frederick tweaks some kernel-doc bits to avoid warnings.
Larry Finger corrects a possible unaligned access in the rtlwifi code.
Marek Puzyniak avoids a kernel panic in ath9k_hw_reset.
Sujith Manoharan goes for the hat trick -- he fixes a smatch warning
in the shared ath code, he fixes a crash in ath9k, and he corrects
a sequence number assignment problem in ath9k too.
For ease of merging, I pulled the last bits of the wireless tree as well...
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 3f08e47291879fb047d7d4464d2beaedfea4eb63:
rtlwifi: Fix static checker warnings for various drivers (2014-10-02 14:26:32
-0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git
tags/master-2014-10-08
for you to fetch changes up to 1fca350b761631d182c2e8bce530896e66404bc2:
rtlwifi: Fix possible unaligned array in ether_addr_copy() (2014-10-08
15:24:16 -0400)
Andrea Merello (1):
rtl818x_pci: fix response rate may be incorrect.
Fabian Frederick (1):
net: rfkill: kernel-doc warning fixes
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Larry Finger (1):
rtlwifi: Fix possible unaligned array in ether_addr_copy()
Marek Puzyniak (1):
ath9k_htc: avoid kernel panic in ath9k_hw_reset
Sujith Manoharan (3):
ath: Fix smatch warning
ath9k: Fix crash in MCC mode
ath9k: Fix sequence number assignment
drivers/net/wireless/ath/ath9k/ath9k.h | 4 ++-
drivers/net/wireless/ath/ath9k/beacon.c| 12 ++--
drivers/net/wireless/ath/ath9k/common-beacon.c | 5 ++-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 4 +--
drivers/net/wireless/ath/ath9k/tx99.c | 8 -
drivers/net/wireless/ath/ath9k/xmit.c | 34 +---
drivers/net/wireless/ath/main.c| 8 ++---
drivers/net/wireless/brcm80211/Kconfig | 10 ++
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 10 +++---
drivers/net/wireless/brcm80211/brcmfmac/bcdc.h | 7 +++--
drivers/net/wireless/brcm80211/brcmfmac/fweh.c | 12 ++--
drivers/net/wireless/brcm80211/brcmfmac/fweh.h | 2 ++
drivers/net/wireless/brcm80211/brcmfmac/msgbuf.h | 11 +--
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 11 +--
drivers/net/wireless/rtl818x/rtl8180/dev.c | 36 +++---
drivers/net/wireless/rtlwifi/wifi.h| 2 +-
drivers/nfc/microread/microread.c | 16 +++---
drivers/nfc/st21nfca/Makefile | 5 +--
drivers/nfc/st21nfcb/Makefile | 5 +--
net/mac80211/sta_info.c| 2 +-
net/rfkill/core.c | 4 +--
net/rfkill/rfkill-gpio.c | 3 +-
net/wireless/nl80211.c | 6
25 files changed, 149 insertions(+), 71 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index bfa0b1518da1..01a7db061c6a 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -294,7 +294,6 @@ struct ath_tx_control {
* (axq_qnum).
*/
struct ath_tx {
- u16 seq_no;
u32 txqsetup;
spinlock_t txbuflock;
struct list_head txbuf;
@@ -563,6 +562,7 @@ int ath_tx_init(struct ath_softc *sc, int nbufs);
int ath_txq_update(struct ath_softc *sc, int qnum,
struct ath9k_tx_queue_info *q);
void ath_update_max_aggr_framelen(struct ath_softc *sc, int queue, int txop);
+void ath_assign_seq(struct ath_common *common, struct sk_buff *skb);
int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
struct ath_tx_control *txctl);
void ath_tx_cabq(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
@@ -592,6 +592,8 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
struct ath_vif {
struct list_head list;
+ u16 seq_no;
+
/* BSS info */
u8 bssid[ETH_ALEN];
u16 aid;
diff --git a/drivers/net/wireless/ath/ath9k/beacon.c
b/drivers/net/wireless/ath/ath9k/beacon.c
index a6af855ef6ed..ecb783beeec2 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -144,16 +144,8 @@ static struct ath_buf *ath9k_beacon_generate(struct
ieee80211_hw *hw,
mgmt_hdr->u.beacon.timestamp = avp->tsf_adjust;
info = IEEE80211_SKB_CB(skb);
- if (info-
Re: [PATCH 1/1 net-next] net: rfkill: kernel-doc warning fixes
On Thu, Oct 09, 2014 at 11:16:53AM +0200, Johannes Berg wrote: > Applied, with a somewhat better changelog. FWIW, I had already merged that one as-is -- sorry! -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 net-next] net: rfkill: kernel-doc warning fixes
On Thu, Oct 09, 2014 at 11:16:53AM +0200, Johannes Berg wrote: Applied, with a somewhat better changelog. FWIW, I had already merged that one as-is -- sorry! -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless-next 2014-10-09
Dave,
Please pull this batch of fixes intended for the 3.18 stream!
Andrea Merello makes rtl818x_pci use a more reasonable transmission
rate for HW generated frames.
Fabian Frederick tweaks some kernel-doc bits to avoid warnings.
Larry Finger corrects a possible unaligned access in the rtlwifi code.
Marek Puzyniak avoids a kernel panic in ath9k_hw_reset.
Sujith Manoharan goes for the hat trick -- he fixes a smatch warning
in the shared ath code, he fixes a crash in ath9k, and he corrects
a sequence number assignment problem in ath9k too.
For ease of merging, I pulled the last bits of the wireless tree as well...
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 3f08e47291879fb047d7d4464d2beaedfea4eb63:
rtlwifi: Fix static checker warnings for various drivers (2014-10-02 14:26:32
-0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git
tags/master-2014-10-08
for you to fetch changes up to 1fca350b761631d182c2e8bce530896e66404bc2:
rtlwifi: Fix possible unaligned array in ether_addr_copy() (2014-10-08
15:24:16 -0400)
Andrea Merello (1):
rtl818x_pci: fix response rate may be incorrect.
Fabian Frederick (1):
net: rfkill: kernel-doc warning fixes
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Larry Finger (1):
rtlwifi: Fix possible unaligned array in ether_addr_copy()
Marek Puzyniak (1):
ath9k_htc: avoid kernel panic in ath9k_hw_reset
Sujith Manoharan (3):
ath: Fix smatch warning
ath9k: Fix crash in MCC mode
ath9k: Fix sequence number assignment
drivers/net/wireless/ath/ath9k/ath9k.h | 4 ++-
drivers/net/wireless/ath/ath9k/beacon.c| 12 ++--
drivers/net/wireless/ath/ath9k/common-beacon.c | 5 ++-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 4 +--
drivers/net/wireless/ath/ath9k/tx99.c | 8 -
drivers/net/wireless/ath/ath9k/xmit.c | 34 +---
drivers/net/wireless/ath/main.c| 8 ++---
drivers/net/wireless/brcm80211/Kconfig | 10 ++
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 10 +++---
drivers/net/wireless/brcm80211/brcmfmac/bcdc.h | 7 +++--
drivers/net/wireless/brcm80211/brcmfmac/fweh.c | 12 ++--
drivers/net/wireless/brcm80211/brcmfmac/fweh.h | 2 ++
drivers/net/wireless/brcm80211/brcmfmac/msgbuf.h | 11 +--
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 11 +--
drivers/net/wireless/rtl818x/rtl8180/dev.c | 36 +++---
drivers/net/wireless/rtlwifi/wifi.h| 2 +-
drivers/nfc/microread/microread.c | 16 +++---
drivers/nfc/st21nfca/Makefile | 5 +--
drivers/nfc/st21nfcb/Makefile | 5 +--
net/mac80211/sta_info.c| 2 +-
net/rfkill/core.c | 4 +--
net/rfkill/rfkill-gpio.c | 3 +-
net/wireless/nl80211.c | 6
25 files changed, 149 insertions(+), 71 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index bfa0b1518da1..01a7db061c6a 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -294,7 +294,6 @@ struct ath_tx_control {
* (axq_qnum).
*/
struct ath_tx {
- u16 seq_no;
u32 txqsetup;
spinlock_t txbuflock;
struct list_head txbuf;
@@ -563,6 +562,7 @@ int ath_tx_init(struct ath_softc *sc, int nbufs);
int ath_txq_update(struct ath_softc *sc, int qnum,
struct ath9k_tx_queue_info *q);
void ath_update_max_aggr_framelen(struct ath_softc *sc, int queue, int txop);
+void ath_assign_seq(struct ath_common *common, struct sk_buff *skb);
int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
struct ath_tx_control *txctl);
void ath_tx_cabq(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
@@ -592,6 +592,8 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
struct ath_vif {
struct list_head list;
+ u16 seq_no;
+
/* BSS info */
u8 bssid[ETH_ALEN];
u16 aid;
diff --git a/drivers/net/wireless/ath/ath9k/beacon.c
b/drivers/net/wireless/ath/ath9k/beacon.c
index a6af855ef6ed..ecb783beeec2 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -144,16 +144,8 @@ static struct ath_buf *ath9k_beacon_generate(struct
ieee80211_hw *hw,
mgmt_hdr-u.beacon.timestamp = avp-tsf_adjust;
info = IEEE80211_SKB_CB(skb);
- if (info-flags
Re: pull request: wireless-next 2014-10-03
On Tue, Oct 07, 2014 at 12:47:24AM -0400, David Miller wrote: > From: David Miller > Date: Sun, 05 Oct 2014 21:38:53 -0400 (EDT) > > > From: David Miller > > Date: Sun, 05 Oct 2014 21:35:11 -0400 (EDT) > > > >> From: "John W. Linville" > >> Date: Fri, 3 Oct 2014 14:01:52 -0400 > >> > >>> Please pull tihs batch of updates intended for the 3.18 stream! > >> > >> Pulled, thanks for the stellar pull request text, as always. > > > > John, what's the deal with the following? Will it be resolved by the > > driver being removed from the staging tree? > > > > WARNING: drivers/staging/rtl8192ee/r8192ee: 'rtl_evm_dbm_jaguar' exported > > twice. Previous export was in drivers/net/wireless/rtlwifi/rtlwifi.ko > > John, ping? Sorry, Dave -- sendmail died on my local machine and I didn't notice until now... :-( Anyway...yes, the staging driver should be removed by a patch in Greg's queue. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless-next 2014-10-03
On Sun, Oct 05, 2014 at 09:38:53PM -0400, David Miller wrote: > From: David Miller > Date: Sun, 05 Oct 2014 21:35:11 -0400 (EDT) > > > From: "John W. Linville" > > Date: Fri, 3 Oct 2014 14:01:52 -0400 > > > >> Please pull tihs batch of updates intended for the 3.18 stream! > > > > Pulled, thanks for the stellar pull request text, as always. > > John, what's the deal with the following? Will it be resolved by the > driver being removed from the staging tree? > > WARNING: drivers/staging/rtl8192ee/r8192ee: 'rtl_evm_dbm_jaguar' exported > twice. Previous export was in drivers/net/wireless/rtlwifi/rtlwifi.ko Yes, exactly. -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless-next 2014-10-03
On Sun, Oct 05, 2014 at 09:38:53PM -0400, David Miller wrote: From: David Miller da...@davemloft.net Date: Sun, 05 Oct 2014 21:35:11 -0400 (EDT) From: John W. Linville linvi...@tuxdriver.com Date: Fri, 3 Oct 2014 14:01:52 -0400 Please pull tihs batch of updates intended for the 3.18 stream! Pulled, thanks for the stellar pull request text, as always. John, what's the deal with the following? Will it be resolved by the driver being removed from the staging tree? WARNING: drivers/staging/rtl8192ee/r8192ee: 'rtl_evm_dbm_jaguar' exported twice. Previous export was in drivers/net/wireless/rtlwifi/rtlwifi.ko Yes, exactly. -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless-next 2014-10-03
On Tue, Oct 07, 2014 at 12:47:24AM -0400, David Miller wrote: From: David Miller da...@davemloft.net Date: Sun, 05 Oct 2014 21:38:53 -0400 (EDT) From: David Miller da...@davemloft.net Date: Sun, 05 Oct 2014 21:35:11 -0400 (EDT) From: John W. Linville linvi...@tuxdriver.com Date: Fri, 3 Oct 2014 14:01:52 -0400 Please pull tihs batch of updates intended for the 3.18 stream! Pulled, thanks for the stellar pull request text, as always. John, what's the deal with the following? Will it be resolved by the driver being removed from the staging tree? WARNING: drivers/staging/rtl8192ee/r8192ee: 'rtl_evm_dbm_jaguar' exported twice. Previous export was in drivers/net/wireless/rtlwifi/rtlwifi.ko John, ping? Sorry, Dave -- sendmail died on my local machine and I didn't notice until now... :-( Anyway...yes, the staging driver should be removed by a patch in Greg's queue. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless-next 2014-10-03
setting retransmission effort Christophe Ricard (29): NFC: st21nfca: Fix sparse: cast to restricted __be32 NFC: st21nfca: Fix scripts/checkpatch.pl warnings "Missing a blank line after declarations" NFC: st21nfcb: Fix scripts/checkpatch.pl error "code indent should use tabs where possible" NFC: st21nfcb: Convert to use devm_gpio_request_one NFC: st21nfcb: Remove double assignment of .owner in struct device_driver NFC: st21nfcb: Remove useless new line in nfc_err call NFC: st21nfcb: Remove inappropriate kfree on a previously devm_kzalloc pointer NFC: st21nfca: Fix logic when setting session_id NFC: st21nfca: Remove useless new line in nfc_err call NFC: st21nfca: Change nfcid3 generation NFC: st21nfca: Remove useless err == 0 condition NFC: st21nfca: Remove useless IS_ERR(skb) conditions NFC: st21nfca: Add condition to make sure atr_req->length is valid. NFC: st21nfcb: Fix logic when running into i2c read retry NFC: st21nfca: Clean up st21nfca.h macros NFC: st21nfca: Clean up macros alignment NFC: st21nfca: fix "WARNING: else is not generally useful after a break or return" NFC: st21nfcb: Remove useless headers NFC: st21nfca: Fix few coding style issue NFC: st21nfca: Fix potential skb leaks in NFC-DEP code NFC: st21nfca: Fix recursive fault when doing p2p in target mode. NFC: dts: st21nfcb_i2c: Fix invalid interrupts polarity. NFC: st21nfcb: Fix improper management of -EREMOTEIO error code. NFC: st21nfcb: Fix improper ndlc T2 management NFC: nci: Add support for proprietary RF Protocols NFC: st21nfcb: Add ISO15693 Reader/Writer support NFC: st21nfcb: remove error output NFC: st21nfca: ERR_PTR vs NULL fix NFC: st21nfca: Fix potential double kfree_skb error Emil Goode (1): NFC: st21nfca: Remove double assignment of .owner in struct device_driver Emmanuel Grumbach (1): iwlwifi: mvm: disable BT Co-running by default Eyal Shapira (5): iwlwifi: mvm: choose an initial tx rate based on rssi conditions iwlwifi: mvm: rs: refactor to allow direct rs updating iwlwifi: mvm: limit aggregation size in low latency to 6 iwlwifi: mvm: report all BA notifs to RS iwlwifi: mvm: rs: fix logic in case of multiple TIDs Felix Fietkau (7): ath5k: add missing include for debug code ath9k: use ah->get_mac_revision for all SoC devices if available ath9k_hw: disable hardware ad-hoc flag on ar934x rev 3 Revert "ath9k_hw: reduce ANI firstep range for older chips" ath9k_hw: reduce ANI spur immunity setting on HT40 extension channel ath9k_hw: fix PLL clock initialization for newer SoC ath9k: fix getting tx duration for dynack Hante Meuleman (5): brcmfmac: On scan timeout do send received results. brcmfmac: Fix sign issue with IOCTL return code in msgbuf. brcmfmac: Avoid usage of GFP_ATOMIC. brcmfmac: Fix crash on cleanup. brcmfmac: Add wowl support for PCIE devices. Hauke Mehrtens (1): bcma: register bcma as device tree driver Ido Yariv (1): iwlwifi: mvm: support cloned tx skbs Joe Perches (1): Bluetooth: Convert bt_ logging functions to return void Johan Hedberg (6): Bluetooth: btusb: Use GFP_KERNEL in btusb_send_frame() Bluetooth: Fix setting correct security level when initiating SMP Bluetooth: Fix reason code used for rejecting SCO connections Bluetooth: Add retransmission effort into SCO parameter table Bluetooth: Rename sco_param_wideband table to esco_param_msbc Bluetooth: Fix lockdep warning with l2cap_chan_connect John W. Linville (5): Merge branch 'master' of git://git.kernel.org/.../iwlwifi/iwlwifi-next Merge branch 'for-linville' of git://github.com/kvalo/ath Merge tag 'nfc-next-3.18-1' of git://git.kernel.org/.../sameo/nfc-next Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next Jukka Rissanen (8): MAINTAINERS: add maintainer for generic 6LoWPAN Bluetooth: 6lowpan: Make sure skb exists before accessing it Bluetooth: 6lowpan: Ensure header compression does not corrupt IPv6 header Bluetooth: 6lowpan: Enable multicast support Bluetooth: 6lowpan: Memory leak as the skb is not freed Bluetooth: 6lowpan: Avoid memory leak if memory allocation fails Bluetooth: 6lowpan: Return EAGAIN error also for multicast packets Bluetooth: 6lowpan: Check transmit errors for multicast packets Kalle Valo (12): ath10k: make ath10k_wmi_cmd_send() public ath10k: add testmode ath10k: fix parenthesis alignment warning in ath10k_htt_rx_alloc() ath10k: fix checkpatch warnings about parenthesis alignment ath10k: fix use of multiple blank lin
pull request: wireless-next 2014-10-03
: Fix sparse: cast to restricted __be32 NFC: st21nfca: Fix scripts/checkpatch.pl warnings Missing a blank line after declarations NFC: st21nfcb: Fix scripts/checkpatch.pl error code indent should use tabs where possible NFC: st21nfcb: Convert to use devm_gpio_request_one NFC: st21nfcb: Remove double assignment of .owner in struct device_driver NFC: st21nfcb: Remove useless new line in nfc_err call NFC: st21nfcb: Remove inappropriate kfree on a previously devm_kzalloc pointer NFC: st21nfca: Fix logic when setting session_id NFC: st21nfca: Remove useless new line in nfc_err call NFC: st21nfca: Change nfcid3 generation NFC: st21nfca: Remove useless err == 0 condition NFC: st21nfca: Remove useless IS_ERR(skb) conditions NFC: st21nfca: Add condition to make sure atr_req-length is valid. NFC: st21nfcb: Fix logic when running into i2c read retry NFC: st21nfca: Clean up st21nfca.h macros NFC: st21nfca: Clean up macros alignment NFC: st21nfca: fix WARNING: else is not generally useful after a break or return NFC: st21nfcb: Remove useless headers NFC: st21nfca: Fix few coding style issue NFC: st21nfca: Fix potential skb leaks in NFC-DEP code NFC: st21nfca: Fix recursive fault when doing p2p in target mode. NFC: dts: st21nfcb_i2c: Fix invalid interrupts polarity. NFC: st21nfcb: Fix improper management of -EREMOTEIO error code. NFC: st21nfcb: Fix improper ndlc T2 management NFC: nci: Add support for proprietary RF Protocols NFC: st21nfcb: Add ISO15693 Reader/Writer support NFC: st21nfcb: remove error output NFC: st21nfca: ERR_PTR vs NULL fix NFC: st21nfca: Fix potential double kfree_skb error Emil Goode (1): NFC: st21nfca: Remove double assignment of .owner in struct device_driver Emmanuel Grumbach (1): iwlwifi: mvm: disable BT Co-running by default Eyal Shapira (5): iwlwifi: mvm: choose an initial tx rate based on rssi conditions iwlwifi: mvm: rs: refactor to allow direct rs updating iwlwifi: mvm: limit aggregation size in low latency to 6 iwlwifi: mvm: report all BA notifs to RS iwlwifi: mvm: rs: fix logic in case of multiple TIDs Felix Fietkau (7): ath5k: add missing include for debug code ath9k: use ah-get_mac_revision for all SoC devices if available ath9k_hw: disable hardware ad-hoc flag on ar934x rev 3 Revert ath9k_hw: reduce ANI firstep range for older chips ath9k_hw: reduce ANI spur immunity setting on HT40 extension channel ath9k_hw: fix PLL clock initialization for newer SoC ath9k: fix getting tx duration for dynack Hante Meuleman (5): brcmfmac: On scan timeout do send received results. brcmfmac: Fix sign issue with IOCTL return code in msgbuf. brcmfmac: Avoid usage of GFP_ATOMIC. brcmfmac: Fix crash on cleanup. brcmfmac: Add wowl support for PCIE devices. Hauke Mehrtens (1): bcma: register bcma as device tree driver Ido Yariv (1): iwlwifi: mvm: support cloned tx skbs Joe Perches (1): Bluetooth: Convert bt_level logging functions to return void Johan Hedberg (6): Bluetooth: btusb: Use GFP_KERNEL in btusb_send_frame() Bluetooth: Fix setting correct security level when initiating SMP Bluetooth: Fix reason code used for rejecting SCO connections Bluetooth: Add retransmission effort into SCO parameter table Bluetooth: Rename sco_param_wideband table to esco_param_msbc Bluetooth: Fix lockdep warning with l2cap_chan_connect John W. Linville (5): Merge branch 'master' of git://git.kernel.org/.../iwlwifi/iwlwifi-next Merge branch 'for-linville' of git://github.com/kvalo/ath Merge tag 'nfc-next-3.18-1' of git://git.kernel.org/.../sameo/nfc-next Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next Jukka Rissanen (8): MAINTAINERS: add maintainer for generic 6LoWPAN Bluetooth: 6lowpan: Make sure skb exists before accessing it Bluetooth: 6lowpan: Ensure header compression does not corrupt IPv6 header Bluetooth: 6lowpan: Enable multicast support Bluetooth: 6lowpan: Memory leak as the skb is not freed Bluetooth: 6lowpan: Avoid memory leak if memory allocation fails Bluetooth: 6lowpan: Return EAGAIN error also for multicast packets Bluetooth: 6lowpan: Check transmit errors for multicast packets Kalle Valo (12): ath10k: make ath10k_wmi_cmd_send() public ath10k: add testmode ath10k: fix parenthesis alignment warning in ath10k_htt_rx_alloc() ath10k: fix checkpatch warnings about parenthesis alignment ath10k: fix use of multiple blank lines ath10k: fix missing a blank line after declarations ath10k: fix space after a cast style errors ath10k: don't use
Re: pull request: bluetooth-next 2014-10-02
On Thu, Oct 02, 2014 at 06:14:57PM +0300, Johan Hedberg wrote: > Hi John, > > Unless 3.17 gets delayed this will probably be our last -next pull request for > 3.18. We've got: > > - New Marvell hardware supportr > - Multicast support for 6lowpan > - Several of 6lowpan fixes & cleanups > - Fix for a (false-positive) lockdep warning in L2CAP > - Minor btusb cleanup > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 565766b087a6d6ff257f5b79c8ceda0188c9169f: > > Bluetooth: Rename sco_param_wideband table to esco_param_msbc (2014-09-25 > 10:35:08 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to 9c238ca8ec79c38ab22762b44aeaf7a42fc97b18: > > Bluetooth: 6lowpan: Check transmit errors for multicast packets (2014-10-02 > 13:41:57 +0300) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-10-02
On Thu, Oct 02, 2014 at 06:14:57PM +0300, Johan Hedberg wrote: Hi John, Unless 3.17 gets delayed this will probably be our last -next pull request for 3.18. We've got: - New Marvell hardware supportr - Multicast support for 6lowpan - Several of 6lowpan fixes cleanups - Fix for a (false-positive) lockdep warning in L2CAP - Minor btusb cleanup Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 565766b087a6d6ff257f5b79c8ceda0188c9169f: Bluetooth: Rename sco_param_wideband table to esco_param_msbc (2014-09-25 10:35:08 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 9c238ca8ec79c38ab22762b44aeaf7a42fc97b18: Bluetooth: 6lowpan: Check transmit errors for multicast packets (2014-10-02 13:41:57 +0300) Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RESEND] ath5k: Remove AHB bus support
R8 },
> - { "2315", AR5K_VERSION_MAC, AR5K_SREV_AR2315_R6 },
> - { "2315", AR5K_VERSION_MAC, AR5K_SREV_AR2315_R7 },
> - { "2317", AR5K_VERSION_MAC, AR5K_SREV_AR2317_R1 },
> - { "2317", AR5K_VERSION_MAC, AR5K_SREV_AR2317_R2 },
> -#else
> { "5210", AR5K_VERSION_MAC, AR5K_SREV_AR5210 },
> { "5311", AR5K_VERSION_MAC, AR5K_SREV_AR5311 },
> { "5311A", AR5K_VERSION_MAC, AR5K_SREV_AR5311A },
> @@ -126,7 +117,6 @@ static const struct ath5k_srev_name srev_names[] = {
> { "5418", AR5K_VERSION_MAC, AR5K_SREV_AR5418 },
> { "2425", AR5K_VERSION_MAC, AR5K_SREV_AR2425 },
> { "2417", AR5K_VERSION_MAC, AR5K_SREV_AR2417 },
> -#endif
> { "x", AR5K_VERSION_MAC, AR5K_SREV_UNKNOWN },
> { "5110", AR5K_VERSION_RAD, AR5K_SREV_RAD_5110 },
> { "5111", AR5K_VERSION_RAD, AR5K_SREV_RAD_5111 },
> @@ -142,10 +132,6 @@ static const struct ath5k_srev_name srev_names[] = {
> { "5413", AR5K_VERSION_RAD, AR5K_SREV_RAD_5413 },
> { "5424", AR5K_VERSION_RAD, AR5K_SREV_RAD_5424 },
> { "5133", AR5K_VERSION_RAD, AR5K_SREV_RAD_5133 },
> -#ifdef CONFIG_ATHEROS_AR231X
> - { "2316", AR5K_VERSION_RAD, AR5K_SREV_RAD_2316 },
> - { "2317", AR5K_VERSION_RAD, AR5K_SREV_RAD_2317 },
> -#endif
> { "x", AR5K_VERSION_RAD, AR5K_SREV_UNKNOWN },
> };
>
> diff --git a/drivers/net/wireless/ath/ath5k/led.c
> b/drivers/net/wireless/ath/ath5k/led.c
> index 2062d1190556..0beb7e7d6075 100644
> --- a/drivers/net/wireless/ath/ath5k/led.c
> +++ b/drivers/net/wireless/ath/ath5k/led.c
> @@ -163,20 +163,14 @@ int ath5k_init_leds(struct ath5k_hw *ah)
> {
> int ret = 0;
> struct ieee80211_hw *hw = ah->hw;
> -#ifndef CONFIG_ATHEROS_AR231X
> struct pci_dev *pdev = ah->pdev;
> -#endif
> char name[ATH5K_LED_MAX_NAME_LEN + 1];
> const struct pci_device_id *match;
>
> if (!ah->pdev)
> return 0;
>
> -#ifdef CONFIG_ATHEROS_AR231X
> - match = NULL;
> -#else
> match = pci_match_id(_led_devices[0], pdev);
> -#endif
> if (match) {
> __set_bit(ATH_STAT_LEDSOFT, ah->status);
> ah->led_pin = ATH_PIN(match->driver_data);
> --
> 1.9.3
>
>
>
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub
suspend = (0 == (bcma_read32(pi->d11core, D11REGOFFS(maccontrol)) &
>MCTL_EN_MAC));
> @@ -4348,7 +4348,7 @@ void wlc_lcnphy_tx_power_adjustment(struct
> brcms_phy_pub *ppi)
> {
> s8 index;
> u16 index2;
> - struct brcms_phy *pi = (struct brcms_phy *) ppi;
> + struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
> struct brcms_phy_lcnphy *pi_lcn = pi->u.pi_lcnphy;
> u16 SAVE_txpwrctrl = wlc_lcnphy_get_tx_pwr_ctrl(pi);
> if (wlc_lcnphy_tempsense_based_pwr_ctrl_enabled(pi) &&
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
> b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
> index 93869e8..084f18f 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
> @@ -14121,7 +14121,7 @@ static u8 ant_sw_ctrl_tbl_rev8_2057v7_core1[] = {
>
> bool wlc_phy_bist_check_phy(struct brcms_phy_pub *pih)
> {
> - struct brcms_phy *pi = (struct brcms_phy *) pih;
> + struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
> u32 phybist0, phybist1, phybist2, phybist3, phybist4;
>
> if (NREV_GE(pi->pubpi.phy_rev, 16))
> @@ -19734,7 +19734,7 @@ void wlc_phy_rxcore_setstate_nphy(struct
> brcms_phy_pub *pih, u8 rxcore_bitmask)
> u16 regval;
> u16 tbl_buf[16];
> uint i;
> - struct brcms_phy *pi = (struct brcms_phy *) pih;
> + struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
> u16 tbl_opcode;
> bool suspend;
>
> @@ -19812,7 +19812,7 @@ void wlc_phy_rxcore_setstate_nphy(struct
> brcms_phy_pub *pih, u8 rxcore_bitmask)
> u8 wlc_phy_rxcore_getstate_nphy(struct brcms_phy_pub *pih)
> {
> u16 regval, rxen_bits;
> - struct brcms_phy *pi = (struct brcms_phy *) pih;
> + struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
>
> regval = read_phy_reg(pi, 0xa2);
> rxen_bits = (regval >> 4) & 0xf;
> @@ -21342,7 +21342,7 @@ void wlc_phy_chanspec_set_nphy(struct brcms_phy *pi,
> u16 chanspec)
>
> void wlc_phy_antsel_init(struct brcms_phy_pub *ppi, bool lut_init)
> {
> - struct brcms_phy *pi = (struct brcms_phy *) ppi;
> + struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
> u16 mask = 0xfc00;
> u32 mc = 0;
>
> --
> 1.9.1
>
>
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-09-25
On Thu, Sep 25, 2014 at 02:35:53PM +0300, Johan Hedberg wrote:
> Hi John,
>
> This 3.18 pull request replaces the one I did on Monday ("bluetooth-next
> 2014-09-22", which hasn't been pulled yet). The additions since the last
> request are:
>
> - SCO connection fix for devices not supporting eSCO
> - Cleanups regarding the SCO establishment logic
> - Remove unnecessary return value from logging functions
> - Header compression fix for 6lowpan
> - Cleanups to the ieee802154/mrf24j40 driver
>
> Here's a copy from previous request that this one replaces:
>
> "
> Here are some more patches for 3.18. They include various fixes to the
> btusb HCI driver, a fix for LE SMP, as well as adding Jukka to the
> MAINTAINERS file for generic 6LoWPAN (as requested by Alexander Aring).
>
> I've held on to this pull request a bit since we were waiting for a SCO
> related fix to get sorted out first. However, since the merge window is
> getting closer I decided not to wait for it. If we do get the fix sorted
> out there'll probably be a second small pull request later this week.
> "
>
> Please let me know if there are any issues pulling. Thanks.
>
> Johan
>
> ---
> The following changes since commit 9a783a139c32a905825ee0aa9597f485ea461f76:
>
> Bluetooth: Fix re-setting RPA as expired when deferring update (2014-09-12
> 18:34:25 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
> for-upstream
>
> for you to fetch changes up to 565766b087a6d6ff257f5b79c8ceda0188c9169f:
>
> Bluetooth: Rename sco_param_wideband table to esco_param_msbc (2014-09-25
> 10:35:08 +0200)
Pulling now, but I don't plan to push it back out until Dave pulls my earlier
batch...
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-09-25
On Thu, Sep 25, 2014 at 02:35:53PM +0300, Johan Hedberg wrote: Hi John, This 3.18 pull request replaces the one I did on Monday (bluetooth-next 2014-09-22, which hasn't been pulled yet). The additions since the last request are: - SCO connection fix for devices not supporting eSCO - Cleanups regarding the SCO establishment logic - Remove unnecessary return value from logging functions - Header compression fix for 6lowpan - Cleanups to the ieee802154/mrf24j40 driver Here's a copy from previous request that this one replaces: Here are some more patches for 3.18. They include various fixes to the btusb HCI driver, a fix for LE SMP, as well as adding Jukka to the MAINTAINERS file for generic 6LoWPAN (as requested by Alexander Aring). I've held on to this pull request a bit since we were waiting for a SCO related fix to get sorted out first. However, since the merge window is getting closer I decided not to wait for it. If we do get the fix sorted out there'll probably be a second small pull request later this week. Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 9a783a139c32a905825ee0aa9597f485ea461f76: Bluetooth: Fix re-setting RPA as expired when deferring update (2014-09-12 18:34:25 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 565766b087a6d6ff257f5b79c8ceda0188c9169f: Bluetooth: Rename sco_param_wideband table to esco_param_msbc (2014-09-25 10:35:08 +0200) Pulling now, but I don't plan to push it back out until Dave pulls my earlier batch... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/2] brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub
*) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
*txchain = pi-sh-phytxchain;
*rxchain = pi-sh-phyrxchain;
@@ -2837,7 +2837,7 @@ u8 wlc_phy_stf_chain_active_get(struct brcms_phy_pub
*pih)
{
s16 nphy_currtemp;
u8 active_bitmap;
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
active_bitmap = (pi-phy_txcore_heatedup) ? 0x31 : 0x33;
@@ -2867,7 +2867,7 @@ u8 wlc_phy_stf_chain_active_get(struct brcms_phy_pub
*pih)
s8 wlc_phy_stf_ssmode_get(struct brcms_phy_pub *pih, u16 chanspec)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
u8 siso_mcs_id, cdd_mcs_id;
siso_mcs_id =
@@ -2944,7 +2944,7 @@ s8 wlc_phy_upd_rssi_offset(struct brcms_phy *pi, s8
rssi, u16 chanspec)
bool wlc_phy_txpower_ipa_ison(struct brcms_phy_pub *ppi)
{
- struct brcms_phy *pi = (struct brcms_phy *) ppi;
+ struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
if (ISNPHY(pi))
return wlc_phy_n_txpower_ipa_ison(pi);
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
index b2d6d6d..5f13662 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -2865,7 +2865,7 @@ static void wlc_lcnphy_idle_tssi_est(struct
brcms_phy_pub *ppi)
{
bool suspend, tx_gain_override_old;
struct lcnphy_txgains old_gains;
- struct brcms_phy *pi = (struct brcms_phy *) ppi;
+ struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
u16 idleTssi, idleTssi0_2C, idleTssi0_OB, idleTssi0_regvalue_OB,
idleTssi0_regvalue_2C;
u16 SAVE_txpwrctrl = wlc_lcnphy_get_tx_pwr_ctrl(pi);
@@ -3084,7 +3084,7 @@ static void wlc_lcnphy_tx_pwr_ctrl_init(struct
brcms_phy_pub *ppi)
s32 a1, b0, b1;
s32 tssi, pwr, maxtargetpwr, mintargetpwr;
bool suspend;
- struct brcms_phy *pi = (struct brcms_phy *) ppi;
+ struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
suspend = (0 == (bcma_read32(pi-d11core, D11REGOFFS(maccontrol))
MCTL_EN_MAC));
@@ -4348,7 +4348,7 @@ void wlc_lcnphy_tx_power_adjustment(struct
brcms_phy_pub *ppi)
{
s8 index;
u16 index2;
- struct brcms_phy *pi = (struct brcms_phy *) ppi;
+ struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
struct brcms_phy_lcnphy *pi_lcn = pi-u.pi_lcnphy;
u16 SAVE_txpwrctrl = wlc_lcnphy_get_tx_pwr_ctrl(pi);
if (wlc_lcnphy_tempsense_based_pwr_ctrl_enabled(pi)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
index 93869e8..084f18f 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
@@ -14121,7 +14121,7 @@ static u8 ant_sw_ctrl_tbl_rev8_2057v7_core1[] = {
bool wlc_phy_bist_check_phy(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
u32 phybist0, phybist1, phybist2, phybist3, phybist4;
if (NREV_GE(pi-pubpi.phy_rev, 16))
@@ -19734,7 +19734,7 @@ void wlc_phy_rxcore_setstate_nphy(struct
brcms_phy_pub *pih, u8 rxcore_bitmask)
u16 regval;
u16 tbl_buf[16];
uint i;
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
u16 tbl_opcode;
bool suspend;
@@ -19812,7 +19812,7 @@ void wlc_phy_rxcore_setstate_nphy(struct
brcms_phy_pub *pih, u8 rxcore_bitmask)
u8 wlc_phy_rxcore_getstate_nphy(struct brcms_phy_pub *pih)
{
u16 regval, rxen_bits;
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
regval = read_phy_reg(pi, 0xa2);
rxen_bits = (regval 4) 0xf;
@@ -21342,7 +21342,7 @@ void wlc_phy_chanspec_set_nphy(struct brcms_phy *pi,
u16 chanspec)
void wlc_phy_antsel_init(struct brcms_phy_pub *ppi, bool lut_init)
{
- struct brcms_phy *pi = (struct brcms_phy *) ppi;
+ struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
u16 mask = 0xfc00;
u32 mc = 0;
--
1.9.1
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Re: [PATCH] [RESEND] ath5k: Remove AHB bus support
char name[ATH5K_LED_MAX_NAME_LEN + 1];
const struct pci_device_id *match;
if (!ah-pdev)
return 0;
-#ifdef CONFIG_ATHEROS_AR231X
- match = NULL;
-#else
match = pci_match_id(ath5k_led_devices[0], pdev);
-#endif
if (match) {
__set_bit(ATH_STAT_LEDSOFT, ah-status);
ah-led_pin = ATH_PIN(match-driver_data);
--
1.9.3
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-09-23
Dave,
Please consider pulling this one last batch of fixes intended for the 3.17
stream!
For the NFC bits, Samuel says:
"Hopefully not too late for a handful of NFC fixes:
- 2 potential build failures for ST21NFCA and ST21NFCB, triggered by a
depmod dependenyc cycle.
- One potential buffer overflow in the microread driver."
On top of that...
Emil Goode provides a fix for a brcmfmac off-by-one regression which
was introduced in the 3.17 cycle.
Loic Poulain fixes a polarity mismatch for a variable assignment
inside of rfkill-gpio.
Wojciech Dubowik prevents a NULL pointer dereference in ath9k.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit dda3b191eb6c5a56d443723dcb71ade60d97c04f:
net: rfkill: gpio: Enable module auto-loading for ACPI based switches
(2014-09-16 16:09:01 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-09-23
for you to fetch changes up to f8adaf0ae978252c9f7e29e96aefcd8fcaf806ba:
brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels() (2014-09-23
10:48:26 -0400)
Christophe Ricard (2):
NFC: st21nfcb: Fix depmod dependency cycle
NFC: st21nfca: Fix potential depmod dependency cycle
Dan Carpenter (1):
NFC: microread: Potential overflows in microread_target_discovered()
Emil Goode (1):
brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()
John W. Linville (1):
Merge tag 'nfc-fixes-3.17-1' of git://git.kernel.org/.../sameo/nfc-fixes
Loic Poulain (1):
net: rfkill: gpio: Fix clock status
Wojciech Dubowik (1):
ath9k: Fix NULL pointer dereference on early irq
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 2 +-
drivers/nfc/microread/microread.c | 16
drivers/nfc/st21nfca/Makefile | 5 +++--
drivers/nfc/st21nfcb/Makefile | 5 +++--
net/rfkill/rfkill-gpio.c | 2 +-
6 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index e6ac8d2e610c..4b148bbb2bf6 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -513,7 +513,7 @@ irqreturn_t ath_isr(int irq, void *dev)
* touch anything. Note this can happen early
* on if the IRQ is shared.
*/
- if (test_bit(ATH_OP_INVALID, >op_flags))
+ if (!ah || test_bit(ATH_OP_INVALID, >op_flags))
return IRQ_NONE;
/* shared irq, not for us */
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index f3a9804988a6..16a246bfc343 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -4921,7 +4921,7 @@ static void brcmf_count_20mhz_channels(struct
brcmf_cfg80211_info *cfg,
struct brcmu_chan ch;
int i;
- for (i = 0; i <= total; i++) {
+ for (i = 0; i < total; i++) {
ch.chspec = (u16)le32_to_cpu(chlist->element[i]);
cfg->d11inf.decchspec();
diff --git a/drivers/nfc/microread/microread.c
b/drivers/nfc/microread/microread.c
index f868333271aa..963a4a5dc88e 100644
--- a/drivers/nfc/microread/microread.c
+++ b/drivers/nfc/microread/microread.c
@@ -501,9 +501,13 @@ static void microread_target_discovered(struct nfc_hci_dev
*hdev, u8 gate,
targets->sens_res =
be16_to_cpu(*(u16 *)>data[MICROREAD_EMCF_A_ATQA]);
targets->sel_res = skb->data[MICROREAD_EMCF_A_SAK];
- memcpy(targets->nfcid1, >data[MICROREAD_EMCF_A_UID],
- skb->data[MICROREAD_EMCF_A_LEN]);
targets->nfcid1_len = skb->data[MICROREAD_EMCF_A_LEN];
+ if (targets->nfcid1_len > sizeof(targets->nfcid1)) {
+ r = -EINVAL;
+ goto exit_free;
+ }
+ memcpy(targets->nfcid1, >data[MICROREAD_EMCF_A_UID],
+ targets->nfcid1_len);
break;
case MICROREAD_GATE_ID_MREAD_ISO_A_3:
targets->supported_protocols =
@@ -511,9 +515,13 @@ static void microread_target_discovered(struct nfc_hci_dev
*hdev, u8 gate,
targets->sens_res =
be16_to_cpu(*(u16
*)>data[MICROREAD_EMCF_A3_ATQA]);
targets->sel_res = skb->data[MICROREAD_EMCF_A3_SAK];
- memcpy(targets->nfcid1, >data[MICROREAD_EMCF_A3_UID],
- skb->data[MICROREAD_EMCF_A3_LEN]);
targets
Re: [PATCH] ath: change logging functions to return void
On Tue, Sep 23, 2014 at 07:20:53AM +0300, Kalle Valo wrote: > Joe Perches writes: > > > The return values are not used by callers of these functions > > so change the functions to return void. > > > > Other miscellanea: > > > > o add __printf verification to wil6210 logging functions > > No format/argument mismatches found > > > > Signed-off-by: Joe Perches > > --- > > This change is associated to a desire to eventually > > change printk to return void. > > > > drivers/net/wireless/ath/ath10k/debug.c| 18 +- > > drivers/net/wireless/ath/ath10k/debug.h| 6 +++--- > > drivers/net/wireless/ath/ath6kl/common.h | 2 +- > > drivers/net/wireless/ath/ath6kl/debug.c| 28 > > > > drivers/net/wireless/ath/ath6kl/debug.h| 13 ++--- > > For ath6kl and ath10k: > > Acked-by: Kalle Valo > > > drivers/net/wireless/ath/wil6210/debug.c | 14 -- > > drivers/net/wireless/ath/wil6210/wil6210.h | 7 +-- > > 7 files changed, 32 insertions(+), 56 deletions(-) > > John, as this patch also contains a wil6210 change how do you want to > handle this? I had presumed that you would merge it through the ath tree, so I deleted it... John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ath: change logging functions to return void
On Tue, Sep 23, 2014 at 07:20:53AM +0300, Kalle Valo wrote: Joe Perches j...@perches.com writes: The return values are not used by callers of these functions so change the functions to return void. Other miscellanea: o add __printf verification to wil6210 logging functions No format/argument mismatches found Signed-off-by: Joe Perches j...@perches.com --- This change is associated to a desire to eventually change printk to return void. drivers/net/wireless/ath/ath10k/debug.c| 18 +- drivers/net/wireless/ath/ath10k/debug.h| 6 +++--- drivers/net/wireless/ath/ath6kl/common.h | 2 +- drivers/net/wireless/ath/ath6kl/debug.c| 28 drivers/net/wireless/ath/ath6kl/debug.h| 13 ++--- For ath6kl and ath10k: Acked-by: Kalle Valo kv...@qca.qualcomm.com drivers/net/wireless/ath/wil6210/debug.c | 14 -- drivers/net/wireless/ath/wil6210/wil6210.h | 7 +-- 7 files changed, 32 insertions(+), 56 deletions(-) John, as this patch also contains a wil6210 change how do you want to handle this? I had presumed that you would merge it through the ath tree, so I deleted it... John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-09-23
Dave,
Please consider pulling this one last batch of fixes intended for the 3.17
stream!
For the NFC bits, Samuel says:
Hopefully not too late for a handful of NFC fixes:
- 2 potential build failures for ST21NFCA and ST21NFCB, triggered by a
depmod dependenyc cycle.
- One potential buffer overflow in the microread driver.
On top of that...
Emil Goode provides a fix for a brcmfmac off-by-one regression which
was introduced in the 3.17 cycle.
Loic Poulain fixes a polarity mismatch for a variable assignment
inside of rfkill-gpio.
Wojciech Dubowik prevents a NULL pointer dereference in ath9k.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit dda3b191eb6c5a56d443723dcb71ade60d97c04f:
net: rfkill: gpio: Enable module auto-loading for ACPI based switches
(2014-09-16 16:09:01 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-09-23
for you to fetch changes up to f8adaf0ae978252c9f7e29e96aefcd8fcaf806ba:
brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels() (2014-09-23
10:48:26 -0400)
Christophe Ricard (2):
NFC: st21nfcb: Fix depmod dependency cycle
NFC: st21nfca: Fix potential depmod dependency cycle
Dan Carpenter (1):
NFC: microread: Potential overflows in microread_target_discovered()
Emil Goode (1):
brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()
John W. Linville (1):
Merge tag 'nfc-fixes-3.17-1' of git://git.kernel.org/.../sameo/nfc-fixes
Loic Poulain (1):
net: rfkill: gpio: Fix clock status
Wojciech Dubowik (1):
ath9k: Fix NULL pointer dereference on early irq
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 2 +-
drivers/nfc/microread/microread.c | 16
drivers/nfc/st21nfca/Makefile | 5 +++--
drivers/nfc/st21nfcb/Makefile | 5 +++--
net/rfkill/rfkill-gpio.c | 2 +-
6 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index e6ac8d2e610c..4b148bbb2bf6 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -513,7 +513,7 @@ irqreturn_t ath_isr(int irq, void *dev)
* touch anything. Note this can happen early
* on if the IRQ is shared.
*/
- if (test_bit(ATH_OP_INVALID, common-op_flags))
+ if (!ah || test_bit(ATH_OP_INVALID, common-op_flags))
return IRQ_NONE;
/* shared irq, not for us */
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index f3a9804988a6..16a246bfc343 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -4921,7 +4921,7 @@ static void brcmf_count_20mhz_channels(struct
brcmf_cfg80211_info *cfg,
struct brcmu_chan ch;
int i;
- for (i = 0; i = total; i++) {
+ for (i = 0; i total; i++) {
ch.chspec = (u16)le32_to_cpu(chlist-element[i]);
cfg-d11inf.decchspec(ch);
diff --git a/drivers/nfc/microread/microread.c
b/drivers/nfc/microread/microread.c
index f868333271aa..963a4a5dc88e 100644
--- a/drivers/nfc/microread/microread.c
+++ b/drivers/nfc/microread/microread.c
@@ -501,9 +501,13 @@ static void microread_target_discovered(struct nfc_hci_dev
*hdev, u8 gate,
targets-sens_res =
be16_to_cpu(*(u16 *)skb-data[MICROREAD_EMCF_A_ATQA]);
targets-sel_res = skb-data[MICROREAD_EMCF_A_SAK];
- memcpy(targets-nfcid1, skb-data[MICROREAD_EMCF_A_UID],
- skb-data[MICROREAD_EMCF_A_LEN]);
targets-nfcid1_len = skb-data[MICROREAD_EMCF_A_LEN];
+ if (targets-nfcid1_len sizeof(targets-nfcid1)) {
+ r = -EINVAL;
+ goto exit_free;
+ }
+ memcpy(targets-nfcid1, skb-data[MICROREAD_EMCF_A_UID],
+ targets-nfcid1_len);
break;
case MICROREAD_GATE_ID_MREAD_ISO_A_3:
targets-supported_protocols =
@@ -511,9 +515,13 @@ static void microread_target_discovered(struct nfc_hci_dev
*hdev, u8 gate,
targets-sens_res =
be16_to_cpu(*(u16
*)skb-data[MICROREAD_EMCF_A3_ATQA]);
targets-sel_res = skb-data[MICROREAD_EMCF_A3_SAK];
- memcpy(targets-nfcid1, skb-data[MICROREAD_EMCF_A3_UID],
- skb-data[MICROREAD_EMCF_A3_LEN]);
targets-nfcid1_len = skb-data[MICROREAD_EMCF_A3_LEN];
+ if (targets-nfcid1_len sizeof
pull request: wireless-next 2014-09-22
Eran Harary (1): iwlwifi: mvm: allow preventing dummy notifications Eyal Shapira (7): mac80211: fix broken use of VHT/20Mhz with some APs iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate iwlwifi: mvm: fix an overflow in iwl_mvm_get_signal_strength iwlwifi: mvm: add LDPC support iwlwifi: enable LDPC in 8000 chip family iwlwifi: mvm: rs: remove max_rate_idx iwlwifi: mvm: rs: don't zero tx stats after idle Fabian Frederick (2): brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub brcm80211: use container_of to resolve dma_info from dma_pub Hans Wennborg (2): iwl4965: fix %d confusingly prefixed with 0x in format string rtlwifi: fix %d confusingly prefixed with 0x in format strings Hauke Mehrtens (7): bcma: store more alternative addresses bcma: add support for chipcommon B core b43: tell the ucode the mac capabilities b43: tell ucode the phy type and version b43: add missing rate b43: update some transmit header constants b43: add support for setting the beacon listen interval Johan Hedberg (41): Bluetooth: Fix incorrect LE CoC PDU length restriction based on HCI MTU Bluetooth: Remove unnecessary l2cap_chan_unlock before l2cap_chan_add Bluetooth: Fix hci_conn reference counting for fixed channels Bluetooth: Set addr_type only when it's needed Bluetooth: Optimize connection parameter lookup for LE connections Bluetooth: Improve *_get() functions to return the object type Bluetooth: Fix using hci_conn_get() for hci_conn pointers Bluetooth: Refactor connection parameter freeing into its own function Bluetooth: Use zero timeout for immediate scheduling Bluetooth: Fix hci_conn reference counting with hci_chan Bluetooth: Set disc_timeout to 0 when calling hci_chan_del Bluetooth: Ignore incoming data after initiating disconnection Bluetooth: Remove hci_conn_hold/drop from hci_chan Bluetooth: Set discon_timeout to 0 in l2cap_conn_del Bluetooth: Use hci_disconnect for immediate disconnection from SMP Bluetooth: Remove unused l2cap_conn_shutdown API Bluetooth: Fix SMP error and response to be mutually exclusive Bluetooth: Update hci_disconnect() to return an error value Bluetooth: Use hci_disconnect() for mgmt_disconnect_device() Bluetooth: Move clock offset reading into hci_disconnect() Bluetooth: Add clarifying comment for LE CoC result value Bluetooth: Remove unnecessary checks after canceling SMP security timer Bluetooth: Don't take any action in smp_resume_cb if not encrypted Bluetooth: Move identity address update behind a workqueue Bluetooth: Remove unnecessary deferred work for SMP key distribution Bluetooth: Fix locking of the SMP context Bluetooth: Add define for key distribution mask Bluetooth: Fix calling smp_distribute_keys() when still waiting for keys Bluetooth: Add strict checks for allowed SMP PDUs Bluetooth: Fix dereferencing conn variable before NULL check Bluetooth: Fix mgmt pairing failure when authentication fails Bluetooth: Fix allowing SMP Signing info PDU Bluetooth: Remove unnecessary early initialization of variable Bluetooth: Fix ignoring unknown SMP authentication requirement bits Bluetooth: Centralize disallowing SMP commands to a single place Bluetooth: Fix SMP security level when we have no IO capabilities Bluetooth: Add smp_ltk_sec_level() helper function Bluetooth: Fix L2CAP information request handling for fixed channels Bluetooth: Avoid hard-coded IO capability values in SMP Bluetooth: Expire RPA if encryption fails Bluetooth: Fix re-setting RPA as expired when deferring update Johannes Berg (19): mac80211: clean up ieee80211_i.h mac80211: add Intel Mobile Communications copyright cfg80211: add Intel Mobile Communications copyright iwlwifi: mvm: BT Coex - remove shadowing variable iwlwifi: mvm: correctly handle PM/QoS changes from mac80211 iwlwifi: mvm: BT Coex - always initialize smps_mode mac80211: annotate MMIC head/tailroom warning cfg80211: clear connect keys when freeing them mac80211: clear key material when freeing keys cfg80211: clear wext keys when freeing and removing them cfg80211: don't put kek/kck/replay counter on the stack cfg80211: clear nl80211 messages carrying keys after processing cfg80211: add WMM traffic stream API iwlwifi: mvm: disable aggregation queues in station DB in FW iwlwifi: pcie: clear command data on freeing iwlwifi: mvm: don't update quota in firmware too often iwlwifi: mvm: update d0i3 debugfs iwlwifi: mvm: fix quota update avoidance iwlwifi: mvm: update QoS parameters when they change John W. Linville (3): Merge branch 'for-john' of git://git.kernel.org/.../iwl
pull request: wireless-next 2014-09-22
notifications Eyal Shapira (7): mac80211: fix broken use of VHT/20Mhz with some APs iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate iwlwifi: mvm: fix an overflow in iwl_mvm_get_signal_strength iwlwifi: mvm: add LDPC support iwlwifi: enable LDPC in 8000 chip family iwlwifi: mvm: rs: remove max_rate_idx iwlwifi: mvm: rs: don't zero tx stats after idle Fabian Frederick (2): brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub brcm80211: use container_of to resolve dma_info from dma_pub Hans Wennborg (2): iwl4965: fix %d confusingly prefixed with 0x in format string rtlwifi: fix %d confusingly prefixed with 0x in format strings Hauke Mehrtens (7): bcma: store more alternative addresses bcma: add support for chipcommon B core b43: tell the ucode the mac capabilities b43: tell ucode the phy type and version b43: add missing rate b43: update some transmit header constants b43: add support for setting the beacon listen interval Johan Hedberg (41): Bluetooth: Fix incorrect LE CoC PDU length restriction based on HCI MTU Bluetooth: Remove unnecessary l2cap_chan_unlock before l2cap_chan_add Bluetooth: Fix hci_conn reference counting for fixed channels Bluetooth: Set addr_type only when it's needed Bluetooth: Optimize connection parameter lookup for LE connections Bluetooth: Improve *_get() functions to return the object type Bluetooth: Fix using hci_conn_get() for hci_conn pointers Bluetooth: Refactor connection parameter freeing into its own function Bluetooth: Use zero timeout for immediate scheduling Bluetooth: Fix hci_conn reference counting with hci_chan Bluetooth: Set disc_timeout to 0 when calling hci_chan_del Bluetooth: Ignore incoming data after initiating disconnection Bluetooth: Remove hci_conn_hold/drop from hci_chan Bluetooth: Set discon_timeout to 0 in l2cap_conn_del Bluetooth: Use hci_disconnect for immediate disconnection from SMP Bluetooth: Remove unused l2cap_conn_shutdown API Bluetooth: Fix SMP error and response to be mutually exclusive Bluetooth: Update hci_disconnect() to return an error value Bluetooth: Use hci_disconnect() for mgmt_disconnect_device() Bluetooth: Move clock offset reading into hci_disconnect() Bluetooth: Add clarifying comment for LE CoC result value Bluetooth: Remove unnecessary checks after canceling SMP security timer Bluetooth: Don't take any action in smp_resume_cb if not encrypted Bluetooth: Move identity address update behind a workqueue Bluetooth: Remove unnecessary deferred work for SMP key distribution Bluetooth: Fix locking of the SMP context Bluetooth: Add define for key distribution mask Bluetooth: Fix calling smp_distribute_keys() when still waiting for keys Bluetooth: Add strict checks for allowed SMP PDUs Bluetooth: Fix dereferencing conn variable before NULL check Bluetooth: Fix mgmt pairing failure when authentication fails Bluetooth: Fix allowing SMP Signing info PDU Bluetooth: Remove unnecessary early initialization of variable Bluetooth: Fix ignoring unknown SMP authentication requirement bits Bluetooth: Centralize disallowing SMP commands to a single place Bluetooth: Fix SMP security level when we have no IO capabilities Bluetooth: Add smp_ltk_sec_level() helper function Bluetooth: Fix L2CAP information request handling for fixed channels Bluetooth: Avoid hard-coded IO capability values in SMP Bluetooth: Expire RPA if encryption fails Bluetooth: Fix re-setting RPA as expired when deferring update Johannes Berg (19): mac80211: clean up ieee80211_i.h mac80211: add Intel Mobile Communications copyright cfg80211: add Intel Mobile Communications copyright iwlwifi: mvm: BT Coex - remove shadowing variable iwlwifi: mvm: correctly handle PM/QoS changes from mac80211 iwlwifi: mvm: BT Coex - always initialize smps_mode mac80211: annotate MMIC head/tailroom warning cfg80211: clear connect keys when freeing them mac80211: clear key material when freeing keys cfg80211: clear wext keys when freeing and removing them cfg80211: don't put kek/kck/replay counter on the stack cfg80211: clear nl80211 messages carrying keys after processing cfg80211: add WMM traffic stream API iwlwifi: mvm: disable aggregation queues in station DB in FW iwlwifi: pcie: clear command data on freeing iwlwifi: mvm: don't update quota in firmware too often iwlwifi: mvm: update d0i3 debugfs iwlwifi: mvm: fix quota update avoidance iwlwifi: mvm: update QoS parameters when they change John W. Linville (3): Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-next Merge tag 'mac80211-next
pull request: wireless 2014-09-17
NL80211_IFTYPE_ADHOC) ||
(wdev->iftype == NL80211_IFTYPE_AP) ||
@@ -5143,6 +5146,7 @@ static int brcmf_enable_bw40_2g(struct
brcmf_cfg80211_info *cfg)
ch.band = BRCMU_CHAN_BAND_2G;
ch.bw = BRCMU_CHAN_BW_40;
+ ch.sb = BRCMU_CHAN_SB_NONE;
ch.chnum = 0;
cfg->d11inf.encchspec();
@@ -5176,6 +5180,7 @@ static int brcmf_enable_bw40_2g(struct
brcmf_cfg80211_info *cfg)
brcmf_update_bw40_channel_flag(>channels[j], );
}
+ kfree(pbuf);
}
return err;
}
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 02a86a27fd84..5fa54dd78e25 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -163,6 +163,7 @@ static const struct acpi_device_id rfkill_acpi_match[] = {
{ "LNV4752", RFKILL_TYPE_GPS },
{ },
};
+MODULE_DEVICE_TABLE(acpi, rfkill_acpi_match);
#endif
static struct platform_driver rfkill_gpio_driver = {
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
pgpXnodsPtHU1.pgp
Description: PGP signature
pull request: wireless 2014-09-17
= BRCMU_CHAN_BAND_2G;
ch.bw = BRCMU_CHAN_BW_40;
+ ch.sb = BRCMU_CHAN_SB_NONE;
ch.chnum = 0;
cfg-d11inf.encchspec(ch);
@@ -5176,6 +5180,7 @@ static int brcmf_enable_bw40_2g(struct
brcmf_cfg80211_info *cfg)
brcmf_update_bw40_channel_flag(band-channels[j], ch);
}
+ kfree(pbuf);
}
return err;
}
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 02a86a27fd84..5fa54dd78e25 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -163,6 +163,7 @@ static const struct acpi_device_id rfkill_acpi_match[] = {
{ LNV4752, RFKILL_TYPE_GPS },
{ },
};
+MODULE_DEVICE_TABLE(acpi, rfkill_acpi_match);
#endif
static struct platform_driver rfkill_gpio_driver = {
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
pgpXnodsPtHU1.pgp
Description: PGP signature
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Tue, Sep 16, 2014 at 10:26:59PM +0200, Paul Bolle wrote: > On Mon, 2014-09-15 at 14:45 -0400, John W. Linville wrote: > > FYI -- Sergey posted a series to linux-mips on 14 September 2014 that > > touches the symbol in question. For whatever reason, it is posted > > there as RFC. > > Thanks for passing that on. > > > Does this satisfy the interested parties?? > > In case I qualify as an interested party: resolving this by, in short, > making AHB support actually buildable is of course the preferable > solution. > > Whether or not we should drop my patch while waiting for that series to > land in linux-next is not my call. But if it hasn't landed by, say, > about the time v3.18-rc3 is released I might raise this issue again. > > I must say that I'm a bit puzzled why people have resisted this rather > small cleanup for years. How did having unbuildable AHB support in > mainline benefit anyone? Couldn't the revert of this cleanup also be > handled out of tree? Note that the revert is only "6 files changed, 3 > insertions(+), 294 deletions(-)", while the series is "39 files changed, > 3911 insertions(+), 10 deletions(-)". I think it got added with the notion that the code was "coming soon". As you have tried to remove it, the "coming soon" refrain continued. I'm still inclined to merge your patch. An RFC series posted to another mailing list doesn't really change my mind. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Tue, Sep 16, 2014 at 10:26:59PM +0200, Paul Bolle wrote: On Mon, 2014-09-15 at 14:45 -0400, John W. Linville wrote: FYI -- Sergey posted a series to linux-mips on 14 September 2014 that touches the symbol in question. For whatever reason, it is posted there as RFC. Thanks for passing that on. Does this satisfy the interested parties?? In case I qualify as an interested party: resolving this by, in short, making AHB support actually buildable is of course the preferable solution. Whether or not we should drop my patch while waiting for that series to land in linux-next is not my call. But if it hasn't landed by, say, about the time v3.18-rc3 is released I might raise this issue again. I must say that I'm a bit puzzled why people have resisted this rather small cleanup for years. How did having unbuildable AHB support in mainline benefit anyone? Couldn't the revert of this cleanup also be handled out of tree? Note that the revert is only 6 files changed, 3 insertions(+), 294 deletions(-), while the series is 39 files changed, 3911 insertions(+), 10 deletions(-). I think it got added with the notion that the code was coming soon. As you have tried to remove it, the coming soon refrain continued. I'm still inclined to merge your patch. An RFC series posted to another mailing list doesn't really change my mind. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Thu, Sep 11, 2014 at 03:21:46PM -0400, John W. Linville wrote: > On Wed, Sep 10, 2014 at 04:19:21PM +0400, Sergey Ryazanov wrote: > > 2014-09-10 15:36 GMT+04:00, Jiri Slaby : > > > On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: > > >> 2014-09-09 22:27 GMT+04:00, John W. Linville : > > >>> On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: > > >>>> 2014-09-05 15:33 GMT+04:00 Paul Bolle : > > >>>>> Hi Sergey, > > >>>>> > > >>>>> On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: > > >>>>>> 2014-09-05 14:10 GMT+04:00, Paul Bolle : > > >>>>>>> On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > > >>>>>>>> Having this conversation every rc1 is getting a bit silly. Could > > >>>>>>>> Jiri > > >>>>>>>> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > > >>>>>>>> submitted? > > >>>>>>> > > >>>>>>> I waited until rc3. Have you seen any activity on this front? If > > >>>>>>> not, > > >>>>>>> should I resend the patch that removes the code in mainline that > > >>>>>>> depends > > >>>>>>> on ATHEROS_AR231X (ie, AHB bus support)? > > >>>>>>> > > >>>>>> Recent activity always could be found in [1]. Now I finish another > > >>>>>> one > > >>>>>> round of cleanups and have a plan to fix several things (you can > > >>>>>> always find something that you really want to improve). But if you > > >>>>>> insist I could immediately switch to "send upstream" mode. And seems > > >>>>>> that this would be better approach. > > >>>>>> > > >>>>>> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros > > >>>>> > > >>>>> And where can the related PULL requests or patch submissions be found? > > >>>>> > > >>>> I have not sent patches yet, since I thought that it would be easier > > >>>> to cleanup them in openwrt tree and then send them upstream. > > >>> > > >>> That excuse has worn a bit thin. Perhaps Paul should repost his > > >>> removal and you can add a revert to the start of your patch series? > > >>> > > >> As for me, I do not like such flapping > > > > > > Agreed in case what you have is in a good enough shape. You (and also > > > others) can still clean up the code in upstream too. So, if it is > > > mergeable, send it for upstream inclusion now, otherwise I am all for > > > John to apply the Paul's patch. > > > > Two days is the last deadline :) > > > > > The unused code has been a way too long > > > in the tree now. > > > > Code actively used in owrt firmware and its forks. > > Is this code coming or not? When can I expect to see it posted? FYI -- Sergey posted a series to linux-mips on 14 September 2014 that touches the symbol in question. For whatever reason, it is posted there as RFC. Does this satisfy the interested parties?? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-09-14
On Sun, Sep 14, 2014 at 07:24:27AM +0300, Johan Hedberg wrote: > Hi John, > > On Sun, Sep 14, 2014, Johan Hedberg wrote: > > Here are some more patches intended for 3.18. Most of them are cleanups > > or fixes for SMP. The only exception is a fix for BR/EDR L2CAP fixed > > channels which should now work better together with the L2CAP > > information request procedure. > > > > Let me know if there are any issues pulling. Thanks. > > > > Johan > > > > --- > > The following changes since commit 39e90c77637b3892a39f2908aea57539e961c50e: > > > > Bluetooth: 6lowpan: Route packets that are not meant to peer via correct > > device (2014-09-09 15:51:47 +0200) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > > master > > This was supposed to be a reference to the for-upstream branch instead > of master. Both point to the same commit at this moment but it'd be more > convenient if you pull from for-upstream so that the master branch can > continue living on without waiting for the pull to happen. Sorry for the > extra hassle. > > Johan Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-09-14
On Sun, Sep 14, 2014 at 07:24:27AM +0300, Johan Hedberg wrote: Hi John, On Sun, Sep 14, 2014, Johan Hedberg wrote: Here are some more patches intended for 3.18. Most of them are cleanups or fixes for SMP. The only exception is a fix for BR/EDR L2CAP fixed channels which should now work better together with the L2CAP information request procedure. Let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 39e90c77637b3892a39f2908aea57539e961c50e: Bluetooth: 6lowpan: Route packets that are not meant to peer via correct device (2014-09-09 15:51:47 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master This was supposed to be a reference to the for-upstream branch instead of master. Both point to the same commit at this moment but it'd be more convenient if you pull from for-upstream so that the master branch can continue living on without waiting for the pull to happen. Sorry for the extra hassle. Johan Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Thu, Sep 11, 2014 at 03:21:46PM -0400, John W. Linville wrote: On Wed, Sep 10, 2014 at 04:19:21PM +0400, Sergey Ryazanov wrote: 2014-09-10 15:36 GMT+04:00, Jiri Slaby jirisl...@gmail.com: On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: 2014-09-09 22:27 GMT+04:00, John W. Linville linvi...@tuxdriver.com: On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: 2014-09-05 15:33 GMT+04:00 Paul Bolle pebo...@tiscali.nl: Hi Sergey, On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: 2014-09-05 14:10 GMT+04:00, Paul Bolle pebo...@tiscali.nl: On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: Having this conversation every rc1 is getting a bit silly. Could Jiri e.a. perhaps set some specific deadline for ATHEROS_AR231X to be submitted? I waited until rc3. Have you seen any activity on this front? If not, should I resend the patch that removes the code in mainline that depends on ATHEROS_AR231X (ie, AHB bus support)? Recent activity always could be found in [1]. Now I finish another one round of cleanups and have a plan to fix several things (you can always find something that you really want to improve). But if you insist I could immediately switch to send upstream mode. And seems that this would be better approach. 1. https://dev.openwrt.org/log/trunk/target/linux/atheros And where can the related PULL requests or patch submissions be found? I have not sent patches yet, since I thought that it would be easier to cleanup them in openwrt tree and then send them upstream. That excuse has worn a bit thin. Perhaps Paul should repost his removal and you can add a revert to the start of your patch series? As for me, I do not like such flapping Agreed in case what you have is in a good enough shape. You (and also others) can still clean up the code in upstream too. So, if it is mergeable, send it for upstream inclusion now, otherwise I am all for John to apply the Paul's patch. Two days is the last deadline :) The unused code has been a way too long in the tree now. Code actively used in owrt firmware and its forks. Is this code coming or not? When can I expect to see it posted? FYI -- Sergey posted a series to linux-mips on 14 September 2014 that touches the symbol in question. For whatever reason, it is posted there as RFC. Does this satisfy the interested parties?? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Wed, Sep 10, 2014 at 04:19:21PM +0400, Sergey Ryazanov wrote: > 2014-09-10 15:36 GMT+04:00, Jiri Slaby : > > On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: > >> 2014-09-09 22:27 GMT+04:00, John W. Linville : > >>> On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: > >>>> 2014-09-05 15:33 GMT+04:00 Paul Bolle : > >>>>> Hi Sergey, > >>>>> > >>>>> On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: > >>>>>> 2014-09-05 14:10 GMT+04:00, Paul Bolle : > >>>>>>> On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > >>>>>>>> Having this conversation every rc1 is getting a bit silly. Could > >>>>>>>> Jiri > >>>>>>>> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > >>>>>>>> submitted? > >>>>>>> > >>>>>>> I waited until rc3. Have you seen any activity on this front? If > >>>>>>> not, > >>>>>>> should I resend the patch that removes the code in mainline that > >>>>>>> depends > >>>>>>> on ATHEROS_AR231X (ie, AHB bus support)? > >>>>>>> > >>>>>> Recent activity always could be found in [1]. Now I finish another > >>>>>> one > >>>>>> round of cleanups and have a plan to fix several things (you can > >>>>>> always find something that you really want to improve). But if you > >>>>>> insist I could immediately switch to "send upstream" mode. And seems > >>>>>> that this would be better approach. > >>>>>> > >>>>>> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros > >>>>> > >>>>> And where can the related PULL requests or patch submissions be found? > >>>>> > >>>> I have not sent patches yet, since I thought that it would be easier > >>>> to cleanup them in openwrt tree and then send them upstream. > >>> > >>> That excuse has worn a bit thin. Perhaps Paul should repost his > >>> removal and you can add a revert to the start of your patch series? > >>> > >> As for me, I do not like such flapping > > > > Agreed in case what you have is in a good enough shape. You (and also > > others) can still clean up the code in upstream too. So, if it is > > mergeable, send it for upstream inclusion now, otherwise I am all for > > John to apply the Paul's patch. > > Two days is the last deadline :) > > > The unused code has been a way too long > > in the tree now. > > Code actively used in owrt firmware and its forks. Is this code coming or not? When can I expect to see it posted? -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pull request: wireless 2014-09-11
Dave,
Please pull this batch of fixes intended for the 3.17 stream:
For the mac80211 bits, Johannes says:
"Two more fixes for mac80211 - one of them addresses a long-standing
issue that we only found when using vendor events more frequently;
the other addresses some bad information being reported in userspace
that people were starting to actually look at."
For the iwlwifi bits, Emmanuel says:
"I re-enable scheduled scan on firmware that contain the fix for
the bug that Linus reported. A few trivial fixes: endianity issues,
the same DTIM period fix that I did in mac80211. Eyal fixes a few
issues we identified with EAPOL, we now send them just as if they were
management frames, this solves interrop issues. Johannes has another
set of trivial fixes, while Luca fixes the way we configure the filters
in the firmware. Last but not least, a new device is added by Oren."
Emmanuel was traveling, resulting in his pull to be a bit larger than
I would have liked to see at this point. FWIW, I have asked Emmanuel
to be much more strict for any more pull requests in this cycle.
In addition to the above, Sujith Manoharan reverts an earlier ath9k
patch. The earlier change was found to allow for the device to sleep
too long and miss beacons.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 1bd3fa7b8c9b2936c16c6e6452f9cc991c405872:
Merge branch 'for-john' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2014-09-04
13:12:02 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-09-11
for you to fetch changes up to ae0fd6354134e63aa3e62456e2080c430287144d:
Revert "ath9k: Calculate sleep duration" (2014-09-11 14:17:20 -0400)
wireless-testing 2014-09-11
Eliad Peller (1):
iwlwifi: increase DEFAULT_MAX_TX_POWER
Emmanuel Grumbach (5):
iwlwifi: mvm: enable scheduled scan on newest firmware
mac80211: use bss_conf->dtim_period instead of conf.ps_dtim_period
iwlwifi: mvm: fix endianity issues with Smart Fifo commands
iwlwiwi: mvm: use bss_conf->dtim_period instead of conf.ps_dtim_period
iwlwifi: dvm: disable power save by default
Eyal Shapira (2):
iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate
iwlwifi: mvm: fix an overflow in iwl_mvm_get_signal_strength
Johannes Berg (4):
nl80211: clear skb cb before passing to netlink
iwlwifi: mvm: BT Coex - remove shadowing variable
iwlwifi: mvm: correctly handle PM/QoS changes from mac80211
iwlwifi: mvm: BT Coex - always initialize smps_mode
John W. Linville (2):
Merge tag 'mac80211-for-john-2014-09-08' of
git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Luciano Coelho (1):
iwlwifi: mvm: set MAC_FILTER_IN_BEACON correctly for STA/P2P client
Oren Givon (1):
iwlwifi: add PCI IDs and add then new 3165 series
Sujith Manoharan (1):
Revert "ath9k: Calculate sleep duration"
drivers/net/wireless/ath/ath9k/common-beacon.c | 5 ++---
drivers/net/wireless/iwlwifi/dvm/power.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-7000.c| 16
drivers/net/wireless/iwlwifi/iwl-config.h | 3 +++
drivers/net/wireless/iwlwifi/iwl-nvm-parse.c | 4 +---
drivers/net/wireless/iwlwifi/mvm/coex.c| 9 +++--
drivers/net/wireless/iwlwifi/mvm/debugfs-vif.c | 3 +--
drivers/net/wireless/iwlwifi/mvm/fw-api.h | 4 ++--
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c| 10 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c| 25 ++---
drivers/net/wireless/iwlwifi/mvm/power.c | 5 ++---
drivers/net/wireless/iwlwifi/mvm/rx.c | 6 +++---
drivers/net/wireless/iwlwifi/mvm/sf.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/tx.c | 8 ++--
drivers/net/wireless/iwlwifi/pcie/drv.c| 7 +++
net/mac80211/sta_info.c| 2 +-
net/wireless/nl80211.c | 6 ++
17 files changed, 74 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-beacon.c
b/drivers/net/wireless/ath/ath9k/common-beacon.c
index 733be5178481..6ad44470d0f2 100644
--- a/drivers/net/wireless/ath/ath9k/common-beacon.c
+++ b/drivers/net/wireless/ath/ath9k/common-beacon.c
@@ -57,7 +57,7 @@ int ath9k_cmn_beacon_config_sta(struct ath_hw *ah,
struct ath9k_beacon_state *bs)
{
struct ath_common *common = ath9k_hw_common(ah);
- int dtim_intval, sleepduration;
+ int dtim_intval;
u64 tsf;
/* No need to configure beacon if we are not associated */
@@ -75,7 +75,6 @@ int ath9k_cmn_beacon_config_st
pull request: wireless 2014-09-11
Dave,
Please pull this batch of fixes intended for the 3.17 stream:
For the mac80211 bits, Johannes says:
Two more fixes for mac80211 - one of them addresses a long-standing
issue that we only found when using vendor events more frequently;
the other addresses some bad information being reported in userspace
that people were starting to actually look at.
For the iwlwifi bits, Emmanuel says:
I re-enable scheduled scan on firmware that contain the fix for
the bug that Linus reported. A few trivial fixes: endianity issues,
the same DTIM period fix that I did in mac80211. Eyal fixes a few
issues we identified with EAPOL, we now send them just as if they were
management frames, this solves interrop issues. Johannes has another
set of trivial fixes, while Luca fixes the way we configure the filters
in the firmware. Last but not least, a new device is added by Oren.
Emmanuel was traveling, resulting in his pull to be a bit larger than
I would have liked to see at this point. FWIW, I have asked Emmanuel
to be much more strict for any more pull requests in this cycle.
In addition to the above, Sujith Manoharan reverts an earlier ath9k
patch. The earlier change was found to allow for the device to sleep
too long and miss beacons.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 1bd3fa7b8c9b2936c16c6e6452f9cc991c405872:
Merge branch 'for-john' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2014-09-04
13:12:02 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-09-11
for you to fetch changes up to ae0fd6354134e63aa3e62456e2080c430287144d:
Revert ath9k: Calculate sleep duration (2014-09-11 14:17:20 -0400)
wireless-testing 2014-09-11
Eliad Peller (1):
iwlwifi: increase DEFAULT_MAX_TX_POWER
Emmanuel Grumbach (5):
iwlwifi: mvm: enable scheduled scan on newest firmware
mac80211: use bss_conf-dtim_period instead of conf.ps_dtim_period
iwlwifi: mvm: fix endianity issues with Smart Fifo commands
iwlwiwi: mvm: use bss_conf-dtim_period instead of conf.ps_dtim_period
iwlwifi: dvm: disable power save by default
Eyal Shapira (2):
iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate
iwlwifi: mvm: fix an overflow in iwl_mvm_get_signal_strength
Johannes Berg (4):
nl80211: clear skb cb before passing to netlink
iwlwifi: mvm: BT Coex - remove shadowing variable
iwlwifi: mvm: correctly handle PM/QoS changes from mac80211
iwlwifi: mvm: BT Coex - always initialize smps_mode
John W. Linville (2):
Merge tag 'mac80211-for-john-2014-09-08' of
git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Luciano Coelho (1):
iwlwifi: mvm: set MAC_FILTER_IN_BEACON correctly for STA/P2P client
Oren Givon (1):
iwlwifi: add PCI IDs and add then new 3165 series
Sujith Manoharan (1):
Revert ath9k: Calculate sleep duration
drivers/net/wireless/ath/ath9k/common-beacon.c | 5 ++---
drivers/net/wireless/iwlwifi/dvm/power.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-7000.c| 16
drivers/net/wireless/iwlwifi/iwl-config.h | 3 +++
drivers/net/wireless/iwlwifi/iwl-nvm-parse.c | 4 +---
drivers/net/wireless/iwlwifi/mvm/coex.c| 9 +++--
drivers/net/wireless/iwlwifi/mvm/debugfs-vif.c | 3 +--
drivers/net/wireless/iwlwifi/mvm/fw-api.h | 4 ++--
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c| 10 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c| 25 ++---
drivers/net/wireless/iwlwifi/mvm/power.c | 5 ++---
drivers/net/wireless/iwlwifi/mvm/rx.c | 6 +++---
drivers/net/wireless/iwlwifi/mvm/sf.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/tx.c | 8 ++--
drivers/net/wireless/iwlwifi/pcie/drv.c| 7 +++
net/mac80211/sta_info.c| 2 +-
net/wireless/nl80211.c | 6 ++
17 files changed, 74 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-beacon.c
b/drivers/net/wireless/ath/ath9k/common-beacon.c
index 733be5178481..6ad44470d0f2 100644
--- a/drivers/net/wireless/ath/ath9k/common-beacon.c
+++ b/drivers/net/wireless/ath/ath9k/common-beacon.c
@@ -57,7 +57,7 @@ int ath9k_cmn_beacon_config_sta(struct ath_hw *ah,
struct ath9k_beacon_state *bs)
{
struct ath_common *common = ath9k_hw_common(ah);
- int dtim_intval, sleepduration;
+ int dtim_intval;
u64 tsf;
/* No need to configure beacon if we are not associated */
@@ -75,7 +75,6 @@ int ath9k_cmn_beacon_config_sta(struct ath_hw *ah,
* last beacon we received
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Wed, Sep 10, 2014 at 04:19:21PM +0400, Sergey Ryazanov wrote: 2014-09-10 15:36 GMT+04:00, Jiri Slaby jirisl...@gmail.com: On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: 2014-09-09 22:27 GMT+04:00, John W. Linville linvi...@tuxdriver.com: On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: 2014-09-05 15:33 GMT+04:00 Paul Bolle pebo...@tiscali.nl: Hi Sergey, On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: 2014-09-05 14:10 GMT+04:00, Paul Bolle pebo...@tiscali.nl: On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: Having this conversation every rc1 is getting a bit silly. Could Jiri e.a. perhaps set some specific deadline for ATHEROS_AR231X to be submitted? I waited until rc3. Have you seen any activity on this front? If not, should I resend the patch that removes the code in mainline that depends on ATHEROS_AR231X (ie, AHB bus support)? Recent activity always could be found in [1]. Now I finish another one round of cleanups and have a plan to fix several things (you can always find something that you really want to improve). But if you insist I could immediately switch to send upstream mode. And seems that this would be better approach. 1. https://dev.openwrt.org/log/trunk/target/linux/atheros And where can the related PULL requests or patch submissions be found? I have not sent patches yet, since I thought that it would be easier to cleanup them in openwrt tree and then send them upstream. That excuse has worn a bit thin. Perhaps Paul should repost his removal and you can add a revert to the start of your patch series? As for me, I do not like such flapping Agreed in case what you have is in a good enough shape. You (and also others) can still clean up the code in upstream too. So, if it is mergeable, send it for upstream inclusion now, otherwise I am all for John to apply the Paul's patch. Two days is the last deadline :) The unused code has been a way too long in the tree now. Code actively used in owrt firmware and its forks. Is this code coming or not? When can I expect to see it posted? -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the wireless-next tree
On Tue, Sep 09, 2014 at 04:37:33PM -0700, David Miller wrote: > From: Stephen Rothwell > Date: Wed, 10 Sep 2014 09:28:19 +1000 > > > Hi Dave, > ... > > This fix patch is now needed in the net-next tree ... > > Applied thanks Stephen. Doh! Sorry I missed that one... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the wireless-next tree
On Tue, Sep 09, 2014 at 04:37:33PM -0700, David Miller wrote: From: Stephen Rothwell s...@canb.auug.org.au Date: Wed, 10 Sep 2014 09:28:19 +1000 Hi Dave, ... This fix patch is now needed in the net-next tree ... Applied thanks Stephen. Doh! Sorry I missed that one... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-09-09
On Tue, Sep 09, 2014 at 08:54:49AM -0700, Johan Hedberg wrote: > Hi John, > > This set of patches is intended for 3.18. Most of the patches are LE SMP > (Security Manager Protocol) fixes/improvements, but there are also some > 6lowpan fixes as well as a fix for the btusb HCI driver. > > Please let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 61a3d4f9d52c00b2016bc27fc66b10a194043f76: > > Merge branch 'master' of > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2014-09-08 > 11:14:56 -0400) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > for-upstream > > for you to fetch changes up to 39e90c77637b3892a39f2908aea57539e961c50e: > > Bluetooth: 6lowpan: Route packets that are not meant to peer via correct > device (2014-09-09 15:51:47 +0200) > > > Behan Webster (1): > Bluetooth: LLVMLinux: Remove VLAIS from bluetooth/amp.c > > Champion Chen (1): > Bluetooth: Fix issue with USB suspend in btusb driver > > Johan Hedberg (31): > Bluetooth: Fix incorrect LE CoC PDU length restriction based on HCI MTU > Bluetooth: Remove unnecessary l2cap_chan_unlock before l2cap_chan_add > Bluetooth: Fix hci_conn reference counting for fixed channels > Bluetooth: Set addr_type only when it's needed > Bluetooth: Optimize connection parameter lookup for LE connections > Bluetooth: Improve *_get() functions to return the object type > Bluetooth: Fix using hci_conn_get() for hci_conn pointers > Bluetooth: Refactor connection parameter freeing into its own function > Bluetooth: Use zero timeout for immediate scheduling > Bluetooth: Fix hci_conn reference counting with hci_chan > Bluetooth: Set disc_timeout to 0 when calling hci_chan_del > Bluetooth: Ignore incoming data after initiating disconnection > Bluetooth: Remove hci_conn_hold/drop from hci_chan > Bluetooth: Set discon_timeout to 0 in l2cap_conn_del > Bluetooth: Use hci_disconnect for immediate disconnection from SMP > Bluetooth: Remove unused l2cap_conn_shutdown API > Bluetooth: Fix SMP error and response to be mutually exclusive > Bluetooth: Update hci_disconnect() to return an error value > Bluetooth: Use hci_disconnect() for mgmt_disconnect_device() > Bluetooth: Move clock offset reading into hci_disconnect() > Bluetooth: Add clarifying comment for LE CoC result value > Bluetooth: Remove unnecessary checks after canceling SMP security timer > Bluetooth: Don't take any action in smp_resume_cb if not encrypted > Bluetooth: Move identity address update behind a workqueue > Bluetooth: Remove unnecessary deferred work for SMP key distribution > Bluetooth: Fix locking of the SMP context > Bluetooth: Add define for key distribution mask > Bluetooth: Fix calling smp_distribute_keys() when still waiting for keys > Bluetooth: Add strict checks for allowed SMP PDUs > Bluetooth: Fix dereferencing conn variable before NULL check > Bluetooth: Fix mgmt pairing failure when authentication fails > > Jukka Rissanen (3): > Bluetooth: 6lowpan: Increase the connection timeout value > Bluetooth: 6lowpan: Set the peer IPv6 address correctly > Bluetooth: 6lowpan: Route packets that are not meant to peer via > correct device Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: > 2014-09-05 15:33 GMT+04:00 Paul Bolle : > > Hi Sergey, > > > > On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: > >> 2014-09-05 14:10 GMT+04:00, Paul Bolle : > >> > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > >> >> Having this conversation every rc1 is getting a bit silly. Could Jiri > >> >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > >> >> submitted? > >> > > >> > I waited until rc3. Have you seen any activity on this front? If not, > >> > should I resend the patch that removes the code in mainline that depends > >> > on ATHEROS_AR231X (ie, AHB bus support)? > >> > > >> Recent activity always could be found in [1]. Now I finish another one > >> round of cleanups and have a plan to fix several things (you can > >> always find something that you really want to improve). But if you > >> insist I could immediately switch to "send upstream" mode. And seems > >> that this would be better approach. > >> > >> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros > > > > And where can the related PULL requests or patch submissions be found? > > > I have not sent patches yet, since I thought that it would be easier > to cleanup them in openwrt tree and then send them upstream. That excuse has worn a bit thin. Perhaps Paul should repost his removal and you can add a revert to the start of your patch series? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/28] Remove ATHEROS_AR231X
On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: 2014-09-05 15:33 GMT+04:00 Paul Bolle pebo...@tiscali.nl: Hi Sergey, On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: 2014-09-05 14:10 GMT+04:00, Paul Bolle pebo...@tiscali.nl: On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: Having this conversation every rc1 is getting a bit silly. Could Jiri e.a. perhaps set some specific deadline for ATHEROS_AR231X to be submitted? I waited until rc3. Have you seen any activity on this front? If not, should I resend the patch that removes the code in mainline that depends on ATHEROS_AR231X (ie, AHB bus support)? Recent activity always could be found in [1]. Now I finish another one round of cleanups and have a plan to fix several things (you can always find something that you really want to improve). But if you insist I could immediately switch to send upstream mode. And seems that this would be better approach. 1. https://dev.openwrt.org/log/trunk/target/linux/atheros And where can the related PULL requests or patch submissions be found? I have not sent patches yet, since I thought that it would be easier to cleanup them in openwrt tree and then send them upstream. That excuse has worn a bit thin. Perhaps Paul should repost his removal and you can add a revert to the start of your patch series? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-09-09
On Tue, Sep 09, 2014 at 08:54:49AM -0700, Johan Hedberg wrote: Hi John, This set of patches is intended for 3.18. Most of the patches are LE SMP (Security Manager Protocol) fixes/improvements, but there are also some 6lowpan fixes as well as a fix for the btusb HCI driver. Please let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 61a3d4f9d52c00b2016bc27fc66b10a194043f76: Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2014-09-08 11:14:56 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 39e90c77637b3892a39f2908aea57539e961c50e: Bluetooth: 6lowpan: Route packets that are not meant to peer via correct device (2014-09-09 15:51:47 +0200) Behan Webster (1): Bluetooth: LLVMLinux: Remove VLAIS from bluetooth/amp.c Champion Chen (1): Bluetooth: Fix issue with USB suspend in btusb driver Johan Hedberg (31): Bluetooth: Fix incorrect LE CoC PDU length restriction based on HCI MTU Bluetooth: Remove unnecessary l2cap_chan_unlock before l2cap_chan_add Bluetooth: Fix hci_conn reference counting for fixed channels Bluetooth: Set addr_type only when it's needed Bluetooth: Optimize connection parameter lookup for LE connections Bluetooth: Improve *_get() functions to return the object type Bluetooth: Fix using hci_conn_get() for hci_conn pointers Bluetooth: Refactor connection parameter freeing into its own function Bluetooth: Use zero timeout for immediate scheduling Bluetooth: Fix hci_conn reference counting with hci_chan Bluetooth: Set disc_timeout to 0 when calling hci_chan_del Bluetooth: Ignore incoming data after initiating disconnection Bluetooth: Remove hci_conn_hold/drop from hci_chan Bluetooth: Set discon_timeout to 0 in l2cap_conn_del Bluetooth: Use hci_disconnect for immediate disconnection from SMP Bluetooth: Remove unused l2cap_conn_shutdown API Bluetooth: Fix SMP error and response to be mutually exclusive Bluetooth: Update hci_disconnect() to return an error value Bluetooth: Use hci_disconnect() for mgmt_disconnect_device() Bluetooth: Move clock offset reading into hci_disconnect() Bluetooth: Add clarifying comment for LE CoC result value Bluetooth: Remove unnecessary checks after canceling SMP security timer Bluetooth: Don't take any action in smp_resume_cb if not encrypted Bluetooth: Move identity address update behind a workqueue Bluetooth: Remove unnecessary deferred work for SMP key distribution Bluetooth: Fix locking of the SMP context Bluetooth: Add define for key distribution mask Bluetooth: Fix calling smp_distribute_keys() when still waiting for keys Bluetooth: Add strict checks for allowed SMP PDUs Bluetooth: Fix dereferencing conn variable before NULL check Bluetooth: Fix mgmt pairing failure when authentication fails Jukka Rissanen (3): Bluetooth: 6lowpan: Increase the connection timeout value Bluetooth: 6lowpan: Set the peer IPv6 address correctly Bluetooth: 6lowpan: Route packets that are not meant to peer via correct device Pulling now... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
