Re: [PATCH 2/4] reset: add GPIO-based reset controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/01/2024 17:04, Sean Anderson wrote:
> 
>>> Maybe we take the max? But the driver below seems
>>> to only have access to one device. Which I suppose begs the question: how do
>>> we know when it's safe to deassert the reset (e.g. we've gotten to the point
>>> where all devices using this reset gpio have gotten far enough to detect that
>>> they use it)?
>>
>> The driver (reset consumer) knows when it is safe or not. You must
>> implement proper reset handling in your driver.
> 
> The driver has no idea whether it is safe or not. It just calls
> reset_assert/deassert at the appropriate time, and the reset
> framework/controller is supposed to coordinate things so e.g. the device
> doesn't get reset multiple times as multiple drivers all probe.

Hm, wait, now maybe I understand your concern. Did you read the
patchset? This is for the coordinated, shared, non-exclusive reset by
design.  And as stated during previous discussions: that's the driver's
job to be sure it is called like that.

Best regards,
Krzysztof





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux