Hi, On Thu, 2017-10-19 at 11:54 -0700, Bjorn Andersson wrote: > On Wed 19 Jul 08:59 PDT 2017, Philipp Zabel wrote: > > > From: Vivek Gautam <vivek.gautam@xxxxxxxxxxxxxx> > > > > Many devices may want to request a bunch of resets and control them. So > > it's better to manage them as an array. Add APIs to _get() an array of > > reset_control, reusing the _assert(), _deassert(), and _reset() APIs for > > single reset controls. Since reset controls already may control multiple > > reset lines with a single hardware bit, from the user perspective, reset > > control arrays are not at all different from single reset controls. > > Note that these APIs don't guarantee that the reset lines managed in the > > array are handled in any particular order. > > > > Cc: Felipe Balbi <balbi@xxxxxxxxxx> > > Cc: Jon Hunter <jonathanh@xxxxxxxxxx> > > Signed-off-by: Vivek Gautam <vivek.gautam@xxxxxxxxxxxxxx> > > [p.zabel@xxxxxxxxxxxxxx: changed API to hide reset control arrays behind > > struct reset_control] > > Signed-off-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> > > This looks more or less identical to how regulators and clocks already > deals with resources in bulk; see regulator_bulk_data and clk_bulk_data > and their associated functions. > > I would really like to see that you follow this model, to make it easier > for developers to work with and use the various subsystems. These APIs have two undesirable (in this case) properties; the driver has to know the number of resets and their identifiers in advance, and singular resets and bulk reset arrays can't be used interchangeably. Both are not well suited to this use case, which is "triggering one or any number of anonymous resets together". I have nothing against adding a bulk API as well. There are already users such as the pcie-qcom driver that could profit from it. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
