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. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
