[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAE=gft6q8ELJCN5JU5svS6cYHO65GMFKTVrHT9wu_mpr-j1-xw@mail.gmail.com>
Date: Tue, 10 Apr 2018 17:05:23 +0000
From: Evan Green <evgreen@...omium.org>
To: sboyd@...nel.org
Cc: tdas@...eaurora.org, sboyd@...eaurora.org,
Michael Turquette <mturquette@...libre.com>,
Andy Gross <andy.gross@...aro.org>,
David Brown <david.brown@...aro.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
okukatla@...eaurora.org, anischal@...eaurora.org,
linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
collinsd@...eaurora.org
Subject: Re: [PATCH 1/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver
On Thu, Apr 5, 2018 at 4:17 PM Stephen Boyd <sboyd@...nel.org> wrote:
> Quoting Taniya Das (2018-04-02 03:33:26)
> >
> > >
> > >> +
> > >> +#include "common.h"
> > >> +#include "clk-regmap.h"
> > >> +
> > >> +#define CLK_RPMH_ARC_EN_OFFSET 0
> > >> +#define CLK_RPMH_VRM_EN_OFFSET 4
> > >> +#define CLK_RPMH_VRM_OFF_VAL 0
> > >> +#define CLK_RPMH_VRM_ON_VAL 1
> > >> +#define CLK_RPMH_APPS_RSC_AO_STATE_MASK (BIT(RPMH_WAKE_ONLY_STATE)
| \
> > >> + BIT(RPMH_ACTIVE_ONLY_STATE))
> > >> +#define CLK_RPMH_APPS_RSC_STATE_MASK (BIT(RPMH_WAKE_ONLY_STATE) | \
> > >> + BIT(RPMH_ACTIVE_ONLY_STATE) | \
> > >> + BIT(RPMH_SLEEP_STATE))
> > >> +struct clk_rpmh {
> > >> + const char *res_name;
> > >> + u32 res_addr;
> > >> + u32 res_en_offset;
> > >> + u32 res_on_val;
> > >> + u32 res_off_val;
> > >> + u32 state;
> > >> + u32 aggr_state;
> > >> + u32 last_sent_aggr_state;
> > >> + u32 valid_state_mask;
> > >> + struct rpmh_client *rpmh_client;
> > >> + unsigned long rate;
> > >> + struct clk_rpmh *peer;
> > >> + struct clk_hw hw;
> > >
> > > I believe this member should go at the beginning of the structure. At
least
> > > that's what everyone else seems to do, and that's what the clk.txt
> > > documentation seems to ask for.
> > >
> >
> > Yes I missed that, would update it in the next patch series.
> Where is the documentation asking for that? There isn't any place that
> clk_hw should be in a structure. container_of() can figure it out all
> the time, and that macro is preferred instead of plain casts from one
> type to another because it provides slightly more type safety.
Perhaps I'm reading too strictly into the documentation, but this was the
passage that gave me that idea:
To construct a clk hardware structure for your platform you must define
the following::
struct clk_foo {
struct clk_hw hw;
... hardware specific data goes here ...
};
-Evan
Powered by blists - more mailing lists