[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+Ln22FCH-q-joG6i=K2u=3vZTwwytkk0Q48oKekGkVb+VtL3Q@mail.gmail.com>
Date: Wed, 16 Oct 2019 20:43:37 +0900
From: Tomasz Figa <tomasz.figa@...il.com>
To: Markus Elfring <Markus.Elfring@....de>
Cc: "open list:COMMON CLK FRAMEWORK" <linux-clk@...r.kernel.org>,
"moderated list:SAMSUNG SOC CLOCK DRIVERS"
<linux-samsung-soc@...r.kernel.org>,
kernel-janitors@...r.kernel.org,
Chanwoo Choi <cw00.choi@...sung.com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Aditya Pakki <pakki001@....edu>, Kangjie Lu <kjlu@....edu>,
Navid Emamdoost <emamd001@....edu>,
Stephen McCamant <smccaman@....edu>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll()
2019年10月16日(水) 2:55 Markus Elfring <Markus.Elfring@....de>:
>
> > That said, there is no need to print any warnings or error messages on
> > allocation failure, so technically they could be removed.
>
> Do you find information sufficient from the Linux allocation failure report?
A backtrace should be enough for this kind of a failure that shouldn't
normally happen and if happens, then the rest of the system must be in
a state already about to fail anyway.
Best regards,
Tomasz
Powered by blists - more mailing lists