Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1443183pxb; Wed, 2 Feb 2022 05:14:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJzq1/SOeuefN60p8OePJL1XjJxsq+G4SVEjbhdmSTpa26L7/nxbpSAOs9bdDXeo+pg2EmfU X-Received: by 2002:a17:90b:3009:: with SMTP id hg9mr7981471pjb.68.1643807662040; Wed, 02 Feb 2022 05:14:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643807662; cv=none; d=google.com; s=arc-20160816; b=asYmVFHOguk7ee21de0Jwb7GBlwkGsLpgEolFILQHiNICIDq6536zF7o1isuID+PO9 FX3d9mXNrNfzDUggaHVqvTeNaRw1cNYYzcacTAuGMDk263SU0bH93H3l5rA4Z+sDg952 MhrP1l8JKFR8D0qZTEhcX72KIaMueWZHKaWyhR0KAcda80r5HXcm90K0PAATXkGnlX9d eKkYx5dcUyEX5X1xNvujjef3bWFHguvu8y4OBVbUjxchet+Yp7TUDqB9jey/sHTNBPpw LiKdhs3hENvIJyzLsxL5X+Ne18etgibnjY1WJD6ooTTF9J7CMfwQHsDk1YRySMMwsSdH Pz/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=GIsDKDJJ906n8rDktoO+wzfQ/bQlOPoH/WhlGNdvSuQ=; b=HGk47wT7dlBVVB5UwbeOT61Oeld1r4QpXIXst72Gjeu+PCNhboGHBG9MzXQcT4rUEk AydLGvs6eGfYzs4LiKMBApiDwUiU9uZvkh6xL9xDjjAe/ebLw6KR+9s7VyqxoJOe7GzO /6XrsSsOkTw2rsKgOttV2cmWt+wmns6iS0bqGJ4drIuwkO9GxzkU98/wpSK9N32ilGoc pctipvPZ/VhKVU9j34WbqLquUcr+alkPwwjHCLiN9PwNB5GlewzocHnkU68XRnyY9peP yjT3J+CSCA1flg7hn7SDNnphVjCo++UQltQnM8vogw9rjU/Qnwu/xQ3iOajt5cwS5IvK U+fA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gateworks-com.20210112.gappssmtp.com header.s=20210112 header.b=C1rgX19u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t1si19720974pgl.490.2022.02.02.05.14.09; Wed, 02 Feb 2022 05:14:21 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gateworks-com.20210112.gappssmtp.com header.s=20210112 header.b=C1rgX19u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234341AbiBAUzG (ORCPT + 99 others); Tue, 1 Feb 2022 15:55:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229693AbiBAUyy (ORCPT ); Tue, 1 Feb 2022 15:54:54 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91F36C06174E for ; Tue, 1 Feb 2022 12:54:54 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id cq9-20020a17090af98900b001b8262fe2d5so619460pjb.0 for ; Tue, 01 Feb 2022 12:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GIsDKDJJ906n8rDktoO+wzfQ/bQlOPoH/WhlGNdvSuQ=; b=C1rgX19uCzxC26eMC121f6fLG7IdfYgVgd8fIENIEreQseymkVryt/S0SPPJWuMpz9 Nir5/NsGwF9yH+73oYdsaH/3/MJBuVDELgZ4AEteh+/dLWJNIoxCjDW8D32ej5NqJNbO Stvj1+NZmfubXFxuq7ofodQdbNbVAJzEOc3LaLGUC0hXv/OYD2tA8tddEiB4y6O5Blva NXsIzj5paRcLX+ppnCftBWUJbRGN5XtAHdAxPVRn+E3hPl2AxZfNHYrXAscDlvZK74vv Ui9akpOcaPeeo6+NOo8fzCUh+jLx6vJhBjV3Fy87FAiIQwfDgl88G/z4R5Vd87KTZcIB UXRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GIsDKDJJ906n8rDktoO+wzfQ/bQlOPoH/WhlGNdvSuQ=; b=sG+A61iW+H/Q1AXz3Ay8lfgFswl8x4sCr1WRziiWi0jm16RhlpDV6GblPNndBjobt4 HvCMxaGAmtFiumZtmgyP8kdP61Xqe+kNLC7cIXwL/j+ndA7TfTEZVsNbjP+QW1FjhdIE RHZ0/0OysrQ75n6pU8nEtQBctDCi7SA3ZfIj0h5E4PLS+/cw1HOLR2+k1qUpA+F8QwWh JgmqCUSghwzJh8iiS/N7qUOpaHBtY12PvXuTIFBrdgJYOccRYamfmChEgk1b9WuMbqzN vyTn5ZZngRFrrqabBMxcGhQHRYuilXebXDVEqFTqQfl0apmMiX+TyytBOo23oDMojARA 32fg== X-Gm-Message-State: AOAM532NhblJp5zW8+YkddCel3HRmV7kYvM2W93HcI13Ss2f0FrF7rvp wRDxeMeazUktydEdYIa039b/dQbRp0d2XjuMuMOLFw== X-Received: by 2002:a17:90b:4a82:: with SMTP id lp2mr4426203pjb.179.1643748893933; Tue, 01 Feb 2022 12:54:53 -0800 (PST) MIME-Version: 1.0 References: <20210421055047.22858-1-ms@dev.tdt.de> In-Reply-To: <20210421055047.22858-1-ms@dev.tdt.de> From: Tim Harvey Date: Tue, 1 Feb 2022 12:54:42 -0800 Message-ID: Subject: Re: [PATCH net v3] net: phy: intel-xway: enable integrated led functions To: Martin Schiller Cc: Hauke Mehrtens , martin.blumenstingl@googlemail.com, Florian Fainelli , Andrew Lunn , hkallweit1@gmail.com, Russell King - ARM Linux , David Miller , kuba@kernel.org, netdev , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 20, 2021 at 10:51 PM Martin Schiller wrote: > > The Intel xway phys offer the possibility to deactivate the integrated > LED function and to control the LEDs manually. > If this was set by the bootloader, it must be ensured that the > integrated LED function is enabled for all LEDs when loading the driver. > > Before commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") > the LEDs were enabled by a soft-reset of the PHY (using > genphy_soft_reset). Initialize the XWAY_MDIO_LED with it's default > value (which is applied during a soft reset) instead of adding back > the soft reset. This brings back the default LED configuration while > still preventing an excessive amount of soft resets. > > Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") > Signed-off-by: Martin Schiller > --- > > Changes to v2: > o Fixed commit message > o Fixed email recipients once again. > > Changes to v1: > Added additional email recipients. > > --- > drivers/net/phy/intel-xway.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/drivers/net/phy/intel-xway.c b/drivers/net/phy/intel-xway.c > index 6eac50d4b42f..d453ec016168 100644 > --- a/drivers/net/phy/intel-xway.c > +++ b/drivers/net/phy/intel-xway.c > @@ -11,6 +11,18 @@ > > #define XWAY_MDIO_IMASK 0x19 /* interrupt mask */ > #define XWAY_MDIO_ISTAT 0x1A /* interrupt status */ > +#define XWAY_MDIO_LED 0x1B /* led control */ > + > +/* bit 15:12 are reserved */ > +#define XWAY_MDIO_LED_LED3_EN BIT(11) /* Enable the integrated function of LED3 */ > +#define XWAY_MDIO_LED_LED2_EN BIT(10) /* Enable the integrated function of LED2 */ > +#define XWAY_MDIO_LED_LED1_EN BIT(9) /* Enable the integrated function of LED1 */ > +#define XWAY_MDIO_LED_LED0_EN BIT(8) /* Enable the integrated function of LED0 */ > +/* bit 7:4 are reserved */ > +#define XWAY_MDIO_LED_LED3_DA BIT(3) /* Direct Access to LED3 */ > +#define XWAY_MDIO_LED_LED2_DA BIT(2) /* Direct Access to LED2 */ > +#define XWAY_MDIO_LED_LED1_DA BIT(1) /* Direct Access to LED1 */ > +#define XWAY_MDIO_LED_LED0_DA BIT(0) /* Direct Access to LED0 */ > > #define XWAY_MDIO_INIT_WOL BIT(15) /* Wake-On-LAN */ > #define XWAY_MDIO_INIT_MSRE BIT(14) > @@ -159,6 +171,15 @@ static int xway_gphy_config_init(struct phy_device *phydev) > /* Clear all pending interrupts */ > phy_read(phydev, XWAY_MDIO_ISTAT); > > + /* Ensure that integrated led function is enabled for all leds */ > + err = phy_write(phydev, XWAY_MDIO_LED, > + XWAY_MDIO_LED_LED0_EN | > + XWAY_MDIO_LED_LED1_EN | > + XWAY_MDIO_LED_LED2_EN | > + XWAY_MDIO_LED_LED3_EN); > + if (err) > + return err; > + > phy_write_mmd(phydev, MDIO_MMD_VEND2, XWAY_MMD_LEDCH, > XWAY_MMD_LEDCH_NACS_NONE | > XWAY_MMD_LEDCH_SBF_F02HZ | > -- > 2.20.1 > Hi Martin, Similar to my response in another thread to how be393dd685d2 ("net: phy: intel-xway: Add RGMII internal delay configuration") which changes the tx/rx interna delays to default values of 2ns if the common delay properties are not found in the dt and thus may override what boot firmware configured, I do not like the fact that this patch just overrides LED configuration that boot firmware may have setup. I am aware that there is not much consistency in PHY's for LED configuration which makes coming up with common dt bindings impossible but I feel that if PHY drivers add LED configuration they should only apply it if new bindings are found instructing it to. Perhaps it makes sense to at least create a common binding that allows configuration of LED's here? As a person responsible for boot firmware through kernel for a set of boards I continue to do the following to keep Linux from mucking with various PHY configurations: - remove PHY reset pins from Linux DT's to keep Linux from hard resetting PHY's - disabling PHY drivers What are your thoughts about this? Best regards, Tim