Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 8 Nov 2022 08:28:19 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Dave Airlie <airlied@gmail.com>
Cc:     Oded Gabbay <ogabbay@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Daniel Vetter <daniel@ffwll.ch>, Arnd Bergmann <arnd@arndb.de>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        John Hubbard <jhubbard@nvidia.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
        Jiho Chu <jiho.chu@samsung.com>,
        Daniel Stone <daniel@fooishbar.org>,
        Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
        Jeffrey Hugo <quic_jhugo@quicinc.com>,
        Christoph Hellwig <hch@infradead.org>,
        Kevin Hilman <khilman@baylibre.com>,
        Jagan Teki <jagan@amarulasolutions.com>,
        Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>,
        Maciej Kwapulinski <maciej.kwapulinski@linux.intel.com>,
        stanislaw.gruszka@intel.com
Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a
 new major
Message-ID: <Y2pLYxW8p0QeiV+3@nvidia.com>
References: <CAFCwf13uLj=P6u6FAcY8M5qAXoaBdb+Ha-TYj0j2FAZnFAPFYg@mail.gmail.com>
 <CAFCwf12yRUG4593ozJMEwaaJBKyWqXTTCjef9O_fzWdQBxVrtw@mail.gmail.com>
 <Y2kAcCu4z2LUMN7u@nvidia.com>
 <CAFCwf10K-dTu455QfOK8i6thismY-FUN2Rws830EGiqOcGWFgA@mail.gmail.com>
 <Y2kDzPswkKyZyRpS@nvidia.com>
 <CAFCwf10A=-bj2nR8WasNxyQQ07D24Je04tzKxqv2X_XnA0BUSQ@mail.gmail.com>
 <Y2kRvyR8VrZrO/1H@nvidia.com>
 <CAFCwf12E4K7bpLcDvTtG1mKxoy1JnchXGCKDvcKAayCFvGWXXQ@mail.gmail.com>
 <Y2kyvswuCsO0x1/2@nvidia.com>
 <CAPM=9twxu3v4voSukrkror1BrajShRLY9CFxYWpL2rwK7fMiKQ@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPM=9twxu3v4voSukrkror1BrajShRLY9CFxYWpL2rwK7fMiKQ@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?t4NwnxKPoqLBVWjpsdI9TymBAdbQ0hhqRWjfHB2tTW9VIy+CV5DZXusKf4kq?=
 =?us-ascii?Q?xdxjrrSFh3xbuVSUy9653fyAfMWFSOUZe6JqsNeD1rugSvu7ee72MX0XUp3z?=
 =?us-ascii?Q?r04jQaFPDRsU/SeAcqt17bTLis2fzaTrmna+xfO1vo7kOQniNIMryflQRgpn?=
 =?us-ascii?Q?+UvYYxTsFqn+E2lV8Qcdbm6vGMZNgeuF1XX3yRFdazDiLAdzgwzTajct+UND?=
 =?us-ascii?Q?9K7KRXkhC7HRrEKQLtT4xq+js6DMIp98KFg8502nudymGdzB+O2nidcycQDj?=
 =?us-ascii?Q?Tf6Fovq1vA4+d/NY7FbGxDFKgdmA0GMUpreDf4joqcG7GxGKN1kD+fw22IHL?=
 =?us-ascii?Q?Zb5EQJvQOus6dOvgGhEdPyuylgJc7hhgo2Ox3v9dJORGY72K8blGtmedkP7g?=
 =?us-ascii?Q?fzPng8AQ81E+lyMvh+x+N+Ojc+d3EPvudIM0TeiGQcumbquYY0NSkdrvDPMw?=
 =?us-ascii?Q?nhLEfFNL6/nIELoQ+K2R6GemCW+h814aAe+OCTOQmViYuUyMZSGBxeDHFrKq?=
 =?us-ascii?Q?DAZqnzqojufKsvQfoibKfW3LQOueNrsXiuFcMhLguXaQBRJMWG4W51ahM4Hd?=
 =?us-ascii?Q?i+XDRbACAISwCXZWLI4WBtucyGb3TZfK+KreituGYLdHHCt/Qu2d72R+8ROe?=
 =?us-ascii?Q?Mh+bCCzPgFdX/1h3+uiCAlpPJs2NPstB7mtpByyn1vk6ReeLKhJqvZvGvdXe?=
 =?us-ascii?Q?62DvGayQutn9SkzTCbuDH/CnRK9/0O3qgRr/EkY9/h5KfRhL0emrynmbD8bf?=
 =?us-ascii?Q?vYAIgu+xFzTbOTaoXxywQIGl2YCgpB52ZQrdUddPzGEnC30JMDMp+LXb58ro?=
 =?us-ascii?Q?R0QT/L58dvKSfUK7bc+NyZZshb53JC0GAeg4aKOOCEnHviaiSUfJsZSZHJQo?=
 =?us-ascii?Q?52kIu8ki498msUnQIZZyJ+atVzlkITW0k8LAhwLuwn6C0WP2p8Mdf7AiV3yA?=
 =?us-ascii?Q?9qAyKn3qmgLIF45kRbUPDnucXiwzaASL/UHlFtR+MQq3M1AE08kow062m6Vn?=
 =?us-ascii?Q?RrnJj+kCE3KUNYySH1ago7b4ggi/WZ8yfC183VyiCLvJeUu8fo4h3TKVTDBT?=
 =?us-ascii?Q?nYYRPLPX4oyWAVp005VbvDZ+Ef1YU1bdptcHTDefpDB7XrgwoI89I5ENtwpD?=
 =?us-ascii?Q?3//zA/kZpdFK22UvddwZToWTZ7x+y/MCtq/muqy2UOW3ABN2f8V8bFQ/9UnR?=
 =?us-ascii?Q?XailBEnd1vhidFKMn/eHb1t7/bfezhrfhb/Cl+gEgiDrtEvDN0jNU5g/LV0k?=
 =?us-ascii?Q?kpFmN16ZYlHWjtZl0knQNMzcEtS1lTmbvpHbDODnhvKpeFS5J/CwE0PokZgU?=
 =?us-ascii?Q?wVvd7JcKS5q5uJ2dbWqYbWE0HSWrF8winnpgkjzURo93GZDfaRM90fe1k2/u?=
 =?us-ascii?Q?ot5o4/Rr0E+/VPCg3v1R9DPU7PpIzzEH7Vn0lilPM4Q2zMPPOX29WbPUHQxA?=
 =?us-ascii?Q?lbYWE6jolTVUGI6ybw35Ba1YUOvkByeIxKSxV2w57FSXv0+jEVPTnb1i866u?=
 =?us-ascii?Q?GZx2zKwxPxHzbyMOKXfLcEi5mKTDxJmhxxzv9y52mnt2YU0P4wvvELthQ8ZO?=
 =?us-ascii?Q?N7F2jVMoeMc1ftEgPKs=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 32e220df-ecce-4768-7347-08dac184b8f3
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2022 12:28:21.1175
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3E5+/mKNjaa71k1CK9MVolbnYRcf/rZ04XLyFvoN1Fxzr0m/bi/1gUyswhLa3sHq
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB5020
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Nov 08, 2022 at 06:33:23AM +1000, Dave Airlie wrote:

> At plumbers we decided a direction, I think the direction is good, if
> there is refactoring to be done, I'd rather it was done in tree with a
> clear direction.
> 
> Coming in now and saying we should go down a different path isn't
> really helpful. We need to get rolling on this, we have drivers that
> want to land somewhere now, which means we need to just get a
> framework in place, leveraging drm code is the way to do it.

It is not a different path, at plumbers we decided accel should try to
re-use parts of DRM that make sense. I think that should be done by
making those DRM parts into libraries that can be re-used, not by
trying to twist DRM into something weird.

If this thing needs special major/minor numbers, it's own class, its
own debufs, sysfs, etc, then it should not be abusing the DRM struct
device infrastructure to create that very basic kernel infrastructure.

Somehow we ended up with the worst of both worlds. If you want to to
be DRM then it should just be DRM and we shouldn't see all this core
infrastructue code for debugfs/sysfs/cdevs/etc in thes patches at all.

Jason