On 1/7/19 11:24 AM, Pavel Machek wrote:
> On Mon 2019-01-07 11:06:27, Frank Rowand wrote:
>>
>> + Frank
>>
>> On 1/7/19 10:37 AM, Pavel Machek wrote:
>>> Is it "Device Tree" or "device tree"?
>>>
>>> pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
>>> 235
>>> pavel@duo:/da
On 2019-01-08 05:47, Kees Cook wrote:
> On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong
> wrote:
>>
>> Why should we need pstore_block?
>> 1. Most embedded intelligent equipment have no persistent ram, which
>> increases costs. We perfer to cheaper solutions, like block devices.
>> In fast, there is a
On Mon, Jan 07, 2019 at 05:41:39PM -0500, Waiman Long wrote:
> On 01/07/2019 05:32 PM, Dave Chinner wrote:
> > On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> >> As newer systems have more and more IRQs and CPUs available in their
> >> system, the performance of reading /proc/stat fr
On 1/7/19 10:45 AM, Rob Herring wrote:
> On Mon, Jan 7, 2019 at 12:37 PM Pavel Machek wrote:
>>
>> Is it "Device Tree" or "device tree"?
>>
>> pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
>> 235
>> pavel@duo:/data/l/k/Documentation$ grep -r "device tree" | wc -l
>> 595
>>
On Mon, Jan 07, 2019 at 05:41:28PM -0500, Daniel Colascione wrote:
> There should be a general-purpose way for /proc file readers to tell
> the kernel which bits of information interest them on a particular read
> syscall sequence or particular open(2) or something.
This opens a pandora box full o
On Mon, 7 Jan 2019 15:16:22 -0800
Guenter Roeck wrote:
> > Applied, thanks.
> >
> Ok, I'll drop the patch from hwmon.
Oops, sorry, I didn't realize you'd picked that up. Would you prefer that
I stood back and let you handle Documentation/hwmon in the future?
Thanks,
jon
On Mon, Jan 07, 2019 at 03:40:49PM -0700, Jonathan Corbet wrote:
> On Fri, 4 Jan 2019 22:27:22 +0800
> Chengguang Xu wrote:
>
> > Just fix a typo in Documentation/hwmon/f71882fg.
> >
> > Signed-off-by: Chengguang Xu
> > ---
>
> Applied, thanks.
>
Ok, I'll drop the patch from hwmon.
Guente
On Mon, Jan 7, 2019 at 5:32 PM Dave Chinner wrote:
>
> On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> > As newer systems have more and more IRQs and CPUs available in their
> > system, the performance of reading /proc/stat frequently is getting
> > worse and worse.
>
> Because the
On 01/07/2019 05:32 PM, Dave Chinner wrote:
> On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
>> As newer systems have more and more IRQs and CPUs available in their
>> system, the performance of reading /proc/stat frequently is getting
>> worse and worse.
> Because the "roll-your-own"
On Fri, 4 Jan 2019 22:27:22 +0800
Chengguang Xu wrote:
> Just fix a typo in Documentation/hwmon/f71882fg.
>
> Signed-off-by: Chengguang Xu
> ---
Applied, thanks.
jon
On Sun, 23 Dec 2018 02:01:02 +0100
Federico Vaga wrote:
> It translats the document process/submitting-patches.rst.
>
> Signed-off-by: Federico Vaga
> ---
> .../it_IT/process/submitting-patches.rst | 862 +-
> 1 file changed, 858 insertions(+), 4 deletions(-)
Now applied,
On Mon, 7 Jan 2019 10:20:19 -0800
Bart Van Assche wrote:
> In emacs 23.1 support for directory-local variables was added (see also
> https://lists.gnu.org/archive/html/info-gnu-emacs/2009-07/msg0.html).
> Simplify the settings in coding-style.rst by using that feature.
> Additionally, do not
On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> As newer systems have more and more IRQs and CPUs available in their
> system, the performance of reading /proc/stat frequently is getting
> worse and worse.
Because the "roll-your-own" per-cpu counter implementaiton has been
optimised
On Mon, 07 Jan 2019 15:05:37 +1100
NeilBrown wrote:
> I probably did, but I didn't notice them.
> I just ran "make htmldocs" and there are pages and pages of warnings.
> When I look closely they do include these ones. At the time I was more
> focused on getting the output to look right.
The war
Hello Claudiu,
On Mon, Jan 07, 2019 at 09:30:55AM +, claudiu.bez...@microchip.com wrote:
> On 05.01.2019 23:05, Uwe Kleine-König wrote:
> > On Thu, Jan 03, 2019 at 01:29:44PM +, claudiu.bez...@microchip.com
> > wrote:
> >> From: Claudiu Beznea
> >>
> >> Add basic PWM modes: normal and co
On Mon, 07 Jan 2019 07:30:29 -0800 (PST)
David Miller wrote:
> Jon, do you want to integrate these? I'm fine with that and I don't
> anticiapte
> any serious conflicts.
I'll do that shortly, thanks.
jon
On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong
wrote:
>
> Why should we need pstore_block?
> 1. Most embedded intelligent equipment have no persistent ram, which
> increases costs. We perfer to cheaper solutions, like block devices.
> In fast, there is already a sample for block device logger in driv
This commit adds PECI adapter driver implementation for Aspeed
AST24xx/AST25xx SoCs.
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: Andy Shevchenko
Cc: Greg Kroah-Hartman
Cc: Robin Murphy
Cc: Ryan Chen
Signed-off-by: Jae Hyun Yoo
Reviewed-by: Haiyue Wang
Reviewed-by: James Feist
Reviewed-by: Ver
This commit updates ioctl-number.txt to reflect ioctl numbers used
by the PECI subsystem.
Cc: Jonathan Corbet
Cc: Greg Kroah-Hartman
Cc: Kishon Vijay Abraham I
Cc: Lorenzo Pieralisi
Cc: Gustavo Pimentel
Cc: Darrick J. Wong
Cc: Tomohiro Kusumi
Cc: Eric Sandeen
Cc: Frederic Barrat
Cc: Bryan
This commit adds PECI bus/adapter node of AST24xx/AST25xx into
aspeed-g4 and aspeed-g5.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: Jason M Biils
Cc: Ryan Chen
Signed-off-by: Jae Hyun Yoo
Reviewed-by: Haiyue Wang
Reviewed-by: James Feist
Reviewed-by: Vernon Ma
This commit adds driver implementation for PECI bus core into linux
driver framework.
PECI (Platform Environment Control Interface) is a one-wire bus interface
that provides a communication channel from Intel processors and chipset
components to external monitoring or control devices. PECI is desi
Introduction of the Platform Environment Control Interface (PECI) bus
device driver. PECI is a one-wire bus interface that provides a
communication channel from Intel processors and chipset components to
external monitoring or control devices. PECI is designed to support the
following sideband func
This commit adds hwmon documents for PECI cputemp and dimmtemp drivers.
Cc: Guenter Roeck
Cc: Jean Delvare
Cc: Jonathan Corbet
Cc: Jason M Biils
Cc: Randy Dunlap
Signed-off-by: Jae Hyun Yoo
Reviewed-by: Haiyue Wang
Reviewed-by: James Feist
Reviewed-by: Vernon Mauery
Acked-by: Guenter Roec
On Mon, Jan 7, 2019 at 7:13 AM Waiman Long wrote:
>
> The code that generates the "intr" line of /proc/stat is now moved
> from show_stat() into a new function - show_stat_irqs(). There is no
> functional change.
>
> Signed-off-by: Waiman Long
Reviewed-by: Kees Cook
-Kees
> ---
> fs/proc/sta
This commit adds PECI dimmtemp hwmon driver.
Cc: Guenter Roeck
Cc: Jean Delvare
Cc: Alan Cox
Cc: Andrew Jeffery
Cc: Andy Shevchenko
Cc: Arnd Bergmann
Cc: Jason M Biils
Cc: Joel Stanley
Cc: Miguel Ojeda
Cc: Andrew Lunn
Cc: Stef van Os
Signed-off-by: Jae Hyun Yoo
Reviewed-by: Haiyue Wang
This commit adds a dt-bindings document for PECI client driver.
Cc: Lee Jones
Cc: Rob Herring
Cc: Mark Rutland
Cc: Andrew Jeffery
Cc: James Feist
Cc: Jason M Biils
Cc: Joel Stanley
Cc: Vernon Mauery
Signed-off-by: Jae Hyun Yoo
Reviewed-by: Rob Herring
---
.../bindings/mfd/intel-peci-cli
This commit adds PECI cputemp hwmon driver.
Cc: Guenter Roeck
Cc: Jean Delvare
Cc: Alan Cox
Cc: Andrew Jeffery
Cc: Andy Shevchenko
Cc: Arnd Bergmann
Cc: Jason M Biils
Cc: Joel Stanley
Cc: Miguel Ojeda
Cc: Andrew Lunn
Cc: Stef van Os
Signed-off-by: Jae Hyun Yoo
Reviewed-by: Haiyue Wang
This commit adds maintainer information for the PECI subsystem.
Cc: David S. Miller
Cc: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman
Cc: Andrew Morton
Cc: Linus Walleij
Cc: Randy Dunlap
Cc: Jason M Biils
Signed-off-by: Jae Hyun Yoo
---
MAINTAINERS | 22 ++
1 file chang
This commit adds PECI client driver.
Cc: Lee Jones
Cc: Randy Dunlap
Cc: Rob Herring
Cc: Andrew Jeffery
Cc: James Feist
Cc: Jason M Biils
Cc: Joel Stanley
Cc: Vernon Mauery
Signed-off-by: Jae Hyun Yoo
---
drivers/mfd/Kconfig | 14 +++
drivers/mfd/Makefile
This commit adds a document of generic PECI bus, adapter and client
driver.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Andrew Jeffery
Cc: Joel Stanley
Signed-off-by: Jae Hyun Yoo
Reviewed-by: Haiyue Wang
Reviewed-by: James Feist
Reviewed-by: Vernon Mauery
Reviewed-by: Rob Herring
---
.../devic
This commit adds a dt-bindings document of PECI adapter driver for ASPEED
AST24xx/25xx SoCs.
Cc: Mark Rutland
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: Benjamin Herrenschmidt
Cc: Greg Kroah-Hartman
Cc: Jason M Biils
Cc: Milton Miller II
Cc: Pavel Machek
Cc: Robin Murphy
Cc: Ryan Chen
Signe
On Mon, Jan 07, 2019 at 09:48:44AM -0800, Andy Lutomirski wrote:
>
>
> > On Jan 7, 2019, at 7:50 AM, Yuri Norov wrote:
> >
> > Hi all,
> >
> >> On Wed, May 16, 2018 at 11:18:45AM +0300, Yury Norov wrote:
> >> This series enables AARCH64 with ILP32 mode.
> >>
> >> As supporting work, it introd
On Mon, 2019-01-07 at 10:20 -0800, Bart Van Assche wrote:
> In emacs 23.1 support for directory-local variables was added (see also
> https://lists.gnu.org/archive/html/info-gnu-emacs/2009-07/msg0.html).
> Simplify the settings in coding-style.rst by using that feature.
> Additionally, do not i
On Mon, Jan 07, 2019 at 11:25:16AM -0800, Dave Hansen wrote:
> On 1/7/19 6:15 AM, Matthew Wilcox wrote:
> > You're going to get data corruption doing this. try_to_unmap_one()
> > does:
> >
> > /* Move the dirty bit to the page. Now the pte is gone. */
> > if (pte_dirty(pteval))
On Mon, Jan 07, 2019 at 02:13:29PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 11:02:36AM -0800, Paul E. McKenney wrote:
> > On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > > > On Sun, Jan 0
On 1/7/19 6:15 AM, Matthew Wilcox wrote:
> You're going to get data corruption doing this. try_to_unmap_one()
> does:
>
> /* Move the dirty bit to the page. Now the pte is gone. */
> if (pte_dirty(pteval))
> set_page_dirty(page);
>
> so PageDirty() can be false
On Mon 2019-01-07 11:06:27, Frank Rowand wrote:
>
> + Frank
>
> On 1/7/19 10:37 AM, Pavel Machek wrote:
> > Is it "Device Tree" or "device tree"?
> >
> > pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
> > 235
> > pavel@duo:/data/l/k/Documentation$ grep -r "device tree"
On Mon, Jan 07, 2019 at 11:02:36AM -0800, Paul E. McKenney wrote:
> On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > > On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> > > > On Mon, Jan 0
+ Frank
On 1/7/19 10:37 AM, Pavel Machek wrote:
> Is it "Device Tree" or "device tree"?
>
> pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
> 235
> pavel@duo:/data/l/k/Documentation$ grep -r "device tree" | wc -l
> 595
>
> I guess it would be nice to make it cons
On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
> > > > On 2019/1/3 上午4:57,
Am 03.01.19 um 19:12 schrieb Jonathan Corbet:
> On Fri, 21 Dec 2018 16:26:31 +0100
> Thorsten Leemhuis wrote:
>>> Here's an idea if you feel like improving this: rather than putting an
>>> inscrutable program inline, add a taint_status script to scripts/ that
>>> prints out the status in fully hum
On Mon, Jan 7, 2019 at 12:37 PM Pavel Machek wrote:
>
> Is it "Device Tree" or "device tree"?
>
> pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
> 235
> pavel@duo:/data/l/k/Documentation$ grep -r "device tree" | wc -l
> 595
>
> I guess it would be nice to make it consistent
On Mon, Jan 07, 2019 at 07:37:11PM +0100, Pavel Machek wrote:
> Is it "Device Tree" or "device tree"?
>
> pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
> 235
> pavel@duo:/data/l/k/Documentation$ grep -r "device tree" | wc -l
> 595
You missed ...
$ git grep -r "Device
Is it "Device Tree" or "device tree"?
pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
235
pavel@duo:/data/l/k/Documentation$ grep -r "device tree" | wc -l
595
I guess it would be nice to make it consistent. I guess "device tree"
is preffered?
Should we do something
In emacs 23.1 support for directory-local variables was added (see also
https://lists.gnu.org/archive/html/info-gnu-emacs/2009-07/msg0.html).
Simplify the settings in coding-style.rst by using that feature.
Additionally, do not inherit any settings from emacs' linux coding style
to minimize dep
The URL of [api-spec] in Documentation/virtual/kvm/amd-memory-encryption.rst
is no longer valid, replaced space with underscore.
Signed-off-by: Christophe de Dinechin
---
Documentation/virtual/kvm/amd-memory-encryption.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Docum
On 01/07/2019 11:33 AM, Alexey Dobriyan wrote:
> On Mon, Jan 07, 2019 at 07:58:40AM -0800, Matthew Wilcox wrote:
>> On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote:
>>> A new "fs/proc-stat-irqs-latency-ms" sysctl parameter is now added to
>> No. No, no, no, no, no. No.
>>
>> Stop addi
On Mon, Jan 07, 2019 at 07:58:40AM -0800, Matthew Wilcox wrote:
> On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote:
> > A new "fs/proc-stat-irqs-latency-ms" sysctl parameter is now added to
>
> No. No, no, no, no, no. No.
>
> Stop adding new sysctls for this kind of thing. It's jus
On Mon, Jan 07, 2019 at 04:54:23PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
>
> > > How about naming the thing: dependent_ptr() ? That is without any (r)mb
> > > implicatio
On 01/07/2019 11:14 AM, Matthew Wilcox wrote:
> On Mon, Jan 07, 2019 at 11:07:47AM -0500, Waiman Long wrote:
>>> Why are you caching the _output_ of calling sprintf(), rather than caching
>>> the
>>> values of each interrupt?
>>>
>> It is just faster to dump the whole string buffer than redoing th
On Mon, Jan 07, 2019 at 11:07:47AM -0500, Waiman Long wrote:
> > Why are you caching the _output_ of calling sprintf(), rather than caching
> > the
> > values of each interrupt?
> >
> It is just faster to dump the whole string buffer than redoing the
> number formatting each time when the values d
On 01/07/2019 10:58 AM, Matthew Wilcox wrote:
> On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote:
>> Reading /proc/stat can be slow especially if there are many irqs and on
>> systems with many CPUs as summation of all the percpu counts for each
>> of the irqs is required. On some newer
On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote:
> Reading /proc/stat can be slow especially if there are many irqs and on
> systems with many CPUs as summation of all the percpu counts for each
> of the irqs is required. On some newer systems, there can be more than
> 1000 irqs per soc
On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > How about naming the thing: dependent_ptr() ? That is without any (r)mb
> > implications at all. The address dependency is strictly weaker than an
> > rmb in th
Hi all,
On Wed, May 16, 2018 at 11:18:45AM +0300, Yury Norov wrote:
> This series enables AARCH64 with ILP32 mode.
>
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t userspa
From: Otto Sabart
Date: Sun, 6 Jan 2019 00:28:45 +0100
> Changes in v2:
> - Patch #3 and #2 were combined into patch #2.
Jon, do you want to integrate these? I'm fine with that and I don't anticiapte
any serious conflicts.
Acked-by: David S. Miller
As newer systems have more and more IRQs and CPUs available in their
system, the performance of reading /proc/stat frequently is getting
worse and worse.
Last year, I had proposed patch to extract out the IRQ line of /proc/stat
into a new procfs file. However, this may break existing applications
Reading /proc/stat can be slow especially if there are many irqs and on
systems with many CPUs as summation of all the percpu counts for each
of the irqs is required. On some newer systems, there can be more than
1000 irqs per socket.
Applications that need to read /proc/stat many times per second
The code that generates the "intr" line of /proc/stat is now moved
from show_stat() into a new function - show_stat_irqs(). There is no
functional change.
Signed-off-by: Waiman Long
---
fs/proc/stat.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
On 12/19/2018 02:09 PM, Waiman Long wrote:
> With the default SPEC_STORE_BYPASS_SECCOMP/SPEC_STORE_BYPASS_PRCTL mode,
> the TIF_SSBD bit will be inherited when a new task is fork'ed or cloned.
>
> As only certain class of applications (like Java) requires disabling
> speculative store bypass for se
On Mon, Jan 07, 2019 at 02:02:39PM +0100, Vincent Whitchurch wrote:
> +++ b/Documentation/sysctl/vm.txt
> @@ -222,6 +222,10 @@ To increase the number of objects freed by this
> operation, the user may run
> number of dirty objects on the system and create more candidates to be
> dropped.
>
> +
On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
> > > On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
>
> > > > +#if defined(COMPILER_HAS_OPTIMIZER_HI
drop_caches does not drop pages which are currently mapped. Add an
option to try to unmap and drop even these pages. This provides a
simple way to obtain a rough estimate of how many file pages are used in
a particular use case: drop everything and check how much gets read
back.
# cat /proc/mem
The documemt, at Documentation/admin-guide/pstore-block.rst,
tells user how to use pstore_blk and the attentions about panic
read/write
Signed-off-by: liaoweixiong
---
Documentation/admin-guide/pstore-block.rst | 226 +
MAINTAINERS| 1
It is a sample for pstore_blk, using general ram rather than block device.
According to pstore_blk, the data will be saved to ram buffer if not
register device path and apis for panic. So, it can only used to dump
Oops and some things will not reboot.
Signed-off-by: liaoweixiong
---
fs/pstore/Kc
To enable pmsg, just set pmsg_size when block device register blkzone.
Signed-off-by: liaoweixiong
---
fs/pstore/blkzone.c| 254 +
include/linux/pstore_blk.h | 1 +
2 files changed, 233 insertions(+), 22 deletions(-)
diff --git a/fs/pstore/b
pstore_blk is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_blk?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample
Why should we need pstore_block?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have b
On 2019-01-07 10:11, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Mon, Jan 7, 2019 at 10:03 AM Peter Rosin wrote:
>> On 2019-01-07 09:59, Peter Rosin wrote:
>>> On 2019-01-07 09:40, Geert Uytterhoeven wrote:
On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wrote:
> On 2019-01-06 10:33, Geert
On Fri, 04 Jan 2019, Bart Van Assche wrote:
> Regarding users having their own version of .dir-locals.el: why do you
> think anyone would want to do that?
Err, .dir-locals.el is not only for a project to enforce local variables
on emacs users, it's also for the users to set local variables for th
On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
> > On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
> > > +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \
> > > + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS)
> > > +
> >
在 2019年01月07日 10:29, Baoquan He 写道:
> On 01/07/19 at 09:47am, Lianbo Jiang wrote:
>> For AMD machine with SME feature, makedumpfile tools need to know
>> whether the crash kernel was encrypted or not. If SME is enabled
> ^ crashed
>> in the first kernel, the crash kernel's page table(
在 2019年01月07日 15:55, Hatayama, Daisuke 写道:
> Hi,
>
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org
>> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Lianbo Jiang
>> Sent: Monday, January 7, 2019 10:48 AM
>> To: linux-ker...@vger.kernel.org
>> Cc: ke...@lists.inf
On 05.01.2019 22:41, Uwe Kleine-König wrote:
> On Thu, Jan 03, 2019 at 01:29:47PM +, claudiu.bez...@microchip.com wrote:
>> From: Claudiu Beznea
>>
>> Add PWM normal and complementary modes.
>>
>
> The Subject line and the commit log don't really match the patch
> content as it only adds do
On 05.01.2019 23:05, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Jan 03, 2019 at 01:29:44PM +, claudiu.bez...@microchip.com wrote:
>> From: Claudiu Beznea
>>
>> Add basic PWM modes: normal and complementary. These modes should
>> differentiate the single output PWM channels from two output
Hi Peter,
On Mon, Jan 7, 2019 at 10:03 AM Peter Rosin wrote:
> On 2019-01-07 09:59, Peter Rosin wrote:
> > On 2019-01-07 09:40, Geert Uytterhoeven wrote:
> >> On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wrote:
> >>> On 2019-01-06 10:33, Geert Uytterhoeven wrote:
> On Mon, Nov 26, 2018 at 10:
On 2019-01-07 09:59, Peter Rosin wrote:
> On 2019-01-07 09:40, Geert Uytterhoeven wrote:
>> Hi Peter,
>>
>> On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wrote:
>>> On 2019-01-06 10:33, Geert Uytterhoeven wrote:
On Mon, Nov 26, 2018 at 10:59 PM Peter Rosin wrote:
> If there are extra logos
On 2019-01-07 09:40, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wrote:
>> On 2019-01-06 10:33, Geert Uytterhoeven wrote:
>>> On Mon, Nov 26, 2018 at 10:59 PM Peter Rosin wrote:
If there are extra logos (CONFIG_FB_LOGO_EXTRA) the heights of these
>>>
Hi Peter,
On Mon, Jan 7, 2019 at 9:26 AM Peter Rosin wrote:
> On 2019-01-06 10:33, Geert Uytterhoeven wrote:
> > On Mon, Nov 26, 2018 at 10:59 PM Peter Rosin wrote:
> >> If there are extra logos (CONFIG_FB_LOGO_EXTRA) the heights of these
> >> extra logos are not considered when centering the fi
On 2019-01-06 10:33, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Mon, Nov 26, 2018 at 10:59 PM Peter Rosin wrote:
>> If there are extra logos (CONFIG_FB_LOGO_EXTRA) the heights of these
>> extra logos are not considered when centering the first logo vertically.
>>
>> Signed-off-by: Peter Rosin
Hi,
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Lianbo Jiang
> Sent: Monday, January 7, 2019 10:48 AM
> To: linux-ker...@vger.kernel.org
> Cc: ke...@lists.infradead.org; t...@linutronix.de; mi...@redhat.com;
> b
81 matches
Mail list logo
