| Message ID | 20240108050735.512445-1-s-vadapalli@ti.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Krzysztof Wilczyński |
| Headers | show |
| Series | [RFC] dt-bindings: PCI: ti,j721e-pci-host: Add device-id for TI's J784S4 SoC | expand |
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
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 >
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
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.
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
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.
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 --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
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(+)