consider such situation, current user_policy.min is 100,
current user_policy.max is 120, in cpufreq_set_policy,
other driver may update policy.min to 120, policy.max to
130. After that, If we input "echo 130 > scaling_min_freq",
then user_policy.min will be 130, and user_pol
Hi Florian,
On Wed, May 23, 2018 at 11:40:50AM -0700, Florian Fainelli wrote:
>
> Antoine, can you please do CC the people who worked on that code before,
> arguably, send an update to MAINTAINERS file to create a specific
> section for PHYLINK.
My bad, sorry for that, I'll make sure to Cc every
On Thu, 24 May 2018 09:49:05 +0800
Dave Young wrote:
> Hi Petr,
>
> On 05/23/18 at 10:22pm, Petr Tesarik wrote:
>[...]
> > In short, if one size fits none, what good is it to hardcode that "one
> > size" into the kernel image?
>
> I agreed with all the things that we can not know the exact me
Add a generic /memory node in each Tegra DTSI (with empty reg property,
to be overidden by each DTS) and set proper unit address for /memory
nodes to fix the DTC warnings:
arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
/memory: node has a reg or ranges property,
Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
(with 1024 MB NAND) flavors. Both of them will use the same DTSI
expecting the bootloader to do the fixup of /memory node. However in
case it does not happen, let's stay on safe side by limiting the memory
to 256 MB for both vers
Remove unneeded address/size cells properties and unit addresses to fix
DTC warnings like:
arch/arm/boot/dts/tegra30-apalis-eval.dtb: Warning (unit_address_vs_reg):
/i2c@7000d000/stmpe811@41/stmpe_touchscreen@0: node has a unit name,
but no reg property
arch/arm/boot/dts/tegra30-a
Remove the usage of skeleton.dtsi because it was deprecated since commit
9c0da3cc61f1 ("ARM: dts: explicitly mark skeleton.dtsi as deprecated").
It also allows later to fix DTC warnings for missing unit name in
/memory nodes.
The /chosen and /aliases nodes are added only when dependent DTSes do
no
On Wed, May 16, 2018 at 05:32:14PM +0530, Akshay Adiga wrote:
> Init all present cpus for deep states instead of "all possible" cpus.
> Init fails if the possible cpu is gaurded. Resulting in making only
> non-deep states available for cpuidle/hotplug.
>
> Signed-off-by: Akshay Adiga
> ---
> arc
On Wed, May 23, 2018 at 08:18:11PM -0700, Dan Williams wrote:
> On Wed, May 23, 2018 at 5:10 PM, Jerome Glisse wrote:
> > On Mon, May 21, 2018 at 03:35:14PM -0700, Dan Williams wrote:
> >> Hi Andrew, please consider this series for 4.18.
> >>
> >> For maintainability, as ZONE_DEVICE continues to a
On 24/05/18 01:02, Aaro Koskinen wrote:
But turns out that omapdrm tree is unbisectable, as I get build failures such
as (commit 28d79f3e56b2c1d5ff0fd363da3229be0962cc85):
/home/aaro/git/devel/linux/drivers/gpu/drm/omapdrm/dss/dss.c:1473:52: error:
undefined identifier 'dss_debug_dump_clocks'
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac
Le 23/05/2018 à 20:34, Segher Boessenkool a écrit :
On Tue, May 22, 2018 at 08:57:01AM +0200, Christophe Leroy wrote:
The generic csum_ipv6_magic() generates a pretty bad result
Please try with a more recent compiler, what you used is pretty ancient.
It's not like recent compilers do great
Hi Stanimir,
On Tue, May 15, 2018 at 5:10 PM Stanimir Varbanov <
stanimir.varba...@linaro.org> wrote:
> This extends the clocks number to support suspend and resume
> on Venus version 4xx.
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/core.h | 4 +--
> drivers
On Wed, May 23, 2018 at 07:10:58PM +0300, Sergei Shtylyov wrote:
> On 05/23/2018 05:37 PM, Heikki Krogerus wrote:
>
> > Trying to determine the USB port type with this mux is very
> > difficult. To simplify the situation, always allowing user
>
>s/allowing/allow/? Else the statement doesn't p
On Wed, May 23, 2018 at 10:58:04AM -0700, Rajat Jain wrote:
> ---
> v2: Fix the license header as per Greg's suggestions
> (Since there is disagreement with using "//" vs "/* */" for license
> I decided to keep the one preferred by Linus, also used by others
> in this directory)
The
On Wed, May 23, 2018 at 08:03:43PM +0200, Hans de Goede wrote:
> Hi,
>
> On 23-05-18 16:37, Heikki Krogerus wrote:
> > Trying to determine the USB port type with this mux is very
> > difficult. To simplify the situation, always allowing user
> > control, even if the port is USB Type-C port.
> >
>
Configurations and Makefile for BD71837 regulator driver
Signed-off-by: Matti Vaittinen
---
drivers/regulator/Kconfig | 11 +++
drivers/regulator/Makefile | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 097f61784a7d..13
Configuration options and Makefile for BD71837 clock driver
Signed-off-by: Matti Vaittinen
---
drivers/clk/Kconfig | 9 +
drivers/clk/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 41492e980ef4..4b045699bb5e 100644
--- a/d
Support for controlling the 8 bucks and 7 LDOs the PMIC contains.
Signed-off-by: Matti Vaittinen
---
drivers/regulator/bd71837-regulator.c | 683 ++
1 file changed, 683 insertions(+)
create mode 100644 drivers/regulator/bd71837-regulator.c
diff --git a/drivers/r
Support BD71837 gateable 32768 Hz clock.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-bd71837.c | 155 ++
1 file changed, 155 insertions(+)
create mode 100644 drivers/clk/clk-bd71837.c
diff --git a/drivers/clk/clk-bd71837.c b/drivers/clk/clk-bd
On 23.05.2018 21:51, Christoph Hellwig wrote:
> On Wed, May 23, 2018 at 05:11:51PM +0200, David Hildenbrand wrote:
>> Kernel modules that want to control how/when memory is onlined/offlined
>> need a proper interface to these functions. Also, for adding memory
>> properly, memory_block_size_bytes i
Document devicetree bindings for ROHM BD71837 PMIC clock output.
Signed-off-by: Matti Vaittinen
---
.../bindings/clock/rohm,bd71837-clock.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
Document devicetree bindings for ROHM BD71837 PMIC regulators.
Signed-off-by: Matti Vaittinen
---
.../bindings/regulator/rohm,bd71837-regulator.txt | 124 +
1 file changed, 124 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/rohm,bd71837-regula
Document devicetree bindings for ROHM BD71837 PMIC MFD.
Signed-off-by: Matti Vaittinen
---
.../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
diff --git
ROHM BD71837 PMIC MFD driver providing interrupts and support
for two subsystems:
- clk
- Regulators
Signed-off-by: Matti Vaittinen
---
drivers/mfd/bd71837.c | 238 +
include/linux/mfd/bd71837.h | 316
2 files cha
Configuration options and Makefile for BD71837 PMIC MFD driver
Signed-off-by: Matti Vaittinen
---
drivers/mfd/Kconfig | 13 +
drivers/mfd/Makefile | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..7aa05fc9ed8e 10064
Patch series adding support for ROHM BD71837 PMIC.
BD71837 is a programmable Power Management IC for powering single-core,
dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
low BOM cost and compact solution footprint. It integrates 8 buck
regulators and 7 LDO’s to provide all
Hi Neil, Hi Stefan,
On Fri, May 18, 2018 at 03:05:02PM +0200, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP direc
On 5/23/2018 8:43 PM, Sudeep Holla wrote:
On 19/05/18 18:34, Taniya Das wrote:
Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by firmware.
Signed-off-by: Taniya Das
---
.../bin
Commit-ID: 22916fdb9c50e8fb303bdcedca88fd8798a85844
Gitweb: https://git.kernel.org/tip/22916fdb9c50e8fb303bdcedca88fd8798a85844
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:45 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:44 -0300
perf kcore_c
Commit-ID: a1a3a0624e6cd0e2c46a7400800a5e687521a504
Gitweb: https://git.kernel.org/tip/a1a3a0624e6cd0e2c46a7400800a5e687521a504
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:44 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:43 -0300
perf kcore_c
Commit-ID: 15acef6c3727cfe0bc9d1f6b273cca46689e8cd8
Gitweb: https://git.kernel.org/tip/15acef6c3727cfe0bc9d1f6b273cca46689e8cd8
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:41 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:42 -0300
perf kcore_c
Commit-ID: b4503cdb67098b2f08320c2c83df758ea72a4431
Gitweb: https://git.kernel.org/tip/b4503cdb67098b2f08320c2c83df758ea72a4431
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:43 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:43 -0300
perf kcore_c
Commit-ID: d2c959803c8843f64e419d833dc3722154c82492
Gitweb: https://git.kernel.org/tip/d2c959803c8843f64e419d833dc3722154c82492
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:42 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:42 -0300
perf kcore_c
On 24-05-18, 10:48, Taniya Das wrote:
> Hello Rob, Viresh,
>
> Thank you for the comments. If I understand correctly, the device tree nodes
> should look something like the below.
>
> Though I am not sure if any vendor name could be associated in the cpu
> nodes.
Well Rob said Yes to that I thin
Commit-ID: c9dd1d894958b81a329ec01e7dd03b92eca52789
Gitweb: https://git.kernel.org/tip/c9dd1d894958b81a329ec01e7dd03b92eca52789
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:40 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:41 -0300
perf kcore_c
Commit-ID: 6e97957d3d30552c415292bb08a0e5f3c459c027
Gitweb: https://git.kernel.org/tip/6e97957d3d30552c415292bb08a0e5f3c459c027
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:39 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:41 -0300
perf kcore_c
Commit-ID: f6838209484d5cfb368ca5c61d150cc4054eef59
Gitweb: https://git.kernel.org/tip/f6838209484d5cfb368ca5c61d150cc4054eef59
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:38 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:40 -0300
perf kcore_c
Commit-ID: 5759a6820aadd38b2c8c10e93919eae8e31a9f9a
Gitweb: https://git.kernel.org/tip/5759a6820aadd38b2c8c10e93919eae8e31a9f9a
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:35 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 22 May 2018 10:59:22 -0300
perf machine
Commit-ID: 787e4da9f95fd44376b3af6fa163ac0b3a48a1fc
Gitweb: https://git.kernel.org/tip/787e4da9f95fd44376b3af6fa163ac0b3a48a1fc
Author: Jin Yao
AuthorDate: Tue, 22 May 2018 19:38:35 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:40 -0300
perf annotate: Sho
Commit-ID: 1c5aae7710bb9ecf82a5cc88e35a028a8b385763
Gitweb: https://git.kernel.org/tip/1c5aae7710bb9ecf82a5cc88e35a028a8b385763
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:36 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:24:08 -0300
perf machine
Commit-ID: a8ce99b0ee9ad32debad0a9f28d21451ba237cc1
Gitweb: https://git.kernel.org/tip/a8ce99b0ee9ad32debad0a9f28d21451ba237cc1
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:37 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 23 May 2018 10:26:39 -0300
perf machine
Commit-ID: 4d004365e25251002935fc3843d80934248ad3ed
Gitweb: https://git.kernel.org/tip/4d004365e25251002935fc3843d80934248ad3ed
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:34 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 22 May 2018 10:55:59 -0300
perf machine
Commit-ID: 7ebaf4890f63eb90856b76864a0847413cdf6c86
Gitweb: https://git.kernel.org/tip/7ebaf4890f63eb90856b76864a0847413cdf6c86
Author: Jin Yao
AuthorDate: Mon, 21 May 2018 22:57:46 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 21 May 2018 14:41:25 -0300
perf annotate: Sup
Commit-ID: 9cecca325ea879c84fcd31a5e609a514c1a1dbd1
Gitweb: https://git.kernel.org/tip/9cecca325ea879c84fcd31a5e609a514c1a1dbd1
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:32 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 22 May 2018 10:52:49 -0300
perf machine
Commit-ID: 4d99e4136580d178e3523281a820be17bf814bf8
Gitweb: https://git.kernel.org/tip/4d99e4136580d178e3523281a820be17bf814bf8
Author: Adrian Hunter
AuthorDate: Tue, 22 May 2018 13:54:33 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 22 May 2018 10:54:22 -0300
perf machine
Commit-ID: a26bb0ba706aef4f42cc9377c0d4e849378574a4
Gitweb: https://git.kernel.org/tip/a26bb0ba706aef4f42cc9377c0d4e849378574a4
Author: Jin Yao
AuthorDate: Mon, 21 May 2018 22:57:45 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 21 May 2018 14:41:01 -0300
perf report: Use p
On 24.05.2018 07:30, Viresh Kumar wrote:
> On 23-05-18, 19:00, Dmitry Osipenko wrote:
>> PLL_C is running at 600MHz which is significantly higher than the 216MHz
>> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
>> running on that PLL. Let's use PLL_C as intermediate clock
Commit-ID: e2bdbe80a0b7dea9ba73582701b8a67c01e1da4f
Gitweb: https://git.kernel.org/tip/e2bdbe80a0b7dea9ba73582701b8a67c01e1da4f
Author: Jin Yao
AuthorDate: Mon, 21 May 2018 22:57:44 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 21 May 2018 14:40:54 -0300
perf evlist: Intro
;perf-core-for-mingo-4.18-20180519' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
> (2018-05-19 13:32:53 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d
Florians comment:
c499696e7901bda18
The correct fieldbit value for the NAND PLL reload trigger is 27.
Fixes: commit e120c17a70e5 ("clk: mvebu: support for 98DX3236 SoC")
Signed-off-by: Chris Packham
---
I can't remember where the value of 26 came from. Looking at the lsp source I
have from Marvell it's always been 27, so I suspect
On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote:
> So why is this any better than the current code. Sure I am not a great
> fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> doesn't look too much better, yet we are losing a check for incompatible
> gfp flags. The d
Thanks Bjorn for reviewing.
On 5/23/2018 11:56 AM, Bjorn Andersson wrote:
On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote:
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -10,6 +10,7 @@ on the Qualcomm ADSP H
Hello Rob, Viresh,
Thank you for the comments. If I understand correctly, the device tree
nodes should look something like the below.
Though I am not sure if any vendor name could be associated in the cpu
nodes.
Please suggest if my understanding is wrong.
cpu@0 {
qcom,freq-domain
2018-05-21 20:06 GMT+09:00 Ulf Magnusson :
>>
>> static char *__expand_string(const char **str, bool (*is_end)(const char *))
>> {
>> const char *in, *prev_in, *p;
>> char *new, *out;
>> size_t outlen;
>>
>> out = xmalloc(1);
>> *out = 0;
>>
>> p = i
On Wed, May 23, 2018 at 2:09 AM, Peter Zijlstra wrote:
> On Mon, May 21, 2018 at 11:35:38PM -0700, Ivan Babrou wrote:
>> > + TP_printk("path=%s cpu=%d runtime_remaining=%lld",
>> > __get_str(cfs_path),
>> > + __entry->cpu, __entry->runtime_remaining)
>> >
>>
>> Can you add "[
On 2018/05/23 3:54, Michal Hocko wrote:
> On Tue 22-05-18 22:04:23, TSUKADA Koutaro wrote:
>> On 2018/05/22 3:07, Mike Kravetz wrote:
>>> On 05/17/2018 09:27 PM, TSUKADA Koutaro wrote:
Thanks to Mike Kravetz for comment on the previous version patch.
The purpose of this patch-set is
On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_init(void)
> > +{
> > + /*
> > +* Since the driver depends on smem and nvmem drivers, which may
> > +* return EPROBE_DEFER, all the real activity is done in the probe,
> >
(We analyzed the crash and added the result below.)
We report the crash:
"KASAN: use-after-free Read in vgacon_invert_region"
This crash was found in v4.17-rc3. Specifically, memory access (read
operation) is invalid and which is detected by KASAN.
Analysis:
The function "vt_do_resize" basically
On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +config ARM_QCOM_CPUFREQ_KRYO
> > + bool "Qualcomm Kryo based CPUFreq"
> > + depends on QCOM_QFPROM
> > + depends on QCOM_SMEM
> > + select PM_OPP
> > + help
> > + This adds the CPUFreq driver for Qualcom
On 23-05-18, 19:00, Dmitry Osipenko wrote:
> PLL_C is running at 600MHz which is significantly higher than the 216MHz
> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
> running on that PLL. Let's use PLL_C as intermediate clock source, making
> CPU snappier a tad during of
On 23-05-18, 19:00, Dmitry Osipenko wrote:
> PLL_P is known to be always running at 216MHz, hence there is no need to
> query its rate.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/cpufreq/tegra20-cpufreq.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --gi
On 2018/05/22 22:51, Michal Hocko wrote:
> On Fri 18-05-18 13:27:27, TSUKADA Koutaro wrote:
>> The purpose of this patch-set is to make it possible to control whether or
>> not to charge surplus hugetlb pages obtained by overcommitting to memory
>> cgroup. In the future, I am trying to accomplish l
Arnd Bergmann writes:
> On Fri, May 11, 2018 at 2:20 PM, Kalle Valo wrote:
>> Stephen Rothwell writes:
>>
>>> After merging the mac80211-next tree, today's linux-next build (arm_multi
>>> v7_defconfig) produced this warning:
>>>
>>> drivers/net/wireless/marvell/mwifiex/uap_event.c: In function
On 23-05-18, 12:20, Joe Perches wrote:
> Convert the S_ symbolic permissions to their octal equivalents as
> using octal and not symbolic permissions is preferred by many as more
> readable.
>
> see: https://lkml.org/lkml/2016/8/2/1945
>
> Done with automated conversion via:
> $ ./scripts/checkpa
On Wed, May 23, 2018 at 08:59:06PM -0400, Theodore Y. Ts'o wrote:
> On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote:
> >
> > We've learnt this lesson the hard way over and over again: don't
> > parse untrusted input in privileged contexts. How many times do we
> > have to make the sam
On Wed, May 23, 2018 at 05:54:50PM -0700, Joel Fernandes wrote:
> On Wed, May 23, 2018 at 12:23:49PM -0700, Paul E. McKenney wrote:
> > On Wed, May 23, 2018 at 09:06:17AM -0700, Paul E. McKenney wrote:
> > > On Tue, May 22, 2018 at 11:38:14PM -0700, Joel Fernandes wrote:
> > > > From: "Joel Fernand
scripts/kallsyms.c: function write_src:
"printf", the #1 format specifier "d" need arg type "int",
but the according arg "table_cnt" has type "unsigned int"
scripts/recordmcount.c: function do_file:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "(*w2)(ehdr->e_ma
+static int skl_tplg_get_pvt_data_v4(struct snd_soc_tplg_dapm_widget
*tplg_w,
+ struct skl *skl, struct device *dev,
+ struct skl_module_cfg *mconfig)
+{
+ struct skl_dfw_v4_module *dfw =
+ (struct
> A non-fatal signal being delivered to a task which is
> in the middle of a page fault may well end up in an
> infinite loop, attempting to handle the page fault and
> failing forever.
>
> On seeing NOPAGE, the fault handler believes the PTE
> is in the page table, so does nothing before it return
On 05/23/2018 07:36 PM, Michal Hocko wrote:
> On Wed 23-05-18 19:15:51, Anshuman Khandual wrote:
>> On 05/23/2018 06:25 PM, Michal Hocko wrote:
>>> when adding memory to a node that is currently offline.
>>>
>>> The VM_WARN_ON is just too loud without a good reason. In this
>>> particular case we a
On Wed, May 23, 2018 at 5:10 PM, Jerome Glisse wrote:
> On Mon, May 21, 2018 at 03:35:14PM -0700, Dan Williams wrote:
>> Hi Andrew, please consider this series for 4.18.
>>
>> For maintainability, as ZONE_DEVICE continues to attract new users,
>> it is useful to keep all users consolidated on devm
format specifier "d" need arg type "int" , but the according arg
"fdt32_to_cpu(xxx)" has type "unsigned int"
Signed-off-by: nixiaoming
---
scripts/dtc/fdtdump.c | 6 +++---
scripts/dtc/flattree.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/dtc/fdtdump.c b/scri
On Mon, 2018-04-30 at 11:18 +0100, Lee Jones wrote:
> On Fri, 27 Apr 2018, matthias@kernel.org wrote:
>
> > From: Matthias Brugger
> >
> > The MMSYS subsystem includes clocks and drm components.
> > This patch adds a MFD device to probe both drivers from the same
> > device tree compatible.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: bee797529d7c1ea4e2803fda067d20edbc00bc3d
commit: 02c7b25e5f54321b9063e18d4f52cce07f8e081d netfilter: nf_tables: build-in
filter chain type
date: 8 weeks ago
config: x86_64-randconfig-s0-05240812 (attached
On (05/18/18 15:08), Dmitry Vyukov wrote:
[..]
> >> What consoles do support it?
> >> We are interested at least in qemu console, GCE console and Android
> >> phone consoles. But it would be pity if this can't be used on various
> >> development boards too.
> >
> > Only the netconsole is able to sh
On 05/23/2018 06:43 PM, Masahiro Yamada wrote:
2018-05-24 9:11 GMT+09:00 Masahiro Yamada :
2018-05-24 7:53 GMT+09:00 Laura Abbott :
On 05/22/2018 05:33 PM, Andy Lutomirski wrote:
On Tue, May 22, 2018 at 5:19 PM Laura Abbott wrote:
The vDSO is linked separately from the kernel and modules.
On (05/18/18 14:15), Petr Mladek wrote:
> > Dunno...
> > For instance, can we store context tracking info as a extended record
> > data? We have that dict/dict_len thing. So may we can store tracking
> > info there? Extended records will appear on the serial console /* if
> > console supports exten
On 5/23/18 6:50 PM, Jakub Kicinski wrote:
On Wed, 23 May 2018 18:33:52 -0700, Jakub Kicinski wrote:
Minor glitch with Ubuntu 18.04:
$ gcc --version
gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
In file included from /usr/include/fcntl.h:290:0,
from ../net/bpfilter/main.c:7:
In function ‘
Frederic Weisbecker writes:
> diff --git a/arch/powerpc/kernel/hw_breakpoint.c
> b/arch/powerpc/kernel/hw_breakpoint.c
> index 348cac9..fba6527 100644
> --- a/arch/powerpc/kernel/hw_breakpoint.c
> +++ b/arch/powerpc/kernel/hw_breakpoint.c
> @@ -139,30 +139,31 @@ int arch_bp_generic_fields(int ty
Hi all, I'd like to quote reply of Robin Murphy at
http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
I would suggest s/pin number/bit number in the associated GRF register/
here. At least in this RK3328 case there's only one pin, which isn't
numbered, and if you naively
2018-05-23 9:19 GMT+09:00 Laura Abbott :
>
> The vDSO is linked separately from the kernel and modules. Ensure it picks
> up the comment section, if available.
>
> Signed-off-by: Laura Abbott
> ---
> v3: Invoke the generated linker script. The ".." nightmare is pretty
> ugly but I didn't see an ea
Frederic Weisbecker writes:
> diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
> index 6e28d28..51320c2 100644
> --- a/kernel/events/hw_breakpoint.c
> +++ b/kernel/events/hw_breakpoint.c
> @@ -424,19 +443,22 @@ static int validate_hw_breakpoint(struct perf_event *bp)
>
On Wed, 23 May 2018 18:33:52 -0700, Jakub Kicinski wrote:
> Minor glitch with Ubuntu 18.04:
>
> $ gcc --version
> gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
>
> In file included from /usr/include/fcntl.h:290:0,
> from ../net/bpfilter/main.c:7:
> In function ‘open’,
> inlined from ‘ma
Would anyone please take a look at this ?
Thanks in advance
Jianchao
On 05/23/2018 11:55 AM, jianchao.wang wrote:
>
>
> Hi all
>
> Our customer met a panic triggered by BUG_ON in blk_finish_request.
>>From the dmesg log, the BUG_ON was triggered after command abort occurred
>>many times.
> Th
Hi Mark,
Mark Rutland writes:
> As a step towards unifying the atomic/atomic64/atomic_long APIs, this
> patch converts the arch/powerpc implementation of atomic64_add_unless()
> into an implementation of atomic64_fetch_add_unless().
>
> A wrapper in will build atomic_add_unless() atop of
> this,
Hi Petr,
On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> On Wed, 23 May 2018 10:53:55 -0500
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
> > Dave Young writes:
> >
> > > [snip]
> > >
> > >> >
> > >> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB
> > >> > + int "System memory size thr
Store the HWP request value last set using MSR_HWP_REQUEST. This will
allow us to save cycles used for reading last HWP request value for
dynamic update of MSR_HWP_REQUEST.
Also store HWP capability MSR value in local memory, to avoid reading
MSR later for calculating limits for dynamic update of M
Enable HWP boost on Skylake server platform.
Signed-off-by: Srinivas Pandruvada
---
drivers/cpufreq/intel_pstate.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index b2613c9775d5..6f8214a40764 100644
--- a/drivers/cp
Added two utility functions to HWP boost up gradually and boost down to
the default cached HWP request values.
Boost up:
Boost up updates HWP request minimum value in steps. This minimum value
can reach upto at HWP request maximum values depends on how frequently,
the IOWAIT flag is set. At max, b
v2
This is a much simpler version than the previous one and only consider IO
boost, using the existing mechanism. There is no change in this series
beyond intel_pstate driver.
Once PeterZ finishes his work on frequency invariant, I will revisit
thread migration optimization in HWP mode.
Other cha
When HWP dynamic boost is active then set the HWP specific update util
hook.
Signed-off-by: Srinivas Pandruvada
---
drivers/cpufreq/intel_pstate.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pst
This change uses SCHED_CPUFREQ_IOWAIT flag to boost HWP performance.
Since SCHED_CPUFREQ_IOWAIT flag is set frequently, we don't start
boosting steps unless we see two consecutive flags in two ticks. This
avoids boosting due to IO because of regular system activities.
To avoid synchronization issu
A new attribute is added to intel_pstate sysfs to enable/disable
HWP dynamic performance boost.
Signed-off-by: Srinivas Pandruvada
---
drivers/cpufreq/intel_pstate.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufr
2018-05-24 9:11 GMT+09:00 Masahiro Yamada :
> 2018-05-24 7:53 GMT+09:00 Laura Abbott :
>> On 05/22/2018 05:33 PM, Andy Lutomirski wrote:
>>>
>>> On Tue, May 22, 2018 at 5:19 PM Laura Abbott wrote:
>>>
>>>
The vDSO is linked separately from the kernel and modules. Ensure it
picks
up
Okay, I'll try to split it.
On 三, 2018-05-23 at 19:04 +0530, Vinod wrote:
> On 23-05-18, 12:56, s.ha...@pengutronix.de wrote:
>
> >
> > Well, it's somewhat related to virtual dma support, but that's not
> > my
> > point. My point is that this patch is quite big and thus hard to
> > review.
> > If
Hi Eric,
On 05/23/18 at 10:53am, Eric W. Biederman wrote:
> Dave Young writes:
>
> > [snip]
> >
> >> >
> >> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB
> >> > +int "System memory size threshold for kdump memory default
> >> > reserving"
> >> > +depends on CRASH_CORE
> >> > +
On 05/23/2018 05:06 PM, Linus Torvalds wrote:
On Wed, May 23, 2018, 17:01 Andy Lutomirski mailto:l...@amacapital.net>> wrote:
I don’t know whether I’m missing something obvious, but can’t this be in C?
Yes, but I thought Laura wanted to limit it to linker file tricks (this thread
has g
On Wed, 23 May 2018 17:51:19 -0700
Joel Fernandes wrote:
> Shouldn't this assignment be done outside the loop? I believe the variable
> will be initialized on each iteration.
>
> A program like this doesn't terminate:
>
> #include
>
> int main() {
> for (;;) {
> int i = 10;
1 - 100 of 1075 matches
Mail list logo