Hi,
On Wed, Mar 27, 2019 at 01:57:50PM -0400, Sasha Levin wrote:
> From: Mike Rapoport
>
> [ Upstream commit 337555744e6e39dd1d87698c6084dd88a606d60a ]
>
> The memblock_phys_alloc_try_nid() function tries to allocate memory from
> the requested node and then falls back to allocation from any
On Wed, Mar 27, 2019 at 07:47:55AM -0500, Segher Boessenkool wrote:
> On Wed, Mar 27, 2019 at 07:40:32AM +0100, Christophe Leroy wrote:
> > Le 26/03/2019 à 23:29, Segher Boessenkool a écrit :
> > >I tried to reproduce this. It does not fail with a ppc6xx_defconfig
> > >build, and
Hi Al,
Here's a set of patches that converts a bunch (but not yet all!) to the new
mount API. To this end, it makes the following changes:
(1) Provides a convenience member in struct fs_context that is OR'd into
sb->s_iflags by sget_fc().
(2) Provides a convenience helper function,
Tyrel,
> The text of messages logged with ibmvfc_log_error() always contain the
> term "failed". In the case of cancelled commands during EH they are
> reported back by the VIOS using error codes. This can be confusing to
> somebody looking at these log messages as to whether a command was
>
Convert the spufs filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Convert the cxl filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
From: Bjorn Helgaas
> Sent: 26 March 2019 20:29
>
> On Mon, Mar 11, 2019 at 04:31:10PM +0300, Sergey Miroshnichenko wrote:
> > If a PCIe device driver doesn't yet have support for movable BARs,
> > mark device's BARs with IORESOURCE_PCI_FIXED.
>
> I'm hesitant about using IORESOURCE_PCI_FIXED
On 20.12.18 14:08, Michal Hocko wrote:
> On Thu 20-12-18 13:58:16, David Hildenbrand wrote:
>> On 30.11.18 18:59, David Hildenbrand wrote:
>>> This is the second approach, introducing more meaningful memory block
>>> types and not changing online behavior in the kernel. It is based on
>>> latest
From: Wen Yang
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR:
From: wen yang
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam
From: Wen Yang
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR:
From: Nathan Fontenot
[ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
From: wen yang
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam
From: Wen Yang
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR:
From: Nathan Fontenot
[ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
From: wen yang
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam
From: Wen Yang
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR:
From: "Aneesh Kumar K.V"
[ Upstream commit 5330367fa300742a97e20e953b1f77f48392faae ]
After we ALIGN up the address we need to make sure we didn't overflow
and resulted in zero address. In that case, we need to make sure that
the returned address is greater than mmap_min_addr.
This fixes
From: Nathan Chancellor
[ Upstream commit e7140639b1de65bba435a6bd772d134901141f86 ]
When building with -Wsometimes-uninitialized, Clang warns:
arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
From: Nathan Fontenot
[ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
From: Nicolai Stange
[ Upstream commit eddd0b332304d554ad6243942f87c2fcea98c56b ]
The ppc64 specific implementation of the reliable stacktracer,
save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
trace" whenever it finds an exception frame on the stack. Stack frames
are
From: wen yang
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam
From: Wen Yang
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR:
From: "Aneesh Kumar K.V"
[ Upstream commit 5330367fa300742a97e20e953b1f77f48392faae ]
After we ALIGN up the address we need to make sure we didn't overflow
and resulted in zero address. In that case, we need to make sure that
the returned address is greater than mmap_min_addr.
This fixes
From: Nathan Chancellor
[ Upstream commit e7140639b1de65bba435a6bd772d134901141f86 ]
When building with -Wsometimes-uninitialized, Clang warns:
arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
From: Alexey Kardashevskiy
[ Upstream commit 11f5acce2fa43b015a8120fa7620fa4efd0a2952 ]
We store 2 multilevel tables in iommu_table - one for the hardware and
one with the corresponding userspace addresses. Before allocating
the tables, the iommu_table_group_ops::get_table_size() hook returns
From: Nathan Fontenot
[ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
From: Nicolai Stange
[ Upstream commit eddd0b332304d554ad6243942f87c2fcea98c56b ]
The ppc64 specific implementation of the reliable stacktracer,
save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
trace" whenever it finds an exception frame on the stack. Stack frames
are
From: wen yang
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam
From: Breno Leitao
[ Upstream commit ebb0e13ead2ddc186a80b1b0235deeefc5a1a667 ]
'regno' is directly controlled by user space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
register number
From: Wen Yang
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR:
From: Michael Ellerman
[ Upstream commit aa7150ba378650d0e9d84b8e4d805946965a5926 ]
The recent rework of PCI kconfig symbols exposed an existing bug in
the CURRITUCK kconfig logic.
It selects PPC4xx_PCI_EXPRESS which depends on PCI, but PCI is user
selectable and might be disabled, leading to
From: "Aneesh Kumar K.V"
[ Upstream commit 5330367fa300742a97e20e953b1f77f48392faae ]
After we ALIGN up the address we need to make sure we didn't overflow
and resulted in zero address. In that case, we need to make sure that
the returned address is greater than mmap_min_addr.
This fixes
From: Nathan Chancellor
[ Upstream commit e7140639b1de65bba435a6bd772d134901141f86 ]
When building with -Wsometimes-uninitialized, Clang warns:
arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
From: Christophe Leroy
[ Upstream commit 27da80719ef132cf8c80eb406d5aeb37dddf78cc ]
The commit identified below adds MC_BTB_FLUSH macro only when
CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
on some configs (seen several times with kisskb randconfig_defconfig)
From: Alexey Kardashevskiy
[ Upstream commit 11f5acce2fa43b015a8120fa7620fa4efd0a2952 ]
We store 2 multilevel tables in iommu_table - one for the hardware and
one with the corresponding userspace addresses. Before allocating
the tables, the iommu_table_group_ops::get_table_size() hook returns
From: Dave Hansen
[ Upstream commit 5cd401ace914dc68556c6d2fcae0c349444d5f86 ]
walk_system_ram_range() can return an error code either becuase
*it* failed, or because the 'func' that it calls returned an
error. The memory hotplug does the following:
ret = walk_system_ram_range(...,
From: Mike Rapoport
[ Upstream commit 337555744e6e39dd1d87698c6084dd88a606d60a ]
The memblock_phys_alloc_try_nid() function tries to allocate memory from
the requested node and then falls back to allocation from any node in
the system. The memblock_alloc_base() fallback used by this function
On 3/26/19 11:55 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:13PM +0300, Sergey Miroshnichenko wrote:
>> When movable BARs are enabled, the PCI subsystem at first releases
>> all the bridge windows and then performs an attempt to assign new
>> requested resources and re-assign the
On 3/26/19 11:41 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:12PM +0300, Sergey Miroshnichenko wrote:
>> When the movable BARs feature is enabled, don't rely on the memory gaps
>> reserved by the BIOS/bootloader/firmware, but instead rearrange the BARs
>> and bridge windows starting
On 3/27/19 8:03 PM, David Laight wrote:
> From: Bjorn Helgaas
>> Sent: 26 March 2019 20:29
>>
>> On Mon, Mar 11, 2019 at 04:31:10PM +0300, Sergey Miroshnichenko wrote:
>>> If a PCIe device driver doesn't yet have support for movable BARs,
>>> mark device's BARs with IORESOURCE_PCI_FIXED.
>>
>> I'm
On 3/26/19 11:20 PM, Bjorn Helgaas wrote:
> [+cc Keith, Jens, Christoph, Sagi, linux-nvme, LKML]
>
> On Mon, Mar 11, 2019 at 04:31:09PM +0300, Sergey Miroshnichenko wrote:
>> Hotplugged devices can affect the existing ones by moving their BARs.
>> PCI subsystem will inform the NVME driver about
On 3/26/19 10:24 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:06PM +0300, Sergey Miroshnichenko wrote:
>> If a new PCIe device has been hot-plugged between the two active ones
>> without big enough gap between their BARs,
>
> Just to speak precisely here, a hot-added device is not
On 3/26/19 10:13 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:04PM +0300, Sergey Miroshnichenko wrote:
>> After updating the bridge window resources, the PCI_COMMAND_IO and
>> PCI_COMMAND_MEMORY bits of the bridge must be addressed as well.
>>
>> Signed-off-by: Sergey Miroshnichenko
On 3/26/19 10:00 PM, Bjorn Helgaas wrote:
> [+cc Srinath, Marta, LKML]
>
> On Mon, Mar 11, 2019 at 04:31:03PM +0300, Sergey Miroshnichenko wrote:
>> CPU0 CPU1
>>
>> pci_enable_device_mem() pci_enable_device_mem()
>>pci_enable_bridge()
On 3/27/19 5:37 PM, Cédric Le Goater wrote:
> On 3/27/19 1:36 PM, Sebastian Andrzej Siewior wrote:
>> With qemu-system-ppc64le -machine pseries -smp 4 I get:
>>
>> |# chrt 1 hackbench
>> |Running in process mode with 10 groups using 40 file descriptors each (==
>> 400 tasks)
>> |Each sender will
On 3/27/19 1:36 PM, Sebastian Andrzej Siewior wrote:
> With qemu-system-ppc64le -machine pseries -smp 4 I get:
>
> |# chrt 1 hackbench
> |Running in process mode with 10 groups using 40 file descriptors each (==
> 400 tasks)
> |Each sender will pass 100 messages of 100 bytes
> | Oops: Exception
Hi Sergey,
Since this doesn't touch drivers/pci, I assume powerpc folks will
handle this series. Let me know if otherwise.
On Mon, Mar 11, 2019 at 02:52:25PM +0300, Sergey Miroshnichenko wrote:
> This patchset allows switching from the pnv_php module to the standard
> pciehp driver for PCIe
On 3/27/2019 2:17 AM, Mathieu Malaterre wrote:
In commit cb9e4d10c448 ("[POWERPC] Add support for 750CL Holly board")
new functions were added. Since most of these functions can be made static,
make it so.
Both holly_power_off and holly_halt functions were not changed since they
are unused,
On 3/27/2019 2:17 AM, Mathieu Malaterre wrote:
Silence the following warnings triggered using W=1:
arch/powerpc/platforms/embedded6xx/holly.c:236:6: error: no previous
prototype for 'holly_power_off' [-Werror=missing-prototypes]
arch/powerpc/platforms/embedded6xx/holly.c:243:6: error:
With qemu-system-ppc64le -machine pseries -smp 4 I get:
|# chrt 1 hackbench
|Running in process mode with 10 groups using 40 file descriptors each (== 400
tasks)
|Each sender will pass 100 messages of 100 bytes
| Oops: Exception in kernel mode, sig: 4 [#1]
| LE PAGE_SIZE=64K MMU=Hash PREEMPT
On 03/27/2019 11:05 AM, Aneesh Kumar K.V wrote:
Alexandre Ghiti writes:
On 03/27/2019 09:55 AM, Aneesh Kumar K.V wrote:
On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
.
This is now
#define
The patch
ASoC: fsl_audmix: Fix kbuild failure
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
On Wed, Mar 27, 2019 at 07:40:32AM +0100, Christophe Leroy wrote:
> Le 26/03/2019 à 23:29, Segher Boessenkool a écrit :
> >I tried to reproduce this. It does not fail with a ppc6xx_defconfig
> >build, and mpc885_ads_defconfig fails with
>
> So far, the only defconfig which fails for me is
On Wed, Mar 27, 2019 at 03:29:55PM +1100, Michael Ellerman wrote:
> Mark Brown writes:
> > Hrm, seems PowerPC is still not using the common clock API - is there
> > any plan for that? There are some ASoC PowerPC uses so it's going to be
> > a bit of an issue as we expand our use of the clock
Joe Perches writes:
> A file pattern line in this section of the MAINTAINERS file in linux-next
> does not have a match in the linux source files.
>
> This could occur because a matching filename was never added, was deleted
> or renamed in some other commit.
I think it was removed before the
Mahesh J Salgaonkar writes:
> From: Mahesh Salgaonkar
>
> On pseries, TLB multihit are reported as D-Cache Multihit. This is because
> the wrongly populated mc_err_types[] array. Per PAPR, TLB error type is 0x04
> and mc_err_types[4] points to "D-Cache" instead of "TLB" string. Fixup the
>
Alexandre Ghiti writes:
> On 03/27/2019 09:55 AM, Aneesh Kumar K.V wrote:
>> On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
>>>
>>>
>>> On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
>
.
>>
>> This is now
>> #define
On 03/27/2019 09:55 AM, Aneesh Kumar K.V wrote:
On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
On systems without CONTIG_ALLOC activated but that support gigantic
pages,
boottime reserved gigantic pages
The format in dev_dbg function must be a constant.
Signed-off-by: Viorel Suman
---
sound/soc/fsl/fsl_audmix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
index 3356cb6..dabde03 100644
---
Le 27/03/2019 à 09:56, Christophe Leroy a écrit :
Le 26/03/2019 à 21:12, Segher Boessenkool a écrit :
On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote:
Le 26/03/2019 à 19:19, Segher Boessenkool a écrit :
On Tue, Mar 26, 2019 at 07:55:33AM +, Christophe Leroy wrote:
Le 26/03/2019 à 21:12, Segher Boessenkool a écrit :
On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote:
Le 26/03/2019 à 19:19, Segher Boessenkool a écrit :
On Tue, Mar 26, 2019 at 07:55:33AM +, Christophe Leroy wrote:
STACK off0x vaddr 0x paddr
On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
On systems without CONTIG_ALLOC activated but that support gigantic
pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply
On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
On systems without CONTIG_ALLOC activated but that support gigantic
pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages
On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
On systems without CONTIG_ALLOC activated but that support gigantic pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages to memory
allocator.
Signed-off-by: Alexandre Ghiti
On systems without CONTIG_ALLOC activated but that support gigantic pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages to memory
allocator.
Signed-off-by: Alexandre Ghiti
Acked-by: David S. Miller [sparc]
---
This series fixes sh and sparc that did not advertise their gigantic page
support and then were not able to allocate and free those pages at runtime.
It renames MEMORY_ISOLATION && COMPACTION || CMA condition into the more
accurate CONTIG_ALLOC, since it allows the
Le 26/03/2019 à 23:29, Segher Boessenkool a écrit :
On Tue, Mar 26, 2019 at 03:12:31PM -0500, Segher Boessenkool wrote:
On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote:
Le 26/03/2019 à 19:19, Segher Boessenkool a écrit :
On Tue, Mar 26, 2019 at 07:55:33AM +,
This condition allows to define alloc_contig_range, so simplify
it into a more accurate naming.
Suggested-by: Vlastimil Babka
Signed-off-by: Alexandre Ghiti
Acked-by: Vlastimil Babka
---
arch/arm64/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
sparc actually supports gigantic pages and selecting
ARCH_HAS_GIGANTIC_PAGE allows it to allocate and free
gigantic pages at runtime.
sparc allows configuration such as huge pages of 16GB,
pages of 8KB and MAX_ORDER = 13 (default):
HPAGE_SHIFT (34) - PAGE_SHIFT (13) = 21 >= MAX_ORDER (13)
sh actually supports gigantic pages and selecting
ARCH_HAS_GIGANTIC_PAGE allows it to allocate and free
gigantic pages at runtime.
At least sdk7786_defconfig exposes such a configuration with
huge pages of 64MB, pages of 4KB and MAX_ORDER = 11:
HPAGE_SHIFT (26) - PAGE_SHIFT (12) = 14 >= MAX_ORDER
Joe Lawrence's on March 27, 2019 3:33 am:
> On Tue, Mar 26, 2019 at 02:29:47PM +0900, Masahiro Yamada wrote:
>> On Tue, Mar 26, 2019 at 1:05 AM Joe Lawrence wrote:
>> >
>> > CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
>> > findstring.
>> >
>> > For example, commit
Alastair D'Silva's on March 27, 2019 2:37 pm:
> On Tue, 2019-03-26 at 15:58 +1000, Nicholas Piggin wrote:
>> Alastair D'Silva's on March 14, 2019 12:31 pm:
>> > From: Alastair D'Silva
>> >
>> > When building an LTO kernel, the existing code generates warnings:
>> >
73 matches
Mail list logo
