From: Peter Zijlstra
We can use PCID to retain the TLBs across CR3 switches; including those now
part of the user/kernel switch. This increases performance of kernel
entry/exit at the cost of more expensive/complicated TLB flushing.
Now that we have two address spaces, one for kernel and one
From: Dave Hansen
Kernel page table isolation requires to have two PGDs. One for the kernel,
which contains the full kernel mapping plus the user space mapping and one
for user space which contains the user space mappings and the minimal set
of kernel mappings which are required by the
From: Dave Hansen
In preparation to adding additional PCID flushing, abstract the
loading of a new ASID into CR3.
[ PeterZ: Split out from big combo patch ]
Signed-off-by: Dave Hansen
Signed-off-by: Peter Zijlstra (Intel)
From: Dave Hansen
In preparation to adding additional PCID flushing, abstract the
loading of a new ASID into CR3.
[ PeterZ: Split out from big combo patch ]
Signed-off-by: Dave Hansen
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Cc: Andy
From: Dave Hansen
With PAGE_TABLE_ISOLATION the user portion of the kernel page tables is
poisoned with the NX bit so if the entry code exits with the kernel page
tables selected in CR3, userspace crashes.
But doing so trips the p4d/pgd_bad() checks. Make sure it
From: Dave Hansen
With PAGE_TABLE_ISOLATION the user portion of the kernel page tables is
poisoned with the NX bit so if the entry code exits with the kernel page
tables selected in CR3, userspace crashes.
But doing so trips the p4d/pgd_bad() checks. Make sure it does not do
that.
From: Peter Zijlstra
Ideally we'd also use sparse to enforce this separation so it becomes much
more difficult to mess up.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
From: Peter Zijlstra
Ideally we'd also use sparse to enforce this separation so it becomes much
more difficult to mess up.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian
The upcoming support for dumping the kernel and the user space page tables
of the current process would create more random files in the top level
debugfs directory.
Add a page table directory and move the existing file to it.
Signed-off-by: Borislav Petkov
Signed-off-by: Ingo
The upcoming support for dumping the kernel and the user space page tables
of the current process would create more random files in the top level
debugfs directory.
Add a page table directory and move the existing file to it.
Signed-off-by: Borislav Petkov
Signed-off-by: Ingo Molnar
From: Dave Hansen
Add the pagetable helper functions do manage the separate user space page
tables.
[ tglx: Split out from the big combo kaiser patch. Folded Andys
simplification and made it out of line as Boris suggested ]
Signed-off-by: Dave Hansen
From: Vlastimil Babka
CONFIG_PAGE_TABLE_ISOLATION is relatively new and intrusive feature that may
still have some corner cases which could take some time to manifest and be
fixed. It would be useful to have Oops messages indicate whether it was
enabled for building the kernel,
From: Dave Hansen
This uses INVPCID to shoot down individual lines of the user mapping
instead of marking the entire user map as invalid. This
could/might/possibly be faster.
This for sure needs tlb_single_page_flush_ceiling to be redetermined;
esp. since INVPCID is
From: Dave Hansen
Add the pagetable helper functions do manage the separate user space page
tables.
[ tglx: Split out from the big combo kaiser patch. Folded Andys
simplification and made it out of line as Boris suggested ]
Signed-off-by: Dave Hansen
Signed-off-by: Thomas Gleixner
From: Vlastimil Babka
CONFIG_PAGE_TABLE_ISOLATION is relatively new and intrusive feature that may
still have some corner cases which could take some time to manifest and be
fixed. It would be useful to have Oops messages indicate whether it was
enabled for building the kernel, and whether it
From: Dave Hansen
This uses INVPCID to shoot down individual lines of the user mapping
instead of marking the entire user map as invalid. This
could/might/possibly be faster.
This for sure needs tlb_single_page_flush_ceiling to be redetermined;
esp. since INVPCID is _slow_.
A detailed
From: Andy Lutomirski
Share the cpu entry area so the user space and kernel space page tables
have the same P4D page.
Signed-off-by: Andy Lutomirski
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Cc: Boris
From: Thomas Gleixner
ptdump_walk_pgd_level_checkwx() checks the kernel page table for WX pages,
but does not check the PAGE_TABLE_ISOLATION user space page table.
Restructure the code so that dmesg output is selected by an explicit
argument and not implicit via checking the
From: Andy Lutomirski
Share the cpu entry area so the user space and kernel space page tables
have the same P4D page.
Signed-off-by: Andy Lutomirski
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: David
From: Thomas Gleixner
ptdump_walk_pgd_level_checkwx() checks the kernel page table for WX pages,
but does not check the PAGE_TABLE_ISOLATION user space page table.
Restructure the code so that dmesg output is selected by an explicit
argument and not implicit via checking the pgd argument for
From: Andy Lutomirski
With PTI enabled, the LDT must be mapped in the usermode tables somewhere.
The LDT is per process, i.e. per mm.
An earlier approach mapped the LDT on context switch into a fixmap area,
but that's a big overhead and exhausted the fixmap space when NR_CPUS
From: Andy Lutomirski
With PTI enabled, the LDT must be mapped in the usermode tables somewhere.
The LDT is per process, i.e. per mm.
An earlier approach mapped the LDT on context switch into a fixmap area,
but that's a big overhead and exhausted the fixmap space when NR_CPUS got
big.
Take
struct proc_dir_entry became bit messy over years:
* move 16-bit ->mode_t before namelen to get rid of padding
* make ->in_use first field: it seems to be most used resulting in
smaller code on x86_64 (defconfig):
add/remove: 0/0 grow/shrink: 7/13 up/down: 24/-67 (-43)
Function
struct proc_dir_entry became bit messy over years:
* move 16-bit ->mode_t before namelen to get rid of padding
* make ->in_use first field: it seems to be most used resulting in
smaller code on x86_64 (defconfig):
add/remove: 0/0 grow/shrink: 7/13 up/down: 24/-67 (-43)
Function
From: Dave Hansen
Finally allow CONFIG_PAGE_TABLE_ISOLATION to be enabled.
PARAVIRT generally requires that the kernel not manage its own page tables.
It also means that the hypervisor and kernel must agree wholeheartedly
about what format the page tables are in and
From: Dave Hansen
Finally allow CONFIG_PAGE_TABLE_ISOLATION to be enabled.
PARAVIRT generally requires that the kernel not manage its own page tables.
It also means that the hypervisor and kernel must agree wholeheartedly
about what format the page tables are in and what they contain.
From: Thomas Gleixner
Now that the LDT mapping is in a known area when PAGE_TABLE_ISOLATION is
enabled its a primary target for attacks, if a user space interface fails
to validate a write address correctly. That can never happen, right?
The SDM states:
If the segment
From: Thomas Gleixner
Now that the LDT mapping is in a known area when PAGE_TABLE_ISOLATION is
enabled its a primary target for attacks, if a user space interface fails
to validate a write address correctly. That can never happen, right?
The SDM states:
If the segment descriptors in the
From: Dave Hansen
If changing the page tables in such a way that an invalidation of all
contexts (aka. PCIDs / ASIDs) is required, they can be actively invalidated
by:
1. INVPCID for each PCID (works for single pages too).
2. Load CR3 with each PCID without the
From: Peter Zijlstra
Most NMI/paranoid exceptions will not in fact change pagetables and would
thus not require TLB flushing, however RESTORE_CR3 uses flushing CR3
writes.
Restores to kernel PCIDs can be NOFLUSH, because we explicitly flush the
kernel mappings and now that
From: Dave Hansen
If changing the page tables in such a way that an invalidation of all
contexts (aka. PCIDs / ASIDs) is required, they can be actively invalidated
by:
1. INVPCID for each PCID (works for single pages too).
2. Load CR3 with each PCID without the NOFLUSH bit set
3. Load CR3
From: Peter Zijlstra
Most NMI/paranoid exceptions will not in fact change pagetables and would
thus not require TLB flushing, however RESTORE_CR3 uses flushing CR3
writes.
Restores to kernel PCIDs can be NOFLUSH, because we explicitly flush the
kernel mappings and now that we track which user
From: Thomas Gleixner
Add two debugfs files which allow to dump the pagetable of the current
task.
current_kernel dumps the regular page table. This is the page table which
is normally shared between kernel and user space. If kernel page table
isolation is enabled this is
From: Thomas Gleixner
Add two debugfs files which allow to dump the pagetable of the current
task.
current_kernel dumps the regular page table. This is the page table which
is normally shared between kernel and user space. If kernel page table
isolation is enabled this is the kernel space
From: Peter Zijlstra
Unclutter tlbflush.h a little.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
From: Peter Zijlstra
Unclutter tlbflush.h a little.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: David Laight
Cc: Denys Vlasenko
Cc: Eduardo Valentin
Cc: Greg KH
Cc: H.
From: Peter Zijlstra
__flush_tlb_single() is for user mappings, __flush_tlb_one() for
kernel mappings.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Cc: Andy
From: Peter Zijlstra
__flush_tlb_single() is for user mappings, __flush_tlb_one() for
kernel mappings.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave
From: Peter Zijlstra
Since uv_flush_tlb_others() implements flush_tlb_others() which is
about flushing user mappings, we should use __flush_tlb_single(),
which too is about flushing user mappings.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by:
From: Peter Zijlstra
Since uv_flush_tlb_others() implements flush_tlb_others() which is
about flushing user mappings, we should use __flush_tlb_single(),
which too is about flushing user mappings.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
From: Thomas Gleixner
In order to sanitize the LDT initialization on x86 arch_dup_mmap() must be
allowed to fail. Fix up all instances.
Signed-off-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Cc: Juergen Gross
From: Thomas Gleixner
In order to sanitize the LDT initialization on x86 arch_dup_mmap() must be
allowed to fail. Fix up all instances.
Signed-off-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Cc: Juergen Gross
Cc: Eduardo Valentin
Cc: Denys Vlasenko
Cc: aligu...@amazon.com
Cc:
On Wed, 20 Dec 2017 20:53:41 +, Roman Gushchin wrote:
> On Wed, Dec 20, 2017 at 12:29:21PM -0800, Jakub Kicinski wrote:
> > On Wed, 20 Dec 2017 20:19:43 +, Roman Gushchin wrote:
> > > Bpftool determines it's own version based on the kernel
> > > version, which is picked from the
On Wed, 20 Dec 2017 20:53:41 +, Roman Gushchin wrote:
> On Wed, Dec 20, 2017 at 12:29:21PM -0800, Jakub Kicinski wrote:
> > On Wed, 20 Dec 2017 20:19:43 +, Roman Gushchin wrote:
> > > Bpftool determines it's own version based on the kernel
> > > version, which is picked from the
Andrey,
On Wed, Dec 20, 2017 at 9:45 PM, Andrey Smirnov
wrote:
> Everyone:
>
> This patch series is v16 of the driver for supervisory processor found
> on RAVE series of devices from ZII. Supervisory processor is a PIC
> microcontroller connected to various electrical
Andrey,
On Wed, Dec 20, 2017 at 9:45 PM, Andrey Smirnov
wrote:
> Everyone:
>
> This patch series is v16 of the driver for supervisory processor found
> on RAVE series of devices from ZII. Supervisory processor is a PIC
> microcontroller connected to various electrical subsystems on RAVE
>
On 12/20/2017 02:33 PM, David Lechner wrote:
So, as you can see, we get 4 warnings here. There is no problem with any
clock provider or consumer (as far as I can tell). The bug here is that
spin_trylock_irqsave() always returns true on non-SMP systems, which
messes up the reference counting.
On 12/20/2017 02:33 PM, David Lechner wrote:
So, as you can see, we get 4 warnings here. There is no problem with any
clock provider or consumer (as far as I can tell). The bug here is that
spin_trylock_irqsave() always returns true on non-SMP systems, which
messes up the reference counting.
On Wed, Dec 20, 2017 at 09:26:32AM +0100, Bartosz Golaszewski wrote:
> AT24 EEPROMs have a write-protect pin, which - when pulled high -
> inhibits writes to the upper quadrant of memory (although it has been
> observed that on some chips it disables writing to the entire memory
> range).
>
> On
On Wed, Dec 20, 2017 at 09:26:32AM +0100, Bartosz Golaszewski wrote:
> AT24 EEPROMs have a write-protect pin, which - when pulled high -
> inhibits writes to the upper quadrant of memory (although it has been
> observed that on some chips it disables writing to the entire memory
> range).
>
> On
On Wed, Dec 20, 2017 at 11:30:07AM +0100, Hans de Goede wrote:
> Hi Andy, et al,
>
> Here are 2 patches to add entries for 2 more Chuwi tablet models to
> silead_dmi.c. Note that these are for 2 different tablets, even though
> the entries look similar.
>
> I've based this series on top of the
On Wed, Dec 20, 2017 at 11:30:07AM +0100, Hans de Goede wrote:
> Hi Andy, et al,
>
> Here are 2 patches to add entries for 2 more Chuwi tablet models to
> silead_dmi.c. Note that these are for 2 different tablets, even though
> the entries look similar.
>
> I've based this series on top of the
On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote:
> diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
> index ca554d57d01e..35f973ba9878 100644
> --- a/crypto/aes_generic.c
> +++ b/crypto/aes_generic.c
> @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key);
>
On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote:
> diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
> index ca554d57d01e..35f973ba9878 100644
> --- a/crypto/aes_generic.c
> +++ b/crypto/aes_generic.c
> @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key);
>
On Wed, Dec 20, 2017 at 01:53:10PM +1030, Joel Stanley wrote:
> These are used to by the device tree to map pin numbers to constants
> required by the GPIO bindings.
>
> Signed-off-by: Joel Stanley
> --
> v3:
> - Remove dtsi includes from this patch, they will come later
> ---
>
On Wed, Dec 20, 2017 at 01:53:10PM +1030, Joel Stanley wrote:
> These are used to by the device tree to map pin numbers to constants
> required by the GPIO bindings.
>
> Signed-off-by: Joel Stanley
> --
> v3:
> - Remove dtsi includes from this patch, they will come later
> ---
>
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote:
> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> thermal calibration data, add node to describe it.
>
> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> supported in an external driver
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote:
> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> thermal calibration data, add node to describe it.
>
> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> supported in an external driver
On Wed, Dec 20, 2017 at 11:42:51AM -0800, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> The userspace RDPMC usage never works for large PEBS since the large
> PEBS is introduced by
> commit b8241d20699e ("perf/x86/intel: Implement batched PEBS interrupt
>
On Wed, Dec 20, 2017 at 11:42:51AM -0800, kan.li...@linux.intel.com wrote:
> From: Kan Liang
>
> The userspace RDPMC usage never works for large PEBS since the large
> PEBS is introduced by
> commit b8241d20699e ("perf/x86/intel: Implement batched PEBS interrupt
> handling (large PEBS interrupt
On 12/20/2017 12:52 PM, Michael S. Tsirkin wrote:
> On Wed, Dec 20, 2017 at 12:07:55PM -0500, Jason Baron wrote:
>>
>>
>> On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote:
>>> On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote:
If the hypervisor exports the link and duplex speed,
On 12/20/2017 12:52 PM, Michael S. Tsirkin wrote:
> On Wed, Dec 20, 2017 at 12:07:55PM -0500, Jason Baron wrote:
>>
>>
>> On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote:
>>> On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote:
If the hypervisor exports the link and duplex speed,
On Wed, Dec 20, 2017 at 10:14 PM, Ard Biesheuvel
wrote:
> On 20 December 2017 at 20:52, Arnd Bergmann wrote:
>
> You can use the tcrypt.ko module to benchmark AES.
>
> modprobe tcrypt mode=200 sec=1
Ok, that's what I was looking for. I don't think I'll
On Wed, Dec 20, 2017 at 10:14 PM, Ard Biesheuvel
wrote:
> On 20 December 2017 at 20:52, Arnd Bergmann wrote:
>
> You can use the tcrypt.ko module to benchmark AES.
>
> modprobe tcrypt mode=200 sec=1
Ok, that's what I was looking for. I don't think I'll have time to
analyze this before
my
On Wed, Dec 20, 2017 at 06:10:11PM +, Song Liu wrote:
> I think there is one more thing to change:
OK, folded that too; it should all be at:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
Can you verify it all looks/works right?
On Wed, Dec 20, 2017 at 06:10:11PM +, Song Liu wrote:
> I think there is one more thing to change:
OK, folded that too; it should all be at:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
Can you verify it all looks/works right?
On 18/12/2017 at 12:51:29 +0100, linux-kernel-...@beckhoff.com wrote:
> From: Patrick Bruenn
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover
On 18/12/2017 at 12:51:29 +0100, linux-kernel-...@beckhoff.com wrote:
> From: Patrick Bruenn
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover time counter
> - 32-bit
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote:
> Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
> compatible string is actually brcm,bcm-cpu-biu-ctrl. Also
> document in the binding the fallback property
> ("brcm,brcmstb-cpu-biu-ctrl") and update the example
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote:
> Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
> compatible string is actually brcm,bcm-cpu-biu-ctrl. Also
> document in the binding the fallback property
> ("brcm,brcmstb-cpu-biu-ctrl") and update the example
On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> > On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> > > I don't know what the right interface is, but my laptop has a set of
> > > /sys/devices/system/memory/memoryN/
On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> > On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> > > I don't know what the right interface is, but my laptop has a set of
> > > /sys/devices/system/memory/memoryN/
On Tue, Dec 19 2017, Jan Kara wrote:
> On Fri 08-12-17 13:17:31, NeilBrown wrote:
>> On Thu, Dec 07 2017, Amir Goldstein wrote:
>>
>> > On Thu, Dec 7, 2017 at 5:20 AM, NeilBrown wrote:
>> >> On Wed, Dec 06 2017, Linus Torvalds wrote:
>> >>
>> >>> On Thu, Nov 30, 2017 at 12:56
On Tue, Dec 19 2017, Jan Kara wrote:
> On Fri 08-12-17 13:17:31, NeilBrown wrote:
>> On Thu, Dec 07 2017, Amir Goldstein wrote:
>>
>> > On Thu, Dec 7, 2017 at 5:20 AM, NeilBrown wrote:
>> >> On Wed, Dec 06 2017, Linus Torvalds wrote:
>> >>
>> >>> On Thu, Nov 30, 2017 at 12:56 PM, NeilBrown
> Some observations:
>
> o Your patch fixes no bug nor replaces any depreciated feature.
How do you think about information from the section “14) Allocating memory”
in the document “coding-style.rst” for the shown source code transformation?
> o There will be no functional change; …
Yes. -
> Some observations:
>
> o Your patch fixes no bug nor replaces any depreciated feature.
How do you think about information from the section “14) Allocating memory”
in the document “coding-style.rst” for the shown source code transformation?
> o There will be no functional change; …
Yes. -
On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
> Hi Viresh,
>
> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> > On 19-12-17, 21:25, Sricharan R wrote:
> >> + cpu@0 {
> >> + compatible = "qcom,krait";
> >> + enable-method = "qcom,kpss-acc-v1";
> >> +
On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
> Hi Viresh,
>
> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> > On 19-12-17, 21:25, Sricharan R wrote:
> >> + cpu@0 {
> >> + compatible = "qcom,krait";
> >> + enable-method = "qcom,kpss-acc-v1";
> >> +
On 20/12/2017 20:40, Jim Mattson wrote:
> This doesn't look right to me. Without APIC-register virtualization,
> the only X2APIC MSR intercept that should be disabled is TPR.
Of course... The bitmap that has to be outside the "if" is
*_x2apic_apicv, not *_x2apic. I sent the wrong version of the
On 20/12/2017 20:40, Jim Mattson wrote:
> This doesn't look right to me. Without APIC-register virtualization,
> the only X2APIC MSR intercept that should be disabled is TPR.
Of course... The bitmap that has to be outside the "if" is
*_x2apic_apicv, not *_x2apic. I sent the wrong version of the
On Wed, Dec 20, 2017 at 09:20:48PM +0100, Philippe Ombredanne wrote:
> On Wed, Dec 20, 2017 at 9:15 PM, Cheah Kok Cheong wrote:
> > Remove FSF address otherwise checkpatch will flag my next patch.
> >
> > Signed-off-by: Cheah Kok Cheong
> > ---
> >
On Wed, Dec 20, 2017 at 09:20:48PM +0100, Philippe Ombredanne wrote:
> On Wed, Dec 20, 2017 at 9:15 PM, Cheah Kok Cheong wrote:
> > Remove FSF address otherwise checkpatch will flag my next patch.
> >
> > Signed-off-by: Cheah Kok Cheong
> > ---
> > kernel/padata.c | 4
> > 1 file changed,
On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> > I don't know what the right interface is, but my laptop has a set of
> > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> > right place to expose write_bw (etc).
On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> > I don't know what the right interface is, but my laptop has a set of
> > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> > right place to expose write_bw (etc).
On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote:
> From: Stephen Boyd
>
> The Krait clock controller controls the krait CPU and the L2 clocks
> consisting a primary mux and secondary mux. Add document for that.
>
> Signed-off-by: Stephen Boyd
On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote:
> From: Stephen Boyd
>
> The Krait clock controller controls the krait CPU and the L2 clocks
> consisting a primary mux and secondary mux. Add document for that.
>
> Signed-off-by: Stephen Boyd
> ---
>
On 20 December 2017 at 20:52, Arnd Bergmann wrote:
> While testing other changes, I discovered that gcc-7.2.1 produces badly
> optimized code for aes_encrypt/aes_decrypt. This is especially true when
> CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely
> large stack
On 20 December 2017 at 20:52, Arnd Bergmann wrote:
> While testing other changes, I discovered that gcc-7.2.1 produces badly
> optimized code for aes_encrypt/aes_decrypt. This is especially true when
> CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely
> large stack usage that in
On Wed, Dec 20, 2017 at 10:19:37AM -0800, Matthew Wilcox wrote:
> On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote:
> > What I'm hoping to do with this series is to just provide a sysfs
> > representation of the HMAT so that applications can know which NUMA nodes to
> > select with
On Wed, Dec 20, 2017 at 10:19:37AM -0800, Matthew Wilcox wrote:
> On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote:
> > What I'm hoping to do with this series is to just provide a sysfs
> > representation of the HMAT so that applications can know which NUMA nodes to
> > select with
On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote:
> From: Stephen Boyd
>
> The ACC and GCC regions present in KPSSv1 contain registers to
> control clocks and power to each Krait CPU and L2. Documenting
> the bindings here.
>
> Signed-off-by: Stephen Boyd
On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote:
> From: Stephen Boyd
>
> The ACC and GCC regions present in KPSSv1 contain registers to
> control clocks and power to each Krait CPU and L2. Documenting
> the bindings here.
>
> Signed-off-by: Stephen Boyd
> ---
>
On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote:
> From: Stephen Boyd
>
> Adds bindings document for qcom,hfpll instantiated within
> the Krait processor subsystem as separate register region.
>
> Signed-off-by: Stephen Boyd
> ---
>
On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote:
> From: Stephen Boyd
>
> Adds bindings document for qcom,hfpll instantiated within
> the Krait processor subsystem as separate register region.
>
> Signed-off-by: Stephen Boyd
> ---
> .../devicetree/bindings/clock/qcom,hfpll.txt
On Wed, 2017-12-13 at 08:21 +0100, Peter Zijlstra wrote:
> On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote:
> > >
> > > There's work on the way to allow multiple HW PMUs. You'll either have to
> > > wait for that or help in making that happen. What you do not do is
> > > silently hack
On Wed, 2017-12-13 at 08:21 +0100, Peter Zijlstra wrote:
> On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote:
> > >
> > > There's work on the way to allow multiple HW PMUs. You'll either have to
> > > wait for that or help in making that happen. What you do not do is
> > > silently hack
On 20.12.2017 23:16, Thierry Reding wrote:
> On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
>> On 20.12.2017 21:01, Thierry Reding wrote:
>>> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
On 20.12.2017 23:16, Thierry Reding wrote:
> On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
>> On 20.12.2017 21:01, Thierry Reding wrote:
>>> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
DEVICE_ATTR is a declaration macro that has a few alternate and
preferred forms like DEVICE_ATTR_RW, DEVICE_ATTR_RO, and DEVICE_ATTR.
As well, many uses of DEVICE_ATTR could use the preferred forms when
the show or store functions are also named in a regular form.
Suggest the preferred forms
DEVICE_ATTR is a declaration macro that has a few alternate and
preferred forms like DEVICE_ATTR_RW, DEVICE_ATTR_RO, and DEVICE_ATTR.
As well, many uses of DEVICE_ATTR could use the preferred forms when
the show or store functions are also named in a regular form.
Suggest the preferred forms
501 - 600 of 1904 matches
Mail list logo