On 18-3-2017 1:47, Dan Williams wrote:
> On Fri, 2017-03-17 at 13:26 -0700, Nikita N. wrote:
>> Hi All,
>> I'm addressing to the maintainers of Ralink driver rt2800usb
>> (RT2870,RT3070).
>> To who can I send my request?
Seeing this kind of emails repeatedly on this list and others makes me
thin
Hi Andrew,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andrew-F-Davis/Remove-unneeded-build-director
Hi Andrew,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andrew-F-Davis/Remove-unneeded-build-director
On Fri, 2017-03-17 at 13:26 -0700, Nikita N. wrote:
> Hi All,
> I'm addressing to the maintainers of Ralink driver rt2800usb
> (RT2870,RT3070).
> To who can I send my request?
This mailing list (linux-wireless@) is the right place.
Dan
Hi All,
I'm addressing to the maintainers of Ralink driver rt2800usb
(RT2870,RT3070).
To who can I send my request?
Thanks
--
http://www.fastmail.com - Or how I learned to stop worrying and
love email again
Hi All,
I'm addressing to the maintainers of Ralink driver rt2800usb
(RT2870,RT3070).
To who can I send my request?
Thanks
--
http://www.fastmail.com - Access all of your messages and folders
wherever you are
On 2017-03-16 10:33, Kalle Valo wrote:
Erik Stromdahl writes:
There seems to be same pattern for reading four bytes, what if we should
add a helper for that? Something like ath10k_sdio_read32()? It could
handle the kmalloc and switch endianess also.
But please don't make any chances to sdio
you may quickly realize that this patch cannot be a solution
example:
- if (channel >= 1 && channel <= 14) {
+ if (channel >= 1 && channel <= 7) {
status->band = NL80211_BAND_2GHZ;
do you you really want to limit the 2.4 channels for all users?
Am 16.03.2017 um 16:
On Thu, Mar 16, 2017 at 11:03:52PM +0900, Greg KH wrote:
> On Thu, Mar 16, 2017 at 02:55:09PM +0100, Rafał Miłecki wrote:
> > Luis: would you ack this patch now I followed your guidance?
>
> It's up to Luis now :)
I'm reviewing now!
Luis
From: Ben Greear
Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to e
On Tue, 2017-03-07 at 12:25 +0200, Andy Shevchenko wrote:
> We return -ENODEV if ACPI provides a GPIO resource. Looks really
> wrong.
> If it has even been tested?
Any comments on this clean up?
Next patch which is dependent to this is related to ACPI enumeration.
After GPIO ACPI library gets str
The tech committee would like to announce our first accepted tutorial
Monsieurs Andy Gospodarek and Jesper Dangaard Brouer will give an
XDP tutorial catered to mere mortals titled "XDP for the Rest of Us"
Description:
-
XDP (eXpress Data Path) has been one of the most widely discussed topics
writes:
> From: Ryan Hsu
>
> In the 'commit ebee76f7fa46 ("ath10k: allow setting coverage class")',
> it inherits the design and the address offset from ath9k, but the address
> is not applicable to QCA6174, which leads to a random crash while doing the
> resume() operation, since the set_covera
On Friday, March 17, 2017 1:58:58 PM EDT Johannes Berg wrote:
> > > I guess this is intended behavior?
> >
> > I had thought this was intended behavior as well but I see that a
> > patch is already prepped and tested to make this not happen. At any
> > rate it wasn't appearing to affect my usecase
On Friday, March 17, 2017 2:40:50 PM CET Zefir Kurtisi wrote:
> On 03/16/2017 04:13 PM, Simon Wunderlich wrote:
> > @@ -126,10 +142,14 @@ int ath9k_cmn_init_channels_rates(struct ath_common
> > *common)>
> > {
> >
> > struct ath_hw *ah = (struct ath_hw *)common->ah;
> > void *channels;
On 03/16/2017 04:13 PM, Simon Wunderlich wrote:
> From: Ben Greear
>
> Many chips support channels in licensed bands. Add support for those,
> along with a corresponding kernel config option to disable them by
> default. Note that these channels are not selectable even if the
> option has been co
> > I guess this is intended behavior?
>
> I had thought this was intended behavior as well but I see that a
> patch is already prepped and tested to make this not happen. At any
> rate it wasn't appearing to affect my usecase.
I can't actually see how it'd affect any usecase, since you really n
On 17 March 2017 at 09:55, Simon Wunderlich wrote:
> On Friday, March 17, 2017 9:48:07 AM CET Janusz Dziedzic wrote:
>> On 16 March 2017 at 16:13, Simon Wunderlich wrote:
>> > Introduce a debugfs option to manually override the noise floor,
>> > ignoring the automatically tuned noise floor of the
On Friday, March 17, 2017 10:30:24 AM EDT Arend Van Spriel wrote:
> On 17-3-2017 10:06, Arend Van Spriel wrote:
> > On 16-3-2017 22:51, Mark Asselstine wrote:
> >> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
> >>> To support network namespace the driver must assure all created
On Fri, 2017-03-17 at 14:56 +0900, Masashi Honma wrote:
> > It seems that this is really what the meshcfg.rssi_threshold was
> > intended for, and the plink code *does* take it into account. Can
> > you
> > explain where that's breaking down?
>
> Indeed meshcfg.rssi_threshold is already referred
When a wdev changes network namespace, its wdev ID will get
reassigned since NETDEV_REGISTER is called again, in the new
network namespace. Avoid that by checking if it was already
assigned before, and document why we do that.
Reported-and-tested-by: Arend Van Spriel
Signed-off-by: Johannes Berg
On 17-3-2017 10:24, Johannes Berg wrote:
> On Fri, 2017-03-17 at 10:06 +0100, Arend Van Spriel wrote:
>> On 16-3-2017 22:51, Mark Asselstine wrote:
>>> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
To support network namespace the driver must assure all created
network
On 17-3-2017 10:24, Johannes Berg wrote:
> On Fri, 2017-03-17 at 10:06 +0100, Arend Van Spriel wrote:
>> On 16-3-2017 22:51, Mark Asselstine wrote:
>>> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
To support network namespace the driver must assure all created
network
On 17-3-2017 10:06, Arend Van Spriel wrote:
> On 16-3-2017 22:51, Mark Asselstine wrote:
>> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
>>> To support network namespace the driver must assure all created
>>> network interfaces are in the same namespace as the wiphy instance.
>
On Fri, 2017-03-17 at 10:06 +0100, Arend Van Spriel wrote:
> On 16-3-2017 22:51, Mark Asselstine wrote:
> > On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
> > > To support network namespace the driver must assure all created
> > > network interfaces are in the same namespace as t
On Friday, March 17, 2017 9:48:07 AM CET Janusz Dziedzic wrote:
> On 16 March 2017 at 16:13, Simon Wunderlich wrote:
> > Introduce a debugfs option to manually override the noise floor,
> > ignoring the automatically tuned noise floor of the driver/hw.
> >
> > In my tests with a AR9580 based modu
On 16-3-2017 22:51, Mark Asselstine wrote:
> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
>> To support network namespace the driver must assure all created
>> network interfaces are in the same namespace as the wiphy instance.
>>
>> Reported-by: Mark Asselstine
>> Signed-off-
On 16 March 2017 at 16:13, Simon Wunderlich wrote:
> Introduce a debugfs option to manually override the noise floor,
> ignoring the automatically tuned noise floor of the driver/hw.
>
> In my tests with a AR9580 based module and a tx99 5 MHz interferer,
> I could tune the noisefloor to -95 dBm or
Dear linux-wireless developers,
I recently acquired a few Dell DW1601 cards and after a few initial searches it
sounded like they could be used to connect to each other.
Now it seems that they do not have the wifi connectivity enabled, just WBE.
relevant lspci output:
03:00.0 PCI bridge [0604]:
Am 17.03.2017 00:21, schrieb Colin King:
> From: Colin Ian King
>
> The pmkid data is meant be be copied to the previous item in the
> pmkidlist, however the code is just copying the data to itself because
> the src index into pmkidlist is the same as the dst index into pmkidlist.
> Fix this wi
On 16-3-2017 22:51, Mark Asselstine wrote:
> On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
>> To support network namespace the driver must assure all created
>> network interfaces are in the same namespace as the wiphy instance.
>>
>> Reported-by: Mark Asselstine
>> Signed-off-
On 17-3-2017 6:47, Stephen Hemminger wrote:
>
Hi Stephen,
The issue here is with an out-of-tree driver, ie. broadcom-wl, so not
really a kernel issue. Anyway, I asked for more info in bugzilla to
determine whether using the brcmfmac driver, which is supported
upstream, is an option.
Regards,
Ar
On Thu, 2017-03-16 at 11:18 -0700, David Miller wrote:
> From: Johannes Berg
> Date: Thu, 16 Mar 2017 10:51:55 +0100
>
> > Here's the pull request you were waiting for. I went through all my
> > pending patches but only this one is applicable for net.git at this
> > time, so it's just a single on
33 matches
Mail list logo