Re: [PATCH v3 1/2] regulator: dt-bindings: pca9450: add PMIC_RST_B warm reset property

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

 



Dear Krzysztof,

Il Sat, Apr 13, 2024 at 11:40:18PM +0200, Krzysztof Kozlowski ha scritto:
> On 13/04/2024 19:10, Fabio Aiuto wrote:
> > Dear Krzysztof,
> > 
> > Il Sat, Apr 13, 2024 at 12:58:35PM +0200, Krzysztof Kozlowski ha scritto:
> >> On 12/04/2024 09:21, Fabio Aiuto wrote:
> >>> Dear Krzysztof,
> >>>
> >>> Il Thu, Apr 11, 2024 at 09:52:12PM +0200, Krzysztof Kozlowski ha scritto:
> >>>> On 11/04/2024 18:58, Fabio Aiuto wrote:
<snip> 
> I don't understand what is the use case. You wrote runtime does not
> solve your use case. What is the use case?

We experimented problems on some boards with SD card, if a cold reset
is done when the card is powered back on it completely freezes, the way
devices behave when unpowered for such short intervals is design specific,
not an OS policy.

kr,

fabio

> > 
> >>
> >> Sorry, you did not bring any further argument why this is board
> >> specific. And please don't explain how probing works, but address the
> >> problem here: why type of reset is specific to board design. To me it is
> >> OS policy.
> >>
> > 
> > Why reset type is specific to board design? I'm sorry but I don't know
> > what you mean, as said my intention was to enlarge the number of configurable
> > bits in pca9450 register space hoping this would be useful for someone.
> > 
> > All I can say is that is specific to board design for the same reason the
> > wdog_b- reset type was specific to board design.
> 
> Specific to board design means different boards have somehow different
> configuration/schematics/layout/hardware meaning they need this property
> to configure device differently.
> 
> I already said it implicitly, but let's reiterate: Devicetree is for
> hardware properties, not OS policies.
> 
> I also said, so repeating the same argument, the choice how you want to
> reboot the system based on button press, sounds like debugging choice
> thus runtime suits better.
> 
> Unless you want to say there are two signals and you want to configure
> them differently? But that's your job to explain it, not mine.

please see above,

kr,

fabio

> 
> Best regards,
> Krzysztof
> 




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux