On Mon, 11 Mar 2024 20:13:44 +0900, Chancel Liu wrote:
> echo /lib/firmware/fw.elf > /sys/class/remoteproc/remoteproc0/firmware
> (A) echo start > /sys/class/remoteproc/remoteproc0/state
> (B) echo stop > /sys/class/remoteproc/remoteproc0/state
>
> The rpmsg sound card is registered in (
On Mon, Mar 11, 2024 at 7:14 PM Chancel Liu wrote:
>
> echo /lib/firmware/fw.elf > /sys/class/remoteproc/remoteproc0/firmware
> (A) echo start > /sys/class/remoteproc/remoteproc0/state
> (B) echo stop > /sys/class/remoteproc/remoteproc0/state
>
> The rpmsg sound card is registered
echo /lib/firmware/fw.elf > /sys/class/remoteproc/remoteproc0/firmware
(A) echo start > /sys/class/remoteproc/remoteproc0/state
(B) echo stop > /sys/class/remoteproc/remoteproc0/state
The rpmsg sound card is registered in (A) and unregistered in (B).
After "start", imx-audio-rpmsg
echo /lib/firmware/fw.elf > /sys/class/remoteproc/remoteproc0/firmware
(A) echo start > /sys/class/remoteproc/remoteproc0/state
(B) echo stop > /sys/class/remoteproc/remoteproc0/state
The rpmsg sound card is registered in (A) and unregistered in (B).
After "start", imx-audio-rpmsg
echo /lib/firmware/fw.elf > /sys/class/remoteproc/remoteproc0/firmware
(A) echo start > /sys/class/remoteproc/remoteproc0/state
(B) echo stop > /sys/class/remoteproc/remoteproc0/state
The rpmsg sound card is registered in (A) and unregistered in (B).
After "start", imx-audio-rpmsg
lassdev_unregister() calls
>> led_set_brightness() to turn off the LEDs and module's appropriate
callback
>> uses resources those were destroyed already in module's remove().
>> So explicitly unregister LEDs at module shutdown.
>>
>> Signed-off-by: George Stark
>
; uses resources those were destroyed already in module's remove().
> So explicitly unregister LEDs at module shutdown.
>
> Signed-off-by: George Stark
> ---
> drivers/leds/leds-nic78bx.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/leds/l
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-an30259a.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-an30259a.c b/drivers/leds/leds-an30259a.c
index 24b1041213c2..4209a407d802 100644
--- a/drivers/leds/leds-a
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index 743e2cdd0891..7c7f696c8265 100644
--- a/drivers/leds/leds-
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-nic78bx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-nic78bx.c b/drivers/leds/leds-nic78bx.c
index f196f52eec1e..12b70fcad37f 100644
--- a/drivers/leds/leds-
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-aw2013.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-aw2013.c b/drivers/leds/leds-aw2013.c
index 59765640b70f..bd233500aa2d 100644
--- a/drivers/leds/leds-aw2013.
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-lp3952.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/leds/leds-lp3952.c b/drivers/leds/leds-lp3952.c
index 3bd55652a706..2de49192011a 100644
--- a/drivers/leds/leds-lp3952.
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-aw200xx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-aw200xx.c b/drivers/leds/leds-aw200xx.c
index 96979b8e09b7..3da0923507ec 100644
--- a/drivers/leds/leds-
.
So explicitly unregister LEDs at module shutdown.
Signed-off-by: George Stark
---
drivers/leds/leds-mlxreg.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-mlxreg.c b/drivers/leds/leds-mlxreg.c
index b7855c93bd72..6d65e39c3372 100644
--- a/dr
As of_device_(add|register|unregister) functions work on struct
platform_device, they should be declared in of_platform.h instead.
This move is transparent for now as both headers include each other.
Signed-off-by: Rob Herring
---
include/linux/of_device.h | 4
include/linux
On Wed, Feb 01, 2023 at 01:57:39PM -0600, Brian King wrote:
> This moves the removal of the rescan sysfs attribute to occur
> before the call to unregister the vio to ensure the removal
> does not fail due to the vio driver already being freed.
>
> Signed-off-by: Brian King
>
This moves the removal of the rescan sysfs attribute to occur
before the call to unregister the vio to ensure the removal
does not fail due to the vio driver already being freed.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
This moves the removal of the rescan sysfs attribute to occur
before the call to unregister the vio to ensure the removal
does not fail due to the vio driver already being freed.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
On Mon, 14 Nov 2022 17:01:50 +0100, Laurent Dufour wrote:
> The VPA should unregister when offlining a CPU. Otherwise there could be a
> short window where 2 CPUs could share the same VPA.
>
> This happens because the hypervisor is still keeping the VPA attached to
> the vCPU ev
Undo everything done by init_subsystems() if a later initialization step
fails, i.e. unregister perf callbacks in addition to unregistering the
power management notifier.
Fixes: bfa79a805454 ("KVM: arm64: Elevate hypervisor mappings creation at EL2")
Signed-off-by: Sean Christopherson
Laurent Dufour writes:
> The VPA should unregister when offlining a CPU. Otherwise there could be a
> short window where 2 CPUs could share the same VPA.
>
> This happens because the hypervisor is still keeping the VPA attached to
> the vCPU even if it became offline.
>
>
The VPA should unregister when offlining a CPU. Otherwise there could be a
short window where 2 CPUs could share the same VPA.
This happens because the hypervisor is still keeping the VPA attached to
the vCPU even if it became offline.
Here is a potential situation:
1. remove proc A,
2. add
Undo everything done by init_subsystems() if a later initialization step
fails, i.e. unregister perf callbacks in addition to unregistering the
power management notifier.
Fixes: bfa79a805454 ("KVM: arm64: Elevate hypervisor mappings creation at EL2")
Signed-off-by: Sean Christopherson
mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow.
This matches how other drivers (e.g. nand/raw/nandsim.c) use
mtd_device_unregister().
By returning 0 in the platform remove callback a generic error message
by the device core is suppressed, nothing else changes.
This is a pr
On Thu, 28 Oct 2021 22:27:16 +0530, Vasant Hegde wrote:
> Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
> opal notifier. But I missed to unregister the notifier during module unload
> path. This results in below call trace if you try to unload and load
&
On 10/1/21 11:40 AM, Daniel Axtens wrote:
Hi Vasant,
Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
opal notifier. But I missed to unregister the notifier during module unload
path. This results in below call trace if you try to unload and load
opal_prd module
Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
opal notifier. But I missed to unregister the notifier during module unload
path. This results in below call trace if you try to unload and load
opal_prd module.
Also add new notifier_block for OPAL_MSG_PRD2 message
Hi Vasant,
> Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
> opal notifier. But I missed to unregister the notifier during module unload
> path. This results in below call trace if you try to unload and load
> opal_prd module.
>
> Fixes: 587164cd
Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
opal notifier. But I missed to unregister the notifier during module unload
path. This results in below call trace if you try to unload and load
opal_prd module.
Sample calltrace (modprobe -r opal_prd; modprobe opal_prd
The user space uses /dev/crypto/nx-gzip interface to setup VAS
windows, create paste mapping and close windows. This patch adds
changes to create/remove this interface with VAS register/unregister
functions on PowerVM platform.
Signed-off-by: Haren Myneni
Acked-by: Herbert Xu
Acked-by
powerNV and pseries drivers register / unregister to the corresponding
platform specific VAS separately. Then these VAS functions call the
common API with the specific window operations. So rename powerNV VAS
API register/unregister functions.
Signed-off-by: Haren Myneni
Reviewed-by: Nicholas
Excerpts from Haren Myneni's message of June 13, 2021 9:04 pm:
>
> The user space uses /dev/crypto/nx-gzip interface to setup VAS
> windows, create paste mapping and close windows. This patch adds
> changes to create/remove this interface with VAS register/unregister
>
The user space uses /dev/crypto/nx-gzip interface to setup VAS
windows, create paste mapping and close windows. This patch adds
changes to create/remove this interface with VAS register/unregister
functions on PowerVM platform.
Signed-off-by: Haren Myneni
Acked-by: Herbert Xu
---
drivers
powerNV and pseries drivers register / unregister to the corresponding
platform specific VAS separately. Then these VAS functions call the
common API with the specific window operations. So rename powerNV VAS
API register/unregister functions.
Signed-off-by: Haren Myneni
Reviewed-by: Nicholas
Excerpts from Haren Myneni's message of May 21, 2021 7:41 pm:
>
> Changes to create /dev/crypto/nx-gzip interface with VAS register
> and to remove this interface with VAS unregister.
>
Could you include why the change is done, or what goes wrong without it?
Thanks,
Nick
Changes to create /dev/crypto/nx-gzip interface with VAS register
and to remove this interface with VAS unregister.
Signed-off-by: Haren Myneni
Acked-by: Herbert Xu
---
drivers/crypto/nx/Kconfig | 1 +
drivers/crypto/nx/nx-common-pseries.c | 9 +
2 files changed, 10
powerNV and pseries drivers register / unregister to the corresponding
platform specific VAS separately. Then these VAS functions call the
common API with the specific window operations. So rename powerNV VAS
API register/unregister functions.
Signed-off-by: Haren Myneni
Reviewed-by: Nicholas
On Mon, 2021-05-10 at 15:10 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of April 18, 2021 7:00 am:
> > powerNV and pseries drivers register / unregister to the
> > corresponding
> > VAS code separately. So rename powerNV VAS API register/unregist
Excerpts from Haren Myneni's message of April 18, 2021 7:00 am:
>
> powerNV and pseries drivers register / unregister to the corresponding
> VAS code separately. So rename powerNV VAS API register/unregister
> functions.
The pseries VAS driver will have different calls
On Sat, Apr 17, 2021 at 02:12:12PM -0700, Haren Myneni wrote:
>
> Changes to create /dev/crypto/nx-gzip interface with VAS register
> and to remove this interface with VAS unregister.
>
> Signed-off-by: Haren Myneni
> ---
> drivers/crypto/nx/Kconfig | 1 +
&g
Changes to create /dev/crypto/nx-gzip interface with VAS register
and to remove this interface with VAS unregister.
Signed-off-by: Haren Myneni
---
drivers/crypto/nx/Kconfig | 1 +
drivers/crypto/nx/nx-common-pseries.c | 9 +
2 files changed, 10 insertions(+)
diff --git a
powerNV and pseries drivers register / unregister to the corresponding
VAS code separately. So rename powerNV VAS API register/unregister
functions.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/vas.h | 6 +++---
arch/powerpc/platforms/powernv/vas-api.c | 10
Changes to create /dev/crypto/nx-gzip interface with VAS register
and to remove this interface with VAS unregister.
Signed-off-by: Haren Myneni
---
drivers/crypto/nx/Kconfig | 1 +
drivers/crypto/nx/nx-common-pseries.c | 9 +
2 files changed, 10 insertions(+)
diff --git a
powerNV and pseries drivers register / unregister to the corresponding
VAS code separately. So rename powerNV VAS API register/unregister
functions.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/vas.h | 6 +++---
arch/powerpc/platforms/powernv/vas-api.c | 10
Hi Haren,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on cryptodev/master crypto/master v5.12-rc6
next-20210409]
[cannot apply to scottwood/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submi
Changes to create /dev/crypto/nx-gzip interface with VAS register
and to remove this interface with VAS unregister.
Signed-off-by: Haren Myneni
---
drivers/crypto/nx/nx-common-pseries.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/crypto/nx/nx-common-pseries.c
b
powerNV and pseries drivers register / unregister to the corresponding
VAS code separately. So rename powerNV VAS API register/unregister
functions.
Signed-off-by: Haren Myneni
---
arch/powerpc/include/asm/vas.h | 6 +++---
arch/powerpc/platforms/powernv/vas-api.c | 10
cpuidle_device is touched during the cpu hotplug. At present, ppc64 just
online/offline cpu during hotplug/unplug. But if using the
register_cpu/unregister_cpu() API to implement the hotplug, the dir
/sys/../cpuX is created/destroyed during hotplug, hence we also need to
create the file cpuX/cpuidl
imc_common_cpuhp_mem_free(struct imc_pmu
*pmu_ptr)
}
}
+/*
+ * Function to unregister thread-imc if core-imc
+ * is not registered.
+ */
+void unregister_thread_imc(void)
+{
+ imc_common_cpuhp_mem_free(thread_imc_pmu);
+ imc_common_mem_free(thread_imc_pmu);
+ perf_pmu_unregister
On Fri, 2018-04-27 at 06:23:18 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> Unregister fadump on kexec down path otherwise the fadump registration in
> new kexec-ed kernel complains that fadump is already registered. This
> makes new kernel to continue using fadum
)
}
}
+/*
+ * Function to unregister thread-imc if core-imc
+ * is not registered.
+ */
+void unregister_thread_imc(void)
+{
+ imc_common_cpuhp_mem_free(thread_imc_pmu);
+ imc_common_mem_free(thread_imc_pmu);
+ perf_pmu_unregister(&thread_imc_pmu->pmu);
+}
/*
* imc_mem_init : Func
From: Mahesh Salgaonkar
Unregister fadump on kexec down path otherwise the fadump registration in
new kexec-ed kernel complains that fadump is already registered. This
makes new kernel to continue using fadump registered by previous kernel
which may lead to invalid vmcore generation. Hence this
cpuidle_device is touched during the cpu hotplug. In order to cope with the
incoming
patch [3/3], which causes the dir /sys/../cpuX is created/destroyed during
hotplug,
we also need to create the file cpuX/cpuidle dynamically.
Signed-off-by: Pingfan Liu
Reviewed-by: Hari Bathini
---
drivers/c
;
struct imc_pmu *imc_event_to_pmu(struct perf_event *event)
@@ -1228,6 +1229,16 @@ static void imc_common_cpuhp_mem_free(struct imc_pmu
*pmu_ptr)
}
}
+/*
+ * Function to unregister thread-imc if core-imc
+ * is not registered.
+ */
+void unregister_thread_imc(void
Now for pseries, ../cpu/cpuX is created and deleted dynamically.
Hence cpuX/cpuidle should be created and deleted dynamically.
For powernv, it is harmless to use the same method.
Signed-off-by: Pingfan Liu
---
drivers/cpuidle/cpuidle-powernv.c | 2 ++
drivers/cpuidle/cpuidle-pseries.c | 2 ++
2
y calling irq_dispose_mapping() on the virq of the
> viodev on unregister.
>
> Signed-off-by: Tyrel Datwyler
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b8f89fea599d91e674497aad572613
cheers
Tyrel Datwyler writes:
> Ping...
>
> Anybody, see any issues with this patch?
No it looks OK to me.
I'll put it in next. I'm going to drop the stable tag for now, I'd like
it to get some more testing. We can request a backport later.
cheers
() on the virq of the
viodev on unregister.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
---
arch/powerpc/kernel/vio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 5f8dcda..a3228d6 100644
--- a/arch/powerpc/kernel/
CV-V5-C25 removed
ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3
ics_rtas_set_affinity: ibm,set-xive irq=655385 returns -3
This patch fixes the issue by calling irq_dispose_mapping() on the virq of the
viodev on unregister.
Cc: sta...@vger.kernel.org
Signed-off-by: Tyrel Datwyler
---
On 02/11/2015 04:27 PM, Anshuman Khandual wrote:
On 02/11/2015 11:57 AM, Neelesh Gupta wrote:
Provide an unregister interface for the opal message notifiers
to be called when not needed like during driver unload/remove.
Why only for unload/remove, you can also use it in cases where you need
On 02/11/2015 11:57 AM, Neelesh Gupta wrote:
> Provide an unregister interface for the opal message notifiers
> to be called when not needed like during driver unload/remove.
Why only for unload/remove, you can also use it in cases where you need
to abort because of any other error soon
Provide an unregister interface for the opal message notifiers
to be called when not needed like during driver unload/remove.
Signed-off-by: Neelesh Gupta
Reviewed-by: Vasant Hegde
---
arch/powerpc/include/asm/opal.h |2 ++
arch/powerpc/platforms/powernv/opal.c |7 +++
2
Provide an unregister interface for the opal message notifiers
to be called when not needed like during driver unload/remove.
Signed-off-by: Neelesh Gupta
Reviewed-by: Vasant Hegde
---
arch/powerpc/include/asm/opal.h |2 ++
arch/powerpc/platforms/powernv/opal.c |7 +++
2
PowerNV platform is capable of capturing host memory region when system
crashes (because of host/firmware). We have new OPAL API to register/
unregister memory region to be captured when system crashes.
This patch adds support for new API. Also during boot time we register
kernel log buffer and
PowerNV platform is capable of capturing host memory region when system
crashes (because of host/firmware). We have new OPAL API to register/
unregister memory region to be captured when system crashes.
This patch adds support for new API. Also during boot time we register
kernel log buffer and
PowerNV platform is capable of capturing host memory region when system
crashes (because of host/firmware). We have new OPAL API to register/
unregister memory region to be captured when system crashes.
This patch adds support for new API. Also during boot time we register
kernel log buffer and
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
---
drivers/tty/serial/ucc_uart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index 7355303..f86f447
Libo Chen wrote:
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
Acked-by: Timur Tabi
Thanks for catching this.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On 11/27/2012 06:00 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
CC: David
On Wed, 2012-11-28 at 13:42 -0600, Nathan Fontenot wrote:
> The of reconfiguration notification chains should be exported for use
> by modules.
>
> Signed-off-by:Nathan Fontenot
Grant, I'm applying that into the powerpc tree (with a slightly modified
subject line). You don't need to add it to yo
The of reconfiguration notification chains should be exported for use
by modules.
Signed-off-by:Nathan Fontenot
---
Index: linux-next/drivers/of/base.c
===
--- linux-next.orig/drivers/of/base.c 2012-11-28 09:18:02.0 -0600
+
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC
012 05:44 PM, Wen Congyang wrote:
>>>>>> From: Yasuaki Ishimatsu
>>>>>>
>>>>>> Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
>>>>>> even if
>>>>>> we use SPARSEMEM_VMEMMAP, we
012 05:44 PM, Wen Congyang wrote:
>>>>>> From: Yasuaki Ishimatsu
>>>>>>
>>>>>> Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
>>>>>> even if
>>>>>> we use SPARSEMEM_VMEMMAP, we
SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related patches. Hot
add memory need allocated vmemmap pages, but
remove_section for SPARSEMEM_VMEMMAP does nothing. But
>>>> even if
>>>> we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
>>>>
>>>> So the patch add unregister_memory_section() into __remove_section().
>>> Hi Yasuaki,
>>>
On 11/21/2012 11:05 AM, Wen Congyang wrote:
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
> On 11/01/2012 05:44 PM, Wen Congyang wrote:
>> From: Yasuaki Ishimatsu
>>
>> Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
>> even if
>> we use SPARSEMEM_VMEMMAP, we can unregister the memor
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I
SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
In order to review this patch, I should dig sparse memory codes in
advance. But I have some confuse of codes. Why need
remove_section for SPARSEMEM_VMEMMAP does nothing. But
>>>> even if
>>>> we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
>>>>
>>>> So the patch add unregister_memory_section() into __remove_section().
>>> Hi Yasuaki,
>>>
&
On 11/20/2012 02:55 PM, Wen Congyang wrote:
At 11/20/2012 02:22 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki
At 11/20/2012 02:22 PM, Jaegeuk Hanse Wrote:
> On 11/01/2012 05:44 PM, Wen Congyang wrote:
>> From: Yasuaki Ishimatsu
>>
>> Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
>> even if
>> we use SPARSEMEM_VMEMMAP, we can unregister the memor
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC
From: Yasuaki Ishimatsu
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Christoph Lameter
Cc: Minchan
for each directory into the register/
>> unregister routines to avoid duplicating it with these updates.
>>
>> Signed-off-by: Nathan Fontenot
>> ---
>> drivers/base/memory.c | 93
>> +-
>> 1 file changed,
On Mon, 12 Jul 2010 10:44:10 -0500
Nathan Fontenot wrote:
> This patch moves the register/unregister_memory routines to
> avoid a forward declaration. It also moves the sysfs file
> creation and deletion for each directory into the register/
> unregister routines to avoid duplica
This patch moves the register/unregister_memory routines to
avoid a forward declaration. It also moves the sysfs file
creation and deletion for each directory into the register/
unregister routines to avoid duplicating it with these updates.
Signed-off-by: Nathan Fontenot
---
drivers/base
* Arun R Bharadwaj [2009-09-01 17:07:04]:
Implement a LIFO based approach for registering arch dependent
idle routines.
This is a prototype for pseries, needs to be extended
for other platforms.
Signed-off-by: Arun R Bharadwaj
---
arch/powerpc/kernel/idle.c |5 +
drivers/cpuidle/cpuid
On Friday 28 March 2008, Mark Lord wrote:
> Sergei Shtylyov wrote:
> > Bartlomiej Zolnierkiewicz wrote:
> >
> >> hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS
> >> and given the number of bugs we can assume that there are no real users
On Thursday 27 March 2008, Sergei Shtylyov wrote:
[...]
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
>
> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
Thanks for reviewing it.
> > Index: b/drivers/ide/ide-pnp.c
> > ===
Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS
and given the number of bugs we can assume that there are no real users:
..
There is the odd user of these, actually.
But the most recent to email me (a few weeks
Bartlomiej Zolnierkiewicz wrote:
hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS
and given the number of bugs we can assume that there are no real users:
* DMA has no chance of working because DMA resources are released by
ide_unregister() and they are never
hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS
and given the number of bugs we can assume that there are no real users:
* DMA has no chance of working because DMA resources are released by
ide_unregister() and they are never allocated again.
* Since
Routines to invalidate and unregister dump routines.
Unregister has not been used yet, I will release another
patch for that at a later stage with the kdump integration patches.
There is also a routine which calculates the regions to be
freed and exports that through sysfs.
Signed-off-by
Stephen,
>> +/* Add addr value if not initialized before */
>> +if (ph->cpu_data.destination_address == 0) {
>> +ph->cpu_data.destination_address += addr;
>
> Could be just '=' like further down, right?
Actually the one below should be += as well. Thanks for catching it.
>>
Hi Manish,
Just more trivial stuff.
On Mon, 07 Jan 2008 18:37:31 -0600 Manish Ahuja <[EMAIL PROTECTED]> wrote:
>
> static void register_dump_area(struct phyp_dump_header *ph, unsigned long
> addr)
> {
> int rc;
> - ph->cpu_data.destination_address += addr;
> - ph->hpte_data.desti
1 - 100 of 101 matches
Mail list logo
