> When driver uses custom regulatory it registers initial channels at
> init but it can also react to regdom changes using reg_notifier. Is
> that correct?
We can treat regulatory and OF data as entirely independent, I think.
At least that's my suggestion:
* use OF data to populate the original
> I suppose this then can also be done early in the wiphy_register()
> function itself, right?
No, because of the shared channel data issue. If this is
unconditionally in wiphy_register() then we can no longer guarantee
that sharing it is acceptable - which it is today under certain
circumstances
If port100_send_ack() was called twice or more, it has race to hangup.
port100_send_ack() port100_send_ack()
init_completion()
[...]
dev->cmd_cancel = true
/* this removes previous from completion */
init_compl
If sent packet size is wMaxPacketSize boundary, this device doesn't
answer. To fix this, we have to send zero-length packet in usb spec.
Signed-off-by: OGAWA Hirofumi
---
drivers/nfc/port100.c |1 +
1 file changed, 1 insertion(+)
diff -puN drivers/nfc/port100.c~nfc-need-zero-packet driver
Now, NFC_EVENT_DEVICE_ADDED doesn't send NFC_ATTR_RF_MODE. But
NFC_CMD_GET_DEVICE send.
To get NFC_ATTR_RF_MODE, we have to call NFC_CMD_GET_DEVICE just for
NFC_ATTR_RF_MODE when get NFC_EVENT_DEVICE_ADDED.
This fixes those inconsistent.
Signed-off-by: OGAWA Hirofumi
---
net/nfc/netlink.c |
Signed-off-by: OGAWA Hirofumi
---
drivers/nfc/port100.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff -puN drivers/nfc/port100.c~nfc-add-rcs380p drivers/nfc/port100.c
--- linux/drivers/nfc/port100.c~nfc-add-rcs380p 2016-12-18 22:16:53.503673411
+0900
+++ linux-hirofumi
Hi Christian / Kalle,
On Fri, Dec 30, 2016 at 03:35:10PM +0100, Christian Lamparter wrote:
> On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo wrote:
> > Christian Lamparter wrote:
> >> The 10.4 firmware adds extended peer information to the
> >> firmware's statistics payload. This additional info is
Hi Rafał,
[auto build test WARNING on mac80211-next/master]
[also build test WARNING on v4.10-rc2 next-20161224]
[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/Rafa-Mi-ecki/cfg80211-allow-passin
On 01/02/2017 02:24 AM, Johannes Berg wrote:
On Fri, 2016-12-30 at 10:49 -0800, gree...@candelatech.com wrote:
From: Ben Greear
ieee80211_xmit_fast assigns info from the passed-in
skb, but then later it also checks for skb_shared(skb),
and may create a new skb based on that check.
But, the co
On 02/01/17 21:12, Fabio Coatti wrote:
Hi all,
I'm using kernel 4.9 and maybe half of the times I boot my laptop I get the
error reported below, and the wifi does not work. I have to remove iwlwifi (like
modprobe -r iwldvm iwlwifi) and insert it again to get things workig again.
This seems a bit
On 2 January 2017 at 21:12, Arend van Spriel
wrote:
> On 02-01-17 18:52, Johannes Berg wrote:
>>> +static void wiphy_freq_limits_apply(struct wiphy *wiphy)
>> [...]
>>> +if (!wiphy_freq_limits_valid_chan(wiphy,
>>> chan)) {
>>> +pr_debug("Disabling f
On 2 January 2017 at 18:52, Johannes Berg wrote:
>> +static void wiphy_freq_limits_apply(struct wiphy *wiphy)
> [...]
>> + if (!wiphy_freq_limits_valid_chan(wiphy,
>> chan)) {
>> + pr_debug("Disabling freq %d MHz as
>> it's out of OF limits\n",
>> +
From: Kalle Valo
Date: Mon, 02 Jan 2017 15:20:59 +0200
> first pull request for 4.11. The tree is based on 4.9 but that shouldn't
> be a problem, at least my test pull to net-next worked ok. I'll fast
> forward my trees after you have pulled this.
>
> Please let me know if you have any problems.
On 02-01-17 18:52, Johannes Berg wrote:
>> +static void wiphy_freq_limits_apply(struct wiphy *wiphy)
> [...]
>> +if (!wiphy_freq_limits_valid_chan(wiphy,
>> chan)) {
>> +pr_debug("Disabling freq %d MHz as
>> it's out of OF limits\n",
>> +
Implements an optional, per bridge port flag and feature to deliver
multicast packets to any host on the according port via unicast
individually. This is done by copying the packet per host and
changing the multicast destination MAC to a unicast one accordingly.
multicast-to-unicast works on top o
On Mon, Jan 2, 2017 at 7:11 PM, wrote:
> Dear Madam Sedat,
Hehe, my family name is indeed a female first name - Sedat is male.
> Thank you for your answer.
>
> I already consulted Ubuntu Community but it is not so nice for a beginner
> like me. I tried several recomedations from them, but no wa
Dear Madam Sedat,
Thank you for your answer.
I already consulted Ubuntu Community but it is not so nice for a
beginner like me. I tried several recomedations from them, but no way.
So, I thought, it is better to ask to the source.
Yes, I have the firmware you mention, but wifi doesn't work.
> +static void wiphy_freq_limits_apply(struct wiphy *wiphy)
[...]
> + if (!wiphy_freq_limits_valid_chan(wiphy,
> chan)) {
> + pr_debug("Disabling freq %d MHz as
> it's out of OF limits\n",
> + chan->center_freq);
>
From: Johannes Berg
Date: Mon, 2 Jan 2017 15:39:03 +0100
> Happy New Year :-)
Same to you :-)
> Even though I was out for around two weeks, only a single fix came in,
> I guess everyone else was also out. But if people were out, then they
> won't be sending fixes soon again I suppose, and if t
From: Rafał Miłecki
There are some devices (e.g. Netgear R8000 home router) with one chipset
model used for different radios, some of them limited to subbands. NVRAM
entries don't contain any extra info on such limitations and firmware
reports full list of channels to us. We need to store extra l
From: Rafał Miłecki
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by
From: Rafał Miłecki
It allows specifying hardware limitations of supported channels. This
may be useful for specifying single band devices or devices that support
only some part of the whole band.
This can be useful for some tri-band routers that have separated radios
for lower and higher part of
On Mon, 2017-01-02 at 16:05 +0100, Rafał Miłecki wrote:
> On 2 January 2017 at 15:04, Johannes Berg
> wrote:
> > Perhaps a better approach would be to not combine this with wiphy
> > registration, but require drivers that may use this to call a new
> > helper function *before* wiphy registration (
On 2 January 2017 at 15:04, Johannes Berg wrote:
> Perhaps a better approach would be to not combine this with wiphy
> registration, but require drivers that may use this to call a new
> helper function *before* wiphy registration (and *after* calling
> set_wiphy_dev()), like e.g.
>
>ieee80211
On Mon, 2017-01-02 at 16:01 +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> There are no users of this ("vrfkill") in the tree, so it's just
> dead code - remove it.
>
> This also isn't really how rfkill is supposed to be used - it's
> intended as a signalling mechanism to/from the device,
From: Johannes Berg
There are no users of this ("vrfkill") in the tree, so it's just
dead code - remove it.
This also isn't really how rfkill is supposed to be used - it's
intended as a signalling mechanism to/from the device, which the
driver (and partially cfg80211) will handle - having a sepa
> My understanding is it is generally felt that using the regulator
> enable GPIO commonly found on WiFi chips for rfkill is an abuse of
> rfkill as it is more that just an RF disable. From a DT standpoint,
> this seems like creating a binding for what a Linux driver wants.
> Instead, I think this
Hi Dave,
Happy New Year :-)
Even though I was out for around two weeks, only a single fix came in,
I guess everyone else was also out. But if people were out, then they
won't be sending fixes soon again I suppose, and if they weren't out
they haven't sent more fixes, so I decided to send this one
> Acknowledgment is done for transmitter<->receiver addresses,
> not for source<->destination?
Well, these are management frames, there either are no SA/DA or they're
identical to RA/TA, depending on how you want to look at it. Typically
it does get called SA/DA too then.
> Patch talks about sou
On 01/02/2017 02:28 PM, Johannes Berg wrote:
On Fri, 2016-12-30 at 22:55 +0300, IgorMitsyanko wrote:
The driver needs to configure receive behavior to accept frames to
the
specified random address during the time the frame exchange is
pending
and such frames need to be acknowledged similarly to
> 2) mac80211 - it's a big one as it's used in SET_IEEE80211_DEV
>
> I was planning to work on mac80211 drivers later. This will require
> similar modification of ieee80211_alloc_hw.
Ah, ok, thanks for the explanation.
johannes
On 2 January 2017 at 15:04, Johannes Berg wrote:
>> + prop = of_find_property(np, "ieee80211-freq-limit", &i);
>> + if (!prop)
>> + return 0;
>> +
>> + i = i / sizeof(u32);
>
> What if it's not even a multiple of sizeof(u32)? Shouldn't you check
> that, in case it's complet
On Mon, Jan 2, 2017 at 2:11 PM, wrote:
> Dear Sirs,
> Which of the below drivers should I install for my Lenovo 3000 V200?
> I am runing Ubuntu 16.04
>
> Intel® Wireless WiFi Link 4965AGN
> 2.6.24+ iwlwifi-4965-ucode-4.44.14.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.15.tgz
> 2.6.24+ iwlwifi-4965-ucod
On 2 January 2017 at 14:38, Johannes Berg wrote:
>
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -3730,8 +3730,8 @@ static inline const char *wiphy_name(const
>> struct wiphy *wiphy)
>> * Return: A pointer to the new wiphy. This pointer must be
>> * assigned to each net
> + prop = of_find_property(np, "ieee80211-freq-limit", &i);
> + if (!prop)
> + return 0;
> +
> + i = i / sizeof(u32);
What if it's not even a multiple of sizeof(u32)? Shouldn't you check
that, in case it's completely bogus?
> + if (i % 2) {
> + dev_err(de
> +pcie@0,0 {
> + reg = <0x 0 0 0 0>;
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
> + ieee80211-freq-limit = <2402000 2432000>,
> + <2432000 2462000>;
> + };
> +};
Syntactically, that might be a good example, but semantical
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -3730,8 +3730,8 @@ static inline const char *wiphy_name(const
> struct wiphy *wiphy)
> * Return: A pointer to the new wiphy. This pointer must be
> * assigned to each netdev's ieee80211_ptr for proper operation.
> */
> -struc
From: Rafał Miłecki
So far wiphy's device had to be set using separated set_wiphy_dev call.
Most drivers were doing this right after calling wiphy_new anyway so
this just simplifies the code a bit.
The real advantage of this however is having access to struct dev during
early wiphy init. This all
From: Rafał Miłecki
It allows specifying hardware limitations of supported channels. This
may be useful for specifying single band devices or devices that support
only some part of the whole band.
This can be useful for some tri-band routers that have separated radios
for lower and higher part of
From: Rafał Miłecki
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by
Hi Dave,
first pull request for 4.11. The tree is based on 4.9 but that shouldn't
be a problem, at least my test pull to net-next worked ok. I'll fast
forward my trees after you have pulled this.
Please let me know if you have any problems.
Kalle
The following changes since commit adc176c54722
Dear Sirs,
Which of the below drivers should I install for my Lenovo 3000 V200?
I am runing Ubuntu 16.04
Intel® Wireless WiFi Link 4965AGN
2.6.24+ iwlwifi-4965-ucode-4.44.14.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.15.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.17.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.1.18.tgz
On Mon, 2017-01-02 at 13:21 +0100, Johannes Berg wrote:
> > I'm not super happy with this conditional locking - can't we
> > instead
> > defer the necessary work to a workqueue, or so, for purposes of the
> > LED?
>
> Actually, since you can sleep in here, and do various other things
> like schedu
> I'm not super happy with this conditional locking - can't we instead
> defer the necessary work to a workqueue, or so, for purposes of the
> LED?
Actually, since you can sleep in here, and do various other things like
scheduling etc. this can't even be correct as is - one thread might be
in the
On Wed, Dec 21, 2016 at 09:45:33AM +0100, Michał Kępień wrote:
> Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
> which may be useful on laptops with a single "radio LED" and multiple
> radio transmitters. The trigger is meant to turn a LED on whenever
> there is at least
> + * @random_sa: indicates whether the source address is randomized.
> When this is
> + * true, the driver needs to transmit the management frame
> using the
> + * address specified in the SA field (Address 2) in the
> buffer and the
> + * driver needs to receive and acknowledge the respons
On Fri, 2016-12-30 at 22:55 +0300, IgorMitsyanko wrote:
>
> > The driver needs to configure receive behavior to accept frames to
> > the
> > specified random address during the time the frame exchange is
> > pending
> > and such frames need to be acknowledged similarly to frames sent to
> > the
>
> -Original Message-
> From: Johannes Berg [mailto:johan...@sipsolutions.net]
> Sent: Monday, January 02, 2017 13:00
> To: Peer, Ilan
> Cc: linux-wireless@vger.kernel.org; masashi.ho...@gmail.com
> Subject: Re: [PATCH] mac80211: Fix addition of mesh configuration element
>
> On Mon, 2016-
> - Handle the global mutex properly when rfkill_set_{hw,sw}_state()
> or
> rfkill_set_states() is called from within an rfkill callback. v2
> always tried to lock the global mutex in such a case, which led
> to a
> deadlock when an rfkill driver called one of the above functions
>
On Mon, 2017-01-02 at 08:28 +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> It's maintained by Seth Forshe for a long time now.
>
Both applied, thanks.
johannes
On Mon, 2016-12-26 at 18:17 +0200, Ilan Peer wrote:
> The code was setting the capabilities byte to zero,
> after it was already properly set previously. Fix it.
>
> The bug was found while debugging hwsim mesh tests failures
> that happened in commit 76f43b4 (mac80211: Remove invalid flag
> opera
> > 1) does it even make sense to split it out per AC? wouldn't it be
> > weird
> > if you supported this only for VO and BK, and not the others, or
> > something like that?
> >
>
> It has support for BE, VI, management and beacon frames also.
> Or do you meant to say like support only for VO an
On Mon, 2016-12-19 at 12:58 +0200, Lazar, Alexei Avshalom wrote:
> > What you're doing here is *extremely* vague. No definitions of what
> > this means, no description of how it's intended to be implemented,
> > no note even on whether or not this is for full-MAC chips or not,
> > etc.
> >
>
> T
> + /*
> + * allow only one legacy scheduled scan if user-space
> + * does not indicate multiple scheduled scan support.
> + */
> + if (!info->attrs[NL80211_ATTR_SCHED_SCAN_MULTI] &&
> + cfg80211_legacy_sched_scan_active(rdev))
> return -EINPROGRESS;
T
From: Johannes Berg
In ieee80211_xmit_fast(), 'info' is initialized to point to the skb
that's passed in, but that skb may later be replaced by a clone (if
it was shared), leading to an invalid pointer.
This can lead to use-after-free and also later crashes since the
real SKB's info->hw_queue do
On Fri, 2016-12-30 at 10:49 -0800, gree...@candelatech.com wrote:
> From: Ben Greear
>
> ieee80211_xmit_fast assigns info from the passed-in
> skb, but then later it also checks for skb_shared(skb),
> and may create a new skb based on that check.
>
> But, the code did not re-assign 'info', so it
Hi all,
I'm using kernel 4.9 and maybe half of the times I boot my laptop I get the
error reported below, and the wifi does not work. I have to remove iwlwifi
(like
modprobe -r iwldvm iwlwifi) and insert it again to get things workig again.
This seems a bit random, it does not happens all the t
57 matches
Mail list logo
