Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3614647pxb; Fri, 4 Feb 2022 12:24:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfLOcHHGgfciy944rcWjLlskjqd1uH6dZPlHc8Oi1FXCTgjTkL1KFL08ZqPFDqAikBpJRh X-Received: by 2002:a17:90b:384f:: with SMTP id nl15mr768458pjb.116.1644006269081; Fri, 04 Feb 2022 12:24:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644006269; cv=none; d=google.com; s=arc-20160816; b=etal6rBMNEDNc/R5TBaipivNl0bs6l9n5imFH1Lljqq3VkbAmG7vJ11iQTbt4/4fiP qxlpewWfpt4OBw+0VZM9TH2qtC5RHxHZgt7UU2xty9AJxEgaBui10bCT6MEZzOj+MpLX W+3Yu3BlrhMu1BYZII9wY8oM5rhR/2LUqd1Z9UWKKzImbtVnRGCW70WV3Ec7TRyi9dil ZVkzKYWr+ll7fCBv5MXiXZRwZXe4gLDaW0ASOWumNmCjh8/IPz7dJhVzSm1lSLQFDmhE cEhGxWT0BwA4fUYo8I3Q+aQKuuoRS0Kr/C64MaKpKoIxZrEBfmGhL43aMlivb+OI5SqZ 2G/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=p/zPqhK7rICYn+fsLs3IXm5cKsznKQy/YMAmPq7nniU=; b=ONywyI0GE5Yvx1RsOYai40027BQOA4SPlhBDtaKLnZ4QBktVIi353D7zM+4d6GehMx 5kUzKKDMg8rnkGvjGYRHzn/aKCLbTYI0+ckZPU7hS2iH7D4Ui0C+aPlI2x4kvWBMkUhI zR+Jiakezl6UUqahh1J9l1ncYv08wRZ+zsmGL/gwd9s88CV4Y/qUQXz7wDDsxbtjqGLx ZomXafMFM6scZkejZXIjL0wBBINydWLFEYPDY7U7gQ+811iaqcLzivwlzvL1j1xw22dP i++6fLxVj3YU1tbCkrkkJtAdFNCzJdUYTDxHqUKNGprw2e3xXfpZD7aXr8Y9yGUbAF8e t4TA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=yogmTzkF; 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 r20si2445277pla.31.2022.02.04.12.24.16; Fri, 04 Feb 2022 12:24:29 -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=@lunn.ch header.s=20171124 header.b=yogmTzkF; 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 S242572AbiBCBBr (ORCPT + 99 others); Wed, 2 Feb 2022 20:01:47 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:39960 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348704AbiBCBBp (ORCPT ); Wed, 2 Feb 2022 20:01:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=p/zPqhK7rICYn+fsLs3IXm5cKsznKQy/YMAmPq7nniU=; b=yogmTzkFdURCUDAn/stzjxjV8u rCoHcf2lIgFQ+ntjcLO9MOuexhyI04CXHzXVGepe4V8FF9nycQ+3wzb4EIgiiO++ktgpxK7z1H2g0 yfNWiNW1i2Xz8rP7E/hqJDfcP4ALWws/uF9xoM702YoABiCXZLYI1j8kwZR5WW+Hhog8=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nFQV9-0042X4-O4; Thu, 03 Feb 2022 02:01:31 +0100 Date: Thu, 3 Feb 2022 02:01:31 +0100 From: Andrew Lunn To: Tim Harvey Cc: Martin Schiller , Hauke Mehrtens , martin.blumenstingl@googlemail.com, Florian Fainelli , hkallweit1@gmail.com, Russell King - ARM Linux , David Miller , kuba@kernel.org, netdev , open list Subject: Re: [PATCH net v3] net: phy: intel-xway: enable integrated led functions Message-ID: References: <20210421055047.22858-1-ms@dev.tdt.de> 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-kernel@vger.kernel.org > 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? Hi Tim I don't like the idea that the bootloader is controlling the hardware, not linux. There are well defined ways for telling Linux how RGMII delays should be set, and most PHY drivers do this. Any which don't should be extended to actually set the delay as configured. LEDs are trickier. There is a slow on going effort to allow PHY LEDs to be configured as standard Linux LEDs. That should result in a DT binding which can be used to configure LEDs from DT. You probably are going to have more and more issues if you think the bootloader is controlling the hardware, so you really should stop trying to do that. Andrew