From: Simon Horman <simon.horman@corigine•com>
To: Andrew Lunn <andrew@lunn•ch>
Cc: netdev <netdev@vger•kernel.org>,
Heiner Kallweit <hkallweit1@gmail•com>,
Russell King <rmk+kernel@armlinux•org.uk>,
Christian Marangi <ansuelsmth@gmail•com>
Subject: Re: [PATCH net-next v1 1/3] led: trig: netdev: Fix requesting offload device
Date: Wed, 21 Jun 2023 17:34:30 +0200 [thread overview]
Message-ID: <ZJMYhiZpip8ly8+0@corigine.com> (raw)
In-Reply-To: <864bfa14-ab8f-4953-873c-a9ad4721be22@lunn.ch>
On Wed, Jun 21, 2023 at 05:19:01PM +0200, Andrew Lunn wrote:
> > > set_device_name(trigger_data, name, strlen(name));
> > > trigger_data->hw_control = true;
> > > - trigger_data->mode = mode;
> > > +
> > > + rc = led_cdev->hw_control_get(led_cdev, &mode);
> > > + if (!rc)
> > > + trigger_data->mode = mode;
> >
> > Is the case where trigger_data->hw_control is set to true
> > but trigger_data->mode is not set ok?
> >
> > I understand that is the whole point is not to return an error in this case.
> > But I'm concerned about the value of trigger_data->mode.
>
> Yes, its something Christian and I talked about off-list.
> trigger_data->mode is 0 by default due to the kzalloc(). 0 is a valid
> value, it means don't blink for any reason. So in effect the LED
> should be off. And any LED driver which the ledtrig-netdev.c supports
> must support software control of the LED, so does support setting the
> LED off.
>
> In the normal case hw_control_get() returns indicating the current
> blink mode, and the trigger sets its initial state to that. If
> however, it returns an error, it probably means its current state
> cannot be represented by the netdev trigger. PHY vendors do all sort
> of odd things, and we don't want to support all the craziness. So
> setting the LED off and leaving the user to configure the LED how they
> want seems like a reasonable thing to do.
>
> And i tested this because my initial implementation of the Marvell
> driver was FUBAR and it returned an error here.
Thanks Andrew,
sounds good to me.
Especially,
"we don't want to support all the craziness"
Reviewed-by: Simon Horman <simon.horman@corigine•com>
next prev parent reply other threads:[~2023-06-21 15:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-19 21:57 [PATCH net-next v1 0/3] Support offload LED blinking to PHY Andrew Lunn
2023-06-19 21:57 ` [PATCH net-next v1 1/3] led: trig: netdev: Fix requesting offload device Andrew Lunn
2023-06-21 13:37 ` Simon Horman
2023-06-21 15:19 ` Andrew Lunn
2023-06-21 15:34 ` Simon Horman [this message]
2023-06-19 21:57 ` [PATCH net-next v1 2/3] net: phy: phy_device: Call into the PHY driver to set LED offload Andrew Lunn
2023-06-21 13:39 ` Simon Horman
2023-06-21 22:24 ` Jakub Kicinski
2023-06-21 22:28 ` Jakub Kicinski
2023-06-19 21:57 ` [PATCH net-next v1 3/3] net: phy: marvell: Add support for offloading LED blinking Andrew Lunn
2023-06-21 13:45 ` Simon Horman
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=ZJMYhiZpip8ly8+0@corigine.com \
--to=simon.horman@corigine$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=ansuelsmth@gmail$(echo .)com \
--cc=hkallweit1@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rmk+kernel@armlinux$(echo .)org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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