On Tue, Jul 23, 2019 at 8:01 PM Mark Brown wrote:
>
> On Mon, Jul 22, 2019 at 03:48:24PM +0300, Daniel Baluta wrote:
> > From: Lucas Stach
> >
> > New revisions of the SAI IP block have even more differences that need
> > be taken into account by the driver. To avoid sprinking compatible
> > chec
On 7/22/19 11:19 PM, Michal Suchánek wrote:
> On Fri, 28 Jun 2019 00:51:19 +0530
> Hari Bathini wrote:
>
>> Currently, if memory_limit is specified and it overlaps with memory to
>> be reserved for capture kernel, memory_limit is adjusted to accommodate
>> capture kernel. With memory reservation
Device tree aware platforms can make use of CMDLINE_EXTEND to extend the
kernel command line provided by the bootloader. This is particularly
useful to set parameters for built-in modules that would otherwise be
done at module insertion. Add support for this in the powerpc
architecture.
Signed-off
Hi,
may I also ask to provide ppc_clone3 symbol also for 32-bit powerpc? Otherwise
Michael's patch breaks build for me:
powerpc-e500v2-linux-gnuspe-ld: arch/powerpc/kernel/systbl.o: in function
`sys_call_table':
(.rodata+0x6cc): undefined reference to `ppc_clone3'
make: *** [Makefile:1060:
On 7/22/19 11:16 PM, Nicholas Piggin wrote:
alloc_pages_node return value should be tested before applying
page_address.
Cc: Anju T Sudhakar
Cc: Madhavan Srinivasan
Signed-off-by: Nicholas Piggin
---
Tested-by: Anju T Sudhakar
Each iteration of for_each_child_of_node puts the previous node, but
in the case of a return from the middle of the loop, there is no put,
thus causing a memory leak. Add an of_node_put before the return.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/crypto/nx/nx-842-po
Michael Ellerman's on July 23, 2019 8:52 pm:
> Nicholas Piggin writes:
>> create_physical_mapping expects physical addresses, but creating and
>> splitting these mappings after boot is supplying virtual (effective)
>> addresses. This can be hit by booting with limited memory then probing
>> new ph
Hello Philipp,
Philipp Rudo writes:
> Hi Thiago,
>
> On Thu, 04 Jul 2019 15:57:34 -0300
> Thiago Jung Bauermann wrote:
>
>> Hello Philipp,
>>
>> Philipp Rudo writes:
>>
>> > Hi Thiago,
>> >
>> >
>> > On Thu, 04 Jul 2019 03:42:57 -0300
>> > Thiago Jung Bauermann wrote:
>> >
>> >> Jessic
On 23.07.19 17:39, Geert Uytterhoeven wrote:
On Tue, Jul 23, 2019 at 5:22 PM Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v5.3-rc1[1] compared to v5.2[2].
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/5f9e832c137075045d15cd6899ab
On Thu, Jul 18, 2019 at 12:49 AM Aneesh Kumar K.V
wrote:
>
> "Oliver O'Halloran" writes:
>
> > On Tue, Jul 16, 2019 at 7:08 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM
> >> device
> >> numa node online. Hence we need to make sur
On Mon, Jul 22, 2019 at 03:48:24PM +0300, Daniel Baluta wrote:
> From: Lucas Stach
>
> New revisions of the SAI IP block have even more differences that need
> be taken into account by the driver. To avoid sprinking compatible
> checks all over the driver move the current differences into of_matc
In some cases initial bind of scm memory for an lpar can fail if
previously it wasn't released using a scm-unbind hcall. This situation
can arise due to panic of the previous kernel or forced lpar
fadump. In such cases the H_SCM_BIND_MEM return a H_OVERLAP error.
To mitigate such cases the patch u
The new hcall named H_SCM_UNBIND_ALL has been introduce that can
unbind all or specific scm memory assigned to an lpar. This is
more efficient than using H_SCM_UNBIND_MEM as currently we don't
support partial unbind of scm memory.
Hence this patch proposes following changes to drc_pmem_unbind():
Update the hvcalls.h to include op-codes for new hcalls introduce to
manage SCM memory. Also update existing hcall definitions to reflect
current papr specification for SCM.
The removed hcall op-codes H_SCM_MEM_QUERY, H_SCM_BLOCK_CLEAR were
transient proposals and there support was never implement
This doc patch provides an initial description of the HCall op-codes
that are used by Linux kernel running as a guest operating
system (LPAR) on top of PowerVM or any other sPAPR compliant
hyper-visor (e.g qemu).
Apart from documenting the HCalls the doc-patch also provides a
rudimentary overview
Presently an error is returned in response to hcall H_SCM_BIND_MEM when a
new kernel boots on lpar via kexec. This prevents papr_scm from registering
drc memory regions with nvdimm. The error reported is of the form below:
"papr_scm ibm,persistent-memory:ibm,pmemory@4412: bind err: -68"
On in
On Tue, Jul 23, 2019 at 5:22 PM Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.3-rc1[1] compared to v5.2[2].
> [1]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/5f9e832c137075045d15cd6899ab0505cfb2ca4b/
> (241 out of 242 configs)
On 23/07/2019 21:46, Michael Ellerman wrote:
> Alexey Kardashevskiy writes:
>> Mapping ~5.000.000 TCEs currently takes about 40s; this is the amount
>> required for a 300GB VM with 64k IOMMU page size. Anything bigger than
>> this produces RCU stall warnings.
>
> OK. Are we sure we're not doin
On 07/05/2019 02:05 AM, Michael Ellerman wrote:
Hi Nayna,
Hi Michael, Oliver,
Nayna Jain writes:
As part of PowerNV secure boot support, OS verification keys are stored
and controlled by OPAL as secure variables. These need to be exposed to
the userspace so that sysadmins can perform k
Alexey Kardashevskiy writes:
> Mapping ~5.000.000 TCEs currently takes about 40s; this is the amount
> required for a 300GB VM with 64k IOMMU page size. Anything bigger than
> this produces RCU stall warnings.
OK. Are we sure we're not doing anything stupid in that code to make it
go that slowly?
The patch
ASoC: fsl_esai: recover the channel swap after xrun
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours
Hi Qian,
On 7/16/19 12:11 AM, Qian Cai wrote:
On Thu, 2019-07-11 at 14:53 +1000, Michael Ellerman wrote:
Hi Maddy,
Madhavan Srinivasan writes:
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index 186109bdd41b..e04b20625cb9 100644
--- a/arch
Nicholas Piggin writes:
> create_physical_mapping expects physical addresses, but creating and
> splitting these mappings after boot is supplying virtual (effective)
> addresses. This can be hit by booting with limited memory then probing
> new physical memory sections.
>
> Cc: Reza Arbab
> Fixes
The cpufreq core now takes the min/max frequency constraints via QoS
requests and the CPUFREQ_ADJUST notifier shall get removed later on.
Switch over to using the QoS request for maximum frequency constraint
for windfarm_cpufreq_clamp driver.
Signed-off-by: Viresh Kumar
---
drivers/macintosh/wi
Hello,
Now that cpufreq core supports taking QoS requests for min/max cpu
frequencies, lets migrate rest of the users to using them instead of the
policy notifiers.
The CPUFREQ_NOTIFY and CPUFREQ_ADJUST events of the policy notifiers are
removed as a result, but we have to add CPUFREQ_CREATE_POLI
Convert existing messages, where appropriate, to use the eeh_edev_*
logging macros.
The only effect should be minor adjustments to the log messages, apart
from:
- A new message in pseries_eeh_probe() "Probing device" to match the
powernv case.
- The "Probing device" message in pnv_eeh_probe() is
On PowerNV and pSeries, devices currently acquire EEH support from
several different places: Boot-time devices from eeh_probe_devices()
and eeh_addr_cache_build(), Virtual Function devices from the pcibios
bus add device hooks and hot plugged devices from pci_hp_add_devices()
(with other platforms
Now that EEH support for all devices (on PowerNV and pSeries) is
provided by the pcibios bus add device hooks, eeh_probe_devices() and
eeh_addr_cache_build() are redundant and can be removed.
Move the EEH enabled message into it's own function so that it can be
called from multiple places.
Note t
Hi all,
Here is v3, addressing feedback from v2 to do with debug logging.
It includes a new patch from Oliver O'Halloran (patch 7) and two additional
patches based on it. See those patches for details.
Cover letter:
This patch set adds support for EEH recovery of hot plugged devices on pSeries
The EEH_DEV_NO_HANDLER flag is used by the EEH system to prevent the
use of driver callbacks in drivers that have been bound part way
through the recovery process. This is necessary to prevent later stage
handlers from being called when the earlier stage handlers haven't,
which can be confusing for
Also remove useless comment.
Signed-off-by: Sam Bobroff
Reviewed-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/eeh.c| 2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c | 14
arch/powerpc/platforms/pseries/eeh_pseries.c | 23 +++-
3 files cha
31 matches
Mail list logo
