> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index e32ef3f01fe8..b13b1cbcac29 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1785,7 +1785,7 @@ static int i801_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
>
Em Wed, 09 Sep 2020 13:06:39 -0700
Joe Perches escreveu:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is b
At some point in the distant past we only supported EEH on pseries. The
various EEH RTAS call use the "PE config address" as a handle to the PE
being manipulated so we need to find that address a PE.
There's three ways to determine the address of a PE starting from a device
inside of that PE: The
There's no real reason why zero can't be a valid PE configuration address.
Under qemu each sPAPR PHB (i.e. EEH supporting) has the passed-though
devices on bus zero, so the PE address of bus :00 should be zero.
However, all previous versions of Linux will reject that, so Qemu at least
goes out of
The process Linux uses for determining if a device supports EEH or not
appears to be at odds with what PAPR+ says the OS should be doing. The
current flow is something like:
1. Assume pe_config_addr is equal the the device's config_addr.
2. Attempt to enable EEH on that PE
3. Verify EEH was enable
De-duplicate, and fix up the comments, and make the prototype just take a
pci_dn since the job of the function is to return the pe_config_addr of the
PE which contains a given device.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 80 +++-
1 f
The initialisation of EEH mostly happens in a core_initcall_sync initcall,
followed by registering a bus notifier later on in an arch_initcall.
Anything involving initcall dependecies is mostly incomprehensible unless
you've spent a while staring at code so here's the full sequence:
ppc_md.setup_a
No longer used since the platforms perform their EEH initialisation before
calling eeh_init().
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/include/asm/eeh.h | 1 -
arch/powerpc/kernel/eeh.c | 8
2 files changed, 9 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/ar
Fold pseries_eeh_init() into eeh_pseries_init() rather than having
eeh_init() call it via eeh_ops->init(). It's simpler and it'll let us
delete eeh_ops.init.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 155 +--
1 file changed, 71 insertions
Fold pnv_eeh_init() into eeh_powernv_init() rather than having eeh_init()
call it via eeh_ops->init(). It's simpler and it'll let us delete
eeh_ops.init.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 94 ++--
1 file changed, 45 insertions(+),
Drop the EEH register / unregister ops thing and have the platform pass the
ops structure into eeh_init() directly. This takes one initcall out of the
EEH setup path and it means we're only doing EEH setup on the platforms
which actually support it. It's also less code and generally easier to
follo
This is really two series joined together since they end up conflicting
with each other lighty slightly and I figured this is easier for all
involved.
Patches 1-5 streamline how the generic and platform specfic parts of EEH
are initialised at boot so more of the setup process happens in linear cod
Jing,
> Fix to return error code PTR_ERR() from the error handling case instead
> of 0.
Applied to 5.10/scsi-staging. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
randconfig-a004-20200909
x86_64 randconfig-a006-20200909
x86_64 randconfig-a003-20200909
x86_64 randconfig-a001-20200909
x86_64 randconfig-a005-20200909
x86_64 randconfig-a002-20200909
i386
defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20200909
x86_64 randconfig-a006-20200909
x86_64 randconfig
lmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20200909
x86_64 randconfig-a006-20200
On Wed, 2020-09-09 at 19:36 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> >
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label is
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
> index eea0f453cfb6..8aac5bc60f4c 100644
> --- a/crypto/tcrypt.c
> +++ b/crypto/tcrypt.c
> @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32 mask,
> int m, u32 num_m
On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool
wrote:
>
> It will not work like this in GCC, no. The LLVM people know about that.
> I do not know why they insist on pushing this, being incompatible and
> everything.
Umm. Since they'd be the ones supporting this, *gcc* would be the
incompatib
On 9/9/20 15:06, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
>
> Found usi
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep-2.5.4 -rP --include=*.[ch] -n
"fallthrou
On 9/7/20 1:39 AM, Jing Xiangfeng wrote:
> Fix to return error code PTR_ERR() from the error handling case instead
> of 0.
>
> Signed-off-by: Jing Xiangfeng
Acked-by: Tyrel Datwyler
> ---
> drivers/scsi/ibmvscsi/ibmvfc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/i
On Wed, Sep 09, 2020 at 10:31:34AM -0700, Linus Torvalds wrote:
> And apparently there are people working on this on the gcc side too,
> so it won't just be clang-specific. Nor kernel-specific in that Nick
> tells me some other projects are looking at using that asm goto with
> outputs too.
It wil
On Wed, Sep 09, 2020 at 07:25:34PM +0200, Gerald Schaefer wrote:
> I actually had to draw myself a picture to get some hold of
> this, or rather a walk-through with a certain pud-crossing
> range in a folded 3-level scenario. Not sure if I would have
> understood my explanation above w/o that, but
On Thu, Sep 3, 2020 at 7:28 AM Al Viro wrote:
>
> I can live with this series; do you want that in vfs.git#for-next?
Well, it's apparently there now (at least it's in your base.set_fs
branch, I didn't check actual -next).
So this is just a heads-up that I plan to merge the "asm goto" changes
on
On Wed, 9 Sep 2020 09:18:46 -0700
Dave Hansen wrote:
> On 9/9/20 5:29 AM, Gerald Schaefer wrote:
> > This only works well as long there are real pagetable pointers involved,
> > that can also be used for iteration. For gup_fast, or any other future
> > pagetable walkers using the READ_ONCE logic
On 9/9/20 5:29 AM, Gerald Schaefer wrote:
> This only works well as long there are real pagetable pointers involved,
> that can also be used for iteration. For gup_fast, or any other future
> pagetable walkers using the READ_ONCE logic w/o lock, that is not true.
> There are pointers involved to lo
On Tue, 8 Sep 2020 19:36:50 +0200
Gerald Schaefer wrote:
[..]
>
> It seems now that the generalization is very well accepted so far,
> apart from some apparent issues on arm. Also, merging 2 + 3 and
> putting them first seems to be acceptable, so we could do that for
> v3, if there are no object
On Thu, 13 Aug 2020 10:11:31 -0500, Nathan Lynch wrote:
> The drmem lmb list can have hundreds of thousands of entries, and
> unfortunately lookups take the form of linear searches. As long as
> this is the case, traversals have the potential to monopolize the CPU
> and provoke lockup reports, work
On Tue, 19 Nov 2019 14:14:29 +0800, zhengbin wrote:
> zhengbin (5):
> powerpc/fadump: Remove set but not used variable 'elf'
> powerpc/perf: Remove set but not used variable 'target'
> powerpc/powernv: Remove set but not used variable 'total_vfs'
> powerpc/powernv: Remove set but not used v
On Fri, 3 Apr 2020 17:38:34 +0200, Frederic Barrat wrote:
> Short series to cleanup AFU interrupt allocation for opencapi.
> Current code was using its own allocation service, calling opal
> directly to get the trigger page. This is not needed and we can use
> xive to achieve the same thing. The on
On Mon, 2 Jul 2018 11:08:16 +0200, Nicholas Mc Guire wrote:
> The call to of_find_compatible_node() returns a node pointer with refcount
> incremented thus it must be explicitly decremented here before returning.
Applied to powerpc/next.
[1/1] powerpc/pseries: Fix missing of_node_put() in rng_in
On Wed, 4 Jul 2018 10:03:27 +0200, Nicholas Mc Guire wrote:
> Both of_find_compatible_node() and of_find_node_by_type() will
> return a refcounted node on success - thus for the success path
> the node must be explicitly released with a of_node_put().
Applied to powerpc/next.
[1/1] powerpc/icp-h
On Tue, 4 Aug 2020 10:54:05 +1000, Oliver O'Halloran wrote:
> When building with W=1 we get the following warning:
>
> arch/powerpc/platforms/powernv/smp.c: In function
> âpnv_smp_cpu_kill_selfâ:
> arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
> empty body
On Tue, 7 Apr 2020 13:56:01 +0200, Frederic Barrat wrote:
> Improve the error message shown if a capi adapter is plugged on a
> capi-incompatible slot directly under the PHB (no intermediate switch).
Applied to powerpc/next.
[1/1] cxl: Rework error message for incompatible slots
https://git
On Tue, 4 Aug 2020 18:43:16 +0100, Colin King wrote:
> There is a spelling mistake in a pr_debug message. Fix it.
Applied to powerpc/next.
[1/1] powerpc/oprofile: fix spelling mistake "contex" -> "context"
https://git.kernel.org/powerpc/c/346427e668163e85cbbe14e4d9a2ddd49df1536c
cheers
On Wed, 27 May 2020 11:42:27 +0800, Biwen Li wrote:
> Since the interrupt pin for RTC DS1374 is not connected
> to the CPU on T4240RDB, remove the interrupt property
> from the device tree.
>
> This also fix the following warning for hwclock.util-linux:
> $ hwclock.util-linux
> hwclock.util-linux:
On Fri, 31 Jul 2020 17:04:59 +0530, Aneesh Kumar K.V wrote:
> If we fail to allocate vmemmap list, we don't keep track of allocated
> vmemmap block buf. Hence on section deactivate we skip vmemmap block
> buf free. This results in memory leak.
Applied to powerpc/next.
[1/2] powerpc/vmemmap: Fix m
On Fri, 7 Aug 2020 17:27:13 +0200, Stephen Kitt wrote:
> The i2c probe functions here don't use the id information provided in
> their second argument, so the single-parameter i2c probe function
> ("probe_new") can be used instead.
>
> This avoids scanning the identifier tables during probes.
App
On Wed, 12 Aug 2020 18:10:34 +1000, Stephen Rothwell wrote:
> These 2 patches enable this script to work properly when llvm-objtool
> is being used.
>
> They depend on my previos series that make this script suck less.
Applied to powerpc/next.
[1/2] powerpc: unrel_branch_check.sh: use nm to find
On Wed, 12 Aug 2020 00:04:27 +1000, Stephen Rothwell wrote:
> Michael Ellerman: "who wants to make
> arch/powerpc/tools/unrel_branch_check.sh suck less"
>
> This series is based off the current powerpc/next branch and keeps the
> same functionaity as the original except that it suppresses some err
On Fri, 28 Aug 2020 12:05:42 +1000, Russell Currey wrote:
> As of commit bdc48fa11e46, scripts/checkpatch.pl now has a default line
> length warning of 100 characters. The powerpc wrapper script was using
> a length of 90 instead of 80 in order to make checkpatch less
> restrictive, but now it's m
On Tue, 25 Aug 2020 17:55:35 +1000, Nicholas Piggin wrote:
> The ISA v3.1 the copy-paste facility has a new memory move functionality
> which allows the copy buffer to be pasted to domestic memory (RAM) as
> opposed to foreign memory (accelerator).
>
> This means the POWER9 trick of avoiding the c
On Tue, 18 Aug 2020 14:45:57 +1000, Oliver O'Halloran wrote:
> These annoy me every time I see them. Why are they here? They're not even
> needed for 80cols compliance.
Applied to powerpc/next.
[1/1] powerpc/pseries/eeh: Fix dumb linebreaks
https://git.kernel.org/powerpc/c/10bf59d923c2766ec
On Thu, 13 Aug 2020 10:11:31 -0500, Nathan Lynch wrote:
> The drmem lmb list can have hundreds of thousands of entries, and
> unfortunately lookups take the form of linear searches. As long as
> this is the case, traversals have the potential to monopolize the CPU
> and provoke lockup reports, work
On Tue, 28 Jul 2020 12:37:41 -0500, Nathan Lynch wrote:
> The drmem lmb list can have hundreds of thousands of entries, and
> unfortunately lookups take the form of linear searches. As long as
> this is the case, traversals have the potential to monopolize the CPU
> and provoke lockup reports, work
On Wed, 19 Aug 2020 11:57:04 +1000, Michael Ellerman wrote:
> The last caller was removed in 2014 in commit fb5a515704d7 ("powerpc:
> Remove platforms/wsp and associated pieces").
>
> As Jordan noticed even though there are no callers, the code above in
> fsl_secondary_thread_init() falls through
On Wed, 19 Aug 2020 11:57:19 +1000, Michael Ellerman wrote:
> These platforms don't show the MMU in /proc/cpuinfo, but they always
> use hash, so teach using_hash_mmu() that.
Applied to powerpc/next.
[1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac
https://git.kernel.o
On Thu, 13 Aug 2020 11:34:43 +1000, Michael Ellerman wrote:
> Several of the TM tests fail spuriously if CPU 0 is offline, because
> they blindly try to affinitise to CPU 0.
>
> Fix them by picking any online CPU and using that instead.
Applied to powerpc/next.
[1/3] selftests/powerpc: Fix TM te
On Wed, 5 Aug 2020 00:04:51 -0300, Leonardo Bras wrote:
> There are some devices in which a hypervisor may only allow 1 DMA window
> to exist at a time, and in those cases, a DDW is never created to them,
> since the default DMA window keeps using this resource.
>
> LoPAR recommends this procedure
On Wed, 2 Sep 2020 09:30:11 +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
>
> This uses pr_warn_once instead of pr_warn_ratelimit as testing
> 'ppc64_cpu --smt=off' on a 24 core /
On Tue, 30 Jun 2020 11:29:35 +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
>
> Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
> Cc: sta...@vger.kernel.
On Thu, 1 Aug 2019 14:46:30 +0930, Joel Stanley wrote:
> Often the firmware will guard out cores after a crash. This often
> undesirable, and is not immediately noticeable.
>
> This adds an informative message when a CPU device tree nodes are marked
> bad in the device tree.
Applied to powerpc/ne
On Thu, 27 Aug 2020 14:05:56 +1000, Jordan Niethe wrote:
> Update the CPU to ISA Version Mapping document to include Power10 and
> ISA v3.1.
Applied to powerpc/next.
[1/1] powerpc: Update documentation of ISA versions for Power10
https://git.kernel.org/powerpc/c/51a1588154cb1ddc4fe8fa786324
On Mon, 24 Aug 2020 23:12:31 +1000, Jordan Niethe wrote:
> The signal handler in the alignment handler self test has the ability to
> jump over the instruction that triggered the signal. It does this by
> incrementing the PT_NIP in the user context by 4. If it were a prefixed
> instruction this wil
On Tue, 25 Aug 2020 13:51:47 +1000, Jordan Niethe wrote:
> As of commit 147c05168fc8 ("powerpc/boot: Add support for 64bit little
> endian wrapper") the comment in the Makefile is misleading. The wrapper
> packaging 64bit kernel may built as a 32 or 64 bit elf. Update the
> comment to reflect this.
On Fri, 14 Aug 2020 05:49:29 + (UTC), Christophe Leroy wrote:
> flush_instruction_cache() is never used on 8xx, remove it.
Applied to powerpc/next.
[1/1] powerpc: Remove flush_instruction_cache() on 8xx
https://git.kernel.org/powerpc/c/76d46a1e2fe2c35f24c07b7cc8a41afbf98b349e
cheers
On Thu, 6 Aug 2020 11:29:01 +0100, Colin King wrote:
> There are spelling mistakes in two debug messages. As recommended
> by Wolfram Sang, these can be removed as there is plenty of debug
> in the driver core.
Applied to powerpc/next.
[1/1] macintosh: windfarm: remove detatch debug containing sp
On Wed, 12 Aug 2020 12:25:16 + (UTC), Christophe Leroy wrote:
> At the time being, __put_user()/__get_user() and friends only use
> D-form addressing, with 0 offset. Ex:
>
> lwz reg1, 0(reg2)
>
> Give the compiler the opportunity to use other adressing modes
> whenever possible, to
On Fri, 14 Aug 2020 06:54:49 + (UTC), Christophe Leroy wrote:
> _nmask_and_or_msr() is only used at two places to set MSR_IP.
>
> The SYNC is unnecessary as the users are not PowerPC 601.
>
> Can be easily writen in C.
>
> Do it, and drop _nmask_and_or_msr()
Applied to powerpc/next.
[1/1]
On Fri, 14 Aug 2020 05:56:24 + (UTC), Christophe Leroy wrote:
> The only callers of flush_instruction_cache() are:
>
> arch/powerpc/kernel/swsusp_booke.S: bl flush_instruction_cache
> arch/powerpc/mm/nohash/40x.c: flush_instruction_cache();
> arch/powerpc/mm/nohash/44x.c: flush_instruction_c
On Mon, 17 Aug 2020 05:46:39 + (UTC), Christophe Leroy wrote:
> ftrace_graph_ret_addr() is always defined and returns 'ip' when
> CONFIG_FUNCTION GRAPH_TRACER is not set.
>
> So the #ifdef is not needed, remove it.
Applied to powerpc/next.
[1/1] powerpc/process: Remove unnecessary #ifdef CON
On Thu, 6 Aug 2020 12:19:46 + (UTC), Christophe Leroy wrote:
> Since the commit identified below, the forward declaration of
> struct irqaction is useless. Drop it.
Applied to powerpc/next.
[1/1] powerpc/irq: Drop forward declaration of struct irqaction
https://git.kernel.org/powerpc/c/
On Thu, 6 Aug 2020 06:01:42 + (UTC), Christophe Leroy wrote:
> The assembler says:
> arch/powerpc/kernel/head_32.S:1095: Warning: invalid register expression
>
> It's objecting to the use of r0 as the RA argument. That's because
> when RA = 0 the literal value 0 is used, rather than the cont
On Thu, 6 Aug 2020 12:19:06 + (UTC), Christophe Leroy wrote:
> Since commit identified below, the forward declaration of
> struct irq_chip is useless (was struct hw_interrupt_type at that time)
>
> Remove it, together with the associated comment.
Applied to powerpc/next.
[1/1] powerpc/hwirq:
On Thu, 6 Aug 2020 12:20:34 + (UTC), Christophe Leroy wrote:
> Those two functions have been unused since commit identified below.
> Drop them.
Applied to powerpc/next.
[1/2] powerpc/fpu: Drop cvt_fd() and cvt_df()
https://git.kernel.org/powerpc/c/63442de4301188129e1fcff144fbfb966ad5eb1
On Mon, 27 Jul 2020 13:46:04 -0500, Scott Cheloha wrote:
> The H_GetPerformanceCounterInfo (GPCI) hypercall input/output structs are
> useful to modules outside of perf/, so move them into asm/hvcall.h to live
> alongside the other powerpc hypercall structs.
>
> Leave the perf-specific GPCI stuff
On Mon, 10 Aug 2020 20:51:15 -0500, Scott Cheloha wrote:
> At memory hot-remove time we can retrieve an LMB's nid from its
> corresponding memory_block. There is no need to store the nid
> in multiple locations.
>
> Note that lmb_to_memblock() uses find_memory_block() to get the
> corresponding m
On Tue, 8 Sep 2020 07:30:50 -0700
Dave Hansen wrote:
> On 9/7/20 11:00 AM, Gerald Schaefer wrote:
> > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
> > code") introduced a subtle but severe bug on s390 with gup_fast, due to
> > dynamic page table folding.
>
> Would it
On 09.09.20 13:37, David Hildenbrand wrote:
> On 09.09.20 13:24, Michael Ellerman wrote:
>> David Hildenbrand writes:
>>> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added Syste
On 09.09.20 13:24, Michael Ellerman wrote:
> David Hildenbrand writes:
>> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
On Wed, 9 Sep 2020 13:38:25 +0530
Anshuman Khandual wrote:
>
>
> On 09/04/2020 08:56 PM, Gerald Schaefer wrote:
> > On Fri, 4 Sep 2020 12:18:05 +0530
> > Anshuman Khandual wrote:
> >
> >>
> >>
> >> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> >>> This patch series includes fixes for debu
David Hildenbrand writes:
> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>>> We soon want to pass flags, e.g., to mark added System RAM resources.
>>> mergeable. Prepare for that.
>>
>> What are these random "flags", and how do
On Wed, 09 Sep 2020 11:38:39 +0530
"Aneesh Kumar K.V" wrote:
> Gerald Schaefer writes:
>
> > On Fri, 4 Sep 2020 18:01:15 +0200
> > Gerald Schaefer wrote:
> >
> > [...]
> >>
> >> BTW2, a quick test with this change (so far) made the issues on s390
> >> go away:
> >>
> >> @@ -1069,7 +1074,7 @@
On Wed, 9 Sep 2020 13:45:48 +0530
Anshuman Khandual wrote:
[...]
> >
> > That would more match the "pte_t pointer" usage for hugetlb code,
> > i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned,
> > but I think the root cause is the pte_t pointer.
>
> Ideally, the pte_t pointer u
Matthew Wilcox writes:
> PowerPC has special handling of hugetlbfs pages. Well, that's what
> the config option says, but actually it handles THP as well. If
> the config option is enabled.
>
> #ifdef CONFIG_HUGETLB_PAGE
> if (PageCompound(page)) {
> flush_dcache_icache_
On 09/09/2020 17:58, Christoph Hellwig wrote:
> On Tue, Sep 08, 2020 at 11:10:03PM +1000, Alexey Kardashevskiy wrote:
a-ha, this makes more sense, thanks. Then I guess we need to revert that
one bit from yours f1565c24b596, do not we?
>>>
>>> Why? The was the original intent of the AP
On 09/04/2020 11:23 PM, Gerald Schaefer wrote:
> On Fri, 4 Sep 2020 18:01:15 +0200
> Gerald Schaefer wrote:
>
>> On Fri, 4 Sep 2020 17:26:47 +0200
>> Gerald Schaefer wrote:
>>
>>> On Fri, 4 Sep 2020 12:18:05 +0530
>>> Anshuman Khandual wrote:
>>>
On 09/02/2020 05:12 PM, Aneesh Ku
On Tue, 2020-09-08 at 16:15 +0200, Alexander Gordeev wrote:
> On Tue, Sep 08, 2020 at 10:16:49AM +0200, Christophe Leroy wrote:
> > >Yes, and also two more sources :/
> > > arch/powerpc/mm/kasan/8xx.c
> > > arch/powerpc/mm/kasan/kasan_init_32.c
> > >
> > >But these two are not quite obvious wrt
On 09/04/2020 09:31 PM, Gerald Schaefer wrote:
> On Fri, 4 Sep 2020 17:26:47 +0200
> Gerald Schaefer wrote:
>
>> On Fri, 4 Sep 2020 12:18:05 +0530
>> Anshuman Khandual wrote:
>>
>>>
>>>
>>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
This patch series includes fixes for debug_vm_pgta
On 09/04/2020 08:56 PM, Gerald Schaefer wrote:
> On Fri, 4 Sep 2020 12:18:05 +0530
> Anshuman Khandual wrote:
>
>>
>>
>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
>>> This patch series includes fixes for debug_vm_pgtable test code so that
>>> they follow page table updates rules correctl
On 09.09.20 09:17, Greg Kroah-Hartman wrote:
> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>> We soon want to pass flags, e.g., to mark added System RAM resources.
>> mergeable. Prepare for that.
>
> What are these random "flags", and how do we know what should be passed
> t
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.
What are these random "flags", and how do we know what should be passed
to them?
Why not make this an enumerated type so that w
84 matches
Mail list logo
