[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ceefc854-5d15-b73c-0135-c1cbbbb473b7@gmail.com>
Date: Wed, 10 Nov 2021 16:38:07 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Jonathan Neuschäfer <j.neuschaefer@....net>
Cc: Guenter Roeck <linux@...ck-us.net>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Lee Jones <lee.jones@...aro.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Mark Brown <broonie@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Russell King <linux@...linux.org.uk>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Guo Ren <guoren@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Greg Ungerer <gerg@...ux-m68k.org>,
Joshua Thompson <funaho@...ai.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Nick Hu <nickhu@...estech.com>,
Greentime Hu <green.hu@...il.com>,
Vincent Chen <deanbo422@...il.com>,
Helge Deller <deller@....de>,
Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Len Brown <lenb@...nel.org>,
Santosh Shilimkar <ssantosh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
Linus Walleij <linus.walleij@...aro.org>,
Chen-Yu Tsai <wens@...e.org>, Tony Lindgren <tony@...mide.com>,
Liam Girdwood <lgirdwood@...il.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Vladimir Zapolskiy <vz@...ia.com>,
Avi Fishman <avifishman70@...il.com>,
Tomer Maimon <tmaimon77@...il.com>,
Tali Perry <tali.perry1@...il.com>,
Patrick Venture <venture@...gle.com>,
Nancy Yuen <yuenn@...gle.com>,
Benjamin Fair <benjaminfair@...gle.com>,
Pavel Machek <pavel@....cz>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-csky@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org,
linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-riscv@...ts.infradead.org, linux-sh@...r.kernel.org,
xen-devel@...ts.xenproject.org, linux-acpi@...r.kernel.org,
linux-omap@...r.kernel.org, openbmc@...ts.ozlabs.org,
linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 27/45] mfd: ntxec: Use devm_register_power_handler()
10.11.2021 13:43, Jonathan Neuschäfer пишет:
> On Mon, Nov 08, 2021 at 02:36:42PM +0300, Dmitry Osipenko wrote:
>> 08.11.2021 14:22, Jonathan Neuschäfer пишет:
>>> On Sun, Nov 07, 2021 at 08:42:33PM +0300, Dmitry Osipenko wrote:
>>> [...]
>>>> EC drivers tend to use higher priority in general. Jonathan, could you
>>>> please confirm that NTXEC driver is a more preferable restart method
>>>> than the watchdog?
>>>
>>> Yes. The original firmware uses the NTXEC to restart, and it works well,
>>> so I do think it's preferable.
>>
>> Thank you, then I'll update the NTXEC patch like this:
>>
>> https://github.com/grate-driver/linux/commit/22da3d91f1734d9a0ed036220ad4ea28465af988
>
> I tested again, but sys_off_handler_reboot called a bogus pointer
> (probably reboot_prepare_cb). I think it was left uninitialized in
> ntxec_probe, which uses devm_kmalloc. I guess we could switch it to
> devm_kzalloc:
>
> diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
> index 1f55dfce14308..30364beb4b1d0 100644
> --- a/drivers/mfd/ntxec.c
> +++ b/drivers/mfd/ntxec.c
> @@ -144,7 +144,7 @@ static int ntxec_probe(struct i2c_client *client)
> const struct mfd_cell *subdevs;
> size_t n_subdevs;
>
> - ec = devm_kmalloc(&client->dev, sizeof(*ec), GFP_KERNEL);
> + ec = devm_kzalloc(&client->dev, sizeof(*ec), GFP_KERNEL);
> if (!ec)
> return -ENOMEM;
>
>
>
> With that done, it works flawlessly.
Good catch, thank you! I'll correct this patch and add yours t-b.
Powered by blists - more mailing lists