[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a11d60af-3a67-6a76-57ae-7cb9bad13bed@gmail.com>
Date: Fri, 28 Aug 2020 11:30:25 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Chanwoo Choi <cw00.choi@...sung.com>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Georgi Djakov <georgi.djakov@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Peter De Schrijver <pdeschrijver@...dia.com>,
MyungJoo Ham <myungjoo.ham@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Mikko Perttunen <cyndis@...si.fi>
Cc: linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v5 13/36] PM / devfreq: tegra30: Use MC timings for
building OPP table
28.08.2020 04:47, Chanwoo Choi пишет:
> Hi,
...
>> Hence the NULL-checking is unnecessary.
>>
>> When I first encountered the of_device_get_match_data(), I was also
>> thinking that adding the NULL-checks is a good idea, but later on
>> somebody pointed out to me (maybe Thierry) that it's unnecessary to do.
>
> OK. Thanks.
>
>>
>>>> +
>>>> + mc = tegra_get_memory_controller(soc_data->mc_compatible);
>>>> + if (IS_ERR(mc))
>>>> + return PTR_ERR(mc);
>>>
>>> You better to add error log.
>>
>> In practice we should get only -EPROBE_DEFER here ever. I'll consider
>> adding the message in the next revision, at least just for consistency.
>
> In order to handle -EPROBE_DEFER, recommend the using of dev_err_probe().
Hello, Chanwoo!
Thank you for the suggestion! I wasn't aware about the dev_err_probe()
until recently and will use this new helper in the v6!
Thanks!
Powered by blists - more mailing lists