Hi,
Here is a driver for the RTC found inside of the
Motorola Droid 4 based on linux-next 2017021.
I tried to set & get the time using hwclock and
used ./tools/testing/selftests/timers/rtctest.c:
$ ./rtctest
RTC Driver Test Example.
Counting 5 update (1/sec) interrupts
Hi,
Here is a driver for the RTC found inside of the
Motorola Droid 4 based on linux-next 2017021.
I tried to set & get the time using hwclock and
used ./tools/testing/selftests/timers/rtctest.c:
$ ./rtctest
RTC Driver Test Example.
Counting 5 update (1/sec) interrupts
This driver supports the Motorola CPCAP PMIC found on
some of Motorola's mobile phones, such as the Droid 4.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/rtc/cpcap-rtc.txt | 13 +
drivers/rtc/Kconfig| 7 +
This driver supports the Motorola CPCAP PMIC found on
some of Motorola's mobile phones, such as the Droid 4.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/rtc/cpcap-rtc.txt | 13 +
drivers/rtc/Kconfig| 7 +
drivers/rtc/Makefile
On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
> I don't think that's a regression in this series, it just triggers more easily
> with this series. The BLOCK_PC removal fixes aren't touching device life times
> at all.
Yes.
> That said, we will look into this again, of course.
On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
> I don't think that's a regression in this series, it just triggers more easily
> with this series. The BLOCK_PC removal fixes aren't touching device life times
> at all.
Yes.
> That said, we will look into this again, of course.
On 2017年02月20日 15:08, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2
On 2017年02月20日 15:08, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2
Hi Arushi,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.10 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Arushi,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.10 next-20170217]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
* Kees Cook wrote:
> On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote:
> > Hi!
> >
> >>
> >> -config DEBUG_RODATA
> >> +config STRICT_KERNEL_RWX
> >> bool "Make kernel text and rodata read-only" if
> >> ARCH_OPTIONAL_KERNEL_RWX
> >> depends
* Kees Cook wrote:
> On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote:
> > Hi!
> >
> >>
> >> -config DEBUG_RODATA
> >> +config STRICT_KERNEL_RWX
> >> bool "Make kernel text and rodata read-only" if
> >> ARCH_OPTIONAL_KERNEL_RWX
> >> depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>
These are patches designed to improve system responsiveness and interactivity
with specific emphasis on the desktop, but configurable for any workload. The
patchset is mainly centred around the Multiple Queue Skiplist Scheduler,
MuQSS.
-ck1 patches:
These are patches designed to improve system responsiveness and interactivity
with specific emphasis on the desktop, but configurable for any workload. The
patchset is mainly centred around the Multiple Queue Skiplist Scheduler,
MuQSS.
-ck1 patches:
On Sat, Feb 18, 2017 at 06:52:25PM +0100, Borislav Petkov wrote:
> On Fri, Feb 17, 2017 at 06:48:13PM +0100, Boris Petkov wrote:
> > LGTM.
> >
> > Acked-by: me
>
> Well, it looks good but actually trying it is a different story. For
> example:
>
> $ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/
On Sat, Feb 18, 2017 at 06:52:25PM +0100, Borislav Petkov wrote:
> On Fri, Feb 17, 2017 at 06:48:13PM +0100, Boris Petkov wrote:
> > LGTM.
> >
> > Acked-by: me
>
> Well, it looks good but actually trying it is a different story. For
> example:
>
> $ ./perf stat -e amd_nb/event=0xe0,umask=0x1f/
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in this
case.
Add a missing call to 'pm_runtime_put()'.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for
The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
Dear Thierry,
I understand that your opinion is:
It is better to handle the error every time it is input to the
register, rather than error handling at once in the struct using
error. This not only makes the code easier to maintain, but also
reduces unnecessary computation.
So I modified the
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
Acked-by: Rob Herring
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 28
Dear Thierry,
I understand that your opinion is:
It is better to handle the error every time it is input to the
register, rather than error handling at once in the struct using
error. This not only makes the code easier to maintain, but also
reduces unnecessary computation.
So I modified the
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
Reviewed-by: Andrzej Hajda
---
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
* Ravi Bangoria wrote:
> All events from 'perf list', except SDT events, can be directly recorded
> with 'perf record'. But, the flow is little different for SDT events.
> Probe point for SDT event needs to be created using 'perf probe' before
> recording it
* Ravi Bangoria wrote:
> All events from 'perf list', except SDT events, can be directly recorded
> with 'perf record'. But, the flow is little different for SDT events.
> Probe point for SDT event needs to be created using 'perf probe' before
> recording it using 'perf record'.
>
> As
From: Jagan Teki
i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus
openframe display carriers" which are good solution for develop
user friendly graphic user interface.
General features:
CPU NXP i.MX6Q rev1.2 at 792 MHz
RAM 1GB, 32,
From: Jagan Teki
This patch add support for lvds backlight on i.CoreM6 QDL
variant boards.
Cc: Domenico Acri
Cc: Matteo Lisi
Cc: Michael Trimarchi
Cc: Shawn Guo
From: Jagan Teki
i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus
openframe display carriers" which are good solution for develop
user friendly graphic user interface.
General features:
CPU NXP i.MX6Q rev1.2 at 792 MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND
From: Jagan Teki
This patch add support for lvds backlight on i.CoreM6 QDL
variant boards.
Cc: Domenico Acri
Cc: Matteo Lisi
Cc: Michael Trimarchi
Cc: Shawn Guo
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/imx6qdl-icore.dtsi | 20
1 file changed, 20 insertions(+)
On Mon, 20 Feb 2017, Arushi Singhal wrote:
> Unnecessary parentheses should be avoided as reported by checkpatch.pl.
> Remove unnecessary parentheses, as reported by checkpatch as are nicer
> to read.For example:-
> It's often nicer to read if &(foo[0]) is converted to foo like:
>
On Mon, 20 Feb 2017, Arushi Singhal wrote:
> Unnecessary parentheses should be avoided as reported by checkpatch.pl.
> Remove unnecessary parentheses, as reported by checkpatch as are nicer
> to read.For example:-
> It's often nicer to read if &(foo[0]) is converted to foo like:
>
On 2017年02月20日 14:41, Christophe JAILLET wrote:
Le 20/02/2017 à 02:40, Mark yao a écrit :
On 2017年02月20日 00:59, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not
On 2017年02月20日 14:41, Christophe JAILLET wrote:
Le 20/02/2017 à 02:40, Mark yao a écrit :
On 2017年02月20日 00:59, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not
Unnecessary parentheses should be avoided as reported by checkpatch.pl.
Remove unnecessary parentheses, as reported by checkpatch as are nicer
to read.For example:-
It's often nicer to read if &(foo[0]) is converted to foo like:
memcpy(&(ap->bssid[0]), &(ap_info->bssid[0]), ETH_ALEN);
Unnecessary parentheses should be avoided as reported by checkpatch.pl.
Remove unnecessary parentheses, as reported by checkpatch as are nicer
to read.For example:-
It's often nicer to read if &(foo[0]) is converted to foo like:
memcpy(&(ap->bssid[0]), &(ap_info->bssid[0]), ETH_ALEN);
On Sun, Feb 19, 2017 at 01:12:50PM +, Jonathan Cameron wrote:
> On 16/02/17 10:02, Eva Rachel Retuya wrote:
> > Add SPI driver for initializing spi regmap for the adxl345 core driver.
> > The driver supports the same functionality as I2C namely the x, y, z and
> > scale readings.
> >
> >
On Sun, Feb 19, 2017 at 01:12:50PM +, Jonathan Cameron wrote:
> On 16/02/17 10:02, Eva Rachel Retuya wrote:
> > Add SPI driver for initializing spi regmap for the adxl345 core driver.
> > The driver supports the same functionality as I2C namely the x, y, z and
> > scale readings.
> >
> >
On Sun, Feb 19, 2017 at 01:11:29PM +, Jonathan Cameron wrote:
> On 16/02/17 10:02, Eva Rachel Retuya wrote:
> > Move I2C-specific code into its own file and rely on regmap to access
> > registers. The core code provides access to x, y, z and scale readings.
> >
> > Signed-off-by: Eva Rachel
Le 20/02/2017 à 02:40, Mark yao a écrit :
On 2017年02月20日 00:59, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in
this
case.
Fixes: 1a0f7ed3abe2
On Sun, Feb 19, 2017 at 01:11:29PM +, Jonathan Cameron wrote:
> On 16/02/17 10:02, Eva Rachel Retuya wrote:
> > Move I2C-specific code into its own file and rely on regmap to access
> > registers. The core code provides access to x, y, z and scale readings.
> >
> > Signed-off-by: Eva Rachel
Le 20/02/2017 à 02:40, Mark yao a écrit :
On 2017年02月20日 00:59, Christophe JAILLET wrote:
It is likely that both 'clk_disable_unprepare()' should be called if
'pm_runtime_get_sync()' fails.
Add a new label for that, because 'err_set_rate' is not meaningful in
this
case.
Fixes: 1a0f7ed3abe2
Hi Eric,
On Thursday 16 February 2017 04:55 PM, Eric W. Biederman wrote:
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE 8
+
+struct perf_ns_link_info {
+ charname[NS_NAME_SIZE];
+ __u64 dev;
+ __u64 ino;
+};
Hi Eric,
On Thursday 16 February 2017 04:55 PM, Eric W. Biederman wrote:
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE 8
+
+struct perf_ns_link_info {
+ charname[NS_NAME_SIZE];
+ __u64 dev;
+ __u64 ino;
+};
Hi Linus,
Everything in my pull-request has been in linux-next for three
weeks. There are overlappings with mfd & arm, but no problems
were reported by Stephen, so I assume the immutable branches
worked as expected.
-- Sebastian
The following changes since commit
Hi Linus,
Everything in my pull-request has been in linux-next for three
weeks. There are overlappings with mfd & arm, but no problems
were reported by Stephen, so I assume the immutable branches
worked as expected.
-- Sebastian
The following changes since commit
We met an issue for kdump: after kdump kernel boots up,
and there comes a broadcasted mce in first kernel, the
other cpus remaining in first kernel will enter the old
mce handler of first kernel, then timeout and panic due
to MCE synchronization, finally reset the kdump cpus.
This patch lets cpus
We met an issue for kdump: after kdump kernel boots up,
and there comes a broadcasted mce in first kernel, the
other cpus remaining in first kernel will enter the old
mce handler of first kernel, then timeout and panic due
to MCE synchronization, finally reset the kdump cpus.
This patch lets cpus
On 17/02/17 20:47, Dmitry Torokhov wrote:
> On Mon, Jan 30, 2017 at 01:27:29PM +0200, Oleksandr Andrushchenko wrote:
>> On 01/30/2017 01:23 PM, Juergen Gross wrote:
>>> On 27/01/17 17:10, Dmitry Torokhov wrote:
On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
>
On 17/02/17 20:47, Dmitry Torokhov wrote:
> On Mon, Jan 30, 2017 at 01:27:29PM +0200, Oleksandr Andrushchenko wrote:
>> On 01/30/2017 01:23 PM, Juergen Gross wrote:
>>> On 27/01/17 17:10, Dmitry Torokhov wrote:
On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
> On 27/01/17
Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
It keeps consistent with the WorkQueue and avoids some bugs which may be caused
by the dynamic assignment.
As we know, It is implemented by the patches as follows: 2532fc318d, f7c28833c2,
8f54969dc8, 8ad893faf2,
Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
It keeps consistent with the WorkQueue and avoids some bugs which may be caused
by the dynamic assignment.
As we know, It is implemented by the patches as follows: 2532fc318d, f7c28833c2,
8f54969dc8, 8ad893faf2,
Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
It keeps consistent with the WorkQueue and avoids some bugs which may be caused
by the dynamic assignment.
But, The ACPI table is unreliable and it is very risky that we use the entity
which isn't related to a
After we never do the last mapping of "cpuid <-> nodeid" at booting time. we
also no need to enable MADT APIs to return disabled apicid.
So, The patch work for reverting the commit 8ad893faf2:
"x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid"
Signed-off-by: Dou Liyang
Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
It keeps consistent with the WorkQueue and avoids some bugs which may be caused
by the dynamic assignment.
But, The ACPI table is unreliable and it is very risky that we use the entity
which isn't related to a
After we never do the last mapping of "cpuid <-> nodeid" at booting time. we
also no need to enable MADT APIs to return disabled apicid.
So, The patch work for reverting the commit 8ad893faf2:
"x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid"
Signed-off-by: Dou Liyang
---
Hello all,
Am 13.02.2017 um 22:31 schrieb Rob Herring:
On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher wrote:
Hello Rob,
Am 10.02.2017 um 16:51 schrieb Rob Herring:
On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:
From: Guan Ben
Hello all,
Am 13.02.2017 um 22:31 schrieb Rob Herring:
On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher wrote:
Hello Rob,
Am 10.02.2017 um 16:51 schrieb Rob Herring:
On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:
From: Guan Ben
Make the EN2 pin optional. This is
>> While booting next-20170217 on a POWER6 box, I ran into following
>> warning. This is a full system lpar. Previous next tree was good.
>> I will try a bisect tomorrow.
>
> Do you have CONFIG_DEBUG_SHIRQ=y ?
>
Yes. CONFIG_DEBUG_SHIRQ is enabled.
As suggested by you reverting following
>> While booting next-20170217 on a POWER6 box, I ran into following
>> warning. This is a full system lpar. Previous next tree was good.
>> I will try a bisect tomorrow.
>
> Do you have CONFIG_DEBUG_SHIRQ=y ?
>
Yes. CONFIG_DEBUG_SHIRQ is enabled.
As suggested by you reverting following
On Sun, Feb 19, 2017 at 12:52:48AM -0500, David Miller wrote:
> From: "Michael S. Tsirkin"
> Date: Sun, 19 Feb 2017 07:17:17 +0200
>
> > Dave, could you merge this before 4.10? If not - I can try.
>
> I just sent my last pull request to Linus, please merge it to
> him directly.
On Sun, Feb 19, 2017 at 12:52:48AM -0500, David Miller wrote:
> From: "Michael S. Tsirkin"
> Date: Sun, 19 Feb 2017 07:17:17 +0200
>
> > Dave, could you merge this before 4.10? If not - I can try.
>
> I just sent my last pull request to Linus, please merge it to
> him directly.
>
> Thanks.
I
On 17-02-17, 15:54, Kevin Hilman wrote:
> Viresh Kumar writes:
>
> > Some platforms have the capability to configure the performance state of
> > their Power Domains. The performance levels are represented by positive
> > integer values, a lower value represents lower
On 17-02-17, 15:54, Kevin Hilman wrote:
> Viresh Kumar writes:
>
> > Some platforms have the capability to configure the performance state of
> > their Power Domains. The performance levels are represented by positive
> > integer values, a lower value represents lower performance state.
> >
> >
Hi all,
Changes since 20170217:
The pci tree gained a conflict (probably) against Linus' tree.
The kspp tree gained a conflict against the net-next tree.
The tip tree gained a conflict against the net-next tree.
The target-bva tree gained conflicts against the target-updates tree.
Non-merge
Hi all,
Changes since 20170217:
The pci tree gained a conflict (probably) against Linus' tree.
The kspp tree gained a conflict against the net-next tree.
The tip tree gained a conflict against the net-next tree.
The target-bva tree gained conflicts against the target-updates tree.
Non-merge
(Really add Will this time ...)
On Mon, Feb 20, 2017 at 12:53:58PM +0800, Boqun Feng wrote:
> On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote:
> > On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> > > All the locking related cmpxchg's in the following functions are
> > >
(Really add Will this time ...)
On Mon, Feb 20, 2017 at 12:53:58PM +0800, Boqun Feng wrote:
> On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote:
> > On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> > > All the locking related cmpxchg's in the following functions are
> > >
On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote:
> On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> > All the locking related cmpxchg's in the following functions are
> > replaced with the _acquire variants:
> > - pv_queued_spin_steal_lock()
> > -
On Mon, Feb 20, 2017 at 05:20:52AM +0100, Andrea Parri wrote:
> On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> > All the locking related cmpxchg's in the following functions are
> > replaced with the _acquire variants:
> > - pv_queued_spin_steal_lock()
> > -
On 02/19/2017 03:52 PM, Alexandre Belloni wrote:
On 19/02/2017 at 08:57:35 -0800, Guenter Roeck wrote:
That means if the watchdog is running, the timeout would not be updated.
It should be updated no matter if it is running or not.
No, it is enabling the watchdog, then changing WDV and WDD
On 02/19/2017 03:52 PM, Alexandre Belloni wrote:
On 19/02/2017 at 08:57:35 -0800, Guenter Roeck wrote:
That means if the watchdog is running, the timeout would not be updated.
It should be updated no matter if it is running or not.
No, it is enabling the watchdog, then changing WDV and WDD
Pan Xinhui writes:
> 在 2017/2/17 14:05, Michael Ellerman 写道:
>> Pan Xinhui writes:
>>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>>> index 9c0e17c..f6e5c3d 100644
>>> --- a/arch/powerpc/xmon/xmon.c
>>> +++
Pan Xinhui writes:
> 在 2017/2/17 14:05, Michael Ellerman 写道:
>> Pan Xinhui writes:
>>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>>> index 9c0e17c..f6e5c3d 100644
>>> --- a/arch/powerpc/xmon/xmon.c
>>> +++ b/arch/powerpc/xmon/xmon.c
>>> @@ -76,6 +76,7 @@ static int
Hi Cory,
On Tue, 2016-12-06 at 16:02 +0100, Cédric Le Goater wrote:
> [ this is a resend bc of some mailing list issues]
>
> On 12/06/2016 03:57 AM, Andrew Jeffery wrote:
> > The registers for the bt-bmc device live under the Aspeed LPC
> > controller. Devicetree bindings have recently been
Hi Cory,
On Tue, 2016-12-06 at 16:02 +0100, Cédric Le Goater wrote:
> [ this is a resend bc of some mailing list issues]
>
> On 12/06/2016 03:57 AM, Andrew Jeffery wrote:
> > The registers for the bt-bmc device live under the Aspeed LPC
> > controller. Devicetree bindings have recently been
On Mon, 2017-02-20 at 15:40 +1100, Michael Ellerman wrote:
> Joe Perches writes:
>
> > To enable eventual removal of pr_warning
> >
> > This makes pr_warn use consistent for arch/powerpc
> >
> > Prior to this patch, there were 36 uses of pr_warning and
> > 217 uses of pr_warn
On Mon, 2017-02-20 at 15:40 +1100, Michael Ellerman wrote:
> Joe Perches writes:
>
> > To enable eventual removal of pr_warning
> >
> > This makes pr_warn use consistent for arch/powerpc
> >
> > Prior to this patch, there were 36 uses of pr_warning and
> > 217 uses of pr_warn in arch/powerpc
>
Joe Perches writes:
> To enable eventual removal of pr_warning
>
> This makes pr_warn use consistent for arch/powerpc
>
> Prior to this patch, there were 36 uses of pr_warning and
> 217 uses of pr_warn in arch/powerpc
>
> Signed-off-by: Joe Perches
Can I
Joe Perches writes:
> To enable eventual removal of pr_warning
>
> This makes pr_warn use consistent for arch/powerpc
>
> Prior to this patch, there were 36 uses of pr_warning and
> 217 uses of pr_warn in arch/powerpc
>
> Signed-off-by: Joe Perches
Can I take this via the powerpc tree, or do
James Bottomley writes:
> On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote:
>> I think I am missing something but I completely do not understand
>> that subthread that says use file marks and perform the work in the
>> vfs. The problem is that
James Bottomley writes:
> On Fri, 2017-02-17 at 14:57 +1300, Eric W. Biederman wrote:
>> I think I am missing something but I completely do not understand
>> that subthread that says use file marks and perform the work in the
>> vfs. The problem is that fundamentally we need multiple mappings
On Mon, Feb 20, 2017 at 1:04 PM, Zain Wang wrote:
> 在 2017/2/20 10:40, Tomasz Figa 写道:
>> On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote:
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>>
On Mon, Feb 20, 2017 at 1:04 PM, Zain Wang wrote:
> 在 2017/2/20 10:40, Tomasz Figa 写道:
>> On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote:
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>> index 303083a..5384aca 100644
On 19/02/17 02:43 PM, Dan Williams wrote:
> Is this race present for all file operations? I've only seen it with
> mmap() and late faults. So if these other drivers do not support mmap
> it's not clear they can trigger the failure.
I don't see how it's related to mmap only. I think there's a
On 19/02/17 02:43 PM, Dan Williams wrote:
> Is this race present for all file operations? I've only seen it with
> mmap() and late faults. So if these other drivers do not support mmap
> it's not clear they can trigger the failure.
I don't see how it's related to mmap only. I think there's a
On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> All the locking related cmpxchg's in the following functions are
> replaced with the _acquire variants:
> - pv_queued_spin_steal_lock()
> - trylock_clear_pending()
>
> This change should help performance on architectures that use
On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> All the locking related cmpxchg's in the following functions are
> replaced with the _acquire variants:
> - pv_queued_spin_steal_lock()
> - trylock_clear_pending()
>
> This change should help performance on architectures that use
Hi Peter,
On Thursday 16 February 2017 03:58 PM, Peter Zijlstra wrote:
On Wed, Feb 08, 2017 at 02:01:24PM +0530, Hari Bathini wrote:
With the advert of container technologies like docker, that depend
on namespaces for isolation, there is a need for tracing support for
namespaces. This patch
Hi Peter,
On Thursday 16 February 2017 03:58 PM, Peter Zijlstra wrote:
On Wed, Feb 08, 2017 at 02:01:24PM +0530, Hari Bathini wrote:
With the advert of container technologies like docker, that depend
on namespaces for isolation, there is a need for tracing support for
namespaces. This patch
Alexey Gladkov writes:
> The pidfs filesystem contains a subset of the /proc file system which
> contains only information about the processes.
My summary of your motivation.
It hurts when I create a container with a processes with uid 0 inside of
it. This generates
Alexey Gladkov writes:
> The pidfs filesystem contains a subset of the /proc file system which
> contains only information about the processes.
My summary of your motivation.
It hurts when I create a container with a processes with uid 0 inside of
it. This generates lots of hacks to attempt
On 19 February 2017 at 19:29, Viresh Kumar wrote:
> On 17-02-17, 12:27, Markus Mayer wrote:
>> From: Markus Mayer
>>
>> Add maintainer information for bmips-cpufreq.c.
>>
>> Signed-off-by: Markus Mayer
>> Acked-by: Florian
On 19 February 2017 at 19:29, Viresh Kumar wrote:
> On 17-02-17, 12:27, Markus Mayer wrote:
>> From: Markus Mayer
>>
>> Add maintainer information for bmips-cpufreq.c.
>>
>> Signed-off-by: Markus Mayer
>> Acked-by: Florian Fainelli
>> ---
>>
>> This is based on PM's linux-next from today
Hi Tomasz,
在 2017/2/20 10:40, Tomasz Figa 写道:
Hi Zain,
On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote:
The analogix_dp_transfer() will return -EBUSY if num_transferred is zero.
But sometimes we will send a bare address packet to start the transaction,
like
Hi Tomasz,
在 2017/2/20 10:40, Tomasz Figa 写道:
Hi Zain,
On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote:
The analogix_dp_transfer() will return -EBUSY if num_transferred is zero.
But sometimes we will send a bare address packet to start the transaction,
like drm_dp_i2c_xfer() show:
We set queues before reset which will cause a crash[1]. This is
because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
number to do the correct detection. So fix this by
- passing xdp queue pairs and current queue pairs to virtnet_reset()
- change vi->xdp_qp after reset but before
We set queues before reset which will cause a crash[1]. This is
because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
number to do the correct detection. So fix this by
- passing xdp queue pairs and current queue pairs to virtnet_reset()
- change vi->xdp_qp after reset but before
1 - 100 of 630 matches
Mail list logo