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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <691334e4-8c00-4bcc-8009-13139b10463b@kernel.org>
Date: Mon, 6 Oct 2025 23:32:38 +0900
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
Cc: Pankaj Patil <pankaj.patil@....qualcomm.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 17/24] arm64: dts: qcom: glymur-crd: Avoid RTC probe
 failure

On 01/10/2025 21:23, Kamal Wadhwa wrote:
> Hi Krzysztof,
> 
> On Thu, Sep 25, 2025 at 1:41 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On Thu, 25 Sept 2025 at 15:34, Pankaj Patil
>> <pankaj.patil@....qualcomm.com> wrote:
>>>
>>> From: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
>>>
>>> On Glymur boards, the RTC alarm interrupts are routed to SOCCP
>>> subsystems and are not available to APPS. This can cause the
>>> RTC probe failure as the RTC IRQ registration will fail in
>>> probe.
>>>
>>> Fix this issue by adding `no-alarm` property in the RTC DT
>>> node. This will skip the RTC alarm irq registration and
>>> the RTC probe will return success.
>>
>>
>> This is ridiculous. You just added glymur CRD and you claim now that
>> it's broken and you need to fix it. So just fix that commit!
> 
> I'm afraid, but this is an actual limitation we have for Glymur
> (compared to Kaanapali).
> The RTC is part of the pmk8850.dtsi that is common between Kaanapali and
> Glymur. On Glymur (unlike Kaanapali) the APPS processor does *not* have the RTC
> IRQ permission for the RTC peripheral.
> 
> So we need this extra change in Glymur explicitly as a workaround to
> make RTC register
> properly.
> 
> But sure, we can squash this into the main DT patch, if you think this
> is not a limitation
> that needs to be highlighted in a separate patch.
> 
>>
>> This is a gross misinterpretation of splitting patchset, some twisted
>> LWN stats work.
> 
> Sorry for this. It was not intentional (definitely not for LWN stats),
> mainly this happened
> because this is how individual driver owners/teams internally added
> their patches. So


You upstream all this, so YOU should organize this work for upstream,
not just copy-paste what internal owners/teams did.

Upstream community does not care about owners/teams concept. You must
send logically consistent and organized in sane way patchset, which
means squashing all such stuff so in new code you will never use word
"fix" for something you just added.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ