Skip to contentSkip to conversation

PCI fixes for v4.20

GIT PULL Merged Bjorn Helgaas 4 participants 14 messages Nov 14, 2018 – Nov 15, 2018

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PCI fixes:

- Revert a _PXM change that causes silent early boot failure on some AMD ThreadRipper systems (Bjorn Helgaas)

The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

ssh://[email protected]/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1

for you to fetch changes up to 0d76bcc960e6057750fcf556b65da13f8bbdfd2b:

Revert "ACPI/PCI: Pay attention to device-specific _PXM node values" (2018-11-13 08:38:17 -0600)

----------------------------------------------------------------
pci-v4.20-fixes-1

----------------------------------------------------------------
Bjorn Helgaas (1):
Revert "ACPI/PCI: Pay attention to device-specific _PXM node values"

 drivers/pci/pci-acpi.c | 5 -----
 1 file changed, 5 deletions(-)
#2 lore raw

Hey Konstantin,

that bot needs some parsing improvs: "None None".

Quoted 12 lines · On Wed, Nov 14, 2018 at 08:00:03PM +0000, [email protected] wrote:

The pull request you sent on Wed, 14 Nov 2018 00:20:10 -0600:

Quoted 1 line

None None

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d41217aac0a577a247c9c8cde688419fde25fba5

Thank you!

Signature · 2 lines
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
Signature · 4 lines
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
#3 lore raw
Quoted 3 lines · Borislav Petkov

Hey Konstantin,

that bot needs some parsing improvs: "None None".

Correct, this is because the original pull request was for an ssh:// URL, which I'm not properly handling for the purposes of generating responses. I will add some logic to deal with that.

-K

#4 lore raw
Quoted 6 lines · Konstantin Ryabitsev
Quoted 3 lines · Borislav Petkov

Hey Konstantin,

that bot needs some parsing improvs: "None None".

Correct, this is because the original pull request was for an ssh://

You'd think Bjorn would know better... :-)))

Signature · 4 lines
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
#5 lore raw
Quoted 5 lines · Borislav Petkov
Quoted 3 lines
Quoted 1 line

that bot needs some parsing improvs: "None None".

Correct, this is because the original pull request was for an ssh://

You'd think Bjorn would know better... :-)))

For the record, there's nothing wrong with that, it's just a condition that I didn't expect. I have a fix in place that should avoid this in the future.

-K

#6 lore raw
Quoted 3 lines · Konstantin Ryabitsev

For the record, there's nothing wrong with that, it's just a condition that I didn't expect. I have a fix in place that should avoid this in the future.

Actually, I meant the pull request URL.

Here's some background info:

https://lkml.kernel.org/r/CA%2B55aFyMxkS=8JzZ%2BROOAFkwR45EKBnQ0GUMQS4f%[email protected]

and I kinda see the point of maybe not having your ssh username in the URL. Not that it is a big deal for us, k.org users though.

Signature · 4 lines
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
#7 lore raw
Quoted 6 lines · Borislav Petkov
Quoted 3 lines · Konstantin Ryabitsev

For the record, there's nothing wrong with that, it's just a condition that I didn't expect. I have a fix in place that should avoid this in the future.

Actually, I meant the pull request URL.

My pull request URL was this:

ssh://[email protected]/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1

Quoted 6 lines

Here's some background info:

https://lkml.kernel.org/r/CA%2B55aFyMxkS=8JzZ%2BROOAFkwR45EKBnQ0GUMQS4f%[email protected]

and I kinda see the point of maybe not having your ssh username in the URL. Not that it is a big deal for us, k.org users though.

Sorry, I don't understand the problem. I have this in my .gitconfig:

[url "ssh://[email protected]"]
insteadOf = https://git.kernel.org
insteadOf = http://git.kernel.org
insteadOf = git://git.kernel.org

because I thought that was the recommended way (see the end of
https://korg.wiki.kernel.org/userdoc/gitolite). But that also makes my request-pull:

    $ git request-pull origin/master git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci-v4.20-fixes-1

generate the ssh URL above. If I remove the insteadOf stuff from .gitconfig, request-pull produces this instead:

    git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1

I'm happy to do either; just tell me which :)

Bjorn

#8 lore raw
Quoted 14 lines · Bjorn Helgaas
Quoted 2 lines

and I kinda see the point of maybe not having your ssh username in the URL. Not that it is a big deal for us, k.org users though.

Sorry, I don't understand the problem. I have this in my .gitconfig:

[url "ssh://[email protected]"]
insteadOf = https://git.kernel.org
insteadOf = http://git.kernel.org
insteadOf = git://git.kernel.org

because I thought that was the recommended way (see the end of
https://korg.wiki.kernel.org/userdoc/gitolite). But that also makes my request-pull:

Quoted 8 lines
    $ git request-pull origin/master git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci-v4.20-fixes-1

generate the ssh URL above. If I remove the insteadOf stuff from .gitconfig, request-pull produces this instead:

    git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1

I'm happy to do either; just tell me which :)

You didn't really do anything wrong. In *general* I prefer to see public URLs if they are sent to public lists, so if you're cc'ing something to LKML, I would generally expect the pull request to have a public URL like https://git.kernel.org/ instead of a private ssh:// URL that is only accessible to people with a kernel.org account.

That's basically all there is to it. It doesn't *really* matter, since Linus is the one who will be merging the actual pull request, and he certainly has access to internal ssh:// URLs. However, in case someone else was interested in reviewing the pull request, it would be more friendly to have a public URL for them.

Best,
-K

#9 lore raw
Quoted 30 lines · Konstantin Ryabitsev
Quoted 14 lines · Bjorn Helgaas
Quoted 2 lines

and I kinda see the point of maybe not having your ssh username in the URL. Not that it is a big deal for us, k.org users though.

Sorry, I don't understand the problem. I have this in my .gitconfig:

[url "ssh://[email protected]"]
insteadOf = https://git.kernel.org
insteadOf = http://git.kernel.org
insteadOf = git://git.kernel.org

because I thought that was the recommended way (see the end of
https://korg.wiki.kernel.org/userdoc/gitolite). But that also makes my request-pull:

Quoted 8 lines
    $ git request-pull origin/master git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci-v4.20-fixes-1

generate the ssh URL above. If I remove the insteadOf stuff from .gitconfig, request-pull produces this instead:

    git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.20-fixes-1

I'm happy to do either; just tell me which :)

You didn't really do anything wrong. In *general* I prefer to see public URLs if they are sent to public lists, so if you're cc'ing something to LKML, I would generally expect the pull request to have a public URL like https://git.kernel.org/ instead of a private ssh:// URL that is only accessible to people with a kernel.org account.

Quoted 5 lines

That's basically all there is to it. It doesn't *really* matter, since Linus is the one who will be merging the actual pull request, and he certainly has access to internal ssh:// URLs. However, in case someone else was interested in reviewing the pull request, it would be more friendly to have a public URL for them.

OK, I think I'll remove the insteadOf chunk from my .gitconfig. Should
https://korg.wiki.kernel.org/userdoc/gitolite be updated to remove or expand that recommendation? The only reason I added insteadOf in the first place was because it sounded like a security improvement.

Bjorn

#10 lore raw
Quoted 12 lines · Bjorn Helgaas
Quoted 11 lines

You didn't really do anything wrong. In *general* I prefer to see public URLs if they are sent to public lists, so if you're cc'ing something to LKML, I would generally expect the pull request to have a public URL like https://git.kernel.org/ instead of a private ssh:// URL that is only accessible to people with a kernel.org account.

That's basically all there is to it. It doesn't *really* matter, since Linus is the one who will be merging the actual pull request, and he certainly has access to internal ssh:// URLs. However, in case someone else was interested in reviewing the pull request, it would be more friendly to have a public URL for them.

Quoted 4 lines

OK, I think I'll remove the insteadOf chunk from my .gitconfig. Should
https://korg.wiki.kernel.org/userdoc/gitolite be updated to remove or expand that recommendation? The only reason I added insteadOf in the first place was because it sounded like a security improvement.

It is. Does adding the insteadOf rules result in ssh:// URLs when using git-request-pull? I didn't expect that it would.

-K

#11 lore raw
Quoted 13 lines · Konstantin Ryabitsev
Quoted 12 lines · Bjorn Helgaas
Quoted 11 lines

You didn't really do anything wrong. In *general* I prefer to see public URLs if they are sent to public lists, so if you're cc'ing something to LKML, I would generally expect the pull request to have a public URL like https://git.kernel.org/ instead of a private ssh:// URL that is only accessible to people with a kernel.org account.

That's basically all there is to it. It doesn't *really* matter, since Linus is the one who will be merging the actual pull request, and he certainly has access to internal ssh:// URLs. However, in case someone else was interested in reviewing the pull request, it would be more friendly to have a public URL for them.

Quoted 7 lines
Quoted 4 lines

OK, I think I'll remove the insteadOf chunk from my .gitconfig. Should
https://korg.wiki.kernel.org/userdoc/gitolite be updated to remove or expand that recommendation? The only reason I added insteadOf in the first place was because it sounded like a security improvement.

It is. Does adding the insteadOf rules result in ssh:// URLs when using git-request-pull? I didn't expect that it would.

Yep, it seems to for me. Maybe I'm doing something else weird, because I don't see many other pull requests with ssh:// URLs.

#12 lore raw
Quoted 2 lines · Bjorn Helgaas

Yep, it seems to for me. Maybe I'm doing something else weird, because I don't see many other pull requests with ssh:// URLs.

So what I've done here is I've added a remote git repo using the *public* URL of my repo and so when I use git request-pull, I always point to the public one - I need to fetch the tag before, of course, but that's trivial - and then the URL is the public one.

I.e,

$ git request-pull master bp-pub <TAG>

This has the additional value of *actually* making sure I've really pushed the tag.

HTH.

Signature · 4 lines
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
#13 lore raw
In reply to Bjorn Helgaas
Quoted 10 lines · Bjorn Helgaas
Quoted 7 lines
Quoted 4 lines

OK, I think I'll remove the insteadOf chunk from my .gitconfig. Should
https://korg.wiki.kernel.org/userdoc/gitolite be updated to remove or expand that recommendation? The only reason I added insteadOf in the first place was because it sounded like a security improvement.

It is. Does adding the insteadOf rules result in ssh:// URLs when using git-request-pull? I didn't expect that it would.

Yep, it seems to for me. Maybe I'm doing something else weird, because I don't see many other pull requests with ssh:// URLs.

Hmm, you're right -- I just tested this and it does. I can't imagine that's the intended effect of insteadOf -- it's supposed to alter URLs behind the scenes, not permanently transform them. I'll talk to git folks about it.

For now, you should probably remove that from your gitconfig so that your pull requests have public URLs in them.

Best,
-K