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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5AA4C433DF for ; Sat, 4 Jul 2020 14:08:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A258A20885 for ; Sat, 4 Jul 2020 14:08:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bGGfNXsw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726819AbgGDOIy (ORCPT ); Sat, 4 Jul 2020 10:08:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726258AbgGDOIy (ORCPT ); Sat, 4 Jul 2020 10:08:54 -0400 Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2858EC061794; Sat, 4 Jul 2020 07:08:54 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id w17so27994411oie.6; Sat, 04 Jul 2020 07:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sruIXwAXhVbyB5irGxpmieYBkvT+Yh76sngiyp81DSY=; b=bGGfNXswYZe14/cuzAmIfTCOrYwfHvCH4h2te1yO88pI7RbPNA7Czv4reMww8I8SbP s7KT5FPP1bFRY4eFbAuO4gaa8m7yQVpHAYj/lMxb4yc97Az2qudXG0cbkRsYUUD3wZoF VcfO/PuPPWvtKdkXdSKu7vcI1ir7FriWYlg+YA0IYCfpVJH0UvzY1LXnLM1XgzBP40WZ jfTvdG/d7nzvQcNmMNtQZZGcTvo0v8HkU6ccy9hOpu+mYF/Sq7YbmlKkHIMZJk+UZhaH yQZa/f4ADWlFCb+UE+CsDdnFeAWIn9DAei37pKrH6P/kqqxK70mAp9uaEyAIA+AGLOPT fSIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sruIXwAXhVbyB5irGxpmieYBkvT+Yh76sngiyp81DSY=; b=opqxa+FgwjmJqkAq856nfqoAgVdogaV50658Qsj9tBg0TB+7jGuFu9v+OkyHv69dZk Yl7fa90kDXtefzmPwLOGxCspKyhlDFIdxae9Sfc7EgHEBvSuVJBIOkdsMPERd9fxEu1e xaSfILW86HUKQjoDuHFKj4zzKrwnRCZZd+liWB7au2U2kFj7uu7qeKOqd2yNDg8jC5Cp BTpLD8iWlNnrDDIuCbIQ8NaU6MV6yYTy7H6qAf8dBLAmNoKzvaqjsHKr5G02DKwxL4yh wau5HJYUJXEMUyfXi0Q+H7+w+VwuEyFfcU42p7oLRcjxvT8eMCn9ynD7FZTd1KcjuM13 pNgA== X-Gm-Message-State: AOAM533rNVbfuEN2xltMvguTaJ9NoDKRWn7E0NftZRkdlxboxKr2lIxD 65Y9ld4j0NjkJ/g5G1DVZ61oG9fQrBbM0JNNiEA= X-Google-Smtp-Source: ABdhPJztoFfvdTLj2yMn1sCGZxmmBOCYmRIuPcHWgshbnsn/EhxPtETALm2xO46URFZ5cicFgCzGhlj5YWM8/IMYuUI= X-Received: by 2002:aca:b205:: with SMTP id b5mr32722874oif.103.1593871733367; Sat, 04 Jul 2020 07:08:53 -0700 (PDT) MIME-Version: 1.0 References: <20200702175352.19223-1-TheSven73@gmail.com> <20200702175352.19223-3-TheSven73@gmail.com> In-Reply-To: From: Sven Van Asbroeck Date: Sat, 4 Jul 2020 10:08:42 -0400 Message-ID: Subject: Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref To: Fabio Estevam Cc: Shawn Guo , Fugang Duan , Rob Herring , "David S. Miller" , Jakub Kicinski , netdev , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Sascha Hauer , Pengutronix Kernel Team , NXP Linux Team , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Fabio, Andy, On Thu, Jul 2, 2020 at 6:29 PM Fabio Estevam wrote: > > With the device tree approach, I think that a better place to touch > GPR5 would be inside the fec driver. > Are we 100% sure this is the best way forward, though? All the FEC driver should care about is the FEC logic block inside the SoC. It should not concern itself with the way a SoC happens to bring a clock (PTP clock) to the input of the FEC logic block - that is purely a SoC implementation detail. It makes sense to add fsl,stop-mode (= a GPR bit) to the FEC driver, as this bit is a logic input to the FEC block, which the driver needs to dynamically flip. But the PTP clock is different, because it's statically routed by the SoC. Maybe this problem needs a clock routing solution? Isn't there an imx6q plus clock mux we're not modelling? enet_ref-o------>ext>---pad_clk--| \ | |M |----fec_ptp_clk o-----------------------|_/ Where M = mux controlled by GPR5[9] The issue here is that pad_clk is routed externally, so its parent could be any internal or external clock. I have no idea how to model this in the clock framework.