From: Krzysztof Kozlowski <krzk@kernel.org>
To: Mayank Rana <quic_mrana@quicinc.com>,
will@kernel.org, lpieralisi@kernel.org, kw@linux.com,
robh@kernel.org, bhelgaas@google.com, jingoohan1@gmail.com,
manivannan.sadhasivam@linaro.org, cassel@kernel.org,
yoshihiro.shimoda.uh@renesas.com, s-vadapalli@ti.com,
u.kleine-koenig@pengutronix.de, dlemoal@kernel.org,
amishin@t-argos.ru, thierry.reding@gmail.com,
jonathanh@nvidia.com, Frank.Li@nxp.com,
ilpo.jarvinen@linux.intel.com, vidyas@nvidia.com,
marek.vasut+renesas@gmail.com, krzk+dt@kernel.org,
conor+dt@kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Cc: quic_ramkri@quicinc.com, quic_nkela@quicinc.com,
quic_shazhuss@quicinc.com, quic_msarkar@quicinc.com,
quic_nitegupt@quicinc.com
Subject: Re: [PATCH V226/7] dt-bindings: PCI: host-generic-pci: Add snps,dw-pcie-ecam-msi binding
Date: Sat, 20 Jul 2024 20:30:29 +0200 [thread overview]
Message-ID: <24aee2d7-927b-4ea0-bb34-e8f63d8e7856@kernel.org> (raw)
In-Reply-To: <1a6f5cdf-9256-4d8d-b8c7-92bd6e7d3813@quicinc.com>
On 19/07/2024 01:19, Mayank Rana wrote:
> Hi Krzysztof
>
> On 7/17/2024 11:05 PM, Krzysztof Kozlowski wrote:
>> On 17/07/2024 19:20, Mayank Rana wrote:
>>> Hi Krzysztof
>>>
>>> On 7/16/2024 11:47 PM, Krzysztof Kozlowski wrote:
>>>> On 17/07/2024 00:09, Mayank Rana wrote:
>>>>> Hi Krzysztof
>>>>>
>>>>> On 7/16/2024 12:28 AM, Krzysztof Kozlowski wrote:
>>>>>> On 15/07/2024 20:13, Mayank Rana wrote:
>>>>>>> To support MSI functionality using Synopsys DesignWare PCIe controller
>>>>>>> based MSI controller with ECAM driver, add "snps,dw-pcie-ecam-msi
>>>>>>> compatible binding which uses provided SPIs to support MSI functionality.
>>>>>>
>>>>>> To support MSI, you add MSI support... That's a tautology. Describe
>>>>>> hardware instead.
>>>>> Ok. let me repharse it to provide more useful information.
>>>>>>>
>>>>>>> Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
>>>>>>> ---
>>>>>>> .../devicetree/bindings/pci/host-generic-pci.yaml | 57 ++++++++++++++++++++++
>>>>>>> 1 file changed, 57 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
>>>>>>> index 9c714fa..9e860d5 100644
>>>>>>> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
>>>>>>> @@ -81,6 +81,12 @@ properties:
>>>>>>> - marvell,armada8k-pcie-ecam
>>>>>>> - socionext,synquacer-pcie-ecam
>>>>>>> - const: snps,dw-pcie-ecam
>>>>>>> + - description: |
>>>>>>> + Firmware is configuring Synopsys DesignWare PCIe controller in RC mode with
>>>>>>> + ECAM compatible fashion. To use MSI controller of Synopsys DesignWare PCIe
>>>>>>> + controller for MSI functionality, this compatible is used.
>>>>>>> + items:
>>>>>>> + - const: snps,dw-pcie-ecam-msi
>>>>>>
>>>>>> MSI is already present in the binding, isn't it?
>>>>> It is mentioning as msi-parent usage which could be different MSI
>>>>> controller (GIC or vendor specific one) not related to designware PCIe
>>>>> controller based MSI controller.
>>>>>
>>>>>> Anyway, aren't you
>>>>>> forgetting specific compatible? Please open your internal (quite
>>>>>> comprehensive) guideline on bindings and DTS.
>>>>> Here I am trying to define Designware based PCIe ECAM controller
>>>>> supporting MSIcontroller based device. Hence I am not mentioning vendor
>>>>> specific compatible usage
>>>>> and keeping generic compatible binding for such device.
>>>>
>>>> I know what you try, yet it feels simply wrong. Read your guideline.
>>>> Are you sure you work on Designware core itself, not on one used in
>>>> Qualcomm? I would expect people from Designware to design Designware
>>>> cores and people from Qualcomm only to design licensed cores.
>>> Ok. let me not make generic comment here. I refereed how it is done with
>>> other
>>> snps based IP usage for example USB, and would follow same.
>>
>> Well, it is not. If you read their bindings or any reviews related to
>> such cores, you would see that single Designware compatible is always
>> never appropriate. Such cores always have customization per user.
>>
>> You can also look at the binding you are changing. Do you see Designware
>> alone? No.
> I found reference in this binding as below:
> 79 items:
> 80 - enum:
> 81 - marvell,armada8k-pcie-ecam
> 82 - socionext,synquacer-pcie-ecam
> 83 - const: snps,dw-pcie-ecam
>
> And as you mentioned in previous emails about how to add such usage, I
> ACKed it but let me put reason why I tried to add differently to start
> with it.
>
> This specific driver under-discussion is really not vendor specific
> driver. It can work with any PCIe controller which is already configured
> in ECAM mode by firmware (i.e. PCIe controller from SNPS or any other
> vendor). There are few quirks only added to get specific vendor based
> SOC configuration for SNPS PCIe controller by different SOC vendors.
>
> 90 - description:
> 91 CAM or ECAM compliant PCI host controllers without any quirks
> 92 enum:
> 93 - pci-host-cam-generic
> 94 - pci-host-ecam-generic
>
> Above enum based usage works for SA8775P platform which is having SNPS
> PCIe controller which doesn't need any quirks, and firmware is able to
> configure PCIe controller into ECAM mode. Here I tried adding PCIe SNPS
> controller based MSI support as SA8775P doesn't support LPI/ITS for MSI.
> I need to differentiate it hence added generic enum as MSI controller is
> part of SNPS PCIe controller, and not separate MSI IP here. Although how
> many MSI can be supported it depends on how many SPIs are available/used
> with MSI controller depend on particular SOC. Hence put as
> snps,dw-pcie-ecam-msi as usage and variable number of MSI. hopefully I
> am able to convey why this driver binding modified differently.
Your binding already defines some specifics for specific device, but you
still claim all of them are identical.
Sorry, I am confused. Read carefully writing bindings, consult internal
guideline (go/upstream - it is really detailed!) and then come with a
solution.
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-07-20 18:30 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 18:13 [PATCH V2 0/7] Add power domain and MSI functionality with PCIe host generic ECAM driver Mayank Rana
2024-07-15 18:13 ` [PATCH V2 1/7] PCI: dwc: Move MSI functionality related code to separate file Mayank Rana
2024-07-31 16:40 ` Manivannan Sadhasivam
2024-07-15 18:13 ` [PATCH V222/7] PCI: dwc: Add msi_ops to allow DBI based MSI register access Mayank Rana
2024-07-31 17:17 ` Manivannan Sadhasivam
2024-07-15 18:13 ` [PATCH V2 3/7] PCI: dwc: Add pcie-designware-msi driver related Kconfig option Mayank Rana
2024-07-15 18:39 ` Andrew Lunn
2024-07-16 0:04 ` Mayank Rana
2024-07-15 18:13 ` [PATCH V2 4/7] dt-bindings: PCI: host-generic-pci: Add power-domains related binding Mayank Rana
2024-07-16 7:25 ` Krzysztof Kozlowski
2024-07-16 21:47 ` Mayank Rana
2024-07-15 18:13 ` [PATCH V2 5/7] PCI: host-generic: Add power domain based handling for PCIe controller Mayank Rana
2024-07-15 18:13 ` [PATCH V226/7] dt-bindings: PCI: host-generic-pci: Add snps,dw-pcie-ecam-msi binding Mayank Rana
2024-07-15 19:43 ` Rob Herring (Arm)
2024-07-16 7:28 ` Krzysztof Kozlowski
2024-07-16 22:09 ` Mayank Rana
2024-07-17 6:47 ` Krzysztof Kozlowski
2024-07-17 17:20 ` Mayank Rana
2024-07-18 6:05 ` Krzysztof Kozlowski
2024-07-18 23:19 ` Mayank Rana
2024-07-20 18:30 ` Krzysztof Kozlowski [this message]
2024-07-31 17:26 ` Manivannan Sadhasivam
2024-07-15 18:13 ` [PATCH V2 7/7] PCI: host-generic: Add dwc PCIe controller based MSI controller usage Mayank Rana
2024-07-16 8:58 ` Will Deacon
2024-07-16 13:42 ` Rob Herring
2024-07-16 22:32 ` Mayank Rana
2024-07-23 22:56 ` Mayank Rana
2024-07-24 9:54 ` Manivannan Sadhasivam
2024-07-24 2:13 ` [PATCH V2 0/7] Add power domain and MSI functionality with PCIe host generic ECAM driver Dmitry Baryshkov
2024-07-24 3:58 ` Mayank Rana
2024-07-24 7:12 ` Dmitry Baryshkov
2024-07-24 13:31 ` Manivannan Sadhasivam
2024-07-24 13:34 ` Dmitry Baryshkov
2024-07-24 16:51 ` Mayank Rana
2024-07-29 17:19 ` Mayank Rana
2024-07-30 5:34 ` Manivannan Sadhasivam
2024-07-30 16:16 ` Mayank Rana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24aee2d7-927b-4ea0-bb34-e8f63d8e7856@kernel.org \
--to=krzk@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=amishin@t-argos.ru \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlemoal@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=krzk+dt@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=marek.vasut+renesas@gmail.com \
--cc=quic_mrana@quicinc.com \
--cc=quic_msarkar@quicinc.com \
--cc=quic_nitegupt@quicinc.com \
--cc=quic_nkela@quicinc.com \
--cc=quic_ramkri@quicinc.com \
--cc=quic_shazhuss@quicinc.com \
--cc=robh@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vidyas@nvidia.com \
--cc=will@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.