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=-1.0 required=3.0 tests=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 E43A3C43381 for ; Tue, 19 Feb 2019 09:14:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BC9E421848 for ; Tue, 19 Feb 2019 09:14:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727990AbfBSJO0 (ORCPT ); Tue, 19 Feb 2019 04:14:26 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:50657 "EHLO relay2-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727907AbfBSJOZ (ORCPT ); Tue, 19 Feb 2019 04:14:25 -0500 X-Originating-IP: 90.88.30.68 Received: from aptenodytes (aaubervilliers-681-1-89-68.w90-88.abo.wanadoo.fr [90.88.30.68]) (Authenticated sender: paul.kocialkowski@bootlin.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id C86B340013; Tue, 19 Feb 2019 09:14:21 +0000 (UTC) Message-ID: Subject: Handling an Extra Signal at PHY Reset From: Paul Kocialkowski To: Andrew Lunn , Florian Fainelli , Heiner Kallweit Cc: netdev@vger.kernel.org, Thomas Petazzoni , =?ISO-8859-1?Q?Myl=E8ne?= Josserand Date: Tue, 19 Feb 2019 10:14:20 +0100 Organization: Bootlin Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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.18.1 Hardware Configuration of the datasheet). It must be connected "soon after reset" for the PHY to be correctly configured. We have a switch for connecting the CONFIG pin to the other pin (LED0), which needs to be controlled by Linux. The CONFIG pin seems to be used for a PTP clock the rest of the time. So we are wondering how to properly represent this case, especially on the device-tree side. 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. Basically, it looks like we need to handle this like the reset pin and describe it at the MDIO bus level. 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; - Adding a new optional GPIO for the MDIO bus dedicated to controlling switches for such config switching, perhaps called "config-gpios" (quite a narrow solution); - 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); - 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). What do you think about how we could solve this issue? Do you see other options that I missed here? Cheers and thanks in advance, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com