netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Vadym Kochan <vadym.kochan@plvision.eu>
Cc: netdev@vger.kernel.org, Russell King <linux@armlinux.org.uk>
Subject: Re: [DISCUSS] sfp: sfp controller concept
Date: Mon, 14 Sep 2020 04:28:40 +0200	[thread overview]
Message-ID: <20200914022840.GF3463198@lunn.ch> (raw)
In-Reply-To: <20200911181914.GB20711@plvision.eu>

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

      parent reply	other threads:[~2020-09-14  2:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 18:19 [DISCUSS] sfp: sfp controller concept Vadym Kochan
2020-09-12  9:12 ` Russell King - ARM Linux admin
2020-09-14  2:28 ` Andrew Lunn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200914022840.GF3463198@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=vadym.kochan@plvision.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).