On Fri, May 13, 2022 at 01:10:44PM +0300, Dmitry Baryshkov wrote: > On Fri, 13 May 2022 at 12:36, Johan Hovold <johan@xxxxxxxxxx> wrote: > > > > On Fri, May 13, 2022 at 12:28:40PM +0300, Dmitry Baryshkov wrote: > > > On Fri, 13 May 2022 at 11:58, Johan Hovold <johan@xxxxxxxxxx> wrote: > > But you also added > > > > + - properties: > > + interrupts: > > + minItems: 8 > > + interrupt-names: > > + minItems: 8 > > + items: > > + - const: msi0 > > + - const: msi1 > > + - const: msi2 > > + - const: msi3 > > + - const: msi4 > > + - const: msi5 > > + - const: msi6 > > + - const: msi7 > > > > which means that I can no longer describe the four interrupts in DT. > > > > I didn't check the implementation, but it seems you should derive the > > number of MSIs based on the devicetree as I guess you did in v7. > > It is a conditional, so you can add another conditional for the > sc8280xp platform describing just 4 interrupts. And as you don't have > legacy DTS, you can completely omit the backwards compatible clause in > your case. > So, something like: > - if: > properties: > contains: > enum: > - qcom,pcie-sc8280xp > then: > properties: > interrupts: > minItems: 4 > maxItems: 4 > interrupt-names: > items: > - const: msi0 > - const: msi1 > - const: msi2 > - const: msi3 Ok, so the driver code still handles it, thanks. Are you able to confirm that all sc8280xp systems have only four msi IRQs? This seems like another case of using the kernel as a DT validator by describing things in two places and making sure that they match. I assume the number of vectors will always be a multiple of the numbers of msi IRQs. Right? Then we don't need to encode this number for every supported platform in the corresponding PCIe driver even if we end up describing it in the binding. Johan
