On Mon, Nov 11, 2013 at 12:52:06AM -0200, Luca Bartolacci wrote:
> The thing is this one, for example i already read about kerneljanitors
> and the we are "cleaning" the code with checkpatch. I put next here
> some "clean" of a whitespace on bluetooth/bfusb.c. The thing is: "Its
> ok to make a big patch, cleaning all the warnings?"
> We must do it all at once ?
> Example:
> total: 2 errors, 13 warnings, 742 lines checked
> If i clean all in one patch, its ok?.
> Im asking this because i know its a pain in the *ss to be
> cherrypicking from all the clean, not in this case. But there are code
> with 200 warnings (of line over 80 characters).
It's easiest to start in staging/. Staging is less picky.
Generally the rule in staging is to pick one kind of white space problem
and fix it throughout the file. But really just consider it from a
reviewer perspective and do something that makes sense.
Sign up for the staging email list and review other newbie patches.
> Beside this, the other thing the is bothering me is: "Should i do this
> kind of patch or should i focus on find bugs in the code?"(Like
> locking bugs, security bugs, etc)
It's more interesting to focus on bugs.
>
> I apologize if I made/asked something wrong.
>
>
The patch is white space damaged and doesn't apply. I have no idea what
you were fixing.
regards,
dan carpenter
> diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
> index 3138699..cc8a707 100644
> --- a/drivers/bluetooth/bfusb.c
> +++ b/drivers/bluetooth/bfusb.c
> @@ -145,8 +145,8 @@ static int bfusb_send_bulk(struct bfusb_data *data, struct s
>
> err = usb_submit_urb(urb, GFP_ATOMIC);
> if (err) {
> - BT_ERR("%s bulk tx submit failed urb %p err %d",
> - data->hdev->name, urb, err);
> + BT_ERR("%s bulk tx submit failed urb %p err %d",
> + data->hdev->name, urb, err);
> skb_unlink(skb, &data->pending_q);
> usb_free_urb(urb);
> } else
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
