lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3a7376aa-18a2-41cb-a4c9-680e735ce75b@linaro.org>
Date:   Fri, 1 Dec 2023 14:25:44 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     Krishna Chaitanya Chundru <quic_krichai@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        quic_vbadigan@...cinc.com, quic_ramkri@...cinc.com,
        quic_nitegupt@...cinc.com, quic_skananth@...cinc.com,
        quic_vpernami@...cinc.com, quic_parass@...cinc.com
Subject: Re: [PATCH v3 1/3] dt-bindings: phy: qcom,qmp: Add PCIe
 qcom,refclk-always-on property

On 01/12/2023 13:30, Manivannan Sadhasivam wrote:
>> What I said before:
>> "Again, third time (once from Bjorn, once from Dmitry), rephrase
>> property name and description to describe the hardware issue. I see
>> description improved, but not the property name. Again in the end of
>> description you say what Linux should do. Bindings do not describe Linux
>> OS."
>>
> 
> You didn't answer my question:
> 
> "I see a plenty of properties similar to this one instructing the OS to keep some
> resource ON to workaround hardware issues. So they are all wrong?"

They are not the best, but it all depends on the individual case.

> 
> If you say they are wrong, why are they approved in the first place?
Because we don't have time to keep digging what the driver is doing and
what is claimed in DT. Some people don't even CC us on the driver.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ