| Message ID | MA0P287MB28228572C526C5099A8BDA2DFE7B2@MA0P287MB2822.INDP287.PROD.OUTLOOK.COM (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [GIT,PULL] RISC-V Devicetrees fix for Sophgo/SG2042 v6.8-rc1 | expand |
On Wed, Jan 24, 2024, at 08:50, Chen Wang wrote: > Hey Arnd, > > Please pull one DT fix for Sophgo SG2042 based off v6.8-rc1. Thank you for the pull request I found a few small mistakes, so please respin the tag and the email: > > are available in the Git repository at: > > git@github.com:sophgo/linux.git > tags/riscv-dt-fixes-sophgo-sg2042-for-v6.8-rc1 This is not a URL I can pull from. You may want to add something like this in your .gitconfig in order to turn it into a normal https:// URL when sending a pull request: [url "https://github.com"] insteadOf = git@github.com > ---------------------------------------------------------------- > RISC-V Devicetrees fix for Sophgo/SG2042 v6.8-rc1 > > This patch is [2/2] of [1]. The binding part [2] has been merged in > v6.8-rc1, but > the dt patch [3] is missed. This fix add the dt patch. > > Signed-off-by: Chen Wang <unicorn_wang@outlook.com> > > Link: > https://lore.kernel.org/all/IA1PR20MB4953C912FC58C0D248976564BB86A@IA1PR20MB4953.namprd20.prod.outlook.com/ > [1] > Link: > https://lore.kernel.org/all/09b2fc2f-dde9-4f43-9704-d8053bfc85cf@linaro.org/ > [2] > Link: > https://lore.kernel.org/all/IA1PR20MB4953669C097D9C9E24B549FFBB86A@IA1PR20MB4953.namprd20.prod.outlook.com/ > [3] The tag description is what gets turned into the merge commit when I pull it, so it needs to be something that makes sense for the long-term git history as well as for me to understand why I need to pull it. For a normal branch, that would mainly mean that you should give a summary of the branch contents. In this case, I see you have only one patch, so it's probably easier to send that patch to soc@kernel.org individually, with the same cc list. Arnd
On 2024/1/26 14:11, Arnd Bergmann wrote: [......] > The tag description is what gets turned into the merge commit > when I pull it, so it needs to be something that makes sense > for the long-term git history as well as for me to understand > why I need to pull it. > > For a normal branch, that would mainly mean that you should > give a summary of the branch contents. In this case, I see you > have only one patch, so it's probably easier to send that > patch to soc@kernel.org individually, with the same cc list. > > Arnd I have one question about your mentiond "send that patch to soc@kernel.org individiually ...". If I sent it as a patch, where should I add the explanation of what I explained in this GIT PULL about the omission. After all, the content of this explanation is not part of the commit of that patch. Should I send this patch email and then reply it, and then explain in the reply email? Thanks, Chen
On Fri, Jan 26, 2024, at 08:06, Chen Wang wrote: > On 2024/1/26 14:11, Arnd Bergmann wrote: > [......] >> The tag description is what gets turned into the merge commit >> when I pull it, so it needs to be something that makes sense >> for the long-term git history as well as for me to understand >> why I need to pull it. >> >> For a normal branch, that would mainly mean that you should >> give a summary of the branch contents. In this case, I see you >> have only one patch, so it's probably easier to send that >> patch to soc@kernel.org individually, with the same cc list. > > I have one question about your mentiond "send that patch to > soc@kernel.org individiually ...". If I sent it as a patch, where > should I add the explanation of what I explained in this GIT PULL about > the omission. After all, the content of this explanation is not part of > the commit of that patch. > > Should I send this patch email and then reply it, and then explain in > the reply email? There are two common ways of doing it: a) You can add extra information below the '---' line in your patch, next to the diffstat. This text will get dropped during 'git am' when I pick it up but is available when I look at the email. b) You can send the patches as a series using 'git format-patch --cover letter' and 'git send-email'. In this case, the cover letter will be numbered as '[PATCH 0/1]' and allow you to add the same kind of description that would go into a pull request but won't become a merge commit. Arnd
On 2024/1/26 15:10, Arnd Bergmann wrote: > On Fri, Jan 26, 2024, at 08:06, Chen Wang wrote: >> On 2024/1/26 14:11, Arnd Bergmann wrote: >> [......] >>> The tag description is what gets turned into the merge commit >>> when I pull it, so it needs to be something that makes sense >>> for the long-term git history as well as for me to understand >>> why I need to pull it. >>> >>> For a normal branch, that would mainly mean that you should >>> give a summary of the branch contents. In this case, I see you >>> have only one patch, so it's probably easier to send that >>> patch to soc@kernel.org individually, with the same cc list. >> I have one question about your mentiond "send that patch to >> soc@kernel.org individiually ...". If I sent it as a patch, where >> should I add the explanation of what I explained in this GIT PULL about >> the omission. After all, the content of this explanation is not part of >> the commit of that patch. >> >> Should I send this patch email and then reply it, and then explain in >> the reply email? > There are two common ways of doing it: > > a) You can add extra information below the '---' line in your > patch, next to the diffstat. This text will get dropped during > 'git am' when I pick it up but is available when I look at > the email. > > b) You can send the patches as a series using 'git format-patch > --cover letter' and 'git send-email'. In this case, the cover > letter will be numbered as '[PATCH 0/1]' and allow you to > add the same kind of description that would go into a pull > request but won't become a merge commit. > > Arnd I like method b) :) I will re-send it, thanks for your direction. Regards, Chen
On 2024/1/26 15:10, Arnd Bergmann wrote: > On Fri, Jan 26, 2024, at 08:06, Chen Wang wrote: >> On 2024/1/26 14:11, Arnd Bergmann wrote: >> [......] >>> The tag description is what gets turned into the merge commit >>> when I pull it, so it needs to be something that makes sense >>> for the long-term git history as well as for me to understand >>> why I need to pull it. >>> >>> For a normal branch, that would mainly mean that you should >>> give a summary of the branch contents. In this case, I see you >>> have only one patch, so it's probably easier to send that >>> patch to soc@kernel.org individually, with the same cc list. >> I have one question about your mentiond "send that patch to >> soc@kernel.org individiually ...". If I sent it as a patch, where >> should I add the explanation of what I explained in this GIT PULL about >> the omission. After all, the content of this explanation is not part of >> the commit of that patch. >> >> Should I send this patch email and then reply it, and then explain in >> the reply email? > There are two common ways of doing it: > > a) You can add extra information below the '---' line in your > patch, next to the diffstat. This text will get dropped during > 'git am' when I pick it up but is available when I look at > the email. > > b) You can send the patches as a series using 'git format-patch > --cover letter' and 'git send-email'. In this case, the cover > letter will be numbered as '[PATCH 0/1]' and allow you to > add the same kind of description that would go into a pull > request but won't become a merge commit. > > Arnd Hi, Arnd, I have re-sent that patch to soc@kernel.org. Will it be merged in master in 6.8-rc2? Thanks, Chen
On Fri, Jan 26, 2024, at 13:31, Chen Wang wrote: > On 2024/1/26 15:10, Arnd Bergmann wrote: >> On Fri, Jan 26, 2024, at 08:06, Chen Wang wrote: >>> On 2024/1/26 14:11, Arnd Bergmann wrote: > > I have re-sent that patch to soc@kernel.org. Will it be merged in master > in 6.8-rc2? Yes, you are lucky as I'm just in the process of sending out a fixes pull request. Arnd
On 2024/1/26 20:59, Arnd Bergmann wrote: [......] > Yes, you are lucky as I'm just in the process of sending out > a fixes pull request. > > Arnd Great, thank you. :) Chen
Hey Arnd, Please pull one DT fix for Sophgo SG2042 based off v6.8-rc1. Thanks, Chen. The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d: Linux 6.8-rc1 (2024-01-21 14:11:32 -0800) are available in the Git repository at: git@github.com:sophgo/linux.git tags/riscv-dt-fixes-sophgo-sg2042-for-v6.8-rc1 for you to fetch changes up to eb37a1537da8c92eadc6bde026c18988b00892c1: riscv: dts: sophgo: separate sg2042 mtime and mtimecmp to fit aclint format (2024-01-24 14:20:51 +0800) ---------------------------------------------------------------- RISC-V Devicetrees fix for Sophgo/SG2042 v6.8-rc1 This patch is [2/2] of [1]. The binding part [2] has been merged in v6.8-rc1, but the dt patch [3] is missed. This fix add the dt patch. Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/all/IA1PR20MB4953C912FC58C0D248976564BB86A@IA1PR20MB4953.namprd20.prod.outlook.com/ [1] Link: https://lore.kernel.org/all/09b2fc2f-dde9-4f43-9704-d8053bfc85cf@linaro.org/ [2] Link: https://lore.kernel.org/all/IA1PR20MB4953669C097D9C9E24B549FFBB86A@IA1PR20MB4953.namprd20.prod.outlook.com/ [3] ---------------------------------------------------------------- Inochi Amaoto (1): riscv: dts: sophgo: separate sg2042 mtime and mtimecmp to fit aclint format arch/riscv/boot/dts/sophgo/sg2042.dtsi | 80 ++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------- 1 file changed, 48 insertions(+), 32 deletions(-)