[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0daa6f37-8c50-4051-873a-4e8cd4e6cc58@kernel.org>
Date: Wed, 14 Feb 2024 13:31:29 -0700
From: David Ahern <dsahern@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Saeed Mahameed <saeed@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Leon Romanovsky <leonro@...dia.com>, Jason Gunthorpe <jgg@...dia.com>,
Jiri Pirko <jiri@...dia.com>, Leonid Bloch <lbloch@...dia.com>,
Itay Avraham <itayavr@...dia.com>, Saeed Mahameed <saeedm@...dia.com>,
Aron Silverton <aron.silverton@...cle.com>,
Christoph Hellwig <hch@...radead.org>, andrew.gospodarek@...adcom.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver
On 2/9/24 10:01 PM, David Ahern wrote:
> Maybe my bigger question is should drivers that can do different
> physical layers, or can operate without a netdev, should they be split
> into different drivers? drivers/misc for the PCI interface, drivers/net
> for ethernet interfaces and its APIs and drivers/infiniband for IB and
> its APIs? Generic capabilities like this debugging interface belong to
> the PCI device since it is generic to the device hence drivers/misc.
>
I do not recall seeing a response to this line of questions. We are
considering splitting our driver along these lines to upstream it given
the independent nature of the capabilities and need to interact with
different S/W APIs and hence different maintainers. Any reason new
drivers should not be split along these lines?
If the answer is no, then where is the best home for the PCI device
driver piece of it? drivers/misc or drivers/accel or create a new
drivers/multifcn/?
Powered by blists - more mailing lists