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 E803AC63703 for ; Wed, 7 Dec 2022 23:22:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230102AbiLGXWC (ORCPT ); Wed, 7 Dec 2022 18:22:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230094AbiLGXWB (ORCPT ); Wed, 7 Dec 2022 18:22:01 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA8F72AC41; Wed, 7 Dec 2022 15:21:59 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 85E4561CE1; Wed, 7 Dec 2022 23:21:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 964F9C433C1; Wed, 7 Dec 2022 23:21:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670455318; bh=dVKNuSs23/RLcOZiUdgdY2RGcdWZI8KuPFx1NSO6Lg4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=niOao95J921qZ+6Nvip0Uv3W/z/wALnJXAO129lsAWEgxw6Polxdli306eglq8SYp qL6LG2B7ws4h2a08ROAHnFnZMHm6FrlKM6LRxffHEOLZ328nJsXyo93LFpDTZdTZKp wOxgeEmmxugjdDJPu10tFE6i9L7/tFB23hJTEacxvnHcybODlW8EY/U0tuotOOGUjC bdHNkEmFvVZyiFgel2N1lfGEEOhtPoz4jHMguosdcvPaeoT86sQkIpQCCKN8SPwywC ho+VzMjeREGZYfAsPlUEvBSqAkNleooZiFlyomhGmPwThqimVRoifiMzEDGPq/cD+G hwhqbZOGdHysA== Date: Wed, 7 Dec 2022 15:21:57 -0800 From: Jakub Kicinski To: Cc: "'Jiri Pirko'" , "'Kubalewski, Arkadiusz'" , "'Vadim Fedorenko'" , "'Jonathan Lemon'" , "'Paolo Abeni'" , , , Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Message-ID: <20221207152157.6185b52b@kernel.org> In-Reply-To: <10bb01d90a45$77189060$6549b120$@gmail.com> References: <20221129213724.10119-1-vfedorenko@novek.ru> <20221206184740.28cb7627@kernel.org> <10bb01d90a45$77189060$6549b120$@gmail.com> 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 Wed, 7 Dec 2022 15:09:03 +0100 netdev.dump@gmail.com wrote: > > -----Original Message----- > > From: Jakub Kicinski > > Sent: Wednesday, December 7, 2022 3:48 AM > > Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API > > > > On Fri, 2 Dec 2022 17:12:06 +0100 Jiri Pirko wrote: > [...] > capable > [...] > require > [...] Please fix line wrapping in your email client. And add a name to your account configuration :/ > > > Yep, you have the knowledge of sharing inside the driver, so you should > > > do it there. For multiple instances, use in-driver notifier for example. > > > > No, complexity in the drivers is not a good idea. The core should cover > > the complexity and let the drivers be simple. > > But how does Driver A know where to connect its pin to? It makes sense to > share I think we discussed using serial numbers. > pins between the DPLLs exposed by a single driver, but not really outside of > it. > And that can be done simply by putting the pin ptr from the DPLLA into the > pin > list of DPLLB. Are you saying within the driver it's somehow easier? The driver state is mostly per bus device, so I don't see how. > If we want the kitchen-and-sink solution, we need to think about corner > cases. > Which pin should the API give to the userspace app - original, or > muxed/parent? IDK if I parse but I think both. If selected pin is not directly attached the core should configure muxes. > How would a teardown look like - if Driver A registered DPLLA with Pin1 and > Driver B added the muxed pin then how should Driver A properly > release its pins? Should it just send a message to driver B and trust that > it > will receive it in time before we tear everything apart? Trivial. > There are many problems with that approach, and the submitted patch is not > explaining any of them. E.g. it contains the dpll_muxed_pin_register but no > free > counterpart + no flows. SMOC. > If we want to get shared pins, we need a good example of how this mechanism > can be used. Agreed. > > > There are currently 3 drivers for dpll I know of. This in ptp_ocp and > > > mlx5 there is no concept of sharing pins. You you are talking about a > > > single driver. > > > > > > What I'm trying to say is, looking at the code, the pin sharing, > > > references and locking makes things uncomfortably complex. You are so > > > far the only driver to need this, do it internally. If in the future > > > other driver appears, this code would be eventually pushed into dpll > > > core. No impact on UAPI from what I see. Please keep things as simple as > > > possible. > > > > But the pin is shared for one driver. Who cares if it's not shared in > > another. The user space must be able to reason about the constraints. > > > > You are suggesting drivers to magically flip state in core objects > > because of some hidden dependencies?! > > If we want to go outside the device, we'd need some universal language > to describe external connections - such as the devicetree. I don't see how > we can reliably implement inter-driver dependency otherwise. There's plenty examples in the tree. If we can't use serial number directly we can compare the driver pointer + whatever you'd compare in the driver internal solution. > I think this would be better served in the userspace with a board-specific > config file. Especially since the pins can be externally connected anyway. Opinions vary, progress is not being made. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B0D00C4708D for ; Wed, 7 Dec 2022 23:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=F8WNRtwi7ELJz8dUXwNcAcivtM/zjaLu4LfN1FPv8VE=; b=xWpZg3A1C7cays bMDbS8kuMkcKIidvtucvHhM9aIjuY1uGRvutZ5H2Nkc0xIVFSDF2S8kEMpzpUC5QHrFVsA9Vfmviz s8gJW23VNgTq0XSPm+ewrhFnF4RAqZd9PQhbEYU/8MGTXYPm1mDmIItm8IX6FaOmnmuLoaogBoDkr NfJP8CvZOGm7kUT7t8REwUF1QKrhqG01JG4v5JG01u9Nff0S/RRHGbQFiJuZ7VaMJ9r2ms62DAMc3 RRY77qZXp0vZJEuGdweKU7rbdzaPYXX/U7i3u3nVwn8NWIu3Olbgkx/ytXQDiXmUOjcq6u0XrYIwt pYzrgFzl2vfMxs/2Ur4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p33jo-00FGhD-TI; Wed, 07 Dec 2022 23:22:05 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p33jl-00FGcv-Ki for linux-arm-kernel@lists.infradead.org; Wed, 07 Dec 2022 23:22:03 +0000 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 1C6A1B82151; Wed, 7 Dec 2022 23:22:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 964F9C433C1; Wed, 7 Dec 2022 23:21:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670455318; bh=dVKNuSs23/RLcOZiUdgdY2RGcdWZI8KuPFx1NSO6Lg4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=niOao95J921qZ+6Nvip0Uv3W/z/wALnJXAO129lsAWEgxw6Polxdli306eglq8SYp qL6LG2B7ws4h2a08ROAHnFnZMHm6FrlKM6LRxffHEOLZ328nJsXyo93LFpDTZdTZKp wOxgeEmmxugjdDJPu10tFE6i9L7/tFB23hJTEacxvnHcybODlW8EY/U0tuotOOGUjC bdHNkEmFvVZyiFgel2N1lfGEEOhtPoz4jHMguosdcvPaeoT86sQkIpQCCKN8SPwywC ho+VzMjeREGZYfAsPlUEvBSqAkNleooZiFlyomhGmPwThqimVRoifiMzEDGPq/cD+G hwhqbZOGdHysA== Date: Wed, 7 Dec 2022 15:21:57 -0800 From: Jakub Kicinski To: Cc: "'Jiri Pirko'" , "'Kubalewski, Arkadiusz'" , "'Vadim Fedorenko'" , "'Jonathan Lemon'" , "'Paolo Abeni'" , , , Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Message-ID: <20221207152157.6185b52b@kernel.org> In-Reply-To: <10bb01d90a45$77189060$6549b120$@gmail.com> References: <20221129213724.10119-1-vfedorenko@novek.ru> <20221206184740.28cb7627@kernel.org> <10bb01d90a45$77189060$6549b120$@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221207_152202_029806_3033C521 X-CRM114-Status: GOOD ( 43.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 7 Dec 2022 15:09:03 +0100 netdev.dump@gmail.com wrote: > > -----Original Message----- > > From: Jakub Kicinski > > Sent: Wednesday, December 7, 2022 3:48 AM > > Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API > > > > On Fri, 2 Dec 2022 17:12:06 +0100 Jiri Pirko wrote: > [...] > capable > [...] > require > [...] Please fix line wrapping in your email client. And add a name to your account configuration :/ > > > Yep, you have the knowledge of sharing inside the driver, so you should > > > do it there. For multiple instances, use in-driver notifier for example. > > > > No, complexity in the drivers is not a good idea. The core should cover > > the complexity and let the drivers be simple. > > But how does Driver A know where to connect its pin to? It makes sense to > share I think we discussed using serial numbers. > pins between the DPLLs exposed by a single driver, but not really outside of > it. > And that can be done simply by putting the pin ptr from the DPLLA into the > pin > list of DPLLB. Are you saying within the driver it's somehow easier? The driver state is mostly per bus device, so I don't see how. > If we want the kitchen-and-sink solution, we need to think about corner > cases. > Which pin should the API give to the userspace app - original, or > muxed/parent? IDK if I parse but I think both. If selected pin is not directly attached the core should configure muxes. > How would a teardown look like - if Driver A registered DPLLA with Pin1 and > Driver B added the muxed pin then how should Driver A properly > release its pins? Should it just send a message to driver B and trust that > it > will receive it in time before we tear everything apart? Trivial. > There are many problems with that approach, and the submitted patch is not > explaining any of them. E.g. it contains the dpll_muxed_pin_register but no > free > counterpart + no flows. SMOC. > If we want to get shared pins, we need a good example of how this mechanism > can be used. Agreed. > > > There are currently 3 drivers for dpll I know of. This in ptp_ocp and > > > mlx5 there is no concept of sharing pins. You you are talking about a > > > single driver. > > > > > > What I'm trying to say is, looking at the code, the pin sharing, > > > references and locking makes things uncomfortably complex. You are so > > > far the only driver to need this, do it internally. If in the future > > > other driver appears, this code would be eventually pushed into dpll > > > core. No impact on UAPI from what I see. Please keep things as simple as > > > possible. > > > > But the pin is shared for one driver. Who cares if it's not shared in > > another. The user space must be able to reason about the constraints. > > > > You are suggesting drivers to magically flip state in core objects > > because of some hidden dependencies?! > > If we want to go outside the device, we'd need some universal language > to describe external connections - such as the devicetree. I don't see how > we can reliably implement inter-driver dependency otherwise. There's plenty examples in the tree. If we can't use serial number directly we can compare the driver pointer + whatever you'd compare in the driver internal solution. > I think this would be better served in the userspace with a board-specific > config file. Especially since the pins can be externally connected anyway. Opinions vary, progress is not being made. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel