Re: [PATCH v3 2/3] arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC

[Maulik Shah (mkshah)]

On 7/17/2026 7:38 AM, Bjorn Andersson wrote:
> On Thu, Jul 16, 2026 at 09:59:44AM +0200, Krzysztof Kozlowski wrote:
>> On Wed, Jul 15, 2026 at 06:52:01PM +0530, Maulik Shah wrote:
>>> X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
>>> register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
>>> Workaround hardware register bug on X1E80100") is already fixed in
>>> X1P42100 silicon.
>>>
>>> X1E80100 compatible forces the software workaround. Use the X1P42100
>>> specific compatible string for the PDC node to remove the workaround.
>>>
>>> Fixes: f08edb529916 ("arm64: dts: qcom: Add X1P42100 SoC and CRD")
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
>>> Signed-off-by: Maulik Shah <maulik.shah@xxxxxxxxxxxxxxxx>
>>> ---
>>>  arch/arm64/boot/dts/qcom/purwa.dtsi | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>
>> Why does the DT change appear in the middle of the patchset? Please read
>> submitting patches documents - both of them - and maintainer-soc
>> profile.
>>
> 
> I thought I had figured it out, but I'm not sure anymore.
> 
> The claim from the cover letter is that patch 1 and 2 are completely
> independent, but patch 3 depends on Bartosz's thank you letter [2] that
> arrived a week before this series was sent out.
> 
> We're not merging the three changes through the same tree and there's no
> expressed dependency between patch 2 and 3 (only implicitly by the order
> in the series). But as Konrad points out, in-between patch 2 and 3 we
> would not enable the secondary GPIO in the PDC driver, so Purwa would
> have broken GPIOs for a while (not ok). I think merging them in the
> opposite order would be what we want (i.e. 1, 3, then 2)

purwa-iot-evk.dts where firmware sets pass through mode, so current order of the patch seems to be ok.
(patch 3 as such is no impact for iot evk)

x1p42100-crd.dts where firmware sets secondary mode, applying in 1, 2, and then 3 may leave crd boards
in broken GPIOs for a while after [2],  so yes order 1, 3, and then 2 makes more sense.

patch 1/2 - fixes the purwa to operate on correct registers.
patch 3 - Allow crd boards to re-set the mode to pass through

> 
> 
> But this series implies that Purwa has been broken from the start - that
> the PDC driver has always operated on the wrong registers.

yes, purwa always operated on the wrong registers.

> 
> Perhaps the impact of this was limited as there's not that many direct
> &pdc references in the DT, but the patch that Bartosz's thank-you email
> was sent for got merged as 77fbc756d9cb ("Revert "pinctrl: qcom:
> x1e80100: Bypass PDC wakeup parent for now""), and that would make a lot
> more use of the PDC.
> 
> So while nothing in this series states it, it sounds like Purwa might be
> completely broken right now and this series aims to fix it?
> 
> 
> It's not clear to me why the driver change doesn't have a Fixes tag, it
> seems like the patch that introduced x1e_quirk was broken and should be
> marked as Fixes.

x1e_quirk in the driver via commit e9a48ea4d90b ("irqchip/qcom-pdc: Workaround hardware register bug on X1E80100")
says only about x1e/ hamoa specific bug, it seemed it never wanted to enable the quirk for x1p / purwa. the quirk
rather got anyway enabled for purwa due to both hamoa/purwa sharing the same compatible.

Patch 1/2 of the series aims to fix this (and patch-2 carries the fixes: tag).

Thanks,
Maulik

> 
> [2] https://lore.kernel.org/linux-arm-msm/CAMRc=MeU0QuRozMscv02M59+a66S05Jm18CyvNE-qSYrY=S7hQ@xxxxxxxxxxxxxx/
> 
> Regards,
> Bjorn
> 
>> Best regards,
>> Krzysztof
>>