Let's add ShmemHugePages and ShmemPmdMapped fields into meminfo and
smaps. It indicates how many times we allocate and map shmem THP.
NR_ANON_TRANSPARENT_HUGEPAGES is renamed to NR_ANON_THPS.
Signed-off-by: Kirill A. Shutemov
---
drivers/base/node.c| 13 +
fs/proc/meminfo.c
Even if user asked to allocate huge pages always (huge=always), we
should be able to free up some memory by splitting pages which are
partly byound i_size if memory presure comes or once we hit limit on
filesystem size (-o size=).
In order to do this we maintain per-superblock list of inodes, whic
split_huge_pmd() for file mappings (and DAX too) is implemented by just
clearing pmd entry as we can re-fill this area from page cache on pte
level later.
This means we don't need deposit page tables when file THP is mapped.
Therefore we shouldn't try to withdraw a page table on zap_huge_pmd()
fil
These flags are in use for file THP.
Signed-off-by: Kirill A. Shutemov
---
include/linux/page-flags.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 517707ae8cd1..9d518876dd6a 100644
--- a/include/linux/page
For now, we would have HPAGE_PMD_NR entries in radix tree for every huge
page. That's suboptimal and it will be changed to use Matthew's
multi-order entries later.
'add' operation is not changed, because we don't need it to implement
hugetmpfs: shmem uses its own implementation.
Signed-off-by: Ki
From: Hugh Dickins
Provide a shmem_get_unmapped_area method in file_operations, called
at mmap time to decide the mapping address. It could be conditional
on CONFIG_TRANSPARENT_HUGEPAGE, but save #ifdefs in other places by
making it unconditional.
shmem_get_unmapped_area() first calls the usual
Naive approach: on mapping/unmapping the page as compound we update
->_mapcount on each 4k page. That's not efficient, but it's not obvious
how we can optimize this. We can look into optimization later.
PG_double_map optimization doesn't work for file pages since lifecycle
of file pages is differe
This update aimed to address my todo list from lsf/mm summit:
- we now able to recovery memory by splitting huge pages partly beyond
i_size. This should address concern about small files.
- bunch of bug fixes for khugepaged, including fix for data corruption
reported by Hugh.
- Disabled
Add info about tmpfs/shmem with huge pages.
Signed-off-by: Kirill A. Shutemov
---
Documentation/vm/transhuge.txt | 130 +
1 file changed, 93 insertions(+), 37 deletions(-)
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index
change_huge_pmd() has assert which is not relvant for file page.
For shared mapping it's perfectly fine to have page table entry
writable, without explicit mkwrite.
Signed-off-by: Kirill A. Shutemov
---
mm/huge_memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/hug
The new helper is similar to radix_tree_maybe_preload(), but tries to
preload number of nodes required to insert (1 << order) continuous
naturally-aligned elements.
This is required to push huge pages into pagecache.
Signed-off-by: Kirill A. Shutemov
---
include/linux/radix-tree.h | 1 +
lib/r
The idea borrowed from Peter's patch from patchset on speculative page
faults[1]:
Instead of passing around the endless list of function arguments,
replace the lot with a single structure so we can change context
without endless function signature changes.
The changes are mostly mechanical with e
On Wednesday 11 May 2016 17:12:14 Nicolas Ferre wrote:
> Another regression reported by Richard yesterday and quickly fixed by Boris.
> Since this regression was introduced in 4.6-rc1 it would be great if you could
> take it before 4.6 is released.
Applied to fixes, thanks!
Arnd
khugepaged implementation grew to the point when it deserve separate
file in source.
Let's move it to mm/khugepaged.c.
Signed-off-by: Kirill A. Shutemov
---
include/linux/huge_mm.h| 10 +
include/linux/khugepaged.h |6 +
mm/Makefile|2 +-
mm/huge_memory.c
copy_page_range() has a check for "Don't copy ptes where a page fault
will fill them correctly." It works on VMA level. We still copy all page
table entries from private mappings, even if they map page cache.
We can simplify copy_huge_pmd() a bit by skipping file PMDs.
We don't map file private p
Basic scheme is the same as for anon THP.
Main differences:
- File pages are on radix-tree, so we have head->_count offset by
HPAGE_PMD_NR. The count got distributed to small pages during split.
- mapping->tree_lock prevents non-lockless access to pages under split
over radix-tree;
Splitting THP PMD is simple: just unmap it as in DAX case. This way we
can avoid memory overhead on page table allocation to deposit.
It's probably a good idea to try to allocation page table with
GFP_ATOMIC in __split_huge_pmd_locked() to avoid refaulting the area,
but clearing pmd should be good
Hi,
> Martin Sperl hat am 12. Mai 2016 um 17:28
> geschrieben:
>
>
>
> > On 12.05.2016, at 16:50, Stefan Wahren wrote:
> >
> > Hi Martin,
> >
> >> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
> >>
> >>
> >> From: Martin Sperl
> >>
> >> As the sdram clock is a critic
Le 12/05/2016 17:37, Ludovic Desroches a écrit :
> There is a macro named ATMEL_SERIAL_RINGSIZE which suggesting that it
> corresponds to the real size of the ring buffer. Let warn people that
> there is a factor of four since allocation size is
> sizeof(struct atmel_uart_char) * ATMEL_SERIAL_RINGS
Hello Nicolas,
On Thu, May 12, 2016 at 05:31:52PM +0200, Nicolas Morey-Chaisemartin wrote:
>
>
> Le 05/12/2016 à 03:52 PM, Jerome Glisse a écrit :
> > On Thu, May 12, 2016 at 03:30:24PM +0200, Nicolas Morey-Chaisemartin wrote:
> >> Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit :
> >>> On Thu,
On Thu, May 12, 2016 at 06:06:41PM +0300, Andy Shevchenko wrote:
> On Fri, 2016-05-06 at 18:17 +0300, Andy Shevchenko wrote:
> > This is combined series of two things:
> > - split out the Intel LPSS specific driver from 8250_pci into
> > 8250_lpss
> > - enable DMA support on Intel Quark UART
> >
>
> On 12.05.2016, at 16:56, Stefan Wahren wrote:
>
> Hi,
>
>> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
>>
>>
>> From: Martin Sperl
>>
>> Add the bcm2835 sdram controller to the device tree.
>>
>> Signed-off-by: Martin Sperl
>> ---
>> arch/arm/boot/dts/bcm283x.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index ab4384f..fb1c3fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3941,8 +3941,8 @@ F:Documentation/efi-stub.txt
F: arch/ia64/kernel/efi.c
F: arch/x86/boot/compressed/eboot.[ch]
F: arch/x86/include/asm/efi.h
-F: arch/x86/platform
I am announcing the release of the Linux 4.2.8-ckt10 kernel.
The updated 4.2.y-ckt tree can be found at:
git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt
linux-4.2.y
and can be browsed at:
https://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt/log/?
> On 12.05.2016, at 17:55, Stefan Wahren wrote:
>
> Hi,
>
>> Martin Sperl hat am 12. Mai 2016 um 17:28
>> geschrieben:
>>
>>
>>
>>> On 12.05.2016, at 16:50, Stefan Wahren wrote:
>>>
>>> Hi Martin,
>>>
ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
On Thu, May 12, 2016 at 03:13:46PM +0530, Kedareswara rao Appana wrote:
> This patch adds config structure in the driver to differentiate
> AXI DMA's and to add more features(clock support etc..) to these DMA's.
>
> Signed-off-by: Kedareswara rao Appana
> ---
> drivers/dma/xilinx/xilinx_vdma.c |
On Thu, May 12, 2016 at 4:06 PM, Benjamin Tissoires
wrote:
> As mentioned in drivers/platform/x86/surfacepro3_button.c, the various
> Microsoft Surface tablets do not follow the ACPI SOC buttons specification.
> They present an I2C device like this:
>
> Device (WBUT)
> {
> Method (_HID,
I am announcing the release of the Linux 3.19.8-ckt21 kernel.
The updated 3.19.y-ckt tree can be found at:
git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt
linux-3.19.y
and can be browsed at:
https://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt/lo
At elf loading in flush_old_exec() in fs/exec.c, generic code sets
current_thread_info()->addr_limit to one that corresponds aarch64 value,
and ignores compat mode there as corresponding status setup happens
later on in load_elf_binary() by SET_PERSONALITY() macro. As result,
compat task has wrong
diff --git a/MAINTAINERS b/MAINTAINERS
index 808ee80..5a9f241 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3658,8 +3658,8 @@ F:Documentation/efi-stub.txt
F: arch/ia64/kernel/efi.c
F: arch/x86/boot/compressed/eboot.[ch]
F: arch/x86/include/asm/efi.h
-F: arch/x86/platform
Hi Vinod,
> On Thu, May 12, 2016 at 03:13:46PM +0530, Kedareswara rao Appana wrote:
> > This patch adds config structure in the driver to differentiate AXI
> > DMA's and to add more features(clock support etc..) to these DMA's.
> >
> > Signed-off-by: Kedareswara rao Appana
> > ---
> > drivers/dm
Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define
the padding used for the physical memory mapping section when KASLR
memory is enabled. It ensures there is enough virtual address space when
CONFIG_MEMORY_HOTPLUG is used. The default value is 10 terabytes. If
CONFIG_MEMORY_HOTPL
Move the KASLR entropy functions in x86/libray to be used in early
kernel boot for KASLR memory randomization.
Signed-off-by: Thomas Garnier
---
Based on next-20160511
---
arch/x86/boot/compressed/kaslr.c | 77 +++---
arch/x86/include/asm/kaslr.h | 6 +++
arch/x8
Randomizes the virtual address space of kernel memory sections (physical
memory mapping, vmalloc & vmemmap) for x86_64. This security feature
mitigates exploits relying on predictable kernel addresses. These
addresses can be used to disclose the kernel modules base addresses or
corrupt specific str
This is PATCH v4 for KASLR memory implementation for x86_64.
Recent changes:
Add performance information on commit.
Add details on PUD alignment.
Add information on testing against the KASLR bypass exploit.
Rebase on next-20160511 and merge recent KASLR changes.
Integrate feedb
Minor change that allows early boot physical mapping of PUD level virtual
addresses. The current implementation expect the virtual address to be
PUD aligned. For KASLR memory randomization, we need to be able to
randomize the offset used on the PUD table.
It has no impact on current usage.
Signed
This is from a 32-bit x86 computer with 4.6-rc* and UBSAN enabled. I am
also seeing it on some other 32-bit x86 machines. This one is SMP
AthlonMP.
[ 211.406263]
[ 211.406327] UBSAN: Undefined behaviour in kernel
This is from a dual-AthlonMP 32-bit x86 system with onboard Adaptec SCSI
controller, once during bootup.
[4.896307]
[4.896471] UBSAN: Undefined behaviour in
drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31
[
On Wed, May 11, 2016 at 05:55:18PM +0800, Wanpeng Li wrote:
> From: Wanpeng Li
...
> This patch fix it by catching !DISASSOCIATED to avoid rebind bound
> workers.
>
> Cc: Tejun Heo
> Cc: Lai Jiangshan
> Cc: Thomas Gleixner
> Cc: Peter Zijlstra
> Cc: Frédéric Weisbecker
> Suggested-by: Lai J
> It's worse: before the patch series we get 'struct hv_device' (as it is
> called from core VMBus code and we simply cannot get to 'struct
> net_device' we need without traveling through 'struct
> netvsc_device'. This structure is removed and re-created by both
> netvsc_set_channels() and netvsc_
Hi
Am 12.05.2016 um 11:05 schrieb Wolfram Sang:
> Hi Thomas,
>
> On Wed, Apr 27, 2016 at 08:11:54PM +0200, Thomas Zimmermann wrote:
>> Some I2C adapters don't raise SDA by themselves when sending a bit. This
>> behavior can be seen with the DDC channel of SiS 300 graphics cards.
>
> I think you
On Tue 10-05-16 09:35:56, Vlastimil Babka wrote:
[...]
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 570383a41853..0cb09714d960 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -256,8 +256,7 @@ struct vm_area_struct;
> #define GFP_HIGHUSER (GFP_USER | __GFP_HI
This is form dual AthlonMP 32-bit x86 system with onboatrd AMD PATA
controller:
[0.550152] pata_amd :00:07.1: version 0.4.1
[0.550865] scsi host0: pata_amd
[0.550966]
[0.551124] UBSAN: Undefined
This appears on a lot of my test machines after turning on UBSAN checks.
[0.180837]
[0.181001] UBSAN: Undefined behaviour in
drivers/acpi/acpica/dsutils.c:641:16
[0.181161] index -1 is out of range for t
On Wed, May 11, 2016 at 03:42:08PM +0200, Arnd Bergmann wrote:
> The dwc_460ex SATA driver has become available on non-powerpc architectures
> and may cause randconfig build errors when CONFIG_DMADEVICES is not set
> and SATA_DWC_OLD_DMA is enabled:
>
> warning: (SATA_DWC_OLD_DMA) selects DW_DMAC_
On Thu, May 12, 2016 at 08:27:08AM -0700, David Daney wrote:
> On 05/12/2016 02:49 AM, Catalin Marinas wrote:
> >On Wed, May 11, 2016 at 05:06:13PM -0700, David Daney wrote:
> >>On 05/11/2016 03:39 AM, Catalin Marinas wrote:
> [...]
> >>>
> >>>I wonder whether you could replace the get_mpidr_in_mad
Hi,
[auto build test ERROR on next-20160512]
[cannot apply to tip/x86/core v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-boot-KASLR
* Dave Gerlach [160509 14:44]:
> Hi,
> There are several instances when one would want to execute out of on-chip
> SRAM, such as PM code on ARM platforms, so once again revisiting this
> series to allow that. Seems that having a solution for allowing SRAM to be
> mapped as executable will help cle
This will provide fully accuracy to the mapcount calculation in the
write protect faults, so page pinning will not get broken by false
positive copy-on-writes.
total_mapcount() isn't the right calculation needed in
reuse_swap_page(), so this introduces a page_trans_huge_mapcount()
that is effectiv
On Fri 13-05-16 00:09:07, Tetsuo Handa wrote:
[...]
> Michal, this version eliminated overhead of walking the process list
> when nothing is wrong. You are aware of the possibility of
> debug_show_all_locks() failing to report the culprit, aren't you?
> So, what are unacceptable major problems for
On Mon, May 09, 2016 at 04:41:49PM -0500, Dave Gerlach wrote:
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index 66a978d05958..c6eef3c98074 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -400,6 +400,20 @@ EXPORT_SYMBOL(ioremap_wc);
> * clocks that would
This is Part 1 of previous 13 XSAVES patches. Break it down to
smaller series. There are no code changes; only minor fixes in
the titles.
Fenghua Yu (3):
x86/fpu/xstate: Define and use fpu_user_xstate_size
x86/fpu/xstate: Rename xstate_size to fpu_kernel_xstate_size to
distinguish from fpu
From: Fenghua Yu
Keep init_fpstate.xsave.header.xfeatures as zero for init optimization.
This is important for init optimization that is implemented in processor.
If a bit corresponding to an xstate in xstate_bv is 0, it means the
xstate is in init status and will not be read from memory to the p
XSAVES is a kernel instruction and uses a compacted format. When working
with user space, the kernel should provide standard-format, non-supervisor
state data. We cannot do __copy_to_user() from a compacted-format kernel
xstate area to a signal frame.
Dave Hansen proposes this method to simplify c
From: Fenghua Yu
User space uses standard format xsave area. fpstate in signal frame
should have standard format size.
To explicitly distinguish between xstate size in kernel space and the
one in user space, we rename xstate_size to fpu_kernel_xstate_size.
This patch is not fixing a bug. It just
From: Fenghua Yu
The kernel xstate area can be in standard or compacted format;
it is always in standard format for user mode. When XSAVES is
enabled, the kernel uses the compacted format and it is necessary
to use a separate fpu_user_xstate_size for signal/ptrace frames.
Signed-off-by: Fenghua
* Peter Ujfalusi [160511 01:46]:
> Tony, Paul,
>
> On 04/29/16 13:53, Peter Ujfalusi wrote:
> > Hi,
> >
> > Based on the ongoing discussion on v2 (ARM: OMAP3: Fix McBSP2/3 hwmod setup
> > for
> > sidetone) I have dropped the removal of the sidetone hwmod and only
> > corrected
> > it. The seri
Le 05/12/2016 à 03:52 PM, Jerome Glisse a écrit :
> On Thu, May 12, 2016 at 03:30:24PM +0200, Nicolas Morey-Chaisemartin wrote:
>> Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit :
>>> On Thu, May 12, 2016 at 08:07:59AM +0200, Nicolas Morey-Chaisemartin wrote:
[...]
With transparent_hugepage
Hi Kefeng,
On 5/12/2016 7:46 AM, Jon Mason wrote:
On Thu, May 12, 2016 at 2:16 AM, Kefeng Wang mailto:wangkefeng.w...@huawei.com>> wrote:
On 2016/5/12 6:56, Jon Mason wrote:
> Add all of the UARTs present on NS2 and enable them in the SVK device
> tree file. Also, do some magic
I am seeing it on multiple different PC-s.
[7.837957]
[7.837959] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47
[7.837961] index -1 is out of range for type 'u32 [1]'
[7.837964] CPU:
Hi Gustavo,
On 11 May 2016 at 14:45, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add Gustavo as maintainer for the Sync File Framework. Sumit is
> co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
> tree as base.
>
> Cc: Sumit Semwal
> Signed-off-by: Gustavo Padovan
>
Sorry about that. I will fix and send a new iteration this afternoon.
Thomas
On Thu, May 12, 2016 at 9:27 AM, kbuild test robot wrote:
> Hi,
>
> [auto build test ERROR on next-20160512]
> [cannot apply to tip/x86/core v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6-rc7]
> [if your patch is appli
* Eduard Gavin [160509 07:43]:
> Dear Nishanth,
> In igepV5 the LDO7 is connected to:
> VDDA_DSIPORTA - ball AA33
> VDDA_DSIPORTC - ball AE33
> VDDA_HDMI - ball AN25
> LDO4 is connected to:
> VPP1 - ball AD9
Thanks for the info, here's an updated patch with comments and now
us
On Thu 12-05-16 13:57:45, Peter Zijlstra wrote:
[...]
> Subject: locking, rwsem: Fix down_write_killable()
> From: Peter Zijlstra
> Date: Wed, 11 May 2016 11:41:28 +0200
>
> The new signal_pending exit path in __rwsem_down_write_failed_common()
> was fingered as breaking his kernel by Tetsuo Hand
On Thu, 12 May 2016, David Howells wrote:
Mat Martineau wrote:
+ len = crypto_akcipher_maxsize(tfm);
+ info->key_size = len * 8;
+ info->max_data_size = len;
+ info->max_sig_size = len;
+ info->max_enc_size = len;
+ info->max_dec_size = len;
If len > UIN
Andrew,
do you think this should go in in the next merge window or should I
repost after rc1 is out? I do not mind one way or the other. I would
obviously would like to get them in sooner rather than later but I can
certainly live with these wait a bit longer.
Thanks!
--
Michal Hocko
SUSE Labs
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_fb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 7136e52..17c1ef0 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -360,6 +360,9 @@
On Thu, 2016-05-12 at 10:41 +0200, Jan Kara wrote:
> On Wed 11-05-16 15:08:50, Vishal Verma wrote:
> >
> > From: Christoph Hellwig
> >
> > This allows XFS to perform zeroing using the iomap infrastructure
> > and
> > avoid buffer heads.
> >
> > [vishal: fix conflicts with dax-error-handling]
>
Hi Luke,
On 12/05/16 16:34, Luke Starrett wrote:
Hi Robin,
I pulled this in to a userspace test app expecting that the __uint128_t
type might cause GCC to emit 'ldp'. Seems like that was that your
intent based on your commit note. Instead I see two 64b loads (ldr Xn),
and a single 32b load (l
Hi,
* Keerthy [160510 22:56]:
> With the device tree parsing using the regulator framework
> there is a no longer a need for separate compatibles for
> individual regulator nodes. Hence removing them all.
Please resend the dts related clean-up patches separately
once the rest of the dependencies
On Thu, May 12, 2016 at 07:38:00PM +0300, Meelis Roos wrote:
> I am seeing it on multiple different PC-s.
>
> [7.837957]
>
> [7.837959] UBSAN: Undefined behaviour in
> drivers/usb/host/ehci-hub.c:877:47
And
This patch series removes the write() interface for user access in favor of an
ioctl() based approach. This is in response to the complaint that we had
different handlers for write() and writev() doing different things and expecting
different types of data. See:
http://www.spinics.net/lists/linux-
User space consumers of hfi1 will need to know what version of the
driver they are dealing with. This becomes particularly important when
the write() interface is removed. User's will need to be able to query
the driver information but without asking the driver directly.
Add the driver's software
The HFI1_CMD_SDMA_STATUS_UPD command was never implemented it has no
reason to live in the driver. Remove it.
Reviewed-by: Christoph Hellwig
Reviewed-by: Mitko Haralanov
Reviewed-by: Ira Weiny
Signed-off-by: Dennis Dalessandro
---
drivers/staging/rdma/hfi1/file_ops.c |3 ---
include/uapi/
Add a trace message to HFI1s user IOCTL handling. This allows debugging
of which IOCTLs are being handled by the driver.
Reviewed-by: Ira Weiny
Signed-off-by: Dennis Dalessandro
---
drivers/staging/rdma/hfi1/file_ops.c |2 ++
drivers/staging/rdma/hfi1/trace.c|1 +
drivers/staging/rd
IOCTL is more suited to what user space commands need to do than the
write() interface. Add IOCTL definitions for all existing write commands
and the handling for those. The write() interface will be removed in a
follow on patch.
Reviewed-by: Mitko Haralanov
Reviewed-by: Mike Marciniszyn
Reviewe
Remove the write() handler for user space commands now that ioctl
handling is available. User apps will need to change to use ioctl from
this point forward.
Reviewed-by: Mitko Haralanov
Signed-off-by: Dennis Dalessandro
---
drivers/staging/rdma/hfi1/file_ops.c | 249 ---
On Thu, May 12, 2016 at 07:06:03PM +0300, Yury Norov wrote:
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 24ed037..fda75ce 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -138,7 +138,10 @@ typedef struct user_fpsimd_state el
Anyway, here's an actual patch with a commit message. Guenter, can you
give it a run please?
It does fix the issue here with your .config but I'd appreciate a
confirmation.
Thanks.
---
From: Borislav Petkov
down_write() calls a function to handle the slow path when the lock
is contended. B
On Thu, May 12, 2016 at 10:18:27AM -0700, Dennis Dalessandro wrote:
> There is also a driver software version being exported via a sysfs
> file. This is needed so that user space applications (psm) can
> determine if it needs to do ioctl() or write().
Why? Don't do this, just call ioctl() and if
On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote:
> + case HFI1_IOCTL_EP_INFO:
> + case HFI1_IOCTL_EP_ERASE_CHIP:
> + case HFI1_IOCTL_EP_ERASE_RANGE:
> + case HFI1_IOCTL_EP_READ_RANGE:
> + case HFI1_IOCTL_EP_WRITE_RANGE:
> + if (!capable(CAP_SYS_ADM
When configuring FPS during probe, assuming a DT node is present for
FPS, the code can run into a problem with the switch statements in
max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely,
in the case of chip->chip_id == MAX77620, it will set
fps_[mix|max]_period but then fall thr
On Thu, 12 May 2016 04:53:19 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, May 12, 2016 10:21 AM
> >
> > On Thu, 12 May 2016 01:19:44 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Alex Williamson [mailto:alex.william...@redhat
Thanks for the clarification. Below some comments.
> On Wed, 2016-05-11 at 14:54 +0200, Hector Marco-Gisbert wrote:
>>
>> El 21/04/16 a las 00:12, Kees Cook escribió:
>>> On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert >> v.es> wrote:
> On Wed, Apr 6, 2016 at 12:07 PM, Hector Marco-Gisb
On Thu, May 12, 2016 at 11:48:43AM +0530, Abhishek Sahu wrote:
> On Thu, May 12, 2016 at 12:13:47AM -0500, Andy Gross wrote:
> > On Wed, May 11, 2016 at 11:04:17PM +0530, Abhishek Sahu wrote:
> >
> >
> >
> > > > In qup_i2c_xfer and qup_i2c_xfer_v2 state is set to RESET at the
> > > >end, w
Hello,
On Thu, May 12, 2016 at 09:11:33AM +0800, Miao Xie wrote:
> >My box has 48 cores and 188GB memory, but I set
> >vm.dirty_background_bytes = 268435456
> >vm.dirty_bytes = 536870912
> >
> >if I set vm.dirty_background_bytes and vm.dirty_bytes to be a large
> >number(vm.dirty_background_bytes
Just like every other Rockhip device, the MMC "_sample" clocks should
have a shift of 0, not a shift of 1. The rk3399 TRM agrees. Presumably
these values were set to 0 because of a typo.
Things _sorta_ would have worked with the incorrect sample phase shift
because of the register layout but wou
On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote:
When configuring FPS during probe, assuming a DT node is present for
FPS, the code can run into a problem with the switch statements in
max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely,
in the case of chip->chip_id == MA
This reverts commit 7a03fe6f48f3 ("clk: rockchip: reset init state
before mmc card initialization").
Though not totally obvious from the commit message nor from the source
code, that commit appears to be trying to reset the "_drv" MMC clocks to
90 degrees (note that the "_sample" MMC clocks have a
On Thu, May 12, 2016 at 06:22:03PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 07:06:03PM +0300, Yury Norov wrote:
> > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > index 24ed037..fda75ce 100644
> > --- a/arch/arm64/include/asm/elf.h
> > +++ b/arch/arm64/i
On Thu, 12 May 2016, Wenyou Yang wrote:
> In order to get lower consumption, as a workaround, suspend
> the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> Configuration Register while OHCI USB suspending.
What does this mean? What does suspending a port do? Is it the same
as
> On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote:
> > + case HFI1_IOCTL_EP_INFO:
> > + case HFI1_IOCTL_EP_ERASE_CHIP:
> > + case HFI1_IOCTL_EP_ERASE_RANGE:
> > + case HFI1_IOCTL_EP_READ_RANGE:
> > + case HFI1_IOCTL_EP_WRITE_RANGE:
> > + if (!capable(CAP_SYS_A
ker...@martin.sperl.org writes:
> From: Martin Sperl
>
> As the sdram clock is a critical clock to the system
> the minimal bcm2835-sdram driver claims (and enables)
> this clock and also exposes the corresponding sdram
> registers via debugfs.
I don't think this is a good solution to the proble
On Thu, 12 May 2016, Yoshihiro Shimoda wrote:
> > > Alan, does USB core even know which EHCI and OHCI are linked to the same
> > > port
> > > or the handoff is software transparent?
> >
> > The core knows. It doesn't use the information for a whole lot of
> > things, but it does use it in a cou
Hi,
On Wed, May 11, 2016 at 2:40 PM, Douglas Anderson wrote:
> Historically for Rockchip devices we've relied on the power-on
> default (or perhaps the firmware setting) to get the correct drive
> phase for dw_mmc devices. This worked OK for the most part, but:
>
> * Relying on the setting just
Martin Sperl writes:
>> On 10.05.2016, at 19:37, Eric Anholt wrote:
>>
>> Martin Sperl writes:
>>> and also hsm (probably hardware security module):
>>> root@raspcm:~# cat /sys/kernel/debug/clk/hsm/regdump
>>> ctl = 0x02d6
>>> div = 0x30e0
>>> root@raspcm:~# cat /sys/kernel/debug/clk/h
Martin Sperl writes:
> On 10.05.2016, at 21:58, Martin Sperl wrote:
>>
>>
>>
>>> On 10.05.2016, at 19:37, Eric Anholt wrote:
>>>
>>> Martin Sperl writes:
>>>
> On 10.05.2016 03:01, Eric Anholt wrote:
> With the new patch 2 inserted between my previous pair, I think this
> shou
drm_framebuffer_init() uses const for the drm_framebuffer_funcs
argument so use that on drm_fb_cma_alloc() and
drm_fbdev_cma_create_with_funcs() as well.
Cc: laurent.pinch...@ideasonboard.com
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 4 ++--
include/drm/drm_fb_cma_h
This patchset adds various helpers that was originally part of the
tinydrm patchset.
Essentially it adds 2 functions:
- drm_fb_cma_create_with_funcs()
CMA backed framebuffer supporting a dirty() callback.
- drm_simple_display_pipe_init()
Plane, crtc and encoder are collapsed into one entity.
Add drm_fb_cma_create_with_funcs() for drivers that need to set the
dirty() callback.
Signed-off-by: Noralf Trønnes
Acked-by: Laurent Pinchart
---
Changes since v3:
- funcs argument should be const
Changes since v1:
- Expand docs
drivers/gpu/drm/drm_fb_cma_helper.c | 31 +
501 - 600 of 871 matches
Mail list logo
