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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 6BB60C3A5A0 for ; Mon, 20 Apr 2020 17:20:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4528D208E4 for ; Mon, 20 Apr 2020 17:20:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="Ie5TFC4x" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726750AbgDTRUa (ORCPT ); Mon, 20 Apr 2020 13:20:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726013AbgDTRUa (ORCPT ); Mon, 20 Apr 2020 13:20:30 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BC37C061A0C; Mon, 20 Apr 2020 10:20:29 -0700 (PDT) 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-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding: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=d8hn8TYhXkanozCI896xHfztLh3G1m8lpd0qQJenmuE=; b=Ie5TFC4xXLvpH8VIdZhJgD/vQ U0UnL3buhmistVbJaceQe2O08t0R8ajzlMqcANzrvhpG7EVkigE99IQIPz3V21WX7wXNlCAWbbMg+ KacUXQy44xapf7PVhh6B1RCbSqXheTXfugi9pzz/TTW33QFoxAqUov3nKP1dUV9CRISq5YoV5ghrx rD2eDKRilSdZiaks8OJHTv47vE1YMWE2b7KqwcsRi15gvUfmm6bWCBvE1GZ7xEdsB4M8v+TpHf9wc k6fPgbq22LikuV14yTqjXD1DOX/TvSXJkhxDqsC3tN5kXgezZ2+SzwXbtb13DjMhMBjzZwDiPn8xT Dle/kOZKA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:52812) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jQa5i-0004i2-Nw; Mon, 20 Apr 2020 18:20:18 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jQa5d-00060E-8D; Mon, 20 Apr 2020 18:20:13 +0100 Date: Mon, 20 Apr 2020 18:20:13 +0100 From: Russell King - ARM Linux admin To: Michael Walle Cc: Andrew Lunn , linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Jean Delvare , Guenter Roeck , Florian Fainelli , Heiner Kallweit , "David S . Miller" Subject: Re: [PATCH net-next 3/3] net: phy: bcm54140: add hwmon support Message-ID: <20200420172013.GZ25745@shell.armlinux.org.uk> References: <20200417201338.GI785713@lunn.ch> <84679226df03bdd8060cb95761724d3a@walle.cc> <20200417212829.GJ785713@lunn.ch> <4f3ff33f78472f547212f87f75a37b66@walle.cc> <20200419162928.GL836632@lunn.ch> <20200419170547.GO836632@lunn.ch> <0f7ea4522a76f977f3aa3a80dd62201d@walle.cc> <20200419215549.GR836632@lunn.ch> <75428c5faab7fc656051ab227663e6e6@walle.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75428c5faab7fc656051ab227663e6e6@walle.cc> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 20, 2020 at 05:10:19PM +0200, Michael Walle wrote: > Hi Andrew, > > Am 2020-04-19 23:55, schrieb Andrew Lunn: > > > But what does that have to do with the shared structure? I don't think > > > you have to "bundle" the shared structure with the "access the global > > > registers" method. > > > > We don't need to. But it would be a good way to clean up code which > > locks the mdio bus, does a register access on some other device, and > > then unlocks the bus. > > I'd like do an RFC for that. But how should I proceed with the original > patch series? Should I send an updated version; you didn't reply to the > LED stuff. That is the last remark for now. The LED stuff is something that there isn't a solution for at the moment. There's been talk about coming up with some generic way to describe the PHY LED configuration in DT, but given that almost every PHY has quite different ways to configure LEDs, I fear such a task is virtually impossible. Very few PHYs under Linux have their LEDs operating "correctly" or in a meaningful or sensible way because of this, and it's been this way for years. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up