aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-06-13 13:34:13 -0400
committerDavid S. Miller <davem@davemloft.net>2017-06-13 13:34:13 -0400
commitc5549ee40112f2511a794c9aad7eb6ac5f18b0eb (patch)
treebcd773cb87894e264be36091891eaee194038551 /tools/perf/scripts/python
parentqed: fix dump of context data (diff)
parentmac80211: don't send SMPS action frame in AP mode when not needed (diff)
downloadlinux-c5549ee40112f2511a794c9aad7eb6ac5f18b0eb.tar.gz
linux-c5549ee40112f2511a794c9aad7eb6ac5f18b0eb.zip
Merge tag 'mac80211-for-davem-2017-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says: ==================== Some fixes: * Avi fixes some fallout from my mac80211 RX flags changes * Emmanuel fixes an issue with adhering to the spec, and an oversight in the SMPS management code * Jason's patch makes mac80211 use constant-time memory comparisons for message authentication, to avoid having potentially observable timing differences * my fix makes mac80211 set the basic rates bitmap before the channel so the next update to the driver has more consistent data - this required another rework patch to remove some useless 5/10 MHz code that can never be hit ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-16 12:12:52 +0000
viresh.kumar@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17acpi-cpufreq: Adjust the code to use the common boost attributeLukasz Majewski1-57/+29 Modify acpi-cpufreq's hardware-based boost solution to work with the common cpufreq boost framework. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17cpufreq: Add boost frequency support in coreLukasz Majewski3-8/+190 This commit adds boost frequency support in cpufreq core (Hardware & Software). Some SoCs (like Exynos4 - e.g. 4x12) allow setting frequency above its normal operation limits. Such mode shall be only used for a short time. Overclocking (boost) support is essentially provided by platform dependent cpufreq driver. This commit unifies support for SW and HW (Intel) overclocking solutions in the core cpufreq driver. Previously the "boost" sysfs attribute was defined in the ACPI processor driver code. By default boost is disabled. One global attribute is available at: /sys/devices/system/cpu/cpufreq/boost. It only shows up when cpufreq driver supports overclocking. Under the hood frequencies dedicated for boosting are marked with a special flag (CPUFREQ_BOOST_FREQ) at driver's frequency table. It is the user's concern to enable/disable overclocking with a proper call to sysfs. The cpufreq_boost_trigger_state() function is defined non static on purpose. It is used later with thermal subsystem to provide automatic enable/disable of the BOOST feature. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17intel_pstate: Add trace point to report internal state.Dirk Brandewie2-0/+77 Add perf trace event "power:pstate_sample" to report driver state to aid in diagnosing issues reported against intel_pstate. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17cpufreq: introduce cpufreq_generic_get() routineViresh Kumar18-229/+112 CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), to get CPUs clk rate, have similar sort of code used in most of them. This patch adds a generic ->get() which will do the same thing for them. All those drivers are required to now is to set .get to cpufreq_generic_get() and set their clk pointer in policy->clk during ->init(). Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17ARM: SA1100: Create dummy clk_get_rate() to avoid build failuresViresh Kumar1-0/+7 There are some parts of common kernel which would be using routines like clk_get_rate() on some platforms. Currently, they wouldn't be called for SA1100 boards, but they are needed for successful kernel compilation. Create a dummy clk_get_rate() routine for SA1100 which can be called by the cpufreq core. More dummy routines might be added later if necessary. Cc: Russell King <linux@arm.linux.org.uk> Cc: Arnd Bergmann <arnd.bergmann@linaro.org> Reported-by: Olof Johansson <olof@lixom.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17cpufreq: stats: create sysfs entries when cpufreq_stats is a moduleViresh Kumar1-2/+25 When cpufreq_stats is compiled in as a module, cpufreq driver would have already been registered. And so the CPUFREQ_CREATE_POLICY notifiers wouldn't be called for it. Hence no sysfs entries for stats. :( This patch calls cpufreq_stats_create_table() for each online CPU from cpufreq_stats_init() and so if policy is already created for CPUx then we will register sysfs stats for it. When its not compiled as module, we will return early as policy wouldn't be found for any of the CPUs. Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17cpufreq: stats: free table and remove sysfs entry in a single routineViresh Kumar1-31/+19 We don't have code paths now where we need to do these two things separately, so it is better do them in a single routine. Just as they are allocated in a single routine. Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17cpufreq: stats: remove hotplug notifiersViresh Kumar1-36/+2 Either CPUs are hot-unplugged or suspend/resume occurs, cpufreq core will send notifications to cpufreq-stats and stats structure and sysfs entries would be correctly handled.. And so we don't actually need hotcpu notifiers in cpufreq-stats anymore. We were only handling cpu hot-unplug events here and that are already taken care of by POLICY notifiers. Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17cpufreq: stats: handle cpufreq_unregister_driver() and suspend/resume properlyViresh Kumar3-7/+24 There are several problems with cpufreq stats in the way it handles cpufreq_unregister_driver() and suspend/resume.. - We must not lose data collected so far when suspend/resume happens and so stats directories must not be removed/allocated during these operations, which is done currently. - cpufreq_stat has registered notifiers with both cpufreq and hotplug. It adds sysfs stats directory with a cpufreq notifier: CPUFREQ_NOTIFY and removes this directory with a notifier from hotplug core. In case cpufreq_unregister_driver() is called (on rmmod cpufreq driver), stats directories per cpu aren't removed as CPUs are still online. The only call cpufreq_stats gets is cpufreq_stats_update_policy_cpu() for all CPUs except the last of each policy. And pointer to stat information is stored in the entry for last CPU in the per-cpu cpufreq_stats_table. But policy structure would be freed inside cpufreq core and so that will result in memory leak inside cpufreq stats (as we are never freeing memory for stats). Now if we again insert the module cpufreq_register_driver() will be called and we will again allocate stats data and put it on for first CPU of every policy. In case we only have a single CPU per policy, we will return with a error from cpufreq_stats_create_table() due to this code: if (per_cpu(cpufreq_stats_table, cpu)) return -EBUSY; And so probably cpufreq stats directory would not show up anymore (as it was added inside last policies->kobj which doesn't exist anymore). I haven't tested it, though. Also the values in stats files wouldn't be refreshed as we are using the earlier stats structure. - CPUFREQ_NOTIFY is called from cpufreq_set_policy() which is called for scenarios where we don't really want cpufreq_stat_notifier_policy() to get called. For example whenever we are changing anything related to a policy: min/max/current freq, etc. cpufreq_set_policy() is called and so cpufreq stats is notified. Where we don't do any useful stuff other than simply returning with -EBUSY from cpufreq_stats_create_table(). And so this isn't the right notifier that cpufreq stats.. Due to all above reasons this patch does following changes: - Add new notifiers CPUFREQ_CREATE_POLICY and CPUFREQ_REMOVE_POLICY, which are only called when policy is created/destroyed. They aren't called for suspend/resume paths.. - Use these notifiers in cpufreq_stat_notifier_policy() to create/destory stats sysfs entries. And so cpufreq_unregister_driver() or suspend/resume shouldn't be a problem for cpufreq_stats. - Return early from cpufreq_stat_cpu_callback() for suspend/resume sequence, so that we don't free stats structure. Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17cpufreq: speedstep: remove unused speedstep_get_statePaul Bolle1-32/+0 The only caller of speedstep_get_state() was removed in commit d4019f0a92ab ("cpufreq: move freq change notifications to cpufreq core"). So building speedstep-smi.o now triggers a GCC warning: drivers/cpufreq/speedstep-smi.c:148:12: warning: 'speedstep_get_state' defined but not used [-Wunused-function] Remove this unused function. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2014-01-17platform: introduce OF style 'modalias' support for platform busZhang Rui3-0/+13 Fix a problem that, the platform bus supports the OF style modalias in .uevent() call, but not in its device 'modalias' sysfs attribute. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>