netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Jiri Pirko <jiri@resnulli.us>
Cc: David Ahern <dsahern@gmail.com>, Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, davem@davemloft.net,
	jacob.e.keller@intel.com, roopa@nvidia.com, mlxsw@nvidia.com,
	vadimp@nvidia.com
Subject: Re: [patch net-next RFC 00/10] introduce line card support for modular switch
Date: Tue, 26 Jan 2021 14:56:08 +0100	[thread overview]
Message-ID: <YBAfeESYudCENZ2e@lunn.ch> (raw)
In-Reply-To: <20210126113326.GO3565223@nanopsycho.orion>

On Tue, Jan 26, 2021 at 12:33:26PM +0100, Jiri Pirko wrote:
> Fri, Jan 22, 2021 at 03:13:12PM CET, andrew@lunn.ch wrote:
> >> I don't see any way. The userspace is the one who can get the info, from
> >> the i2c driver. The mlxsw driver has no means to get that info itself.
> >
> >Hi Jiri
> >
> >Please can you tell us more about this i2c driver. Do you have any
> >architecture pictures?
> 
> Quoting Vadim Pasternak:
> "
> Not upstreamed yet.
> It will be mlxreg-lc driver for line card in drivers/platfrom/mellanox and
> additional mlxreg-pm for line card powering on/off, setting enable/disable
> and handling power off upon thermal shutdown event.
> "
> 
> 
> >
> >It is not unknown for one driver to embed another driver inside it. So
> >the i2c driver could be inside the mlxsw. It is also possible to link
> >drivers together, the mlxsw could go find the i2c driver and make use
> >of its services.
> 
> Okay. Do you have examples? How could the kernel figure out the relation
> of the instances?

Hi Jiri

One driver, embedded into another? You actually submitted an example:

commit 6882b0aee180f2797b8803bdf699aa45c2e5f2d6
Author: Vadim Pasternak <vadimp@mellanox.com>
Date:   Wed Nov 16 15:20:44 2016 +0100

    mlxsw: Introduce support for I2C bus
    
    Add I2C bus implementation for Mellanox Technologies Switch ASICs.
    This includes command interface implementation using input / out mailboxes,
    whose location is retrieved from the firmware during probe time.
    
    Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
    Reviewed-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

There are Linux standard APIs for controlling the power to devices,
the regulator API. So i assume mlxreg-pm will make use of that. There
are also standard APIs for thermal management, which again, mlxreg-pm
should be using. The regulator API allows you to find regulators by
name. So just define a sensible naming convention, and the switch
driver can lookup the regulator, and turn it on/off as needed.

I'm guessing there are no standard Linux API which mlxreg-lc fits. I'm
also not sure it offers anything useful standalone. So i would
actually embed it inside the switchdev driver, and have internal APIs
to get information about the line card.

But i'm missing big picture architecture knowledge here, there could
be reasons why these suggestions don't work.

   Andrew

  reply	other threads:[~2021-01-26 13:58 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 12:12 [patch net-next RFC 00/10] introduce line card support for modular switch Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 01/10] devlink: add support to create line card and expose to user Jiri Pirko
2021-01-15 15:47   ` Ido Schimmel
2021-01-13 12:12 ` [patch net-next RFC 02/10] devlink: implement line card provisioning Jiri Pirko
2021-01-15 16:03   ` Ido Schimmel
2021-01-15 16:51     ` Jiri Pirko
2021-01-15 18:09       ` Ido Schimmel
2021-01-18 12:50         ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 03/10] devlink: implement line card active state Jiri Pirko
2021-01-15 16:06   ` Ido Schimmel
2021-01-15 16:52     ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 04/10] devlink: append split port number to the port name Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 05/10] devlink: add port to line card relationship set Jiri Pirko
2021-01-15 16:10   ` Ido Schimmel
2021-01-15 16:53     ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 06/10] netdevsim: introduce line card support Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 07/10] netdevsim: allow port objects to be linked with line cards Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 08/10] netdevsim: create devlink line card object and implement provisioning Jiri Pirko
2021-01-15 16:30   ` Ido Schimmel
2021-01-15 16:54     ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 09/10] netdevsim: implement line card activation Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 10/10] selftests: add netdevsim devlink lc test Jiri Pirko
2021-01-13 13:39 ` [patch iproute2/net-next RFC] devlink: add support for linecard show and provision Jiri Pirko
2021-01-14  2:07 ` [patch net-next RFC 00/10] introduce line card support for modular switch Andrew Lunn
2021-01-14  7:39   ` Jiri Pirko
2021-01-14 22:56     ` Jacob Keller
2021-01-15 14:19       ` Jiri Pirko
2021-01-19 11:56   ` Jiri Pirko
2021-01-19 14:51     ` Andrew Lunn
2021-01-20  8:36       ` Jiri Pirko
2021-01-20 13:56         ` Andrew Lunn
2021-01-20 23:41           ` Jakub Kicinski
2021-01-21  0:01             ` Andrew Lunn
2021-01-21  0:16               ` Jakub Kicinski
2021-01-21 15:34               ` Jiri Pirko
2021-01-21 15:32             ` Jiri Pirko
2021-01-21 16:38               ` David Ahern
2021-01-22  7:28                 ` Jiri Pirko
2021-01-22 14:13                   ` Andrew Lunn
2021-01-26 11:33                     ` Jiri Pirko
2021-01-26 13:56                       ` Andrew Lunn [this message]
2021-01-27  7:57                         ` Jiri Pirko
2021-01-27 14:14                           ` Andrew Lunn
2021-01-27 14:57                             ` David Ahern
2021-01-28  8:14                             ` Jiri Pirko
2021-01-28 14:17                               ` Andrew Lunn
2021-01-29  7:20                                 ` Jiri Pirko
     [not found]                                   ` <YBQujIdnFtEhWqTF@lunn.ch>
2021-01-29 16:45                                     ` Vadim Pasternak
2021-01-29 17:31                                       ` Andrew Lunn
2021-01-30 14:19                                         ` Jiri Pirko
     [not found]                                           ` <251d1e12-1d61-0922-31f8-a8313f18f194@gmail.com>
2021-02-01  8:16                                             ` Jiri Pirko
2021-02-01 13:41                                               ` Andrew Lunn
2021-02-03 14:57                                                 ` Jiri Pirko
2021-02-03 16:26                                                   ` Andrew Lunn
2021-02-01  1:43                                       ` Andrew Lunn
2021-01-22  8:05                 ` Jiri Pirko
2021-01-19 16:23     ` David Ahern
2021-01-20  8:37       ` Jiri Pirko
2021-01-14  2:27 ` Jakub Kicinski
2021-01-14  7:48   ` Jiri Pirko
2021-01-14 23:30     ` Jakub Kicinski
2021-01-15 14:39       ` Jiri Pirko
2021-01-15 19:26         ` Jakub Kicinski
2021-01-18 13:00           ` Jiri Pirko
2021-01-18 17:59             ` Jakub Kicinski
2021-01-19 11:51               ` Jiri Pirko
2021-01-18 22:55             ` David Ahern
2021-01-22  8:01               ` Jiri Pirko
2021-01-14 22:58   ` Jacob Keller
2021-01-14 23:20     ` Jakub Kicinski
2021-01-15 14:40       ` Jiri Pirko
2021-01-15 15:43 ` Ido Schimmel
2021-01-15 16:55   ` Jiri Pirko
2021-01-15 18:01     ` Ido Schimmel
2021-01-18 13:03       ` Jiri Pirko
2021-01-18 18:01 ` Edwin Peer
2021-01-18 22:57   ` David Ahern
2021-01-18 23:40     ` Edwin Peer
2021-01-19  2:39       ` David Ahern
2021-01-19  5:06         ` Edwin Peer

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=YBAfeESYudCENZ2e@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@nvidia.com \
    --cc=vadimp@nvidia.com \
    /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).