Received-SPF: pass (google.com: domain of linux-kernel+bounces-19438-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <e4bd76d1-e5d9-4ff6-8917-db5784dea847@ti.com>
Date: Mon, 8 Jan 2024 17:04:14 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
CC: <linux-pci@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
        <srk@ti.com>, <s-vadapalli@ti.com>
Subject: Re: [RFC PATCH] dt-bindings: PCI: ti,j721e-pci-host: Add device-id
 for TI's J784S4 SoC
Content-Language: en-US
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        <lpieralisi@kernel.org>, <kw@linux.com>, <robh@kernel.org>,
        <bhelgaas@google.com>, <krzysztof.kozlowski+dt@linaro.org>,
        <conor+dt@kernel.org>
References: <20240108050735.512445-1-s-vadapalli@ti.com>
 <67af1724-6424-456a-aff6-85d9e010c430@linaro.org>
 <bc3a0fb0-6268-476a-a13a-2d538704f61d@ti.com>
 <7d3439c2-35e3-4318-aa99-af9b7c8ed53b@linaro.org>
From: Siddharth Vadapalli <s-vadapalli@ti.com>
In-Reply-To: <7d3439c2-35e3-4318-aa99-af9b7c8ed53b@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit


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.

-- 
Regards,
Siddharth.