lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120731115733.GB30417@gmail.com>
Date:	Tue, 31 Jul 2012 13:57:33 +0200
From:	Fabio Baltieri <fabio.baltieri@...il.com>
To:	Marc Kleine-Budde <mkl@...gutronix.de>
Cc:	linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	Wolfgang Grandegger <wg@...ndegger.com>
Subject: Re: [PATCH can-next v3 1/2] can: add tx/rx LED trigger support

On Tue, Jul 31, 2012 at 09:10:00AM +0200, Marc Kleine-Budde wrote:
> >>> +/*
> >>> + * Register CAN LED triggers for a CAN device
> >>> + *
> >>> + * This is normally called from a driver's probe function
> >>> + */
> >>> +void can_led_init(struct net_device *netdev)
> >>> +{
> >>> +	struct can_priv *priv = netdev_priv(netdev);
> >>> +
> >>> +	priv->tx_led_trig_name = kasprintf(GFP_KERNEL, "%s-tx", netdev->name);
> >>> +	if (!priv->tx_led_trig_name)
> >>> +		goto tx_led_failed;
> >>> +
> >>> +	priv->rx_led_trig_name = kasprintf(GFP_KERNEL, "%s-rx", netdev->name);
> >>> +	if (!priv->rx_led_trig_name)
> >>> +		goto rx_led_failed;
> >>> +
> >>> +	led_trigger_register_simple(priv->tx_led_trig_name,
> >>> +				    &priv->tx_led_trig);
> >>> +	led_trigger_register_simple(priv->rx_led_trig_name,
> >>> +				    &priv->rx_led_trig);
> >>> +
> >>> +	return;
> >>> +
> >>> +rx_led_failed:
> >>> +	kfree(priv->tx_led_trig_name);
> >>> +	priv->tx_led_trig_name = NULL;
> >>> +tx_led_failed:
> >>> +	return;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(can_led_init);
> >>
> >> Can you provide a devm implementation for can_led?
> > 
> > Sounds reasonable, you mean like a devm_kasprintf implementation to
> > remove kfree and unwinding code?
> 
> IMHO it would be sufficient if you implement the devm cleanup functions
> here.

Uh - can you be more specific?  I mean, are you suggesting to just
convert the code to something like:

unsigned int len;
char *p;

len = snprintf(NULL, 0, "%s-tx", netdev->name);
p = devm_kzalloc(&netdev->dev, len + 1, GFP_KERNEL);
if (!p)
return -ENOMEM;
sprintf(p, len + 1, "%s-tx", netdev->name);

or to implement something with devres_alloc() and a specific
release function?

Fabio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ