Hi Michael,
Hi All,
kbuild test robot Wed, 03 Jan 2018 04:17:20 -0800 wrote:
Hi Darren,
Thank you for the patch! Perhaps something to improve:
arch/powerpc/platforms/pasemi/pci.c: In function 'sb600_set_flag': >>
include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of >>
On Thu, 7 Jun 2018 23:03:23 -0600
Alex Williamson wrote:
> On Fri, 8 Jun 2018 14:14:23 +1000
> Alexey Kardashevskiy wrote:
>
> > On 8/6/18 1:44 pm, Alex Williamson wrote:
> > > On Fri, 8 Jun 2018 13:08:54 +1000
> > > Alexey Kardashevskiy wrote:
> > >
> > >> On 8/6/18 8:15 am, Alex
On Mon, 9 Jul 2018 16:57:46 -0700
Linus Torvalds wrote:
> We have a funny new bugzilla entry for an issue that is 12 years old,
> and not really all that critical, but one that *can* become a problem
> for people who do very specific things.
>
> What happens is that 'fork()' will cause a re-try
Hi Daniel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.18-rc4 next-20180709]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Sun, Jul 1, 2018 at 5:47 PM, Meelis Roos wrote:
> A patch for the subject is now upstream. That made me finally take some
> time to test it on my PowerMac G4. Tha date is OK but I get two warnings
> with backtrace on bootup. Full dmesg below.
Thanks for testing this, and sorry for the slow
On Mon, 2018-07-09 at 09:38 +0100, Tim Small wrote:
> On 06/07/18 19:41, Scott Wood wrote:
> > > My openwrt patch
> > > just does a:
> > >
> > > /delete-node/ crypto@3;
> > >
> > > after the p1010si-post.dtsi include.
> >
> > U-Boot should already be removing the node on non-E chips -- see
On Mon, 2018-07-09 at 15:57 +0200, Daniel Klamt wrote:
> Replaced msleep for less than 10ms with usleep_range because will
> often sleep longer than intended.
> For original explanation see:
> Documentation/timers/timers-howto.txt
Why ? This is pointless. The original code is smaller and more
Hi,
On 07/08, Baoquan He wrote:
>Hi,
>
>On 07/05/18 at 01:00am, kbuild test robot wrote:
>> Hi Baoquan,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on v4.18-rc3 next-20180704]
>> [if your patch is applied to the
Document the support for spec_store_bypass_disable that was added for
powerpc in commit a048a07d7f45 ("powerpc/64s: Add support for a store
forwarding barrier at kernel entry/exit").
Signed-off-by: Michael Ellerman
---
Documentation/admin-guide/kernel-parameters.txt | 16 +---
1
On 07/10/18 at 08:59am, Ye Xiaolong wrote:
> Hi,
>
> On 07/08, Baoquan He wrote:
> >Hi,
> >
> >On 07/05/18 at 01:00am, kbuild test robot wrote:
> >> Hi Baoquan,
> >>
> >> I love your patch! Yet something to improve:
> >>
> >> [auto build test ERROR on linus/master]
> >> [also build test ERROR
On Mon, Jul 9, 2018 at 7:08 PM, Michael Ellerman wrote:
> Document the support for spec_store_bypass_disable that was added for
> powerpc in commit a048a07d7f45 ("powerpc/64s: Add support for a store
> forwarding barrier at kernel entry/exit").
>
> Signed-off-by: Michael Ellerman
Reviewed-by:
On Mon, 9 Jul 2018, Arnd Bergmann wrote:
>
> The most likely explanation I have here is that the RTC was indeed set
> to an incorrect date, either because of a depleted battery (not unlikely
> for a ~15 year old box) or because it was previously stored incorrectly.
The PowerMac stores the GMT
Replaced msleep for less than 10ms with usleep_range because will
often sleep longer than intended.
For original explanation see:
Documentation/timers/timers-howto.txt
Signed-off-by: Daniel Klamt
Signed-off-by: Bjoern Noetel
---
arch/powerpc/sysdev/xive/native.c | 24
On Sun, Jul 8, 2018 at 4:25 PM Rafael J. Wysocki wrote:
>
> On Sat, Jul 7, 2018 at 6:24 AM, Pingfan Liu wrote:
> > On Fri, Jul 6, 2018 at 9:55 PM Pingfan Liu wrote:
> >>
> >> On Fri, Jul 6, 2018 at 4:47 PM Rafael J. Wysocki wrote:
> >> >
> >> > On Fri, Jul 6, 2018 at 10:36 AM, Lukas Wunner
On Mon, Jul 9, 2018 at 10:40 AM, Pingfan Liu wrote:
> On Mon, Jul 9, 2018 at 3:48 PM Rafael J. Wysocki wrote:
>>
>> On Mon, Jul 9, 2018 at 8:48 AM, Pingfan Liu wrote:
>> > On Sun, Jul 8, 2018 at 4:25 PM Rafael J. Wysocki wrote:
[cut]
>>
>> I simply think that there should be one way to
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 15
On Mon, Jul 09, 2018 at 03:21:23PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Today's next fails to build on powerpc with below error
>
> kernel/cpu.o:(.data.rel+0x18e0): undefined reference to
> `lockup_detector_online_cpu'
> ld: BFD version 2.26.1-1.fc25 assertion fail elf64-ppc.c:14734
>
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
Signed-off-by: Nipun Gupta
Reviewed-by: Rob Herring
---
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.c | 7 +++
drivers/iommu/iommu.c| 13 +
include/linux/fsl/mc.h | 8
iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.
'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.
Signed-off-by: Nipun Gupta
fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.
Signed-off-by: Nipun Gupta
Reviewed-by: Laurentiu Tudor
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.
The patch series is based on top of dma-mapping tree (for-next branch):
http://git.infradead.org/users/hch/dma-mapping.git
These patches
- Define property 'iommu-map' for fsl-mc bus (patch 1)
-
With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus
Signed-off-by: Nipun Gupta
Reviewed-by: Robin Murphy
---
drivers/iommu/of_iommu.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/of_iommu.c
of_dma_configure() API expects coherent_dma_mask to be correctly
set in the devices. This patch does the needful.
Signed-off-by: Nipun Gupta
Reviewed-by: Robin Murphy
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c
When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.
Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is mitigated by
hardware changes.
So rework the sysfs files to
On Mon, Jul 9, 2018 at 8:48 AM, Pingfan Liu wrote:
> On Sun, Jul 8, 2018 at 4:25 PM Rafael J. Wysocki wrote:
>>
>> On Sat, Jul 7, 2018 at 6:24 AM, Pingfan Liu wrote:
>> > On Fri, Jul 6, 2018 at 9:55 PM Pingfan Liu wrote:
>> >>
>> >> On Fri, Jul 6, 2018 at 4:47 PM Rafael J. Wysocki
>> >>
On 06/07/18 19:41, Scott Wood wrote:
My openwrt patch
just does a:
/delete-node/ crypto@3;
after the p1010si-post.dtsi include.
U-Boot should already be removing the node on non-E chips -- see
ft_cpu_setup() in arch/powerpc/cpu/mpc85xx/fdt.c
Hi Scott,
Thanks for your email. The
On Mon, Jul 9, 2018 at 3:48 PM Rafael J. Wysocki wrote:
>
> On Mon, Jul 9, 2018 at 8:48 AM, Pingfan Liu wrote:
> > On Sun, Jul 8, 2018 at 4:25 PM Rafael J. Wysocki wrote:
> >>
> >> On Sat, Jul 7, 2018 at 6:24 AM, Pingfan Liu wrote:
> >> > On Fri, Jul 6, 2018 at 9:55 PM Pingfan Liu wrote:
> >>
On Sun, Jul 8, 2018 at 1:53 PM Michael Ellerman wrote:
>
> Randy Dunlap writes:
> > Hi,
> >
> > Is there a good way (or a shortcut) to do something like:
>
> The best I know of is:
>
> > $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig
> > to get a PPC32/32BIT allmodconfig
>
> $ echo
Dear All,
The CMA related functions cma_alloc() and dma_alloc_from_contiguous()
have gfp mask parameter, but sadly they only support __GFP_NOWARN flag.
This gave their users a misleading feeling that any standard memory
allocation flags are supported, what resulted in the security issue when
The CMA memory allocator doesn't support standard gfp flags for memory
allocation, so there is no point having it as a parameter for
dma_alloc_from_contiguous() function. Replace it by a boolean no_warn
argument, which covers all the underlaying cma_alloc() function supports.
This will help to
Nicholas Piggin writes:
> On Fri, 6 Jul 2018 21:58:29 -0700
> Randy Dunlap wrote:
>
>> On 07/06/2018 06:45 PM, Benjamin Herrenschmidt wrote:
>> > On Thu, 2018-07-05 at 14:30 -0700, Randy Dunlap wrote:
>> >> Hi,
>> >>
>> >> Is there a good way (or a shortcut) to do something like:
>> >>
>> >>
On Mon 09-07-18 14:19:55, Marek Szyprowski wrote:
> cma_alloc() function doesn't really support gfp flags other than
> __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
>
> This will help to avoid giving false feeling that this function supports
> standard gfp flags and
cma_alloc() function doesn't really support gfp flags other than
__GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
This will help to avoid giving false feeling that this function supports
standard gfp flags and callers can pass __GFP_ZERO to get zeroed buffer,
what has
[CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-a...@ghiti.fr]
On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
> In order to reduce copy/paste of functions across architectures and then
> make riscv hugetlb port (and future ports) simpler and smaller, this
> patchset intends to
Because the allmodconfig logic just sets every symbol to M or Y, it
has the effect of always generating a 64-bit config, because
CONFIG_PPC64 becomes Y.
So to make it easier for folks to test 32-bit code, provide a phony
defconfig target that generates a 32-bit allmodconfig.
The 32-bit port has
On 08/07/18 16:07, Christoph Hellwig wrote:
On Fri, Jul 06, 2018 at 03:20:34PM +0100, Robin Murphy wrote:
What are you trying to do? I really don't want to see more users of
the hooks as they are are a horribly bad idea.
I really need to fix the ongoing problem we have where, due to funky
The migration of LPARs across Power systems affects many attributes
including that of the associativity of CPUs. The patches in this
set execute when a system is coming up fresh upon a migration target.
They are intended to,
* Recognize changes to the associativity of CPUs recorded in internal
powerpc/cpu: Modify dlpar_cpu_add and dlpar_cpu_remove to allow the
skipping of DRC index acquire or release operations during the CPU
add or remove operations. This is intended to support subsequent
changes to provide a 'CPU readd' operation.
Signed-off-by: Michael Bringmann
---
Changes in
migration/dlpar: This patch adds function dlpar_queue_action()
which will queued up information about a CPU/Memory 'readd'
operation according to resource type, action code, and DRC index.
At a subsequent point, the list of operations can be run/played
in series. Examples of such oprations
Similarly as we just did for 32-bit, add phony targets for generating
a little endian and Book3E allmodconfig. These aren't covered by the
regular allmodconfig, which is big endian and Book3S due to the way
the Kconfig symbols are structured.
Signed-off-by: Michael Ellerman
---
powerpc/dlpar: Provide hotplug CPU 'readd by index' operation to
support LPAR Post Migration state updates. When such changes are
invoked by the PowerPC 'mobility' code, they will be queued up so
that modifications to CPU properties will take place after the new
property value is written to the
On 07/09/2018 05:19 AM, Marek Szyprowski wrote:
cma_alloc() function doesn't really support gfp flags other than
__GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
This will help to avoid giving false feeling that this function supports
standard gfp flags and callers can
mobility/numa: Ensure that numa_update_cpu_topology() can not be
entered multiple times concurrently. It may be accessed through
many different paths / concurrent work functions, and the lock
ordering may be difficult to ensure otherwise.
Signed-off-by: Michael Bringmann
---
numa: Provide mechanism to disable/enable operation of
arch_update_cpu_topology/numa_update_cpu_topology. This is
a simple tool to eliminate some avenues for thread deadlock
observed during system execution.
Signed-off-by: Michael Bringmann
---
arch/powerpc/include/asm/topology.h | 10
powerpc/rtas: Provide mechanism by which the rtas_event_scan can
be disabled/re-enabled by other portions of the powerpc code.
Among other things, this simplifies the usage of locking mechanisms
for shared kernel resources.
Signed-off-by: Michael Bringmann
---
arch/powerpc/include/asm/rtas.h |
hotplug/pmt: Call rebuild_sched_domains after applying changes
to update CPU associativity i.e. 'readd' CPUs. This is to
ensure that the deferred calls to arch_update_cpu_topology are
now reflected in the system data structures.
Signed-off-by: Michael Bringmann
---
On Fri, 6 Jul 2018 19:40:24 +1000
Nicholas Piggin wrote:
> On Wed, 04 Jul 2018 23:30:12 +0530
> Mahesh J Salgaonkar wrote:
>
> > From: Mahesh Salgaonkar
> >
> > Now that other platforms also implements real mode mce handler,
> > lets consolidate the code by sharing existing powernv machine
pmt/numa: Disable arch_update_cpu_topology during post migration
CPU readd updates when evaluating device-tree changes after LPM
to avoid thread deadlocks trying to update node assignments.
System timing between all of the threads and timers restarted in
a migrated system overlapped frequently
hotplug/rtas: Disable rtas_event_scan during device-tree property
updates after migration to reduce conflicts with changes propagated
to other parts of the kernel configuration, such as CPUs or memory.
Signed-off-by: Michael Bringmann
---
arch/powerpc/platforms/pseries/hotplug-cpu.c |4
On Mon, 2018-07-09 at 13:47 +0200, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 03:21:23PM +0530, Abdul Haleem wrote:
> > Greeting's
> >
> > Today's next fails to build on powerpc with below error
> >
> > kernel/cpu.o:(.data.rel+0x18e0): undefined reference to
> > `lockup_detector_online_cpu'
51 matches
Mail list logo
