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 7DE31C678D5 for ; Wed, 8 Mar 2023 00:58:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229872AbjCHA6A (ORCPT ); Tue, 7 Mar 2023 19:58:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229484AbjCHA57 (ORCPT ); Tue, 7 Mar 2023 19:57:59 -0500 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69EB721961; Tue, 7 Mar 2023 16:57:58 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id t15so13880352wrz.7; Tue, 07 Mar 2023 16:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678237077; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=HS6FPXIvmqqNsIYAM5JYJ/QIONzW3Nl9HxNsbGlenoM=; b=XEYOm62uQkBq9a1kTtaYUa/sXQmdDN1evfVVkYdRuHIlDQocAZ/DVDu/t7HoxxJAzU sdG/iNf/SqbSE1smhqUQ1e/KdDdMiX5bRgrFL/iRpuVmhAzZ8eO8QrEHRqhJ4X6Zqkg7 jHtArVRmnWuTOiZWEQEKL+Z+32WIKouf+jG+4l7YrXjStuvpeLHadXReq0IuhYxTgjqw URMCAAEe70JWXIfxeUsF+lFjbB3soaxGW2fxNC+OYtbuEt0+ybv+2RpoGMKdvrw5DY8Z fxRwqsFh1hy/Kokpd8xvtii6H9uJ3+H7vn0y7IjwKjKMobxdIwpiVRoGGfAsHJb2pJQ+ 7Pbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678237077; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HS6FPXIvmqqNsIYAM5JYJ/QIONzW3Nl9HxNsbGlenoM=; b=t4CwKAGQyK8ao1Am3y/uaAU3xMked+E4goiyGpdJxLwIsLNq6Fwq9Y3NT80+QuWsxI qrO4B2ZSUdFysaH/QWxZYft2HvNOpGcFBAY8WC0alwt2Wa03Ub+vX/17zn6IHcvYaYbd slipAGoa+UEKiySLr7iP4lJFwkN/tVFFPvM7/Cf+gozixRodFetJgQNe3ipvrqmt2QQY m8jQ2cD0iVE1S2bzeTXPPvtVCnsSfW+Xf51U98T6C1XOfmzUEbkJ84mce669IN9RAdJC R6pfs/1n3/ZQRmviHu2rPN54nOxF/PYUbIZTp2cEMEt/sOjvVROTz56GZMiEXzN7ayoq +U1A== X-Gm-Message-State: AO0yUKUoRDsyKxJjTHcuHKiBt65N+IZYIpYVpL1Jbv22OuITKlXyDstK 4WdYBZ4owPow08O/iG5+pK0= X-Google-Smtp-Source: AK7set9tO5H/alRCXfzjN/mP1zUeZLrxFfo+KwylfdU81WRcdlFvzou1cKKbs+HkFxOzr2ExWYrOAw== X-Received: by 2002:adf:f30f:0:b0:2cb:f4:e5a2 with SMTP id i15-20020adff30f000000b002cb00f4e5a2mr12312806wro.14.1678237076605; Tue, 07 Mar 2023 16:57:56 -0800 (PST) Received: from Ansuel-xps. (93-34-89-197.ip49.fastwebnet.it. [93.34.89.197]) by smtp.gmail.com with ESMTPSA id f2-20020adfdb42000000b002c54fb024b2sm13605789wrj.61.2023.03.07.16.57.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Mar 2023 16:57:56 -0800 (PST) Message-ID: <6407dd94.df0a0220.b4618.52e4@mx.google.com> X-Google-Original-Message-ID: Date: Tue, 7 Mar 2023 20:41:55 +0100 From: Christian Marangi To: Andrew Lunn Cc: Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Heiner Kallweit , Russell King , Gregory Clement , Sebastian Hesselbarth , John Crispin , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lee Jones , linux-leds@vger.kernel.org Subject: Re: [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support References: <20230307170046.28917-1-ansuelsmth@gmail.com> <20230307170046.28917-2-ansuelsmth@gmail.com> <6407c6ea.050a0220.7c931.824f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Wed, Mar 08, 2023 at 01:49:55AM +0100, Andrew Lunn wrote: > On Tue, Mar 07, 2023 at 06:57:10PM +0100, Christian Marangi wrote: > > On Wed, Mar 08, 2023 at 12:16:13AM +0100, Andrew Lunn wrote: > > > > +qca8k_setup_led_ctrl(struct qca8k_priv *priv) > > > > +{ > > > > + struct fwnode_handle *ports, *port; > > > > + int port_num; > > > > + int ret; > > > > + > > > > + ports = device_get_named_child_node(priv->dev, "ports"); > > > > + if (!ports) { > > > > + dev_info(priv->dev, "No ports node specified in device tree!\n"); > > > > + return 0; > > > > + } > > > > + > > > > + fwnode_for_each_child_node(ports, port) { > > > > + struct fwnode_handle *phy_node, *reg_port_node = port; > > > > + > > > > + phy_node = fwnode_find_reference(port, "phy-handle", 0); > > > > + if (!IS_ERR(phy_node)) > > > > + reg_port_node = phy_node; > > > > > > I don't understand this bit. Why are you looking at the phy-handle? > > > > > > > + > > > > + if (fwnode_property_read_u32(reg_port_node, "reg", &port_num)) > > > > + continue; > > > > > > I would of expect port, not reg_port_node. I'm missing something > > > here.... > > > > > > > It's really not to implement ugly things like "reg - 1" > > > > On qca8k the port index goes from 0 to 6. > > 0 is cpu port 1 > > 1 is port0 at mdio reg 0 > > 2 is port1 at mdio reg 1 > > ... > > 6 is cpu port 2 > > > > Each port have a phy-handle that refer to a phy node with the correct > > reg and that reflect the correct port index. > > > > Tell me if this looks wrong, for qca8k we have qca8k_port_to_phy() and > > at times we introduced the mdio thing to describe the port - 1 directly > > in DT. If needed I can drop the additional fwnode and use this function > > but I would love to use what is defined in DT thatn a simple - 1. > > This comes back to the off list discussion earlier today. What you > actually have here are MAC LEDs, not PHY LEDs. They are implemented in > the MAC, not the PHY. To the end user, it should not matter, they > blink when you would expect. > > So your addressing should be based around the MAC port number, not the > PHY. Ok will drop this. > > Also, at the moment, all we are adding are a bunch of LEDs. There is > no link to a netdev at this point. At least, i don't see one. Be once > we start using ledtrig-netdev we will need that link to a netdev. Take > a look in my git tree at the last four patch. They add an additional > call to get the device an LED is attached to. > No currently we have no link for netdev, hence we are setting keep and not setting a default trigger in DT. Just checked them, interesting concept, guess we can think of something also for the interval setting. That would effectively make all the setting of the trigger set. Just my concern is that they may be too much specific to netdev trigger and may be problematic for other kind of hw control. (one main argument that was made for this feature was that some stuff were too much specific and actually not that generic) -- Ansuel 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 73636C678D5 for ; Wed, 8 Mar 2023 00:58:58 +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:In-Reply-To:MIME-Version:References: Subject:Cc:To:From:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=CpZpoX7vg06h6Rbh/1tFI8zby5UaAqRSxEtecsnQX9A=; b=PVxd0T5iCFQnJ0 9we+hxKN4+AvBGQHE9OYs/k+oZWGsLx7+7cuP7YuxY7Z4WL+tqyqAwWUvM2nv0FeHMMGAYezIrvSy m51mjyygFaVmySyKV2jZncPVDT3KrRBB18pMQLMKGUjoYUig1X3oPDkkRH3WlZEfIS80+OoLnHSNa FzMBUK0NV/m7WqlqMRZZkV+yR260yQQPAS7hCgcvb6jIvdLBwmC38MNPpkZKKZ5tHvFnf7rYRo4Rf QXFjTjSf4iyKkNCHW6p0HkIZImVoPl5lO04+BEMDU1XYxxzpvGvdkN4lXeinXYv1Q5xz4oK6IiSkz b7ASEBjEpFg5vJuEv6xQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZi83-0031eT-3a; Wed, 08 Mar 2023 00:58:03 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZi7z-0031dm-ER for linux-arm-kernel@lists.infradead.org; Wed, 08 Mar 2023 00:58:00 +0000 Received: by mail-wr1-x42f.google.com with SMTP id bx12so13864731wrb.11 for ; Tue, 07 Mar 2023 16:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678237077; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=HS6FPXIvmqqNsIYAM5JYJ/QIONzW3Nl9HxNsbGlenoM=; b=XEYOm62uQkBq9a1kTtaYUa/sXQmdDN1evfVVkYdRuHIlDQocAZ/DVDu/t7HoxxJAzU sdG/iNf/SqbSE1smhqUQ1e/KdDdMiX5bRgrFL/iRpuVmhAzZ8eO8QrEHRqhJ4X6Zqkg7 jHtArVRmnWuTOiZWEQEKL+Z+32WIKouf+jG+4l7YrXjStuvpeLHadXReq0IuhYxTgjqw URMCAAEe70JWXIfxeUsF+lFjbB3soaxGW2fxNC+OYtbuEt0+ybv+2RpoGMKdvrw5DY8Z fxRwqsFh1hy/Kokpd8xvtii6H9uJ3+H7vn0y7IjwKjKMobxdIwpiVRoGGfAsHJb2pJQ+ 7Pbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678237077; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HS6FPXIvmqqNsIYAM5JYJ/QIONzW3Nl9HxNsbGlenoM=; b=CP6P4lbQ4ABa/H+dLfqPthPJKQn0nH7rNeDUFvfoz2/8senEzbu/Cxc6qvHiGeKMYk RTI5GfnRR2YmLaTiauIpdHLt1u/zQ9bkuctrqTsCt/XPfnHLu+qOrPOe8PFevz9Pcsp0 NGFENKteJIfKGpJtrBXW3wbLXvfbp3CwAiosMsXXiLZb1M8lnmzazVQf06wUMGJTO/26 zP2o+ArgdoVSm6eyr7us2nGYxfYhgdhK339clbcNd72u/6hQDN9v8LDSJnotzlH32oIw I08qarytn1B3GMZFkClEFAs+TLUyGbK6qGhWgPKOuUtO/74aLQPApGQIx+ghmiyhIHKj kwfA== X-Gm-Message-State: AO0yUKU6nwvxv1xZcyC8c5uGmefYMy85YHAKJPpGFdBRL/9D7KstV62c sva+hiT7JtwRJaNARYQU3Wo= X-Google-Smtp-Source: AK7set9tO5H/alRCXfzjN/mP1zUeZLrxFfo+KwylfdU81WRcdlFvzou1cKKbs+HkFxOzr2ExWYrOAw== X-Received: by 2002:adf:f30f:0:b0:2cb:f4:e5a2 with SMTP id i15-20020adff30f000000b002cb00f4e5a2mr12312806wro.14.1678237076605; Tue, 07 Mar 2023 16:57:56 -0800 (PST) Received: from Ansuel-xps. (93-34-89-197.ip49.fastwebnet.it. [93.34.89.197]) by smtp.gmail.com with ESMTPSA id f2-20020adfdb42000000b002c54fb024b2sm13605789wrj.61.2023.03.07.16.57.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Mar 2023 16:57:56 -0800 (PST) Message-ID: <6407dd94.df0a0220.b4618.52e4@mx.google.com> X-Google-Original-Message-ID: Date: Tue, 7 Mar 2023 20:41:55 +0100 From: Christian Marangi To: Andrew Lunn Cc: Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Heiner Kallweit , Russell King , Gregory Clement , Sebastian Hesselbarth , John Crispin , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lee Jones , linux-leds@vger.kernel.org Subject: Re: [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support References: <20230307170046.28917-1-ansuelsmth@gmail.com> <20230307170046.28917-2-ansuelsmth@gmail.com> <6407c6ea.050a0220.7c931.824f@mx.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230307_165759_510583_F984DA16 X-CRM114-Status: GOOD ( 34.31 ) 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, Mar 08, 2023 at 01:49:55AM +0100, Andrew Lunn wrote: > On Tue, Mar 07, 2023 at 06:57:10PM +0100, Christian Marangi wrote: > > On Wed, Mar 08, 2023 at 12:16:13AM +0100, Andrew Lunn wrote: > > > > +qca8k_setup_led_ctrl(struct qca8k_priv *priv) > > > > +{ > > > > + struct fwnode_handle *ports, *port; > > > > + int port_num; > > > > + int ret; > > > > + > > > > + ports = device_get_named_child_node(priv->dev, "ports"); > > > > + if (!ports) { > > > > + dev_info(priv->dev, "No ports node specified in device tree!\n"); > > > > + return 0; > > > > + } > > > > + > > > > + fwnode_for_each_child_node(ports, port) { > > > > + struct fwnode_handle *phy_node, *reg_port_node = port; > > > > + > > > > + phy_node = fwnode_find_reference(port, "phy-handle", 0); > > > > + if (!IS_ERR(phy_node)) > > > > + reg_port_node = phy_node; > > > > > > I don't understand this bit. Why are you looking at the phy-handle? > > > > > > > + > > > > + if (fwnode_property_read_u32(reg_port_node, "reg", &port_num)) > > > > + continue; > > > > > > I would of expect port, not reg_port_node. I'm missing something > > > here.... > > > > > > > It's really not to implement ugly things like "reg - 1" > > > > On qca8k the port index goes from 0 to 6. > > 0 is cpu port 1 > > 1 is port0 at mdio reg 0 > > 2 is port1 at mdio reg 1 > > ... > > 6 is cpu port 2 > > > > Each port have a phy-handle that refer to a phy node with the correct > > reg and that reflect the correct port index. > > > > Tell me if this looks wrong, for qca8k we have qca8k_port_to_phy() and > > at times we introduced the mdio thing to describe the port - 1 directly > > in DT. If needed I can drop the additional fwnode and use this function > > but I would love to use what is defined in DT thatn a simple - 1. > > This comes back to the off list discussion earlier today. What you > actually have here are MAC LEDs, not PHY LEDs. They are implemented in > the MAC, not the PHY. To the end user, it should not matter, they > blink when you would expect. > > So your addressing should be based around the MAC port number, not the > PHY. Ok will drop this. > > Also, at the moment, all we are adding are a bunch of LEDs. There is > no link to a netdev at this point. At least, i don't see one. Be once > we start using ledtrig-netdev we will need that link to a netdev. Take > a look in my git tree at the last four patch. They add an additional > call to get the device an LED is attached to. > No currently we have no link for netdev, hence we are setting keep and not setting a default trigger in DT. Just checked them, interesting concept, guess we can think of something also for the interval setting. That would effectively make all the setting of the trigger set. Just my concern is that they may be too much specific to netdev trigger and may be problematic for other kind of hw control. (one main argument that was made for this feature was that some stuff were too much specific and actually not that generic) -- Ansuel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel