All of lore.kernel.org
 help / color / mirror / Atom feed
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



WARNING: multiple messages have this Message-ID (diff)
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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-03-17 15:13 UTC|newest]

Thread overview: 72+ 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 ` 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   ` 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  2:31   ` Christian Marangi
2023-03-17 11:24   ` Michal Kubiak
2023-03-17 11:24     ` Michal Kubiak
2023-03-17 13:34     ` Andrew Lunn
2023-03-17 13:34       ` Andrew Lunn
2023-03-17 14:01     ` Christian Marangi
2023-03-17 14:01       ` Christian Marangi
2023-03-17 18:05       ` Michal Kubiak
2023-03-17 18:05         ` Michal Kubiak
2023-03-18 18:54         ` Christian Marangi
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  2:31   ` Christian Marangi
2023-03-17 11:54   ` Michal Kubiak
2023-03-17 11:54     ` Michal Kubiak
2023-03-17 14:03     ` Christian Marangi
2023-03-17 14:03       ` Christian Marangi
2023-03-18 19:14     ` 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  2:31   ` Christian Marangi
2023-03-17  7:45   ` Marek Behún
2023-03-17  7:45     ` Marek Behún
2023-03-17 13:55     ` Andrew Lunn
2023-03-17 13:55       ` Andrew Lunn
2023-03-17 14:29       ` Marek Behún
2023-03-17 14:29         ` Marek Behún
2023-03-17 15:31         ` Andrew Lunn
2023-03-17 15:31           ` Andrew Lunn
2023-03-17  9:15   ` kernel test robot
2023-03-17 12:10   ` kernel test robot
2023-03-17 13:38   ` Michal Kubiak
2023-03-17 13:38     ` Michal Kubiak
2023-03-17 14:03     ` Andrew Lunn
2023-03-17 14:03       ` Andrew Lunn
2023-03-17 15:12       ` Michal Kubiak [this message]
2023-03-17 15:12         ` Michal Kubiak
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  2:31   ` Christian Marangi
2023-03-17 14:01   ` Michal Kubiak
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   ` 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   ` 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   ` 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   ` 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  2:31   ` Christian Marangi
2023-03-17  8:14   ` Marek Behún
2023-03-17  8:14     ` Marek Behún
2023-03-17 14:09     ` Christian Marangi
2023-03-17 14:09       ` Christian Marangi
2023-03-17 14:22     ` Andrew Lunn
2023-03-17 14:22       ` Andrew Lunn
2023-03-17 16:02     ` 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   ` 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   ` 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   ` 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
2023-03-17  2:31   ` 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 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.