Re: [PATCH net 1/2] dt: ar803x: Document disable-hibernation property

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

 



On Fri, Aug 12, 2022 at 03:36:43PM +0300, Krzysztof Kozlowski wrote:
> On 12/08/2022 15:30, Russell King (Oracle) wrote:
> > On Fri, Aug 12, 2022 at 03:04:41PM +0300, Krzysztof Kozlowski wrote:
> >> I did not propose a property to enable hibernation. The property must
> >> describe hardware, so this piece is missing, regardless whether the
> >> logic in the driver is "enable" or "disable".
> >>
> >> The hardware property for example is: "broken foo, so hibernation should
> >> be disabled" or "engineer forgot to wire cables, so hibernation won't
> >> work"...
> > 
> > From the problem description, the PHY itself isn't broken. The stmmac
> > hardware doesn't reset properly when the clock from the PHY is stopped.
> 
> There is nothing like that in the property name or property description.
> Again - DT is not for describing driver behavior or driver policy.

Where have I said that it's describing driver behaviour or policy?
Hint: I haven't.

I have no idea why DT maintainers like to keep shoving that idiotic
statement down people's thoats. WE KNOW THIS. And that is NOT what
is being proposed here.

It is purely in your mind that this is a driver behaviour or driver
policy property. It *isn't*.

> > That could hardly be described as "broken" - it's quite common for
> > hardware specifications to state that clocks must be running for the
> > hardware to operate correctly.
> > 
> > This is a matter of configuring the hardware to inter-operate correctly.
> > Isn't that the whole purpose of DT?
> > 
> > So, nothing is broken. Nothing has forgotten to be wired. It's a matter
> > of properly configuring the hardware. Just the same as selecting the
> > correct interface mode to connect two devices together.
> 
> I just gave you two examples what could be written, don't need to stick
> them. You can use some real one...

So the original proposed property to _disable_ a feature implemented by
the hardware should be fine, because it's describing how the hardware
needs to be configured. It's not driver behaviour. It's not driver
policy. It's a configuration bit in a register.

I think you're thinking that the "hibernation" described here is
somehow related to system hibernation, which this has nothing to do
with. This is about configuring the PHY hardware to operate with the
MAC hardware.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!



[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