[<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
 
