On Thu, Nov 23, 2023 at 01:02:24AM +0530, Krishna Kurapati PSSNV wrote: > Pushed [1] to address all the queries and comments. I was initially > looking at only Femto phy targets, but when I looked at all targets in > general, seems there is one irq not defined in bindings. It is qubs2_phy > irq which is named as "hs_phy_irq" on QUSB target DT's (both downstream > and upstream). > > There is one actual "hs_phy_irq" as well but it is not used either by hs > validation team or sw team on any target. It was put in for debug > purpose only and doesn't have code to trigger it (even downstream never > implemented it I suppose) Atleast 4.4 onwards I saw the code but I > didn't see the actual hs_phy_irq being used. It was the qusb2_phy irq > named as hs_phy_irq. > > Even hw folks used it under the same name which is why they recommended > using it on qusb2 targets and dp/dm on femto targets. Ah, thanks for getting to the bottom of this. > On some targets the hs_phy_irq was given vector number of pwr_event irq > also like sm8550/sm8450 etc., I tried to address those as well in the > series. I can imagine that we have a number of such issues. > Also, per your question as to there are some qusb2 targets having dp/dm > interrupts defined... It is only for SDM845/SDM670/SM6350 which were > last in line of using qusb2 phy's and they started incorporating dp/dm > interrupts. Ok. > Also added missing interrupts for qcs404/ipq5332. Thanks. > I didn't add missing interrupts on sc8280xp because I see that current > interrupts present are working fine (I see ADB working and wakeup > working as well), but the interrupt vector numbers are off by "1" > between hs specifics and DT (both upstream and downstream). Will sort it > out and clean that target up later. Which interrupt numbers are off by one here? > [1]: https://patchwork.kernel.org/project/linux-arm-msm/list/?series=803412 I took a quick look at the series, and it looks like this will eventually clean things up a lot. We should probably define a generic order for the interrupts with the sometimes optional SS interrupts last. Side note: It looks like the threading in that series is broken. Consider using git-send-email for sending series as it takes care of things like that. Johan
