Received-SPF: pass (google.com: domain of linux-kernel+bounces-51273-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sat, 3 Feb 2024 19:38:09 +0000
From: Simon Horman <horms@kernel.org>
To: Ravi Gunasekaran <r-gunasekaran@ti.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, andrew@lunn.ch, rogerq@kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	s-vadapalli@ti.com, srk@ti.com
Subject: Re: [RFC PATCH net-next 2/2] net: ethernet: ti: inter-core-virt-eth:
 Register as network device
Message-ID: <20240203193809.GA706477@kernel.org>
References: <20240130110944.26771-1-r-gunasekaran@ti.com>
 <20240130110944.26771-3-r-gunasekaran@ti.com>
 <20240201131912.GB530335@kernel.org>
 <32f49a1d-7974-4dc6-be20-f21f5aabc264@ti.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <32f49a1d-7974-4dc6-be20-f21f5aabc264@ti.com>

On Thu, Feb 01, 2024 at 07:54:24PM +0530, Ravi Gunasekaran wrote:

..

> Thanks for taking time to review the patches.
> 
> The primary intention of this series was to know if the RPMsg based approach
> would be upstream friendly or not. But I would not like to use that as an excuse
> for not fixing checks/warnings/errors reported by checkpatch completely.
> Even though if its RFC, I will treat it as an actual upstream patch  and address the
> checkpatch/smatch/sparse findings or atleast mention in the cover letter that the
> findings have not been fully addressed.

Understood. TBH, I am unsure of the value of this kind of review for an RFC
- I understand it is important to get the bigger picture questions out of
the way at this point.

..