diff for duplicates of <521B6AF3.9070909@keymile.com> diff --git a/a/1.txt b/N1/1.txt index 2d28097..bfb43a5 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -54,8 +54,8 @@ offline right now... :-( > It's been quite some time that I've actually tested that, but it used to > work properly. What you basically need to do is represent the whole bus > hierarchy within the DT. In the above example there's the top-level root -> port (pci at 1,0), which provides a bus (1) on which there's a switch named -> pci at 0,0. That switch provides another bus (2) on which more devices are +> port (pci@1,0), which provides a bus (1) on which there's a switch named +> pci@0,0. That switch provides another bus (2) on which more devices are > listed (pci@[012345],0). Those are all downstream ports providing > separate busses again and have a single device attached to them. > @@ -68,7 +68,7 @@ for? I assume if the output of a plain (i.e. no params) 'lspci' is bb:dd.f (bus:device.function) -I should only have a "pci at dd,f" node, with the bus numbering being +I should only have a "pci@dd,f" node, with the bus numbering being imposed by the hierarchy after an actual probing, right? So the actual bus number is never listed in the device tree (whereas the "@device,function" is). Is that right? @@ -85,10 +85,10 @@ So the actual bus number is never listed in the device tree (whereas the >> Is that also what you mean? > > Yes. In the example above you'll see that there's actually a GPIO -> controller (pci at 1,0/pci at 0,0/pci at 2,0/pci at 0,0), so you could simply +> controller (pci@1,0/pci@0,0/pci@2,0/pci@0,0), so you could simply > associate a phandle with it, as in: > -> gpioext: pci at 0,0 { +> gpioext: pci@0,0 { > ... > }; > diff --git a/a/content_digest b/N1/content_digest index fad98c3..83e03fb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,10 +6,20 @@ "ref\020130809140140.GA14990@ulmo\0" "ref\0521B1F6A.1090304@keymile.com\0" "ref\020130826120200.GA15842@ulmo\0" - "From\0gerlando.falauto@keymile.com (Gerlando Falauto)\0" - "Subject\0pci-mvebu driver on km_kirkwood\0" + "From\0Gerlando Falauto <gerlando.falauto@keymile.com>\0" + "Subject\0Re: pci-mvebu driver on km_kirkwood\0" "Date\0Mon, 26 Aug 2013 16:49:23 +0200\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Thierry Reding <thierry.reding@gmail.com>\0" + "Cc\0Thomas Petazzoni <thomas.petazzoni@free-electrons.com>" + Longchamp + Valentin <Valentin.Longchamp@keymile.com> + Jason Cooper <jason@lakedaemon.net> + devicetree@vger.kernel.org <devicetree@vger.kernel.org> + Jason Gunthorpe <jgunthorpe@obsidianresearch.com> + Andrew Lunn <andrew@lunn.ch> + Ezequiel Garcia <ezequiel.garcia@free-electrons.com> + linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org> + " Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>\0" "\00:1\0" "b\0" "Hi Thierry,\n" @@ -68,8 +78,8 @@ "> It's been quite some time that I've actually tested that, but it used to\n" "> work properly. What you basically need to do is represent the whole bus\n" "> hierarchy within the DT. In the above example there's the top-level root\n" - "> port (pci at 1,0), which provides a bus (1) on which there's a switch named\n" - "> pci at 0,0. That switch provides another bus (2) on which more devices are\n" + "> port (pci@1,0), which provides a bus (1) on which there's a switch named\n" + "> pci@0,0. That switch provides another bus (2) on which more devices are\n" "> listed (pci@[012345],0). Those are all downstream ports providing\n" "> separate busses again and have a single device attached to them.\n" ">\n" @@ -82,7 +92,7 @@ "\n" "bb:dd.f (bus:device.function)\n" "\n" - "I should only have a \"pci at dd,f\" node, with the bus numbering being \n" + "I should only have a \"pci@dd,f\" node, with the bus numbering being \n" "imposed by the hierarchy after an actual probing, right?\n" "So the actual bus number is never listed in the device tree (whereas the \n" "\"@device,function\" is). Is that right?\n" @@ -99,10 +109,10 @@ ">> Is that also what you mean?\n" ">\n" "> Yes. In the example above you'll see that there's actually a GPIO\n" - "> controller (pci at 1,0/pci at 0,0/pci at 2,0/pci at 0,0), so you could simply\n" + "> controller (pci@1,0/pci@0,0/pci@2,0/pci@0,0), so you could simply\n" "> associate a phandle with it, as in:\n" ">\n" - "> \tgpioext: pci at 0,0 {\n" + "> \tgpioext: pci@0,0 {\n" "> \t\t...\n" "> \t};\n" ">\n" @@ -131,4 +141,4 @@ "Thanks!\n" Gerlando -815219d13c7fd7342254c11d119d23e8cbebf55a22f12d7372a3472d5ff05c28 +5fa1fd18b3e523c7267b387df62ba9291e4a4621d964aa5029efdfc6349f0807
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.