On Mon, 2014-10-27 at 16:14 -0700, Marcel Holtmann wrote:
> Hi Luca,
Hi Marcel,
> > 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 v
On Tue, Oct 28, 2014 at 08:11:19AM +0200, Emmanuel Grumbach wrote:
> This patch series allows to use the firmware debugging features
> of iwlwifi on 3.16. These features are already in 3.17.
>
> I know that this patch series is not compliant with Greg's
> rules for stable patches. It is unlikely t
commit 1fa1605648d15d42f350807279b6c6e8d33b6382 upstream.
This is not related to mvm. Rename to iwl_fw_error_next_data.
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h | 4 ++--
drivers/net/wireless/iwlwifi/mvm/ops.c | 6 +++---
2 files changed, 5
commit 06ddbf5adac1fd2a031eade8a92239abfa6db93a upstream.
This can be useful later for parsing since the parsing may
differ based on the device's family / bus.
Also add the human readable version of the firmware.
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/iwl-drv.c
commit 5bfe6f53283de44855ee45a102210abbfac995f9 upstream.
The memory was not zeroed - fix that. Also update the
iwl_fw_error_dump_info structure.
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
This patch series allows to use the firmware debugging features
of iwlwifi on 3.16. These features are already in 3.17.
I know that this patch series is not compliant with Greg's
rules for stable patches. It is unlikely that these patches
will be applied on vanilla 3.16 - I know that.
I send them
commit c2d202017da18ebd6567862bd9a50392970f048f upstream
This allows to use the firmware monitor. This capability
uses a lot of contiguous memory (up to 64MB), so make its
usage module parameter dependent.
The driver will try to allocate as much contiguous memory
as possible downgrading its requi
commit 655e6d6db21b0c0d411aef9d816816fb68b0496c upstream.
Its content can move to the caller.
While at it, move iwl_mvm_fw_error_rxf_dump to caller.
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 100
drivers/net/wireless/iwlwifi/
commit d4849277f92a0bfa08a988545ea527fc8e0c9571 upstream.
The chunks of data do not need to be multipliers of 4 nor
4-bytes aligned.
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
commit 78dae98fab85f4cd2d38cfc3474dea6e87e7b53a upstream.
Instead of reading all the data in the context of the
interrupt thread, collect the data in the restart flow
before the actual restart takes place so that the device
still has all the information.
Remove iwl_mvm_fw_error_sram_dump and move
The driver is not released when ieee80211_register_hw fails in
mac80211_hwsim_create_radio, leading to the access to the unregistered (and
possibly freed) device in platform_driver_unregister:
[0.447547] mac80211_hwsim: ieee80211_register_hw failed (-2)
[0.448292] [ cut here ]-
Hi,
We wish to note the following changes should be made to the wireless regulatory
database to reflect some recent changes to the 60 GHz band here in New Zealand.
In additional there are some inaccuracies when compared to our current
licencing for the 5 GHz "Wi-Fi" band.
The updated entry for
On 28.10.2014 00:15, Lennart Poettering wrote:
> On Mon, 27.10.14 23:43, poma (pomidorabelis...@gmail.com) wrote:
>
>> but is there a better way to do it?
>
> This appears to be a kernel driver bug. Please report this issue
> against the kernel driver in question, systemd is not the right place
>
On 10/27/2014 04:14 PM, Marcel Holtmann wrote:
> 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 info
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
It is tested and works,
# systemctl suspend
[ 144.218876] PM: Entering mem sleep
[ 144.219249] r8712u 2-3:1.0 wlp0s4f1u3: Suspending...
[ 144.219255] r8712u 2-3:1.0 wlp0s4f1u3: Unable to suspend
& RESUME
[ 146.844240] r8712u 2-3:1.0 wlp0s4f1u3: Resuming...
[ 146.844241] r8712
From: Ben Greear
Add frequency attribute when sending to user-space over
netlink socket. The frequency is currently ignored when
receiving from user-space.
Signed-off-by: Ben Greear
---
drivers/net/wireless/mac80211_hwsim.c | 7 +++
drivers/net/wireless/mac80211_hwsim.h | 4 +++-
2 files
Dear Zefir,
Thanks a lot for these precisions, This makes thing more clear.
There is still one thing unclear to me. If we do not consider working
on the DFS channels and that we only want to operate on channels 36,
40, 44 and 48 in EU. Do we still need to enable DFS flags in ath9k to
comply with
Am 27.10.2014 um 16:20 schrieb John W. Linville:
> On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
>> I am not a developer, but I stumbled upon this just a couple of days ago in
>> the OpenWRT forums:
>>
>> https://forum.openwrt.org/viewtopic.php?id=53215
>>
>> In short, MediaTek is looking f
On Fri, Oct 24, 2014 at 02:44:32PM +0300, Kalle Valo wrote:
> Hi John,
>
> here are the latest ath10k patches plus a small logging change to ath6kl
> and wil6210. Unfortunately this time there's a small conflict in
> drivers/net/wireless/ath/wil6210/wil6210.h but luckily it's easy to fix.
> Here's
On Wed, Oct 22, 2014 at 03:03:49AM +0400, Sergey Ryazanov wrote:
> This reverts commit 093ec3c5337434f40d77c1af06c139da3e5ba6dc.
>
> AHB bus code has been removed, since we did not have support Atheros
> AR231x SoC, required for building the AHB version of ath5k. Now that
> support WiSoC chips add
On Wed, Oct 22, 2014 at 03:03:50AM +0400, Sergey Ryazanov wrote:
> - Use config symbol defined in the driver instead of arch specific one for
> conditional compilation.
> - Rename the ATHEROS_AR231X config symbol to ATH25.
> - Fix include (ar231x_platform.h -> ath25_platform.h).
> - Some of AR231
On Thu, Oct 23, 2014 at 09:24:33PM +0300, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 8:48 PM, John W. Linville
> wrote:
> > I do not have the 3.18-rc1 tag, because Dave doesn't have it yet in
> > the net.git tre. Please rebase.
> >
>
> Done - new tag:
>
> git://git.kernel.org/pub/scm/li
I'm always a bit cautious about merging regdb patches that loosen
the rules. Would anyone with more expertise on such regulations care
to comment on this one?
On Sun, Oct 12, 2014 at 09:56:51PM +1100, Michael Harris wrote:
> I am not sure where the existing regdb rules for Australia were derived
On Thu, Oct 23, 2014 at 08:35:36PM +0200, Johannes Berg wrote:
> John,
>
> Please pull the below changes for the current 3.18 preparations. More
> details below.
>
> Thanks,
> johannes
>
> ---
>
> The following changes since commit
> 35a9ad8af0bb0fa3525e6d0d20e32551d226f38e:
>
> Merge git://
On Mon, 2014-10-27 at 07:19 -0700, Marcel Holtmann wrote:
> Hi Johannes,
>
> >>> 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 di
On Sun, Oct 19, 2014 at 09:49:52AM +0300, Vladimir Kondratiev wrote:
> On Tuesday, October 14, 2014 02:28:58 PM Xose Vazquez Perez wrote:
> > "(57240 - 65880 @ 2160), (40), NO-OUTDOOR" should(must) be replaced by:
> > "(57000 - 66000 @ 2160), (40)"
> >
>
> Yes, looks like you are right. I used dr
On Mon, Oct 27, 2014 at 11:15:09AM -0400, John W. Linville wrote:
> Yes, I have it queued. Things have been delayed due to my recent
> travels, etc.
>
Thanks!
Guenter
> 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 wr
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 ha
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 th
On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
> I am not a developer, but I stumbled upon this just a couple of days ago in
> the OpenWRT forums:
>
> https://forum.openwrt.org/viewtopic.php?id=53215
>
> In short, MediaTek is looking for volunteers to help get their drivers
> mainlined in
Gar... I am stupid. The original shift can't wrap. I don't know what
I was thinking. Sorry for the noise...
Thanks for checking me on this Joe.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kerne
On Mon, 2014-10-27 at 12:52 +0300, Dan Carpenter wrote:
> On Fri, Oct 24, 2014 at 02:43:31AM -0700, Joe Perches wrote:
> > On Fri, 2014-10-24 at 11:15 +0300, Dan Carpenter wrote:
> > > @@ -8028,10 +8028,10 @@ static void ipw_handle_promiscuous_rx(struct
> > > ipw_priv *priv,
> > >
> > > /* Zer
On Mon, 2014-10-27 at 09:43 +0100, Jes Sorensen wrote:
> Sanjeev Sharma writes:
> > This is a patch to the rtw_cmd.c file that fixes
> > Error reported by checkpatch.
[]
> > diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
> > b/drivers/staging/rtl8723au/core/rtw_cmd.c
[]
> > @@ -957,7 +957,
On 10/27/2014 03:18 PM, Adrien Decostre wrote:
> Hello Zefir,
>
> Thanks a lot for your answer. This helps me a lot.
> If I correctly understand, the ability of ath9k to detect all pulses
> may also depend of the platform performances. So on an embedded
> platform with limited performances, we may
Hi Johannes,
>>> 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
Hello Zefir,
Thanks a lot for your answer. This helps me a lot.
If I correctly understand, the ability of ath9k to detect all pulses
may also depend of the platform performances. So on an embedded
platform with limited performances, we may observe more pulses losses
than on a more powerful platfor
Let the other listeners being notified when a new or del interface
command has been issued, thus reducing later necessary request to be in
sync with current context.
Signed-off-by: Tomasz Bursztyka
---
Hi,
In order not to change current API behavior for the command issuer, I kept
the reply for
Source is QCA's regulatory team's efforts.
Signed-off-by: Jouni Malinen
---
db.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/db.txt b/db.txt
index 1df0b4c..43afa5c 100644
--- a/db.txt
+++ b/db.txt
@@ -133,6 +133,7 @@ country BG: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 -
This extends regulatory rules for China to allow 160 MHz VHT channels to
be used in 5.15-5.25 GHz, 5.25-5.35 GHz. Since the rules between
5.15-5.25 and 5.25-5.35 GHz ranges are different (e.g., DFS
requirement), the AUTO-BW flag needs to be used to allow the maximum
channel bandwidth to be determin
On Mon, 2014-10-27 at 13:55 +0200, Jukka Rissanen wrote:
> > 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
Hi Seongho,
that paper looks quite interesting.
Are you planning to publish code/patches for your implementation as well?
It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht.
Thanks,
- Felix
On 26/10/2014 12:14 AM, Seongho Byeon wrote:
>
> Hi, I am Ph.d. student in Seoul
On ma, 2014-10-27 at 12:31 +0100, Johannes Berg wrote:
> On Mon, 2014-10-27 at 13:29 +0200, Jukka Rissanen wrote:
>
> > Yes, but from generic nl80211 event you cannot know if event is from
> > hwsim radio or not. With this patch, the listener can know that the
> > radio new/del event is specifical
On 2014-10-27 12:40, Sujith Manoharan wrote:
> Hi,
>
> This series looks good to me...
Thanks for the review
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
Hi,
This series looks good to me...
Sujith
Felix Fietkau wrote:
> The initvals use up quite a bit of space, and PC-OEM support is
> typically not needed on embedded systems
>
> Signed-off-by: Felix Fietkau
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 5
> drivers/net/wireless/a
On Mon, 2014-10-27 at 13:29 +0200, Jukka Rissanen wrote:
> Yes, but from generic nl80211 event you cannot know if event is from
> hwsim radio or not. With this patch, the listener can know that the
> radio new/del event is specifically related to hwsim radio.
That's not particularly hard to figur
Hi Johannes,
On ma, 2014-10-27 at 12:20 +0100, Johannes Berg wrote:
> On Mon, 2014-10-27 at 12:44 +0200, Jukka Rissanen wrote:
> > Hi,
> >
> > patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and
> > HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more
> > fitting on how oth
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 n
On Mon, 2014-10-27 at 12:44 +0200, Jukka Rissanen wrote:
> Hi,
>
> patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and
> HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more
> fitting on how other pieces of the wireless system work. A define
> to old name is provided for bac
Userspace can add keys to an AP mode interface before start_ap has been
called. If there have been no calls to start_ap/stop_ap in the mean
time, the keys will still be around when the interface is brought down.
Signed-off-by: Felix Fietkau
---
net/mac80211/iface.c | 3 ---
1 file changed, 3 del
On 10/24/2014 05:23 PM, Adrien Decostre wrote:
>
> I am looking for information about the compliancy of the ath9k driver
> to the EN 300 328 ETSI regulation.
>
> Would someone know if ath9k has already been tested for this regulation?
>
> Is it needed to enable any specific flag in ath9k to guar
When adding new radio via HWSIM_CMD_NEW_RADIO then listeners on the
multicast group "config" are informed.
Signed-off-by: Jukka Rissanen
---
drivers/net/wireless/mac80211_hwsim.c | 141 +-
1 file changed, 123 insertions(+), 18 deletions(-)
diff --git a/drivers/ne
Using the name HWSIM_CMD_NEW_RADIO and HWSIM_CMD_DEL_RADIO is more
fitting on how other pieces of the wireless system work.
Signed-off-by: Jukka Rissanen
---
drivers/net/wireless/mac80211_hwsim.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wirel
When deleting old radio via HWSIM_CMD_DEL_RADIO then listeners on the
multicast group "config" are informed.
Signed-off-by: Jukka Rissanen
---
drivers/net/wireless/mac80211_hwsim.c | 43 ++-
1 file changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/ne
Hi,
patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and
HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more
fitting on how other pieces of the wireless system work. A define
to old name is provided for backward compatibility.
Patches 2 and 3 use the newly named enums and p
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. Ho
Sehr geehrter Herr / Frau,
SPRING FINANCE ist ein britisches Consulting Group, der internationale Eigen-
und Fremdkapital Projektfinanzierung, gewerbliche Immobilienfinanzierung in den
globalen Markt. Wir werden durch den Kreditgeber zertifiziert und bieten
besicherte Kredite an Privatperson
On Fri, Oct 24, 2014 at 02:43:31AM -0700, Joe Perches wrote:
> On Fri, 2014-10-24 at 11:15 +0300, Dan Carpenter wrote:
> > @@ -8028,10 +8028,10 @@ static void ipw_handle_promiscuous_rx(struct
> > ipw_priv *priv,
> >
> > /* Zero the flags, we'll add to them as we go */
> > ipw_rt->rt_flag
On 23 October 2014 17:10, Kalle Valo wrote:
> Bartosz Markowski writes:
>
>> Firmware was crashing when we were trying to warm reset it
>> after suspend. This was due to the fact that target registeres
>> can be accessed only if the hardware is awaken.
>>
>> This patch makes sure to awake the dev
Sanjeev Sharma writes:
> This is a patch to the rtw_cmd.c file that fixes
> Error reported by checkpatch.
>
> Signed-off-by: Sanjeev Sharma
> ---
> drivers/staging/rtl8723au/core/rtw_cmd.c | 83
> +++-
> 1 file changed, 40 insertions(+), 43 deletions(-)
>
> diff --gi
Firmware was crashing when we were trying to warm reset it
after suspend. This was due to the fact that target registeres
can be accessed only if the hardware is awaken.
This patch makes sure to awake the device also on the hif up,
not only in case of probe call.
Signed-off-by: Bartosz Markowski
This is a patch to the rtw_cmd.c file that fixes
Error reported by checkpatch.
Signed-off-by: Sanjeev Sharma
---
drivers/staging/rtl8723au/core/rtw_cmd.c | 83 +++-
1 file changed, 40 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.
62 matches
Mail list logo
