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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 41C5EC433E0 for ; Sun, 27 Dec 2020 16:16:16 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F1CFD207CF for ; Sun, 27 Dec 2020 16:16:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1CFD207CF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=aDQgyXxpmHsZuUBfsIpz5KjQ7n8Kd+9FGxAYdBOoEHM=; b=RR3305WO1NwIsPYAhiNdAcqkV wYeQRTkYLTGbmhRmO8jrQOl6ydYG3ruRUkkaTBKmErvZnQLfAF5u74EgBCC49JtUGFqIc+seln1ex SXUJg2NXEDg6rCAUO9g2r+w0sGt4VHOqtrHQ04BLJNU+YGjN1a8Sn9OJZajhJgiaoyk8Q5DD4iumL ILLau5wumA17OZFpsWX+eMyWxB+jcuQwsQcUC7RQ62RsifbKkhuJokfSv7Y3oPjdqBg2UvRZt1rnx PS4LpAA/EVuklskwWyxBBeA1i1za1r78jQnU+azpnTc8SN8hgcuIpqsco/GdzNNNnOIGDbdiXftfo wn/qw8C7A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ktYgd-0006Wq-9H; Sun, 27 Dec 2020 16:14:27 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ktYga-0006Sk-28 for linux-arm-kernel@lists.infradead.org; Sun, 27 Dec 2020 16:14:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QKb7PedqkINLevYpI16MlA+Nvd0DaQvFFCLUFlx6SXA=; b=wztzm9EFol502iX4uD56nIKvq WRbC8wWaW1EsC+VTHb5iw+Q4UUzK0yaEj6dUxUkLuVTFDi5R2i2OkiJzXDwB0bwEkxSNVnD1GStdG gX07T1GZfoZ6S4yzWsrP3VQPYBRpQebzYdHYoBZbQqsgnM3EWRcodzbbdFCszSFacD9QnLTvIT5tl XYSrdQnT/nbBewz3O3YeaGLn8JJjwNvbe3cbShIacqxYo8RqN8SVd5sniEJNN/5Fv8YeGH9xbLsGf aBBLTyaX/fJB1zDmQHP2yraSKoRdUyEtGwHtugMD0WRzCy1yv6e3RtypmRmDfMLWES0Swcz6ZMKWc MTyvsp5rg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44574) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ktYdY-0003xQ-8Q; Sun, 27 Dec 2020 16:11:16 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1ktYdX-0007sf-5X; Sun, 27 Dec 2020 16:11:15 +0000 Date: Sun, 27 Dec 2020 16:11:15 +0000 From: Russell King - ARM Linux admin To: Michael Walle Subject: Re: Broken ethernet on SolidRun cubox-i Message-ID: <20201227161114.GF1551@shell.armlinux.org.uk> References: <2ae000163aa34b963dd387c824bdc3c9@walle.cc> <20201226123421.GD1551@shell.armlinux.org.uk> <1d79aa88e73b6e0118e570a64026817e@walle.cc> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201227_111424_410820_B8421EEE X-CRM114-Status: GOOD ( 20.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Matus Ujhelyi , acmattheis@gmx.net, Christoph Mattheis , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Dec 27, 2020 at 04:59:39PM +0100, Michael Walle wrote: > Am 2020-12-27 16:33, schrieb Michael Walle: > > Am 2020-12-26 13:34, schrieb Russell King - ARM Linux admin: > > > I'd forgotten that there were boards out there with this problem... > > > the PHY address configuration is done via the LED_ACT pin, and > > > SolidRun > > > omitted a pull resistor on it, so it "floats" with the leakage current > > > of the LED/pin - resulting in it sometimes appearing at address 0 and > > > sometimes at address 4. > > = > > Mh, I've guessed that too, but there must be more to it. The datasheet > > says it has an internal weak pull-up. Or Atheros messed up and it > > doesn't > > reliably work if there is actually an LED attached to it. But then, why > > would any other stronger pull-up/down work.. > = > Mhh, nevermind, from the commit log [1]. > = > "The LED_ACT pin on the carrier-one boards had a pull down that > forces the phy address to 0x0; where on CuBox-i and the production > HummingBoard that pin is connected directly to LED that depending > on the pull down strength of the LED it might be sampled as '0' or '1' > thus > the phy address might appear as either address 0x0 or 0x4." > = > So it actually depends on the forward voltage of the LED and the > hi/low thresholds of the AT8035.. nice! Oh and btw. this pin also > switches between high and low-active LED output. So the missing > pull-down might not only switch the PHY address to 4 but also invert > the LED state. Indeed. And whether it appears at address 0 or 4 will depend on many factors, including temperature - LEDs have a decrease of 2mV/=B0C. I wonder if we can just delete the phy-handle property, and list a PHY at both address 0 and 4 with the appropriate configuration... -- = RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel