Kernel Newbies Archive on lore.kernel.org
 help / color / Atom feed
* picking the first patch
@ 2021-03-21 16:03 Harsha Vardhan
  2021-03-21 16:14 ` Greg KH
  2021-03-22  5:56 ` Valdis Klētnieks
  0 siblings, 2 replies; 5+ messages in thread
From: Harsha Vardhan @ 2021-03-21 16:03 UTC (permalink / raw)
  To: kernelnewbies

[-- Attachment #1.1: Type: text/plain, Size: 664 bytes --]

Hello team ,

Sorry for a vague question.

So far I have spent a lot of time dreaming to be a kernel hacker without
doing much , but I realised its geting too late and now I want to pick my
first patch to work,

I have decided to address the TODO at drivers/staging/grebus/TODO :
" * Make pwm.c use the struct pwm_ops::apply instead of ::config,
::set_polarity,
  4   ::enable and ::disable."

To make sure this is a first good patch , I verified that there is traction
for this driver recently.

But I am not sure, let's say I change the code , how to test it ?

Any thoughts on whether I should just do a checkpatch.pl change as my first
patch ?

Thanks
Vardhan

[-- Attachment #1.2: Type: text/html, Size: 919 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: picking the first patch
  2021-03-21 16:03 picking the first patch Harsha Vardhan
@ 2021-03-21 16:14 ` Greg KH
  2021-03-21 16:25   ` Harsha Vardhan
  2021-03-22  5:56 ` Valdis Klētnieks
  1 sibling, 1 reply; 5+ messages in thread
From: Greg KH @ 2021-03-21 16:14 UTC (permalink / raw)
  To: Harsha Vardhan; +Cc: kernelnewbies

On Sun, Mar 21, 2021 at 12:03:36PM -0400, Harsha Vardhan wrote:
> Any thoughts on whether I should just do a checkpatch.pl change as my first
> patch ?

You should do a checkpatch.pl change as your first patch :)

That way you can focus on the process more than the technical aspects of
the patch (git, changelog text, subject line, email, submission,
revision, acceptance, etc.) and not have to worry a lot about breaking
working code or not.

After you get the process working properly for you, then move to
changing real code and contributing that way.

But that's just a suggestion, not a requirement, you can do whatever you
want to do :)

good luck!

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: picking the first patch
  2021-03-21 16:14 ` Greg KH
@ 2021-03-21 16:25   ` Harsha Vardhan
  2021-03-21 17:34     ` Lukas Bulwahn
  0 siblings, 1 reply; 5+ messages in thread
From: Harsha Vardhan @ 2021-03-21 16:25 UTC (permalink / raw)
  To: Greg KH; +Cc: kernelnewbies

[-- Attachment #1.1: Type: text/plain, Size: 1266 bytes --]

perfect ! I will do it that way then.

besides that, generally if you are making changes to drivers , then the
responsibility of testing is on the author of the patch right ? if you
don't have the device how would you test such things ?  I would assume
other subsystems like memory will have some sort of test suite that gets
run automatically to make sure we are not introducing any regressions but
confused as to how we ensure the same with drivers.

Thanks so much Greg , for a quick reply .

On Sun, Mar 21, 2021 at 12:14 PM Greg KH <greg@kroah.com> wrote:

> On Sun, Mar 21, 2021 at 12:03:36PM -0400, Harsha Vardhan wrote:
> > Any thoughts on whether I should just do a checkpatch.pl change as my
> first
> > patch ?
>
> You should do a checkpatch.pl change as your first patch :)
>
> That way you can focus on the process more than the technical aspects of
> the patch (git, changelog text, subject line, email, submission,
> revision, acceptance, etc.) and not have to worry a lot about breaking
> working code or not.
>
> After you get the process working properly for you, then move to
> changing real code and contributing that way.
>
> But that's just a suggestion, not a requirement, you can do whatever you
> want to do :)
>
> good luck!
>
> greg k-h
>

[-- Attachment #1.2: Type: text/html, Size: 1793 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: picking the first patch
  2021-03-21 16:25   ` Harsha Vardhan
@ 2021-03-21 17:34     ` Lukas Bulwahn
  0 siblings, 0 replies; 5+ messages in thread
From: Lukas Bulwahn @ 2021-03-21 17:34 UTC (permalink / raw)
  To: Harsha Vardhan; +Cc: Greg KH, kernelnewbies

On Sun, Mar 21, 2021 at 5:25 PM Harsha Vardhan
<harshavardhan3294@gmail.com> wrote:
>
> perfect ! I will do it that way then.
>
> besides that, generally if you are making changes to drivers , then the responsibility of testing is on the author of the patch right ? if you don't have the device how would you test such things ?  I would assume other subsystems like memory will have some sort of test suite that gets run automatically to make sure we are not introducing any regressions but confused as to how we ensure the same with drivers.
>

You already violated the first rule of email netiquette. Do not top
post. See more here
https://people.kernel.org/tglx/notes-about-netiquette.

To your question:

It is not required that you have the driver at hand when you make
changes. That requirement would make any larger refactoring
impossible. You should be able to argue that the change you made is
reasonable and does not break any driver that was not already broken
before. It is up to the users and driver maintainers to ensure that
drivers continue working...

Start with some checkpatch fix on staging... and then you will see...

Lukas

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: picking the first patch
  2021-03-21 16:03 picking the first patch Harsha Vardhan
  2021-03-21 16:14 ` Greg KH
@ 2021-03-22  5:56 ` Valdis Klētnieks
  1 sibling, 0 replies; 5+ messages in thread
From: Valdis Klētnieks @ 2021-03-22  5:56 UTC (permalink / raw)
  To: Harsha Vardhan; +Cc: kernelnewbies

[-- Attachment #1.1: Type: text/plain, Size: 339 bytes --]

On Sun, 21 Mar 2021 12:03:36 -0400, Harsha Vardhan said:

> So far I have spent a lot of time dreaming to be a kernel hacker without
> doing much ,

1) What Greg said.. :)

2) Go read this:  https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html

And yes, *why* you want to be a kernel hacker matters. :)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-21 16:03 picking the first patch Harsha Vardhan
2021-03-21 16:14 ` Greg KH
2021-03-21 16:25   ` Harsha Vardhan
2021-03-21 17:34     ` Lukas Bulwahn
2021-03-22  5:56 ` Valdis Klētnieks

Kernel Newbies Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org
	public-inbox-index kernelnewbies

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git