From: Russ Dill
SoCs like AM43XX lose clock registers context during RTC-only
suspend. Hence add functions to save/restore the clock registers
context.
Signed-off-by: Keerthy
Signed-off-by: Russ Dill
---
drivers/clk/ti/clock.h| 2 +
drivers/clk/ti/divider.c | 36 ++
On 05-06-18, 18:59, Janusz Krzysztofik wrote:
> Commit 0198d7bb8a0c ("ASoC: omap-mcbsp: Convert to use the sdma-pcm
> instead of omap-pcm") resulted in broken audio playback on OMAP1510
> (discovered on Amstrad Delta).
>
> When running on OMAP1510, omap-pcm used to obtain DMA offset from
>
The default restore context function enables or disables
the clock based on the enable_count. This is done in cases
where the clock context is lost and based on the enable_count
the clock either needs to be enabled/disabled. This particularly
helps restore the state of gate clocks.
Signed-off-by:
From: Russ Dill
SoCs like AM43XX lose clock registers context during RTC-only
suspend. Hence add functions to save/restore the clock registers
context.
Signed-off-by: Keerthy
Signed-off-by: Russ Dill
---
drivers/clk/ti/clock.h| 2 +
drivers/clk/ti/divider.c | 36 ++
On 05-06-18, 18:59, Janusz Krzysztofik wrote:
> Commit 0198d7bb8a0c ("ASoC: omap-mcbsp: Convert to use the sdma-pcm
> instead of omap-pcm") resulted in broken audio playback on OMAP1510
> (discovered on Amstrad Delta).
>
> When running on OMAP1510, omap-pcm used to obtain DMA offset from
>
The default restore context function enables or disables
the clock based on the enable_count. This is done in cases
where the clock context is lost and based on the enable_count
the clock either needs to be enabled/disabled. This particularly
helps restore the state of gate clocks.
Signed-off-by:
Deep enough power saving mode can result into losing context of the clock
registers also, and they need to be restored once coming back from the power
saving mode. Hence add functions to save/restore clock context.
Tested for DS0 on am437x-gp-evm
Based on top of linux-next
Keerthy (2):
clk:
Deep enough power saving mode can result into losing context of the clock
registers also, and they need to be restored once coming back from the power
saving mode. Hence add functions to save/restore clock context.
Tested for DS0 on am437x-gp-evm
Based on top of linux-next
Keerthy (2):
clk:
Save/restore clk context based on enable_off_mode setting.
The context needs to be saved at the very end of suspend path
and restored at the beginning of resume path.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/pm33xx-core.c| 15 +++
drivers/soc/ti/pm33xx.c | 13
Save/restore clk context based on enable_off_mode setting.
The context needs to be saved at the very end of suspend path
and restored at the beginning of resume path.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/pm33xx-core.c| 15 +++
drivers/soc/ti/pm33xx.c | 13
Hi Enric,
On 2018년 06월 18일 18:10, Enric Balletbo Serra wrote:
> Hi Chanwoo,
>
> Missatge de Chanwoo Choi del dia dg., 17 de juny
> 2018 a les 5:23:
>>
>> Hi Enric,
>>
>> 2018-06-16 0:12 GMT+09:00 Enric Balletbo i Serra
>> :
>>> The opp table is not removed when the driver is unloaded neither
Hi Enric,
On 2018년 06월 18일 18:10, Enric Balletbo Serra wrote:
> Hi Chanwoo,
>
> Missatge de Chanwoo Choi del dia dg., 17 de juny
> 2018 a les 5:23:
>>
>> Hi Enric,
>>
>> 2018-06-16 0:12 GMT+09:00 Enric Balletbo i Serra
>> :
>>> The opp table is not removed when the driver is unloaded neither
Hi Tony,
thanks for doing this!
I cannot find the original bug report in linux-gpio, so I'll comment
on this single patch only.
On Fri, Jun 15, 2018 at 04:11:40AM -0700, Tony Lindgren wrote:
> We must use a mutex around the generic_add functions and save the
> function and group selector in
Hi Tony,
thanks for doing this!
I cannot find the original bug report in linux-gpio, so I'll comment
on this single patch only.
On Fri, Jun 15, 2018 at 04:11:40AM -0700, Tony Lindgren wrote:
> We must use a mutex around the generic_add functions and save the
> function and group selector in
This patch fixes wrong name of headphone widget for receiving events
of insert/remove headphone plug from simple-card or audio-graph-card.
If we use wrong widget name then we get warning messages such as
"asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
when the plug is inserted or
This patch fixes wrong name of headphone widget for receiving events
of insert/remove headphone plug from simple-card or audio-graph-card.
If we use wrong widget name then we get warning messages such as
"asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
when the plug is inserted or
This patch adds GPIO for headphone detection on LD20 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
This patch adds GPIO for headphone detection on LD11 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
This patch adds GPIO for headphone detection on LD20 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
This patch adds GPIO for headphone detection on LD11 global board.
Signed-off-by: Katsuhiro Suzuki
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> Hi Jason, yes please do send me the test suite with the kernel config.
$ git clone https://git.zx2c4.com/WireGuard
$ cd WireGuard/src
$ [[ $(gcc -v 2>&1) =~ gcc\ version\ 8\.1\.0 ]] || echo crash needs 8.1
$ export DEBUG_KERNEL=yes
$ export
On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> Hi Jason, yes please do send me the test suite with the kernel config.
$ git clone https://git.zx2c4.com/WireGuard
$ cd WireGuard/src
$ [[ $(gcc -v 2>&1) =~ gcc\ version\ 8\.1\.0 ]] || echo crash needs 8.1
$ export DEBUG_KERNEL=yes
$ export
On Mon, Jun 18 2018, Christoph Hellwig wrote:
> On Mon, Jun 18, 2018 at 02:55:20PM +1000, NeilBrown wrote:
>> This set of patches makes it possible to build a module from
>> code in multiple directories without needing to list files from one
>> directory in the Makefile of another directory.
>>
On Mon, Jun 18 2018, Christoph Hellwig wrote:
> On Mon, Jun 18, 2018 at 02:55:20PM +1000, NeilBrown wrote:
>> This set of patches makes it possible to build a module from
>> code in multiple directories without needing to list files from one
>> directory in the Makefile of another directory.
>>
On Mon, Jun 18, 2018 at 7:51 PM Jason A. Donenfeld wrote:
>
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
>
On Mon, Jun 18, 2018 at 7:51 PM Jason A. Donenfeld wrote:
>
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
>
This patch allows a "mod.a" to be built in any
directory. A previous patch allows that mod.a
to be included in any module or another mod.a.
This is achieved via a new pair of macros: modobj-y and modobj-m.
Anything in modobj-y is added to obj-y and is otherwise
ignored.
Anything listed in
This patch allows a "mod.a" to be built in any
directory. A previous patch allows that mod.a
to be included in any module or another mod.a.
This is achieved via a new pair of macros: modobj-y and modobj-m.
Anything in modobj-y is added to obj-y and is otherwise
ignored.
Anything listed in
Hi David,
We run CRIU tests for vfs/for-next, and today a few of these test failed. I
found that the problem appears after this patch..
https://travis-ci.org/avagin/linux/jobs/393766778
The reproducer is attached. It creates a process in a new set of namespaces
(user, mount, etc) and then this
Hi David,
We run CRIU tests for vfs/for-next, and today a few of these test failed. I
found that the problem appears after this patch..
https://travis-ci.org/avagin/linux/jobs/393766778
The reproducer is attached. It creates a process in a new set of namespaces
(user, mount, etc) and then this
On 6/19/18 2:58 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> I noticed the group frequently got throttled even it consumed
>> low cpu usage, this caused some jitters on the response time
>> to some of our business containers enabling cpu quota.
>>
>> It's very easy to reproduce:
>>
On 6/19/18 2:58 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> I noticed the group frequently got throttled even it consumed
>> low cpu usage, this caused some jitters on the response time
>> to some of our business containers enabling cpu quota.
>>
>> It's very easy to reproduce:
>>
Hi Dan,
> We need to decrement device->users-- on the error paths as well.
> This function was already slightly broken with respect to counting the
> users, but let's not make it worse.
>
> I think it's still a tiny bit racy because it's not an atomic type.
Oh right, I missed that. I'll fix it
Hi Dan,
> We need to decrement device->users-- on the error paths as well.
> This function was already slightly broken with respect to counting the
> users, but let's not make it worse.
>
> I think it's still a tiny bit racy because it's not an atomic type.
Oh right, I missed that. I'll fix it
On Tue, Jun 12, 2018 at 01:28:42PM -0500, Li Yang wrote:
> Replace license text with corresponding SPDX identifiers and update the
> format of existing SPDX identifiers to follow the new guideline
> Documentation/process/license-rules.rst.
>
> Note that some of the files mentioned X11 license
On Tue, Jun 12, 2018 at 01:28:42PM -0500, Li Yang wrote:
> Replace license text with corresponding SPDX identifiers and update the
> format of existing SPDX identifiers to follow the new guideline
> Documentation/process/license-rules.rst.
>
> Note that some of the files mentioned X11 license
autofs_expire_direct() isn't used outside of fs/autofs/expire.c
so make it static.
Signed-off-by: Ian Kent
---
fs/autofs/autofs_i.h |3 ---
fs/autofs/expire.c |8
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h
index
autofs_expire_direct() isn't used outside of fs/autofs/expire.c
so make it static.
Signed-off-by: Ian Kent
---
fs/autofs/autofs_i.h |3 ---
fs/autofs/expire.c |8
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h
index
The user space automount(8) daemon is meant to perform a forced
expire when sent a SIGUSR2.
But since the expiration is routed through the kernel and the
kernel doesn't send an expire request if the mount is busy this
hasn't worked at least since autofs version 5.
Add an AUTOFS_EXP_FORCED flag
Make the usage of the expire flags consistent by naming
the expire flags the same as it is named in the version
5 miscelaneous ioctl parameters and only check the bit
flags when needed.
Signed-off-by: Ian Kent
---
fs/autofs/autofs_i.h |2 +-
fs/autofs/expire.c | 61
The user space automount(8) daemon is meant to perform a forced
expire when sent a SIGUSR2.
But since the expiration is routed through the kernel and the
kernel doesn't send an expire request if the mount is busy this
hasn't worked at least since autofs version 5.
Add an AUTOFS_EXP_FORCED flag
Make the usage of the expire flags consistent by naming
the expire flags the same as it is named in the version
5 miscelaneous ioctl parameters and only check the bit
flags when needed.
Signed-off-by: Ian Kent
---
fs/autofs/autofs_i.h |2 +-
fs/autofs/expire.c | 61
autofs_expire_indirect() isn't used outside of fs/autofs/expire.c
so make it static.
Signed-off-by: Ian Kent
---
fs/autofs/autofs_i.h |3 ---
fs/autofs/expire.c |8
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h
autofs_expire_indirect() isn't used outside of fs/autofs/expire.c
so make it static.
Signed-off-by: Ian Kent
---
fs/autofs/autofs_i.h |3 ---
fs/autofs/expire.c |8
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h
The global variable "now" in fs/autofs/expire.c is used in
an inconsistent way, sometimes using jiffies directly, and
sometimes using the "now" variable, and setting it isn't done
consistently either.
But the autofs dentry info last_used field is only updated
during path walks or during expire so
The global variable "now" in fs/autofs/expire.c is used in
an inconsistent way, sometimes using jiffies directly, and
sometimes using the "now" variable, and setting it isn't done
consistently either.
But the autofs dentry info last_used field is only updated
during path walks or during expire so
The expire flag AUTOFS_EXP_LEAVES is cleared before the second
call to should_expire() in autofs_expire_indirect() but the
parameter passed in the second call is incorrect.
Fortunately AUTOFS_EXP_LEAVES expire flag has not been used for
a long time but might be needed in the future so fix it
The expire flag AUTOFS_EXP_LEAVES is cleared before the second
call to should_expire() in autofs_expire_indirect() but the
parameter passed in the second call is incorrect.
Fortunately AUTOFS_EXP_LEAVES expire flag has not been used for
a long time but might be needed in the future so fix it
Andrew,
Very sorry, clearly I have already sent this to you.
Unfortunately I didn't stop this in time, please ignore.
On Tue, 2018-06-19 at 10:50 +0800, Ian Kent wrote:
> Depending on how it is configured the autofs user space daemon can
> leave in use mounts mounted at exit and re-connect to
Andrew,
Very sorry, clearly I have already sent this to you.
Unfortunately I didn't stop this in time, please ignore.
On Tue, 2018-06-19 at 10:50 +0800, Ian Kent wrote:
> Depending on how it is configured the autofs user space daemon can
> leave in use mounts mounted at exit and re-connect to
On 6/19/18 2:44 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> The current condition to judge clock drift in expire_cfs_rq_runtime()
>> is wrong, the two runtime_expires are actually the same when clock
>> drift happens, so this condtion can never hit. The orginal design was
>>
On 6/19/18 2:44 AM, bseg...@google.com wrote:
> Xunlei Pang writes:
>
>> The current condition to judge clock drift in expire_cfs_rq_runtime()
>> is wrong, the two runtime_expires are actually the same when clock
>> drift happens, so this condtion can never hit. The orginal design was
>>
On Mon, Jun 18, 2018 at 04:11:09PM +0300, Leonard Crestez wrote:
> Two different regulators are defined with the same name and label but
> distinct properties.
>
> The first definition was added with the first board dts and the second
> was added when upstream added flexcan support.
>
> Looking
On Mon, Jun 18, 2018 at 04:11:09PM +0300, Leonard Crestez wrote:
> Two different regulators are defined with the same name and label but
> distinct properties.
>
> The first definition was added with the first board dts and the second
> was added when upstream added flexcan support.
>
> Looking
On Mon, Jun 18, 2018 at 11:15:44AM +0300, Leonard Crestez wrote:
> The following sensors are on I2C3 on the baseboard:
> * isil,isl29023 light sensor
> * fsl,mag3110 magnetometer
> * fsl,mma8451 accelerometer
>
> Added under i2cmux/i2c@1 because they're not otherwise accessible.
>
> These are
On Mon, Jun 18, 2018 at 11:15:44AM +0300, Leonard Crestez wrote:
> The following sensors are on I2C3 on the baseboard:
> * isil,isl29023 light sensor
> * fsl,mag3110 magnetometer
> * fsl,mma8451 accelerometer
>
> Added under i2cmux/i2c@1 because they're not otherwise accessible.
>
> These are
Hello Shakeel,
It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
introduced a regression. I've bisected a failing test to this commit,
and after staring at the my code for a long time, I'm unable to find a
bug that this commit might have unearthed. Rather, it looks like this
Hello Shakeel,
It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
introduced a regression. I've bisected a failing test to this commit,
and after staring at the my code for a long time, I'm unable to find a
bug that this commit might have unearthed. Rather, it looks like this
Depending on how it is configured the autofs user space daemon can
leave in use mounts mounted at exit and re-connect to them at start
up. But for this to work best the state of the autofs file system
needs to be left intact over the restart.
Also, at system shutdown, mounts in an autofs file
Depending on how it is configured the autofs user space daemon can
leave in use mounts mounted at exit and re-connect to them at start
up. But for this to work best the state of the autofs file system
needs to be left intact over the restart.
Also, at system shutdown, mounts in an autofs file
On Thu, Jun 07, 2018 at 07:21:31PM +0530, Jagan Teki wrote:
> i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected
> to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for
> Android and video capture application.
>
> notable features:
> CPU
On Thu, Jun 07, 2018 at 07:21:31PM +0530, Jagan Teki wrote:
> i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected
> to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for
> Android and video capture application.
>
> notable features:
> CPU
Greg Kroah-Hartman wrote:
4.16-stable review patch. If anyone has any objections, please let me know.
Please drop this and the next patch since these depend on commit
e145242ea0df6, which is not in v4.16.
- Naveen
--
From: "Naveen N. Rao"
[ Upstream commit
Greg Kroah-Hartman wrote:
4.16-stable review patch. If anyone has any objections, please let me know.
Please drop this and the next patch since these depend on commit
e145242ea0df6, which is not in v4.16.
- Naveen
--
From: "Naveen N. Rao"
[ Upstream commit
On Thu, Jun 07, 2018 at 07:17:48PM +0530, Jagan Teki wrote:
> From: Michael Trimarchi
>
> Add USB host and device support for BTicino i.MX6DL Mamoj board.
>
> Signed-off-by: Simone CIANNI
> Signed-off-by: Raffaele RECALCATI
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Jagan Teki
>
On Thu, Jun 07, 2018 at 07:17:48PM +0530, Jagan Teki wrote:
> From: Michael Trimarchi
>
> Add USB host and device support for BTicino i.MX6DL Mamoj board.
>
> Signed-off-by: Simone CIANNI
> Signed-off-by: Raffaele RECALCATI
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Jagan Teki
>
On Thu, Jun 07, 2018 at 07:17:47PM +0530, Jagan Teki wrote:
> Add TI WL18XX Wifi for BTicino i.MX6DL board.
>
> Signed-off-by: Simone CIANNI
> Signed-off-by: Raffaele RECALCATI
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Jagan Teki
> Reviewed-by: Fabio Estevam
> ---
> Changes for v2:
On Thu, Jun 07, 2018 at 07:17:47PM +0530, Jagan Teki wrote:
> Add TI WL18XX Wifi for BTicino i.MX6DL board.
>
> Signed-off-by: Simone CIANNI
> Signed-off-by: Raffaele RECALCATI
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Jagan Teki
> Reviewed-by: Fabio Estevam
> ---
> Changes for v2:
Greg Kroah-Hartman wrote:
4.14-stable review patch. If anyone has any objections, please let me know.
Please drop this and the next patch since these depend on commit
e145242ea0df6, which is not in v4.14.
- Naveen
--
From: "Naveen N. Rao"
[ Upstream commit
On Thu, Jun 07, 2018 at 07:17:46PM +0530, Jagan Teki wrote:
> This patch adds parallel display support for i.MX6DL Mamoj board
> along with relevant backlight through pwm.
>
> LCD power sequence is added by 'Michael Trimarchi'.
>
> Signed-off-by: Simone CIANNI
> Signed-off-by: Raffaele
Greg Kroah-Hartman wrote:
4.14-stable review patch. If anyone has any objections, please let me know.
Please drop this and the next patch since these depend on commit
e145242ea0df6, which is not in v4.14.
- Naveen
--
From: "Naveen N. Rao"
[ Upstream commit
On Thu, Jun 07, 2018 at 07:17:46PM +0530, Jagan Teki wrote:
> This patch adds parallel display support for i.MX6DL Mamoj board
> along with relevant backlight through pwm.
>
> LCD power sequence is added by 'Michael Trimarchi'.
>
> Signed-off-by: Simone CIANNI
> Signed-off-by: Raffaele
On Mon, Jun 18, 2018 at 06:36:06PM -0700, Joel Fernandes wrote:
>
>
> On June 18, 2018 6:08:03 PM PDT, "Paul E. McKenney"
> wrote:
> >On Mon, Jun 18, 2018 at 03:26:47PM -0700, Joel Fernandes wrote:
> >> On Mon, Jun 18, 2018 at 09:56:46AM -0700, Paul E. McKenney wrote:
> >> > > The reason for
On Mon, Jun 18, 2018 at 06:36:06PM -0700, Joel Fernandes wrote:
>
>
> On June 18, 2018 6:08:03 PM PDT, "Paul E. McKenney"
> wrote:
> >On Mon, Jun 18, 2018 at 03:26:47PM -0700, Joel Fernandes wrote:
> >> On Mon, Jun 18, 2018 at 09:56:46AM -0700, Paul E. McKenney wrote:
> >> > > The reason for
Hi Stefan,
Can you take a look at the patch? Thanks.
Shawn
On Tue, Jun 05, 2018 at 10:43:26PM +0100, Suzuki K Poulose wrote:
> Switch to the updated coresight bindings.
>
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: Mathieu Poirier
>
Hi Stefan,
Can you take a look at the patch? Thanks.
Shawn
On Tue, Jun 05, 2018 at 10:43:26PM +0100, Suzuki K Poulose wrote:
> Switch to the updated coresight bindings.
>
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: Mathieu Poirier
>
Hi all,
After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from arch/powerpc/include/asm/thread_info.h:27:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
Hi all,
After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from arch/powerpc/include/asm/thread_info.h:27:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
On Tue, 19 Jun 2018, Andy Shevchenko wrote:
> On Sun, Jun 17, 2018 at 10:07 PM, Nicolas Pitre
> wrote:
> > Make sure the unicode screen buffer matches the video screen content.
> > This is provided for debugging convenience and disabled by default.
>
> > +#define VC_UNI_SCREEN_DEBUG 0
>
> > +
On Tue, 19 Jun 2018, Andy Shevchenko wrote:
> On Sun, Jun 17, 2018 at 10:07 PM, Nicolas Pitre
> wrote:
> > Make sure the unicode screen buffer matches the video screen content.
> > This is provided for debugging convenience and disabled by default.
>
> > +#define VC_UNI_SCREEN_DEBUG 0
>
> > +
Hi Al,
After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/cxlflash/ocxl_hw.c:62:12: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.mount = ocxlflash_fs_mount,
^~
From: Todd Poynor
Add initcall_debug logs for the amount of time taken by each OF platform
bus device create call. For example:
of platform device create /reserved-memory/ramoops@a380 took
3255 usecs
initcall_debug already reports the total of all such device creates
as a single
Hi Randy,
On 06/12/2018 05:07 PM, Randy Dunlap wrote:
> On 06/12/2018 01:39 PM, Jayant Chowdhary wrote:
>> Hi Randy,
>>
>> On 06/11/2018 10:49 PM, Randy Dunlap wrote:
>>> Hi,
>>>
>>> Here is what I have so far. It begins with a makefile and some
>>> template files that are added to. There's a
Hi Al,
After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/cxlflash/ocxl_hw.c:62:12: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.mount = ocxlflash_fs_mount,
^~
From: Todd Poynor
Add initcall_debug logs for the amount of time taken by each OF platform
bus device create call. For example:
of platform device create /reserved-memory/ramoops@a380 took
3255 usecs
initcall_debug already reports the total of all such device creates
as a single
Hi Randy,
On 06/12/2018 05:07 PM, Randy Dunlap wrote:
> On 06/12/2018 01:39 PM, Jayant Chowdhary wrote:
>> Hi Randy,
>>
>> On 06/11/2018 10:49 PM, Randy Dunlap wrote:
>>> Hi,
>>>
>>> Here is what I have so far. It begins with a makefile and some
>>> template files that are added to. There's a
On 19/06/18 12:35, Chris Packham wrote:
> On 19/06/18 01:15, Miquel Raynal wrote:
>> Hi Chris,
>>
>> On Mon, 18 Jun 2018 16:52:53 +1200, Chris Packham
>> wrote:
>>
>>> Hi,
>>>
>>> I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
>>> to one of our boards which uses the
On 19/06/18 12:35, Chris Packham wrote:
> On 19/06/18 01:15, Miquel Raynal wrote:
>> Hi Chris,
>>
>> On Mon, 18 Jun 2018 16:52:53 +1200, Chris Packham
>> wrote:
>>
>>> Hi,
>>>
>>> I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
>>> to one of our boards which uses the
On 6/18/2018 6:45 PM, Peter Zijlstra wrote:
On Mon, Jun 18, 2018 at 02:55:32PM +0800, Jin, Yao wrote:
Thanks for providing the patch. I understand this approach.
In my opinion, the skid window is from counter overflow to interrupt
delivered. While if the skid window is too *big* (e.g. user
On 6/18/2018 6:45 PM, Peter Zijlstra wrote:
On Mon, Jun 18, 2018 at 02:55:32PM +0800, Jin, Yao wrote:
Thanks for providing the patch. I understand this approach.
In my opinion, the skid window is from counter overflow to interrupt
delivered. While if the skid window is too *big* (e.g. user
On June 18, 2018 6:08:03 PM PDT, "Paul E. McKenney"
wrote:
>On Mon, Jun 18, 2018 at 03:26:47PM -0700, Joel Fernandes wrote:
>> On Mon, Jun 18, 2018 at 09:56:46AM -0700, Paul E. McKenney wrote:
>> > > The reason for the rcutorture test failure could be that the
>default
>> > > kthread_prio for
On June 18, 2018 6:08:03 PM PDT, "Paul E. McKenney"
wrote:
>On Mon, Jun 18, 2018 at 03:26:47PM -0700, Joel Fernandes wrote:
>> On Mon, Jun 18, 2018 at 09:56:46AM -0700, Paul E. McKenney wrote:
>> > > The reason for the rcutorture test failure could be that the
>default
>> > > kthread_prio for
Hi Al,
After merging the vfs tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
:1338:2: warning: #warning syscall open_tree not implemented [-Wcpp]
:1341:2: warning: #warning syscall move_mount not implemented [-Wcpp]
:1344:2: warning: #warning syscall fsopen not
Hi Al,
After merging the vfs tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
:1338:2: warning: #warning syscall open_tree not implemented [-Wcpp]
:1341:2: warning: #warning syscall move_mount not implemented [-Wcpp]
:1344:2: warning: #warning syscall fsopen not
On 06/18/2018 02:00 PM, Claudiu Beznea wrote:
>
>
> On 18.06.2018 12:53, Marek Vasut wrote:
>> On 06/18/2018 11:49 AM, Boris Brezillon wrote:
>>> Hi Claudiu,
>>>
>>> The subject prefix should be "mtd: spi-nor: atmel-quadspi: ". No need
>>> to send a new version just for that, I'll fix it when
On 06/18/2018 02:00 PM, Claudiu Beznea wrote:
>
>
> On 18.06.2018 12:53, Marek Vasut wrote:
>> On 06/18/2018 11:49 AM, Boris Brezillon wrote:
>>> Hi Claudiu,
>>>
>>> The subject prefix should be "mtd: spi-nor: atmel-quadspi: ". No need
>>> to send a new version just for that, I'll fix it when
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
include/uapi/linux/fs.h
between commit:
1d91ca426d8d ("Partially revert "locks: fix file locking on overlayfs"")
from the overlayfs tree and commit:
28514d1edad4 ("vfs: Suppress MS_* flag defs within the kernel unless
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
include/uapi/linux/fs.h
between commit:
1d91ca426d8d ("Partially revert "locks: fix file locking on overlayfs"")
from the overlayfs tree and commit:
28514d1edad4 ("vfs: Suppress MS_* flag defs within the kernel unless
Aurelien spotted a problem with the patch - will resend to you
On Mon, Jun 18, 2018 at 12:34 PM, Gustavo A. R. Silva
wrote:
> Hey Steve,
>
> On 06/18/2018 12:18 PM, Steve French wrote:
>>
>> Gustavo,
>> Thx for pointing this out. Let me know if this patch addresses what
>> you found. Code is
Aurelien spotted a problem with the patch - will resend to you
On Mon, Jun 18, 2018 at 12:34 PM, Gustavo A. R. Silva
wrote:
> Hey Steve,
>
> On 06/18/2018 12:18 PM, Steve French wrote:
>>
>> Gustavo,
>> Thx for pointing this out. Let me know if this patch addresses what
>> you found. Code is
101 - 200 of 2166 matches
Mail list logo
