Add a pr_info() in the uvc_probe function to trace when the
uvcvideo driver is loaded. This is for learning purposes.

Signed-off-by: Imene Jaziri <imenjazirii18@gmail.com>
---
 drivers/media/usb/uvc/uvc_driver.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index da24a655ab68..4e5d1d636640 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2170,7 +2170,6 @@ static int uvc_probe(struct usb_interface *intf,
 		(const struct uvc_device_info *)id->driver_info;
 	int function;
 	int ret;
-
 	/* Allocate memory for the device and initialize it. */
 	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
 	if (dev == NULL)
@@ -2188,7 +2187,7 @@ static int uvc_probe(struct usb_interface *intf,
 	dev->info = info ? info : &uvc_quirk_none;
 	dev->quirks = uvc_quirks_param == -1
 		    ? dev->info->quirks : uvc_quirks_param;
-
+	pr_info("I changed uvcvideo driver in the Linux Kernel\n");
 	if (id->idVendor && id->idProduct)
 		uvc_dbg(dev, PROBE, "Probing known UVC device %s (%04x:%04x)\n",
 			udev->devpath, id->idVendor, id->idProduct);
-- 
2.34.1

Hi,

On Fri, Aug 01, 2025 at 03:53:26PM +0100, Imene Jaziri wrote:
> Add a pr_info() in the uvc_probe function to trace when the
> uvcvideo driver is loaded. This is for learning purposes.

What part of the learning instructions you are following instructed you
to submit this patch to kernel mailing lists ? We are regularly spammed
by similar patches, which indicates the instructions are not clear
enough.

> Signed-off-by: Imene Jaziri <imenjazirii18@gmail.com>
> ---
>  drivers/media/usb/uvc/uvc_driver.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index da24a655ab68..4e5d1d636640 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2170,7 +2170,6 @@ static int uvc_probe(struct usb_interface *intf,
>  		(const struct uvc_device_info *)id->driver_info;
>  	int function;
>  	int ret;
> -
>  	/* Allocate memory for the device and initialize it. */
>  	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>  	if (dev == NULL)
> @@ -2188,7 +2187,7 @@ static int uvc_probe(struct usb_interface *intf,
>  	dev->info = info ? info : &uvc_quirk_none;
>  	dev->quirks = uvc_quirks_param == -1
>  		    ? dev->info->quirks : uvc_quirks_param;
> -
> +	pr_info("I changed uvcvideo driver in the Linux Kernel\n");
>  	if (id->idVendor && id->idProduct)
>  		uvc_dbg(dev, PROBE, "Probing known UVC device %s (%04x:%04x)\n",
>  			udev->devpath, id->idVendor, id->idProduct);

-- 
Regards,

Laurent Pinchart

Hi,

On 8/1/25 17:04, Laurent Pinchart wrote:
> Hi,
> 
> On Fri, Aug 01, 2025 at 03:53:26PM +0100, Imene Jaziri wrote:
>> Add a pr_info() in the uvc_probe function to trace when the
>> uvcvideo driver is loaded. This is for learning purposes.
> 
> What part of the learning instructions you are following instructed you
> to submit this patch to kernel mailing lists ? We are regularly spammed
> by similar patches, which indicates the instructions are not clear
> enough.
> 

I got curious too. It comes from the Linux Foundation training LFD103
[1]. Chapter 8 describes this patch pretty much, and chapter 9 describes
how to send the patch, but with a warning not to do so :

  [...]
  At this time, you can run:

  git format-patch -1 <commit ID> --to=maintainer1 --to=maintainer2
--cc=maillist1 --cc=maillist2

  This will generate a patch.

  Important Note:
  Please note that this is just an example. Don’t send this patch upstream.

  You can revert this commit now.

  Please refer to the Select the recipients for your patch section in
the Submitting patches: the essential guide to getting your code into
the kernel document.

  When you have your own patch ready for submittal, you can follow this
example process to generate the patch and send it upstream using the
following command:

  git send-email <patch_file>
  [...]

Looking at it I guess it's pretty easy to miss the note. Maybe
requesting to add '--dry-run' to the git send-email command could be a
simple fix to prevent from copy/pasting ?

[1]
https://training.linuxfoundation.org/training/a-beginners-guide-to-linux-kernel-development-lfd103/

>> Signed-off-by: Imene Jaziri <imenjazirii18@gmail.com>
>> ---
>>  drivers/media/usb/uvc/uvc_driver.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
>> index da24a655ab68..4e5d1d636640 100644
>> --- a/drivers/media/usb/uvc/uvc_driver.c
>> +++ b/drivers/media/usb/uvc/uvc_driver.c
>> @@ -2170,7 +2170,6 @@ static int uvc_probe(struct usb_interface *intf,
>>  		(const struct uvc_device_info *)id->driver_info;
>>  	int function;
>>  	int ret;
>> -
>>  	/* Allocate memory for the device and initialize it. */
>>  	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>>  	if (dev == NULL)
>> @@ -2188,7 +2187,7 @@ static int uvc_probe(struct usb_interface *intf,
>>  	dev->info = info ? info : &uvc_quirk_none;
>>  	dev->quirks = uvc_quirks_param == -1
>>  		    ? dev->info->quirks : uvc_quirks_param;
>> -
>> +	pr_info("I changed uvcvideo driver in the Linux Kernel\n");
>>  	if (id->idVendor && id->idProduct)
>>  		uvc_dbg(dev, PROBE, "Probing known UVC device %s (%04x:%04x)\n",
>>  			udev->devpath, id->idVendor, id->idProduct);
> 

-- 
Regards,
Benjamin

Hi Benjamin,

(CC'ing Shuah)

On Thu, Aug 07, 2025 at 09:53:41AM +0200, Benjamin Mugnier wrote:
> On 8/1/25 17:04, Laurent Pinchart wrote:
> > On Fri, Aug 01, 2025 at 03:53:26PM +0100, Imene Jaziri wrote:
> >> Add a pr_info() in the uvc_probe function to trace when the
> >> uvcvideo driver is loaded. This is for learning purposes.
> > 
> > What part of the learning instructions you are following instructed you
> > to submit this patch to kernel mailing lists ? We are regularly spammed
> > by similar patches, which indicates the instructions are not clear
> > enough.
> > 
> 
> I got curious too. It comes from the Linux Foundation training LFD103
> [1]. Chapter 8 describes this patch pretty much, and chapter 9 describes
> how to send the patch, but with a warning not to do so :
> 
>   [...]
>   At this time, you can run:
> 
>   git format-patch -1 <commit ID> --to=maintainer1 --to=maintainer2
> --cc=maillist1 --cc=maillist2
> 
>   This will generate a patch.
> 
>   Important Note:
>   Please note that this is just an example. Don’t send this patch upstream.
> 
>   You can revert this commit now.
> 
>   Please refer to the Select the recipients for your patch section in
> the Submitting patches: the essential guide to getting your code into
> the kernel document.
> 
>   When you have your own patch ready for submittal, you can follow this
> example process to generate the patch and send it upstream using the
> following command:
> 
>   git send-email <patch_file>
>   [...]

Imene provided me with that information in private.

> Looking at it I guess it's pretty easy to miss the note.

Yes, reading the text, I really can't blame the people training the
course for missing it. It's a bit like if a mushroom foraging book said

- go pick those red mushrooms with white dots on the cap in the forest
- cut them in pieces, pan-fry them with butter
- add a couple of eggs, salt and pepper to make an omelette
- the dish is ready ! enjoy your meal !
- you won't be eating that, it's poisonous. throw it away

:-)

> Maybe
> requesting to add '--dry-run' to the git send-email command could be a
> simple fix to prevent from copy/pasting ?

I've contacted Shuah, who told me she updated the training material.
Hopefully we'll soon stop getting such patches.

> [1] https://training.linuxfoundation.org/training/a-beginners-guide-to-linux-kernel-development-lfd103/

I wonder why the training materials are not public, given that the
training is free of charge. Did I miss something, or does the LF
encourage people to develop free software, but won't eat their own
dogfood and publish their materials under open licenses ?

> >> Signed-off-by: Imene Jaziri <imenjazirii18@gmail.com>
> >> ---
> >>  drivers/media/usb/uvc/uvc_driver.c | 3 +--
> >>  1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> >> index da24a655ab68..4e5d1d636640 100644
> >> --- a/drivers/media/usb/uvc/uvc_driver.c
> >> +++ b/drivers/media/usb/uvc/uvc_driver.c
> >> @@ -2170,7 +2170,6 @@ static int uvc_probe(struct usb_interface *intf,
> >>  		(const struct uvc_device_info *)id->driver_info;
> >>  	int function;
> >>  	int ret;
> >> -
> >>  	/* Allocate memory for the device and initialize it. */
> >>  	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> >>  	if (dev == NULL)
> >> @@ -2188,7 +2187,7 @@ static int uvc_probe(struct usb_interface *intf,
> >>  	dev->info = info ? info : &uvc_quirk_none;
> >>  	dev->quirks = uvc_quirks_param == -1
> >>  		    ? dev->info->quirks : uvc_quirks_param;
> >> -
> >> +	pr_info("I changed uvcvideo driver in the Linux Kernel\n");
> >>  	if (id->idVendor && id->idProduct)
> >>  		uvc_dbg(dev, PROBE, "Probing known UVC device %s (%04x:%04x)\n",
> >>  			udev->devpath, id->idVendor, id->idProduct);

-- 
Regards,

Laurent Pinchart

On 8/7/25 02:14, Laurent Pinchart wrote:
> Hi Benjamin,
> 
> (CC'ing Shuah)
> 
> On Thu, Aug 07, 2025 at 09:53:41AM +0200, Benjamin Mugnier wrote:
>> On 8/1/25 17:04, Laurent Pinchart wrote:
>>> On Fri, Aug 01, 2025 at 03:53:26PM +0100, Imene Jaziri wrote:
>>>> Add a pr_info() in the uvc_probe function to trace when the
>>>> uvcvideo driver is loaded. This is for learning purposes.
>>>
>>> What part of the learning instructions you are following instructed you
>>> to submit this patch to kernel mailing lists ? We are regularly spammed
>>> by similar patches, which indicates the instructions are not clear
>>> enough.
>>>
>>
>> I got curious too. It comes from the Linux Foundation training LFD103
>> [1]. Chapter 8 describes this patch pretty much, and chapter 9 describes
>> how to send the patch, but with a warning not to do so :
>>
>>    [...]
>>    At this time, you can run:
>>
>>    git format-patch -1 <commit ID> --to=maintainer1 --to=maintainer2
>> --cc=maillist1 --cc=maillist2
>>
>>    This will generate a patch.
>>
>>    Important Note:
>>    Please note that this is just an example. Don’t send this patch upstream.
>>
>>    You can revert this commit now.
>>
>>    Please refer to the Select the recipients for your patch section in
>> the Submitting patches: the essential guide to getting your code into
>> the kernel document.
>>
>>    When you have your own patch ready for submittal, you can follow this
>> example process to generate the patch and send it upstream using the
>> following command:
>>
>>    git send-email <patch_file>
>>    [...]
> 
> Imene provided me with that information in private.
> 
>> Looking at it I guess it's pretty easy to miss the note.
> 
> Yes, reading the text, I really can't blame the people training the
> course for missing it. It's a bit like if a mushroom foraging book said
> 
> - go pick those red mushrooms with white dots on the cap in the forest
> - cut them in pieces, pan-fry them with butter
> - add a couple of eggs, salt and pepper to make an omelette
> - the dish is ready ! enjoy your meal !
> - you won't be eating that, it's poisonous. throw it away
> 
> :-)
> 
>> Maybe
>> requesting to add '--dry-run' to the git send-email command could be a
>> simple fix to prevent from copy/pasting ?

No question that the material is confusing. The material is in
a publicly available fee course.

> 
> I've contacted Shuah, who told me she updated the training material.
> Hopefully we'll soon stop getting such patches.

It is fixed now and the spam should stop. This course has been in
use for 6 years, this is the first time we are seeing spam.

Sorry for the oversight that resulted in spam.

thanks,
-- Shuah

On Thu, Aug 07, 2025 at 12:40:48PM -0600, Shuah Khan wrote:
> On 8/7/25 02:14, Laurent Pinchart wrote:
> > Hi Benjamin,
> > 
> > (CC'ing Shuah)
> > 
> > On Thu, Aug 07, 2025 at 09:53:41AM +0200, Benjamin Mugnier wrote:
> >> On 8/1/25 17:04, Laurent Pinchart wrote:
> >>> On Fri, Aug 01, 2025 at 03:53:26PM +0100, Imene Jaziri wrote:
> >>>> Add a pr_info() in the uvc_probe function to trace when the
> >>>> uvcvideo driver is loaded. This is for learning purposes.
> >>>
> >>> What part of the learning instructions you are following instructed you
> >>> to submit this patch to kernel mailing lists ? We are regularly spammed
> >>> by similar patches, which indicates the instructions are not clear
> >>> enough.
> >>>
> >>
> >> I got curious too. It comes from the Linux Foundation training LFD103
> >> [1]. Chapter 8 describes this patch pretty much, and chapter 9 describes
> >> how to send the patch, but with a warning not to do so :
> >>
> >>    [...]
> >>    At this time, you can run:
> >>
> >>    git format-patch -1 <commit ID> --to=maintainer1 --to=maintainer2
> >> --cc=maillist1 --cc=maillist2
> >>
> >>    This will generate a patch.
> >>
> >>    Important Note:
> >>    Please note that this is just an example. Don’t send this patch upstream.
> >>
> >>    You can revert this commit now.
> >>
> >>    Please refer to the Select the recipients for your patch section in
> >> the Submitting patches: the essential guide to getting your code into
> >> the kernel document.
> >>
> >>    When you have your own patch ready for submittal, you can follow this
> >> example process to generate the patch and send it upstream using the
> >> following command:
> >>
> >>    git send-email <patch_file>
> >>    [...]
> > 
> > Imene provided me with that information in private.
> > 
> >> Looking at it I guess it's pretty easy to miss the note.
> > 
> > Yes, reading the text, I really can't blame the people training the
> > course for missing it. It's a bit like if a mushroom foraging book said
> > 
> > - go pick those red mushrooms with white dots on the cap in the forest
> > - cut them in pieces, pan-fry them with butter
> > - add a couple of eggs, salt and pepper to make an omelette
> > - the dish is ready ! enjoy your meal !
> > - you won't be eating that, it's poisonous. throw it away
> > 
> > :-)
> > 
> >> Maybe
> >> requesting to add '--dry-run' to the git send-email command could be a
> >> simple fix to prevent from copy/pasting ?
> 
> No question that the material is confusing. The material is in
> a publicly available fee course.
> 
> > I've contacted Shuah, who told me she updated the training material.
> > Hopefully we'll soon stop getting such patches.
> 
> It is fixed now and the spam should stop. This course has been in
> use for 6 years, this is the first time we are seeing spam.

Just to be clear, I'm not blameing Imene here. I've received quite a few
similar patches over the last years.

> Sorry for the oversight that resulted in spam.

No worries, it happens.

-- 
Regards,

Laurent Pinchart