Le 29/01/2020 à 08:14, Thomas Gleixner a écrit :
Andy Lutomirski writes:
On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote:
Andy Lutomirski writes:
On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
assume the
Andy Lutomirski writes:
> On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote:
>>
>> Andy Lutomirski writes:
>> > On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
>> >
>> > Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
>> > assume the shift is less than 32? That
On Thu, 2020-01-23 at 01:04:55 UTC, Sukadev Bhattiprolu wrote:
> >From 72a7497a8673c93a4b80aa4fc38b88a8e90aa650 Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Wed, 22 Jan 2020 18:57:18 -0600
> Subject: [PATCH 1/1] powerpc/xmon: Fix compile error in print_insn* functions
>
> Fix
On Thu, 2020-01-23 at 17:30:47 UTC, Christophe Leroy wrote:
> Instead of opencoding, use probe_user_read() to failessly read
> a user location and probe_user_write() for writing to user.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
On Wed, 2020-01-22 at 15:51:40 UTC, Vaibhav Jain wrote:
> String 'bus_desc.provider_name' allocated inside
> papr_scm_nvdimm_init() will leaks in case call to
> nvdimm_bus_register() fails or when papr_scm_remove() is called.
>
> This minor patch ensures that 'bus_desc.provider_name' is freed in
On Mon, 2020-01-20 at 22:10:02 UTC, Tyrel Datwyler wrote:
> From: Tyrel Datwyler
>
> Commit e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to
> iommu_table") missed an iommu_table allocation in the pseries vio code.
> The iommu_table is allocated with kzalloc and as a result the
On Wed, 2020-01-22 at 03:11:25 UTC, Oliver O'Halloran wrote:
> Some newer cards supported by aacraid can take up to 40s to recover
> after an EEH event. This causes spurious failures in the basic EEH
> self-test since the current maximim timeout is only 30s.
>
> Fix the immediate issue by bumping
On Tue, 2020-01-14 at 17:54:00 UTC, Christophe Leroy wrote:
> Add support of KASAN_VMALLOC on PPC32.
>
> To allow this, the early shadow covering the VMALLOC space
> need to be removed once high_memory var is set and before
> freeing memblock.
>
> And the VMALLOC area need to be aligned such
On Tue, 2020-01-21 at 01:31:53 UTC, Chen Zhou wrote:
> Fixes coccicheck warning:
> ./arch/powerpc/platforms/maple/setup.c:232:15-16:
> WARNING comparing pointer to 0
>
> Compare pointer-typed values to NULL rather than 0.
>
> Signed-off-by: Chen Zhou
Applied to powerpc next, thanks.
On Wed, 2020-01-15 at 14:53:59 UTC, Michael Bringmann wrote:
> Correct overflow problem in calculation+display of Maximum Memory
> value to syscfg where 32bits is insufficient.
>
> Signed-off-by: Michael Bringmann
Applied to powerpc next, thanks.
On Tue, 2020-01-14 at 11:00:25 UTC, Laurentiu Tudor wrote:
> Michael Ellerman made a call for volunteers from NXP to maintain
> this driver and I offered myself.
>
> Signed-off-by: Laurentiu Tudor
Applied to powerpc next, thanks.
On Tue, 2020-01-14 at 07:14:40 UTC, Christophe Leroy wrote:
> Selecting CONFIG_PPC_DEBUG_WX only impacts ptdump and pgtable_32/64
> init calls. Declaring related functions in asm/pgtable.h implies
> rebuilding almost everything.
>
> Move ptdump_check_wx() declaration in mm/mmu_decl.h
>
>
On Tue, 2020-01-14 at 08:13:10 UTC, Christophe Leroy wrote:
> ptdump_check_wx() is called from mark_rodata_ro() which only exists
> when CONFIG_STRICT_KERNEL_RWX is selected.
>
> Signed-off-by: Christophe Leroy
> Fixes: 453d87f6a8ae ("powerpc/mm: Warn if W+X pages found on boot")
Applied to
On Tue, 2020-01-14 at 08:13:09 UTC, Christophe Leroy wrote:
> Verification cannot rely on simple bit checking because on some
> platforms PAGE_RW is 0, checking that a page is not W means
> checking that PAGE_RO is set instead of checking that PAGE_RW
> is not set.
>
> Use pte helpers instead of
On Tue, 2020-01-14 at 08:13:08 UTC, Christophe Leroy wrote:
> ptdump_check_wx() also have to be called when pages are mapped
> by blocks.
>
> Signed-off-by: Christophe Leroy
> Fixes: 453d87f6a8ae ("powerpc/mm: Warn if W+X pages found on boot")
Applied to powerpc next, thanks.
On Fri, 2020-01-10 at 07:02:03 UTC, Oliver O'Halloran wrote:
> pcibios_bus_add_device() is the only caller of pcibios_setup_device().
> Fold them together since there's no real reason to keep them separate.
>
> Signed-off-by: Oliver O'Halloran
Series applied to powerpc next, thanks.
On Wed, 2020-01-08 at 06:46:47 UTC, "Aneesh Kumar K.V" wrote:
> Setting ND_REGION_PAGEMAP flag implies namespace mode defaults to fsdax mode.
> This also means kernel ends up creating struct page backing for these namspace
> ranges. With large namespaces that is not the right thing to do. We
>
On Fri, 2020-01-10 at 04:54:02 UTC, Pingfan Liu wrote:
> In lmb_is_removable(), if a section is not present, it should continue to
> test the rest sections in the block. But the current code fails to do so.
>
> Signed-off-by: Pingfan Liu
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc:
On Tue, 2020-01-07 at 02:16:33 UTC, Sukadev Bhattiprolu wrote:
> >From 91a77dbea3c909ff15c66cded37f1334304a293d Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Mon, 6 Jan 2020 13:50:02 -0600
> Subject: [PATCH 1/1] powerpc/xmon: don't access ASDR in VMs
>
> ASDR is HV-privileged and
On Mon, 2020-01-06 at 04:29:53 UTC, yingjie_...@126.com wrote:
> From: Bai Yingjie
>
> When CONFIG_RELOCATABLE=y is set, VIRT_PHYS_OFFSET is a 64bit variable,
> thus __pa() returns as 64bit value.
> But when CONFIG_RELOCATABLE=n, __pa() returns 32bit value.
>
> When CONFIG_PHYS_64BIT is set,
On Wed, 2020-01-01 at 17:49:50 UTC, Julia Lawall wrote:
> Use resource_size rather than a verbose computation on
> the end and start fields.
>
> The semantic patch that makes these changes is as follows:
> (http://coccinelle.lip6.fr/)
>
>
> @@ struct resource ptr; @@
> - (ptr.end - ptr.start +
On Wed, 2020-01-01 at 17:49:45 UTC, Julia Lawall wrote:
> Use resource_size rather than a verbose computation on
> the end and start fields.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
>
> @@ struct resource ptr; @@
> - (ptr.end - ptr.start + 1)
On Sun, 2019-12-29 at 15:42:55 UTC, Julia Lawall wrote:
> Mmgrab was introduced in commit f1f1007644ff ("mm: add new mmgrab()
> helper") and most of the kernel was updated to use it. Update a
> remaining file.
>
> The semantic patch that makes this change is as follows:
>
On Wed, 2020-01-01 at 07:43:27 UTC, Julia Lawall wrote:
> The mpic_ipi_chip and mpic_irq_ht_chip structures are only copied
> into other structures, so make them const.
>
> The opportunity for this change was found using Coccinelle.
>
> Signed-off-by: Julia Lawall
Applied to powerpc next,
On Mon, 2019-12-23 at 07:54:22 UTC, Christophe Leroy wrote:
> Running vdsotest leaves many times the following log:
>
> [ 79.629901] vdsotest[396]: User access of kernel address () -
> exploit attempt? (uid: 0)
>
> A pointer set to (-1) is likely a programming error similar to
> a
On Tue, 2019-12-24 at 06:41:25 UTC, Russell Currey wrote:
> With STRICT_KERNEL_RWX on in a relocatable kernel under the hash MMU, if
> the position the kernel is loaded at is not 16M aligned, the kernel
> miscalculates its ALIGN*()s and things go horribly wrong.
>
> We can easily avoid this when
On Sat, 2019-12-21 at 08:32:22 UTC, Christophe Leroy wrote:
> On PPC32, MTMSRD() is simply defined as mtmsr.
>
> Replace MTMSRD(reg) by mtmsr reg in files dedicated to PPC32,
> this makes the code less obscure.
>
> Signed-off-by: Christophe Leroy
Series applied to powerpc next, thanks.
On Fri, 2019-12-06 at 03:17:22 UTC, Jordan Niethe wrote:
> Commit a25bd72badfa ("powerpc/mm/radix: Workaround prefetch issue with
> KVM") introduced a number of workarounds as coming out of a guest with
> the mmu enabled would make the cpu would start running in hypervisor
> state with the PID
On Mon, 2019-12-02 at 07:57:27 UTC, Christophe Leroy wrote:
> Commit 18ad51dd342a ("powerpc: Add VDSO version of getcpu") added
> getcpu() for PPC64 only, by making use of a user readable general
> purpose SPR.
>
> PPC32 doesn't have any such SPR.
>
> For non SMP, just return CPU id 0 from the
On Thu, 2019-11-28 at 12:16:35 UTC, Christophe Leroy wrote:
> Since commit 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO
> descriptors"), the prefered way to define chipselect GPIOs is using
> 'cs-gpios' property instead of the legacy 'gpios' property.
>
> Signed-off-by: Christophe Leroy
On Tue, 2019-11-26 at 13:16:50 UTC, Christophe Leroy wrote:
> When not using large TLBs, the IMMR region is still
> mapped as a whole block in the FIXMAP area.
>
> Properly report that the IMMR region is block-mapped even
> when not using large TLBs.
>
> Signed-off-by: Christophe Leroy
Applied
On Tue, 2019-11-26 at 17:43:29 UTC, Christophe Leroy wrote:
> Unlike standard powerpc, Powerpc 8xx doesn't have SPRN_DABR, but
> it has a breakpoint support based on a set of comparators which
> allow more flexibility.
>
> Commit 4ad8622dc548 ("powerpc/8xx: Implement hw_breakpoint")
> implemented
On Wed, 2019-11-20 at 13:41:15 UTC, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski
Applied to powerpc next, thanks.
On Thu, 2019-11-21 at 13:49:08 UTC, Frederic Barrat wrote:
> The pci_dn structure used to store a pointer to the struct pci_dev, so
> taking a reference on the device was required. However, the pci_dev
> pointer was later removed from the pci_dn structure, but the reference
> was kept for the npu
On Fri, 2019-11-15 at 18:10:58 UTC, Greg Kurz wrote:
> As reported by ./scripts/checkpatch.pl --strict:
>
> CHECK: extern prototypes should be avoided in .h files
>
> Signed-off-by: Greg Kurz
Applied to powerpc next, thanks.
On Fri, 2019-11-01 at 06:26:10 UTC, Oliver O'Halloran wrote:
> Originally we only had a handful of exported memory ranges, but we'd to
> export the per-core trace buffers. This results in a lot of files in the
> exports directory which is a but unfortunate. We can clean things up a bit
> by
On Fri, 2019-11-01 at 08:55:21 UTC, Oliver O'Halloran wrote:
> On PowerNV a few different kinds of reboot are supported. We'd like to be
> able to exercise these from xmon so allow 'zr' to take an argument, and
> pass that to the ppc_md.restart() function.
>
> Signed-off-by: Oliver O'Halloran
On Thu, 2019-09-12 at 05:29:43 UTC, Oliver O'Halloran wrote:
> Use the pnv_phb structure as the private data pointer for the debugfs
> files. This lets us delete some code and an open-coded use of
> hose->private_data.
>
> Signed-off-by: Oliver O'Halloran
Series applied to powerpc next,
On Wed, 2019-10-16 at 01:25:36 UTC, Oliver O'Halloran wrote:
> Many drivers don't check for errors when they get a 0xFFs response from an
> MMIO load. As a result after an EEH event occurs a driver can get stuck in
> a polling loop unless it some kind of internal timeout logic.
>
> Currently EEH
On Wed, 2019-08-21 at 06:26:53 UTC, Oliver O'Halloran wrote:
> When disabling virtual functions on an SR-IOV adapter we currently do not
> correctly remove the EEH state for the now-dead virtual functions. When
> removing the pci_dn that was created for the VF when SR-IOV was enabled
> we free the
On Thu, 2019-07-11 at 02:24:03 UTC, Nicholas Piggin wrote:
> This implements the tricky tracing and soft irq handling bits in C,
> leaving the low level bit to asm.
>
> A functional difference is that this redirects the interrupt exit to
> a return stub to execute blr, rather than the lr address
On Mon, 2019-07-15 at 08:56:08 UTC, Oliver O'Halloran wrote:
> At the point where we start inserting ranges into the EEH address cache the
> binding between pci_dev and eeh_dev has already been set up. Instead of
> consulting the pci_dn tree we can retrieve the eeh_dev directly using
>
On Wed, 2019-07-03 at 22:03:19 UTC, Greg Kurz wrote:
> Cc: triv...@kernel.org
> Signed-off-by: Greg Kurz
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6a3163212f311daaf2ca3b676db2e11cfd81c6b3
cheers
Adhemerval Zanella's on January 29, 2020 3:26 am:
>
>
> On 28/01/2020 11:05, Nicholas Piggin wrote:
>> Florian Weimer's on January 28, 2020 11:09 pm:
>>> * Nicholas Piggin:
>>>
* Proposal is for PPC_FEATURE2_SCV to indicate 'scv 0' support, all other
vectors will return -ENOSYS, and
Florian Weimer's on January 29, 2020 1:58 am:
> * Nicholas Piggin:
>
>> That gets the LR save/restore right when we're also using r0.
>
> Yes, I agree it looks good. Nice.
>
>>> But the kernel uses the -errno convention internally, so I think it
>>> would make sense to pass this to userspace
(-)
--- linux-next-20200128.orig/arch/powerpc/Kconfig
+++ linux-next-20200128/arch/powerpc/Kconfig
@@ -478,7 +478,7 @@ config MPROFILE_KERNEL
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && (PPC_PSERIES || \
- PPC_P
Joel Stanley writes:
> On Tue, 21 Jan 2020 at 04:30, Michael Ellerman wrote:
>>
>> From: Joel Stanley
>>
>> This turns on HARDENED_USERCOPY with HARDENED_USERCOPY_PAGESPAN, and
>> FORTIFY_SOURCE.
>>
>> It also enables SECURITY_LOCKDOWN_LSM with _EARLY and
>> LOCK_DOWN_KERNEL_FORCE_INTEGRITY
Scott Cheloha writes:
> LMB lookup is currently an O(n) linear search. This scales poorly when
> there are many LMBs.
>
> If we cache each LMB by both its base address and its DRC index
> in an xarray we can cut lookups to O(log n), greatly accelerating
> drmem initialization and memory hotplug.
LMB lookup is currently an O(n) linear search. This scales poorly when
there are many LMBs.
If we cache each LMB by both its base address and its DRC index
in an xarray we can cut lookups to O(log n), greatly accelerating
drmem initialization and memory hotplug.
This patch introduces two
On Tue, 28 Jan 2020, Florian Weimer wrote:
> I don't think we can save LR in a regular register around the system
> call, explicitly in the inline asm statement, because we still have to
> generate proper unwinding information using CFI directives, something
> that you cannot do from within the
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring via kprobes and uprobes and eBPF tracing for
> CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
> capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
> chances to misuse the
On Tue, 28 Jan 2020, Alexey Budankov wrote:
> Signed-off-by: Alexey Budankov
> ---
> arch/powerpc/perf/imc-pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index cb50a9e1fd2d..e837717492e4 100644
>
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Signed-off-by: Alexey Budankov
> ---
> kernel/trace/bpf_trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index e5ef4ae9edb5..334f1d71ebb1 100644
> ---
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Signed-off-by: Alexey Budankov
> ---
> include/linux/capability.h | 4
> include/uapi/linux/capability.h | 8 +++-
> security/selinux/include/classmap.h | 4 ++--
> 3 files changed, 13 insertions(+), 3 deletions(-)
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_PERFMON privileged process. Providing
> the access under CAP_PERFMON capability singly, without the rest of
> CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials and
> makes operation more secure.
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation more secure.
On Tue, 28 Jan 2020, Alexey Budankov wrote:
>
> Open access to monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation more secure.
On Tue, Jan 28, 2020 at 05:04:49PM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
>
> >> > I don't think we can save LR in a regular register around the system
> >> > call, explicitly in the inline asm statement, because we still have to
> >> > generate proper unwinding information using
> On Jan 28, 2020, at 12:47 PM, Catalin Marinas wrote:
>
> The primary goal here is not finding regressions but having clearly
> defined semantics of the page table accessors across architectures. x86
> and arm64 are a good starting point and other architectures will be
> enabled as they are
On Mon, Jan 27, 2020 at 09:11:53PM -0500, Qian Cai wrote:
> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
> wrote:
> > This adds tests which will validate architecture page table helpers and
> > other accessors in their compliance with expected generic MM semantics.
> > This will help various
On 28/01/2020 11:05, Nicholas Piggin wrote:
> Florian Weimer's on January 28, 2020 11:09 pm:
>> * Nicholas Piggin:
>>
>>> * Proposal is for PPC_FEATURE2_SCV to indicate 'scv 0' support, all other
>>> vectors will return -ENOSYS, and the decision for how to add support for
>>> a new vector
On 1/27/20 7:33 PM, Qian Cai wrote:
>
>>> What’s the value of this block of new code? It only supports x86 and arm64
>>> which are supposed to be good now.
>> We have been over the usefulness of this code many times before as the patch
>> is
>> already in it's V12. Currently it is enabled on
Le 28/01/2020 à 02:27, Anshuman Khandual a écrit :
This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or
* Segher Boessenkool:
>> > I don't think we can save LR in a regular register around the system
>> > call, explicitly in the inline asm statement, because we still have to
>> > generate proper unwinding information using CFI directives, something
>> > that you cannot do from within the asm
* Nicholas Piggin:
> That gets the LR save/restore right when we're also using r0.
Yes, I agree it looks good. Nice.
>> But the kernel uses the -errno convention internally, so I think it
>> would make sense to pass this to userspace and not convert back and
>> forth. This would align with
On Wed, Jan 29, 2020 at 12:05:40AM +1000, Nicholas Piggin wrote:
> Florian Weimer's on January 28, 2020 11:09 pm:
> > But I don't think we are so lucky for the inline system calls. GCC
> > recognizes an "lr" clobber with inline asm (even though it is not
> > documented), but it generates rather
On 28 January 2020 at 3:16 pm, Rob Herring wrote:
On Tue, Jan 28, 2020 at 2:01 AM Christian Zigotzky
wrote:
Hi All,
Which mailing list is responsible for the pata_pcmcia driver? We are
using new SanDisk High (>8G) CF cards with this driver [1] and we need
the following line in the file
On Sun, 26 Jan 2020 22:52:47 +1100, Michael Ellerman wrote:
> There's an OF helper called of_dma_is_coherent(), which checks if a
> device has a "dma-coherent" property to see if the device is coherent
> for DMA.
>
> But on some platforms devices are coherent by default, and on some
> platforms
From: Ravi Bangoria
[ Upstream commit 913a90bc5a3a06b1f04c337320e9aeee2328dd77 ]
perf_event_open() limits the sample_period to 63 bits. See:
0819b2e30ccb ("perf: Limit perf_event_attr::sample_period to 63 bits")
Make ioctl() consistent with it.
Also on PowerPC, negative sample_period could
On Tue, Jan 28, 2020 at 2:01 AM Christian Zigotzky
wrote:
>
> Hi All,
>
> Which mailing list is responsible for the pata_pcmcia driver? We are
> using new SanDisk High (>8G) CF cards with this driver [1] and we need
> the following line in the file "drivers/ata/pata_pcmcia.c".
>
> +
Florian Weimer's on January 28, 2020 11:09 pm:
> * Nicholas Piggin:
>
>> * Proposal is for PPC_FEATURE2_SCV to indicate 'scv 0' support, all other
>> vectors will return -ENOSYS, and the decision for how to add support for
>> a new vector deferred until we see the next user.
>
> Seems
* Nicholas Piggin:
> * Proposal is for PPC_FEATURE2_SCV to indicate 'scv 0' support, all other
> vectors will return -ENOSYS, and the decision for how to add support for
> a new vector deferred until we see the next user.
Seems reasonable. We don't have to decide this today.
> * Proposal
> On Jan 28, 2020, at 7:10 AM, Mike Rapoport wrote:
>
> Aren't x86 and arm64 not decent enough?
> Even if this test could be used to detect regressions only on these two
> platforms, the test is valuable.
The question is does it detect regressions good enough? Where is the list of
past bugs
Hello Qian,
On Mon, Jan 27, 2020 at 10:33:08PM -0500, Qian Cai wrote:
>
> > On Jan 27, 2020, at 10:06 PM, Anshuman Khandual
> > wrote:
> >
> > enablement of this test (for the moment) but then the goal is to integrate
> > all
> > of them going forward. The test not only validates platform's
On Tue, Jan 28, 2020 at 02:12:56AM -0500, Qian Cai wrote:
> > On Jan 28, 2020, at 1:13 AM, Christophe Leroy
> > wrote:
> > ppc32 an indecent / legacy platform ? Are you kidying ?
> > Powerquicc II PRO for instance is fully supported by the
> > manufacturer and widely used in many small
Christian Zigotzky writes:
> On 24 January 2020 at 12:42 pm, Michael Ellerman wrote:
>> Ulf Hansson writes:
>>> On Thu, 16 Jan 2020 at 12:18, Christian Zigotzky
>>> wrote:
Hi All,
We still need the attached patch for our onboard SD card interface
[1,2]. Could you please add
I would like to enable support for the scv instruction to provide the Linux
system calls.
This requires two things to be defined, firstly how to advertise support
for scv and how to allocate and advertise support for individual scv
vectors. Secondly, how to define a Linux system call ABI with
Hello Nathan,
On Thu 23-01-20 09:56:10, Nathan Lynch wrote:
> Libor Pechacek writes:
> > In KVM guests drmem structure is only zero initialized. Trying to
> > manipulate DLPAR parameters results in a crash in this environment.
>
> I think this statement needs qualification. Unless I'm mistaken,
On Tue, Jan 28, 2020 at 10:41:02AM +1000, Nicholas Piggin wrote:
> Michal Suchánek's on January 28, 2020 4:08 am:
> > On Tue, Jan 28, 2020 at 12:17:12AM +1000, Nicholas Piggin wrote:
> >> This incremental patch fixes several soft-mask debug and unsafe
> >> smp_processor_id messages due to tracing
Hi Dave,
On 27/01/20 9:12 pm, Dave Hansen wrote:
>
> How have you tested this patch (and the whole series for that matter)?
>
I replaced the second patch with this one and did a build test.
Till v16, I had tested the whole series (build + run) on both a POWER8
system (with 4K and 64K page
On 22/01/2020 18.52, Rasmus Villemoes wrote:
> I'm building for a ppc32 (mpc8309) target using Yocto, and I'm hitting a
> very hard to debug problem that maybe someone else has encountered. This
> doesn't happen always, perhaps 1 in 8 times or something like that.
>
> The issue is that when the
On Tue, Jan 28, 2020 at 08:58:29AM +0100, Christian Zigotzky wrote:
> Hi All,
>
> Which mailing list is responsible for the pata_pcmcia driver? We are using
> new SanDisk High (>8G) CF cards with this driver [1] and we need the
> following line in the file "drivers/ata/pata_pcmcia.c".
>
> +
Hi All,
Which mailing list is responsible for the pata_pcmcia driver? We are
using new SanDisk High (>8G) CF cards with this driver [1] and we need
the following line in the file "drivers/ata/pata_pcmcia.c".
+ PCMCIA_DEVICE_MANF_CARD(0x00f1, 0x0101), /* SanDisk High
(>8G) CFA */
83 matches
Mail list logo
