[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190124064515.yimgprg5hzsfghc6@vireshk-i7>
Date: Thu, 24 Jan 2019 12:15:15 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Rajendra Nayak <rnayak@...eaurora.org>,
Stephen Boyd <swboyd@...omium.org>, andy.gross@...aro.org,
david.brown@...aro.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH] soc: qcom: update config dependencies for QCOM_RPMPD
On 23-01-19, 06:22, Guenter Roeck wrote:
> See Documentation/kobject.txt.
>
> "One important point cannot be overstated: every kobject must have a
> release() method, and the kobject must persist (in a consistent state)
> until that method is called. If these constraints are not met, the code is
> flawed. Note that the kernel will warn you if you forget to provide a
> release() method. Do not try to get rid of this warning by providing an
> "empty" release function.
>
> If all your cleanup function needs to do is call kfree(), then you must
> create a wrapper function which uses container_of() to upcast to the correct
> type (as shown in the example above) and then calls kfree() on the overall
> structure."
Guenter, you are of course correct but I am not sure what else we can
do here. In the most common case device & kobject are allocated along
with the real entity, like struct genpd here, and we free those from
the release routine (i.e. kfree(genpd)). But in our case most of the
times the genpd is created statically by platform drivers and not by
the genpd core, and so we can't free it from release().
Over that the genpd->dev is only used by the OPP core currently and
the device isn't even registered with the device core.
--
viresh
Powered by blists - more mailing lists