On Tue, Apr 25, 2023 at 03:33:28PM -0500, Andrew Halaney wrote: > On Sat, Apr 22, 2023 at 09:38:44PM +0530, Krishna Kurapati PSSNV wrote: > > Hi Andrew, Johan, > > > > I was looking at the pwr_event_irq interrupts for Multiport controller and > > see that there are two of them as per HW specs. All targets till date have > > only 1 pwr_event_irq required. > > > > The reason I thought I missed pwr_event_irq in my patches is because in > > downstream this is a required IRQ for all targets, so I was under assumption > > that we need it for upstream targets as well. But upstream qcom driver > > doesn't have support for this IRQ yet. And this has been made a required one > > only for SC8280 [1]/[2]. > > > > Probably we can proceed in one of the following ways: > > 1. Remove pwr_event_irq in both bindings and DT as driver support is not > > present currently. > > 2. Update the bindings for SC8280 to include an optional secondary > > pwr_event_irq for multiport controller. > > > > I would prefer option-1 as removing them would be better because they are > > not being used. Please let me know your thoughts on this. > > > > [1]: > > https://lore.kernel.org/all/20220713131340.29401-2-johan+linaro@xxxxxxxxxx/ > > [2]: > > https://lore.kernel.org/all/20220713131340.29401-6-johan+linaro@xxxxxxxxxx/ > > > > Personally, I prefer option 2 since the IRQ does exist technically > (although it isn't currently used), I like it being described... it > makes the dt-binding a more complete description of the hardware. > > I am unsure of the rules wrt dt-bindings and usage in drivers, but I > always like to view it as "this is a description of the hardware", and > the driver bit is just nice to have to ensure that whoever is adding the > binding is actually describing things sufficiently. As Andrew mentioned, the binding should reflect the hardware and not what is currently supported in some version of software. It looks like you even had four of these pwr_event interrupt line judging from your last iteration of this series. Johan
