linaro-kernel May 2017

linaro-kernel@lists.linaro.org

24 participants
127 discussions

[PATCH V3 00/16] PM / OPP: Introduce APIs to transition OPPs

by Viresh Kumar

Hi Guys, This patchset add APIs in OPP layer to allow OPPs transitioning from within OPP layer. Currently all OPP users need to replicate the same code to switch between OPPs. While the same can be handled easily by OPP-core. The first 7 patches update the OPP core to introduce the new APIs and the next Nine patches update cpufreq-dt for the same. 11 out of 17 are already Reviewed by Stephen, only few are left :) I hope this is the last version of the series :) Testing: - Tested on exynos 5250-arndale (dual-cortex-A15) - Tested for both Old-V1 bindings and New V2 bindings - Tested with regulator names as: 'cpu-supply' and 'cpu0-supply' - Tested with Unsupported supply ranges as well, to check the opp-disable logic V2->V3: - Very minor updates. - find_supply_name() doesn't return an error value now, and so its callers don't check for it. - And so we don't need to initialize name to NULL Viresh Kumar (16): PM / OPP: get/put regulators from OPP core PM / OPP: Disable OPPs that aren't supported by the regulator PM / OPP: Introduce dev_pm_opp_get_max_volt_latency() PM / OPP: Introduce dev_pm_opp_get_max_transition_latency() PM / OPP: Parse clock-latency and voltage-tolerance for v1 bindings PM / OPP: Manage device clk PM / OPP: Add dev_pm_opp_set_rate() cpufreq: dt: Convert few pr_debug/err() calls to dev_dbg/err() cpufreq: dt: Rename 'need_update' to 'opp_v1' cpufreq: dt: OPP layers handles clock-latency for V1 bindings as well cpufreq: dt: Pass regulator name to the OPP core cpufreq: dt: Unsupported OPPs are already disabled cpufreq: dt: Reuse dev_pm_opp_get_max_transition_latency() cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency cpufreq: dt: No need to fetch voltage-tolerance cpufreq: dt: No need to allocate resources anymore drivers/base/power/opp/core.c | 420 ++++++++++++++++++++++++++++++++++++++++++ drivers/base/power/opp/opp.h | 13 ++ drivers/cpufreq/cpufreq-dt.c | 300 +++++++++++------------------- include/linux/pm_opp.h | 27 +++ 4 files changed, 565 insertions(+), 195 deletions(-) -- 2.7.1.370.gb2aa7f8

5 years, 11 months

[PATCH 00/34] CPUFreq: Move freq change notifications out of drivers

by Viresh Kumar

Another 452 lines gone :) Total stats upto now for all the 5 patchsets: Viresh Kumar (186): ... 69 files changed, 700 insertions(+), 2451 deletions(-) Net: 1751 lines gone.. -----x-------------x---------------- Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code and so this patch introduces another flag: CPUFREQ_NO_NOTIFICATION, which will be set by such drivers. This is Fifth part of my cleanup work for CPUFreq, first three are (And obviously its rebased over them): 1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263 2: cpufreq: define generic routines for cpufreq drivers https://lkml.org/lkml/2013/8/10/48 3. CPUFreq: Implement light weight ->target(): for 3.13 https://lkml.org/lkml/2013/8/13/349 4. CPUFreq: set policy->cur in cpufreq core instead of drivers https://lkml.org/lkml/2013/8/14/288 All these are pushed here: https://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/… -- viresh Cc: Andrew Lunn <andrew(a)lunn.ch> Cc: David S. Miller <davem(a)davemloft.net> Cc: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> Cc: Eric Miao <eric.y.miao(a)gmail.com> Cc: Hans-Christian Egtvedt <egtvedt(a)samfundet.no> Cc: Jesper Nilsson <jesper.nilsson(a)axis.com> Cc: John Crispin <blogic(a)openwrt.org> Cc: Kukjin Kim <kgene.kim(a)samsung.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: linux-cris-kernel(a)axis.com Cc: Mikael Starvik <starvik(a)axis.com> Cc: Russell King <linux(a)arm.linux.org.uk> Cc: Santosh Shilimkar <santosh.shilimkar(a)ti.com> Cc: Sekhar Nori <nsekhar(a)ti.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Cc: sparclinux(a)vger.kernel.org Cc: spear-devel(a)list.st.com Cc: Stephen Warren <swarren(a)nvidia.com> Cc: Steven Miao <realmz6(a)gmail.com> Cc: Tony Luck <tony.luck(a)intel.com> Viresh Kumar (34): cpufreq: move freq change notifications to cpufreq core cpufreq: acpi: remove calls to cpufreq_notify_transition() cpufreq: arm_big_little: remove calls to cpufreq_notify_transition() cpufreq: at32ap: remove calls to cpufreq_notify_transition() cpufreq: blackfin: remove calls to cpufreq_notify_transition() cpufreq: cpu0: remove calls to cpufreq_notify_transition() cpufreq: cris: remove calls to cpufreq_notify_transition() cpufreq: davinci: remove calls to cpufreq_notify_transition() cpufreq: dbx500: remove calls to cpufreq_notify_transition() cpufreq: e_powersaver: remove calls to cpufreq_notify_transition() cpufreq: elanfreq: remove calls to cpufreq_notify_transition() cpufreq: exynos: remove calls to cpufreq_notify_transition() cpufreq: exynos5440: set CPUFREQ_NO_NOTIFICATION flag cpufreq: ia64-acpi: remove calls to cpufreq_notify_transition() cpufreq: imx6q: remove calls to cpufreq_notify_transition() cpufreq: kirkwood: remove calls to cpufreq_notify_transition() cpufreq: longhaul: set CPUFREQ_NO_NOTIFICATION flag cpufreq: loongson2: remove calls to cpufreq_notify_transition() cpufreq: maple: remove calls to cpufreq_notify_transition() cpufreq: omap: remove calls to cpufreq_notify_transition() cpufreq: p4-clockmod: remove calls to cpufreq_notify_transition() cpufreq: pasemi: remove calls to cpufreq_notify_transition() cpufreq: pmac: remove calls to cpufreq_notify_transition() cpufreq: powernow: remove calls to cpufreq_notify_transition() cpufreq: ppc: remove calls to cpufreq_notify_transition() cpufreq: pxa: remove calls to cpufreq_notify_transition() cpufreq: s3c: remove calls to cpufreq_notify_transition() cpufreq: s5pv210: remove calls to cpufreq_notify_transition() cpufreq: sa11x0: remove calls to cpufreq_notify_transition() cpufreq: sc520: remove calls to cpufreq_notify_transition() cpufreq: sparc: remove calls to cpufreq_notify_transition() cpufreq: SPEAr: remove calls to cpufreq_notify_transition() cpufreq: speedstep: remove calls to cpufreq_notify_transition() cpufreq: tegra: remove calls to cpufreq_notify_transition() drivers/cpufreq/acpi-cpufreq.c | 14 ++------- drivers/cpufreq/arm_big_little.c | 25 ++-------------- drivers/cpufreq/at32ap-cpufreq.c | 22 ++++++-------- drivers/cpufreq/blackfin-cpufreq.c | 22 +++++--------- drivers/cpufreq/cpufreq-cpu0.c | 33 ++++++++------------- drivers/cpufreq/cpufreq.c | 34 +++++++++++++++++++++ drivers/cpufreq/cris-artpec3-cpufreq.c | 8 ----- drivers/cpufreq/cris-etraxfs-cpufreq.c | 8 ----- drivers/cpufreq/davinci-cpufreq.c | 30 +++++++------------ drivers/cpufreq/dbx500-cpufreq.c | 22 +------------- drivers/cpufreq/e_powersaver.c | 23 ++------------- drivers/cpufreq/elanfreq.c | 13 -------- drivers/cpufreq/exynos-cpufreq.c | 28 +++++------------- drivers/cpufreq/exynos5440-cpufreq.c | 2 +- drivers/cpufreq/ia64-acpi-cpufreq.c | 19 ------------ drivers/cpufreq/imx6q-cpufreq.c | 39 ++++++++++-------------- drivers/cpufreq/kirkwood-cpufreq.c | 54 +++++++++++++--------------------- drivers/cpufreq/longhaul.c | 1 + drivers/cpufreq/loongson2_cpufreq.c | 16 ---------- drivers/cpufreq/maple-cpufreq.c | 18 +----------- drivers/cpufreq/omap-cpufreq.c | 39 +++++++++--------------- drivers/cpufreq/p4-clockmod.c | 10 ------- drivers/cpufreq/pasemi-cpufreq.c | 14 +-------- drivers/cpufreq/pmac32-cpufreq.c | 20 +++---------- drivers/cpufreq/pmac64-cpufreq.c | 18 +----------- drivers/cpufreq/powernow-k6.c | 8 ----- drivers/cpufreq/powernow-k7.c | 11 +------ drivers/cpufreq/powernow-k8.c | 15 +--------- drivers/cpufreq/ppc-corenet-cpufreq.c | 19 +----------- drivers/cpufreq/ppc_cbe_cpufreq.c | 19 +----------- drivers/cpufreq/pxa2xx-cpufreq.c | 27 ++++------------- drivers/cpufreq/pxa3xx-cpufreq.c | 12 -------- drivers/cpufreq/s3c2416-cpufreq.c | 21 +++---------- drivers/cpufreq/s3c64xx-cpufreq.c | 48 ++++++++++-------------------- drivers/cpufreq/s5pv210-cpufreq.c | 16 ++++------ drivers/cpufreq/sa1100-cpufreq.c | 17 ++++------- drivers/cpufreq/sa1110-cpufreq.c | 12 ++------ drivers/cpufreq/sc520_freq.c | 11 ------- drivers/cpufreq/sparc-us2e-cpufreq.c | 7 ----- drivers/cpufreq/sparc-us3-cpufreq.c | 7 ----- drivers/cpufreq/spear-cpufreq.c | 13 +------- drivers/cpufreq/speedstep-centrino.c | 20 +------------ drivers/cpufreq/speedstep-ich.c | 9 ------ drivers/cpufreq/speedstep-smi.c | 7 ----- drivers/cpufreq/tegra-cpufreq.c | 25 ++++------------ include/linux/cpufreq.h | 6 ++++ 46 files changed, 205 insertions(+), 657 deletions(-) -- 1.7.12.rc2.18.g61b472e

6 years, 8 months

[PATCH] cpufreq: dt: Set default policy->transition_delay_ns

by Viresh Kumar

The rate_limit_us for the schedutil governor is getting set to 500 ms by default for the ARM64 hikey board. And its way too much, even for the default value. Lets set the default transition_delay_ns to something more realistic (10 ms), while the userspace always have a chance to set something it wants. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq-dt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index c943787d761e..70eac3fd89ac 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -275,6 +275,9 @@ static int cpufreq_init(struct cpufreq_policy *policy) policy->cpuinfo.transition_latency = transition_latency; + /* Set the default transition delay to 10ms */ + policy->transition_delay_us = 10 * USEC_PER_MSEC; + return 0; out_free_cpufreq_table: -- 2.7.4

6 years, 12 months

[PATCH 0/6] sched: Minor fixes and cleanups

by Viresh Kumar

Hi, The first patch fixes a potential regression we may observe on the UP systems and the others are doing minor optimizations in the scheduler core. They are all tested on ARM 32 (exynos) and 64 (hikey) bit platforms. -- viresh Viresh Kumar (6): sched: fair: Call cpufreq update util handlers less frequently on UP sched: Reuse put_prev_task() sched: fair: Pass rq to weighted_cpuload() sched: fair: Avoid checking cfs_rq->nr_running twice sched: fair: Drop always true parameter of update_cfs_rq_load_avg() sched: cpufreq: Optimize cpufreq_update_this_cpu() a bit kernel/sched/core.c | 2 +- kernel/sched/fair.c | 107 ++++++++++++++++++++++++++------------------------- kernel/sched/sched.h | 2 +- 3 files changed, 56 insertions(+), 55 deletions(-) -- 2.13.0.70.g6367777092d9

6 years, 12 months

[PATCH V7 0/2] PM / Domains: Power domain performance states

by Viresh Kumar

Hi, Here is the 7th version of the series and it looks very different from whatever is sent until now. Almost a rewrite. Here is a brief summary of the problem I am trying to solve. Some platforms have the capability to configure the performance state of their power domains. The process of configuring the performance state is pretty much platform dependent and we may need to work with a wide range of configurables. For some platforms, like Qcom, it can be a positive integer value alone, while in other cases it can be voltage levels, etc. The power-domain framework until now was only designed for the idle state management of the device and this needs to change in order to reuse the power-domain framework for active state management of the devices. Solution: Kevin suggested in V6 that we should wait for a while before introducing any new binding (power-domain-opp) to the OPP table for this stuff and translate the device requirements into a performance index from within the power domain driver as it already knows which devices it supports. If we do that, then there is also no need to represent the performance states of the power domains in the DT. Keep that as well in the driver for now. This simplified things a lot and we can make things work with just two patches. The first one updates the genpd framework to supply new APIs and the second patch uses them from the OPP core. Its quite straight forward and simple. The ideal way is still to get the relation between device and domain states via the DT instead of platform code, but that can be done incrementally later once we have some users for it. It would be much simpler to get these two patches merged. The code never got any real reviews in the last 6 versions as we were stuck with bindings :) This is tested currently by hacking the kernel a bit with virtual power-domains for the dual A15 exynos platform. Driver code: ------------ Here is some sample power-domain driver code that I have. It only supports a single device for now, CPU. int pd_get_performance(struct device *dev, unsigned long rate) { struct device *cpu_dev = get_cpu_device(0); if (cpu_dev != dev) return -EINVAL; if (rate <= 500000000) return 1; else if (rate <= 700000000) return 2; else if (rate <= 900000000) return 3; else if (rate <= 1200000000) return 4; else if (rate <= 1600000000) return 5; else return 6; } static int pd_set_performance(struct generic_pm_domain *domain, unsigned int state) { /* Set performance of the domain in platform dependent way */ return 0; } static const struct of_device_id pm_domain_of_match[] __initconst = { { .compatible = "foo,genpd", }, { }, }; static int __init genpd_test_init(void) { struct device *dev = get_cpu_device(0); struct device_node *np; const struct of_device_id *match; int n; int ret; for_each_matching_node_and_match(np, pm_domain_of_match, &match) { pd.name = kstrdup_const(strrchr(np->full_name, '/') + 1, GFP_KERNEL); if (!pd.name) { of_node_put(np); return -ENOMEM; } pd.get_performance_state = pd_get_performance; pd.set_performance_state = pd_set_performance; pm_genpd_init(&pd, NULL, false); of_genpd_add_provider_simple(np, &pd); } ret = dev_pm_domain_attach(dev, false); return ret; } Pushed here as well: https://git.linaro.org/people/viresh.kumar/linux.git/log/?h=opp/genpd-perfo… Rebased on: pm/linux-next + some OPP cleanups (https://marc.info/?l=linux-kernel&m=149499607030364&w=2) V6->V7: - Almost a rewrite, only two patches against 9 in earlier version. - No bindings updated now and domain's performance state aren't passed via DT for now (until we know how users are going to use it). - We also skipped the QoS framework completely and new APIs are provided directly by genpd. V5->V6: - Use freq/voltage in OPP table as it is for power domain and don't create "domain-performance-level" property - Create new "power-domain-opp" property for the devices. - Take care of domain providers that provide multiple domains and extend "operating-points-v2" property to contain a list of phandles - Update code according to those bindings. V4->V5: - Only 3 patches were resent and 2 of them are Acked from Ulf. V3->V4: - Use OPP table for genpd devices as well. - Add struct device to genpd, in order to reuse OPP infrastructure. - Based over: https://marc.info/?l=linux-kernel&m=148972988002317&w=2 - Fixed examples in DT document to have voltage in target,min,max order. V2->V3: - Based over latest pm/linux-next - Bindings and code are merged together - Lots of updates in bindings - the performance-states node is present within the power-domain now, instead of its phandle. - performance-level property is replaced by "reg". - domain-performance-state property of the consumers contain an integer value now instead of phandle. - Lots of updates to the code as well - Patch "PM / QOS: Add default case to the switch" is merged with other patches and the code is changed a bit as well. - Don't pass 'type' to dev_pm_qos_add_notifier(), rather handle all notifiers with a single list. A new patch is added for that. - The OPP framework patch can be applied now and has proper SoB from me. - Dropped "PM / domain: Save/restore performance state at runtime suspend/resume". - Drop all WARN(). - Tested-by Rajendra nayak. V1->V2: - Based over latest pm/linux-next - It is mostly a resend of what is sent earlier as this series hasn't got any reviews so far and Rafael suggested that its better I resend it. - Only the 4/6 patch got an update, which was shared earlier as reply to V1 as well. It has got several fixes for taking care of power domain hierarchy, etc. -- viresh Viresh Kumar (2): PM / Domains: Add support to select performance-state of domains PM / OPP: Support updating performance state of device's power domains drivers/base/power/domain.c | 172 ++++++++++++++++++++++++++++++++++++++++++ drivers/base/power/opp/core.c | 48 +++++++++++- drivers/base/power/opp/opp.h | 2 + include/linux/pm_domain.h | 19 +++++ 4 files changed, 240 insertions(+), 1 deletion(-) -- 2.13.0.303.g4ebf3021692d

7 years

v4.11.3 build: 0 failures 1 warnings (v4.11.3)

by Build bot for Mark Brown

Tree/Branch: v4.11.3 Git describe: v4.11.3 Commit: b43ae25b70 Linux 4.11.3 Build Time: 98 min 42 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : x86_64-defconfig 1 warnings 0 mismatches : arm-multi_v7_defconfig 1 warnings 0 mismatches : arm-multi_v5_defconfig 1 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 4 ../kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used [-Wunused-function] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used [-Wunused-function] ------------------------------------------------------------------------------- arm-multi_v5_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used [-Wunused-function] ------------------------------------------------------------------------------- arm64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../kernel/cgroup/cgroup.c:439:13: warning: 'cgroup_get' defined but not used [-Wunused-function] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig

7 years

[PATCH 0/2]

by Benjamin Gaignard

Those patches aim to complete stm32 timer features support. The last missing part is to be able to chain to timer blocks which mean that one of timerX's trigger could be used as clock for timerY. Since this operating is neither event or buffer triggered mode I would like to introduce a hardware triggered mode in IIO core. Benjamin Gaignard (2): iio: add hardware triggered operating mode iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode .../ABI/testing/sysfs-bus-iio-timer-stm32 | 15 ++++++ drivers/iio/industrialio-core.c | 4 +- drivers/iio/trigger/stm32-timer-trigger.c | 61 ++++++++++++++++++++++ include/linux/iio/iio.h | 6 +++ 4 files changed, 84 insertions(+), 2 deletions(-) -- 1.9.1

7 years

master build: 0 failures 0 warnings (v4.12-rc3-21-gd602fb6)

by Build bot for Mark Brown

Tree/Branch: master Git describe: v4.12-rc3-21-gd602fb6 Commit: d602fb6844 Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs Build Time: 117 min 59 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years

next-20170531 build: 0 failures 1 warnings (next-20170531)

by Build bot for Mark Brown

Tree/Branch: next-20170531 Git describe: next-20170531 Commit: f2882f46b6 Add linux-next specific files for 20170531 Build Time: 118 min 56 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allmodconfig 1 warnings 0 mismatches : arm-multi_v5_defconfig 1 warnings 0 mismatches : arm-multi_v7_defconfig 1 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-multi_v4t_defconfig 1 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 6 ../drivers/gpio/gpiolib.c:1474:6: warning: unused variable 'i' [-Wunused-variable] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpio/gpiolib.c:1474:6: warning: unused variable 'i' [-Wunused-variable] ------------------------------------------------------------------------------- arm-multi_v5_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpio/gpiolib.c:1474:6: warning: unused variable 'i' [-Wunused-variable] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpio/gpiolib.c:1474:6: warning: unused variable 'i' [-Wunused-variable] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpio/gpiolib.c:1474:6: warning: unused variable 'i' [-Wunused-variable] ------------------------------------------------------------------------------- arm-multi_v4t_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpio/gpiolib.c:1474:6: warning: unused variable 'i' [-Wunused-variable] ------------------------------------------------------------------------------- arm64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpio/gpiolib.c:1474:6: warning: unused variable 'i' [-Wunused-variable] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: x86_64-allnoconfig arm64-allnoconfig arm-allnoconfig x86_64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years

master build: 0 failures 0 warnings (v4.12-rc3-11-gf511c0b)

by Build bot for Mark Brown

Tree/Branch: master Git describe: v4.12-rc3-11-gf511c0b Commit: f511c0b17b "Yes, people use FOLL_FORCE ;)" Build Time: 117 min 48 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel May 2017