在 2021/1/2 上午1:09, Barnabás Pőcze 写道:
> Hi
>
>
> 2021. január 1., péntek 17:08 keltezéssel, Jiaxun Yang írta:
>
>> [...]
>>>> @@ -1006,6 +1018,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
>>>> if (!priv->has_hw_rfkill_switch)
>>>> write_ec_cmd(priv->adev->handle, VPCCMD_W_RF, 1);
>>>>
>>>> + /* The same for Touchpad */
>>>> + if (!priv->has_touchpad_switch)
>>>> + write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, 1);
>>>> +
>>> Shouldn't it be the other way around: `if (priv->has_touchpad_switch)`?
>> It is to prevent accidentally disable touchpad on machines that do have EC switch,
>> so it's intentional.
>> [...]
> Sorry, but the explanation not fully clear to me. The commit message seems to
> indicate that some models "do not use EC to switch touchpad", and I take that
> means that reading from VPCCMD_R_TOUCHPAD will not reflect the actual state of the
> touchpad and writing to VPCCMD_W_TOUCHPAD will not change the state of the touchpad.
I'm just trying to prevent removing functionality on machines that
touchpad can be controlled
by EC but also equipped I2C HID touchpad. At least users will have a
functional touchpad
after that.
>
> But then why do you still write to VPCCMD_W_TOUCHPAD on devices where supposedly
> this does not have any effect (at least not the desired one)? And the part of the
> code I made my comment about only runs on machines on which the touchpad supposedly
> cannot be controlled by the EC. What am I missing?
>
> And there is the other problem: on some machines, this patch removes working
> functionality.
Yeah that's a problem. I just don't want to repeat the story of rfkill
whitelist, it ends up with
countless machine to be added.
Maybe I should specify HID of touchpad as well. Two machines that known
to be problematic
all have ELAN0634 touchpad.
Thanks.
- Jiaxun
>
>
> Regards,
> Barnabás Pőcze
The patch titled
Subject: lib/zlib: fix inflating zlib streams on s390
has been removed from the -mm tree. Its filename was
lib-zlib-fix-inflating-zlib-streams-on-s390.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Ilya Leoshkevich <iii(a)linux.ibm.com>
Subject: lib/zlib: fix inflating zlib streams on s390
Decompressing zlib streams on s390 fails with "incorrect data check"
error.
Userspace zlib checks inflate_state.flags in order to byteswap checksums
only for zlib streams, and s390 hardware inflate code, which was ported
from there, tries to match this behavior. At the same time, kernel zlib
does not use inflate_state.flags, so it contains essentially random
values. For many use cases either zlib stream is zeroed out or checksum
is not used, so this problem is masked, but at least SquashFS is still
affected.
Fix by always passing a checksum to and from the hardware as is, which
matches zlib_inflate()'s expectations.
Link: https://lkml.kernel.org/r/20201215155551.894884-1-iii@linux.ibm.com
Fixes: 126196100063 ("lib/zlib: add s390 hardware support for kernel zlib_inflate")
Signed-off-by: Ilya Leoshkevich <iii(a)linux.ibm.com>
Tested-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Acked-by: Mikhail Zaslonko <zaslonko(a)linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger(a)de.ibm.com>
Cc: Heiko Carstens <hca(a)linux.ibm.com>
Cc: Vasily Gorbik <gor(a)linux.ibm.com>
Cc: Mikhail Zaslonko <zaslonko(a)linux.ibm.com>
Cc: <stable(a)vger.kernel.org> [5.6+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/zlib_dfltcc/dfltcc_inflate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/lib/zlib_dfltcc/dfltcc_inflate.c~lib-zlib-fix-inflating-zlib-streams-on-s390
+++ a/lib/zlib_dfltcc/dfltcc_inflate.c
@@ -125,7 +125,7 @@ dfltcc_inflate_action dfltcc_inflate(
param->ho = (state->write - state->whave) & ((1 << HB_BITS) - 1);
if (param->hl)
param->nt = 0; /* Honor history for the first block */
- param->cv = state->flags ? REVERSE(state->check) : state->check;
+ param->cv = state->check;
/* Inflate */
do {
@@ -138,7 +138,7 @@ dfltcc_inflate_action dfltcc_inflate(
state->bits = param->sbb;
state->whave = param->hl;
state->write = (param->ho + param->hl) & ((1 << HB_BITS) - 1);
- state->check = state->flags ? REVERSE(param->cv) : param->cv;
+ state->check = param->cv;
if (cc == DFLTCC_CC_OP2_CORRUPT && param->oesc != 0) {
/* Report an error if stream is corrupted */
state->mode = BAD;
_
Patches currently in -mm which might be from iii(a)linux.ibm.com are