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=-0.6 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 1F610C43381 for ; Tue, 19 Feb 2019 16:07:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D9CDE217D9 for ; Tue, 19 Feb 2019 16:07:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="upyq3dpC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729016AbfBSQHy (ORCPT ); Tue, 19 Feb 2019 11:07:54 -0500 Received: from mail-ot1-f49.google.com ([209.85.210.49]:40199 "EHLO mail-ot1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728312AbfBSQHy (ORCPT ); Tue, 19 Feb 2019 11:07:54 -0500 Received: by mail-ot1-f49.google.com with SMTP id v20so3069887otk.7 for ; Tue, 19 Feb 2019 08:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:in-reply-to:references:mime-version:content-transfer-encoding :autocrypt:subject:to:cc:from:message-id; bh=IrTYnmt+tMesflADyNRG8XO7t+vYyGqCjAIhQLrVyJE=; b=upyq3dpCtF6ZXz/O6Y+EJrIDvoNh7o8WWEBikgnCb9ZMhknAZD1dZKEMqUb4/aeF9U XlqIidWqfU2UzvNjdMni75XxhsEhll7tqlI3KudoAg+3PdRcxsxksS+f8f43XzNKeT9t 7x3oqroM23UV7mXbIq2ZP6mEDCfLAO7pbpRBVwpaaParoTw22GsuSun2lrmbFAJV2Nqe 29GITiJUL5S9I1Fsg6uZMRONgf5NO562WR4oBlmno16fMF3JaugFKA8X41pOrXFBWNYC Fbex3VlusEoeDt9IW27jHYqQ8wVze/Y2jvr69ORGUi1pO39RAljhXoYcrejZg2ZThCoM KccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:references:mime-version :content-transfer-encoding:autocrypt:subject:to:cc:from:message-id; bh=IrTYnmt+tMesflADyNRG8XO7t+vYyGqCjAIhQLrVyJE=; b=gMB0NMp4nNEgiaZCd3CYQwTlw8bavyzXsEZI4cxJbZV7eA1iL5z2P6PryOS9pieOLr zFLRZX+Lt5h4Lb1y7f6kqitBTSnpPffHwSM5pVTuBvL8AGEhrhIBaHCYL3czCuHRKOkA Pzyf6ONQnMI979FUq0jzdGEYfTr8kxVln+6P2ulZKtCoCa4SHWJRwNOtDFFnRWUe7iNz cWPA27X3q+mOogahLy8m8QuGzRVnGf9OcvJ50g3wDmGD6luIjFWU8XP+A32DxKdkKoDf a/P7VTshhXYUCiToeM7HmHCu27fYqs68SE1hlCX3nLXNzUkKSwkY4hUAy8UzEQP9Sr3O T/Wg== X-Gm-Message-State: AHQUAualeBOCUsrZqMu4LIWsy+gfo7oJn/A6CvOyteIQTCjnsiivFvh7 CjAZUpXrwKKfUommJML/KCrhgAJO X-Google-Smtp-Source: AHgI3IaUNIGNGJJQDnkZmJPtkcX0YIfiudXOmm+0iBYic6t/EGDfJ76zjb2QxVW4lykHGuhgculXqQ== X-Received: by 2002:aca:5143:: with SMTP id f64mr2954078oib.137.1550592473137; Tue, 19 Feb 2019 08:07:53 -0800 (PST) Received: from localhost (ip68-228-73-187.oc.oc.cox.net. [68.228.73.187]) by smtp.gmail.com with ESMTPSA id x4sm6885176otk.37.2019.02.19.08.07.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 08:07:52 -0800 (PST) Date: Tue, 19 Feb 2019 08:07:45 -0800 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Autocrypt: addr=f.fainelli@gmail.com; keydata= mQGiBEjPuBIRBACW9MxSJU9fvEOCTnRNqG/13rAGsj+vJqontvoDSNxRgmafP8d3nesnqPyRxGlk aOSDuu09rxuW+69Y2f1TzjFuGpBk4ysWOR85O2Nx8AJ6fYGCoeTbovrNlGT1M9obSFGQX3IzRnWo qlfudjTO5TKoqkbOgpYqIo5n1QbEjCCwCwCg3DOH/4ug2AUUlcIT9/l3pGvoRJ0EAICDzi3l7pmC 5IWn2n1mvP5247urtHFs/uusE827DDj3K8Upn2vYiOFMBhGsxAk6YKV6IP0dZdWX6fqkJJlu9cSD vWtO1hXeHIfQIE/xcqvlRH783KrihLcsmnBqOiS6rJDO2x1eAgC8meAXSAgsrBhcgGl2Rl5gh/jk eA5ykwbxA/9u1eEuL70Qzt5APJmqVXR+kWvrqdBVPoUNy/tQ8mYcnzJJ63ng3tHhnwHXZOu8hL4n qwlYHRa9eeglXYhBqja4ZvIvCEqSmEukfivk+DlIgVoOAJbhqIWgvr3SIEuR6ayY3f5j0f2ejUMY lYYnKdiHXFlF9uXm1ELrb0YX4GMHz7QnRmxvcmlhbiBGYWluZWxsaSA8Zi5mYWluZWxsaUBnbWFp bC5jb20+iGYEExECACYCGyMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCVF/S8QUJHlwd3wAKCRBh V5kVtWN2DvCVAJ4u4/bPF4P3jxb4qEY8I2gS6hG0gACffNWlqJ2T4wSSn+3o7CCZNd7SLSC5BA0E SM+4EhAQAL/o09boR9D3Vk1Tt7+gpYr3WQ6hgYVON905q2ndEoA2J0dQxJNRw3snabHDDzQBAcqO vdi7YidfBVdKi0wxHhSuRBfuOppupdXkb7zxuPQuSveCLqqZWRQ+Cc2QgF7SBqgznbe6Ngout5qX Y5Dcagk9LqFNGhJQzUGHAsIshap1f0B1PoUyUNeEInV98D8Xd/edM3mhO9nRpUXRK9Bvt4iEZUXG uVtZLT52nK6Wv2EZ1TiTOiqZlf1P+vxYLBx9eKmabPdm3yjalhY8yr1S1vL0gSA/C6W1o/Towdie F1rWN/MYHlkpyj9cRpc281gAO0AP3V1G00YzBEdYyi0gaJbCEQnq8Vz1vDXFxHzyhgGz7umBsVKm YwZgA8DrrB0MoaP35wuGR3RJcaG30AnJpEDkBYHznI2apxdcuTPOHZyEilIRrBGzDwGtAhldzlBo BwE3Z3MY31TOpACu1ZpNOMysZ6xiE35pWkwc0KYm4hJA5GFfmWSN6DniimW3pmdDIiw4Ifcx8b3m FrROBbDIW13E51j9RjbO/nAaK9ndZ5LRO1B/8Fwat7bLzmsCiEXOJY7NNpIEpkoNoEUfCcZwmLrU +eOTPzaF6drw6ayewEi5yzPg3TAT6FV3oBsNg3xlwU0gPK3v6gYPX5w9+ovPZ1/qqNfOrbsEFRui SVsZQ5s3AAMFD/9XjlnnVDh9GX/r/6hjmr4U9tEsM+VQXaVXqZuHKaSmojOLUCP/YVQo7IiYaNss CS4FCPe4yrL4FJJfJAsbeyDykMN7wAnBcOkbZ9BPJPNCbqU6dowLOiy8AuTYQ48mvIyQ4Ijnb6GT rtxIUDQeOBNuQC/gyyx3nbL/lVlHbxr4tb6YkhkO6shjXhQh7nQb33FjGO4PWU11Nr9i/qoV8QCo 12MQEo244RRA6VMud06y/E449rWZFSTwGqb0FS0seTcYNvxt8PB2izX+HZA8SL54j479ubxhfuoT u5nXdtFYFj5Lj5x34LKPx7MpgAmj0H7SDhpFWF2FzcC1bjiW9mjWHaKaX23Awt97AqQZXegbfkJw X2Y53ufq8Np3e1542lh3/mpiGSilCsaTahEGrHK+lIusl6mzJoil+u3k01ofvJMK0ZdzGUZ/aPMZ 16LofjFA+MNxWrZFrkYmiGdv+LG45zSlZyIvzSiG2lKykuVag+IijCIom78P9jRtB1q1Q5lwZp2T LAJlz92DmFwBg1hyFzwDADjZ2nrDxKUiybXIgZp9aU2d++ptEGCVJOfEW4qpWCCLPbOT7XBr+g/4 H3qWbs3j/cDDq7LuVYIe+wchy/iXEJaQVeTCy5arMQorqTFWlEOgRA8OP47L9knl9i4xuR0euV6D ChDrguup2aJVU4hPBBgRAgAPAhsMBQJUX9LxBQkeXB3fAAoJEGFXmRW1Y3YOj4UAn3nrFLPZekMe qX5aD/aq/dsbXSfyAKC45Go0YyxVHGuUuzv+GKZ6nsysJw== Subject: Re: Handling an Extra Signal at PHY Reset To: Paul Kocialkowski , Andrew Lunn , Heiner Kallweit CC: netdev@vger.kernel.org, Thomas Petazzoni , =?ISO-8859-1?Q?Myl=E8ne_Josserand?= From: Florian Fainelli Message-ID: <06B5A7DA-55DC-4F58-8078-D44A5230BBEA@gmail.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On February 19, 2019 1:14:20 AM PST, Paul Kocialkowski wrote: >Hi, > >We are dealing with an Ethernet PHY (Marvell 88E1512) that comes with a >CONFIG pin that must be connected to one of the other pins of the PHY >to configure the LSB of the PHY address as well as I/O voltages (see >section 2=2E18=2E1 Hardware Configuration of the datasheet)=2E It must be >connected "soon after reset" for the PHY to be correctly configured=2E Even voltage? What guarantees do you have that you are not reducing the li= fetime of your pads if e=2Eg=2E: you are configured for 3=2E3V while the ot= her end is 1=2E8/2=2E5V? Is there some kind of embedded voltage comparator = that can be used to help making the right decision? > >We have a switch for connecting the CONFIG pin to the other pin (LED0), >which needs to be controlled by Linux=2E The CONFIG pin seems to be used >for a PTP clock the rest of the time=2E > >So we are wondering how to properly represent this case, especially on >the device-tree side=2E > >The trick here is that this step is necessary before the PHY can be >discovered on the MDIO bus (and thus the PHY driver selected) so we >can't rely on the PHY driver to do this=2E Basically, it looks like we >need to handle this like the reset pin and describe it at the MDIO bus >level=2E > >Here are some ideas for potential solutions: >- Allowing more than a single GPIO to be passed to the MDIO bus' reset- >gpios via device-tree and toggling all the passed GPIOs at once; That would be a mis-representstion of the HW though, since the reset line = is tied to the PHY package=2E Making use of the current implementation deta= ils to put a second reset line does not sound great=2E > >- Adding a new optional GPIO for the MDIO bus dedicated to controlling=20 >switches for such config switching, perhaps called "config-gpios" >(quite a narrow solution); Indeed, and still has the same design flaw as 1) outline above=2E > >- Adding a broader power sequence description to the MDIO bus (a bit >like it's done with the mmc pwrseq descriptions) which would allow >specifying the toggle order/delays of various GPIOs (would probably be >the most extensive solution); That one looks the most compelling and future proof although I do wonder h= ow many people would make use of that=2E > >- Adding the extra GPIO control to the MAC description and toggling it >through bus->reset (probably the less invasive solution for the core >but not very satisfying from the description perspective, since this is >definitely not MAC-specific)=2E > >What do you think about how we could solve this issue? >Do you see other options that I missed here? You could explore having the MDIO bus layer scan its children nodes (PHY n= odes) and handle properties in there before registering devices, so for ins= urance your PHY DT nodes can have an arbitrary number of reset lines, power= sequencing properties etc=2E and the MDIO bus layer knowing it's internal = implementation does make sure that it makes use of these properties in orde= r to make PHY devices functional=2E Does that make sense? One possible caveat is that the CONFIG pin also dict= ates the address on the bus, so what do we do with the PHY's "reg" property= , is it it's actual address or is it the desired one that we should configu= re through reset? --=20 Florian