[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19846931-4b99-4502-9e6f-e992f7959508@amperemail.onmicrosoft.com>
Date: Thu, 17 Jul 2025 17:40:03 -0400
From: Adam Young <admiyo@...eremail.onmicrosoft.com>
To: YH Chung <yh_chung@...eedtech.com>, Jeremy Kerr
<jk@...econstruct.com.au>,
"matt@...econstruct.com.au" <matt@...econstruct.com.au>,
"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com"
<pabeni@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
BMC-SW <BMC-SW@...eedtech.com>
Cc: Khang D Nguyen <khangng@...eremail.onmicrosoft.com>
Subject: Re: [PATCH] net: mctp: Add MCTP PCIe VDM transport driver
On 7/17/25 04:21, YH Chung wrote:
> Would it be preferable to create a directory such as net/mctp/aspeed/ to host the abstraction layer alongside the hardware-specific drivers?
> We're considering this structure to help encapsulate the shared logic and keep the MCTP PCIe VDM-related components organized.
My suggestiong is: Keep it simple. There are only a handful of mctp
device drivers thus far, and there seems to be little justification for
a deeper hierarchy.
Just focus on the cleanest implementation. Having two drivers plus a
single common source code for each in drivers/net/mctp seems to be
easier to manage for now.
Powered by blists - more mailing lists