[PATCH v3 1/5] reset: Add reset_reset() and reset_reset_bulk() API

Michal Simek michal.simek at amd.com
Wed May 20 16:40:14 CEST 2026



On 5/18/26 16:05, Maarten Brock wrote:
> Hello Michal,
> 
>> From: Michal Simek <michal.simek at amd.com>
>> On 5/18/26 15:40, Maarten Brock wrote:
>>>
>>> How about something like this?
>>>
>>> int reset_reset_bulk(struct reset_ctl_bulk *bulk, ulong delay_us)
>>> {
>>> 	int i, ret, soft = 0;
>>>
>>> 	for (i = 0; i < bulk->count; i++) {
>>> 		struct reset_ops *ops = reset_dev_ops(bulk->resets[i].dev);
>>>
>>> 		if (ops->rst_reset) {
>>> 			ret = ops->rst_reset(&bulk->resets[i], delay_us);
>>> 		} else {
>>> 			ret = reset_assert(&bulk->resets[i]);
>>> 			soft++;
>>
>> But this will have weird behavior when you have multiple reset controllers where
>> one has rst_reset implemented and another not. Then on that one with rst_reset
>> another deassert is going to be called.
> 
>>          for (i = 0; i < bulk->count; i++) {
>>                  struct reset_ops *ops = reset_dev_ops(bulk->resets[i].dev);
>>
>>                  if (!ops->rst_reset) {
> 
> Did you miss the ( ! ops->rst_reset ) here? It will not call deassert for the rst_reset cases.

ah.


> 
>>                          ret = reset_deassert(&bulk->resets[i]);
>>                          if (ret < 0)
>>                                  return ret;
>>                  }
>>          }
> 
> I do agree that timing might become sketchy. But I don't see a one-size-fits-all solution.

TBH I think it is too complicated and we don't have any evidence that Linux 
implementation is wrong. I think that make sense to use what Linux has and if 
there is any problem we can change this sequence.

Thanks,
Michal


More information about the U-Boot mailing list