diff mbox series

[RFC] dt-bindings: PCI: ti,j721e-pci-host: Add device-id for TI's J784S4 SoC

Message ID 20240108050735.512445-1-s-vadapalli@ti.com
State New
Headers show
Series [RFC] dt-bindings: PCI: ti,j721e-pci-host: Add device-id for TI's J784S4 SoC | expand

Commit Message

Siddharth Vadapalli Jan. 8, 2024, 5:07 a.m. UTC
Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as
described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID
field. The Register descriptions and the Technical Reference Manual for
J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52

Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---

This patch is based on linux-next tagged next-20240105.

Regards,
Siddharth.

 Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml | 1 +
 1 file changed, 1 insertion(+)

Comments

Krzysztof Kozlowski Jan. 8, 2024, 7:09 a.m. UTC | #1
On 08/01/2024 06:07, Siddharth Vadapalli wrote:
> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as
> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID
> field. The Register descriptions and the Technical Reference Manual for
> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
> 
> This patch is based on linux-next tagged next-20240105.

Why is this patch incomplete? What is missing here? What are you asking
about as RFC?

Best regards,
Krzysztof
Siddharth Vadapalli Jan. 8, 2024, 10:20 a.m. UTC | #2
Hello Krzysztof,

On 08/01/24 12:39, Krzysztof Kozlowski wrote:
> On 08/01/2024 06:07, Siddharth Vadapalli wrote:
>> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as
>> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID
>> field. The Register descriptions and the Technical Reference Manual for
>> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> ---
>>
>> This patch is based on linux-next tagged next-20240105.
> 
> Why is this patch incomplete? What is missing here? What are you asking
> about as RFC?

Since the merge window is closed, I was hoping to get the patch reviewed in
order to get any "Reviewed-by" tags if possible. That way, I will be able to
post it again as v1 along with the tags when the merge window opens. For that
reason, I have marked it as an RFC patch. Is there an alternative to this "RFC
patch" method that I have followed? Please let me know.

> 
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski Jan. 8, 2024, 11:21 a.m. UTC | #3
On 08/01/2024 11:20, Siddharth Vadapalli wrote:
> Hello Krzysztof,
> 
> On 08/01/24 12:39, Krzysztof Kozlowski wrote:
>> On 08/01/2024 06:07, Siddharth Vadapalli wrote:
>>> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as
>>> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID
>>> field. The Register descriptions and the Technical Reference Manual for
>>> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52
>>>
>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>> ---
>>>
>>> This patch is based on linux-next tagged next-20240105.
>>
>> Why is this patch incomplete? What is missing here? What are you asking
>> about as RFC?
> 
> Since the merge window is closed, I was hoping to get the patch reviewed in
> order to get any "Reviewed-by" tags if possible. That way, I will be able to
> post it again as v1 along with the tags when the merge window opens. For that

This is v1, so that would be v2.

> reason, I have marked it as an RFC patch. Is there an alternative to this "RFC
> patch" method that I have followed? Please let me know.

Then how does it differ from posting without RFC? Sorry, RFC is
incomplete work. Often ignored during review.

Best regards,
Krzysztof
Siddharth Vadapalli Jan. 8, 2024, 11:34 a.m. UTC | #4
On 08/01/24 16:51, Krzysztof Kozlowski wrote:
> On 08/01/2024 11:20, Siddharth Vadapalli wrote:
>> Hello Krzysztof,
>>
>> On 08/01/24 12:39, Krzysztof Kozlowski wrote:
>>> On 08/01/2024 06:07, Siddharth Vadapalli wrote:
>>>> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as
>>>> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID
>>>> field. The Register descriptions and the Technical Reference Manual for
>>>> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52
>>>>
>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>> ---
>>>>
>>>> This patch is based on linux-next tagged next-20240105.
>>>
>>> Why is this patch incomplete? What is missing here? What are you asking
>>> about as RFC?
>>
>> Since the merge window is closed, I was hoping to get the patch reviewed in
>> order to get any "Reviewed-by" tags if possible. That way, I will be able to
>> post it again as v1 along with the tags when the merge window opens. For that
> 
> This is v1, so that would be v2.
> 
>> reason, I have marked it as an RFC patch. Is there an alternative to this "RFC
>> patch" method that I have followed? Please let me know.
> 
> Then how does it differ from posting without RFC? Sorry, RFC is
> incomplete work. Often ignored during review.

I was under the impression that posting patches when the merge window is closed
will be met with a "post your patch later when the merge window is open"
response. That is why I chose the "RFC patch" path since RFCs can be posted anytime.

For the Networking Subsystem, it is documented that patches with new features
shouldn't be posted when the merge window is closed. I have mostly posted
patches for the Networking Subsystem and am not sure about the rules for the
device-tree bindings and PCI Subsystems. To be on the safe side I posted this
patch as an RFC patch.

Thank you for clarifying that it is alright to post patches even when merge
window is closed. Going forward I shall not post RFC patches unless it really
requires feedback and suggestions.
Krzysztof Kozlowski Jan. 8, 2024, 12:26 p.m. UTC | #5
On 08/01/2024 12:34, Siddharth Vadapalli wrote:
>>>>
>>>> Why is this patch incomplete? What is missing here? What are you asking
>>>> about as RFC?
>>>
>>> Since the merge window is closed, I was hoping to get the patch reviewed in
>>> order to get any "Reviewed-by" tags if possible. That way, I will be able to
>>> post it again as v1 along with the tags when the merge window opens. For that
>>
>> This is v1, so that would be v2.
>>
>>> reason, I have marked it as an RFC patch. Is there an alternative to this "RFC
>>> patch" method that I have followed? Please let me know.
>>
>> Then how does it differ from posting without RFC? Sorry, RFC is
>> incomplete work. Often ignored during review.
> 
> I was under the impression that posting patches when the merge window is closed
> will be met with a "post your patch later when the merge window is open"
> response. That is why I chose the "RFC patch" path since RFCs can be posted anytime.
> 
> For the Networking Subsystem, it is documented that patches with new features
> shouldn't be posted when the merge window is closed. I have mostly posted
> patches for the Networking Subsystem and am not sure about the rules for the
> device-tree bindings and PCI Subsystems. To be on the safe side I posted this
> patch as an RFC patch.

Ah, so you want to go around that policy by posting non-RFC patch as
RFC. It does not work like that.

Best regards,
Krzysztof
Siddharth Vadapalli Jan. 9, 2024, 4:08 a.m. UTC | #6
On 08/01/24 17:56, Krzysztof Kozlowski wrote:
> On 08/01/2024 12:34, Siddharth Vadapalli wrote:
>>>>>
>>>>> Why is this patch incomplete? What is missing here? What are you asking
>>>>> about as RFC?
>>>>
>>>> Since the merge window is closed, I was hoping to get the patch reviewed in
>>>> order to get any "Reviewed-by" tags if possible. That way, I will be able to
>>>> post it again as v1 along with the tags when the merge window opens. For that
>>>
>>> This is v1, so that would be v2.
>>>
>>>> reason, I have marked it as an RFC patch. Is there an alternative to this "RFC
>>>> patch" method that I have followed? Please let me know.
>>>
>>> Then how does it differ from posting without RFC? Sorry, RFC is
>>> incomplete work. Often ignored during review.
>>
>> I was under the impression that posting patches when the merge window is closed
>> will be met with a "post your patch later when the merge window is open"
>> response. That is why I chose the "RFC patch" path since RFCs can be posted anytime.
>>
>> For the Networking Subsystem, it is documented that patches with new features
>> shouldn't be posted when the merge window is closed. I have mostly posted
>> patches for the Networking Subsystem and am not sure about the rules for the
>> device-tree bindings and PCI Subsystems. To be on the safe side I posted this
>> patch as an RFC patch.
> 
> Ah, so you want to go around that policy by posting non-RFC patch as
> RFC. It does not work like that.

Thank you for clarifying. May I post the v2 of this patch in that case, after
rebasing it on the latest linux-next? I wish to receive feedback or Reviewed-by
tags for the v2 patch and post the v3 accordingly when the merge window opens again.
Rob Herring (Arm) Jan. 13, 2024, 1:45 a.m. UTC | #7
On Mon, 08 Jan 2024 10:37:35 +0530, Siddharth Vadapalli wrote:
> Add the device-id of 0xb012 for the PCIe controller on the J784S4 SoC as
> described in the CTRL_MMR_PCI_DEVICE_ID register's PCI_DEVICE_ID_DEVICE_ID
> field. The Register descriptions and the Technical Reference Manual for
> J784S4 SoC can be found at: https://www.ti.com/lit/zip/spruj52
> 
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
> 
> This patch is based on linux-next tagged next-20240105.
> 
> Regards,
> Siddharth.
> 
>  Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
index b7a534cef24d..0b1f21570ed0 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
@@ -68,6 +68,7 @@  properties:
       - 0xb00d
       - 0xb00f
       - 0xb010
+      - 0xb012
       - 0xb013
 
   msi-map: true