[PATCH] staging: most: hdm-usb: convert pr_warn() to dev_warn()

[PATCH] staging: most: hdm-usb: convert pr_warn() to dev_warn()

[Eva Rachel Retuya]

Replace pr_warn() call with its respective dev_warn() counterpart.
Semantic patch used to detect and apply the transformation:

@a@
identifier f, dev;
expression fmt, E;
@@

f(...) {
	...
	struct device *dev = E;
	<+... when != dev == NULL
- pr_warn(
+ dev_warn(dev,
		fmt, ...);
	...+>
}

Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
---
 drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c b/drivers/staging/most/hdm-usb/hdm_usb.c
index 5b27e96..6fc20b1 100644
--- a/drivers/staging/most/hdm-usb/hdm_usb.c
+++ b/drivers/staging/most/hdm-usb/hdm_usb.c
@@ -1315,8 +1315,8 @@ hdm_probe(struct usb_interface *interface, const struct usb_device_id *id)
 				  ep_desc->bEndpointAddress * 16,
 				  1);
 		if (err < 0)
-			pr_warn("DCI Sync for EP %02x failed",
-				ep_desc->bEndpointAddress);
+			dev_warn(dev, "DCI Sync for EP %02x failed",
+				 ep_desc->bEndpointAddress);
 	}
 	dev_notice(dev, "claimed gadget: Vendor=%4.4x ProdID=%4.4x Bus=%02x Device=%02x\n",
 		   le16_to_cpu(usb_dev->descriptor.idVendor),
-- 
2.7.4

Re: [Outreachy kernel] [PATCH] staging: most: hdm-usb: convert pr_warn() to dev_warn()

[Julia Lawall]

> @a@
> identifier f, dev;
> expression fmt, E;
> @@
>
> f(...) {
> 	...
> 	struct device *dev = E;
> 	<+... when != dev == NULL
> - pr_warn(
> + dev_warn(dev,
> 		fmt, ...);
> 	...+>
> }

This is a good idea, but it is unnecessarily inefficient in the details.
You don't use the function name f, so there is no need to match the entire
function.  Matching the entire function causes Coccinelle to go through
all of its possible control-flow paths (loops, conditional branches,
etc.), which can be expensive.  You can instead just start at struct
device *dev = E;.  Also, you don't do anything with fmt, so you can drop
that, and just put ... for the remaining arguments.

julia

Re: [Outreachy kernel] [PATCH] staging: most: hdm-usb: convert pr_warn() to dev_warn()

[Eva Rachel Retuya]

On Mon, Sep 19, 2016 at 11:56:46AM +0200, Julia Lawall wrote:
> > @a@
> > identifier f, dev;
> > expression fmt, E;
> > @@
> >
> > f(...) {
> > 	...
> > 	struct device *dev = E;
> > 	<+... when != dev == NULL
> > - pr_warn(
> > + dev_warn(dev,
> > 		fmt, ...);
> > 	...+>
> > }
> 
> This is a good idea, but it is unnecessarily inefficient in the details.
> You don't use the function name f, so there is no need to match the entire
> function.  Matching the entire function causes Coccinelle to go through
> all of its possible control-flow paths (loops, conditional branches,
> etc.), which can be expensive.  You can instead just start at struct
> device *dev = E;.  Also, you don't do anything with fmt, so you can drop
> that, and just put ... for the remaining arguments.
> 
> julia

I appreciate the input. I'm going to amend my script according to what
you stated here. Do I have to send v2 for this patch?

Eva

Re: [Outreachy kernel] [PATCH] staging: most: hdm-usb: convert pr_warn() to dev_warn()

[Julia Lawall]

On Mon, 19 Sep 2016, Eva Rachel Retuya wrote:

> On Mon, Sep 19, 2016 at 11:56:46AM +0200, Julia Lawall wrote:
> > > @a@
> > > identifier f, dev;
> > > expression fmt, E;
> > > @@
> > >
> > > f(...) {
> > > 	...
> > > 	struct device *dev = E;
> > > 	<+... when != dev == NULL
> > > - pr_warn(
> > > + dev_warn(dev,
> > > 		fmt, ...);
> > > 	...+>
> > > }
> >
> > This is a good idea, but it is unnecessarily inefficient in the details.
> > You don't use the function name f, so there is no need to match the entire
> > function.  Matching the entire function causes Coccinelle to go through
> > all of its possible control-flow paths (loops, conditional branches,
> > etc.), which can be expensive.  You can instead just start at struct
> > device *dev = E;.  Also, you don't do anything with fmt, so you can drop
> > that, and just put ... for the remaining arguments.
> >
> > julia
>
> I appreciate the input. I'm going to amend my script according to what
> you stated here. Do I have to send v2 for this patch?

Yes, please.  It would be better to have better semantic patches in the
git history, for people to be inspired from :)

thanks,
julia