lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <508585f7-6c2b-3b33-ada8-91cc15ed683e@gmail.com>
Date:   Fri, 8 Jan 2021 01:05:04 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Nick Dyer <nick@...anahar.org>, Rob Herring <robh+dt@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jiada Wang <jiada_wang@...tor.com>,
        linux-input@...r.kernel.org, devicetree@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/3] Support wakeup methods of Atmel maXTouch
 controllers

13.12.2020 12:26, Dmitry Osipenko пишет:
> 13.12.2020 07:41, Dmitry Torokhov пишет:
>> Thank you for the logs. I am confused where these calls to put the
>> controller into deep sleep are coming from. Does something constantly
>> open and close input device?
> 
> Input devices are re-opened multiple times during Linux distro boot-up,
> a regular Ubuntu 20.10 in this case.
> 
>> Do you have any additional patches?
> 
> No, I'm using next-20201211 + this "wakeup methods" patchset.
> 
>> We definitely do not issue deep sleep request in mxt_start(). Do you mind
>> putting dump_stack() into mxt_set_t7_power_cfg() to see where the calls
>> are coming from?
> 
> Please see the log below, I added it like this:
> 
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index e3342fdfe9f3..bbc5a5ee158a 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2271,6 +2271,8 @@ static int mxt_set_t7_power_cfg(struct mxt_data
> *data, u8 sleep)
>  	dev_dbg(dev, "Set T7 ACTV:%d IDLE:%d\n",
>  		new_config->active, new_config->idle);
> 
> +	dump_stack();
> +
>  	return 0;
>  }
> 
>> I also do not see additional "waking up controller" messages after
>> requesting the chip via T7 to be configured to be active, which I'd
>> expected to see if we indeed needed to wake it up again for T6 to
>> succeed.
> 
> I'm not familiar with what controller does internally, hence no clue.
> 
> 
> [ 1.195295] Family: 160 Variant: 0 Firmware V1.0.AA Objects: 18
> [ 1.195468] T37 Start:118 Size:130 Instances:1 Report IDs:0-0
...
Dmitry Torokhov, do you have any more comments? Are you okay with v3? If
yes, could you please pick up patches into -next?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ