All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@corigine.com>
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org>,
	Andrew Lunn <andrew@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Yang Li <yang.lee@linux.alibaba.com>,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [net-next PATCH v4 0/3] leds: trigger: netdev: add additional modes
Date: Mon, 19 Jun 2023 22:27:05 +0200	[thread overview]
Message-ID: <ZJC6GaZO7DgdMmIv@corigine.com> (raw)
In-Reply-To: <20230617115355.22868-1-ansuelsmth@gmail.com>

On Sat, Jun 17, 2023 at 01:53:52PM +0200, Christian Marangi wrote:
> This is a continue of [1]. It was decided to take a more gradual
> approach to implement LEDs support for switch and phy starting with
> basic support and then implementing the hw control part when we have all
> the prereq done.
> 
> This should be the final part for the netdev trigger.
> I added net-next tag and added netdev mailing list since I was informed
> that this should be merged with netdev branch.
> 
> We collect some info around and we found a good set of modes that are
> common in almost all the PHY and Switch.
> 
> These modes are:
> - Modes for dedicated link speed(10, 100, 1000 mbps). Additional mode
>   can be added later following this example.
> - Modes for half and full duplex.
> 
> The original idea was to add hw control only modes.
> While the concept makes sense in practice it would results in lots of 
> additional code and extra check to make sure we are setting correct modes.
> 
> With the suggestion from Andrew it was pointed out that using the ethtool
> APIs we can actually get the current link speed and duplex and this
> effectively removed the problem of having hw control only modes since we
> can fallback to software.
> 
> Since these modes are supported by software, we can skip providing an
> user for this in the LED driver to support hw control for these new modes
> (that will come right after this is merged) and prevent this to be another
> multi subsystem series.
> 
> For link speed and duplex we use ethtool APIs.
> 
> To call ethtool APIs, rtnl lock is needed but this can be skipped on
> handling netdev events as the lock is already held.
> 
> [1] https://lore.kernel.org/lkml/20230216013230.22978-1-ansuelsmth@gmail.com/

Hi Christian,

I am sorry if I am missing something obvious here,
but this series does not appear to apply on top of net-next.

Please consider rebasing and reposting.

As you probably know, you can include the reviewed-by tags
provided by Andrew for this posting, unless there are
substantial changes.

-- 
pw-bot: changes-requested


  parent reply	other threads:[~2023-06-19 20:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-17 11:53 [net-next PATCH v4 0/3] leds: trigger: netdev: add additional modes Christian Marangi
2023-06-17 11:53 ` [net-next PATCH v4 1/3] leds: trigger: netdev: add additional specific link speed mode Christian Marangi
2023-06-17 11:53 ` [net-next PATCH v4 2/3] leds: trigger: netdev: add additional specific link duplex mode Christian Marangi
2023-06-18 20:10   ` Andrew Lunn
2023-06-17 11:53 ` [net-next PATCH v4 3/3] leds: trigger: netdev: expose hw_control status via sysfs Christian Marangi
2023-06-18 20:15   ` Andrew Lunn
2023-06-19 10:40 ` [net-next PATCH v4 0/3] leds: trigger: netdev: add additional modes Lee Jones
2023-06-19 13:34   ` Andrew Lunn
2023-06-20 10:26     ` Lee Jones
2023-06-20 13:59       ` Andrew Lunn
2023-06-21 14:56         ` Lee Jones
2023-06-19 20:27 ` Simon Horman [this message]
2023-06-19 20:48   ` Christian Marangi

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=ZJC6GaZO7DgdMmIv@corigine.com \
    --to=simon.horman@corigine.com \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=yang.lee@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.