Re: [PATCH] ell:: build: bump SO version of libell

Hi Kalle, >> Commit 0.13-7-g4a386a1 changed the ABI of l_signal_create. This >> warrants a bump in the SO version. >> --- >> Makefile.am | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/Makefile.am b/Makefile.am >> index d115360..5a44f40 100644 >> --- a/Makefile.am

Re: RFkill for Bluetooth hard reset

Hi Sukumar, >>> We need an option to reset Bluetooth using GPIO toggle for a Linux >>> product when BT connected over USB (HCI interface). i.e I need out of >>> band(OOB) signal for USB to control/reset the BT. hence I opt to add >>> ACPI device in RfKill gpio driver(rfkill-gpio.c). >>> >>>

Re: RFkill for Bluetooth hard reset

Hi Sukumar, > We need an option to reset Bluetooth using GPIO toggle for a Linux product > when > BT connected over USB (HCI interface). i.e I need out of band(OOB) signal for > USB to control/reset the BT. hence I opt to add ACPI device in RfKill gpio > driver(rfkill-gpio.c). > > localhost

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

; drivers/bluetooth/Kconfig| 4 +--- > drivers/net/wireless/rsi/Kconfig | 4 +++- > 2 files changed, 4 insertions(+), 4 deletions(-) Acked-by: Marcel Holtmann <mar...@holtmann.org> Since I think Kalle still has to take it through his tree until the btrsi driver makes it into net-next. Regards Marcel

Re: [PATCH] Bluetooth: btrsi: rework dependencies

Hi Arnd, >>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile >>> index 03cfc1b20c4a..9e8d22712ff3 100644 >>> --- a/drivers/bluetooth/Makefile >>> +++ b/drivers/bluetooth/Makefile >>> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)+= btqca.o >>> >>>

Re: [PATCH] Bluetooth: btrsi: rework dependencies

Hi Arnd, > The linkage between the bluetooth driver and the wireless > driver is not defined properly, leading to build problems > such as: > > warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies > (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) >

Re: [2/3] mwifiex: support sysfs initiated device coredump

Hi Arend, > Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") > it is possible to initiate a device coredump from user-space. This > patch adds support for it adding the .coredump() driver callback. > As there is no longer a need to initiate it through debugfs

Re: [PATCH 1/2] cfg80211: Add support to enable or disable btcoex

Hi Arend, This patch introduces NL80211_CMD_SET_BTCOEX command and NL80211_ATTR_BTCOEX_OP attribute to enable or disable btcoex. >>> >>> What kind of btcoex are we talking about here? Is it signalling >>> between wlan and bt to get access to the shared RF. >> >> Yes, at least that's

Re: [PATCH 3/3] btmrvl: support sysfs initiated firmware coredump

Hi Arend, > Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") > it is possible to initiate a device coredump from user-space. This > patch adds support for it in btmrvl_sdio adding the .coredump() > driver callback. This makes dump through debugfs obsolete so removing > it. >

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi Carlo, >> Great, thanks for all the info! I'll definitely keep you CC'ed on my >> progress. I'm still very new to kernel development so I expect it'll >> take me quite a while, but I do have a fair bit of time to devote to >> this. > > Welcome to this crazy world ;) > Keep me on CC also, I

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi Martin, Is this for devices with a RTL8723BS chip? If so then they still will not work after this since there also no longer is a /dev/ttyS4 created for the UART for the bluetooth, instead you probably want:

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi Carlo, >> Is this for devices with a RTL8723BS chip? If so then they >> still will not work after this since there also no longer is >> a /dev/ttyS4 created for the UART for the bluetooth, instead >> you probably want: >> >>

Re: [RFC PATCH 0/2] net: rfkill: gpio: Fix and support SerDev

Hi Hans, > Is this for devices with a RTL8723BS chip? If so then they > still will not work after this since there also no longer is > a /dev/ttyS4 created for the UART for the bluetooth, instead > you probably want: > it is not for that hardware, it is for some GPS devices. static const

Re: [RFC PATCH 2/2] net: rfkill: gpio: Convert driver to SerDev

Hi Carlo, > With commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART > devices") UART devices are now expected to be enumerated by > SerDev subsystem. This is breaking the enumeration of platform devices > connected to the UART without a proper SerDev support, like in the >

Re: [v5 7/8] rsi: add module parameter operating mode

Hi Kalle, >> Operating mode determines the support for other protocols. >> This is made as module parameter for better usage. >> >> Signed-off-by: Prameela Rani Garnepudi >> Signed-off-by: Siva Rebbagondla >> Signed-off-by:

Re: [v5 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

t(rsi_91x_bt_module_init); >>> +module_exit(rsi_91x_bt_module_exit); >>> +MODULE_AUTHOR("Redpine Signals Inc"); >>> +MODULE_DESCRIPTION("RSI BT driver"); >>> +MODULE_SUPPORTED_DEVICE("RSI-BT"); >>> +MODULE_LICENSE("Dual BSD/GPL”);

Re: [PATCH 1/2] cfg80211/nl80211: Optional authentication offload to userspace

Hi Jouni, > This interface allows the host driver to offload the authentication to > user space. This is exclusively defined for host drivers that do not > define separate commands for authentication and association, but rely on > userspace SME (e.g., in wpa_supplicant for the

Re: [PATCH] nl80211: Introduce scan flags to emphasize requested scan behavior

Hi Jouni, > This commit defines new scan flags (LOW_SPAN, LOW_POWER, HIGH_LATENCY) > to emphasize the requested scan behavior for the driver. These flags are > optional and are mutually exclusive. Driver shall resort to default > behavior if a respective flag is not supported. The implementation

Re: [v4 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

Hi Amitkumar, >>> Redpine bluetooth driver is a thin driver which depends on >>> 'rsi_91x' driver for transmitting and receiving packets >>> to/from device. It creates hci interface when attach() is >>> called from 'rsi_91x' module. >>> >>> Signed-off-by: Prameela Rani Garnepudi

Re: [v5 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

+ if (!h_adapter) > + return; > + > + hdev = h_adapter->hdev; > + if (hdev) { > + hci_unregister_dev(hdev); > + hci_free_dev(hdev); > + h_adapter->hdev = NULL; > + } > + > + kfree(h_adapter

Re: [v4 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

Hi Amitkumar, > Redpine bluetooth driver is a thin driver which depends on > 'rsi_91x' driver for transmitting and receiving packets > to/from device. It creates hci interface when attach() is > called from 'rsi_91x' module. > > Signed-off-by: Prameela Rani Garnepudi >

Re: [v3 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

Hi Amitkumar, > Redpine bluetooth driver is a thin driver which depends on > 'rsi_91x' driver for transmitting and receiving packets > to/from device. It creates hci interface when attach() is > called from 'rsi_91x' module. > > Signed-off-by: Prameela Rani Garnepudi >

Re: [PATCH 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

Hi Amitkumar, >>> Redpine bluetooth driver is a thin driver which depends on >>> 'rsi_91x' driver for transmitting and receiving packets >>> to/from device. It creates hci interface when attach() is >>> called from 'rsi_91x' module. >>> >>> Signed-off-by: Prameela Rani Garnepudi

Re: [PATCH 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

Hi Amitkumar, > Redpine bluetooth driver is a thin driver which depends on > 'rsi_91x' driver for transmitting and receiving packets > to/from device. It creates hci interface when attach() is > called from 'rsi_91x' module. > > Signed-off-by: Prameela Rani Garnepudi >

Re: [PATCH 2/8] rsi: add bluetooth rx endpoint

Hi Amitkumar, > USB endpoint 1 is used for WLAN which is presently in use. > USB endpoint 2 is introduced for BT Rx traffic. Enumeration > of Rx BT endpoint and submitting Rx BT URB are added. wouldn’t it be good to include the /sys/kernel/debug/usb/devices part here that shows how the USB

Re: New Realtek driver

Hi Larry, > Once again I find myself in the awkward position of needing to submit code to > two different trees, i.e. wireless and staging. > > The code in question concerns a new Realtek device, the RTL8822BE. The device > is already shipping, and Realtek would like it to be available in

Re: Request to add bluetooth module identifier to net/rfkill/rfkill-gpio.c

Hi Sundar, > I have a Cherry Trail laptop with an Atom X5-Z8300. It has a bluetooth > chip that needs the r8723bs (coexisting RTL 8723BS wifi and > bluetooth). > > I am using linux-next (20150817) with the r8723bs staging driver and > the firmware and utility from

Re: [PATCHv2 0/4] Motorola Droid 4: Add WL1285C support

Hi Rob, >> Motorola Droid 4 uses a WL1285C, as visible on iFixit [0]. This >> fixes the DT file to use correct compatible for the wifi node >> and adds the bluetooth node. >> >> [0] https://www.ifixit.com/Teardown/Motorola+Droid+4+Teardown/7759#s31961 >> >> Changes to PATCHv1: >> - use proper

Re: [linux-nfc] [[PATCH v1] 0/6] Support of ST NFC Transceiver

Hi Shikha, > *** V1.0 *** > This patch series is generated on top of latest > code available on nfc-next. > > This patch series introduces the following features: > > (a) A generic Digital NFC UART framework. > The framework itself is an LDISC registered > with the tty core. Any NFC transciever

Re: [RFC 1/3] bpf/wireless: add wifimon program type

Hi Johannes, > Add a new program type for wifi monitor interfaces. This program > type can > * access __sk_buff, but only skb->len > * call bpf_skb_load_bytes() > > The program type is only enabled when something selects the new > Kconfig symbol WANT_BPF_WIFIMON, which will be done by mac80211 >

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

Hi Larry, > The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets > for bluetooth rfkill functionality. > > Tested-by: russianneuroman...@ya.ru > Signed-off-by: Hans de Goede > --- >

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

Hi Hans, >>> The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets >>> for bluetooth rfkill functionality. >>> >>> Tested-by: russianneuroman...@ya.ru >>> Signed-off-by: Hans de Goede >>> --- >>> net/rfkill/rfkill-gpio.c | 1 + >>> 1

Re: [PATCH] net: rfkill: gpio: Add OBDA8723 ACPI HID

Hi Hans, > The OBDA8723 ACPI HID is used on quite a few Bay Trail based tablets > for bluetooth rfkill functionality. > > Tested-by: russianneuroman...@ya.ru > Signed-off-by: Hans de Goede > --- > net/rfkill/rfkill-gpio.c | 1 + > 1 file changed, 1

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

Hi Dave, >> By moving these client drivers to use RPMSG instead of the direct SMD >> API we can reuse them ontop of the newly added GLINK wire-protocol >> support found in the 820 and 835 Qualcomm platforms. >> >> As the new (RPMSG-based) and old SMD implementations are mutually >> exclusive we

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

files changed, 108 insertions(+), 104 deletions(-) I think that it is best if Dave takes these directly then and I pull them back down later into our trees. Including the Kconfig fix that I will ACK as well. Acked-by: Marcel Holtmann <mar...@holtmann.org> Regards Marcel

Re: [PATCH] NFC: remove TI nfcwilink driver

Hi Rob, >>> It appears that TI WiLink devices including NFC (WL185x/WL189x) never >>> shipped. The only information I found were announcements in Feb >>> 2012 about the parts. There's been no activity on this driver besided >>> common changes since initially added in Jan 2012. There's also no in

Re: [PATCH] NFC: remove TI nfcwilink driver

Hi Rob, > It appears that TI WiLink devices including NFC (WL185x/WL189x) never > shipped. The only information I found were announcements in Feb > 2012 about the parts. There's been no activity on this driver besided > common changes since initially added in Jan 2012. There's also no in > users

Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

e| 2 -- > net/wireless/Makefile | 2 -- > 38 files changed, 5 insertions(+), 68 deletions(-) for drivers/bluetooth, net/bluetooth, net/ieee802154 and net/mac802154 Acked-by: Marcel Holtmann <mar...@holtmann.org> Regards Marcel

Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT

Hi Johannes, >>> Well, no, that'd only work with an open connection :) > > Actually, it also works fairly easily for when firmware has 4-way- > handshake offload, which will be coming to a kernel near you soon. > >> And even that is questionable in my mind for some of the more >> advanced

Re: [PATCH 1/2] wcn36xx: Correct Kconfig dependency

Hi Bjorn, > In the case SMD or WCNSS_CTRL are compiled as modules, wcn36xx must be > compiled as module as well, so we need to mention this dependency. > But we still want allow the driver to be compiled in case either of > those are =n, for compile testing reasons. > > Signed-off-by: Bjorn

Re: rfkill guidance

Hi Johannes, >> Today we already have all the platform rfkill instances (like the >> various ACPI ones) that don't live off a device that they control, >> but instead control the platform's radio functionality. And in some >> cases, that actually has very similar behaviour to what was proposed >>

Re: [PATCH] rtlbt: Add RTL8822BE Bluetooth device

Hi Larry, > The RTL8822BE is a new Realtek wifi and BT device. Support for the BT > part is hereby added. > > As this device is similar to most of the other Realtek BT devices, the > changes are minimal. The main difference is that the 8822BE needs a > configuration file for enabling and

Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

Hi Kalle, >> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD >> channel, as such it should be a SMD client. This patch makes this >> transition, now that we have the necessary frameworks available. >> >> Signed-off-by: Bjorn Andersson > > [...] >

Re: [RFC] rfkill: Add new ACPI device for Realtek serial BT

Hi Larry, > The Realtek RTL8723BS chips, which are connected via SDIO, also contain > a serial Bluetooth device. In order for BT to work, the device must be > added to the acpi_device_id table. > > Signed-off-by: Larry Finger > --- > > I have no idea if this device

Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

Hi Geert, > On mips and parisc: > >drivers/bluetooth/btwilink.c: In function 'ti_st_open': >drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit > constant conversion [-Woverflow] > hst->reg_status = -EINPROGRESS; > >drivers/nfc/nfcwilink.c: In function

Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

Hi Mauro, >> On mips and parisc: >> >>drivers/bluetooth/btwilink.c: In function 'ti_st_open': >>drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit >> constant conversion [-Woverflow] >> hst->reg_status = -EINPROGRESS; >> >>drivers/nfc/nfcwilink.c: In function

Re: [RFC v2 1/3] nl80211: Add nl80211_notify_iface

Hi Julian, > This function emits NL80211_CMD_NEW_INTERFACE or > NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core > to notify userspace applications such as wpa_supplicant when a netdev > related to a wireless device has been added or removed. > >

Re: [RFC v2 1/3] nl80211: Add nl80211_notify_iface

Hi Arend, >>> This function emits NL80211_CMD_NEW_INTERFACE or >>> NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core >>> to notify userspace applications such as wpa_supplicant when a netdev >>> related to a wireless device has been added or removed. >>> >>> Signed-off-by:

Re: [RFC v2 1/3] nl80211: Add nl80211_notify_iface

Hi Denis, > This function emits NL80211_CMD_NEW_INTERFACE or > NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core > to notify userspace applications such as wpa_supplicant when a netdev > related to a wireless device has been added or removed. > > Signed-off-by: Denis

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

Hi Joa Paulo, > Provide an interface for the airplane-mode indicator be controlled from > userspace. User has to first acquire the control through > RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time > it wants to be in control of the indicator. Closing the fd or using >

Re: [PATCH 15/26] Bluetooth: Use skcipher and hash

Hi Herbert, > This patch replaces uses of blkcipher with skcipher and the long > obsolete hash interface with shash. > > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> Acked-by: Marcel Holtmann <mar...@holtmann.org> > --- >

Re: [PATCH] net/rfkill: Create "airplane mode" LED trigger

Hi Joao, > For platform drivers to be able to correctly drive the "Airplane Mode" > indicative LED there needs to be a RFKill LED trigger tied to the global > state of RFKILL_TYPE_ALL (instead of to a specific RFKill) and that > works in an inverted manner of regular RFKill LED triggers, that is,

Re: [PATCH] net: rfkill-gpio: more ACPI IDs for BCM Blutooth modules

Hi Heikki, > These are used with BCM43241 Wi-Fi/Bluetooth Combo Device. > > Signed-off-by: Heikki Krogerus > --- > net/rfkill/rfkill-gpio.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c > index

Re: [PATCH] rfkill: Copy "all" global state to other types

gt;>> Signed-off-by: João Paulo Rechi Vita <jprv...@endlessm.com> >>> --- >>> net/rfkill/core.c | 9 ++++- >>> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> Acked-by: Marcel Holtmann <mar...@holtmann.org> >> > > Any feed

Re: [PATCH] rfkill: Copy all global state to other types

...@endlessm.com --- net/rfkill/core.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) Acked-by: Marcel Holtmann mar...@holtmann.org Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo

Re: Interaction issue of intel wifi and broadcom bluetooth - it appears that nobody feels responsible for doing something

Hi Arend, thanks for responding! I did have my mobile phone very nearby also connected to the bluetooth headphones while my laptop was still using 11n wifi. I didn't have any noticeable issues with bluetooth there. But I got the feeling that my phone's android drivers + hardware for

Re: btcoex subsystem

Hi Kalle, I will work on combining the latest BT drivers from Realtek with btusb to see if I can achieve a patch that will both work with the Realtek hardware, and get approval from the reviewers. What would be an approved method of communicating between two kernel modules? Is there some

Re: [PATCH V2 5/6] rtlwifi: btcoexist: Add routines for RTL8812AE kernel socket communications

Hi Larry, I'm adding bluetooth list to the discussion. Full patch is available here: https://patchwork.kernel.org/patch/5712591/ snip So the wireless driver communicates with the bluetooth driver (which is not in upstream) via a localhost UDP connection? I think the first order of

Re: [PATCH V2 5/6] rtlwifi: btcoexist: Add routines for RTL8812AE kernel socket communications

Hi Kalle, I'm adding bluetooth list to the discussion. Full patch is available here: https://patchwork.kernel.org/patch/5712591/ Larry Finger larry.fin...@lwfinger.net writes: From: Troy Tan troy_...@realsil.com.cn This patch adds the routines used to communicate between the

Re: [PATCH] nl80211: don't document per-wiphy interface dump

Hi Johannes, Such a feature doesn't exist and isn't really needed since you probably won't have enough interfaces to make it worthwhile, so just remove that from the documentation. Signed-off-by: Johannes Berg johannes.b...@intel.com --- include/uapi/linux/nl80211.h | 4 ++-- 1 file

Re: changes to Linux wireless maintenance

Hi John, Almost 9 years ago, Jeff Garzik wrote a message on LKML detailing the sad state of wireless LANs in the Linux world. The point of his message was So... there it is. We suck. There's hope. No Luke Skywalker in sight.: https://lkml.org/lkml/2006/1/5/671 Shortly

Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

Hi Johannes, have we considered also exposing the mode of this netdev. So for example sta,ap,p2p-go,p2p-client etc. If we can send dynamic updates via RTNL, we could easily tell the networking management system what type of wireless device we have here. I am thinking about it like

Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0 wlan Signed-off-by: Vadim Kochan vadi...@gmail.com --- net/wireless/core.c | 6 ++ 1 file changed, 6 insertions(+) for what its worth. Acked-by: Marcel Holtmann mar...@holtmann.org Regards Marcel

Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

Hi Johannes, On Dec 9, 2014, at 23:21, Vadim Kochan vadi...@gmail.com wrote: It allows to identify the wlan kind of device for the user application, e.g.: # ip -d link 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default

Re: wl1251: NVS firmware data

Hi Pali, On Saturday 06 December 2014 13:49:54 Pavel Machek wrote: /** + * request_firmware_prefer_user: - prefer usermode helper for loading firmware + * @firmware_p: pointer to firmware image + * @name: name of firmware file + * @device: device for which firmware is being loaded + *

Re: wl1251: NVS firmware data

Hi Pali, On Saturday 06 December 2014 13:49:54 Pavel Machek wrote: /** + * request_firmware_prefer_user: - prefer usermode helper for loading firmware + * @firmware_p: pointer to firmware image + * @name: name of firmware file + * @device: device for which firmware is being loaded + *

Re: wl1251: NVS firmware data

Hi Pali, On Saturday 06 December 2014 13:49:54 Pavel Machek wrote: /** + * request_firmware_prefer_user: - prefer usermode helper for loading firmware + * @firmware_p: pointer to firmware image + * @name: name of firmware file + * @device: device for which firmware is being loaded + *

Re: wl1251: NVS firmware data

Hi Pali, On Saturday 06 December 2014 13:49:54 Pavel Machek wrote: /** + * request_firmware_prefer_user: - prefer usermode helper for loading firmware + * @firmware_p: pointer to firmware image + * @name: name of firmware file + * @device: device for which firmware is being loaded + *

Re: wl1251: NVS firmware data

Hi Dan, a) change driver to prefer a new wl1251-nvs-n900.bin file, but fall back to wl1251-nvs.bin if the first one isn't present b) have a wl1251-cal-nvs-update service that, if wl1521-nvs-n900.bin is *not* present mounts the CAL MTD, reads the data, writes it out into wl1521-nvs-n900.bin,

Re: wl1251: NVS firmware data

Hi Pali, Use your own custom usermode helper for stuff like this, not the firmware interface. But use a binary sysfs file if you want, that seems to make sense for it... greg k-h Patch for telling permanent mac address from userspace via sysfs file was rejected for inclusion into

Re: [PATCH] mac80211: Supporting of IFLA_INFO_KIND rtnl attribute

Hi Vadim, It allows to identify the wireless kind of device for the user application, e.g.: # ip -d link 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 2:

Re: [PATCH v2] ath3k: Add support of MCI 13d3:3408 bt device

Hi Dmitry, Add support for bluetooth MCI WB335 (AR9565) Wi-Fi+bt module. It is AR3011 device according to iProduct == 0. So btusb should be blacklisted I submitted a wrong patch before asif it was an AR3012 device, but it works both ways. This is the right one. include the device details

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

Hi Johannes, I've updated wireless code on RHEL and get complain that now cfg80211 and rfkill modules are loaded on machines that do not have wireless hardware. Modules are auto-loaded because NetworkManager send nl80211 messages to check if there are wireless devices in the system. Hence

Re: [PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

: Marcel Holtmann mar...@holtmann.org Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com --- net/wireless/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/wireless/core.c b/net/wireless/core.c index a4d2792..badcabe 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -34,7

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

Hi Luca, I've updated wireless code on RHEL and get complain that now cfg80211 and rfkill modules are loaded on machines that do not have wireless hardware. Modules are auto-loaded because NetworkManager send nl80211 messages to check if there are wireless devices in the system. Hence my

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

Hi Dan, I've updated wireless code on RHEL and get complain that now cfg80211 and rfkill modules are loaded on machines that do not have wireless hardware. Modules are auto-loaded because NetworkManager send nl80211 messages to check if there are wireless devices in the system. Hence my

Re: Tun/tap-variant for 802.15.4/6lowpan?

Hi Henning, I am working with a external radio module controlled over a serial port and would like to use the linux 6lowpan implementation to make it IP capable. Is there something like the tun/tap-driver for 6lowpan that delivers the raw frames back to userspace over a socket? the simple

Re: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

Hi Luca, That's not particularly hard to figure out, for example by looking at sysfs. Is this really so time-constrained/important/... that you can't do that? It does not seem very practical to dig this information from sysfs as the same information can be easily get via netlink as this

[PATCH v2] net: rfkill: gpio: Enable module auto-loading for ACPI based switches

For the ACPI based switches the MODULE_DEVICE_TABLE is missing to export the entries for module auto-loading. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- net/rfkill/rfkill-gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c

Re: Realtek GPIO chipset, for Baytrail?

Hi Bastien, I have a tablet that seems to be using Realtek chips to do wireless communications (hopefully, this time I won't be wrong[1]). The device, under the gpio class in /sys, shows with a modalias of acpi:OBDA8723: (that's on O, not 0). This seems to correspond to a Realtek chipset

Re: Realtek GPIO chipset, for Baytrail?

Hi Bastien, Your device is a child of 80860F0A (UART) which is driven by the 8250_dw driver. OBDA8723 is the BT part of the realtek 8723 WiFi/BT combo chip. acpi_platform should create a platform device from the ACPI desc. That does show up already in udev, so I should be fine. Then,

Re: Realtek GPIO chipset, for Baytrail?

Hi Bastien, What specific Baytrail tablet do you have? The Onda v975w. It came with Windows 8.1 32-bit. I guess that the device is probably a PCI one, but the enumeration is done through ACPI instead of normal PCI. In

Re: Realtek GPIO chipset, for Baytrail?

Hi Bastien, What specific Baytrail tablet do you have? The Onda v975w. It came with Windows 8.1 32-bit. I guess that the device is probably a PCI one, but the enumeration is done through ACPI instead of normal PCI. In

Re: [PATCH] cfg802111/nl80211: Add device motion indication API

Hi Emmanuel, Add API to notify user-space when the device is in motion and the motion type. This information can be used to react to the changing environment when the device is on the move, or avoid some unnecessary activities when the device is not moving. For example, longer scan intervals

Re: [PATCH] cfg802111/nl80211: Add device motion indication API

Hi Emmanuel, if we have WiFi chips that have these kind of information, then shouldn't it be better exposed via a generic subsystem for motion events. Having this exposed over nl80211 seems a bit too limited. I am thinking that either an input event or maybe via hwmon or IIO. Since at