aboutsummaryrefslogtreecommitdiffstats
path: root/git-gui/lib
ModeNameSize
-rw-r--r--about.tcl1929logstatsplainblame
-rw-r--r--blame.tcl34758logstatsplainblame
-rw-r--r--branch.tcl839logstatsplainblame
-rw-r--r--branch_checkout.tcl2254logstatsplainblame
-rw-r--r--branch_create.tcl5438logstatsplainblame
-rw-r--r--branch_delete.tcl3350logstatsplainblame
-rw-r--r--branch_rename.tcl3217logstatsplainblame
-rw-r--r--browser.tcl12298logstatsplainblame
-rw-r--r--checkout_op.tcl14803logstatsplainblame
-rw-r--r--choose_font.tcl4203logstatsplainblame
-rw-r--r--choose_repository.tcl24720logstatsplainblame
-rw-r--r--choose_rev.tcl15183logstatsplainblame
-rw-r--r--class.tcl4511logstatsplainblame
-rw-r--r--commit.tcl11277logstatsplainblame
-rw-r--r--console.tcl4798logstatsplainblame
-rw-r--r--database.tcl3070logstatsplainblame
-rw-r--r--date.tcl1057logstatsplainblame
-rw-r--r--diff.tcl20764logstatsplainblame
-rw-r--r--encoding.tcl16762logstatsplainblame
-rw-r--r--error.tcl2541logstatsplainblame
-rw-r--r--git-gui.ico3638logstatsplainblame
-rw-r--r--index.tcl9921logstatsplainblame
-rw-r--r--logo.tcl2290logstatsplainblame
-rw-r--r--merge.tcl6312logstatsplainblame
-rw-r--r--mergetool.tcl10605logstatsplainblame
-rw-r--r--option.tcl9752logstatsplainblame
-rw-r--r--remote.tcl7206logstatsplainblame
-rw-r--r--remote_add.tcl4597logstatsplainblame
-rw-r--r--remote_branch_delete.tcl8514logstatsplainblame
-rw-r--r--search.tcl4269logstatsplainblame
-rw-r--r--shortcut.tcl3467logstatsplainblame
-rw-r--r--spellcheck.tcl9626logstatsplainblame
-rw-r--r--sshkey.tcl3415logstatsplainblame
-rw-r--r--status_bar.tcl2576logstatsplainblame
-rw-r--r--themed.tcl4891logstatsplainblame
-rw-r--r--tools.tcl3668logstatsplainblame
-rw-r--r--tools_dlg.tcl10051logstatsplainblame
-rw-r--r--transport.tcl5811logstatsplainblame
-rw-r--r--win32.tcl596logstatsplainblame
-rw-r--r--win32_shortcut.js888logstatsplainblame
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-30 19:52:46 +0000
: clear crypto tx tailroom counter upon keys enableLior Cohen3-35/+15 In case we got a fw restart while roaming from encrypted AP to non-encrypted one, we might end up with hitting a warning on the pending counter crypto_tx_tailroom_pending_dec having a non-zero value. The following comment taken from net/mac80211/key.c explains the rational for the delayed tailroom needed: /* * The reason for the delayed tailroom needed decrementing is to * make roaming faster: during roaming, all keys are first deleted * and then new keys are installed. The first new key causes the * crypto_tx_tailroom_needed_cnt to go from 0 to 1, which invokes * the cost of synchronize_net() (which can be slow). Avoid this * by deferring the crypto_tx_tailroom_needed_cnt decrementing on * key removal for a while, so if we roam the value is larger than * zero and no 0->1 transition happens. * * The cost is that if the AP switching was from an AP with keys * to one without, we still allocate tailroom while it would no * longer be needed. However, in the typical (fast) roaming case * within an ESS this usually won't happen. */ The next flow lead to the warning eventually reported as a bug: 1. Disconnect from encrypted AP 2. Set crypto_tx_tailroom_pending_dec = 1 for the key 3. Schedule work 4. Reconnect to non-encrypted AP 5. Add a new key, setting the tailroom counter = 1 6. Got FW restart while pending counter is set ---> hit the warning While on it, the ieee80211_reset_crypto_tx_tailroom() func was merged into its single caller ieee80211_reenable_keys (previously called ieee80211_enable_keys). Also, we reset the crypto_tx_tailroom_pending_dec and remove the counters warning as we just reset both. Signed-off-by: Lior Cohen <lior2.cohen@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-7-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2019-09-11mac80211: remove unnecessary key conditionJohannes Berg1-3/+3 When we reach this point, the key cannot be NULL. Remove the condition that suggests otherwise. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-6-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2019-09-11mac80211: list features in WEP/TKIP disable in better orderJohannes Berg1-1/+1 "HE/HT/VHT" is a bit confusing since really the order of development (and possible support) is different - change this to "HT/VHT/HE". Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-4-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2019-09-11cfg80211: always shut down on HW rfkillJohannes Berg3-9/+11 When the RFKILL subsystem isn't available, then rfkill_blocked() always returns false. In the case of hardware rfkill this will be wrong though, as if the hardware reported being killed then it cannot operate any longer. Since we only ever call the rfkill_sync work in this case, just rename it to rfkill_block and always pass "true" for the blocked parameter, rather than passing rfkill_blocked(). We rely on the underlying driver to still reject any new attempt to bring up the device by itself. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-2-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2019-09-11mac80211: vht: add support VHT EXT NSS BW in parsing VHTMordechay Goodstein1-1/+9 This fixes was missed in parsing the vht capabilities max bw support. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: e80d642552a3 ("mac80211: copy VHT EXT NSS BW Support/Capable data to station") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830114057.22197-1-luca@coelho.fi Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2019-09-11cfg80211: fix boundary value in ieee80211_frequency_to_channel()Arend van Spriel1-1/+1 The boundary value used for the 6G band was incorrect as it would result in invalid 6G channel number for certain frequencies. Reported-by: Amar Singhal <asinghal@codeaurora.org> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://lore.kernel.org/r/1567510772-24263-1-git-send-email-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2019-09-10net/mlx5: FWTrace, Reduce stack usageSaeed Mahameed1-3/+4 Mark mlx5_tracer_print_trace as noinline as the function only uses 512 bytes on the stack to avoid the following build warning: drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:660:13: error: stack frame size of 1032 bytes in function 'mlx5_fw_tracer_handle_traces' [-Werror,-Wframe-larger-than=] Fixes: 70dd6fdb8987 ("net/mlx5: FW tracer, parse traces and kernel tracing support") Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> 2019-09-10net/mlx5: Fix addr's type in mlx5dr_icm_dmNathan Chancellor1-1/+1 clang errors when CONFIG_PHYS_ADDR_T_64BIT is not set: drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c:121:8: error: incompatible pointer types passing 'u64 *' (aka 'unsigned long long *') to parameter of type 'phys_addr_t *' (aka 'unsigned int *') [-Werror,-Wincompatible-pointer-types] &icm_mr->dm.addr, &icm_mr->dm.obj_id); ^~~~~~~~~~~~~~~~ include/linux/mlx5/driver.h:1092:39: note: passing argument to parameter 'addr' here u64 length, u16 uid, phys_addr_t *addr, u32 *obj_id); ^ 1 error generated. Use phys_addr_t for addr's type in mlx5dr_icm_dm, which won't change anything with 64-bit builds because phys_addr_t is u64 when CONFIG_PHYS_ADDR_T_64BIT is set, which is always when CONFIG_64BIT is set. Fixes: 29cf8febd185 ("net/mlx5: DR, ICM pool memory allocator") Link: https://github.com/ClangBuiltLinux/linux/issues/653 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> 2019-09-10net/mlx5: Fix rt's type in dr_action_create_reformat_actionNathan Chancellor1-1/+1 clang warns: drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1080:9: warning: implicit conversion from enumeration type 'enum mlx5_reformat_ctx_type' to different enumeration type 'enum mlx5dr_action_type' [-Wenum-conversion] rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1082:9: warning: implicit conversion from enumeration type 'enum mlx5_reformat_ctx_type' to different enumeration type 'enum mlx5dr_action_type' [-Wenum-conversion] rt = MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1084:51: warning: implicit conversion from enumeration type 'enum mlx5dr_action_type' to different enumeration type 'enum mlx5_reformat_ctx_type' [-Wenum-conversion] ret = mlx5dr_cmd_create_reformat_ctx(dmn->mdev, rt, data_sz, data, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~ 3 warnings generated. Use the right type for rt, which is mlx5_reformat_ctx_type so there are no warnings about mismatched types. Fixes: 9db810ed2d37 ("net/mlx5: DR, Expose steering action functionality") Link: https://github.com/ClangBuiltLinux/linux/issues/652 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reported-by: Austin Kim <austindh.kim@gmail.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>