From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DC1FC001B2 for ; Fri, 9 Dec 2022 00:36:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229738AbiLIAgl (ORCPT ); Thu, 8 Dec 2022 19:36:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229593AbiLIAgk (ORCPT ); Thu, 8 Dec 2022 19:36:40 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F6DA9D2F7; Thu, 8 Dec 2022 16:36:38 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4B51AB825BC; Fri, 9 Dec 2022 00:36:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B02B0C433D2; Fri, 9 Dec 2022 00:36:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670546196; bh=eS8a/870Vq6o+U0jzi3hH5Q2d6yDRgQcjSD+pj6+cK0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YqDPDVPkIoOgfNNPiA/VU2t7Tu4QQkq5Oh/0Ydb3C/pq9+Sp7hgUU6/ECF5arn9xT 8SsMH/nH7P4nX9Qyz8l0SQFaLVz3JAs3KAMvyGb9eCSzo945CuaNiGZOATp1C+tjma 1qPP+H9GzkR+/nJI4WfqQU3Xc8kd5gwT6t1g1WWedSn3DMG0zx2uU03kOvkCNZD1bY tLflDCXpPO9ZegkGEn6RU/0Py/52DH8pphno1Ek2NytOMpXuwc7Rp+Ynh3FRTVCFBm 0+aZ9HVv0Cl8klIqnq/UI8IQKtzVqOVkSTimnjtAwUSfiVtID4Avaqa+L8iKHtXbsB PW15puTR9owsQ== Date: Thu, 8 Dec 2022 16:36:34 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: "Kubalewski, Arkadiusz" , Vadim Fedorenko , Jonathan Lemon , Paolo Abeni , "netdev@vger.kernel.org" , Vadim Fedorenko , "linux-clk@vger.kernel.org" Subject: Re: [RFC PATCH v4 4/4] ptp_ocp: implement DPLL ops Message-ID: <20221208163634.707c6e07@kernel.org> In-Reply-To: References: <20221129213724.10119-1-vfedorenko@novek.ru> <20221129213724.10119-5-vfedorenko@novek.ru> <20221206183313.713656f8@kernel.org> <20221207090524.3f562eeb@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 8 Dec 2022 12:22:09 +0100 Jiri Pirko wrote: > >To what practical benefit? Where do we draw the line? Do you want > >PTP clocks to also be auxdevs? DPLL lives in netdev, we don't have > >to complicate things. auxdev is a Conway's law solution. > > Auxdev infra is quite simple to implement, I'm not sure what do you mean > by complicating thing here. You didn't answer my question - what's the benefit? We're not faced with A or B choice. We have a A or nothing choice. Doing nothing is easy. > >mlx5 already looks like sausage meat, it's already minced so you can > >fit it there quite easily, but don't force it on non-enterprise devices. > > Not forcing, just suggesting. It's a low-hanging fruit, why not reach > it? What is the fruit? > >There is non 1:1 relationship with a bus device and subsystem in Linux, > >LMK when you convinced Greg otherwise. > > Sure there is not. But maybe that is due to the simple fact that auxdev > was introduces, what, 2 years back? My point is, we are introducing new > subsystem, wouldn't it be nice to start it clean? Still not getting what you think is clean.. Making all driver-facing objects in the kernel be a fake bus-device?!