On 17/01/2017 02:56, Daniel Golle wrote:
> On Mon, Jan 16, 2017 at 11:08:57AM +0100, Stanislaw Gruszka wrote:
>> On Mon, Jan 16, 2017 at 04:06:25AM +0100, Daniel Golle wrote:
>>> From: Claudio Mignanti
>>>
>>> This is needed for devices without support for PCI MWI. See also
>>> https://dev.openw
On Mon, Jan 16, 2017 at 11:08:57AM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 16, 2017 at 04:06:25AM +0100, Daniel Golle wrote:
> > From: Claudio Mignanti
> >
> > This is needed for devices without support for PCI MWI. See also
> > https://dev.openwrt.org/changeset/21850
> >
> > Signed-off-by
On Mon, Jan 16, 2017 at 11:17:44AM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 16, 2017 at 04:17:58AM +0100, Daniel Golle wrote:
> > @@ -7131,6 +7236,12 @@ static int rt2800_validate_eeprom(struct rt2x00_dev
> > *rt2x00dev)
> > rt2x00_set_field16(&word, EEPROM_NIC_CONF0_RF_TYPE, RF28
Hi Martin,
Am 16.01.2017 um 11:17 schrieb Martin Blumenstingl:
> BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
> got a dedicated SDIO device ID which is currently not supported by
> brcmfmac.
> Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
> supp
Hi,
We're working on a formal validation framework for wireless protocol
implementations. We have performed experiments on the 802.11
association state machine and have found peculiar association
behaviors.We'd like to share our findings to the community and confirm
whether they reveal potential i
On 01/16/2017 07:25 AM, Jes Sorensen wrote:
Hanno Zulla writes:
Hi,
has there been any progress on the rtl8723bs / sdio issue?
There were no updates to this mailing list or the usual git repositories
since this was last discussed, unless I missed the proper place to look
for this.
I'm sorry
From: Rafał Miłecki
We have generic place & helpers for storing platform driver data so
there is no reason for using custom priv pointer.
This allows cleaning up struct bcma_sflash from unneeded fields.
Signed-off-by: Rafał Miłecki
---
Kalle: This is mtd focused patch, so I guess it should go
From: Mohammed Shafi Shajakhan
Dump Copy Engine source and destination ring addresses.
This is useful information to debug firmware crashes, assertes or hangs over
long run
assessing the Copy Engine Register status. This also enables dumping CE
register status in debugfs Crash Dump file.
Screen
Folks,
We are pleased to announce that the CFP for netdev 2.1 is now open.
Netdev 2.1 is a community-driven conference geared towards Linux
netheads. Linux kernel networking and user space utilization of the
interfaces to the Linux kernel networking subsystem are the focus.
If you are using Lin
On 14 January 2017 at 19:09, kbuild test robot wrote:
> Hi Waldemar,
>
> [auto build test WARNING on ath6kl/ath-next]
> [also build test WARNING on v4.10-rc3 next-20170113]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https:
Hi Michael,
"Michael Renzmann" writes:
> Michael Renzmann wrote:
>> Someone should also update the "Mailing list" section of [1] accordingly.
>> I guess one needs to have a valid user account for that to do, and I don't
>> have one atm.
>
> I now have an account, but am not sure how to proceed.
Hanno Zulla writes:
> Hi,
>
> has there been any progress on the rtl8723bs / sdio issue?
>
> There were no updates to this mailing list or the usual git repositories
> since this was last discussed, unless I missed the proper place to look
> for this.
>
> I'm sorry that I can't be more helpful wit
Hi,
has there been any progress on the rtl8723bs / sdio issue?
There were no updates to this mailing list or the usual git repositories
since this was last discussed, unless I missed the proper place to look
for this.
I'm sorry that I can't be more helpful with actual development, but am
eager t
Hi Kalle, hi all.
Michael Renzmann wrote:
> Someone should also update the "Mailing list" section of [1] accordingly.
> I guess one needs to have a valid user account for that to do, and I don't
> have one atm.
I now have an account, but am not sure how to proceed.
ath5k-devel is referenced on t
Have proper request id filled in the SCHED_SCAN_RESULTS notification
toward user-space by having the driver provide it through the api.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/ath/ath6kl/wm
This patch implements the idea to have multiple scheduled scan requests
running concurrently. It mainly illustrates how to deal with the incoming
request from user-space in terms of backward compatibility. In order to
use multiple scheduled scans user-space needs to provide a flag attribute
NL80211
Include the request id in the event messages so user-space knows
which scan the event relates to.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
net/wireless/nl80211.c | 23 +++
net/wireless/nl8021
Allow driver to indicate which scheduled scan request is being aborted
by providing the request id.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
.../n
After sending out the initial RFC for multiple scheduled scan support [1]
here a series that deal with it all (I hope) so including events and the
driver function call apis. Resending it due to build issue and it was based
on old mac80211-next master revision.
*Now* it does apply to the master bra
For multiple scheduled scan support the driver needs to know which
scheduled scan request is being stopped. Pass the request id in the
.sched_scan_stop() callback.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
driver
Hi all,
I'm trying to set-up a mesh network using wpa-supplicant (already did
using iw and works fine) because I would like to implement security.
I followed the guide
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh?s[]=mesh&s[]=point
but I bump into some issues:
- when I set the pa
On 16-1-2017 11:17, Martin Blumenstingl wrote:
> BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
> got a dedicated SDIO device ID which is currently not supported by
> brcmfmac.
> Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
> supported because the
On Mon, Jan 16, 2017 at 04:17:58AM +0100, Daniel Golle wrote:
> @@ -7131,6 +7236,12 @@ static int rt2800_validate_eeprom(struct rt2x00_dev
> *rt2x00dev)
> rt2x00_set_field16(&word, EEPROM_NIC_CONF0_RF_TYPE, RF2820);
> rt2800_eeprom_write(rt2x00dev, EEPROM_NIC_CONF0, wor
BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
got a dedicated SDIO device ID which is currently not supported by
brcmfmac.
Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
supported because the chip itself is already supported (due to BCM4345
support
On Mon, Jan 16, 2017 at 04:14:57AM +0100, Daniel Golle wrote:
> This is needed for WiFi to work e.g. on DIR-615 rev.H1 which got
> external RF power amplifiers connected to the WiSoC.
>
> Signed-off-by: Daniel Golle
> Signed-off-by: Gabor Juhos
Acked-by: Stanislaw Gruszka
On Mon, Jan 16, 2017 at 04:08:38AM +0100, Daniel Golle wrote:
> From: Serge Vasilugin
>
> Simple patch to correct HT20/HT40 filter setting.
> Tested with Rt3290, Rt3352 and Rt5350
>
> Signed-off-by: Serge Vasilugin
> Signed-off-by: Daniel Golle
Acked-by: Stanislaw Gruszka
On Mon, Jan 16, 2017 at 04:13:01AM +0100, Daniel Golle wrote:
> From: Felix Fietkau
>
> Signed-off-by: Felix Fietkau
> Signed-off-by: Daniel Golle
Acked-by: Stanislaw Gruszka
On Mon, Jan 16, 2017 at 04:06:25AM +0100, Daniel Golle wrote:
> From: Claudio Mignanti
>
> This is needed for devices without support for PCI MWI. See also
> https://dev.openwrt.org/changeset/21850
>
> Signed-off-by: Daniel Golle
> ---
> drivers/net/wireless/ralink/rt2x00/rt2x00pci.c | 2 ++
>
Hi
I looked more detail in the patches and now I think shared mem
and 16 hw beacons patches are not needed. Explanation is below.
Sorry for not pointing this before.
On Mon, Jan 16, 2017 at 04:01:14AM +0100, Daniel Golle wrote:
> From: Gabor Juhos
>
> On the RT3593 chipset, the beacon registers
On 15-1-2017 0:18, Martin Blumenstingl wrote:
> Hello,
>
> I recently got a "Khadas VIM Pro" (see [0] for more information)
> The "Pro" version comes with an AP6255 wifi chipset.
> Looking at the vendor firmware this seems to be a bcm43455 device: [1]
>
> To my surprise brcmfmac from a mainline 4
30 matches
Mail list logo
