picking the first patch

picking the first patch

[Harsha Vardhan]

[-- 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

Re: picking the first patch

[Greg KH]

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

Re: picking the first patch

[Harsha Vardhan]

[-- 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

Re: picking the first patch

[Lukas Bulwahn]

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

Re: picking the first patch

[Valdis Klētnieks]

[-- 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