Dear Catalin,
Am 13.07.20 um 20:27 schrieb Catalin Marinas:
On Thu, Jul 09, 2020 at 11:08:52PM +0200, Paul Menzel wrote:
Am 09.07.20 um 19:57 schrieb Catalin Marinas:
On Thu, Jul 09, 2020 at 04:37:10PM +0200, Paul Menzel wrote:
Despite Linux 5.8-rc4 reporting memory leaks on the IBM POWER 8
On Mon, Jul 13, 2020 at 02:59:39PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 09/07/2020 01:24, Christoph Hellwig wrote:
> > Several IOMMU drivers have a bypass mode where they can use a direct
> > mapping if the devices DMA mask is large enough. Add generic support
> > to the core dma-mapping
On 14/07/2020 17:07, Christoph Hellwig wrote:
> On Mon, Jul 13, 2020 at 02:59:39PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/07/2020 01:24, Christoph Hellwig wrote:
>>> Several IOMMU drivers have a bypass mode where they can use a direct
>>> mapping if the devices DMA mask is large enoug
On 14/07/2020 15:58, Oliver O'Halloran wrote:
> On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote:
>>
>> On 10/07/2020 15:23, Oliver O'Halloran wrote:
>>> There's an optimisation in the PE setup which skips performing DMA
>>> setup for a PE if we only have bridges in a PE. The assumpti
This converts the PPC4xx SPI driver to use GPIO descriptors.
The driver is already just picking some GPIOs from the device
tree so the conversion is pretty straight forward. However
this driver is looking form a pure "gpios" property rather
than the standard binding "cs-gpios" so we need to add a
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> We pre-configure the m64 window for IODA1 as a 1-1 segment-PE mapping,
> similar to PHB3. Currently the actual mapping of segments occurs in
> pnv_ioda_pick_m64_pe(), but we can move it into pnv_ioda1_init_m64() and
> drop the IODA1 specific code p
Support hp and mic detection.
Add a parameter for asoc_simple_init_jack.
Shengjiu Wang (3):
ASoC: simple-card-utils: Support configure pin_name for
asoc_simple_init_jack
ASoC: bindings: fsl-asoc-card: Support hp-det-gpio and mic-det-gpio
ASoC: fsl-asoc-card: Support Headphone and Microph
Currently the pin_name is fixed in asoc_simple_init_jack, but some driver
may use a different pin_name. So add a new parameter in
asoc_simple_init_jack for configuring pin_name.
If this parameter is NULL, then the default pin_name is used.
Signed-off-by: Shengjiu Wang
---
include/sound/simple_c
Add headphone and microphone detection GPIO support.
Signed-off-by: Shengjiu Wang
---
Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
b/Documentation/devicetree/bindings/so
Use asoc_simple_init_jack function from simple card to implement
the Headphone and Microphone detection.
Register notifier to disable Speaker when Headphone is plugged in
and enable Speaker when Headphone is unplugged.
Register notifier to disable Digital Microphone when Analog Microphone
is plugge
On 14/07/2020 13:08, Oliver O'Halloran wrote:
> On Tue, Jul 14, 2020 at 11:50 AM Alexey Kardashevskiy wrote:
>>
>> On 06/07/2020 11:36, Oliver O'Halloran wrote:
>>> /**
>>> * eeh_pe_tree_insert - Add EEH device to parent PE
>>> * @edev: EEH device
>>> + * @new_pe_parent: PE to create addit
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> pci-ioda.c is getting a bit unwieldly due to the amount of stuff jammed in
> there. The SR-IOV support can be extracted easily enough and is mostly
> standalone, so move it into a seperate file.
>
> This patch also moves the PowerNV SR-IOV specifi
On Tue, Jul 14, 2020 at 12:10:05PM +0200, Daniel Vetter wrote:
> This and next patch merged to drm-misc-next, thanks.
Oops strike this, I just noticed that Jon said he's picked it all up.
Oh well, the confusion, I managed to stop the script before it published
anything at least :-)
-Daniel
>
>
Remove MODULES dependency by creating module subsystem indepdent
text_alloc() and text_memfree() to allocate space for executable code.
Right now one has to compile modules support only to enable kprobes. This
incrases the barrier to use them in test kernels and I'd guess also in some
embedded ker
Rename module_alloc() to text_alloc() and module_memfree() to
text_memfree(), and move them to kernel/text.c, which is unconditionally
compiled to the kernel proper. This allows kprobes, ftrace and bpf to
allocate space for executable code without requiring to compile the modules
support (CONFIG_MO
On Mon, Jul 13, 2020 at 07:34:10PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen wrote:
> > Rename module_alloc() to text_alloc() and module_memfree() to
> > text_memfree(), and move them to kernel/text.c, which is unconditionally
> > compi
On Tue, Jul 14, 2020 at 12:45:36PM +0300, Jarkko Sakkinen wrote:
> Rename module_alloc() to text_alloc() and module_memfree() to
> text_memfree(), and move them to kernel/text.c, which is unconditionally
> compiled to the kernel proper. This allows kprobes, ftrace and bpf to
> allocate space for ex
On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> This patch suggests that there are other reasons why conflating
> allocation of module space and allocating text pages for other uses
> is a bad idea, but switching all users to text_alloc() is a step in
> the wrong direction. It wo
On Tue, Jul 14, 2020 at 12:49:28PM +0300, Jarkko Sakkinen wrote:
> On Mon, Jul 13, 2020 at 07:34:10PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen wrote:
> > > Rename module_alloc() to text_alloc() and module_memfree() to
> > > text_m
This and next patch merged to drm-misc-next, thanks.
On Wed, Jul 08, 2020 at 01:08:21PM +0800, james qian wang (Arm Technology
China) wrote:
> Hi Randy
>
> On Tue, Jul 07, 2020 at 11:04:00AM -0700, Randy Dunlap wrote:
> > Drop the doubled word "and".
> >
> > Signed-off-by: Randy Dunlap
> > Cc:
On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen
wrote:
>
> On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> > This patch suggests that there are other reasons why conflating
> > allocation of module space and allocating text pages for other uses
> > is a bad idea, but switching all
On Tue, Jul 14, 2020 at 12:45:36PM +0300, Jarkko Sakkinen wrote:
> Rename module_alloc() to text_alloc() and module_memfree() to
> text_memfree(), and move them to kernel/text.c, which is unconditionally
> compiled to the kernel proper. This allows kprobes, ftrace and bpf to
> allocate space for ex
On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote:
> On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen
> wrote:
> >
> > On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> > > This patch suggests that there are other reasons why conflating
> > > allocation of module space an
On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote:
> As Ard says, module_alloc() _is_ special, in the sense that the virtual
> memory it allocates wants to be close to the kernel text, whereas the
> concept of allocating executable memory is broader and doesn't have these
> restrictions.
On Tue, Jul 14, 2020 at 10:53:46AM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Jul 14, 2020 at 12:49:28PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Jul 13, 2020 at 07:34:10PM +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen
On Tue, Jul 14, 2020 at 11:33:33AM +0100, Russell King - ARM Linux admin wrote:
> For 32-bit ARM, our bpf code uses "blx/bx" (or equivalent code
> sequences) rather than encoding a "bl" or "b", so BPF there doesn't
> care where the executable memory is mapped, and doesn't need any
> PLTs. Given th
On Tue, 14 Jul 2020 at 14:31, Peter Zijlstra wrote:
>
> On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote:
>
> > As Ard says, module_alloc() _is_ special, in the sense that the virtual
> > memory it allocates wants to be close to the kernel text, whereas the
> > concept of allocating exe
On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote:
> > This series essentially does this: introduces text_alloc() and
> > text_memfree(), which have generic implementations in kernel/text.c.
> > Those can be overriddent by arch specific implementations.
> >
> > What you think should be
On Tue, Jul 14, 2020 at 11:33:33AM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote:
> > On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen
> > wrote:
> > >
> > > On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> > > > This pa
On Tue, Jul 14, 2020 at 01:29:27PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote:
>
> > As Ard says, module_alloc() _is_ special, in the sense that the virtual
> > memory it allocates wants to be close to the kernel text, whereas the
> > concept of allo
> On Jul 13, 2020, at 11:31 PM, Nicholas Piggin wrote:
>
> Excerpts from Nicholas Piggin's message of July 14, 2020 3:04 pm:
>> Excerpts from Andy Lutomirski's message of July 14, 2020 4:18 am:
>>>
On Jul 13, 2020, at 9:48 AM, Nicholas Piggin wrote:
Excerpts from Andy Lutom
On Tue, Jul 14, 2020 at 05:46:05AM -0700, Andy Lutomirski wrote:
> x86 has this exact problem. At least no more than 64*8 CPUs share the cache
> line :)
I've seen patches for a 'sparse' bitmap to solve related problems.
It's basically the same code, except it multiplies everything (size,
bit-nr)
The sparse tool complains as follows:
drivers/cpufreq/powernv-cpufreq.c:88:1: warning:
symbol 'pstate_revmap' was not declared. Should it be static?
drivers/cpufreq/powernv-cpufreq.c:383:18: warning:
symbol 'cpufreq_freq_attr_cpuinfo_nominal_freq' was not declared. Should it be
static?
drivers/
The sparse tool complains as follows:
drivers/cpuidle/cpuidle-pseries.c:25:23: warning:
symbol 'pseries_idle_driver' was not declared. Should it be static?
'pseries_idle_driver' is not used outside of this file, so marks
it static.
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
driv
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/powernv-cpufreq.c:669:6: warning: no previous prototype for
‘gpstate_timer_handler’ [-Wmissing-prototypes]
drivers/cpufreq/powernv-cpufreq.c:902:6: warning: no previous prototype for
‘powernv_cpufreq_work_fn’ [-Wmissing-prototype
If function callers and providers do not share the same prototypes the
compiler complains of missing prototypes. Fix this by moving the
already existing prototypes out to a mutually convenient location.
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/pasemi-cpufreq.c:109:5: war
Repair problems with formatting and missing attributes/parameters, and
demote header comments which do not meet the required standards
applicable to kerneldoc.
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/powernv-cpufreq.c:84: warning: Function parameter or member
'last_lpst
On Tue, 2020-07-14 at 16:38 +1000, Daniel Axtens wrote:
> Hi Nayna,
>
> Thanks! Would you be able to fold in some of the information from my
> reply to v1 into the changelog? Until we have public PAPR release with
> it, that information is the extent of the public documentation. It would
> be good
[trimmed the cc list; it's still too large but maybe arch folks care]
On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote:
> On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa
> wrote:
> > This goal of these series is to move the definition of *all*
> > PCIBIOS* from include/linux/pci.
On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> So perhaps the answer is to have text_alloc() not with a 'where'
> argument but with a 'why' argument. Or more simply, just have separate
> alloc/free APIs for each case, with generic versions that can be
> overridden by the architec
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> > So perhaps the answer is to have text_alloc() not with a 'where'
> > argument but with a 'why' argument. Or more simply, just have separate
> > alloc/free APIs for e
On Tue, 14 Jul 2020 at 16:33, Mark Rutland wrote:
>
> On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> > > So perhaps the answer is to have text_alloc() not with a 'where'
> > > argument but with a 'why' argument.
+++ Jarkko Sakkinen [14/07/20 12:45 +0300]:
Rename module_alloc() to text_alloc() and module_memfree() to
text_memfree(), and move them to kernel/text.c, which is unconditionally
compiled to the kernel proper. This allows kprobes, ftrace and bpf to
allocate space for executable code without requi
On Tue, 14 Jul 2020 14:33:14 +0100
Mark Rutland wrote:
> > Should work for all cases. Yes, we might then want something like a per
> > arch:
> >
> > {BPF,FTRACE,KPROBE}_TEXT_TYPE
>
> ... at that point why not:
>
> text_alloc_ftrace();
> text_alloc_module();
> text_alloc_bpf();
>
On Tue, 14 Jul 2020 15:56:52 +0200
Jessica Yu wrote:
> As Ard and Will have already explained, the major issue I'm having
> with this is that we're taking module_alloc(), an allocator that was
> originally specific to module loading, and turning it into a generic
> interface to be used by other s
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> > So perhaps the answer is to have text_alloc() not with a 'where'
> > argument but with a 'why' argument. Or more simply, just have separate
> > alloc/free APIs for e
On Tue, Jul 14, 2020 at 03:56:52PM +0200, Jessica Yu wrote:
> +++ Jarkko Sakkinen [14/07/20 12:45 +0300]:
> > Rename module_alloc() to text_alloc() and module_memfree() to
> > text_memfree(), and move them to kernel/text.c, which is unconditionally
> > compiled to the kernel proper. This allows kpr
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> > So perhaps the answer is to have text_alloc() not with a 'where'
> > argument but with a 'why' argument. Or more simply, just have separate
> > alloc/free APIs for e
On Tue, Jul 14, 2020 at 07:31:03PM +0300, Jarkko Sakkinen wrote:
> On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> > to help with text_alloc() usage in generic code, but I think
> > fundamentally, there's only these two options.
>
> There is one arch (nios2), which uses a regular
On Thu Jul 9, 2020 at 4:02 AM CDT, Christophe Leroy wrote:
>
>
> Le 09/07/2020 à 06:03, Christopher M. Riedl a écrit :
> > Currently, code patching a STRICT_KERNEL_RWX exposes the temporary
> > mappings to other CPUs. These mappings should be kept local to the CPU
> > doing the patching. Use the pr
Hari Bathini writes:
> Some architectures may have special memory regions, within the given
> memory range, which can't be used for the buffer in a kexec segment.
> Implement weak arch_kexec_locate_mem_hole() definition which arch code
> may override, to take care of special regions, while tryi
On 14/07/2020, Bjorn Helgaas wrote:
>>
>> a) callers of the high-level config space accessors
>>pci_{write,read}_config_{byte,word,dword}, mostly in device
>>drivers.
>> b) low-level implementation of the config space accessors
>> through struct pci_ops
>> c) all other occurrences of
Hi Shengjiu,
The whole series looks good to me. Just a couple of small
questions inline:
On Tue, Jul 14, 2020 at 05:05:36PM +0800, Shengjiu Wang wrote:
> Use asoc_simple_init_jack function from simple card to implement
> the Headphone and Microphone detection.
> Register notifier to disable Speak
On Wed, Jul 08, 2020 at 11:03:16PM -0500, Christopher M. Riedl wrote:
> When live patching with STRICT_KERNEL_RWX, the CPU doing the patching
> must use a temporary mapping which allows for writing to kernel text.
> During the entire window of time when this temporary mapping is in use,
> another C
On Tue, Jul 14, 2020 at 8:45 PM Bjorn Helgaas wrote:
> On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote:
> > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa
> > Starting with a), my first question is whether any high-level
> > drivers even need to care about errors from these func
https://bugzilla.kernel.org/show_bug.cgi?id=208181
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #289937|0 |1
is obsolete|
On Tue, Jul 14, 2020 at 12:45 PM Bjorn Helgaas wrote:
>
> [trimmed the cc list; it's still too large but maybe arch folks care]
>
> On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote:
> > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa
> > wrote:
> > > This goal of these series is
[+cc Kjetil]
On Wed, Jul 15, 2020 at 12:01:56AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 14, 2020 at 8:45 PM Bjorn Helgaas wrote:
> > On Mon, Jul 13, 2020 at 05:08:10PM +0200, Arnd Bergmann wrote:
> > > On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa
> > > Starting with a), my first question
Hello Hari,
Hari Bathini writes:
> In kexec case, the kernel to be loaded uses the same memory layout as
> the running kernel. So, passing on the DT of the running kernel would
> be good enough.
>
> But in case of kdump, different memory ranges are needed to manage
> loading the kdump kernel,
Booting with a 4GB LMB size causes us to panic:
qemu-system-ppc64: OS terminated: OS panic:
Memory block size not suitable: 0x0
Fix pseries_memory_block_size() to handle 64 bit LMBs.
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard
---
arch/powerpc/platforms/pseries/hotplug-me
On 14/07/2020 17:21, Alexey Kardashevskiy wrote:
>
>
> On 14/07/2020 15:58, Oliver O'Halloran wrote:
>> On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote:
>>>
>>> On 10/07/2020 15:23, Oliver O'Halloran wrote:
There's an optimisation in the PE setup which skips performing DMA
>>>
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> SR-IOV support on PowerNV is a byzantine maze of hooks. I have no idea
> how anyone is supposed to know how it works except through a lot of
> stuffering. Write up some docs about the overall story to help out
> the next sucker^Wperson who needs to
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> This prevents SR-IOV being used by making the SR-IOV BAR resources
> unallocatable. Rename it to reflect what it actually does.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/platforms/powernv/pc
On Wed, Jul 8, 2020 at 2:53 PM Ravi Bangoria
wrote:
>
> Milton Miller reported that we are aligning start and end address to
> wrong size SZ_512M. It should be SZ_512. Fix that.
>
> While doing this change I also found a case where ALIGN() comparison
> fails. Within a given aligned range, ALIGN()
Christophe Leroy writes:
> Prepare for switching VDSO to generic C implementation in following
> patch. Here, we:
> - Modify __get_datapage() to take an offset
> - Prepare the helpers to call the C VDSO functions
> - Prepare the required callbacks for the C VDSO functions
> - Prepare the clocksour
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> No need for the multi-dimensional arrays, just use a bitmap.
>
> Signed-off-by: Oliver O'Halloran
> ---
> arch/powerpc/platforms/powernv/pci-sriov.c | 48 +++---
> arch/powerpc/platforms/powernv/pci.h | 7 +++-
> 2 files c
On Tue, Jul 14, 2020 at 5:21 PM Alexey Kardashevskiy wrote:
>
> On 14/07/2020 15:58, Oliver O'Halloran wrote:
> > On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote:
> >>
> >> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> >>> This also means the only remaining user of the old "DMA Weigh
On Wed, Jul 15, 2020 at 11:34 AM Alexey Kardashevskiy wrote:
>
> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> > diff --git a/arch/powerpc/platforms/powernv/pci.h
> > b/arch/powerpc/platforms/powernv/pci.h
> > index 0156d7d17f7d..58c97e60c3db 100644
> > --- a/arch/powerpc/platforms/powernv/pci.
On Tue, 2020-07-14 at 13:45 -0500, Bjorn Helgaas wrote:
>
> > fail for valid arguments on a valid pci_device* ?
>
> I really like this idea.
>
> pci_write_config_*() has one return value, and only 100ish of 2500
> callers check for errors. It's sometimes possible for config
> accessors to detec
On Tue, 2020-07-14 at 23:02 +0200, Kjetil Oftedal wrote:
> >
> > > For b), it might be nice to also change other aspects of the
> > > interface, e.g. passing a pci_host_bridge pointer plus bus number
> > > instead of a pci_bus pointer, or having the callback in the
> > > pci_host_bridge structure.
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> The sequence required to use the single PE BAR mode is kinda janky and
> requires a little explanation. The API was designed with P7-IOC style
> windows where the setup process is something like:
>
> 1. Configure the window start / end address
> 2
On Wed, Jul 8, 2020 at 2:52 PM Ravi Bangoria
wrote:
>
> Pedro Miraglia Franco de Carvalho noticed that on p8, DAR value is
> inconsistent with different type of load/store. Like for byte,word
> etc. load/stores, DAR is set to the address of the first byte of
> overlap between watch range and real
On Tue, 2020-07-14 at 18:46 -0500, Bjorn Helgaas wrote:
> Yes. I have no problem with that. There are a few cases where it's
> important to check for errors, e.g., we read a status register and do
> something based on a bit being set. A failure will return all bits
> set, and we may do the wrong
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> Rework the PE allocation logic to allow allocating blocks of PEs rather
> than individually. We'll use this to allocate contigious blocks of PEs for
> the SR-IOVs.
The patch does not do just this, it also adds missing mutexes (which is
good) but s
Hari Bathini writes:
> diff --git a/arch/powerpc/include/asm/crashdump-ppc64.h
> b/arch/powerpc/include/asm/crashdump-ppc64.h
> new file mode 100644
> index 000..90deb46
> --- /dev/null
> +++ b/arch/powerpc/include/asm/crashdump-ppc64.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: 17babc2734a55cdf4a678d572f316280b820202b powerpc/fadump: fix race
between pstore write and fadump crash trigger
elapsed time: 720m
configs tested: 104
configs skipped: 8
The following config
allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200714
i386 randconfig-a005-20200714
i386 randconfig-a002-20200714
i386 randconfig-a006-20200714
i386
On Wed, Jul 15, 2020 at 12:29 PM Alexey Kardashevskiy wrote:
>
>
>
> On 10/07/2020 15:23, Oliver O'Halloran wrote:
> > Rework the PE allocation logic to allow allocating blocks of PEs rather
> > than individually. We'll use this to allocate contigious blocks of PEs for
> > the SR-IOVs.
>
> The pat
commit e27e0a94651e ("powerpc/xive: Remove xive_kexec_teardown_cpu()")
left behind this, remove it.
Signed-off-by: YueHaibing
---
arch/powerpc/include/asm/xive.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
index d08ea11b271
On 14-07-20, 15:50, Lee Jones wrote:
> If function callers and providers do not share the same prototypes the
> compiler complains of missing prototypes. Fix this by moving the
> already existing prototypes out to a mutually convenient location.
>
> Fixes the following W=1 kernel build warning(s)
On 14-07-20, 15:50, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/cpufreq/powernv-cpufreq.c:669:6: warning: no previous prototype for
> ‘gpstate_timer_handler’ [-Wmissing-prototypes]
> drivers/cpufreq/powernv-cpufreq.c:902:6: warning: no previous prototype for
On 14-07-20, 15:50, Lee Jones wrote:
> Repair problems with formatting and missing attributes/parameters, and
> demote header comments which do not meet the required standards
> applicable to kerneldoc.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/cpufreq/powernv-cpufreq.c:84
commit 441c19c8a290 ("powerpc/kvm/book3s_hv: Rework the secondary inhibit code")
left behind this, remove it.
Signed-off-by: YueHaibing
---
arch/powerpc/include/asm/smp.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 49
On 15/07/2020 12:53, Oliver O'Halloran wrote:
> On Wed, Jul 15, 2020 at 12:29 PM Alexey Kardashevskiy wrote:
>>
>>
>>
>> On 10/07/2020 15:23, Oliver O'Halloran wrote:
>>> Rework the PE allocation logic to allow allocating blocks of PEs rather
>>> than individually. We'll use this to allocate co
The stub helpers name should be consistent with prototypes.
mm_context_add_vas_windows() --> mm_context_add_vas_window()
mm_context_remove_vas_windows() --> mm_context_remove_vas_window()
Fixes: c420644c0a8f ("powerpc: Use mm_context vas_windows counter to issue
CP_ABORT")
Signed-off-by: YueHaib
On Tue, Jul 14, 2020 at 7:50 AM Lee Jones wrote:
>
> If function callers and providers do not share the same prototypes the
> compiler complains of missing prototypes. Fix this by moving the
> already existing prototypes out to a mutually convenient location.
>
> Fixes the following W=1 kernel bu
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> Currently the iov->pe_num_map[] does one of two things depending on
> whether single PE mode is being used or not. When it is, this contains an
> array which maps a vf_index to the corresponding PE number. When single PE
> mode is not being used th
On 15/07/2020 11:38, Oliver O'Halloran wrote:
> On Tue, Jul 14, 2020 at 5:21 PM Alexey Kardashevskiy wrote:
>>
>> On 14/07/2020 15:58, Oliver O'Halloran wrote:
>>> On Tue, Jul 14, 2020 at 3:37 PM Alexey Kardashevskiy wrote:
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> This als
On 14-07-20, 22:23, Wei Yongjun wrote:
> The sparse tool complains as follows:
>
> drivers/cpufreq/powernv-cpufreq.c:88:1: warning:
> symbol 'pstate_revmap' was not declared. Should it be static?
> drivers/cpufreq/powernv-cpufreq.c:383:18: warning:
> symbol 'cpufreq_freq_attr_cpuinfo_nominal_fre
On Tue, Jul 14, 2020 at 8:07 PM Viresh Kumar wrote:
>
> On 14-07-20, 15:50, Lee Jones wrote:
> > If function callers and providers do not share the same prototypes the
> > compiler complains of missing prototypes. Fix this by moving the
> > already existing prototypes out to a mutually convenient
Hari Bathini writes:
> @@ -534,7 +537,7 @@ static int __init early_init_dt_scan_memory_ppc(unsigned
> long node,
> #ifdef CONFIG_PPC_PSERIES
> if (depth == 1 &&
> strcmp(uname, "ibm,dynamic-reconfiguration-memory") == 0) {
> - walk_drmem_lmbs_early(node, early_init
On 14-07-20, 20:49, Olof Johansson wrote:
> On Tue, Jul 14, 2020 at 8:07 PM Viresh Kumar wrote:
> >
> > On 14-07-20, 15:50, Lee Jones wrote:
> > > If function callers and providers do not share the same prototypes the
> > > compiler complains of missing prototypes. Fix this by moving the
> > > al
YueHaibing writes:
> The stub helpers name should be consistent with prototypes.
>
> mm_context_add_vas_windows() --> mm_context_add_vas_window()
> mm_context_remove_vas_windows() --> mm_context_remove_vas_window()
>
> Fixes: c420644c0a8f ("powerpc: Use mm_context vas_windows counter to issue
>
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> Remove the IODA2 PHB checks. We already assume IODA2 in several places so
> there's not much point in wrapping most of the setup and teardown process
> in an if block.
>
> Signed-off-by: Oliver O'Halloran
> ---
> arch/powerpc/platforms/powernv/p
On 10/07/2020 15:23, Oliver O'Halloran wrote:
> I want to refactor the loop this code is currently inside of. Hoist it on
> out.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/platforms/powernv/pci-sriov.c | 31 ++
> 1 fil
Hi Jordan,
@@ -536,7 +538,12 @@ static bool check_dawrx_constraints(struct pt_regs *regs,
int type,
if (OP_IS_LOAD(type) && !(info->type & HW_BRK_TYPE_READ))
return false;
- if (OP_IS_STORE(type) && !(info->type & HW_BRK_TYPE_WRITE))
+ /*
+* The Ca
On Wed, Jul 15, 2020 at 5:16 AM Nicolin Chen wrote:
>
> Hi Shengjiu,
>
> The whole series looks good to me. Just a couple of small
> questions inline:
>
> On Tue, Jul 14, 2020 at 05:05:36PM +0800, Shengjiu Wang wrote:
> > Use asoc_simple_init_jack function from simple card to implement
> > the Hea
On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann wrote:
>
> - Most error checking is static: PCIBIOS_BAD_REGISTER_NUMBER
> only happens if you pass an invalid register number, but most
> callers pass a compile-time constant register number that is
> known to be correct, or the driver would neve
On Wed, Jul 15, 2020 at 2:00 PM Alexey Kardashevskiy wrote:
>
>
> or we could just skip setting
>
> ppc_md.pcibios_sriov_enable = pnv_pcibios_sriov_enable;
>
> for uninteresting platforms in pnv_pci_init_ioda_phb().
I don't think so. ppc_md is per-platform, not per-PHB andw e still
have to deal w
On 15/07/2020 14:21, Oliver O'Halloran wrote:
> On Wed, Jul 15, 2020 at 2:00 PM Alexey Kardashevskiy wrote:
>>
>>
>> or we could just skip setting
>>
>> ppc_md.pcibios_sriov_enable = pnv_pcibios_sriov_enable;
>>
>> for uninteresting platforms in pnv_pci_init_ioda_phb().
>
> I don't think so. p
1 - 100 of 120 matches
Mail list logo
