Skip to contentSkip to conversation

ASoC: wm8804: fix error handling code

PATCH In review Vasiliy Kulikov 2 participants 6 messages Oct 10, 2010 – Oct 11, 2010

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ASoC: wm8804: fix error handling code

kzalloc() returns NULL on error, not ERR_PTR(). Also wm8804_modinit() didn't called i2c_del_driver() if spi_register_driver() failed.

---
Compile tested.

 sound/soc/codecs/wm8804.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)
sound/soc/codecs/wm8804.c +11 -4
index 642b07c..ff4dffd 100644
@@ -720,8 +720,8 @@ static int __devinit wm8804_spi_probe(struct spi_device *spi)
 	int ret;
 
 	wm8804 = kzalloc(sizeof *wm8804, GFP_KERNEL);
-	if (IS_ERR(wm8804))
-		return PTR_ERR(wm8804);
+	if (!wm8804)
+		return -ENOMEM;
 
 	wm8804->control_type = SND_SOC_SPI;
 	spi_set_drvdata(spi, wm8804);
@@ -758,8 +758,8 @@ static __devinit int wm8804_i2c_probe(struct i2c_client *i2c,
 	int ret;
 
 	wm8804 = kzalloc(sizeof *wm8804, GFP_KERNEL);
-	if (IS_ERR(wm8804))
-		return PTR_ERR(wm8804);
+	if (!wm8804)
+		return -ENOMEM;
 
 	wm8804->control_type = SND_SOC_I2C;
 	i2c_set_clientdata(i2c, wm8804);
@@ -804,6 +804,7 @@ static int __init wm8804_modinit(void)
 	if (ret) {
 		printk(KERN_ERR "Failed to register wm8804 I2C driver: %d\n",
 		       ret);
+		goto err;
 	}
 #endif
 #if defined(CONFIG_SPI_MASTER)
@@ -811,7 +812,13 @@ static int __init wm8804_modinit(void)
 	if (ret != 0) {
 		printk(KERN_ERR "Failed to register wm8804 SPI driver: %d\n",
 		       ret);
+		goto err_i2c;
 	}
+err_i2c:
+#endif
+#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
+	i2c_del_driver(&wm8804_i2c_driver);
+err:
 #endif
 	return ret;
 }
Signature · 1 line
1.7.0.4
#1 lore raw
Quoted 5 lines · Vasiliy Kulikov

kzalloc() returns NULL on error, not ERR_PTR(). Also wm8804_modinit() didn't called i2c_del_driver() if spi_register_driver() failed.

Please try to follow Documentation/SubmittingPatches - in particular, you should always split unrelated changes into separate patches. In this case your I2C and kzalloc() changes have nothing to do with each other and so should be in separate patches, and the kzalloc() changes were already applied from a patch by someone else. For the registration changes...

sound/soc/codecs/wm8804.c static int __init wm8804_modinit(void) · line 810

Quoted 8 lines
sound/soc/codecs/wm8804.c +1 -0
@@ -804,6 +804,7 @@ static int __init wm8804_modinit(void)
 	if (ret) {
 		printk(KERN_ERR "Failed to register wm8804 I2C driver: %d\n",
 		       ret);
+		goto err;
 	}
 #endif
 #if defined(CONFIG_SPI_MASTER)

...it's not clear to me that this change is an improvement - it'll make the driver more fragile in the face of errors, I don't see a benefit in refusing to register the variant for one bus if the other fails?

#2 lore raw

Hi Mark,

Quoted 11 lines · Mark Brown
Quoted 5 lines · Vasiliy Kulikov

kzalloc() returns NULL on error, not ERR_PTR(). Also wm8804_modinit() didn't called i2c_del_driver() if spi_register_driver() failed.

Please try to follow Documentation/SubmittingPatches - in particular, you should always split unrelated changes into separate patches. In this case your I2C and kzalloc() changes have nothing to do with each other and so should be in separate patches,

Agreed, thanks.

Quoted 2 lines

and the kzalloc() changes
were already applied from a patch by someone else.

Yes, it was sent by Dan just one day before my patch ;)

Quoted 15 lines

For the registration
changes...

sound/soc/codecs/wm8804.c static int __init wm8804_modinit(void) · line 810

Quoted 8 lines
sound/soc/codecs/wm8804.c +1 -0
@@ -804,6 +804,7 @@ static int __init wm8804_modinit(void)
 	if (ret) {
 		printk(KERN_ERR "Failed to register wm8804 I2C driver: %d\n",
 		       ret);
+		goto err;
 	}
 #endif
 #if defined(CONFIG_SPI_MASTER)

...it's not clear to me that this change is an improvement - it'll make the driver more fragile in the face of errors, I don't see a benefit in refusing to register the variant for one bus if the other fails?

I tried to implement your variant with depca driver in past, but it was rejected by David Miller:
http://lists.openwall.net/netdev/2010/07/12/9

Thanks,

Signature · 1 line
Vasiliy
#3 lore raw
Quoted 9 lines · Vasiliy Kulikov
Quoted 3 lines · Mark Brown

...it's not clear to me that this change is an improvement - it'll make the driver more fragile in the face of errors, I don't see a benefit in refusing to register the variant for one bus if the other fails?

I tried to implement your variant with depca driver in past, but it was rejected by David Miller:
http://lists.openwall.net/netdev/2010/07/12/9

I disagree with David here, and in any case if you're going to make a style change like this they really ought to be applied over all drivers rather than just a few individual ones.

#4 lore raw
Quoted 7 lines · Mark Brown
Quoted 5 lines · Vasiliy Kulikov
Quoted 3 lines · Mark Brown

...it's not clear to me that this change is an improvement - it'll make the driver more fragile in the face of errors, I don't see a benefit in refusing to register the variant for one bus if the other fails?

Quoted 7 lines
Quoted 3 lines

I tried to implement your variant with depca driver in past, but it was rejected by David Miller:
http://lists.openwall.net/netdev/2010/07/12/9

I disagree with David here, and in any case if you're going to make a style change like this they really ought to be applied over all drivers rather than just a few individual ones.

It is not greppable situation to simply change the behavior of all drivers. I was looking for memory leak bugs in drivers/net/ and fixed some of them. Manual looking through _all_ drivers takes much more time. In general I try to search for repeatable bugs with coccinelle, but it is rare case.

Thanks,

Signature · 1 line
Vasiliy
#5 lore raw
Quoted 5 lines · Vasiliy Kulikov

It is not greppable situation to simply change the behavior of all drivers. I was looking for memory leak bugs in drivers/net/ and fixed some of them. Manual looking through _all_ drivers takes much more time. In general I try to search for repeatable bugs with coccinelle, but it is rare case.

The method you're using to generate the patches is pretty much orthogonal to anything else, except of course in the case where you're also submitting the automation for checking (which is useful where possible).