aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/syscall-counts.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2013-02-18mwifiex: coding style cleanup in bss parameter updateYogesh Ashok Powar1-10/+5
They all can make one line. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18mwifiex: fix empty TX ring check for PCIe8897 while unloading driverAvinash Patil1-4/+1
While unloading driver, we free all pending TX packets by flushing TX ring. There is unhandled case for PCIE8897 while checking for ring empty condition. This patch adds the handling by calling mwifiex_pcie_txbd_empty(). Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18iwlwifi: dvm: improve (again) the prints in reclaim pathEmmanuel Grumbach2-15/+37
I removed a bit too much info last time. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: dvm: fix delayed enter to CT-kill bugEytan Lifshitz1-1/+1
Theoretically, the card may not enter CTKILL: In case the timer that iwl_prepare_ct_kill_task is setting, will expire before tt->state revert to its previous state. Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: Reserve MAC id 0 for managed interfacesIlan Peer1-0/+4
Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: Fix resource allocation for P2P DeviceIlan Peer1-3/+3
The time event data structures are required also for P2P Device interface. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: Set the scan type according to the vif typeIlan Peer1-1/+6
The FW can differentiate between scans, according to the interface type on which the scan was issues. Supply the interfaces type information to the FW. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: fix time event command handling raceJohannes Berg1-1/+6
Occasionally, we would run into this warning: iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601 iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9 iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9 iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601 iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1 wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3) ------------[ cut here ]------------ WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]() Modules linked in: [...] Call Trace: [<c1046e42>] warn_slowpath_common+0x72/0xa0 [<c1046e92>] warn_slowpath_null+0x22/0x30 [<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm] [<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm] [<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm] [<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211] The reason is a problem with asynchronous vs. synchronous commands, what happens here is the following: * TE 0x2601 is removed, the TIME_EVENT_CMD for that is async * a new TE (will be 0x2701) is created, the TIME_EVENT_CMD for that is sync and also uses a notification wait for the response (to avoid another race condition) * the response for the TE 0x2601 removal comes from the firmware, and is handled by the notification wait handler that's really waiting for the second response, but can't tell the difference, we therefore see the message "TIME_EVENT_CMD response - UID = 0x2601" instead of "TIME_EVENT_CMD response - UID = 0x2701". Fix this issue by making the TE removal synchronous as well, this means that we wait for the response to that command first, before there's any chance of sending a new one. Also, to detect such issues more easily in the future, add a warning to the notification handler that detects them. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: add debug statement to time event addJohannes Berg1-0/+3
This is helpful for debugging the time event warning, but also in general to see what's going on. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: fix GO powersave client manipulationJohannes Berg3-10/+16
All station commands must include a valid MAC ID, the ID 0 is randomly valid in some cases, but we must set the ID properly. Do that by passing the right station and using its mac_id_n_color. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: program DTIM timings properlyJohannes Berg3-3/+38
For the firmware to know when DTIM beacons arrive we have to program the DTIM time in TSF and system time in the MAC context. Since mac80211 now tracks the different times (on demand), this becomes easy. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: fix merge errorJohannes Berg1-1/+0
The iwlwifi-next tree removed IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC while the mac80211-next tree removed Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18cfg80211: fix station change if TDLS isn't supportedJohannes Berg1-9/+0
Larry noticed (and bisected) that commit df881293c6ba9a12868491a717b25 "cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_station" broke secure connections. This is is the case only for drivers that don't support TDLS, where any kind of change, even just the change of authorized flag that is required for normal operation, was rejected now. To fix this, remove the checks. I have some patches that will add proper verification for all the different cases later. Cc: Jouni Malinen <j@w1.fi> Bisected-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: don't spam mesh probe response messagesThomas Pedersen1-1/+0
If mesh plink debugging is enabled, this gets annoying in a crowded environment, fast. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: stringify mesh peering eventsThomas Pedersen1-14/+24
Convert mesh peering events into strings and make the debug output a little easier to read. Also stop printing the llid and plid since these don't change across peering states and are random numbers anyway so they just amount to noise. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: clean up mesh HT operationThomas Pedersen2-40/+24
ieee80211_ht_cap_ie_to_sta_ht_cap() will clean up the ht_supported flag and station bandwidth field for us if the peer beacon doesn't have an HT capability element (is operating as non-HT). Also, we don't really need a special station ch_width member to track the station operating mode any more so use sta.bandwidth instead. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: fix harmless station flush warningJohannes Berg1-2/+3
If an interface is set down while authenticating or associating, there's a station entry that will be removed by the flushing in do_stop() and that will cause a warning. It's otherwise harmless, but avoid the warning by calling ieee80211_mgd_stop() first. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18cfg80211: add correct docbook entriesJohannes Berg1-2/+2
Update the 802.11 book to list the correct data structures. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: Fix incorrect use of STA_PR_FMT in trace pointsSeth Forshee1-3/+3
Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1". Change these to STA_PR_ARG. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: enable vif.cab_queue for meshBob Copeland1-1/+2
Since mesh powersaving was added, pending bcast/mcast frames may go out the CAB queue now. Unfortunately, the queue was only set up for AP mode, so we would try to tx on the IEEE80211_INVAL_HW_QUEUE. Allow cab_queue for mesh interfaces as well. Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG): WARNING: at net/mac80211/tx.c:1223 __ieee80211_tx+0x162/0x35f [mac80211]() Modules linked in: mac80211_hwsim mac80211 cfg80211 [...] Pid: 3085, comm: avahi-daemon Tainted: G W 3.8.0-rc1+ #377 Call Trace: [<ffffffff81045c20>] warn_slowpath_common+0x83/0x9c [<ffffffff81045c53>] warn_slowpath_null+0x1a/0x1c [<ffffffffa083aef0>] __ieee80211_tx+0x162/0x35f [mac80211] [<ffffffffa083cb1d>] ieee80211_tx+0xd3/0xf9 [mac80211] [<ffffffffa083cc0f>] ieee80211_xmit+0xcc/0xd5 [mac80211] [<ffffffffa083db59>] ieee80211_subif_start_xmit+0xc53/0xcd8 [mac80211] [<ffffffff81319acd>] dev_hard_start_xmit+0x259/0x3ce [<ffffffff81333d6b>] sch_direct_xmit+0x74/0x17d [<ffffffff8131a0b1>] dev_queue_xmit+0x230/0x414 [<ffffffff8134877a>] ip_finish_output2+0x348/0x3aa [<ffffffff81349029>] ip_finish_output+0x6c/0x71 [<ffffffff81349046>] NF_HOOK_COND.constprop.44+0x18/0x58 [<ffffffff8134a03a>] ip_mc_output+0x134/0x13c [<ffffffff8134835a>] dst_output+0x18/0x1c [<ffffffff81349a24>] ip_local_out+0x20/0x24 [<ffffffff8134a8cf>] ip_send_skb+0x16/0x3c [<ffffffff8136bfba>] udp_send_skb+0x254/0x2b9 [<ffffffff8136c85e>] udp_sendmsg+0x5a8/0x7d4 Signed-off-by: Bob Copeland <bob@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: clean up mesh codeJohannes Berg10-263/+252
There's various code with strange indentation, questionable loop and locking constructs, etc. The bigger change is moving the "sdata" argument to the first argument of all functions, like all other mac80211 functions that have one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211_hwsim: ask mac80211 to reserve space for chanctx.drv_privKarl Beldan1-0/+1
Otherwise memory corruption occurs when using channel contexts (ATM when param 'channel' > 1). Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: prevent spurious HT/VHT downgrade messageJohannes Berg1-0/+4
Even when connecting to an AP that doesn't support VHT, and even when the local device doesn't support it either, the downgrade message gets printed. Suppress the message if HT and/or VHT is disabled. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15nl80211: renumber NL80211_FEATURE_FULL_AP_CLIENT_STATEJohannes Berg2-3/+3
Adding the flag to mac80211 already without testing was clearly a mistake, one that we now pay for by having to reserve bit 13 forever. The problem is cfg80211 doesn't allow capability/rate changes for station entries that were added unassociated, so the station entries cannot be set up properly when marked associated. Change the NL80211_FEATURE_FULL_AP_CLIENT_STATE value to make it clear to userspace implementations that all current kernels don't actually support it, even though the previous bit is set, and of course also remove the flag from mac80211 until we test and fix the issues. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_stationJouni Malinen2-11/+85
The information of the peer's capabilities is required for the driver to perform TDLS Peer UAPSD operations. This information of the peer is passed by the supplicant using NL80211_CMD_SET_STATION command. This commit enhances the function nl80211_set_station to pass this information of the peer to the driver in case this command is used with the TDLS peer STA. In addition, make the HT/VHT capability configuration handled more consistently for other STA cases (reject both instead of just HT). Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: Pass station (extended) capability info to kernelJouni Malinen3-0/+54
The information of the peer's capabilities and extended capabilities are required for the driver to perform TDLS Peer UAPSD operations and off channel operations. This information of the peer is passed from user space using NL80211_CMD_SET_STATION command. This commit enhances the function nl80211_set_station to pass the capability information of the peer to the driver. Similarly, there may be need for capability information for other modes, so allow this to be provided with both add_station and change_station. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: advertise operating mode notification capabilityJohannes Berg2-0/+11
Use the new extended capabilities advertising to advertise the fact that operating mode notification is supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: advertise extended capabilities to userspaceJohannes Berg3-0/+29
In many cases, userspace may need to know which of the 802.11 extended capabilities ("Extended Capabilities element") are implemented in the driver or device, to include them e.g. in beacons, assoc request/response or other frames. Add a new nl80211 attribute to hold the extended capabilities bitmap for this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: stop modifying HT SMPS capabilityJohannes Berg11-48/+50
Instead of modifying the HT SMPS capability field for stations, track the SMPS mode explicitly in a new field in the station struct and use it in the drivers that care about it. This simplifies the code using it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: generate mesh probe responsesThomas Pedersen2-2/+63
Mesh interfaces will now respond to any broadcast (or matching directed mesh) probe requests with a probe response. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: cache mesh beaconThomas Pedersen6-65/+171
Previously, the entire mesh beacon would be generated each time the beacon timer fired. Instead generate a beacon head and tail (so the TIM can easily be inserted when mesh power save is on) when starting a mesh or the MBSS parameters change. Also add a mutex for protecting beacon updates and preventing leaks. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: constify IE parsingJohannes Berg9-87/+96
Make all the parsed IE pointers const, and propagate the change to all the users etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15nl80211: advertise HT/VHT channel limitationsJohannes Berg3-1/+31
When drivers or regulatory have limitations on 40, 80 or 160 MHz channels, advertise these to userspace via nl80211. Also add a new feature flag to let userspace know this is supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: allow drivers to selectively disable 80/160 MHzJohannes Berg3-1/+32
Some drivers might support 80 or 160 MHz only on some channels for whatever reason, so allow them to disable these channel widths. Also maintain the new flags when regulatory bandwidth limitations would disable these wide channels. Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: properly track HT/VHT operation changesJohannes Berg1-68/+168
A while ago, I made the mac80211 station code never change the channel type after association. This solved a number of issues but is ultimately wrong, we should react if the AP changes the HT operation IE and switches bandwidth. One of the issues is that we associate as HT40 capable, but if the AP ever switches to 40 MHz we won't be able to receive such frames because we never set our channel to 40 MHz. This addresses this and VHT operation changes. If there's a change that is incompatible with our setup, e.g. if the AP decides to change the channel entirely (and for some reason we still hear the beacon) we'll just disconnect. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: move ieee80211_determine_chantype functionJohannes Berg1-195/+195
The next patch will need it further up in the file, so move it unchanged now. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: add ieee80211_vif_change_bandwidthJohannes Berg3-0/+57
For HT and VHT the current bandwidth can change, add the function ieee80211_vif_change_bandwidth() to take care of this. It returns a failure if the new bandwidth isn't compatible with the existing channel context, the caller has to handle that. When it happens, also inform the driver that the bandwidth changed for this virtual interface (no drivers would actually care today though.) Changing to/from HT/VHT isn't allowed though. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: clean up channel use in ieee80211_config_ht_txJohannes Berg1-11/+3
The channel use is confusing, some uses the channel context and some the bss_conf.chandef. The latter is fine, so get rid of the channel context part. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: disable HT/VHT if AP has no HT/VHT capabilityJohannes Berg1-2/+14
Having HT/VHT operation IEs but not capability IEs leads to a strange situation where we configure the channel to an HT or VHT bandwidth and then can't actually use it. Prevent this by checking that the HT and VHT capability IEs are present as well as the operation IEs; if not, disable HT and/or VHT. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: handle operating mode notif in beacon/assoc responseJohannes Berg5-6/+38
In beacons and association response frames an AP may include an operating mode notification element to advertise changes in the number of spatial streams it can receive. Handle this using the existing function that handles the action frame, but only handle NSS changes, not bandwidth changes which aren't allowed here. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: fix ieee80211_change_chandef nameJohannes Berg1-3/+3
This should be called ieee80211_change_chanctx() since it changes the channel context, not a chandef. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: fix HT/VHT disable flagsJohannes Berg1-2/+2
The code to disable HT and VHT if VHT was advertised without VHT is wrong -- it accidentally uses the wrong flags. Fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: init HT TX data before rate controlJohannes Berg1-20/+19
In case of connection, the station data is initialised from the beacon/probe response first and then updated from the association response. If the latter is different we update the rate control algorithm and driver. Instead of doing it this way, set the station data properly with data from the association response before initializing rate control. Also simplify the code by passing the station pointer. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: handle VHT operating mode notificationJohannes Berg7-10/+128
Handle the operating mode notification action frame. When the supported streams or the bandwidth change let the driver and rate control algorithm know. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: track number of spatial streamsJohannes Berg4-0/+49
With VHT, a station can change the number of spatial streams it can receive on the fly, not unlike spatial multiplexing in HT. Prepare for that by tracking the maximum number of spatial streams it can receive when the connection is established. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15wireless: define operating mode action frameJohannes Berg1-0/+37
Define the action frame format, the VHT category and its action types and the field format and EID for operating mode notifications. The frame may be used outside of VHT context as well, so don't include "VHT" in the names. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40Johannes Berg27-158/+184
For VHT, many more bandwidth changes are possible. As a first step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag in the HT capabilities and instead introduce a bandwidth field indicating the currently usable bandwidth to transmit to the station. Of course, make all drivers use it. To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get the station as an argument, rather than the new capabilities, so it can set up the new bandwidth field. If the station is a VHT station and VHT bandwidth is in use, also set the bandwidth accordingly. Doing this allows us to get rid of the supports_40mhz flag as the HT capabilities now reflect the true capability instead of the current setting. While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not ignore HT cap overrides when MCS TX isn't supported (not that it really happens...) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: pass station to ieee80211_vht_cap_ie_to_sta_vht_capJohannes Berg4-8/+9
Like with HT, make things a bit simpler in future patches by passing the station to ieee80211_vht_cap_ie_to_sta_vht_cap() instead of the vht_cap pointer. Also disable VHT here if HT isn't supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: use spin_lock_bh() for TKIP lockJohannes Berg2-9/+6
Since no driver calls the TKIP functions from interrupt context, there's no need to use spin_lock_irqsave(). Just use spin_lock_bh() (and spin_lock() in the TX path where we're in a BH or they're already disabled.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: use spin_lock_bh() for tim_lockJohannes Berg2-7/+4
There's no need to use _irqsave() as the lock is never used in interrupt context. This also fixes a problem in the iwlwifi MVM driver that calls spin_unlock_bh() within its set_tim() callback. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.