On Mon, Oct 22, 2012 at 11:11 AM, KOSAKI Motohiro
wrote:
>>> ??
>>> If resource was not allocated a driver, a driver doesn't need to
>>> deallocate it when
>>> error path. I haven't caught your point.
>>>
>>
>> REMOVAL_NORMAL can be in 2 cases:
>> 1. error path. If init call fails, we don't call
>> ??
>> If resource was not allocated a driver, a driver doesn't need to
>> deallocate it when
>> error path. I haven't caught your point.
>>
>
> REMOVAL_NORMAL can be in 2 cases:
> 1. error path. If init call fails, we don't call it. We call this function
>only when something fails after
??
If resource was not allocated a driver, a driver doesn't need to
deallocate it when
error path. I haven't caught your point.
REMOVAL_NORMAL can be in 2 cases:
1. error path. If init call fails, we don't call it. We call this function
only when something fails after init.
2. unbind
On Mon, Oct 22, 2012 at 11:11 AM, KOSAKI Motohiro
kosaki.motoh...@jp.fujitsu.com wrote:
??
If resource was not allocated a driver, a driver doesn't need to
deallocate it when
error path. I haven't caught your point.
REMOVAL_NORMAL can be in 2 cases:
1. error path. If init call fails, we
At 10/20/2012 02:19 AM, KOSAKI Motohiro Wrote:
>> Hmm, IIRC, if the memory is recognized from kerenl before driver
>> initialization,
>> the memory device is not managed by the driver acpi_memhotplug.
>
> Yup.
>
>
>> I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will
> Hmm, IIRC, if the memory is recognized from kerenl before driver
> initialization,
> the memory device is not managed by the driver acpi_memhotplug.
Yup.
> I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will
> cause
> some critical problem: we unbind the device from
At 10/19/2012 03:44 AM, KOSAKI Motohiro Wrote:
>> + if (type == ACPI_BUS_REMOVAL_EJECT) {
>> + /*
>> +* offline and remove memory only when the memory device
>> is
>> +* ejected.
>> +*/
>
> This
At 10/18/2012 09:25 AM, Yasuaki Ishimatsu Wrote:
> Hi Wen,
>
> 2012/10/17 18:52, Wen Congyang wrote:
>> At 10/17/2012 05:18 PM, KOSAKI Motohiro Wrote:
Hmm, it doesn't move the code. It just reuse the code in
acpi_memory_powerdown_device().
>>>
>>> Even if reuse or not
At 10/18/2012 09:25 AM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/10/17 18:52, Wen Congyang wrote:
At 10/17/2012 05:18 PM, KOSAKI Motohiro Wrote:
Hmm, it doesn't move the code. It just reuse the code in
acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If
At 10/19/2012 03:44 AM, KOSAKI Motohiro Wrote:
+ if (type == ACPI_BUS_REMOVAL_EJECT) {
+ /*
+* offline and remove memory only when the memory device
is
+* ejected.
+*/
This comment explain nothing. A comment should
Hmm, IIRC, if the memory is recognized from kerenl before driver
initialization,
the memory device is not managed by the driver acpi_memhotplug.
Yup.
I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will
cause
some critical problem: we unbind the device from the
At 10/20/2012 02:19 AM, KOSAKI Motohiro Wrote:
Hmm, IIRC, if the memory is recognized from kerenl before driver
initialization,
the memory device is not managed by the driver acpi_memhotplug.
Yup.
I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will
cause
some
> + if (type == ACPI_BUS_REMOVAL_EJECT) {
> + /*
> +* offline and remove memory only when the memory device
> is
> +* ejected.
> +*/
This comment explain nothing. A comment should describe _why_
+ if (type == ACPI_BUS_REMOVAL_EJECT) {
+ /*
+* offline and remove memory only when the memory device
is
+* ejected.
+*/
This comment explain nothing. A comment should describe _why_ should we do.
e.g. Why REMOVAL_NORMAL
Hi Wen,
2012/10/17 18:52, Wen Congyang wrote:
At 10/17/2012 05:18 PM, KOSAKI Motohiro Wrote:
Hmm, it doesn't move the code. It just reuse the code in
acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If any changes
has no good rational, you cannot get an
At 10/17/2012 05:18 PM, KOSAKI Motohiro Wrote:
>> Hmm, it doesn't move the code. It just reuse the code in
>> acpi_memory_powerdown_device().
>
> Even if reuse or not reuse, you changed the behavior. If any changes
> has no good rational, you cannot get an ack.
I
> Hmm, it doesn't move the code. It just reuse the code in
> acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If any changes
has no good rational, you cannot get an ack.
>>>
>>> I don't understand this? IIRC, the behavior isn't changed.
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device
*mem_device)
{
int result;
struct acpi_memory_info
At 10/17/2012 04:59 PM, KOSAKI Motohiro Wrote:
> On Wed, Oct 17, 2012 at 2:48 AM, Wen Congyang wrote:
>> At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
>> -static int acpi_memory_disable_device(struct acpi_memory_device
>> *mem_device)
>> +static int acpi_memory_remove_memory(struct
On Wed, Oct 17, 2012 at 2:48 AM, Wen Congyang wrote:
> At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
> -static int acpi_memory_disable_device(struct acpi_memory_device
> *mem_device)
> +static int acpi_memory_remove_memory(struct acpi_memory_device
> *mem_device)
> {
>
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device
*mem_device)
{
int result;
struct acpi_memory_info
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device
*mem_device)
{
int result;
struct acpi_memory_info *info, *n;
+
On Wed, Oct 17, 2012 at 2:48 AM, Wen Congyang we...@cn.fujitsu.com wrote:
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device
*mem_device)
{
At 10/17/2012 04:59 PM, KOSAKI Motohiro Wrote:
On Wed, Oct 17, 2012 at 2:48 AM, Wen Congyang we...@cn.fujitsu.com wrote:
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device
*mem_device)
{
int result;
struct acpi_memory_info *info, *n;
+
Hmm, it doesn't move the code. It just reuse the code in
acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If any changes
has no good rational, you cannot get an ack.
I don't understand this? IIRC, the behavior isn't changed.
Heh, please explain why do
At 10/17/2012 05:18 PM, KOSAKI Motohiro Wrote:
Hmm, it doesn't move the code. It just reuse the code in
acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If any changes
has no good rational, you cannot get an ack.
I don't understand this? IIRC, the
Hi Wen,
2012/10/17 18:52, Wen Congyang wrote:
At 10/17/2012 05:18 PM, KOSAKI Motohiro Wrote:
Hmm, it doesn't move the code. It just reuse the code in
acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If any changes
has no good rational, you cannot get an
>>> -static int acpi_memory_disable_device(struct acpi_memory_device
>>> *mem_device)
>>> +static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
>>> {
>>> int result;
>>> struct acpi_memory_info *info, *n;
>>>
>>> + list_for_each_entry_safe(info, n,
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
{
int result;
struct acpi_memory_info *info, *n;
+ list_for_each_entry_safe(info, n, mem_device-res_list, list)
At 10/05/2012 04:53 AM, KOSAKI Motohiro Wrote:
> On Wed, Oct 3, 2012 at 5:58 AM, Yasuaki Ishimatsu
> wrote:
>> From: Yasuaki Ishimatsu
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case,
At 10/05/2012 04:53 AM, KOSAKI Motohiro Wrote:
On Wed, Oct 3, 2012 at 5:58 AM, Yasuaki Ishimatsu
isimatu.yasu...@jp.fujitsu.com wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1
On Wed, Oct 3, 2012 at 5:58 AM, Yasuaki Ishimatsu
wrote:
> From: Yasuaki Ishimatsu
>
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> In the 1st case, acpi_memory_disable_device() will be called.
> In the 2nd
On Wed, Oct 3, 2012 at 5:58 AM, Yasuaki Ishimatsu
isimatu.yasu...@jp.fujitsu.com wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 /sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case,
From: Yasuaki Ishimatsu
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 /sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be
36 matches
Mail list logo
