From: Michal Kubiak <michal.kubiak@intel.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Christian Marangi <ansuelsmth@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Gregory Clement <gregory.clement@bootlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Andy Gross <agross@kernel.org>,
"Bjorn Andersson" <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
John Crispin <john@phrozen.org>, <netdev@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-arm-msm@vger.kernel.org>, "Lee Jones" <lee@kernel.org>,
<linux-leds@vger.kernel.org>
Subject: Re: [net-next PATCH v4 04/14] net: phy: Add a binding for PHY LEDs
Date: Fri, 17 Mar 2023 16:12:07 +0100 [thread overview]
Message-ID: <ZBSDRw5MF431wxz1@localhost.localdomain> (raw)
In-Reply-To: <f292505c-ab74-47f4-be7f-18dd4a7e2903@lunn.ch>
On Fri, Mar 17, 2023 at 03:03:32PM +0100, Andrew Lunn wrote:
> > Hi Andrew,
> >
> > Personally, I see no good reason to provide a dummy implementation
> > of "phy_led_set_brightness", especially if you implement it in the next
> > patch. You only use that function only the function pointer in
> > "led_classdev". I think you can just skip it in this patch.
>
> Hi Michal
>
> The basic code for this patch has been sitting in my tree for a long
> time. It used to be, if you did not have a set_brightness method in
> cdev, the registration failed. That made it hard to test this patch on
> its own during development work, did i have the link list correct, can
> i unload the PHY driver without it exploding etc. I need to check if
> it is still mandatory.
>
Thank you for the explanation. I was not aware of failing registration
in case of undefined "cdev->brightness_set_blocking". I think it is
a good reason of defining the dummy function. (The only alternative
would be to squash two commits, but I think it is easier to review
smaller chunks of code).
> > > +static int of_phy_led(struct phy_device *phydev,
> > > + struct device_node *led)
> > > +{
> > > + struct device *dev = &phydev->mdio.dev;
> > > + struct led_init_data init_data = {};
> > > + struct led_classdev *cdev;
> > > + struct phy_led *phyled;
> > > + int err;
> > > +
> > > + phyled = devm_kzalloc(dev, sizeof(*phyled), GFP_KERNEL);
> > > + if (!phyled)
> > > + return -ENOMEM;
> > > +
> > > + cdev = &phyled->led_cdev;
> > > +
> > > + err = of_property_read_u32(led, "reg", &phyled->index);
> > > + if (err)
> > > + return err;
> >
> > Memory leak. 'phyled' is not freed in case of error.
>
> devm_ API, so it gets freed when the probe fails.
>
> > > +
> > > + cdev->brightness_set_blocking = phy_led_set_brightness;
> >
> > Please move this initialization to the patch where you are actually
> > implementing this callback.
> >
> > > + cdev->max_brightness = 1;
> > > + init_data.devicename = dev_name(&phydev->mdio.dev);
> > > + init_data.fwnode = of_fwnode_handle(led);
> > > +
> > > + err = devm_led_classdev_register_ext(dev, cdev, &init_data);
> > > + if (err)
> > > + return err;
> >
> > Another memory leak.
>
> Ah, maybe you don't know about devm_ ? devm_ allocations and actions
> register an action to be taken when the device is removed, either
> because the probe failed, or when the device is unregistered. For
> memory allocation, the memory is freed automagically. For actions like
> registering an LED, requesting an interrupt etc, an unregister/release
> is performed. This makes cleanup less buggy since the core does it.
>
> Andrew
Yeah, it is my fault, I apologize for that.
I didn't consider neither the probe() context, nor the lifetime of the
list. You are right - I had no experience with using this devm_ API,
so I looked at it as a standard memory allocation.
Thank you for your patience and this piece of knowledge.
Thanks,
Michal
next prev parent reply other threads:[~2023-03-17 15:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 2:31 [net-next PATCH v4 00/14] net: Add basic LED support for switch/phy Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 01/14] net: dsa: qca8k: move qca8k_port_to_phy() to header Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 02/14] net: dsa: qca8k: add LEDs basic support Christian Marangi
2023-03-17 11:24 ` Michal Kubiak
2023-03-17 13:34 ` Andrew Lunn
2023-03-17 14:01 ` Christian Marangi
2023-03-17 18:05 ` Michal Kubiak
2023-03-18 18:54 ` Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 03/14] net: dsa: qca8k: add LEDs blink_set() support Christian Marangi
2023-03-17 11:54 ` Michal Kubiak
2023-03-17 14:03 ` Christian Marangi
2023-03-18 19:14 ` Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 04/14] net: phy: Add a binding for PHY LEDs Christian Marangi
2023-03-17 7:45 ` Marek Behún
2023-03-17 13:55 ` Andrew Lunn
2023-03-17 14:29 ` Marek Behún
2023-03-17 15:31 ` Andrew Lunn
2023-03-17 13:38 ` Michal Kubiak
2023-03-17 14:03 ` Andrew Lunn
2023-03-17 15:12 ` Michal Kubiak [this message]
2023-03-17 2:31 ` [net-next PATCH v4 05/14] net: phy: phy_device: Call into the PHY driver to set LED brightness Christian Marangi
2023-03-17 14:01 ` Michal Kubiak
2023-03-17 2:31 ` [net-next PATCH v4 06/14] net: phy: marvell: Add software control of the LEDs Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 07/14] net: phy: phy_device: Call into the PHY driver to set LED blinking Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 08/14] net: phy: marvell: Implement led_blink_set() Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 09/14] dt-bindings: net: ethernet-controller: Document support for LEDs node Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 10/14] dt-bindings: net: dsa: qca8k: add LEDs definition example Christian Marangi
2023-03-17 8:14 ` Marek Behún
2023-03-17 14:09 ` Christian Marangi
2023-03-17 14:22 ` Andrew Lunn
2023-03-17 16:02 ` Andrew Lunn
2023-03-17 2:31 ` [net-next PATCH v4 11/14] arm: qcom: dt: Drop unevaluated properties in switch nodes for rb3011 Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 12/14] arm: qcom: dt: Add Switch LED for each port " Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 13/14] dt-bindings: net: phy: Document support for LEDs node Christian Marangi
2023-03-17 2:31 ` [net-next PATCH v4 14/14] arm: mvebu: dt: Add PHY LED support for 370-rd WAN port 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=ZBSDRw5MF431wxz1@localhost.localdomain \
--to=michal.kubiak@intel.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=gregory.clement@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=john@phrozen.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.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).