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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 911C1C433E2 for ; Mon, 14 Sep 2020 02:28:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 63D832168B for ; Mon, 14 Sep 2020 02:28:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726024AbgINC2r (ORCPT ); Sun, 13 Sep 2020 22:28:47 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:60574 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725983AbgINC2n (ORCPT ); Sun, 13 Sep 2020 22:28:43 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kHeES-00EXZp-Nm; Mon, 14 Sep 2020 04:28:40 +0200 Date: Mon, 14 Sep 2020 04:28:40 +0200 From: Andrew Lunn To: Vadym Kochan Cc: netdev@vger.kernel.org, Russell King Subject: Re: [DISCUSS] sfp: sfp controller concept Message-ID: <20200914022840.GF3463198@lunn.ch> References: <20200911181914.GB20711@plvision.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200911181914.GB20711@plvision.eu> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Sep 11, 2020 at 09:19:14PM +0300, Vadym Kochan wrote: > Hi, > > I'd like to discuss a concept of introduction additional entity into SFP > subsystem called SFP controller. But lets start with the issue. > > Issue > ===== > > There are boards with SFP ports whose GPIO pins are not connected directly to > the SoC but to the I2C CPLD device which has ability to read/write statuses of > each SFP via I2C read/write commands. > > Of course there is already a solution - implement GPIO chip and convert GPIO > numbers & states into internal representation (I2C registers). But it requires > additional GPIO-related handling like: > > 1) Describe GPIO pins and IN/OUT mapping in DTS > > 2) Consider this mapping also in CPLD driver > > 3) IRQ - for me this is not clear how to simulate > sending IRQ via GPIO chip. Hi Vadym I2C GPIO expanders do work O.K. for this use case. See for example vf610-zii-dev-rev-c.dts. It has a semtech,sx1503q expander. And the two SFF on that board are connected to it. The sx1503q can generate an interrupt when one of its inputs changes state. But for the SFP core, that is optional, it can also poll the GPIOs if interrupts are not supported. Andrew