Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/04/2017 06:17 PM, Philipp Zabel wrote:

Hi Vivek,

On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

[...]

Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.

Ok, understood.
I think the smaller footprint API is more convenient for the user.

[...]

+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.

Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
 const char * const rst_names[] = {
   "rst1", "rst2" ...
 };
 xyz_data = {
   .resets = rst_names;
   .num = ARRAY_SIZE(rst_names);
 };
and then the driver making use of reset_control_array APIs
to request this list of reset controls and assert/deassert them.

I am assuming this case when one user driver is used across a bunch
of platforms with different number of resets available.
We may not want to rely solely on the device tree entries, since
the resets can be mandatory in few cases and we may want to
return failure.

The way I understood the array API was as a method of handling a list of
anonymous resets, specified as

resets = < 1>, < 2>, < 3>;
// reset-names = "rst1", "rst2", "rst3"; /* don't care */

in the device tree.

Now if you want to handle a partial list of those as an unordered list,
with special consideration for others, that could be added as a separate
API when there is use for it. But I expect that most potential users of
this array API will not have to make such a distinction.


Alright, I will modify the array APIs as suggested to handle an
unordered list of resets passed from the device tree.
As you said, we can handle the special cases when the need arise.




@@ -85,6 +107,39 @@ static inline struct reset_control 
*__devm_reset_control_get(
return -ENOTSUPP;
   }
   
+static inline int reset_control_array_assert(int num_rsts,

+   struct reset_control_array *resets)
+{
+   return 0;
+}
+
+static inline int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   return 0;
+}

Is this missing a stub for reset_control_array_get?

No, that's supposed to be a static function.

Oh right, it is static. Please ignore.


Thanks


regards
Philipp



Best Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/04/2017 06:17 PM, Philipp Zabel wrote:

Hi Vivek,

On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

[...]

Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.

Ok, understood.
I think the smaller footprint API is more convenient for the user.

[...]

+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.

Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
 const char * const rst_names[] = {
   "rst1", "rst2" ...
 };
 xyz_data = {
   .resets = rst_names;
   .num = ARRAY_SIZE(rst_names);
 };
and then the driver making use of reset_control_array APIs
to request this list of reset controls and assert/deassert them.

I am assuming this case when one user driver is used across a bunch
of platforms with different number of resets available.
We may not want to rely solely on the device tree entries, since
the resets can be mandatory in few cases and we may want to
return failure.

The way I understood the array API was as a method of handling a list of
anonymous resets, specified as

resets = < 1>, < 2>, < 3>;
// reset-names = "rst1", "rst2", "rst3"; /* don't care */

in the device tree.

Now if you want to handle a partial list of those as an unordered list,
with special consideration for others, that could be added as a separate
API when there is use for it. But I expect that most potential users of
this array API will not have to make such a distinction.


Alright, I will modify the array APIs as suggested to handle an
unordered list of resets passed from the device tree.
As you said, we can handle the special cases when the need arise.




@@ -85,6 +107,39 @@ static inline struct reset_control 
*__devm_reset_control_get(
return -ENOTSUPP;
   }
   
+static inline int reset_control_array_assert(int num_rsts,

+   struct reset_control_array *resets)
+{
+   return 0;
+}
+
+static inline int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   return 0;
+}

Is this missing a stub for reset_control_array_get?

No, that's supposed to be a static function.

Oh right, it is static. Please ignore.


Thanks


regards
Philipp



Best Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Philipp Zabel]

Hi Vivek,

On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]
> > I'd prefer to mirror the gpiod API a little, and to have the number
> > contained in the array structure, similar to struct gpio_descs:
[...]
> Alright, i can update this.
> I took regulator_bulk interface as the reference, but now i see
> gpio_descs has a smaller footprint.

Ok, understood.
I think the smaller footprint API is more convenient for the user.

[...]
> >> + * Returns 0 on success or error number on failure
> >> + */
> >> +static int reset_control_array_get(struct device *dev, int num_rsts,
> >> +  struct reset_control_array *resets,
> >> +  bool shared, bool optional)
> > Can we make this count and return a pointer to the newly created array?
> >
> > static struct reset_controls *
> > reset_control_array_get(struct device *dev, bool shared, bool optional)
> > {
> > ...
> >
> > That way the consumer doesn't have to care about counting and array
> > allocation.
> 
> Just trying to think again in line with the regulator bulk APIs.
> Can't a user provide a list of reset controls as data and thus
> request reset controls with a "id" and num_resets available.
> 
> e.g.
> const char * const rst_names[] = {
>   "rst1", "rst2" ...
> };
> xyz_data = {
>   .resets = rst_names;
>   .num = ARRAY_SIZE(rst_names);
> };
> and then the driver making use of reset_control_array APIs
> to request this list of reset controls and assert/deassert them.
> 
> I am assuming this case when one user driver is used across a bunch
> of platforms with different number of resets available.
> We may not want to rely solely on the device tree entries, since
> the resets can be mandatory in few cases and we may want to
> return failure.

The way I understood the array API was as a method of handling a list of
anonymous resets, specified as

resets = < 1>, < 2>, < 3>;
// reset-names = "rst1", "rst2", "rst3"; /* don't care */

in the device tree.

Now if you want to handle a partial list of those as an unordered list,
with special consideration for others, that could be added as a separate
API when there is use for it. But I expect that most potential users of
this array API will not have to make such a distinction.

> >> @@ -85,6 +107,39 @@ static inline struct reset_control 
> >> *__devm_reset_control_get(
> >>return -ENOTSUPP;
> >>   }
> >>   
> >> +static inline int reset_control_array_assert(int num_rsts,
> >> +  struct reset_control_array *resets)
> >> +{
> >> +  return 0;
> >> +}
> >> +
> >> +static inline int reset_control_array_deassert(int num_rsts,
> >> +  struct reset_control_array *resets)
> >> +{
> >> +  return 0;
> >> +}
> > Is this missing a stub for reset_control_array_get?
> 
> No, that's supposed to be a static function.

Oh right, it is static. Please ignore.

regards
Philipp

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Philipp Zabel]

Hi Vivek,

On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]
> > I'd prefer to mirror the gpiod API a little, and to have the number
> > contained in the array structure, similar to struct gpio_descs:
[...]
> Alright, i can update this.
> I took regulator_bulk interface as the reference, but now i see
> gpio_descs has a smaller footprint.

Ok, understood.
I think the smaller footprint API is more convenient for the user.

[...]
> >> + * Returns 0 on success or error number on failure
> >> + */
> >> +static int reset_control_array_get(struct device *dev, int num_rsts,
> >> +  struct reset_control_array *resets,
> >> +  bool shared, bool optional)
> > Can we make this count and return a pointer to the newly created array?
> >
> > static struct reset_controls *
> > reset_control_array_get(struct device *dev, bool shared, bool optional)
> > {
> > ...
> >
> > That way the consumer doesn't have to care about counting and array
> > allocation.
> 
> Just trying to think again in line with the regulator bulk APIs.
> Can't a user provide a list of reset controls as data and thus
> request reset controls with a "id" and num_resets available.
> 
> e.g.
> const char * const rst_names[] = {
>   "rst1", "rst2" ...
> };
> xyz_data = {
>   .resets = rst_names;
>   .num = ARRAY_SIZE(rst_names);
> };
> and then the driver making use of reset_control_array APIs
> to request this list of reset controls and assert/deassert them.
> 
> I am assuming this case when one user driver is used across a bunch
> of platforms with different number of resets available.
> We may not want to rely solely on the device tree entries, since
> the resets can be mandatory in few cases and we may want to
> return failure.

The way I understood the array API was as a method of handling a list of
anonymous resets, specified as

resets = < 1>, < 2>, < 3>;
// reset-names = "rst1", "rst2", "rst3"; /* don't care */

in the device tree.

Now if you want to handle a partial list of those as an unordered list,
with special consideration for others, that could be added as a separate
API when there is use for it. But I expect that most potential users of
this array API will not have to make such a distinction.

> >> @@ -85,6 +107,39 @@ static inline struct reset_control 
> >> *__devm_reset_control_get(
> >>return -ENOTSUPP;
> >>   }
> >>   
> >> +static inline int reset_control_array_assert(int num_rsts,
> >> +  struct reset_control_array *resets)
> >> +{
> >> +  return 0;
> >> +}
> >> +
> >> +static inline int reset_control_array_deassert(int num_rsts,
> >> +  struct reset_control_array *resets)
> >> +{
> >> +  return 0;
> >> +}
> > Is this missing a stub for reset_control_array_get?
> 
> No, that's supposed to be a static function.

Oh right, it is static. Please ignore.

regards
Philipp

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/03/2017 10:06 PM, Philipp Zabel wrote:

Hi Vivek,

thank you for the patch series. A few comments below: I'd like to reduce
the API surface a bit and include the counting and array allocation in
the _get functions, if possible.


Thank you for reviewing the patch. Please find my comments inline.



On Mon, 2017-04-03 at 19:12 +0530, Vivek Gautam wrote:

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(), _assert(), and _deassert()
an array of reset_control.

Cc: Philipp Zabel 
Signed-off-by: Vivek Gautam 
---

Changes since v1:
  - New patch added to the series.

  drivers/reset/core.c  | 169 ++
  include/linux/reset.h | 108 
  2 files changed, 277 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 66db061165cb..fb908aa4f69e 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
return count;
  }
  EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/*
+ * APIs to manage an array of reset controllers
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be asserted.

This should mention the API doesn't make any guarantees that the reset
lines controlled by the reset array are asserted or deasserted in any
particular order.


Sure, will add this comment.




+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(int num_rsts,
+   struct reset_control_array *resets)

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

struct reset_control_array {
unsigned int num_rstcs;
struct reset_control *rstc[];
};

int reset_control_array_assert(struct reset_control_array *resets)
{
...


Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.


+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++) {
+   ret = reset_control_assert(resets[i].rst);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be deasserted.

Same here, no guarantees on the order in which the resets are
deasserted.


sure.




+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++)
+   ret = reset_control_deassert(resets[i].rst);
+   if (ret)
+   goto err;
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   reset_control_assert(resets[i].rst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+/**
+ * reset_control_array_get - Get a list of reset controllers

A list of "reset controls".


right, will update this.




+ *
+ * @dev: device that requests the list of reset controllers
+ * @num_rsts: number of reset controllers requested
+ * @resets: reset control array holding info about a list of resets
+ * @shared: whether reset controllers are shared or not
+ * @optional: whether it is optional to get the reset controllers
+ *

This should mention that the array API is intended for a list of resets
that just have to be asserted or deasserted, without any requirements on
the order.


Sure, will mention that.




+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.


Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
   const char * const rst_names[] = {
 "rst1", "rst2" ...
   };
   xyz_data = {
 .resets = rst_names;
 .num = 

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/03/2017 10:06 PM, Philipp Zabel wrote:

Hi Vivek,

thank you for the patch series. A few comments below: I'd like to reduce
the API surface a bit and include the counting and array allocation in
the _get functions, if possible.


Thank you for reviewing the patch. Please find my comments inline.



On Mon, 2017-04-03 at 19:12 +0530, Vivek Gautam wrote:

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(), _assert(), and _deassert()
an array of reset_control.

Cc: Philipp Zabel 
Signed-off-by: Vivek Gautam 
---

Changes since v1:
  - New patch added to the series.

  drivers/reset/core.c  | 169 ++
  include/linux/reset.h | 108 
  2 files changed, 277 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 66db061165cb..fb908aa4f69e 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
return count;
  }
  EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/*
+ * APIs to manage an array of reset controllers
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be asserted.

This should mention the API doesn't make any guarantees that the reset
lines controlled by the reset array are asserted or deasserted in any
particular order.


Sure, will add this comment.




+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(int num_rsts,
+   struct reset_control_array *resets)

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

struct reset_control_array {
unsigned int num_rstcs;
struct reset_control *rstc[];
};

int reset_control_array_assert(struct reset_control_array *resets)
{
...


Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.


+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++) {
+   ret = reset_control_assert(resets[i].rst);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be deasserted.

Same here, no guarantees on the order in which the resets are
deasserted.


sure.




+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++)
+   ret = reset_control_deassert(resets[i].rst);
+   if (ret)
+   goto err;
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   reset_control_assert(resets[i].rst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+/**
+ * reset_control_array_get - Get a list of reset controllers

A list of "reset controls".


right, will update this.




+ *
+ * @dev: device that requests the list of reset controllers
+ * @num_rsts: number of reset controllers requested
+ * @resets: reset control array holding info about a list of resets
+ * @shared: whether reset controllers are shared or not
+ * @optional: whether it is optional to get the reset controllers
+ *

This should mention that the array API is intended for a list of resets
that just have to be asserted or deasserted, without any requirements on
the order.


Sure, will mention that.




+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.


Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
   const char * const rst_names[] = {
 "rst1", "rst2" ...
   };
   xyz_data = {
 .resets = rst_names;
 .num = ARRAY_SIZE(rst_names);
   };
and then the driver making use of 

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

On 04/04/2017 09:44 AM, kbuild test robot wrote:

Hi Vivek,

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.11-rc5 next-20170403]
[cannot apply to pza/reset/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vivek-Gautam/reset-APIs-to-manage-a-list-of-resets/20170404-111639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x004-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All warnings (new ones prefixed by >>):

drivers/reset/core.c: In function 'reset_control_array_deassert':

drivers/reset/core.c:526:2: warning: this 'for' clause does not guard... 
[-Wmisleading-indentation]

  for (i = 0; i < num_rsts; i++)
  ^~~
drivers/reset/core.c:528:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'for'
   if (ret)
   ^~


Right, gonna fix these warnings in the next version of the patch.
Thanks


vim +/for +526 drivers/reset/core.c

510 /**
511  * reset_control_array_deassert: deassert a list of resets
512  *
513  * @resets: reset control array holding info about a list of resets
514  * @num_rsts: number of resets to be deasserted.
515  *
516  * Returns 0 on success or error number on failure.
517  */
518 int reset_control_array_deassert(int num_rsts,
519 struct reset_control_array *resets)
520 {
521 int ret, i;
522 
523 if (WARN_ON(IS_ERR_OR_NULL(resets)))
524 return -EINVAL;
525 
  > 526  for (i = 0; i < num_rsts; i++)
527 ret = reset_control_deassert(resets[i].rst);
528 if (ret)
529 goto err;
530 
531 return 0;
532 
533 err:
534 while (--i >= 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


BRs
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

On 04/04/2017 09:44 AM, kbuild test robot wrote:

Hi Vivek,

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.11-rc5 next-20170403]
[cannot apply to pza/reset/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vivek-Gautam/reset-APIs-to-manage-a-list-of-resets/20170404-111639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x004-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All warnings (new ones prefixed by >>):

drivers/reset/core.c: In function 'reset_control_array_deassert':

drivers/reset/core.c:526:2: warning: this 'for' clause does not guard... 
[-Wmisleading-indentation]

  for (i = 0; i < num_rsts; i++)
  ^~~
drivers/reset/core.c:528:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'for'
   if (ret)
   ^~


Right, gonna fix these warnings in the next version of the patch.
Thanks


vim +/for +526 drivers/reset/core.c

510 /**
511  * reset_control_array_deassert: deassert a list of resets
512  *
513  * @resets: reset control array holding info about a list of resets
514  * @num_rsts: number of resets to be deasserted.
515  *
516  * Returns 0 on success or error number on failure.
517  */
518 int reset_control_array_deassert(int num_rsts,
519 struct reset_control_array *resets)
520 {
521 int ret, i;
522 
523 if (WARN_ON(IS_ERR_OR_NULL(resets)))
524 return -EINVAL;
525 
  > 526  for (i = 0; i < num_rsts; i++)
527 ret = reset_control_deassert(resets[i].rst);
528 if (ret)
529 goto err;
530 
531 return 0;
532 
533 err:
534 while (--i >= 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


BRs
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[kbuild test robot]

Hi Vivek,

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.11-rc5 next-20170403]
[cannot apply to pza/reset/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vivek-Gautam/reset-APIs-to-manage-a-list-of-resets/20170404-111639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x004-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/reset/core.c: In function 'reset_control_array_deassert':
>> drivers/reset/core.c:526:2: warning: this 'for' clause does not guard... 
>> [-Wmisleading-indentation]
 for (i = 0; i < num_rsts; i++)
 ^~~
   drivers/reset/core.c:528:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'for'
  if (ret)
  ^~

vim +/for +526 drivers/reset/core.c

   510  /**
   511   * reset_control_array_deassert: deassert a list of resets
   512   *
   513   * @resets: reset control array holding info about a list of resets
   514   * @num_rsts: number of resets to be deasserted.
   515   *
   516   * Returns 0 on success or error number on failure.
   517   */
   518  int reset_control_array_deassert(int num_rsts,
   519  struct reset_control_array *resets)
   520  {
   521  int ret, i;
   522  
   523  if (WARN_ON(IS_ERR_OR_NULL(resets)))
   524  return -EINVAL;
   525  
 > 526  for (i = 0; i < num_rsts; i++)
   527  ret = reset_control_deassert(resets[i].rst);
   528  if (ret)
   529  goto err;
   530  
   531  return 0;
   532  
   533  err:
   534  while (--i >= 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[kbuild test robot]

Hi Vivek,

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.11-rc5 next-20170403]
[cannot apply to pza/reset/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vivek-Gautam/reset-APIs-to-manage-a-list-of-resets/20170404-111639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x004-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/reset/core.c: In function 'reset_control_array_deassert':
>> drivers/reset/core.c:526:2: warning: this 'for' clause does not guard... 
>> [-Wmisleading-indentation]
 for (i = 0; i < num_rsts; i++)
 ^~~
   drivers/reset/core.c:528:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'for'
  if (ret)
  ^~

vim +/for +526 drivers/reset/core.c

   510  /**
   511   * reset_control_array_deassert: deassert a list of resets
   512   *
   513   * @resets: reset control array holding info about a list of resets
   514   * @num_rsts: number of resets to be deasserted.
   515   *
   516   * Returns 0 on success or error number on failure.
   517   */
   518  int reset_control_array_deassert(int num_rsts,
   519  struct reset_control_array *resets)
   520  {
   521  int ret, i;
   522  
   523  if (WARN_ON(IS_ERR_OR_NULL(resets)))
   524  return -EINVAL;
   525  
 > 526  for (i = 0; i < num_rsts; i++)
   527  ret = reset_control_deassert(resets[i].rst);
   528  if (ret)
   529  goto err;
   530  
   531  return 0;
   532  
   533  err:
   534  while (--i >= 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[kbuild test robot]

Hi Vivek,

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.11-rc5 next-20170403]
[cannot apply to pza/reset/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vivek-Gautam/reset-APIs-to-manage-a-list-of-resets/20170404-111639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x008-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/reset/core.c: In function 'reset_control_array_deassert':
   drivers/reset/core.c:526:2: warning: this 'for' clause does not guard... 
[-Wmisleading-indentation]
 for (i = 0; i < num_rsts; i++)
 ^~~
   drivers/reset/core.c:528:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'for'
  if (ret)
  ^~
>> drivers/reset/core.c:531:9: warning: 'ret' may be used uninitialized in this 
>> function [-Wmaybe-uninitialized]
 return 0;
^

vim +/ret +531 drivers/reset/core.c

   520  {
   521  int ret, i;
   522  
   523  if (WARN_ON(IS_ERR_OR_NULL(resets)))
   524  return -EINVAL;
   525  
 > 526  for (i = 0; i < num_rsts; i++)
   527  ret = reset_control_deassert(resets[i].rst);
   528  if (ret)
   529  goto err;
   530  
 > 531  return 0;
   532  
   533  err:
   534  while (--i >= 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[kbuild test robot]

Hi Vivek,

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.11-rc5 next-20170403]
[cannot apply to pza/reset/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vivek-Gautam/reset-APIs-to-manage-a-list-of-resets/20170404-111639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x008-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/reset/core.c: In function 'reset_control_array_deassert':
   drivers/reset/core.c:526:2: warning: this 'for' clause does not guard... 
[-Wmisleading-indentation]
 for (i = 0; i < num_rsts; i++)
 ^~~
   drivers/reset/core.c:528:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'for'
  if (ret)
  ^~
>> drivers/reset/core.c:531:9: warning: 'ret' may be used uninitialized in this 
>> function [-Wmaybe-uninitialized]
 return 0;
^

vim +/ret +531 drivers/reset/core.c

   520  {
   521  int ret, i;
   522  
   523  if (WARN_ON(IS_ERR_OR_NULL(resets)))
   524  return -EINVAL;
   525  
 > 526  for (i = 0; i < num_rsts; i++)
   527  ret = reset_control_deassert(resets[i].rst);
   528  if (ret)
   529  goto err;
   530  
 > 531  return 0;
   532  
   533  err:
   534  while (--i >= 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Philipp Zabel]

Hi Vivek,

thank you for the patch series. A few comments below: I'd like to reduce
the API surface a bit and include the counting and array allocation in
the _get functions, if possible.

On Mon, 2017-04-03 at 19:12 +0530, Vivek Gautam wrote:
> 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(), _assert(), and _deassert()
> an array of reset_control.
> 
> Cc: Philipp Zabel 
> Signed-off-by: Vivek Gautam 
> ---
> 
> Changes since v1:
>  - New patch added to the series.
> 
>  drivers/reset/core.c  | 169 
> ++
>  include/linux/reset.h | 108 
>  2 files changed, 277 insertions(+)
> 
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 66db061165cb..fb908aa4f69e 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
>   return count;
>  }
>  EXPORT_SYMBOL_GPL(of_reset_control_get_count);
> +
> +/*
> + * APIs to manage an array of reset controllers
> + */
> +/**
> + * reset_control_array_assert: assert a list of resets
> + *
> + * @resets: reset control array holding info about a list of resets
> + * @num_rsts: number of resets to be asserted.

This should mention the API doesn't make any guarantees that the reset
lines controlled by the reset array are asserted or deasserted in any
particular order.

> + * Returns 0 on success or error number on failure.
> + */
> +int reset_control_array_assert(int num_rsts,
> + struct reset_control_array *resets)

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

struct reset_control_array {
unsigned int num_rstcs;
struct reset_control *rstc[];
};

int reset_control_array_assert(struct reset_control_array *resets)
{
...

> +{
> + int ret, i;
> +
> + if (WARN_ON(IS_ERR_OR_NULL(resets)))
> + return -EINVAL;
> +
> + for (i = 0; i < num_rsts; i++) {
> + ret = reset_control_assert(resets[i].rst);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(reset_control_array_assert);
> +
> +/**
> + * reset_control_array_deassert: deassert a list of resets
> + *
> + * @resets: reset control array holding info about a list of resets
> + * @num_rsts: number of resets to be deasserted.

Same here, no guarantees on the order in which the resets are
deasserted.

> + * Returns 0 on success or error number on failure.
> + */
> +int reset_control_array_deassert(int num_rsts,
> + struct reset_control_array *resets)
> +{
> + int ret, i;
> +
> + if (WARN_ON(IS_ERR_OR_NULL(resets)))
> + return -EINVAL;
> +
> + for (i = 0; i < num_rsts; i++)
> + ret = reset_control_deassert(resets[i].rst);
> + if (ret)
> + goto err;
> +
> + return 0;
> +
> +err:
> + while (--i >= 0)
> + reset_control_assert(resets[i].rst);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(reset_control_array_deassert);
> +
> +/**
> + * reset_control_array_get - Get a list of reset controllers

A list of "reset controls".

> + *
> + * @dev: device that requests the list of reset controllers
> + * @num_rsts: number of reset controllers requested
> + * @resets: reset control array holding info about a list of resets
> + * @shared: whether reset controllers are shared or not
> + * @optional: whether it is optional to get the reset controllers
> + *

This should mention that the array API is intended for a list of resets
that just have to be asserted or deasserted, without any requirements on
the order.

> + * Returns 0 on success or error number on failure
> + */
> +static int reset_control_array_get(struct device *dev, int num_rsts,
> + struct reset_control_array *resets,
> + bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.

> +{
> + int ret, i;
> + struct reset_control *rstc;
> +
> + for (i = 0; i < num_rsts; i++) {
> + rstc = __of_reset_control_get(dev ? dev->of_node : NULL,
> + resets[i].name, i, shared, optional);
> + if (IS_ERR(rstc)) {
> + ret = PTR_ERR(rstc);
> + goto err_rst;
> + }
> + resets[i].rst = rstc;
> + }
> +
> + return 0;
> +
> +err_rst:
> + while (--i >= 0)
> + reset_control_put(resets[i].rst);
> +  

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Philipp Zabel]

Hi Vivek,

thank you for the patch series. A few comments below: I'd like to reduce
the API surface a bit and include the counting and array allocation in
the _get functions, if possible.

On Mon, 2017-04-03 at 19:12 +0530, Vivek Gautam wrote:
> 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(), _assert(), and _deassert()
> an array of reset_control.
> 
> Cc: Philipp Zabel 
> Signed-off-by: Vivek Gautam 
> ---
> 
> Changes since v1:
>  - New patch added to the series.
> 
>  drivers/reset/core.c  | 169 
> ++
>  include/linux/reset.h | 108 
>  2 files changed, 277 insertions(+)
> 
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index 66db061165cb..fb908aa4f69e 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
>   return count;
>  }
>  EXPORT_SYMBOL_GPL(of_reset_control_get_count);
> +
> +/*
> + * APIs to manage an array of reset controllers
> + */
> +/**
> + * reset_control_array_assert: assert a list of resets
> + *
> + * @resets: reset control array holding info about a list of resets
> + * @num_rsts: number of resets to be asserted.

This should mention the API doesn't make any guarantees that the reset
lines controlled by the reset array are asserted or deasserted in any
particular order.

> + * Returns 0 on success or error number on failure.
> + */
> +int reset_control_array_assert(int num_rsts,
> + struct reset_control_array *resets)

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

struct reset_control_array {
unsigned int num_rstcs;
struct reset_control *rstc[];
};

int reset_control_array_assert(struct reset_control_array *resets)
{
...

> +{
> + int ret, i;
> +
> + if (WARN_ON(IS_ERR_OR_NULL(resets)))
> + return -EINVAL;
> +
> + for (i = 0; i < num_rsts; i++) {
> + ret = reset_control_assert(resets[i].rst);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(reset_control_array_assert);
> +
> +/**
> + * reset_control_array_deassert: deassert a list of resets
> + *
> + * @resets: reset control array holding info about a list of resets
> + * @num_rsts: number of resets to be deasserted.

Same here, no guarantees on the order in which the resets are
deasserted.

> + * Returns 0 on success or error number on failure.
> + */
> +int reset_control_array_deassert(int num_rsts,
> + struct reset_control_array *resets)
> +{
> + int ret, i;
> +
> + if (WARN_ON(IS_ERR_OR_NULL(resets)))
> + return -EINVAL;
> +
> + for (i = 0; i < num_rsts; i++)
> + ret = reset_control_deassert(resets[i].rst);
> + if (ret)
> + goto err;
> +
> + return 0;
> +
> +err:
> + while (--i >= 0)
> + reset_control_assert(resets[i].rst);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(reset_control_array_deassert);
> +
> +/**
> + * reset_control_array_get - Get a list of reset controllers

A list of "reset controls".

> + *
> + * @dev: device that requests the list of reset controllers
> + * @num_rsts: number of reset controllers requested
> + * @resets: reset control array holding info about a list of resets
> + * @shared: whether reset controllers are shared or not
> + * @optional: whether it is optional to get the reset controllers
> + *

This should mention that the array API is intended for a list of resets
that just have to be asserted or deasserted, without any requirements on
the order.

> + * Returns 0 on success or error number on failure
> + */
> +static int reset_control_array_get(struct device *dev, int num_rsts,
> + struct reset_control_array *resets,
> + bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.

> +{
> + int ret, i;
> + struct reset_control *rstc;
> +
> + for (i = 0; i < num_rsts; i++) {
> + rstc = __of_reset_control_get(dev ? dev->of_node : NULL,
> + resets[i].name, i, shared, optional);
> + if (IS_ERR(rstc)) {
> + ret = PTR_ERR(rstc);
> + goto err_rst;
> + }
> + resets[i].rst = rstc;
> + }
> +
> + return 0;
> +
> +err_rst:
> + while (--i >= 0)
> + reset_control_put(resets[i].rst);
> + return ret;
> +}
> +
> +static void 

[PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

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(), _assert(), and _deassert()
an array of reset_control.

Cc: Philipp Zabel 
Signed-off-by: Vivek Gautam 
---

Changes since v1:
 - New patch added to the series.

 drivers/reset/core.c  | 169 ++
 include/linux/reset.h | 108 
 2 files changed, 277 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 66db061165cb..fb908aa4f69e 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
return count;
 }
 EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/*
+ * APIs to manage an array of reset controllers
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be asserted.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++) {
+   ret = reset_control_assert(resets[i].rst);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be deasserted.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++)
+   ret = reset_control_deassert(resets[i].rst);
+   if (ret)
+   goto err;
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   reset_control_assert(resets[i].rst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+/**
+ * reset_control_array_get - Get a list of reset controllers
+ *
+ * @dev: device that requests the list of reset controllers
+ * @num_rsts: number of reset controllers requested
+ * @resets: reset control array holding info about a list of resets
+ * @shared: whether reset controllers are shared or not
+ * @optional: whether it is optional to get the reset controllers
+ *
+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)
+{
+   int ret, i;
+   struct reset_control *rstc;
+
+   for (i = 0; i < num_rsts; i++) {
+   rstc = __of_reset_control_get(dev ? dev->of_node : NULL,
+   resets[i].name, i, shared, optional);
+   if (IS_ERR(rstc)) {
+   ret = PTR_ERR(rstc);
+   goto err_rst;
+   }
+   resets[i].rst = rstc;
+   }
+
+   return 0;
+
+err_rst:
+   while (--i >= 0)
+   reset_control_put(resets[i].rst);
+   return ret;
+}
+
+static void devm_reset_control_array_release(struct device *dev, void *res)
+{
+   struct reset_control_devres *ptr = res;
+   int i;
+
+   for (i = 0; i < ptr->num_resets; i++)
+   reset_control_put(ptr->resets[i].rst);
+}
+
+/**
+ * devm_reset_control_array_get - Resource managed reset_control_array_get
+ *   See reset_control_array_get() for more
+ *   details
+ *
+ * Returns 0 on success or error number on failure
+ */
+int devm_reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)
+{
+   struct reset_control_devres *ptr;
+   int ret;
+
+   ptr = devres_alloc(devm_reset_control_array_release, sizeof(*ptr),
+  GFP_KERNEL);
+   if (!ptr)
+   return -ENOMEM;
+
+   ret = reset_control_array_get(dev, num_rsts, resets,
+   shared, optional);
+   if (ret) {
+   ptr->resets = resets;
+   ptr->num_resets = num_rsts;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_reset_control_array_get);
+
+int of_reset_control_array_get(struct device_node *node, 

[PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

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(), _assert(), and _deassert()
an array of reset_control.

Cc: Philipp Zabel 
Signed-off-by: Vivek Gautam 
---

Changes since v1:
 - New patch added to the series.

 drivers/reset/core.c  | 169 ++
 include/linux/reset.h | 108 
 2 files changed, 277 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 66db061165cb..fb908aa4f69e 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
return count;
 }
 EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/*
+ * APIs to manage an array of reset controllers
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be asserted.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++) {
+   ret = reset_control_assert(resets[i].rst);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be deasserted.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++)
+   ret = reset_control_deassert(resets[i].rst);
+   if (ret)
+   goto err;
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   reset_control_assert(resets[i].rst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+/**
+ * reset_control_array_get - Get a list of reset controllers
+ *
+ * @dev: device that requests the list of reset controllers
+ * @num_rsts: number of reset controllers requested
+ * @resets: reset control array holding info about a list of resets
+ * @shared: whether reset controllers are shared or not
+ * @optional: whether it is optional to get the reset controllers
+ *
+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)
+{
+   int ret, i;
+   struct reset_control *rstc;
+
+   for (i = 0; i < num_rsts; i++) {
+   rstc = __of_reset_control_get(dev ? dev->of_node : NULL,
+   resets[i].name, i, shared, optional);
+   if (IS_ERR(rstc)) {
+   ret = PTR_ERR(rstc);
+   goto err_rst;
+   }
+   resets[i].rst = rstc;
+   }
+
+   return 0;
+
+err_rst:
+   while (--i >= 0)
+   reset_control_put(resets[i].rst);
+   return ret;
+}
+
+static void devm_reset_control_array_release(struct device *dev, void *res)
+{
+   struct reset_control_devres *ptr = res;
+   int i;
+
+   for (i = 0; i < ptr->num_resets; i++)
+   reset_control_put(ptr->resets[i].rst);
+}
+
+/**
+ * devm_reset_control_array_get - Resource managed reset_control_array_get
+ *   See reset_control_array_get() for more
+ *   details
+ *
+ * Returns 0 on success or error number on failure
+ */
+int devm_reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)
+{
+   struct reset_control_devres *ptr;
+   int ret;
+
+   ptr = devres_alloc(devm_reset_control_array_release, sizeof(*ptr),
+  GFP_KERNEL);
+   if (!ptr)
+   return -ENOMEM;
+
+   ret = reset_control_array_get(dev, num_rsts, resets,
+   shared, optional);
+   if (ret) {
+   ptr->resets = resets;
+   ptr->num_resets = num_rsts;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_reset_control_array_get);
+
+int of_reset_control_array_get(struct device_node *node, int num_rsts,
+   struct