From: laurentiu.tu...@nxp.com
Date: Thu, 30 May 2019 17:19:45 +0300
> Depends on this pull request:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
I'm not sure how you want me to handle this.
On Thu, 2019-05-30 at 14:37 -0500, Segher Boessenkool wrote:
> On Thu, May 30, 2019 at 05:09:06PM +1000, Alexey Kardashevskiy wrote:
> > so, it is sort-of nack from David and sort-of ack from Segher, what
> > happens now?
>
> Maybe what we really need just a CI call to get all properties of a
On 05/20/2019 02:25 AM, Daniel Axtens wrote:
Hi all,
As PowerNV moves towards secure boot, we need a place to put secure
variables. One option that has been canvassed is to make our secure
variables look like EFI variables. This is an early sketch of another
approach where we create a
On Thu, May 30, 2019 at 10:17:32PM +0200, Federico Vaga wrote:
> On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote:
> > Mostly due to x86 and acpi conversion, several documentation
> > links are still pointing to the old file. Fix them.
>
> For the Italian documentation I just
On 5/29/19 10:39 PM, Alexey Kardashevskiy wrote:
On 28/05/2019 17:39, Shawn Anastasio wrote:
On 5/28/19 1:27 AM, Alexey Kardashevskiy wrote:
On 28/05/2019 15:36, Oliver wrote:
On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio
wrote:
Introduce a new pcibios function
On 31/05/2019 08:49, Shawn Anastasio wrote:
> On 5/29/19 10:39 PM, Alexey Kardashevskiy wrote:
>>
>>
>> On 28/05/2019 17:39, Shawn Anastasio wrote:
>>>
>>>
>>> On 5/28/19 1:27 AM, Alexey Kardashevskiy wrote:
On 28/05/2019 15:36, Oliver wrote:
> On Tue, May 28, 2019 at 2:03 PM
On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
For the Italian documentation I just send I patch to fix them in a dedicated
patch
>
> Signed-off-by:
On Mon, May 27, 2019 at 7:12 AM David Hildenbrand wrote:
>
> Only memory to be added to the buddy and to be onlined/offlined by
> user space using /sys/devices/system/memory/... needs (and should have!)
> memory block devices.
>
> Factor out creation of memory block devices. Create all devices
On 5/30/19 1:55 AM, Sam Bobroff wrote:
On Tue, May 28, 2019 at 03:36:34PM +1000, Oliver wrote:
On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio wrote:
Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine
On Mon, May 27, 2019 at 7:12 AM David Hildenbrand wrote:
>
> By converting start and size to page granularity, we actually ignore
> unaligned parts within a page instead of properly bailing out with an
> error.
>
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: David
On Thu, May 30, 2019 at 5:09 PM David Miller wrote:
>
> From: laurentiu.tu...@nxp.com
> Date: Thu, 30 May 2019 17:19:45 +0300
>
> > Depends on this pull request:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html
>
> I'm not sure how you want me to handle this.
On Mon, May 27, 2019 at 7:12 AM David Hildenbrand wrote:
>
> We want to improve error handling while adding memory by allowing
> to use arch_remove_memory() and __remove_pages() even if
> CONFIG_MEMORY_HOTREMOVE is not set to e.g., implement something like:
>
> arch_add_memory()
>
On 5/21/19 2:24 AM, Madhavan Srinivasan wrote:
>
> On 18/05/19 7:55 PM, Claudio Carvalho wrote:
>> From: Ram Pai When the ultravisor firmware is
>> available, it takes control over the LDBAR register. In this case,
>> thread-imc updates and save/restore operations on the LDBAR register are
>>
Hi Christophe,
I tried this on the t4240rdb and it fails to boot if KASAN is
enabled. It does boot with the patch applied but KASAN disabled, so that
narrows it down a little bit.
I need to focus on 3s first so I'll just drop 3e from my patch set for
now.
Regards,
Daniel
> The KASAN shadow
On Thu, May 30, 2019 at 05:09:06PM +1000, Alexey Kardashevskiy wrote:
> so, it is sort-of nack from David and sort-of ack from Segher, what
> happens now?
Maybe what we really need just a CI call to get all properties of a node
at once? Will that speed up things enough?
That way you need no
We allocate only the first level of multilevel TCE tables for KVM
already (alloc_userspace_copy==true), and the rest is allocated on demand.
This is not enabled though for baremetal.
This removes the KVM limitation (implicit, via the alloc_userspace_copy
parameter) and always allocates just the
On 30/05/19 01:23, Mauro Carvalho Chehab wrote:
> Sphinx doesn't like orphan documents:
>
> Documentation/accelerators/ocxl.rst: WARNING: document isn't included in
> any toctree
> Documentation/arm/stm32/overview.rst: WARNING: document isn't included in
> any toctree
>
powerpc architecture (both 64-bit and 32-bit) supports stack protector
mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
add stack protector support")].
Update stackprotector arch support documentation to reflect the same.
Signed-off-by: Bhupesh Sharma
---
On Thu, May 30, 2019 at 11:25:13AM +0530, Anshuman Khandual wrote:
> Similar notify_page_fault() definitions are being used by architectures
> duplicating much of the same code. This attempts to unify them into a
> single implementation, generalize it and then move it to a common place.
>
On Wed, May 29, 2019 at 08:23:53PM -0300, Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Didn't I ack this already?
For the I2C part:
Reviewed-by:
so, it is sort-of nack from David and sort-of ack from Segher, what
happens now?
On 01/05/2019 13:42, Alexey Kardashevskiy wrote:
> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
> about 8.5sec to fetch the entire device tree via the client interface
> as the DT is
On Tue, May 28, 2019 at 03:36:34PM +1000, Oliver wrote:
> On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio wrote:
> >
> > Introduce a new pcibios function pcibios_ignore_alignment_request
> > which allows the PCI core to defer to platform-specific code to
> > determine whether or not to ignore
POWER8 and newer support a bypass mode which maps all host memory to
PCI buses so an IOMMU table is not always required. However if we fail to
create such a table, the DMA setup fails and the kernel does not boot.
This skips the 32bit DMA setup check if the bypass is can be selected.
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to 40 is usually available.
This is based on v5.2-rc2.
Please comment. Thanks.
Alexey Kardashevskiy (3):
powerpc/iommu: Allow
At the moment we create a small window only for 32bit devices, the window
maps 0..2GB of the PCI space only. For other devices we either use
a sketchy bypass or hardware bypass but the former can only work if
the amount of RAM is no bigger than the device's DMA mask and the latter
requires devices
Ping, anyone?
On 07/05/2019 16:25, Alexey Kardashevskiy wrote:
> This is an attempt to allow PCI pass through to a secure guest when
> hardware can only access insecure memory. This allows SWIOTLB use
> for passed through devices.
>
> Later on secure VMs will unsecure SWIOTLB bounce buffers for
Bhupesh Sharma writes:
> powerpc architecture (both 64-bit and 32-bit) supports stack protector
> mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
> add stack protector support")].
>
> Update stackprotector arch support documentation to reflect the same.
>
> Signed-off-by:
On Tue, May 21, 2019 at 01:34:06PM +, Christophe Leroy wrote:
> Several test failures have popped up following recent changes to crypto
> selftests.
>
> This series fixes (most of) them.
>
> The last three patches are trivial cleanups.
>
> Christophe Leroy (15):
> crypto: talitos - fix
On Thu, 30 May 2019 18:37:46 +0530
Bhupesh Sharma wrote:
> > This should probably go via the documentation tree?
> >
> > Acked-by: Michael Ellerman
>
> Thanks for the review Michael.
> I am ok with this going through the documentation tree as well.
Works for me too, but I don't seem to find
From: Laurentiu Tudor
Add an API that retrieves the 'struct device' that the specified fman
port probed against. The new API will be used in a subsequent iommu
enablement related patch.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/fman/fman_port.c
On Thu, May 30, 2019 at 6:25 PM Michael Ellerman wrote:
>
> Bhupesh Sharma writes:
> > powerpc architecture (both 64-bit and 32-bit) supports stack protector
> > mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
> > add stack protector support")].
> >
> > Update stackprotector
On Mon, May 20, 2019 at 09:42:32AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove the boilerplate license text and replace it with the equivalent
> SPDX license identifier.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/vmx/aes.c | 14 +-
>
From: Laurentiu Tudor
Enabling SMMU altered the order of device probing causing the dpaa1
ethernet driver to get probed before qbman and causing a boot crash.
Add predictability in the probing order by deferring the ethernet
driver probe after qbman and portals by using the recently introduced
On 30/05/2019 04:48, Zhen Lei wrote:
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
Since this was
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this also for scatter-gather frames
using the iova -> phys conversion function added in the
On 5/28/19 6:04 AM, Vincenzo Frascino wrote:
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
On 5/28/19 6:04 AM, Vincenzo Frascino wrote:
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
On Thu, May 30, 2019 at 05:31:15PM +0530, Anshuman Khandual wrote:
> On 05/30/2019 04:36 PM, Matthew Wilcox wrote:
> > The two handle preemption differently. Why is x86 wrong and this one
> > correct?
>
> Here it expects context to be already non-preemptible where as the proposed
> generic
On Mon, May 20, 2019 at 09:44:48AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Convert the VMX implementations of AES-CBC, AES-CTR, and AES-XTS from
> the deprecated "blkcipher" API to the "skcipher" API.
>
> As part of this, I moved the skcipher_request for the fallback algorithm
> off
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this by adding a function that does
proper iova -> phys conversions using the iommu api and
From: Laurentiu Tudor
This patch series contains several fixes in preparation for SMMU
support on NXP LS1043A and LS1046A chips. Once these get picked up,
I'll submit the actual SMMU enablement patches consisting in the
required device tree changes.
This patch series contains only part of the
On 05/30/2019 04:36 PM, Matthew Wilcox wrote:
> On Thu, May 30, 2019 at 11:25:13AM +0530, Anshuman Khandual wrote:
>> Similar notify_page_fault() definitions are being used by architectures
>> duplicating much of the same code. This attempts to unify them into a
>> single implementation,
On Mon, May 20, 2019 at 09:47:19AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> On PowerPC with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, there is sometimes
> a crash in generate_random_aead_testvec(). The problem is that the
> generated test vectors use data lengths of up to about 2 *
From: Laurentiu Tudor
The dma transactions initiator is the rx fman port so that's the device
that the dma mappings should be done. Previously the mappings were done
through the MAC device which makes no sense because it's neither dma-able
nor connected in any way to smmu.
Signed-off-by:
From: Laurentiu Tudor
liodn base registers are specific to PAMU based NXP systems and on SMMU
based ones are reserved. Don't access them if PAMU is compiled in.
Signed-off-by: Laurentiu Tudor
---
drivers/net/ethernet/freescale/fman/fman.c | 6 +-
1 file changed, 5 insertions(+), 1
Hi all,
Friendly ping:
Who can take this?
On 2019/4/24 10:17, Yue Haibing wrote:
> From: YueHaibing
>
> rtas_parse_epow_errlog() should pass 'modifier' to
> handle_system_shutdown, because event modifier only use
> bottom 4 bits.
>
> Fixes: 55fc0c561742 ("powerpc/pseries: Parse and handle
Hi Dan,
Are you ok with this patch series? If yes I can send a non-RFC version for
this series. Since we are now marking all previously created pfn_sb on
ppc64 as not supported, (pfn_sb->page_size = SZ_4K) I would like to get
this merged early.
-aneesh
"Aneesh Kumar K.V" writes:
> This
47 matches
Mail list logo
