[PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Viresh Kumar]

global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64 bit systems.

Fix that by making global_lock an u32 instead.

Cc: <stable@vger.kernel.org>  # v4.1+
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

---
Its marked just for # v4.1+, because arm64 has the first 64 big-endian
platform with ACPI. And ACPI support for that is mainlined recently
only (Arnd Bergmann).

Another thing worth noticing is that, global_lock is getting an unsigned
long long value assigned to it in ec_parse_device() and this is what
Arnd had to say about that:

"I think that's fine, it does this because the _GLP variable in ACPI is
defined as an u64. And that's what happens on 32-bit architectures
anyway."

This patch should go via GregKH, as the second patch has dependency on
it.

V2->V3:
- Moved this out in a separate patch, so that it can be backported.
---
 drivers/acpi/ec_sys.c   | 2 +-
 drivers/acpi/internal.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b4c216bab22b..bea8e425a8de 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
 	if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
 		goto error;
 	if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
-				 (u32 *)&first_ec->global_lock))
+				 &first_ec->global_lock))
 		goto error;
 
 	if (write_support)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 9e426210c2a8..9db196de003c 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -138,7 +138,7 @@ struct acpi_ec {
 	unsigned long gpe;
 	unsigned long command_addr;
 	unsigned long data_addr;
-	unsigned long global_lock;
+	u32 global_lock;
 	unsigned long flags;
 	unsigned long reference_count;
 	struct mutex mutex;
-- 
2.4.0

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems.
> 
> Fix that by making global_lock an u32 instead.
> 
> Cc: <stable@vger.kernel.org>  # v4.1+
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> 
> ---
> Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> platform with ACPI. And ACPI support for that is mainlined recently
> only (Arnd Bergmann).

OK

So are you aware of any ARM platform implementing the ACPI EC?

I am not.  Moreover, I'm not aware of any plans in that area.

> Another thing worth noticing is that, global_lock is getting an unsigned
> long long value assigned to it in ec_parse_device() and this is what
> Arnd had to say about that:
> 
> "I think that's fine, it does this because the _GLP variable in ACPI is
> defined as an u64. And that's what happens on 32-bit architectures
> anyway."
> 
> This patch should go via GregKH, as the second patch has dependency on
> it.
> 
> V2->V3:
> - Moved this out in a separate patch, so that it can be backported.

Lv, can you have a look at this, please?

> ---
>  drivers/acpi/ec_sys.c   | 2 +-
>  drivers/acpi/internal.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..bea8e425a8de 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
>  	if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
>  		goto error;
>  	if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> -				 (u32 *)&first_ec->global_lock))
> +				 &first_ec->global_lock))
>  		goto error;
>  
>  	if (write_support)
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 9e426210c2a8..9db196de003c 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -138,7 +138,7 @@ struct acpi_ec {
>  	unsigned long gpe;
>  	unsigned long command_addr;
>  	unsigned long data_addr;
> -	unsigned long global_lock;
> +	u32 global_lock;
>  	unsigned long flags;
>  	unsigned long reference_count;
>  	struct mutex mutex;
> 

Thanks,
Rafael

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Viresh Kumar]

On 16-09-15, 04:06, Rafael J. Wysocki wrote:
> In any case, please just split the EC-related changes off from your second
> patch and send them separately.

That !! change isn't required anymore, will be dropping it completely.

-- 
viresh

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Rafael J. Wysocki]

On Wednesday, September 16, 2015 03:57:05 AM Rafael J. Wysocki wrote:
> On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems.
> > 
> > Fix that by making global_lock an u32 instead.
> > 
> > Cc: <stable@vger.kernel.org>  # v4.1+
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > 
> > ---
> > Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> > platform with ACPI. And ACPI support for that is mainlined recently
> > only (Arnd Bergmann).
> 
> OK
> 
> So are you aware of any ARM platform implementing the ACPI EC?
> 
> I am not.  Moreover, I'm not aware of any plans in that area.

In any case, please just split the EC-related changes off from your second
patch and send them separately.

Thanks,
Rafael

RE: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Zheng, Lv]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2969 bytes --]

Hi,

> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Wednesday, September 16, 2015 9:57 AM
> 
> On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems.
> >
> > Fix that by making global_lock an u32 instead.
> >
> > Cc: <stable@vger.kernel.org>  # v4.1+
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > ---
> > Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> > platform with ACPI. And ACPI support for that is mainlined recently
> > only (Arnd Bergmann).
> 
> OK
> 
> So are you aware of any ARM platform implementing the ACPI EC?
> 
> I am not.  Moreover, I'm not aware of any plans in that area.
> 
> > Another thing worth noticing is that, global_lock is getting an unsigned
> > long long value assigned to it in ec_parse_device() and this is what
> > Arnd had to say about that:
> >
> > "I think that's fine, it does this because the _GLP variable in ACPI is
> > defined as an u64. And that's what happens on 32-bit architectures
> > anyway."
> >
> > This patch should go via GregKH, as the second patch has dependency on
> > it.
> >
> > V2->V3:
> > - Moved this out in a separate patch, so that it can be backported.
> 
> Lv, can you have a look at this, please?
> 
> > ---
> >  drivers/acpi/ec_sys.c   | 2 +-
> >  drivers/acpi/internal.h | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> > index b4c216bab22b..bea8e425a8de 100644
> > --- a/drivers/acpi/ec_sys.c
> > +++ b/drivers/acpi/ec_sys.c
> > @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
> >  	if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> >  		goto error;
> >  	if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > -				 (u32 *)&first_ec->global_lock))
> > +				 &first_ec->global_lock))
> >  		goto error;
> >
> >  	if (write_support)
> > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> > index 9e426210c2a8..9db196de003c 100644
> > --- a/drivers/acpi/internal.h
> > +++ b/drivers/acpi/internal.h
> > @@ -138,7 +138,7 @@ struct acpi_ec {
> >  	unsigned long gpe;
> >  	unsigned long command_addr;
> >  	unsigned long data_addr;
> > -	unsigned long global_lock;
> > +	u32 global_lock;
> >  	unsigned long flags;
> >  	unsigned long reference_count;
> >  	struct mutex mutex;
> >
> 

If we really want to change, we may change everything here.
gpe/command_addr/data_addr/global_lock.
And IMO, if we really want to change global_lock, we should make it bool here.

Thanks and best regards
-Lv

> Thanks,
> Rafael

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Sudeep Holla]

On 15/09/15 09:34, Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems.
>
> Fix that by making global_lock an u32 instead.
>
> Cc: <stable@vger.kernel.org>  # v4.1+
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> ---
> Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> platform with ACPI. And ACPI support for that is mainlined recently
> only (Arnd Bergmann).
>

Just to clarify, we don't support big-endian with ACPI on ARM64.
We mandate use of EFI for ACPI on ARM64 and EFI spec mandates only
little endian.

Regards,
Sudeep

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Arnd Bergmann]

On Wednesday 23 September 2015 10:15:42 Sudeep Holla wrote:
> On 15/09/15 09:34, Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems.
> >
> > Fix that by making global_lock an u32 instead.
> >
> > Cc: <stable@vger.kernel.org>  # v4.1+
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > ---
> > Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> > platform with ACPI. And ACPI support for that is mainlined recently
> > only (Arnd Bergmann).
> >
> 
> Just to clarify, we don't support big-endian with ACPI on ARM64.
> We mandate use of EFI for ACPI on ARM64 and EFI spec mandates only
> little endian.
> 

EFI doesn't care what endianess the kernel has, as long as the
data structures are interpreted in the same way that the firmware
defines them, and I thought that at least UEFI on ARM64 with big-endian
is working in principle (if not, that is a bug that should be fixed).

If ACPI is broken with big-endian kernels, we should probably add a
Kconfig statement to forbid it, like this:

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5d1015c26ff4..06cacc13e3d2 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -6,6 +6,7 @@ menuconfig ACPI
 	bool "ACPI (Advanced Configuration and Power Interface) Support"
 	depends on !IA64_HP_SIM
 	depends on IA64 || X86 || (ARM64 && EXPERT)
+	depends on !ARM64 || !CPU_BIG_ENDIAN || BROKEN
 	depends on PCI
 	select PNP
 	default y


	Arnd

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Sudeep Holla]

On 23/09/15 10:39, Arnd Bergmann wrote:
> On Wednesday 23 September 2015 10:15:42 Sudeep Holla wrote:
>> On 15/09/15 09:34, Viresh Kumar wrote:
>>> global_lock is defined as an unsigned long and accessing only its lower
>>> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
>>> for big endian 64 bit systems.
>>>
>>> Fix that by making global_lock an u32 instead.
>>>
>>> Cc: <stable@vger.kernel.org>  # v4.1+
>>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>>>
>>> ---
>>> Its marked just for # v4.1+, because arm64 has the first 64 big-endian
>>> platform with ACPI. And ACPI support for that is mainlined recently
>>> only (Arnd Bergmann).
>>>
>>
>> Just to clarify, we don't support big-endian with ACPI on ARM64.
>> We mandate use of EFI for ACPI on ARM64 and EFI spec mandates only
>> little endian.
>>
>
> EFI doesn't care what endianess the kernel has, as long as the
> data structures are interpreted in the same way that the firmware
> defines them, and I thought that at least UEFI on ARM64 with big-endian
> is working in principle (if not, that is a bug that should be fixed).
>
> If ACPI is broken with big-endian kernels, we should probably add a
> Kconfig statement to forbid it, like this:
>

The diff looks sensible thing to have to avoid enabling ACPI with BE
though I am not sure if this can be regarded as broken as it could be
case of just not supported(my guess as I am not completely aware of the
history).

Also I am not against the $subject patch as such, just added
clarification so that it shouldn't be assumed that BE + ACPI works on
ARM64.

Regards,
Sudeep

> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 5d1015c26ff4..06cacc13e3d2 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -6,6 +6,7 @@ menuconfig ACPI
>   	bool "ACPI (Advanced Configuration and Power Interface) Support"
>   	depends on !IA64_HP_SIM
>   	depends on IA64 || X86 || (ARM64 && EXPERT)
> +	depends on !ARM64 || !CPU_BIG_ENDIAN || BROKEN
>   	depends on PCI
>   	select PNP
>   	default y
>
>
> 	Arnd
>

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Arnd Bergmann]

On Wednesday 23 September 2015 10:57:44 Sudeep Holla wrote:
> 
> Also I am not against the $subject patch as such, just added
> clarification so that it shouldn't be assumed that BE + ACPI works on
> ARM64.
> 

Ok, at least we can safely assume that we do not need to backport that
patch to stable then.

	Arnd

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Viresh Kumar]

On 23-09-15, 07:52, Zheng, Lv wrote:
> And IMO, if we really want to change global_lock, we should make it bool here.

Yeah, so the second patch in this series is doing just that. Just kept
this patch separate to make more sense. Will resend both and keep you
in cc.

-- 
viresh

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Viresh Kumar]

On 25-09-15, 02:17, Rafael J. Wysocki wrote:
> Actually, what about adding a local u32 variable, say val, here and doing
> 
> >  	if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> >  		goto error;
> >  	if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > -				 (u32 *)&first_ec->global_lock))
> > +				 &first_ec->global_lock))
> 
> 	if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
> 
> >  		goto error;
> 
> 	first_ec->global_lock = val;
> 
> And then you can turn val into bool just fine without changing the structure
> definition.

sure. Looks good.

-- 
viresh

Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'

[Rafael J. Wysocki]

On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems.
> 
> Fix that by making global_lock an u32 instead.
> 
> Cc: <stable@vger.kernel.org>  # v4.1+
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> 
> ---
> Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> platform with ACPI. And ACPI support for that is mainlined recently
> only (Arnd Bergmann).
> 
> Another thing worth noticing is that, global_lock is getting an unsigned
> long long value assigned to it in ec_parse_device() and this is what
> Arnd had to say about that:
> 
> "I think that's fine, it does this because the _GLP variable in ACPI is
> defined as an u64. And that's what happens on 32-bit architectures
> anyway."
> 
> This patch should go via GregKH, as the second patch has dependency on
> it.
> 
> V2->V3:
> - Moved this out in a separate patch, so that it can be backported.
> ---
>  drivers/acpi/ec_sys.c   | 2 +-
>  drivers/acpi/internal.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..bea8e425a8de 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)

Actually, what about adding a local u32 variable, say val, here and doing

>  	if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
>  		goto error;
>  	if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> -				 (u32 *)&first_ec->global_lock))
> +				 &first_ec->global_lock))

	if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))

>  		goto error;

	first_ec->global_lock = val;

And then you can turn val into bool just fine without changing the structure
definition.

>  
>  	if (write_support)
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 9e426210c2a8..9db196de003c 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -138,7 +138,7 @@ struct acpi_ec {
>  	unsigned long gpe;
>  	unsigned long command_addr;
>  	unsigned long data_addr;
> -	unsigned long global_lock;
> +	u32 global_lock;
>  	unsigned long flags;
>  	unsigned long reference_count;
>  	struct mutex mutex;
> 

Thanks,
Rafael