* Re: [PATCH] ath10k: move irq setup
From: Kalle Valo @ 2013-07-30 18:35 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374129572-6079-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> There was a slight race during PCI shutdown. Since
> interrupts weren't really stopped (only Copy
> Engine interrupts were disabled through device hw
> registers) it was possible for a firmware
> indication (crash) interrupt to come in after
> tasklets were synced/killed. This would cause
> memory corruption and a panic in most cases. It
> was also possible for interrupt to come before CE
> was initialized during device probing.
>
> Interrupts are required for BMI phase so they are enabled as soon as
> power_up() is called but are freed upon both power_down() and stop()
> so there's asymmetry here. As by design stop() cannot be followed by
> start() it is okay. Both power_down() and stop() should be merged
> later on to avoid confusion.
Why are the interrupts freed both in power_down() and stop()? I don't
get that.
What if we call disable_irq() in power_down() instead?
> Before this can be really properly fixed var/hw
> init code split is necessary.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
> ---
>
> Please note: this is based on my (still under
> review at the time of posting) previous patchests:
> device setup refactor and recovery.
>
> I'm posting this before those patchsets are merged
> so anyone interested in testing this fix (I can't
> reproduce the problem on my setup) can give it a
> try.
This was reported by Ben, right? So this sould have a Reported-by line
attributing him.
> @@ -1783,16 +1792,24 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> return 0;
>
> err_ce:
> + /* XXX: Until var/hw init is split it's impossible to fix the ordering
> + * here so we must call stop_intr() here too to prevent interrupts after
> + * CE is teared down. It's okay to double call the stop_intr()
> */
"FIXME:"
> exit:
> + ar_pci->intr_started = ret == 0;
A bit too clever for the sake of readibility for my taste, but I guess
it's ok.
> --- a/drivers/net/wireless/ath/ath10k/pci.h
> +++ b/drivers/net/wireless/ath/ath10k/pci.h
> @@ -198,6 +198,7 @@ struct ath10k_pci {
> * interrupts.
> */
> int num_msi_intrs;
> + bool intr_started;
Adding a new state variable makes me worried. I really would prefer a
solution which would not require that.
Also if we call request_irq() in ath10k_pci_probe() we should also call
free_irq() in ath10k_pci_remove() for symmetry. Just doing a temporary
hack will most likely stay forever :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mac80211: implement critical protocol protection
From: Eliad Peller @ 2013-07-30 18:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Emmanuel Grumbach
In-Reply-To: <1374826090-17322-1-git-send-email-johannes@sipsolutions.net>
hi,
On Fri, Jul 26, 2013 at 11:08 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>
> This new API add in cfg80211 wasn't implemented in mac80211.
> Advertise the capabilities based on the device's
> implementation (possibly NULL) of crit_prot mac80211 ops.
>
> This callback will be called by cfg80211 when hinted by
> userspace that a critical protocol is happening, e.g. it can
> be EAPOL, DHCP.
>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> +static void ieee80211_crit_prot_timeout(struct work_struct *wk)
> +{
> + struct ieee80211_sub_if_data *sdata;
> +
> + sdata = container_of(wk, struct ieee80211_sub_if_data,
> + crit_prot_end_wk.work);
> +
> + drv_crit_proto(sdata->local, sdata, NL80211_CRIT_PROTO_UNSPEC, false);
> +}
> +
i think you should call cfg80211_crit_proto_stopped()?
and even better, maybe provide some callback to let/require the driver
indicate completion (and implicitly call cfg80211_crit_proto_stopped()
there).
Eliad.
^ permalink raw reply
* Re: [PATCH v2] Documentation: dt: bindings: TI WiLink modules
From: Luciano Coelho @ 2013-07-30 18:54 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-doc, mturquette, mark.rutland, balbi,
grant.likely, rob.herring, linux-kernel, linux-omap,
linux-wireless, linux-arm, tony, nm
In-Reply-To: <1551085.3MDKgN8U89@avalon>
(using the new devicetree mailing list address)
On Tue, 2013-07-30 at 20:24 +0200, Laurent Pinchart wrote:
> Hi Luciano,
>
> Thank you for the patch.
>
> On Monday 29 July 2013 17:55:28 Luciano Coelho wrote:
> > Add device tree bindings documentation for the TI WiLink modules.
> > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
> > modules is supported.
> >
> > Signed-off-by: Luciano Coelho <coelho@ti.com>
> > ---
> >
> > Changes in v2:
> >
> > Use generic clock definitions to get the clock data instead of passing
> > the frequencies directly. Also added definition for "internal"
> > ti,wilink-clock.
> >
> > Please review.
>
> The proposal looks good to me, I just have one small comment.
Cool! Thanks for the review.
[...]
> > +Example:
> > +--------
> > +
> > +Example definition that can be used in OMAP4 Panda:
> > +
> > +wlan {
> > + compatible = "ti,wilink6";
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
>
> Could you please use the IRQ_TYPE_LEVEL_HIGH macro (defined in <dt-
> bindings/interrupt-controller/irq.h>) instead of the hardcode 0x4 constant ?
Ah, right, I saw this new header file recently but forgot to update my
example. I'll update the OMAP4 Panda and OMAP4 SDP dts files I just
sent out as well.
--
Cheers,
Luca.
^ permalink raw reply
* RE: [PATCH] mac80211: implement critical protocol protection
From: Grumbach, Emmanuel @ 2013-07-30 19:14 UTC (permalink / raw)
To: Eliad Peller, Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEfy_ts00HnEgaLYQqzMhLR2KbZsn1KVH6eOMYUiTSjD-g@mail.gmail.com>
> On Fri, Jul 26, 2013 at 11:08 AM, Johannes Berg <johannes@sipsolutions.net>
> wrote:
> > From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> >
> > This new API add in cfg80211 wasn't implemented in mac80211.
> > Advertise the capabilities based on the device's implementation
> > (possibly NULL) of crit_prot mac80211 ops.
> >
> > This callback will be called by cfg80211 when hinted by userspace that
> > a critical protocol is happening, e.g. it can be EAPOL, DHCP.
> >
> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > ---
>
> > +static void ieee80211_crit_prot_timeout(struct work_struct *wk) {
> > + struct ieee80211_sub_if_data *sdata;
> > +
> > + sdata = container_of(wk, struct ieee80211_sub_if_data,
> > + crit_prot_end_wk.work);
> > +
> > + drv_crit_proto(sdata->local, sdata, NL80211_CRIT_PROTO_UNSPEC,
> > +false); }
> > +
>
> i think you should call cfg80211_crit_proto_stopped()?
> and even better, maybe provide some callback to let/require the driver
> indicate completion (and implicitly call cfg80211_crit_proto_stopped() there).
Oops, your're right.
Otherwise I won't be able to issue another crit_prot_session since start reads:
if (rdev->crit_proto_nlportid)
return -EBUSY;
The API is just a bit funny: there is a duration, but I am still supposed to call stop when I am done?
If so, why not put the timer internally in cfg80211?
^ permalink raw reply
* Oops in nl80211_set_reg, Linux 3.10.3
From: Ben Hutchings @ 2013-07-30 19:18 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 13095 bytes --]
I was having trouble associating with a wireless network, and hit this
oops:
Jul 30 17:50:09 deadeye kernel: [79205.769051] wlan1: authenticate with a4:56:30:46:54:40
Jul 30 17:50:09 deadeye kernel: [79205.773509] wlan1: send auth to a4:56:30:46:54:40 (try 1/3)
Jul 30 17:50:09 deadeye kernel: [79205.773545] cfg80211: Calling CRDA to update world regulatory domain
Jul 30 17:50:09 deadeye kernel: [79205.777747] cfg80211: World regulatory domain updated:
Jul 30 17:50:09 deadeye kernel: [79205.777752] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 30 17:50:09 deadeye kernel: [79205.777754] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.777756] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.777759] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.777761] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.777762] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.777780] cfg80211: Calling CRDA for country: GB
Jul 30 17:50:09 deadeye kernel: [79205.778936] wlan1: authenticated
Jul 30 17:50:09 deadeye kernel: [79205.779101] wlan1: associate with a4:56:30:46:54:40 (try 1/3)
Jul 30 17:50:09 deadeye NetworkManager[1100]: <info> (wlan1): roamed from BSSID A4:56:30:15:B4:8F (OHM2013) to (none) ((none))
Jul 30 17:50:09 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: completed -> authenticating
Jul 30 17:50:09 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: authenticating -> associating
Jul 30 17:50:09 deadeye kernel: [79205.783659] cfg80211: Regulatory domain changed to country: GB
Jul 30 17:50:09 deadeye kernel: [79205.783662] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 30 17:50:09 deadeye kernel: [79205.783664] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.783665] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.783666] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.783667] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.783669] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
Jul 30 17:50:09 deadeye kernel: [79205.794765] wlan1: RX AssocResp from a4:56:30:46:54:40 (capab=0x421 status=17 aid=0)
Jul 30 17:50:09 deadeye kernel: [79205.794770] wlan1: a4:56:30:46:54:40 denied association (code=17)
Jul 30 17:50:09 deadeye kernel: [79205.827545] wlan1: deauthenticating from a4:56:30:46:54:40 by local choice (reason=3)
Jul 30 17:50:09 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: associating -> disconnected
Jul 30 17:50:09 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Jul 30 17:50:10 deadeye kernel: [79206.155383] wlan1: authenticate with f4:7f:35:5e:ba:70
Jul 30 17:50:10 deadeye kernel: [79206.158140] wlan1: send auth to f4:7f:35:5e:ba:70 (try 1/3)
Jul 30 17:50:10 deadeye kernel: [79206.160341] wlan1: authenticated
Jul 30 17:50:10 deadeye kernel: [79206.162981] wlan1: associate with f4:7f:35:5e:ba:70 (try 1/3)
Jul 30 17:50:10 deadeye kernel: [79206.200270] wlan1: RX AssocResp from f4:7f:35:5e:ba:70 (capab=0x421 status=17 aid=0)
Jul 30 17:50:10 deadeye kernel: [79206.200286] wlan1: f4:7f:35:5e:ba:70 denied association (code=17)
Jul 30 17:50:10 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Jul 30 17:50:10 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: authenticating -> associating
Jul 30 17:50:10 deadeye kernel: [79206.229284] wlan1: deauthenticating from f4:7f:35:5e:ba:70 by local choice (reason=3)
Jul 30 17:50:10 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: associating -> disconnected
Jul 30 17:50:10 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: disconnected -> scanning
Jul 30 17:50:10 deadeye kernel: [79206.601352] wlan1: authenticate with a4:56:30:15:b4:8f
Jul 30 17:50:10 deadeye kernel: [79206.605532] wlan1: send auth to a4:56:30:15:b4:8f (try 1/3)
Jul 30 17:50:10 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: scanning -> authenticating
Jul 30 17:50:10 deadeye kernel: [79206.708757] wlan1: authenticated
Jul 30 17:50:10 deadeye kernel: [79206.710848] wlan1: associate with a4:56:30:15:b4:8f (try 1/3)
Jul 30 17:50:10 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: authenticating -> associating
Jul 30 17:50:10 deadeye kernel: [79206.724962] wlan1: RX AssocResp from a4:56:30:15:b4:8f (capab=0x1 status=0 aid=24)
Jul 30 17:50:10 deadeye kernel: [79206.728872] wlan1: associated
Jul 30 17:50:10 deadeye kernel: [79206.728944] cfg80211: Calling CRDA for country: NL
Jul 30 17:50:10 deadeye NetworkManager[1100]: <info> (wlan1): supplicant interface state: associating -> completed
Jul 30 17:50:10 deadeye kernel: [79206.736985] PGD 1d4b42067 PUD 1f957e067 PMD 0
Jul 30 17:50:10 deadeye kernel: [79206.737110] Oops: 0000 [#1] SMP
Jul 30 17:50:10 deadeye kernel: [79206.737201] Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc snd_hrtimer rfcomm bnep cpufreq_userspace cpufreq_conservative cpufreq_powersave cpufreq_stats parport_pc ppdev lp parport uinput joydev snd_hda_codec_hdmi snd_hda_codec_conexant nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc thinkpad_acpi iTCO_wdt iTCO_vendor_support nvram snd_seq_midi snd_seq_midi_event coretemp snd_hda_intel snd_hda_codec uvcvideo snd_hwdep crc32c_intel snd_pcm_oss snd_mixer_oss videobuf2_vmalloc videobuf2_memops videobuf2_core videodev snd_pcm snd_rawmidi media ghash_clmulni_intel snd_page_alloc arc4 snd_seq snd_seq_device snd_timer btusb bluetooth iwldvm mac80211 ac aesni_intel snd battery aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper iwlwifi tpm_tis microcode tpm tpm_bios soundcore cfg80211 psmouse pcspkr evdev serio_raw i2c_i801 wmi rfkill mei_me mei i915 lpc_ich mfd_core video button drm_kms_helper drm i2c_algo_bit i2c_core vhost_net tun macvtap macvlan kvm_intel kvm mperf processor fuse autofs4 ext4 crc16 jbd2 mbcache btrfs xor zlib_deflate raid6_pq crc32c libcrc32c dm_mod sg sr_mod sd_mod cdrom crc_t10dif thermal thermal_sys ahci libahci libata ehci_pci ehci_hcd scsi_mod sdhci_pci sdhci mmc_core usbcore usb_common e1000e ptp pps_core
Jul 30 17:50:10 deadeye kernel: [79206.740916] CPU: 3 PID: 525 Comm: crda Not tainted 3.10-1-amd64 #1 Debian 3.10.3-1
Jul 30 17:50:10 deadeye kernel: [79206.741075] Hardware name: LENOVO 4180ET1/4180ET1, BIOS 83ET65WW (1.35 ) 10/06/2011
Jul 30 17:50:10 deadeye kernel: [79206.741234] task: ffff88016d38d0c0 ti: ffff88016d2c8000 task.ti: ffff88016d2c8000
Jul 30 17:50:10 deadeye kernel: [79206.741388] RIP: 0010:[<ffffffffa04a8715>] [<ffffffffa04a8715>] nl80211_set_reg+0xd6/0x212 [cfg80211]
Jul 30 17:50:10 deadeye kernel: [79206.741612] RSP: 0018:ffff88016d2c9a10 EFLAGS: 00210246
Jul 30 17:50:10 deadeye kernel: [79206.741725] RAX: 0000000000000000 RBX: ffff880214a6c240 RCX: 00000000000000c0
Jul 30 17:50:10 deadeye kernel: [79206.741872] RDX: 0000000000000090 RSI: ffff880214a6c240 RDI: 0000000000000000
Jul 30 17:50:10 deadeye kernel: [79206.742019] RBP: 0000000000000004 R08: 00000000000080d0 R09: 0000000000050008
Jul 30 17:50:10 deadeye kernel: [79206.742166] R10: ffff88021211a414 R11: 0001000800000034 R12: 0000000000000000
Jul 30 17:50:10 deadeye kernel: [79206.742314] R13: ffff88021211a414 R14: ffff88016d2c9a90 R15: ffffffffa04d23d0
Jul 30 17:50:10 deadeye kernel: [79206.742462] FS: 0000000000000000(0000) GS:ffff88021e2c0000(0063) knlGS:00000000f7262a00
Jul 30 17:50:10 deadeye kernel: [79206.742628] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
Jul 30 17:50:10 deadeye kernel: [79206.742747] CR2: 0000000000000000 CR3: 0000000210354000 CR4: 00000000000407e0
Jul 30 17:50:10 deadeye kernel: [79206.742898] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul 30 17:50:10 deadeye kernel: [79206.743046] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jul 30 17:50:10 deadeye kernel: [79206.743191] Stack:
Jul 30 17:50:10 deadeye kernel: [79206.743238] 000000006d1a6400 ffffffff8167f760 ffff88021211a424 0000000000000108
Jul 30 17:50:10 deadeye kernel: [79206.743422] ffff880212aba000 00000000000000b4 ffffffff811d66f8 ffffffffa04d29d8
Jul 30 17:50:10 deadeye kernel: [79206.743599] ffffffffa04d29d8 0000000000000000 ffff880212aba000 ffff8801d4ad78c0
Jul 30 17:50:10 deadeye kernel: [79206.743777] Call Trace:
Jul 30 17:50:10 deadeye kernel: [79206.743844] [<ffffffff811d66f8>] ? nla_parse+0x54/0xb6
Jul 30 17:50:10 deadeye kernel: [79206.743970] [<ffffffff812e84fe>] ? genl_family_rcv_msg+0x1cc/0x230
Jul 30 17:50:10 deadeye kernel: [79206.744110] [<ffffffff812e86e4>] ? genl_rcv_msg+0x35/0x53
Jul 30 17:50:10 deadeye kernel: [79206.744228] [<ffffffff812e86af>] ? genl_lock+0xc/0xc
Jul 30 17:50:10 deadeye kernel: [79206.744337] [<ffffffff812e8135>] ? netlink_rcv_skb+0x36/0x7c
Jul 30 17:50:10 deadeye kernel: [79206.744460] [<ffffffff812e8325>] ? genl_rcv+0x1f/0x2c
Jul 30 17:50:10 deadeye kernel: [79206.744574] [<ffffffff812e7999>] ? netlink_unicast+0xa4/0x120
Jul 30 17:50:10 deadeye kernel: [79206.744702] [<ffffffff812e7f43>] ? netlink_sendmsg+0x52e/0x573
Jul 30 17:50:10 deadeye kernel: [79206.744829] [<ffffffff8138801f>] ? _raw_spin_unlock_irqrestore+0xc/0xd
Jul 30 17:50:10 deadeye kernel: [79206.744971] [<ffffffff812e6681>] ? netlink_recvmsg+0x2b1/0x2d1
Jul 30 17:50:10 deadeye kernel: [79206.745101] [<ffffffff812b5a3f>] ? sock_sendmsg+0x4f/0x6c
Jul 30 17:50:10 deadeye kernel: [79206.745225] [<ffffffff81073936>] ? current_kernel_time+0x11/0x35
Jul 30 17:50:10 deadeye kernel: [79206.745357] [<ffffffff812b5c48>] ? ___sys_sendmsg+0x1ec/0x27e
Jul 30 17:50:10 deadeye kernel: [79206.745486] [<ffffffff810de4f3>] ? handle_pte_fault+0x2c5/0x7a7
Jul 30 17:50:10 deadeye kernel: [79206.745615] [<ffffffff810ded46>] ? handle_mm_fault+0x1f1/0x238
Jul 30 17:50:10 deadeye kernel: [79206.745743] [<ffffffff8138b1b3>] ? __do_page_fault+0x32d/0x3cb
Jul 30 17:50:10 deadeye kernel: [79206.745870] [<ffffffff812b4de7>] ? move_addr_to_user+0x60/0x90
Jul 30 17:50:10 deadeye kernel: [79206.745998] [<ffffffff812b5173>] ? SYSC_getsockname+0x8e/0xb7
Jul 30 17:50:10 deadeye kernel: [79206.746125] [<ffffffff812b696a>] ? __sys_sendmsg+0x39/0x57
Jul 30 17:50:10 deadeye kernel: [79206.746248] [<ffffffff812dda04>] ? compat_sys_socketcall+0x157/0x1af
Jul 30 17:50:10 deadeye kernel: [79206.746388] [<ffffffff8138e9ec>] ? sysenter_dispatch+0x7/0x21
Jul 30 17:50:10 deadeye kernel: [79206.746509] Code: b6 fc 88 43 14 41 8a 45 05 88 43 15 e8 6b 5c ff ff 84 c0 74 04 44 88 63 16 49 8b 46 20 45 31 e4 48 8b 80 10 01 00 00 48 8d 68 04 <0f> b7 00 83 e8 04 89 44 24 04 e9 c3 00 00 00 0f b7 4d 00 48 8d
Jul 30 17:50:10 deadeye kernel: [79206.751445] RSP <ffff88016d2c9a10>
Jul 30 17:50:10 deadeye kernel: [79206.756353] CR2: 0000000000000000
Jul 30 17:50:10 deadeye kernel: [79206.783728] ---[ end trace 6c1535d909d97f6d ]---
The code dump seems to match up to source like this:
if (reg_supported_dfs_region(dfs_region))
rd->dfs_region = dfs_region;
f6f6: e8 00 00 00 00 callq reg_supported_dfs_region
f6fb: 84 c0 test %al,%al
f6fd: 74 04 je f703 <nl80211_set_reg+0xc4>
f6ff: 44 88 63 16 mov %r12b,0x16(%rbx)
nla_for_each_nested(nl_reg_rule, info->attrs[NL80211_ATTR_REG_RULES],
rem_reg_rules) {
f703: 49 8b 46 20 mov 0x20(%r14),%rax info->attrs
f707: 45 31 e4 xor %r12d,%r12d
f70a: 48 8b 80 10 01 00 00 mov 0x110(%rax),%rax info->attrs[NL80211_ATTR_REG_RULES]
f711: 48 8d 68 04 lea 0x4(%rax),%rbp
* f715: 0f b7 00 movzwl (%rax),%eax info->attrs[NL80211_ATTR_REG_RULES]->nla_len
So info->attrs[NL80211_ATTR_REG_RULES] == NULL. But the function
already checked that it wasn't! So I don't know what's going on - could
be a memory corruption completely unrelated to nl80211.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH 1/2] staging: vt6656: dead code wCTSDuration.
From: Malcolm Priestley @ 2013-07-30 20:03 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Always set to zero, so remove.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/device.h | 1 -
drivers/staging/vt6656/main_usb.c | 1 -
drivers/staging/vt6656/rxtx.c | 4 ----
3 files changed, 6 deletions(-)
diff --git a/drivers/staging/vt6656/device.h b/drivers/staging/vt6656/device.h
index f07ba24..5324c24 100644
--- a/drivers/staging/vt6656/device.h
+++ b/drivers/staging/vt6656/device.h
@@ -591,7 +591,6 @@ struct vnt_private {
u8 abyBSSID[ETH_ALEN];
u8 abyDesireBSSID[ETH_ALEN];
- u16 wCTSDuration; /* update while speed change */
u16 wACKDuration;
u16 wRTSTransmitLen;
u8 byRTSServiceField;
diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index 0c9e60f..3bc5834 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -267,7 +267,6 @@ device_set_options(struct vnt_private *pDevice) {
pDevice->bUpdateBBVGA = true;
pDevice->byFOETuning = 0;
pDevice->byAutoPwrTunning = 0;
- pDevice->wCTSDuration = 0;
pDevice->byPreambleType = 0;
pDevice->bExistSWNetAddr = false;
/* pDevice->bDiversityRegCtlON = true; */
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 00e0c71..be0c9ce 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -1005,15 +1005,12 @@ static void s_vFillCTSHead(struct vnt_private *pDevice, u32 uDMAIdx,
);
pBuf->wTransmitLength_b = cpu_to_le16(wLen);
pBuf->wDuration_ba = (u16)s_uGetRTSCTSDuration(pDevice, CTSDUR_BA, cbFrameLength, byPktType, wCurrentRate, bNeedAck, byFBOption); //3:CTSDuration_ba, 1:2.4G, 2,3:2.4G OFDM Data
- pBuf->wDuration_ba += pDevice->wCTSDuration;
pBuf->wDuration_ba = cpu_to_le16(pBuf->wDuration_ba);
//Get CTSDuration_ba_f0
pBuf->wCTSDuration_ba_f0 = (u16)s_uGetRTSCTSDuration(pDevice, CTSDUR_BA_F0, cbFrameLength, byPktType, wCurrentRate, bNeedAck, byFBOption); //8:CTSDuration_ba_f0, 1:2.4G, 2,3:2.4G OFDM Data
- pBuf->wCTSDuration_ba_f0 += pDevice->wCTSDuration;
pBuf->wCTSDuration_ba_f0 = cpu_to_le16(pBuf->wCTSDuration_ba_f0);
//Get CTSDuration_ba_f1
pBuf->wCTSDuration_ba_f1 = (u16)s_uGetRTSCTSDuration(pDevice, CTSDUR_BA_F1, cbFrameLength, byPktType, wCurrentRate, bNeedAck, byFBOption); //9:CTSDuration_ba_f1, 1:2.4G, 2,3:2.4G OFDM Data
- pBuf->wCTSDuration_ba_f1 += pDevice->wCTSDuration;
pBuf->wCTSDuration_ba_f1 = cpu_to_le16(pBuf->wCTSDuration_ba_f1);
//Get CTS Frame body
pBuf->Data.wDurationID = pBuf->wDuration_ba;
@@ -1031,7 +1028,6 @@ static void s_vFillCTSHead(struct vnt_private *pDevice, u32 uDMAIdx,
pBuf->wTransmitLength_b = cpu_to_le16(wLen);
//Get CTSDuration_ba
pBuf->wDuration_ba = cpu_to_le16((u16)s_uGetRTSCTSDuration(pDevice, CTSDUR_BA, cbFrameLength, byPktType, wCurrentRate, bNeedAck, byFBOption)); //3:CTSDuration_ba, 1:2.4G, 2,3:2.4G OFDM Data
- pBuf->wDuration_ba += pDevice->wCTSDuration;
pBuf->wDuration_ba = cpu_to_le16(pBuf->wDuration_ba);
//Get CTS Frame body
--
1.8.1.2
^ permalink raw reply related
* Re: Oops in nl80211_set_reg, Linux 3.10.3
From: Johannes Berg @ 2013-07-30 20:08 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-wireless
In-Reply-To: <1375211931.2664.21.camel@deadeye.wl.decadent.org.uk>
On Tue, 2013-07-30 at 21:18 +0200, Ben Hutchings wrote:
> nla_for_each_nested(nl_reg_rule, info->attrs[NL80211_ATTR_REG_RULES],
> rem_reg_rules) {
> f703: 49 8b 46 20 mov 0x20(%r14),%rax info->attrs
> f707: 45 31 e4 xor %r12d,%r12d
> f70a: 48 8b 80 10 01 00 00 mov 0x110(%rax),%rax info->attrs[NL80211_ATTR_REG_RULES]
> f711: 48 8d 68 04 lea 0x4(%rax),%rbp
> * f715: 0f b7 00 movzwl (%rax),%eax info->attrs[NL80211_ATTR_REG_RULES]->nla_len
>
> So info->attrs[NL80211_ATTR_REG_RULES] == NULL. But the function
> already checked that it wasn't! So I don't know what's going on - could
> be a memory corruption completely unrelated to nl80211.
Hmm. Linus ran into a similar issue, but I thought that was fixed by
3a5a423bb958ad22eeccca66c533e85bf69ba10e ("nl80211: fix attrbuf access
race by allocating a separate one"), which went into 3.10.
I don't see a similar issue with the other code that uses
nl80211_fam.attrbuf, so I'm not sure what could be causing it in your
case. It seems more likely to have been something like this than random
memory corruption though.
johannes
^ permalink raw reply
* [PATCH 2/2] staging: vt6656: device.h unused variables
From: Malcolm Priestley @ 2013-07-30 20:08 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
wACKDuration
wRTSTransmitLen
byRTSServiceField
byRTSSignalField
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/device.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/vt6656/device.h b/drivers/staging/vt6656/device.h
index 5324c24..4986910 100644
--- a/drivers/staging/vt6656/device.h
+++ b/drivers/staging/vt6656/device.h
@@ -591,11 +591,6 @@ struct vnt_private {
u8 abyBSSID[ETH_ALEN];
u8 abyDesireBSSID[ETH_ALEN];
- u16 wACKDuration;
- u16 wRTSTransmitLen;
- u8 byRTSServiceField;
- u8 byRTSSignalField;
-
u32 dwMaxReceiveLifetime; /* dot11MaxReceiveLifetime */
int bCCK;
--
1.8.1.2
^ permalink raw reply related
* [PATCH v3] Documentation: dt: bindings: TI WiLink modules
From: Luciano Coelho @ 2013-07-30 20:21 UTC (permalink / raw)
To: devicetree, linux-doc
Cc: mturquette, mark.rutland, balbi, grant.likely, rob.herring,
linux-kernel, linux-omap, linux-wireless, linux-arm-kernel, tony,
nm, laurent.pinchart
Add device tree bindings documentation for the TI WiLink modules.
Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
modules is supported.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
.../devicetree/bindings/net/wireless/ti-wilink.txt | 68 ++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
new file mode 100644
index 0000000..aafebb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
@@ -0,0 +1,68 @@
+TI WiLink Wireless Modules Device Tree Bindings
+===============================================
+
+The WiLink modules provide wireless connectivity, such as WLAN,
+Bluetooth, FM and NFC.
+
+There are several different modules available, which can be grouped by
+their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not
+currently supported with device tree.
+
+Currently, only the WLAN portion of the modules is supported with
+device tree.
+
+Required properties:
+--------------------
+
+- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
+- interrupt-parent: the interrupt controller
+- interrupts: out-of-band WLAN interrupt
+ See the interrupt controller's bindings documentation for
+ detailed definition.
+
+Optional properties:
+--------------------
+
+- clocks: list of clocks needed by the chip as follows:
+
+ refclock: the internal WLAN reference clock frequency (required for
+ WiLink6 and WiLink7; not used for WiLink8).
+
+ tcxoclock: the internal WLAN TCXO clock frequency (required for
+ WiLink7 not used for WiLink6 and WiLink8).
+
+ The clocks must be defined and named accordingly. For example:
+
+ clocks = <&refclock>
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <38400000>;
+ };
+
+ Some modules that contain the WiLink chip provide clocks in the
+ module itself. In this case, we define a "ti,wilink-clock" as shown
+ above. But any other clock could in theory be used, so the proper
+ clock definition should be used.
+
+
+Example:
+--------
+
+Example definition that can be used in OMAP4 Panda:
+
+wlan {
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <38400000>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3.11] nl80211: fix another nl80211_fam.attrbuf race
From: Johannes Berg @ 2013-07-30 20:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Hutchings, Johannes Berg
In-Reply-To: <1375211931.2664.21.camel@deadeye.wl.decadent.org.uk>
From: Johannes Berg <johannes.berg@intel.com>
This is similar to the race Linus had reported, but in this case
it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy
index in cb->args[0] as it is and thus parses the message over
and over again instead of just once because 0 is the first valid
wiphy index. Similar code in nl80211_testmode_dump() correctly
offsets the wiphy_index by 1, do that here as well.
Cc: stable@vger.kernel.org
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 25d217d..3fcba69 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -441,10 +441,12 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
goto out_unlock;
}
*rdev = wiphy_to_dev((*wdev)->wiphy);
- cb->args[0] = (*rdev)->wiphy_idx;
+ /* 0 is the first index - add 1 to parse only once */
+ cb->args[0] = (*rdev)->wiphy_idx + 1;
cb->args[1] = (*wdev)->identifier;
} else {
- struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0]);
+ /* subtract the 1 again here */
+ struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0] - 1);
struct wireless_dev *tmp;
if (!wiphy) {
--
1.8.0
^ permalink raw reply related
* Re: Oops in nl80211_set_reg, Linux 3.10.3
From: Johannes Berg @ 2013-07-30 20:38 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-wireless
In-Reply-To: <1375214899.8176.4.camel@jlt4.sipsolutions.net>
On Tue, 2013-07-30 at 22:08 +0200, Johannes Berg wrote:
> I don't see a similar issue with the other code that uses
> nl80211_fam.attrbuf
That's just because I'm blind -- it *looks* correct but isn't.. patch
coming.
johannes
^ permalink raw reply
* [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
Hi,
In v2: use IRQ_TYPE_LEVEL_HIGH when defining the interrupts, as
suggested by Laurent.
These patches add the necessary DT configuration to use the WLAN part
of WiLink on OMAP4 Pandaboard and on OMAP4-SDP (including Blaze).
I've tested these changes on Panda and it works fine. But I couldn't
test the OMAP4 SDP changes properly on 3.11-rc3 because I'm having
problems with clocks and SDIO stuff. So it's pretty much just
compiled tested. I've tried this (without the new clock definition
stuff) on Blaze with 3.10 and it was working, though.
Please take a look and let me know what you think.
Luca.
Luciano Coelho (4):
ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
arm: dts: omap4-panda-common: add WiLink6 device tree nodes
ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
arm: dts: omap4-sdp: add WiLink7 device tree node
arch/arm/boot/dts/omap4-panda-common.dtsi | 46 +++++++++++++++++++++++++++-
arch/arm/boot/dts/omap4-sdp.dts | 50 +++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+), 1 deletion(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH v2 2/4] arm: dts: omap4-panda-common: add WiLink6 device tree nodes
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add the WiLink device tree nodes. On omap4-panda, a WiLink6 module is
connected on MMC5 and a GPIO interrupt is used. The refclock
frequency is 38.4MHz.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..59a797d 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -5,6 +5,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include <dt-bindings/interrupt-controller/irq.h>
#include "elpida_ecb240abacn.dtsi"
/ {
@@ -117,6 +118,20 @@
startup-delay-us = <70000>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <38400000>;
+ };
+ };
};
&omap4_pmx_wkup {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
*/
clock-frequency = <19200000>;
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio2 11 0>; /* gpio line 43 */
+ startup-delay-us = <70000>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -132,6 +142,7 @@
&dss_hdmi_pins
&tpd12s015_pins
&hsusbb1_pins
+ &wilink_pins
>;
twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x66 0x3 /* gpio_43 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -314,8 +338,13 @@
};
&mmc5 {
- ti,non-removable;
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 4/4] arm: dts: omap4-sdp: add WiLink7 device tree node
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add appropriate device tree node for Blaze's WiLink7 module. It uses
a GPIO as interrupt, so configure the gpio2 node as interrupt parent
and assign the corresponding GPIO. Additionally, add the clock
frequencies used by the module.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..63f1af1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -7,6 +7,7 @@
*/
/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
#include "omap443x.dtsi"
#include "elpida_ecb240abacn.dtsi"
@@ -150,6 +151,26 @@
startup-delay-us = <70000>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink7";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock &tcxoclock>;
+ clock-names = "refclock tcxoclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ tcxoclock: tcxoclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+ };
};
&omap4_pmx_wkup {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..3845615 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,16 @@
"DMic", "Digital Mic",
"Digital Mic", "Digital Mic1 Bias";
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio2 22 0>; /* gpio line 54 */
+ startup-delay-us = <70000>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -166,6 +176,7 @@
&mcbsp2_pins
&dss_hdmi_pins
&tpd12s015_pins
+ &wilink_pins
>;
uart2_pins: pinmux_uart2_pins {
@@ -295,6 +306,19 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x7c 0x3 /* gpio_54 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -420,8 +444,13 @@
};
&mmc5 {
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 15/30] iwlwifi: mvm: reprobe device on firmware error during restart
From: Eliad Peller @ 2013-07-30 21:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1374827327-3464-16-git-send-email-johannes@sipsolutions.net>
On Fri, Jul 26, 2013 at 11:28 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> If we get a firmware error during restart, we currently abandon any
> hope and simply fail, getting stuck until the driver is reloaded.
> Unfortunately, there isn't really much else we can do since restart
> will likely continue to fail, and asking mac80211 for disconnection
> just causes more error.
>
> To allow the user to at least set up the device again completely
> from scratch, reprobe the device and in doing so completely destroy
> any mac80211/driver state.
>
> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
[...]
> + /*
> + * get a module reference to avoid doing this while unloading
> + * anyway and to avoid scheduling a work with code that's
> + * being removed.
> + */
> + if (!try_module_get(THIS_MODULE)) {
> + IWL_ERR(mvm, "Module is being unloaded - abort\n");
> + return;
> + }
> +
> + reprobe = kzalloc(sizeof(*reprobe), GFP_ATOMIC);
> + if (!reprobe)
> + return;
missing module_put() :)
Eliad.
^ permalink raw reply
* Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
From: Mike Turquette @ 2013-07-30 22:35 UTC (permalink / raw)
To: Luciano Coelho, linux-wireless, tony, nsekhar
Cc: coelho, luca, mark.rutland, balbi, grant.likely, rob.herring,
devicetree-discuss, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, nm, martinez.javier
In-Reply-To: <1375189476-21557-7-git-send-email-coelho@ti.com>
Quoting Luciano Coelho (2013-07-30 06:04:34)
> +static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
> + { .compatible = "ti,wilink-clock" },
> +};
> +
> static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> {
> struct wl12xx_platform_data *pdata;
> struct device_node *np = dev->of_node;
> + struct device_node *clock_node;
>
> if (!np) {
> np = of_find_matching_node(NULL, dev->driver->of_match_table);
> @@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> goto out_free;
> }
>
> + for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
> + of_fixed_clk_setup(clock_node);
Hi Luciano,
Any reason for establishing your own compatible string if you just plan
to use the fixed rate clock? You could just use "fixed-clock" compatible
in your DTS.
I will be posting patches this week which makes the fixed-rate clock a
proper driver and matches that compatible string to instantiate those
clocks. That means that your driver could probably remove the clock
setup code completely.
Regards,
Mike
> +
> goto out;
>
> out_free:
> --
> 1.8.3.2
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-30 22:48 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Hector Palacios, linux-wireless, linux-bluetooth@vger.kernel.org,
gustavo@padovan.org, johan.hedberg@gmail.com, mcgrof,
linux-kernel@vger.kernel.org, surajs@qca.qualcomm.com, jjohnson,
Adrian Chadd, ddahlby, Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <2C94C740-76BA-4058-B0D7-C37D44875CA1@holtmann.org>
CC'ing linux-wireless as ROM patching is mentioned and in so far as
802.11 mobile is concerned this is a pretty frequent practice there
as well so figured we'd tie in the conversations.
On Tue, Jul 30, 2013 at 03:05:18PM -0700, Marcel Holtmann wrote:
> Hi Luis,
>
> >> This brings an interesting question: shouldn't the firmware download
> >> part be isolated from the USB driver? After all, I want to
> >> communicate with a UART bluetooth chip.
> >
> > There are a few BT firmware upload modules (last I checked at least 2),
> > I believe it should be possible to stuff all that code a shared
> > module or even as FreeBSD does it -- treat fw uploading in userspace,
> > however just keep in mind for quirks [0]. So patches welcomed.
>
> it really depends on what kind of patching or firmware download has to be done.
>
> For all the ROM patching via HCI commands, we explicitly added support
> for setup stage
This stage is what is I was referring to.
> and exposed a standard way of getting in front of
> Bluetooth core init sequence.
Nice.
> An example here would be the Intel
> Bluetooth devices that require ROM patching. This can be useful for
> many Bluetooth devices that are generally USB transport standard
> compliant, but need a few extra commands of vendor setup.
Interesting. I believe for 802.11 we just throw in a bunch of ROM
patching onto the 802.11 driver_firwmare.fw file and then assume
the driver can do the right thing. I however haven't worked on that so I
am curious if someone more familiar with this can provide details of
how that happens. I do know that the 802.11 mobile drivers get tons of
firmware updates because of this exact architectural choice and do
wonder how we can easily keep up with the firmware updates in meaninful
way to linux-firwmare.
How often do the ROM patches get updated? And do the HCI commands
trigger a userspace event?
> We are planning to take one extra step and split this into a
> mini-driver approach similar to what has been done for usbnet, but we
> are not there yet.
Neat. Perhaps we need something that we can share with 802.11 or other
hardare I highly doubt we're the only ones patching ROM. Don't we even
patch up core CPUs? I'm wondering if firmware_class could be expanded to
support serialized ROM patching. The biggest hurdle I see with splititng
ROM patching from a single firmware is serializing that, addressing
revision dependencies and of course kernel dependencies.
I've thrown this on the list of topics for the next wireless summit
at New Orleans.
> However the ROM patching drivers need to be in the kernel since
> otherwise they will race with the core init sequence.
Sure and depending on the architecture -- if this is kicked off to
userspace helpers or not then we may need to consider dbus in
kernel thing to help with speed / races, dependenecies / async
loading, -EPROBE_DEFER, etc.
> There are also just firmware download drivers that do nothing else
> than just loading the firmware. And here it can be done via userspace
> or kernel space. In the Bluetooth world we have seen both, but
> generally the kernel ones stayed around while the userspace ones had a
> hard time to work with udev, libusb, libusb1 etc.
Ah I see. Perhaps we can address this once we get some form of dbus in
kernel.
> For UART based drivers it is a little bit different since we had to
> bring up the line discipline from userspace anyway and configure all
> the UART parameters. For these drivers the firmware download or ROM
> patching has been done normally via userspace since there is full
> exclusive access before the Bluetooth subsystem knows about the
> device.
Is this something that dbus in kernel can help clean up a bit?
> With the newly introduced setup stage, the drivers could actually
> share the setup handling for UART and USB based devices. Not sure if
> any vendor is going for this approach.
Interesting... Is the architecture documented somewhere? Is this
upstream already?
Luis
^ permalink raw reply
* Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
From: Luciano Coelho @ 2013-07-30 23:04 UTC (permalink / raw)
To: Mike Turquette
Cc: linux-wireless, tony, nsekhar, mark.rutland, balbi, grant.likely,
rob.herring, devicetree-discuss, linux-doc, linux-kernel,
linux-omap, linux-arm-kernel, nm, martinez.javier
In-Reply-To: <20130730223535.5270.39864@quantum>
On Tue, 2013-07-30 at 15:35 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-30 06:04:34)
> > +static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
> > + { .compatible = "ti,wilink-clock" },
> > +};
> > +
> > static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> > {
> > struct wl12xx_platform_data *pdata;
> > struct device_node *np = dev->of_node;
> > + struct device_node *clock_node;
> >
> > if (!np) {
> > np = of_find_matching_node(NULL, dev->driver->of_match_table);
> > @@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> > goto out_free;
> > }
> >
> > + for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
> > + of_fixed_clk_setup(clock_node);
>
> Hi Luciano,
Hi Mike,
> Any reason for establishing your own compatible string if you just plan
> to use the fixed rate clock? You could just use "fixed-clock" compatible
> in your DTS.
The reason is that I can't call of_clk_init(), because this function is
not exported and my module can't use it. I would have to link with the
clk code to be able to call it.
Also, I reckoned that, since these clock cannot be used by anyone else
than the WiLink module itself, it would make sense to have a different
compatible string.
> I will be posting patches this week which makes the fixed-rate clock a
> proper driver and matches that compatible string to instantiate those
> clocks. That means that your driver could probably remove the clock
> setup code completely.
Okay, if this is done, then I could probably use "fixed-clock" directly,
since the driver itself will take care of going through the DT and
initializing all the fixed-clocks.
--
Luca.
^ permalink raw reply
* Re: [GIT] [3.11] NFC fixes
From: Samuel Ortiz @ 2013-07-30 23:48 UTC (permalink / raw)
To: John W. Linville; +Cc: Linux NFC, Linux Wireless
In-Reply-To: <20130730130843.GA28677@zurbaran>
Hi John,
On Tue, Jul 30, 2013 at 03:08:43PM +0200, Samuel Ortiz wrote:
> Hi John,
>
> This is the first NFC fixes pull request for 3.11.
Forget about this one, I'm going to send another pull request.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Greg Kroah-Hartman @ 2013-07-30 23:55 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings
In-Reply-To: <20130730224809.GN17130@pogo>
On Tue, Jul 30, 2013 at 03:48:09PM -0700, Luis R. Rodriguez wrote:
> > We are planning to take one extra step and split this into a
> > mini-driver approach similar to what has been done for usbnet, but we
> > are not there yet.
>
> Neat. Perhaps we need something that we can share with 802.11 or other
> hardare I highly doubt we're the only ones patching ROM. Don't we even
> patch up core CPUs? I'm wondering if firmware_class could be expanded to
> support serialized ROM patching. The biggest hurdle I see with splititng
> ROM patching from a single firmware is serializing that, addressing
> revision dependencies and of course kernel dependencies.
What does the firmware_class need to do here that it doesn't do today?
> > However the ROM patching drivers need to be in the kernel since
> > otherwise they will race with the core init sequence.
>
> Sure and depending on the architecture -- if this is kicked off to
> userspace helpers or not then we may need to consider dbus in
> kernel thing to help with speed / races, dependenecies / async
> loading, -EPROBE_DEFER, etc.
How would dbus in the kernel change anything here?
> > There are also just firmware download drivers that do nothing else
> > than just loading the firmware. And here it can be done via userspace
> > or kernel space. In the Bluetooth world we have seen both, but
> > generally the kernel ones stayed around while the userspace ones had a
> > hard time to work with udev, libusb, libusb1 etc.
>
> Ah I see. Perhaps we can address this once we get some form of dbus in
> kernel.
The kernel directly loads firmware from the filesystem now, no userspace
helpers are involved, so no need for udev, libusb, etc. And as such, no
need for any "dbus" in the kernel to do this either.
> > For UART based drivers it is a little bit different since we had to
> > bring up the line discipline from userspace anyway and configure all
> > the UART parameters. For these drivers the firmware download or ROM
> > patching has been done normally via userspace since there is full
> > exclusive access before the Bluetooth subsystem knows about the
> > device.
>
> Is this something that dbus in kernel can help clean up a bit?
I don't understand how it could, please explain.
Also note, for those not knowing, we have been working on dbus in the
kernel (google "kdbus" for the github repo), but it is all
outward-facing (i.e. userspace using the kdbus code to interact with
other processes with a dbus-like protocol, not for in-kernel dbus
things, although adding it wouldn't be that hard, just really strange.
thanks,
greg k-h
^ permalink raw reply
* [GIT] [NFC] 3.11 fixes
From: Samuel Ortiz @ 2013-07-30 23:59 UTC (permalink / raw)
To: John W. Linville; +Cc: Linux Wireless, Linux NFC
Hi John,
This is the second NFC fixes pull request for 3.11.
We have:
1) A build failure fix for the NCI SPI transport layer due to a
missing CRC_CCITT Kconfig dependency.
2) A netlink command rename: CMD_FW_UPLOAD was merged during the 3.11
merge window but the typical terminology for loading a firmware to a
target is firmware download rather than upload. In order to avoid any
confusion in a file exported to userspace, we rename this command to
CMD_FW_DOWNLOAD.
I realize 2) might not meet the net.git criteria for what fixes are. If
you don't want to take it then I'll have to push it through the
3.12 merge window. If that's the case, and you only want to take 1) then
please use tags/nfc-3.11-1 instead of tags/nfc-3.11-2 in your pull URL.
The following changes since commit 64b6f46f1141ad938e354f37af62e28da972e8eb:
ath9k_hw: Fix multicast search for AR9002 family (2013-07-18 16:22:00 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes.git tags/nfc-fixes-3.11-2
for you to fetch changes up to 9ea7187c53f63e31f2d1b2b1e474e31808565009:
NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD (2013-07-31 01:19:43 +0200)
----------------------------------------------------------------
Frederic Danis (1):
NFC: Fix NCI over SPI build
Samuel Ortiz (1):
NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD
include/net/nfc/hci.h | 2 +-
include/net/nfc/nfc.h | 4 ++--
include/uapi/linux/nfc.h | 6 +++---
net/nfc/core.c | 20 ++++++++++----------
net/nfc/hci/core.c | 8 ++++----
net/nfc/nci/Kconfig | 1 +
net/nfc/netlink.c | 12 ++++++------
net/nfc/nfc.h | 6 +++---
8 files changed, 30 insertions(+), 29 deletions(-)
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH] mwifiex: fix adapter pointer dereference issue
From: Bing Zhao @ 2013-07-31 0:18 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Dan Carpenter, Amitkumar Karwar, Avinash Patil,
Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Amitkumar Karwar <akarwar@marvell.com>
It has introduced by recent commit 6b41f941d7cd: "mwifiex:
handle driver initialization error paths" which adds error
path handling for mwifiex_fw_dpc().
release_firmware(adapter->*) is called for success as well
as failure paths. In failure paths, adapter is already freed
at this point.
The issue is fixed by moving mwifiex_free_adapter() call.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/main.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 5644c7f..3402bff 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -414,6 +414,8 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
struct mwifiex_private *priv;
struct mwifiex_adapter *adapter = context;
struct mwifiex_fw_image fw;
+ struct semaphore *sem = adapter->card_sem;
+ bool init_failed = false;
if (!firmware) {
dev_err(adapter->dev,
@@ -528,15 +530,20 @@ err_dnld_fw:
}
adapter->surprise_removed = true;
mwifiex_terminate_workqueue(adapter);
- mwifiex_free_adapter(adapter);
+ init_failed = true;
done:
if (adapter->cal_data) {
release_firmware(adapter->cal_data);
adapter->cal_data = NULL;
}
- release_firmware(adapter->firmware);
+ if (adapter->firmware) {
+ release_firmware(adapter->firmware);
+ adapter->firmware = NULL;
+ }
complete(&adapter->fw_load);
- up(adapter->card_sem);
+ if (init_failed)
+ mwifiex_free_adapter(adapter);
+ up(sem);
return;
}
--
1.8.2.3
^ permalink raw reply related
* [PATCH] mwifiex: populate rates in probe request using cfg80211_scan_request
From: Bing Zhao @ 2013-07-31 0:18 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Avinash Patil, Amitkumar Karwar,
Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Avinash Patil <patila@marvell.com>
Whenever available, use cfg80211_scan_request to populates rates
in outgoing probe request. This will help to advertise band specific
rates and fix an issue where 11b rates were advertised in probe
request going out on 11a band.
This will also ensure that we do not advertise 11b rates while P2P
scan is going on.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/cfp.c | 42 ++++++++++++++++++++++---
drivers/net/wireless/mwifiex/main.h | 2 ++
drivers/net/wireless/mwifiex/scan.c | 63 +++++++++++++++++++++++++++----------
3 files changed, 85 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfp.c b/drivers/net/wireless/mwifiex/cfp.c
index 5178c46..9eefacb 100644
--- a/drivers/net/wireless/mwifiex/cfp.c
+++ b/drivers/net/wireless/mwifiex/cfp.c
@@ -404,11 +404,43 @@ mwifiex_is_rate_auto(struct mwifiex_private *priv)
return false;
}
-/*
- * This function gets the supported data rates.
- *
- * The function works in both Ad-Hoc and infra mode by printing the
- * band and returning the data rates.
+/* This function gets the supported data rates from bitmask inside
+ * cfg80211_scan_request.
+ */
+u32 mwifiex_get_rates_from_cfg80211(struct mwifiex_private *priv,
+ u8 *rates, u8 radio_type)
+{
+ struct wiphy *wiphy = priv->adapter->wiphy;
+ struct cfg80211_scan_request *request = priv->scan_request;
+ u32 num_rates, rate_mask;
+ struct ieee80211_supported_band *sband;
+ int i;
+
+ if (radio_type) {
+ sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+ if (WARN_ON_ONCE(!sband))
+ return 0;
+ rate_mask = request->rates[IEEE80211_BAND_5GHZ];
+ } else {
+ sband = wiphy->bands[IEEE80211_BAND_2GHZ];
+ if (WARN_ON_ONCE(!sband))
+ return 0;
+ rate_mask = request->rates[IEEE80211_BAND_2GHZ];
+ }
+
+ num_rates = 0;
+ for (i = 0; i < sband->n_bitrates; i++) {
+ if ((BIT(i) & rate_mask) == 0)
+ continue; /* skip rate */
+ rates[num_rates++] = (u8)(sband->bitrates[i].bitrate / 5);
+ }
+
+ return num_rates;
+}
+
+/* This function gets the supported data rates. The function works in
+ * both Ad-Hoc and infra mode by printing the band and returning the
+ * data rates.
*/
u32 mwifiex_get_supported_rates(struct mwifiex_private *priv, u8 *rates)
{
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 48685e7..cf961d9 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -903,6 +903,8 @@ int mwifiex_cmd_append_vsie_tlv(struct mwifiex_private *priv, u16 vsie_mask,
u32 mwifiex_get_active_data_rates(struct mwifiex_private *priv,
u8 *rates);
u32 mwifiex_get_supported_rates(struct mwifiex_private *priv, u8 *rates);
+u32 mwifiex_get_rates_from_cfg80211(struct mwifiex_private *priv,
+ u8 *rates, u8 radio_type);
u8 mwifiex_is_rate_auto(struct mwifiex_private *priv);
extern u16 region_code_index[MWIFIEX_MAX_REGION_CODE];
void mwifiex_save_curr_bcn(struct mwifiex_private *priv);
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index c447d9b..8cf7d50 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -543,6 +543,37 @@ mwifiex_scan_create_channel_list(struct mwifiex_private *priv,
return chan_idx;
}
+/* This function appends rate TLV to scan config command. */
+static int
+mwifiex_append_rate_tlv(struct mwifiex_private *priv,
+ struct mwifiex_scan_cmd_config *scan_cfg_out,
+ u8 radio)
+{
+ struct mwifiex_ie_types_rates_param_set *rates_tlv;
+ u8 rates[MWIFIEX_SUPPORTED_RATES], *tlv_pos;
+ u32 rates_size;
+
+ memset(rates, 0, sizeof(rates));
+
+ tlv_pos = (u8 *)scan_cfg_out->tlv_buf + scan_cfg_out->tlv_buf_len;
+
+ if (priv->scan_request)
+ rates_size = mwifiex_get_rates_from_cfg80211(priv, rates,
+ radio);
+ else
+ rates_size = mwifiex_get_supported_rates(priv, rates);
+
+ dev_dbg(priv->adapter->dev, "info: SCAN_CMD: Rates size = %d\n",
+ rates_size);
+ rates_tlv = (struct mwifiex_ie_types_rates_param_set *)tlv_pos;
+ rates_tlv->header.type = cpu_to_le16(WLAN_EID_SUPP_RATES);
+ rates_tlv->header.len = cpu_to_le16((u16) rates_size);
+ memcpy(rates_tlv->rates, rates, rates_size);
+ scan_cfg_out->tlv_buf_len += sizeof(rates_tlv->header) + rates_size;
+
+ return rates_size;
+}
+
/*
* This function constructs and sends multiple scan config commands to
* the firmware.
@@ -564,9 +595,10 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
struct mwifiex_chan_scan_param_set *tmp_chan_list;
struct mwifiex_chan_scan_param_set *start_chan;
- u32 tlv_idx;
+ u32 tlv_idx, rates_size;
u32 total_scan_time;
u32 done_early;
+ u8 radio_type;
if (!scan_cfg_out || !chan_tlv_out || !scan_chan_list) {
dev_dbg(priv->adapter->dev,
@@ -591,6 +623,7 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
tlv_idx = 0;
total_scan_time = 0;
+ radio_type = 0;
chan_tlv_out->header.len = 0;
start_chan = tmp_chan_list;
done_early = false;
@@ -612,6 +645,7 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
continue;
}
+ radio_type = tmp_chan_list->radio_type;
dev_dbg(priv->adapter->dev,
"info: Scan: Chan(%3d), Radio(%d),"
" Mode(%d, %d), Dur(%d)\n",
@@ -692,6 +726,9 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
break;
}
+ rates_size = mwifiex_append_rate_tlv(priv, scan_cfg_out,
+ radio_type);
+
priv->adapter->scan_channels = start_chan;
/* Send the scan command to the firmware with the specified
@@ -699,6 +736,14 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
ret = mwifiex_send_cmd_async(priv, HostCmd_CMD_802_11_SCAN,
HostCmd_ACT_GEN_SET, 0,
scan_cfg_out);
+
+ /* rate IE is updated per scan command but same starting
+ * pointer is used each time so that rate IE from earlier
+ * scan_cfg_out->buf is overwritten with new one.
+ */
+ scan_cfg_out->tlv_buf_len -=
+ sizeof(struct mwifiex_ie_types_header) + rates_size;
+
if (ret)
break;
}
@@ -741,7 +786,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
struct mwifiex_adapter *adapter = priv->adapter;
struct mwifiex_ie_types_num_probes *num_probes_tlv;
struct mwifiex_ie_types_wildcard_ssid_params *wildcard_ssid_tlv;
- struct mwifiex_ie_types_rates_param_set *rates_tlv;
u8 *tlv_pos;
u32 num_probes;
u32 ssid_len;
@@ -753,8 +797,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
u8 radio_type;
int i;
u8 ssid_filter;
- u8 rates[MWIFIEX_SUPPORTED_RATES];
- u32 rates_size;
struct mwifiex_ie_types_htcap *ht_cap;
/* The tlv_buf_len is calculated for each scan command. The TLVs added
@@ -889,19 +931,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
}
- /* Append rates tlv */
- memset(rates, 0, sizeof(rates));
-
- rates_size = mwifiex_get_supported_rates(priv, rates);
-
- rates_tlv = (struct mwifiex_ie_types_rates_param_set *) tlv_pos;
- rates_tlv->header.type = cpu_to_le16(WLAN_EID_SUPP_RATES);
- rates_tlv->header.len = cpu_to_le16((u16) rates_size);
- memcpy(rates_tlv->rates, rates, rates_size);
- tlv_pos += sizeof(rates_tlv->header) + rates_size;
-
- dev_dbg(adapter->dev, "info: SCAN_CMD: Rates size = %d\n", rates_size);
-
if (ISSUPP_11NENABLED(priv->adapter->fw_cap_info) &&
(priv->adapter->config_bands & BAND_GN ||
priv->adapter->config_bands & BAND_AN)) {
--
1.8.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox