Hi Doug,
Thanks for the review!
I noticed both the quirks just after sending it out :(, will fix them.
On 2018-10-30 00:07, Doug Anderson wrote:
Hi,
On Fri, Oct 26, 2018 at 5:28 AM Sibi Sankar
wrote:
Add reserve-memory nodes for mpss and mba required for
remoteproc mss pil.
Hi Doug,
Thanks for the review!
I noticed both the quirks just after sending it out :(, will fix them.
On 2018-10-30 00:07, Doug Anderson wrote:
Hi,
On Fri, Oct 26, 2018 at 5:28 AM Sibi Sankar
wrote:
Add reserve-memory nodes for mpss and mba required for
remoteproc mss pil.
On 2018/10/30 18:09, Peter Zijlstra wrote:
On Tue, Oct 30, 2018 at 06:39:24PM +0900, Masahiro Yamada wrote:
Hi,
On Tue, Oct 30, 2018 at 3:57 PM Zhenzhong Duan
wrote:
Since retpoline capable compilers are widely available, make
CONFIG_RETPOLINE hard depend on it.
Change KBUILD to use
On 2018/10/30 18:09, Peter Zijlstra wrote:
On Tue, Oct 30, 2018 at 06:39:24PM +0900, Masahiro Yamada wrote:
Hi,
On Tue, Oct 30, 2018 at 3:57 PM Zhenzhong Duan
wrote:
Since retpoline capable compilers are widely available, make
CONFIG_RETPOLINE hard depend on it.
Change KBUILD to use
This goes back to by-hand parsing of the proc mmap file, and removes
the timeout.
In my measurements this makes the parsing about twice as fast.
Profiling thread synthesizing shows that most of the time is spent in
the sscanf() call.
Processing samples is critical for perf top and perf record
This goes back to by-hand parsing of the proc mmap file, and removes
the timeout.
In my measurements this makes the parsing about twice as fast.
Profiling thread synthesizing shows that most of the time is spent in
the sscanf() call.
Processing samples is critical for perf top and perf record
Masahiro Yamada writes:
> Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
> bumped the minimum GCC version to 4.6 for all architectures.
>
> The workaround code in fs/reiserfs/Makefile is obsolete now.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> fs/reiserfs/Makefile | 9
Masahiro Yamada writes:
> Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
> bumped the minimum GCC version to 4.6 for all architectures.
>
> The workaround code in fs/reiserfs/Makefile is obsolete now.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> fs/reiserfs/Makefile | 9
On 10/30/18 6:07 PM, Zhang Rui wrote:
> Hi, Randy,
>
> On 五, 2018-10-26 at 20:35 -0700, Randy Dunlap wrote:
>> On 10/26/18 2:14 AM, Rafael J. Wysocki wrote:
>>>
>>> On Monday, October 22, 2018 8:37:25 PM CEST Randy Dunlap wrote:
On 8/16/18 2:33 PM, Randy Dunlap wrote:
>
>
On 10/30/18 6:07 PM, Zhang Rui wrote:
> Hi, Randy,
>
> On 五, 2018-10-26 at 20:35 -0700, Randy Dunlap wrote:
>> On 10/26/18 2:14 AM, Rafael J. Wysocki wrote:
>>>
>>> On Monday, October 22, 2018 8:37:25 PM CEST Randy Dunlap wrote:
On 8/16/18 2:33 PM, Randy Dunlap wrote:
>
>
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
mount API series from David Howells. Last cycle's objections
had been of the "I'd do it differently" variety and with no such
differently done variants having ever materialized over several
cycles...
Conflicts: two trivial ones in
drivers/infiniband/Kconfig (removal of select
mount API series from David Howells. Last cycle's objections
had been of the "I'd do it differently" variety and with no such
differently done variants having ever materialized over several
cycles...
Conflicts: two trivial ones in
drivers/infiniband/Kconfig (removal of select
If events are coming in at a rate such that the event processing
thread can barely keep up, our initial run of the event ring will
almost never terminate and this delays the starting of the display
thread.
The screen basically stays black until the event thread can get out of
it's endless loop.
If events are coming in at a rate such that the event processing
thread can barely keep up, our initial run of the event ring will
almost never terminate and this delays the starting of the display
thread.
The screen basically stays black until the event thread can get out of
it's endless loop.
When synthesizing FORK events, we are trying to create thread objects
for the already running tasks on the machine.
Normally, for a kernel FORK event, we want to clone the parent's maps
because that is what the kernel just did.
But when synthesizing, this should not be done. If we do, we end
When synthesizing FORK events, we are trying to create thread objects
for the already running tasks on the machine.
Normally, for a kernel FORK event, we want to clone the parent's maps
because that is what the kernel just did.
But when synthesizing, this should not be done. If we do, we end
On Tue, Oct 30, 2018 at 5:08 AM Linus Walleij wrote:
>
> On Wed, Oct 17, 2018 at 11:30 PM Kun Yi wrote:
>
> > Indicate that the pins are both controlled by the pinctrl driver and the
> > generic GPIO driver, thus GPIO driver should read the register value
> > before updating, instead of using
On Tue, Oct 30, 2018 at 5:08 AM Linus Walleij wrote:
>
> On Wed, Oct 17, 2018 at 11:30 PM Kun Yi wrote:
>
> > Indicate that the pins are both controlled by the pinctrl driver and the
> > generic GPIO driver, thus GPIO driver should read the register value
> > before updating, instead of using
So when a cpu is overpowered processing samples, most of the time is
spent in the histogram code.
It seems we initialize a ~262 byte structure on the stack to do every
histogram entry lookup.
This is a side effect of how the sorting code is shared with the code
that does lookups and insertions
So when a cpu is overpowered processing samples, most of the time is
spent in the histogram code.
It seems we initialize a ~262 byte structure on the stack to do every
histogram entry lookup.
This is a side effect of how the sorting code is shared with the code
that does lookups and insertions
Christian Brauner writes:
> On Tue, Oct 30, 2018 at 12:12 PM Daniel Colascione wrote:
>>
>> On Tue, Oct 30, 2018 at 11:04 AM, Christian Brauner
>> wrote:
>> > On Tue, Oct 30, 2018 at 11:48 AM Daniel Colascione
>> > wrote:
>> >>
>> >> Why not?
>> >>
>> >> Does your proposed API allow for a
Christian Brauner writes:
> On Tue, Oct 30, 2018 at 12:12 PM Daniel Colascione wrote:
>>
>> On Tue, Oct 30, 2018 at 11:04 AM, Christian Brauner
>> wrote:
>> > On Tue, Oct 30, 2018 at 11:48 AM Daniel Colascione
>> > wrote:
>> >>
>> >> Why not?
>> >>
>> >> Does your proposed API allow for a
On 2018/10/30 16:32, Peter Zijlstra wrote:
On Mon, Oct 29, 2018 at 11:55:04PM -0700, Zhenzhong Duan wrote:
Since retpoline capable compilers are widely available, make
CONFIG_RETPOLINE hard depend on it.
Change KBUILD to use CONFIG_RETPOLINE_SUPPORT to avoid conflict with
CONFIG_RETPOLINE
On 2018/10/30 16:32, Peter Zijlstra wrote:
On Mon, Oct 29, 2018 at 11:55:04PM -0700, Zhenzhong Duan wrote:
Since retpoline capable compilers are widely available, make
CONFIG_RETPOLINE hard depend on it.
Change KBUILD to use CONFIG_RETPOLINE_SUPPORT to avoid conflict with
CONFIG_RETPOLINE
Ls208xa has several thermal sensors. Add all the sensor id to dts
to enable them.
To make the dts cleaner, re-organize the nodes to split out the
common part so that it can be shared with other SoCs.
Signed-off-by: Yuantian Tang
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |8 +-
Ls208xa has several thermal sensors. Add all the sensor id to dts
to enable them.
To make the dts cleaner, re-organize the nodes to split out the
common part so that it can be shared with other SoCs.
Signed-off-by: Yuantian Tang
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |8 +-
Aleksa Sarai writes:
> On 2018-10-29, Daniel Colascione wrote:
>> Add a simple proc-based kill interface. To use /proc/pid/kill, just
>> write the signal number in base-10 ASCII to the kill file of the
>> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>>
>> Semantically,
Aleksa Sarai writes:
> On 2018-10-29, Daniel Colascione wrote:
>> Add a simple proc-based kill interface. To use /proc/pid/kill, just
>> write the signal number in base-10 ASCII to the kill file of the
>> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>>
>> Semantically,
Daniel Colascione writes:
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works like kill(2), except that the
>
Daniel Colascione writes:
> Add a simple proc-based kill interface. To use /proc/pid/kill, just
> write the signal number in base-10 ASCII to the kill file of the
> process to be killed: for example, 'echo 9 > /proc/$$/kill'.
>
> Semantically, /proc/pid/kill works like kill(2), except that the
>
Hi Matias,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 73569e11032fc5a9b314b6351632cfca7793afd5 lightnvm: remove dependencies
on BLK_DEV_NVME and PCI
date: 3
Hi Matias,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 73569e11032fc5a9b314b6351632cfca7793afd5 lightnvm: remove dependencies
on BLK_DEV_NVME and PCI
date: 3
Benjamin Gordon writes:
> Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
> in its effective capability set, but the current check looks in the root
> namespace instead of the process' user namespace. Since a process is
> allowed to do other activities controlled by
Benjamin Gordon writes:
> Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
> in its effective capability set, but the current check looks in the root
> namespace instead of the process' user namespace. Since a process is
> allowed to do other activities controlled by
On 30-10-18, 14:35, Daniel Lezcano wrote:
> I'm wondering if having a statically per_cpu variable, even if it is not
> free at the end, isn't worth regarding the twisted code we end up with
> an allocation.
Maybe yeah.
--
viresh
On 30-10-18, 14:35, Daniel Lezcano wrote:
> I'm wondering if having a statically per_cpu variable, even if it is not
> free at the end, isn't worth regarding the twisted code we end up with
> an allocation.
Maybe yeah.
--
viresh
On Tue, Oct 30, 2018 at 7:56 PM, Aleksa Sarai wrote:
> On 2018-10-31, Christian Brauner wrote:
>> > I think Aleksa's larger point is that it's useful to treat processes
>> > as other file-descriptor-named, poll-able, wait-able resources.
>> > Consistency is important. A process is just another
On Tue, Oct 30, 2018 at 7:56 PM, Aleksa Sarai wrote:
> On 2018-10-31, Christian Brauner wrote:
>> > I think Aleksa's larger point is that it's useful to treat processes
>> > as other file-descriptor-named, poll-able, wait-able resources.
>> > Consistency is important. A process is just another
On Tue, Oct 30, 2018 at 8:57 PM, Peng15 Wang 王鹏 wrote:
>
>>From: Joel Fernandes
>>Sent: Wednesday, October 31, 2018 6:16
>>To: Kees Cook
>>Cc: Peng15 Wang 王鹏; Anton Vorontsov; Colin Cross; Tony Luck; LKML;
>>vipwangerx...@gmail.com
>>Subject: Re: [PATCH v4] pstore: Avoid duplicate call of
On Tue, Oct 30, 2018 at 8:57 PM, Peng15 Wang 王鹏 wrote:
>
>>From: Joel Fernandes
>>Sent: Wednesday, October 31, 2018 6:16
>>To: Kees Cook
>>Cc: Peng15 Wang 王鹏; Anton Vorontsov; Colin Cross; Tony Luck; LKML;
>>vipwangerx...@gmail.com
>>Subject: Re: [PATCH v4] pstore: Avoid duplicate call of
>From: Joel Fernandes
>Sent: Wednesday, October 31, 2018 6:16
>To: Kees Cook
>Cc: Peng15 Wang 王鹏; Anton Vorontsov; Colin Cross; Tony Luck; LKML;
>vipwangerx...@gmail.com
>Subject: Re: [PATCH v4] pstore: Avoid duplicate call of persistent_ram_zap()
>
>On Tue, Oct 30, 2018 at 02:52:43PM -0700,
>From: Joel Fernandes
>Sent: Wednesday, October 31, 2018 6:16
>To: Kees Cook
>Cc: Peng15 Wang 王鹏; Anton Vorontsov; Colin Cross; Tony Luck; LKML;
>vipwangerx...@gmail.com
>Subject: Re: [PATCH v4] pstore: Avoid duplicate call of persistent_ram_zap()
>
>On Tue, Oct 30, 2018 at 02:52:43PM -0700,
Hi all,
Please do not add any v4.21/v5.1 code to your linux-next included trees
until after the merge window closes.
Changes since 20181030:
My fixes tree contains this:
"drivers: net: include linux/ip.h for iphdr"
The xfs tree gained a conflict against Linus' tree.
The vfs t
Hi all,
Please do not add any v4.21/v5.1 code to your linux-next included trees
until after the merge window closes.
Changes since 20181030:
My fixes tree contains this:
"drivers: net: include linux/ip.h for iphdr"
The xfs tree gained a conflict against Linus' tree.
The vfs t
On 10/31/2018 04:30 AM, Andreas Dilger wrote:
> Could you please explain your statement below that on-stack
> initialization does not zero unspecified fields? According
> to documents I found, for example:
>
> https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
>
> they *are* initialized
On 10/31/2018 04:30 AM, Andreas Dilger wrote:
> Could you please explain your statement below that on-stack
> initialization does not zero unspecified fields? According
> to documents I found, for example:
>
> https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
>
> they *are* initialized
G'day,
Success, see below.
On Tue, Oct 30, 2018 at 08:40:38PM +0100, Lubomir Rintel wrote:
> Hello Pavel,
>
> On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
> >
G'day,
Success, see below.
On Tue, Oct 30, 2018 at 08:40:38PM +0100, Lubomir Rintel wrote:
> Hello Pavel,
>
> On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > > >
> >
Hi Peter,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 7aa54be2976550f17c11a1c3e3630002dea39303 locking/qspinlock, x86:
Provide liveness guarantee
date: 2 weeks
Hi Peter,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 7aa54be2976550f17c11a1c3e3630002dea39303 locking/qspinlock, x86:
Provide liveness guarantee
date: 2 weeks
On 10/30/18 4:09 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-10-30-16-08 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
On 10/30/18 4:09 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-10-30-16-08 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
On Tue, Oct 30, 2018 at 08:00:03AM -0700, syzbot wrote:
> syzbot found the following crash on:
>
> HEAD commit:4b42745211af Merge tag 'armsoc-soc' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1187d06d40
> kernel config:
On 30/10/18 6:26 pm, Boris Brezillon wrote:
> On Mon, 29 Oct 2018 23:15:42 +
> "Grandbois, Brett" wrote:
>
>> On 28/10/18 1:39 am, Boris Brezillon wrote:
>>> Hi Brett,
>>>
>>> On Tue, 16 Oct 2018 00:57:41 +
>>> "Grandbois, Brett" wrote:
>>>
Add support to expose the SPI boot
On Tue, Oct 30, 2018 at 08:00:03AM -0700, syzbot wrote:
> syzbot found the following crash on:
>
> HEAD commit:4b42745211af Merge tag 'armsoc-soc' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1187d06d40
> kernel config:
On 30/10/18 6:26 pm, Boris Brezillon wrote:
> On Mon, 29 Oct 2018 23:15:42 +
> "Grandbois, Brett" wrote:
>
>> On 28/10/18 1:39 am, Boris Brezillon wrote:
>>> Hi Brett,
>>>
>>> On Tue, 16 Oct 2018 00:57:41 +
>>> "Grandbois, Brett" wrote:
>>>
Add support to expose the SPI boot
Perf report has supported the displaying of LBR stats
(such as cycles, predicted%) in callchain entry.
For example,
perf report --branch-history --stdio
--1.01%--intel_idle mwait.h:29
intel_idle cpufeature.h:164 (cycles:5)
intel_idle cpufeature.h:164 (predicted:76.4%)
Perf report has supported the displaying of LBR stats
(such as cycles, predicted%) in callchain entry.
For example,
perf report --branch-history --stdio
--1.01%--intel_idle mwait.h:29
intel_idle cpufeature.h:164 (cycles:5)
intel_idle cpufeature.h:164 (predicted:76.4%)
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> From: Vasily Khoruzhick
>
> Pinebook has ACIN connector and 1 mAh battery.
>
> Signed-off-by: Vasily Khoruzhick
You should have your own SoB following the author's when you resend other
people's patches. Otherwise,
Reviewed-by:
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> From: Vasily Khoruzhick
>
> Pinebook has ACIN connector and 1 mAh battery.
>
> Signed-off-by: Vasily Khoruzhick
You should have your own SoB following the author's when you resend other
people's patches. Otherwise,
Reviewed-by:
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> AXP803 ACIN pins are routed from SOM to the DC jack on the baseboard.
> AXP803 charger pins BATSENSE, LOADSENSE, N_BATDRV, LX_CHG, VIN_CHG
> and IPSOUT are connected via PMOS driver to SOM VBAT pins. VBAT and
> AXP803 TS pins are routed to
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> AXP803 ACIN pins are routed from SOM to the DC jack on the baseboard.
> AXP803 charger pins BATSENSE, LOADSENSE, N_BATDRV, LX_CHG, VIN_CHG
> and IPSOUT are connected via PMOS driver to SOM VBAT pins. VBAT and
> AXP803 TS pins are routed to
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> Parts of the AXP803 are compatible with their counterparts on the AXP813.
> Add DT nodes ADC, GPIO, AC and battery power supplies.
>
> Signed-off-by: Oskari Lemmela
> Reviewed-by: Quentin Schulz
> Tested-by: Vasily Khoruzhick
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> Parts of the AXP803 are compatible with their counterparts on the AXP813.
> Add DT nodes ADC, GPIO, AC and battery power supplies.
>
> Signed-off-by: Oskari Lemmela
> Reviewed-by: Quentin Schulz
> Tested-by: Vasily Khoruzhick
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> The AXP803 GPIO is compatible with AXP813 GPIO, but add
> specific compatible for it.
>
> Signed-off-by: Oskari Lemmela
> ---
> Documentation/devicetree/bindings/gpio/gpio-axp209.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> The AXP803 GPIO is compatible with AXP813 GPIO, but add
> specific compatible for it.
>
> Signed-off-by: Oskari Lemmela
> ---
> Documentation/devicetree/bindings/gpio/gpio-axp209.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
On 2018-10-31, Christian Brauner wrote:
> > I think Aleksa's larger point is that it's useful to treat processes
> > as other file-descriptor-named, poll-able, wait-able resources.
> > Consistency is important. A process is just another system resource,
> > and like any other system resource, you
On 2018-10-31, Christian Brauner wrote:
> > I think Aleksa's larger point is that it's useful to treat processes
> > as other file-descriptor-named, poll-able, wait-able resources.
> > Consistency is important. A process is just another system resource,
> > and like any other system resource, you
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> AXP813 and AXP803 PMICs can control input current and minimum voltage.
>
> Both of these values are configurable.
>
> Signed-off-by: Oskari Lemmela
> Reviewed-by: Quentin Schulz
Reviewed-by: Chen-Yu Tsai
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> AXP813 and AXP803 PMICs can control input current and minimum voltage.
>
> Both of these values are configurable.
>
> Signed-off-by: Oskari Lemmela
> Reviewed-by: Quentin Schulz
Reviewed-by: Chen-Yu Tsai
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> The AXP803 power supplies are compatible with AXP813, but
> add specific compatibles for them.
>
> Signed-off-by: Oskari Lemmela
> ---
> .../devicetree/bindings/power/supply/axp20x_ac_power.txt | 1 +
>
On Wed, Oct 24, 2018 at 2:54 AM Oskari Lemmela wrote:
>
> The AXP803 power supplies are compatible with AXP813, but
> add specific compatibles for them.
>
> Signed-off-by: Oskari Lemmela
> ---
> .../devicetree/bindings/power/supply/axp20x_ac_power.txt | 1 +
>
On Fri, Oct 26, 2018 at 3:08 AM Sebastian Reichel
wrote:
>
> Hi,
>
> Patches 1, 2 & 9 look good to me and do not seem to have any
> dependencies. I plan to merge them after the merge window
> for 4.20 closes.
Patches 2, 3 & 4 aren't needed. They aren't in the correct format
for model-specific +
Hi:
>-Original Message-
>From: Alan Stern [mailto:st...@rowland.harvard.edu]
>Sent: Tuesday, October 30, 2018 10:08 PM
>To: Zengtao (B)
>Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com;
>gre...@linuxfoundation.org; linux-s...@vger.kernel.org;
>linux-kernel@vger.kernel.org;
On Fri, Oct 26, 2018 at 3:08 AM Sebastian Reichel
wrote:
>
> Hi,
>
> Patches 1, 2 & 9 look good to me and do not seem to have any
> dependencies. I plan to merge them after the merge window
> for 4.20 closes.
Patches 2, 3 & 4 aren't needed. They aren't in the correct format
for model-specific +
Hi:
>-Original Message-
>From: Alan Stern [mailto:st...@rowland.harvard.edu]
>Sent: Tuesday, October 30, 2018 10:08 PM
>To: Zengtao (B)
>Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com;
>gre...@linuxfoundation.org; linux-s...@vger.kernel.org;
>linux-kernel@vger.kernel.org;
On Mon, Oct 29, 2018 at 9:10 PM Quentin Schulz
wrote:
>
> Hi Jonathan,
>
> On Sun, Oct 28, 2018 at 03:40:11PM +, Jonathan Cameron wrote:
> > On Wed, 24 Oct 2018 08:56:33 -0500
> > Rob Herring wrote:
> >
> > > On Tue, 23 Oct 2018 21:53:23 +0300, Oskari Lemmela wrote:
> > > > The AXP803 ADC is
On Mon, Oct 29, 2018 at 9:10 PM Quentin Schulz
wrote:
>
> Hi Jonathan,
>
> On Sun, Oct 28, 2018 at 03:40:11PM +, Jonathan Cameron wrote:
> > On Wed, 24 Oct 2018 08:56:33 -0500
> > Rob Herring wrote:
> >
> > > On Tue, 23 Oct 2018 21:53:23 +0300, Oskari Lemmela wrote:
> > > > The AXP803 ADC is
After syncing with Hyper-V team, we have got answers as below.
On 18-10-24 16:53:00, Michael Kelley wrote:
> From: Yi Sun Sent: Friday, October 19, 2018 6:14
> AM
> >
> > The HvNotifyLongSpinWait hypercall (HVCALL_NOTIFY_LONG_SPIN_WAIT)
> > is used by a guest OS to notify the hypervisor that
After syncing with Hyper-V team, we have got answers as below.
On 18-10-24 16:53:00, Michael Kelley wrote:
> From: Yi Sun Sent: Friday, October 19, 2018 6:14
> AM
> >
> > The HvNotifyLongSpinWait hypercall (HVCALL_NOTIFY_LONG_SPIN_WAIT)
> > is used by a guest OS to notify the hypervisor that
On Wed, Oct 31, 2018 at 12:42 AM, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 09:49:08AM +1100, Aleksa Sarai wrote:
>> On 2018-10-30, Joel Fernandes wrote:
>> > > > [...]
>> > > > > > > (Unfortunately
>> > > > > > > there are lots of things that make it a bit difficult to use
>> > > > > > >
On Wed, Oct 31, 2018 at 12:42 AM, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 09:49:08AM +1100, Aleksa Sarai wrote:
>> On 2018-10-30, Joel Fernandes wrote:
>> > > > [...]
>> > > > > > > (Unfortunately
>> > > > > > > there are lots of things that make it a bit difficult to use
>> > > > > > >
On Wed, Oct 31, 2018 at 12:57 AM, Joel Fernandes wrote:
> On Tue, Oct 30, 2018 at 11:10:47PM +, Daniel Colascione wrote:
>> On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes
>> wrote:
>> > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
>> >> On 2018-10-30, Joel Fernandes
On 18-10-23 17:33:28, Yi Sun wrote:
> On 18-10-23 10:51:27, Peter Zijlstra wrote:
> > On Tue, Oct 23, 2018 at 10:57:40AM +0800, Yi Sun wrote:
> > > On 18-10-22 19:15:16, Peter Zijlstra wrote:
> >
> > > > > +#if defined(CONFIG_X86_64) &&
> > > > > defined(CONFIG_PARAVIRT_SPINLOCKS) &&
On Wed, Oct 31, 2018 at 12:57 AM, Joel Fernandes wrote:
> On Tue, Oct 30, 2018 at 11:10:47PM +, Daniel Colascione wrote:
>> On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes
>> wrote:
>> > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
>> >> On 2018-10-30, Joel Fernandes
On 18-10-23 17:33:28, Yi Sun wrote:
> On 18-10-23 10:51:27, Peter Zijlstra wrote:
> > On Tue, Oct 23, 2018 at 10:57:40AM +0800, Yi Sun wrote:
> > > On 18-10-22 19:15:16, Peter Zijlstra wrote:
> >
> > > > > +#if defined(CONFIG_X86_64) &&
> > > > > defined(CONFIG_PARAVIRT_SPINLOCKS) &&
Hi Arnd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 21924765862a0871908a35cb0e53e2e1c169b888 SUNRPC: use cmpxchg64() in
gss_seq_send64_fetch_and_inc()
date: 4
Hi Arnd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 21924765862a0871908a35cb0e53e2e1c169b888 SUNRPC: use cmpxchg64() in
gss_seq_send64_fetch_and_inc()
date: 4
On Tue, Oct 30, 2018 at 5:29 PM, Tycho Andersen wrote:
> On Tue, Oct 30, 2018 at 03:34:54PM -0700, Kees Cook wrote:
>> On Tue, Oct 30, 2018 at 3:32 PM, Tycho Andersen wrote:
>> > On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
>> >> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen
On Tue, Oct 30, 2018 at 5:29 PM, Tycho Andersen wrote:
> On Tue, Oct 30, 2018 at 03:34:54PM -0700, Kees Cook wrote:
>> On Tue, Oct 30, 2018 at 3:32 PM, Tycho Andersen wrote:
>> > On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
>> >> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen
Hi, Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
to receive the latest Thermal management updates for v4.20-rc1 with
top-most commit c2b59d279dbbac750958f6a1bc4841e431d934e3:
thermal: core: using power_efficient_wq for thermal worker (2018-10-
Hi, Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
to receive the latest Thermal management updates for v4.20-rc1 with
top-most commit c2b59d279dbbac750958f6a1bc4841e431d934e3:
thermal: core: using power_efficient_wq for thermal worker (2018-10-
Hi Rob,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree
dtb build rules
date: 4 weeks ago
On Wed, Oct 31, 2018 at 11:52:47AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> [I don't understand why all this new work turned up in the xfs tree
> during the merge window ...]
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/read_write.c
>
> between commits:
>
>
Hi Rob,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 kbuild: consolidate Devicetree
dtb build rules
date: 4 weeks ago
On Wed, Oct 31, 2018 at 11:52:47AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> [I don't understand why all this new work turned up in the xfs tree
> during the merge window ...]
>
> Today's linux-next merge of the vfs tree got a conflict in:
>
> fs/read_write.c
>
> between commits:
>
>
Hi Paul,
On Tue, Oct 30, 2018 at 04:43:36PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote:
> > Hi Paul,
> >
> > On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> > > As per this thread [1], it seems this smp_mb isn't
Hi Paul,
On Tue, Oct 30, 2018 at 04:43:36PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote:
> > Hi Paul,
> >
> > On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> > > As per this thread [1], it seems this smp_mb isn't
1 - 100 of 1220 matches
Mail list logo
