* Re: My kexec test patches for OpenBMC
2021-02-19 0:53 My kexec test patches for OpenBMC Bruce Mitchell
@ 2021-02-24 8:03 ` Joel Stanley
2021-02-24 17:33 ` Bruce Mitchell
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: Joel Stanley @ 2021-02-24 8:03 UTC (permalink / raw)
To: Bruce Mitchell; +Cc: Andrew Jeffery, OpenBMC Maillist
On Fri, 19 Feb 2021 at 00:53, Bruce Mitchell <Bruce.Mitchell@ibm.com> wrote:
>
> Hello Joel,
>
> Per your request yesterday, I am emailing the details of my kexec/kdump development efforts.
Thanks. Here's what I tested:
https://github.com/shenki/linux/commits/ast2600-kexec
>
> I am running QEMU
>
> qemu-system-arm --version
> QEMU emulator version 5.2.0 (v5.1.0-3479-g27ca38d3db)
That looks fine. I'm using cedric's tree, but anything that will boot
your kernel is fine.
> qemu-system-arm -d cpu_reset -M tacoma-bmc -kernel /tmp/tmp.y2fpdAXM1h.kernel -dtb /tmp/tmp.BWkadwNbTf.dtb -initrd /tmp/tmp.jRpFbzfpBs.initrd -drive file=obmc-phosphor-image-witherspoon-tacoma.wic,if=sd,format=raw,index=2 -net nic -net user,hostfwd=:127.0.0.1:2222-:22,hostfwd=:127.0.0.1:2443-:443,hostname=qemu -nographic -append "crashkernel=64M console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a"
You could simplify your qemu setup if you want. Here's how I tested:
$ qemu-system-arm -M tacoma-bmc -nographic -net nic -nic
user,hostfwd=::2222-:22,tftp=/srv/tftp/ -kernel
aspeed-g5-dev/arch/arm/boot/zImage -dtb
aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb -initrd
~/dev/kernels/misc/rootfs.cpio.xz
This uses a small initramfs with the kexec utility, and has a copy of
the kernel, initrd and dtb inside to make testing easy.
Or, if you want, you can copy files into the system over the ssh port:
I have this in my ~/.ssh/config:
Host qemu
Hostname localhost
Port 2222
User root
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
And then you can use scp like this:
scp aspeed-g5-dev/arch/arm/boot/zImage
aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb
/home/joel/dev/kernels/misc/rootfs.cpio.xz qemu:
> From OpenBMC within QEMU I am using the following to test kexec
>
> kexec -d -l /home/kexec_files/tmp.y2fpdAXM1h.kernel --initrd=/home/kexec_files/tmp.jRpFbzfpBs.initrd --dtb=/home/kexec_files/tmp.BWkadwNbTf.dtb --append="earlycon console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a 1 maxcpus=1 reset_devices"
> kexec -d -e
Here's how I was running it:
# kexec -l zImage --dtb aspeed-bmc-opp-tacoma.dtb --initrd rootfs.cpio.xz
# kexec -e
I haven't set a new command line, so it uses the command line from the
device tree (console=ttyS4,115200n8).
With my patch we will not get the secondary CPU:
[ 0.039517] ASPEED AST2600 rev A1 (05010303)
[ 0.042030] smp: Bringing up secondary CPUs ...
[ 1.163950] CPU1: failed to come online
[ 1.167999] smp: Brought up 1 node, 1 CPU
[ 1.168164] SMP: Total of 1 processors activated (2250.00 BogoMIPS).
That should be the next step in working on the kexec patches. We want
the secondary CPU to be in a state such that the new kernel can take
control as it would in a firmware boot.
Note that this didn't require any changes to the system beyond the
kernel patch. I'm using the same defconfig as we have in the tree.
Cheers,
Joel
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: My kexec test patches for OpenBMC
2021-02-19 0:53 My kexec test patches for OpenBMC Bruce Mitchell
2021-02-24 8:03 ` Joel Stanley
@ 2021-02-24 17:33 ` Bruce Mitchell
2021-03-05 22:27 ` Bruce Mitchell
2021-03-16 20:42 ` Bruce Mitchell
3 siblings, 0 replies; 6+ messages in thread
From: Bruce Mitchell @ 2021-02-24 17:33 UTC (permalink / raw)
To: Joel Stanley; +Cc: Andrew Jeffery, OpenBMC Maillist
-----"openbmc" <openbmc-bounces+bruce.mitchell=ibm.com@lists.ozlabs.org> wrote: -----
>To: Bruce Mitchell <Bruce.Mitchell@ibm.com>
>From: Joel Stanley
>Sent by: "openbmc"
>Date: 02/24/2021 00:04
>Cc: Andrew Jeffery <andrew@aj.id.au>, OpenBMC Maillist
><openbmc@lists.ozlabs.org>
>Subject: [EXTERNAL] Re: My kexec test patches for OpenBMC
>
>On Fri, 19 Feb 2021 at 00:53, Bruce Mitchell
><Bruce.Mitchell@ibm.com> wrote:
>>
>> Hello Joel,
>>
>> Per your request yesterday, I am emailing the details of my
>kexec/kdump development efforts.
>
>Thanks. Here's what I tested:
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sh
>enki_linux_commits_ast2600-2Dkexec&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1Z
>Og&r=XYNAOU-BEndJr70kO1xkYnetCkaomJrlYQm5DudYzNc&m=oX_dPGCu4X3pBZl
>Dw0XYgu4z-3G1JebwP-IvlNbEMDE&s=gT3O534rB4ZDIPbf6Z78bKCR_op-JR1uYcv
>bd3z18RA&e=
>
>>
>> I am running QEMU
>>
>> qemu-system-arm --version
>> QEMU emulator version 5.2.0 (v5.1.0-3479-g27ca38d3db)
>
>That looks fine. I'm using cedric's tree, but anything that will
>boot
>your kernel is fine.
I believe I am using Cédric's tree as well.
https://github.com/legoater/qemu.git
commit 27ca38d3db4a35da977cc89d52541ea12e1ba9c4 (HEAD -> aspeed-5.2, origin/aspeed-5.2, origin/HEAD)
>
>> qemu-system-arm -d cpu_reset -M tacoma-bmc -kernel
>/tmp/tmp.y2fpdAXM1h.kernel -dtb /tmp/tmp.BWkadwNbTf.dtb -initrd
>/tmp/tmp.jRpFbzfpBs.initrd -drive
>file=obmc-phosphor-image-witherspoon-tacoma.wic,if=sd,format=raw,i
>ndex=2 -net nic -net
>user,hostfwd=:127.0.0.1:2222-:22,hostfwd=:127.0.0.1:2443-:443,host
>name=qemu -nographic -append "crashkernel=64M
>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a"
>
>You could simplify your qemu setup if you want. Here's how I
>tested:
>
> $ qemu-system-arm -M tacoma-bmc -nographic -net nic -nic
>user,hostfwd=::2222-:22,tftp=/srv/tftp/ -kernel
>aspeed-g5-dev/arch/arm/boot/zImage -dtb
>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb -initrd
>~/dev/kernels/misc/rootfs.cpio.xz
>
>This uses a small initramfs with the kexec utility, and has a copy
>of
>the kernel, initrd and dtb inside to make testing easy.
>
>Or, if you want, you can copy files into the system over the ssh
>port:
>
>I have this in my ~/.ssh/config:
>
>Host qemu
> Hostname localhost
> Port 2222
> User root
> UserKnownHostsFile /dev/null
> StrictHostKeyChecking no
>
>And then you can use scp like this:
>
>scp aspeed-g5-dev/arch/arm/boot/zImage
>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb
>/home/joel/dev/kernels/misc/rootfs.cpio.xz qemu:
>
>> From OpenBMC within QEMU I am using the following to test kexec
>>
>> kexec -d -l /home/kexec_files/tmp.y2fpdAXM1h.kernel
>--initrd=/home/kexec_files/tmp.jRpFbzfpBs.initrd
>--dtb=/home/kexec_files/tmp.BWkadwNbTf.dtb --append="earlycon
>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a 1 maxcpus=1
>reset_devices"
>> kexec -d -e
>
>Here's how I was running it:
>
># kexec -l zImage --dtb aspeed-bmc-opp-tacoma.dtb --initrd
>rootfs.cpio.xz
># kexec -e
>
>I haven't set a new command line, so it uses the command line from
>the
>device tree (console=ttyS4,115200n8).
>
>With my patch we will not get the secondary CPU:
>
>[ 0.039517] ASPEED AST2600 rev A1 (05010303)
>[ 0.042030] smp: Bringing up secondary CPUs ...
>[ 1.163950] CPU1: failed to come online
>[ 1.167999] smp: Brought up 1 node, 1 CPU
>[ 1.168164] SMP: Total of 1 processors activated (2250.00
>BogoMIPS).
>
>That should be the next step in working on the kexec patches. We
>want
>the secondary CPU to be in a state such that the new kernel can
>take
>control as it would in a firmware boot.
>
>Note that this didn't require any changes to the system beyond the
>kernel patch. I'm using the same defconfig as we have in the tree.
>
>Cheers,
>
>Joel
>
>
I had only found examples that had changed the kernel config
so I changed defconfig to match. I'll try without changing it.
Thank Joel for all your suggestions.
--
Bruce
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: My kexec test patches for OpenBMC
2021-02-19 0:53 My kexec test patches for OpenBMC Bruce Mitchell
2021-02-24 8:03 ` Joel Stanley
2021-02-24 17:33 ` Bruce Mitchell
@ 2021-03-05 22:27 ` Bruce Mitchell
2021-03-16 20:42 ` Bruce Mitchell
3 siblings, 0 replies; 6+ messages in thread
From: Bruce Mitchell @ 2021-03-05 22:27 UTC (permalink / raw)
To: Joel Stanley; +Cc: Andrew Jeffery, OpenBMC Maillist
-----"openbmc" <openbmc-bounces+bruce.mitchell=ibm.com@lists.ozlabs.org> wrote: -----
>To: Bruce Mitchell <Bruce.Mitchell@ibm.com>
>From: Joel Stanley
>Sent by: "openbmc"
>Date: 02/24/2021 00:04
>Cc: Andrew Jeffery <andrew@aj.id.au>, OpenBMC Maillist
><openbmc@lists.ozlabs.org>
>Subject: [EXTERNAL] Re: My kexec test patches for OpenBMC
>
>On Fri, 19 Feb 2021 at 00:53, Bruce Mitchell
><Bruce.Mitchell@ibm.com> wrote:
>>
>> Hello Joel,
>>
>> Per your request yesterday, I am emailing the details of my
>kexec/kdump development efforts.
>
>Thanks. Here's what I tested:
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sh
>enki_linux_commits_ast2600-2Dkexec&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1Z
>Og&r=XYNAOU-BEndJr70kO1xkYnetCkaomJrlYQm5DudYzNc&m=oX_dPGCu4X3pBZl
>Dw0XYgu4z-3G1JebwP-IvlNbEMDE&s=gT3O534rB4ZDIPbf6Z78bKCR_op-JR1uYcv
>bd3z18RA&e=
>
Your kernel changes are similar to what I had done. Since you know
the community better than I do, I propose submitting your changes.
I can do the labor, but want you to get the credit. How would you
like me to proceed?
>>
>> I am running QEMU
>>
>> qemu-system-arm --version
>> QEMU emulator version 5.2.0 (v5.1.0-3479-g27ca38d3db)
>
>That looks fine. I'm using cedric's tree, but anything that will
>boot
>your kernel is fine.
>
>> qemu-system-arm -d cpu_reset -M tacoma-bmc -kernel
>/tmp/tmp.y2fpdAXM1h.kernel -dtb /tmp/tmp.BWkadwNbTf.dtb -initrd
>/tmp/tmp.jRpFbzfpBs.initrd -drive
>file=obmc-phosphor-image-witherspoon-tacoma.wic,if=sd,format=raw,i
>ndex=2 -net nic -net
>user,hostfwd=:127.0.0.1:2222-:22,hostfwd=:127.0.0.1:2443-:443,host
>name=qemu -nographic -append "crashkernel=64M
>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a"
>
>You could simplify your qemu setup if you want. Here's how I
>tested:
>
> $ qemu-system-arm -M tacoma-bmc -nographic -net nic -nic
>user,hostfwd=::2222-:22,tftp=/srv/tftp/ -kernel
>aspeed-g5-dev/arch/arm/boot/zImage -dtb
>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb -initrd
>~/dev/kernels/misc/rootfs.cpio.xz
>
>This uses a small initramfs with the kexec utility, and has a copy
>of
>the kernel, initrd and dtb inside to make testing easy.
>
>Or, if you want, you can copy files into the system over the ssh
>port:
>
>I have this in my ~/.ssh/config:
>
>Host qemu
> Hostname localhost
> Port 2222
> User root
> UserKnownHostsFile /dev/null
> StrictHostKeyChecking no
>
>And then you can use scp like this:
>
>scp aspeed-g5-dev/arch/arm/boot/zImage
>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb
>/home/joel/dev/kernels/misc/rootfs.cpio.xz qemu:
>
>> From OpenBMC within QEMU I am using the following to test kexec
>>
>> kexec -d -l /home/kexec_files/tmp.y2fpdAXM1h.kernel
>--initrd=/home/kexec_files/tmp.jRpFbzfpBs.initrd
>--dtb=/home/kexec_files/tmp.BWkadwNbTf.dtb --append="earlycon
>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a 1 maxcpus=1
>reset_devices"
>> kexec -d -e
>
>Here's how I was running it:
>
># kexec -l zImage --dtb aspeed-bmc-opp-tacoma.dtb --initrd
>rootfs.cpio.xz
># kexec -e
>
>I haven't set a new command line, so it uses the command line from
>the
>device tree (console=ttyS4,115200n8).
>
>With my patch we will not get the secondary CPU:
>
>[ 0.039517] ASPEED AST2600 rev A1 (05010303)
>[ 0.042030] smp: Bringing up secondary CPUs .
>[ 1.163950] CPU1: failed to come online
>[ 1.167999] smp: Brought up 1 node, 1 CPU
>[ 1.168164] SMP: Total of 1 processors activated (2250.00
>BogoMIPS).
>
>That should be the next step in working on the kexec patches. We
>want
>the secondary CPU to be in a state such that the new kernel can
>take
>control as it would in a firmware boot.
>
>Note that this didn't require any changes to the system beyond the
>kernel patch. I'm using the same defconfig as we have in the tree.
>
>Cheers,
>
>Joel
>
>
Hello Joel,
Thanks again for your advice and sharing your wisdom.
I am being urged by our manager to get this up-streamed
sooner rather than later. How can I best work with the
system to make this happen?
Thank you!
--
Bruce
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: My kexec test patches for OpenBMC
2021-02-19 0:53 My kexec test patches for OpenBMC Bruce Mitchell
` (2 preceding siblings ...)
2021-03-05 22:27 ` Bruce Mitchell
@ 2021-03-16 20:42 ` Bruce Mitchell
2021-03-16 22:57 ` Andrew Jeffery
3 siblings, 1 reply; 6+ messages in thread
From: Bruce Mitchell @ 2021-03-16 20:42 UTC (permalink / raw)
To: Joel Stanley, Andrew Jeffery; +Cc: Andrew Jeffery, OpenBMC Maillist, bradleyb
-----Bruce Mitchell/US/IBM wrote: -----
>To: Joel Stanley <joel@jms.id.au>
>From: Bruce Mitchell/US/IBM
>Date: 03/05/2021 14:27
>Cc: Andrew Jeffery <andrew@aj.id.au>, OpenBMC Maillist
><openbmc@lists.ozlabs.org>
>Subject: Re: [EXTERNAL] Re: My kexec test patches for OpenBMC
>
>
>-----"openbmc"
><openbmc-bounces+bruce.mitchell=ibm.com@lists.ozlabs.org> wrote:
>-----
>
>>To: Bruce Mitchell <Bruce.Mitchell@ibm.com>
>>From: Joel Stanley
>>Sent by: "openbmc"
>>Date: 02/24/2021 00:04
>>Cc: Andrew Jeffery <andrew@aj.id.au>, OpenBMC Maillist
>><openbmc@lists.ozlabs.org>
>>Subject: [EXTERNAL] Re: My kexec test patches for OpenBMC
>>
>>On Fri, 19 Feb 2021 at 00:53, Bruce Mitchell
>><Bruce.Mitchell@ibm.com> wrote:
>>>
>>> Hello Joel,
>>>
>>> Per your request yesterday, I am emailing the details of my
>>kexec/kdump development efforts.
>>
>>Thanks. Here's what I tested:
>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_s
>h
>>enki_linux_commits_ast2600-2Dkexec&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1
>Z
>>Og&r=XYNAOU-BEndJr70kO1xkYnetCkaomJrlYQm5DudYzNc&m=oX_dPGCu4X3pBZ
>l
>>Dw0XYgu4z-3G1JebwP-IvlNbEMDE&s=gT3O534rB4ZDIPbf6Z78bKCR_op-JR1uYc
>v
>>bd3z18RA&e=
>>
>
>Your kernel changes are similar to what I had done. Since you know
>the community better than I do, I propose submitting your changes.
>I can do the labor, but want you to get the credit. How would you
>like me to proceed?
>
>>>
>>> I am running QEMU
>>>
>>> qemu-system-arm --version
>>> QEMU emulator version 5.2.0 (v5.1.0-3479-g27ca38d3db)
>>
>>That looks fine. I'm using cedric's tree, but anything that will
>>boot
>>your kernel is fine.
>>
>>> qemu-system-arm -d cpu_reset -M tacoma-bmc -kernel
>>/tmp/tmp.y2fpdAXM1h.kernel -dtb /tmp/tmp.BWkadwNbTf.dtb -initrd
>>/tmp/tmp.jRpFbzfpBs.initrd -drive
>>file=obmc-phosphor-image-witherspoon-tacoma.wic,if=sd,format=raw,
>i
>>ndex=2 -net nic -net
>>user,hostfwd=:127.0.0.1:2222-:22,hostfwd=:127.0.0.1:2443-:443,hos
>t
>>name=qemu -nographic -append "crashkernel=64M
>>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a"
>>
>>You could simplify your qemu setup if you want. Here's how I
>>tested:
>>
>> $ qemu-system-arm -M tacoma-bmc -nographic -net nic -nic
>>user,hostfwd=::2222-:22,tftp=/srv/tftp/ -kernel
>>aspeed-g5-dev/arch/arm/boot/zImage -dtb
>>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb -initrd
>>~/dev/kernels/misc/rootfs.cpio.xz
>>
>>This uses a small initramfs with the kexec utility, and has a
>copy
>>of
>>the kernel, initrd and dtb inside to make testing easy.
>>
>>Or, if you want, you can copy files into the system over the ssh
>>port:
>>
>>I have this in my ~/.ssh/config:
>>
>>Host qemu
>> Hostname localhost
>> Port 2222
>> User root
>> UserKnownHostsFile /dev/null
>> StrictHostKeyChecking no
>>
>>And then you can use scp like this:
>>
>>scp aspeed-g5-dev/arch/arm/boot/zImage
>>aspeed-g5-dev/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dtb
>>/home/joel/dev/kernels/misc/rootfs.cpio.xz qemu:
>>
>>> From OpenBMC within QEMU I am using the following to test kexec
>>>
>>> kexec -d -l /home/kexec_files/tmp.y2fpdAXM1h.kernel
>>--initrd=/home/kexec_files/tmp.jRpFbzfpBs.initrd
>>--dtb=/home/kexec_files/tmp.BWkadwNbTf.dtb --append="earlycon
>>console=ttyS4,115200n8 rootwait root=PARTLABEL=rofs-a 1 maxcpus=1
>>reset_devices"
>>> kexec -d -e
>>
>>Here's how I was running it:
>>
>># kexec -l zImage --dtb aspeed-bmc-opp-tacoma.dtb --initrd
>>rootfs.cpio.xz
>># kexec -e
>>
>>I haven't set a new command line, so it uses the command line
>from
>>the
>>device tree (console=ttyS4,115200n8).
>>
>>With my patch we will not get the secondary CPU:
>>
>>[ 0.039517] ASPEED AST2600 rev A1 (05010303)
>>[ 0.042030] smp: Bringing up secondary CPUs .
>>[ 1.163950] CPU1: failed to come online
>>[ 1.167999] smp: Brought up 1 node, 1 CPU
>>[ 1.168164] SMP: Total of 1 processors activated (2250.00
>>BogoMIPS).
>>
>>That should be the next step in working on the kexec patches. We
>>want
>>the secondary CPU to be in a state such that the new kernel can
>>take
>>control as it would in a firmware boot.
>>
>>Note that this didn't require any changes to the system beyond
>the
>>kernel patch. I'm using the same defconfig as we have in the
>tree.
>>
>>Cheers,
>>
>>Joel
>>
>>
>
>Hello Joel,
>
>Thanks again for your advice and sharing your wisdom.
>I am being urged by our manager to get this up-streamed
>sooner rather than later. How can I best work with the
>system to make this happen?
>
>Thank you!
>
>--
>Bruce
>
>
Hi Joel and Andrew,
I cannot find any response to this thread in my inbox,
however I may still have missed it.
"Joel's kernel changes are similar to what I had done. Since you know
the community better than I do, I propose submitting your changes.
I can do the labor, but want you to get the credit. How would you
like me to proceed?"
Also openbmc/meta-aspeed/MAINTAINERS and the
Linux ARM/ASPEED MACHINE SUPPORT MAINTAINERS
can communicate faster with Joel than I.
I am seeking direction on how to be effective in making this
happen that works with the community.
Thank you!
--
Bruce
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: My kexec test patches for OpenBMC
2021-03-16 20:42 ` Bruce Mitchell
@ 2021-03-16 22:57 ` Andrew Jeffery
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Jeffery @ 2021-03-16 22:57 UTC (permalink / raw)
To: Bruce Mitchell, Joel Stanley
Cc: Andrew Jeffery, OpenBMC Maillist, Brad Bishop
On Wed, 17 Mar 2021, at 07:12, Bruce Mitchell wrote:
>
>
> -----Bruce Mitchell/US/IBM wrote: -----
> >Hello Joel,
> >
> >Thanks again for your advice and sharing your wisdom.
> >I am being urged by our manager to get this up-streamed
> >sooner rather than later. How can I best work with the
> >system to make this happen?
> >
> >Thank you!
> >
> >--
> >Bruce
> >
> >
>
> Hi Joel and Andrew,
>
> I cannot find any response to this thread in my inbox,
> however I may still have missed it.
I don't think you missed anything :)
>
> "Joel's kernel changes are similar to what I had done. Since you know
> the community better than I do, I propose submitting your changes.
> I can do the labor, but want you to get the credit. How would you
> like me to proceed?"
Well, you've both ended up with the same implementation as far as I'm
aware? I don't think it matters too much which way the patches go in
terms of credit. Let's not hold the show up on something like that.
Joel will need to review your patches on the upstream list anyway, so
you might as well just post them rather than wait on getting
permission. "Bias for action" from Amazon's leadership principles is a
helpful mindset[1] (and it's worth reading the others).
[1] https://www.aboutamazon.com/about-us/leadership-principles
Before sending your patches, please read the following and make sure
you are confident your work satisfies all the listed requirements:
1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v5.11
2. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submit-checklist.rst?h=v5.11
The very minimum is that ./scripts/checkpatch.pl says your patches are
clean and that you Cc the appropriate maintainers as listed by
./scripts/get_maintainer.pl.
The process of emailing patches is terrible, so if you have any
questions about that please don't hesitate to ask.
Cheers,
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread