> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Scott Wood
> Sent: Wednesday, August 29, 2018 5:49 AM
> To: Vabhav Sharma ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; robh...@kernel.org;
> mark.rutl...@arm.com; linuxpp
On Sun, Aug 19, 2018 at 5:35 PM Lukas Wunner wrote:
>
> Here's PCI hotplug material I've prepared for v4.20:
>
> Patches [1/9] to [8/9] reduce the code by 488 lines. There should be no
> loss of functionality and no new features, just less and simpler code.
>
> Patch [9/9] collects TODOs for hotp
register")
---
Problem located during code-review
Patch is against 4.19-rc1 (localversion-next is next-20180830)
drivers/usb/gadget/udc/fsl_udc_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/drivers/usb/gadget/ud
Patch is against 4.19-rc1 (localversion-next is next-20180830)
drivers/usb/gadget/udc/fsl_udc_core.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/drivers/usb/gadget/udc/fsl_udc_core.c
index be59309..e637
On 21.08.2018 12:44, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
>
I'll be on vacation for two weeks
On Wed, Aug 29, 2018 at 9:49 PM Qiang Zhao wrote:
>
> From: Rob Herring
> date: 2018/8/30 4:04
>
> > To: Qiang Zhao
> > Cc: linux-ker...@vger.kernel.org; Leo Li ;
> > linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org
> > Subject: [PATCH] soc: fsl/qe: Use of_get_child_by_name he
On Wed, Aug 29, 2018 at 4:29 AM Colin King wrote:
>
> From: Colin Ian King
>
> Pointer 'priv' is being assigned but is never used hence it is
> redundant and can be removed.
>
> Cleans up clang warning:
> variable 'priv' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian Ki
On Thu, 2018-08-30 at 07:36 +, Vabhav Sharma wrote:
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Scott Wood
> > Sent: Wednesday, August 29, 2018 5:49 AM
> > To: Vabhav Sharma ; linux-
> > ker...@vger.kernel.org; devicet...@vg
On Thu, 2018-08-30 at 12:39 -0500, Scott Wood wrote:
> On Thu, 2018-08-30 at 07:36 +, Vabhav Sharma wrote:
> > > -Original Message-
> > > From: linux-kernel-ow...@vger.kernel.org > > ow...@vger.kernel.org> On Behalf Of Scott Wood
> > > Sent: Wednesday, August 29, 2018 5:49 AM
> > > To:
From: Randy Dunlap
[ Upstream commit f5daf77a55ef0e695cc90c440ed6503073ac5e07 ]
Fix build errors and warnings in t1042rdb_diu.c by adding header files
and MODULE_LICENSE().
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: data definition
has no type or storage class
early_initcal
From: Randy Dunlap
[ Upstream commit f5daf77a55ef0e695cc90c440ed6503073ac5e07 ]
Fix build errors and warnings in t1042rdb_diu.c by adding header files
and MODULE_LICENSE().
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: data definition
has no type or storage class
early_initcal
Thank you Jiri, I am studying it.
Pavel
On 8/24/18 3:44 AM, Jiri Slaby wrote:
> pasha.tatas...@oracle.com -> pavel.tatas...@microsoft.com
>
> due to
> 550 5.1.1 Unknown recipient address.
>
>
> On 08/24/2018, 09:32 AM, Jiri Slaby wrote:
>> On 06/19/2018, 09:56 PM, Pavel Tatashin wrote:
>>> On
Hi Jiri,
I believe this bug is fixed with this change:
d39f8fb4b7776dcb09ec3bf7a321547083078ee3
mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM
I am not able to reproduce this problem on x86-32.
Pavel
On 8/30/18 10:35 AM, Pavel Tatashin wrote:
> Thank you Jiri, I am studying
On 8/30/18 8:31 AM, David Hildenbrand wrote:
> On 21.08.2018 12:44, David Hildenbrand wrote:
>> This is the same approach as in the first RFC, but this time without
>> exporting device_hotplug_lock (requested by Greg) and with some more
>> details and documentation regarding locking. Tested only
> +
> +void __ref remove_memory(int nid, u64 start, u64 size)
Remove __ref, otherwise looks good:
Reviewed-by: Pavel Tatashin
> +{
> + lock_device_hotplug();
> + __remove_memory(nid, start, size);
> + unlock_device_hotplug();
> +}
> EXPORT_SYMBOL_GPL(remove_memory);
> #endif /* CO
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> add_memory() currently does not take the device_hotplug_lock, however
> is aleady called under the lock from
> arch/powerpc/platforms/pseries/hotplug-memory.c
> drivers/acpi/acpi_memhotplug.c
> to synchronize against CPU hot-remove and simi
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
> fix concurrent memory hot-add deadlock"), which tried to fix a possible
> lock inversion reported and discussed in [1] due to the two locks
> a) device_lock()
> b) mem
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> device_online() should be called with device_hotplug_lock() held.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rashmica Gupta
> Cc: Balbir Singh
> Cc: Michael Neuling
> Signed-off
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> Let's perform all checking + offlining + removing under
> device_hotplug_lock, so nobody can mess with these devices via
> sysfs concurrently.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> Let's document the magic a bit, especially why device_hotplug_lock is
> required when adding/removing memory and how it all play together with
> requests to online/offline memory from user space.
>
Stress testing has uncovered issues with handling continuously queued PRRN
events. Running PRRN events in this way can seriously load the system given
the sheer volume of dlpar being handled. This patchset ensures that PRRN
events are handled more synchronously. It also updates dlpar invocation
so
When a PRRN event is received we are already running in a worker
thread. Instead of spawning off another worker thread on the prrn_work
workqueue to handle the PRRN event we can just call the PRRN handler
routine directly.
With this update we can also pass the scope variable for the PRRN
event dir
There are three instances in which dlpar hotplug events are invoked;
handling a hotplug interrupt (in a kvm guest), handling a dlpar
request through sysfs, and updating LMB affinity when handling a
PRRN event. Only in the case of handling a hotplug interrupt do we
have to put the work on a workqueu
Add property 'big-endian' and supportted IP's configuration info.
Remove property 'fsl,#rcpm-wakeup-cell'.
Signed-off-by: Ran Wang
---
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 42 ++-
1 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/Documentation/dev
The NXP's QorIQ Processors based on ARM Core have RCPM module (Run
Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on FSL platform PM driver framework which help to
isolate user and PM service
This driver is to provide a independent framework for PM service
provider and consumer to configure system level wake up feature. For
example, RCPM driver could register a callback function on this
platform first, and Flex timer driver who want to enable timer wake
up feature, will call generic API
On 30/08/2018 14:01, David Gibson wrote:
> On Thu, Aug 30, 2018 at 01:16:44PM +1000, Alexey Kardashevskiy wrote:
>> The KVM TCE handlers are written in a way so they fail when either
>> something went horribly wrong or the userspace did some obvious mistake
>> such as passing a misaligned addres
On Thu, 2018-08-30 at 20:39 -0600, Mac User wrote:
> On 8/29/18 7:05 PM, Rob Herring wrote:
>
> > On Wed, Aug 29, 2018 at 7:44 PM Finn Thain
> > wrote:
> > > Hi Frank,
> > >
> > > Linux v4.17 and later will no longer boot on a G3 PowerMac. The boot hangs
> > > very early, before any video drive
Hi Finn,
On 08/29/18 17:44, Finn Thain wrote:
> Hi Frank,
>
> Linux v4.17 and later will no longer boot on a G3 PowerMac. The boot hangs
> very early, before any video driver loads.
>
> Stan and I were able to bisect the regression between v4.16 and v4.17 and
> arrived at commit 0b3ce78e90fc (
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.19-rc1 next-20180830]
[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 Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> > If I force output with "-f", the resulting file has no occurrences
> > of "phandle".
>
> Are you booting with BootX or Open Firmware ?
Assuming you are using BootX (or miBoot), can you try this patch ?
--- a/arch/powerpc/pl
On Thu, 2018-08-30 at 21:36 -0700, Frank Rowand wrote:
> > No idea whether that's relevant; I haven't done any further investigation.
> > Complete dmesg output is attached. Please let me know if there's any more
> > information you need to help find the bug.
> >
> > Thanks.
>
> I don't have any
On Fri, 31 Aug 2018 12:38:19 +0800
kbuild test robot wrote:
> Hi Nicholas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on powerpc/next]
> [also build test ERROR on v4.19-rc1 next-20180830]
> [if your patch is applied to the wrong git tree,
At the moment the real mode handler of H_PUT_TCE calls iommu_tce_xchg_rm()
which in turn reads the old TCE and if it was a valid entry - marks
the physical page dirty if it was mapped for writing. Since it is
the real mode, realmode_pfn_to_page() is used instead of pfn_to_page()
to get the page str
Hi Scott,
Please see my replay inline.
> -Original Message-
> From: linux-arm-kernel
> On Behalf Of Scott Wood
> Sent: 2018年8月31日 1:43
> To: Vabhav Sharma ;
> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com;
> linuxppc-dev@lists.ozlabs
35 matches
Mail list logo
