diff for duplicates of <1371142157.2028.9@snotra> diff --git a/a/1.txt b/N1/1.txt index 5e20037..3983c9f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,16 +2,16 @@ On 06/13/2013 02:21:24 AM, Rojhalat Ibrahim wrote: > On Wednesday 12 June 2013 16:50:26 Scott Wood wrote: > > On 06/12/2013 03:19:30 AM, Rojhalat Ibrahim wrote: > > > On Tuesday 11 June 2013 12:28:59 Scott Wood wrote: -> > > > Yes, I figured it was non-PCIe because the code change that you =20 +> > > > Yes, I figured it was non-PCIe because the code change that you > said -> > > > helped was on the non-PCIe branch of the if/else. Generally =20 +> > > > helped was on the non-PCIe branch of the if/else. Generally > it's > > > > > > good > > > > > > > to explicitly mention the chip you're using, though. > > > > -> > > > fsl_setup_indirect_pci should be renamed to =20 +> > > > fsl_setup_indirect_pci should be renamed to > fsl_setup_indirect_pcie. > > > > Your patch above should be applied, and fsl_setup_indirect_pcie > > > @@ -23,13 +23,13 @@ On 06/13/2013 02:21:24 AM, Rojhalat Ibrahim wrote: > > > > > > > -Scott > > > -> > > How about this patch? It uses setup_indirect_pci for the PCI case =20 +> > > How about this patch? It uses setup_indirect_pci for the PCI case > in > > > mpc83xx_add_bridge. Additionally it adds a check in > > > fsl_setup_indirect_pci > > > to only use the modified read function in case of PCIe. > > -> > If we're adding the check to fsl_setup_indirect_pci, there's no =20 +> > If we're adding the check to fsl_setup_indirect_pci, there's no > need to > > change the 83xx call back to setup_indirect_pci. I see that 85xx is > > also callirng fsl_setup_indirect_pci for both; it'd be good to be @@ -39,29 +39,29 @@ On 06/13/2013 02:21:24 AM, Rojhalat Ibrahim wrote: > > message? > > > > -Scott ->=20 -> Where is it called for 85xx? As far as I can tell =20 +> +> Where is it called for 85xx? As far as I can tell > fsl_setup_indirect_pci is -> called exactly once in fsl_add_bridge and nowhere else (after =20 +> called exactly once in fsl_add_bridge and nowhere else (after > applying the > proposed patch). fsl_add_bridge() is where it's called for 85xx. > For 83xx the decision between PCI and PCIe has already been made at -> the point where the setup function is called. So IMO it doesn't make =20 +> the point where the setup function is called. So IMO it doesn't make > sense -> to call fsl_setup_indirect_pci and do the check again. Moreover PCIe =20 +> to call fsl_setup_indirect_pci and do the check again. Moreover PCIe > on 83xx > uses a completely different set of functions. -My concern is consistency. E.g. if 85xx is using =20 -fsl_setup_indirect_pci for both, but 83xx isn't, then a developer using =20 -83xx could end up breaking 85xx by introducing another PCIe dependency =20 -in fsl_setup_indirect_pci. Or an 85xx developer could put something =20 +My concern is consistency. E.g. if 85xx is using +fsl_setup_indirect_pci for both, but 83xx isn't, then a developer using +83xx could end up breaking 85xx by introducing another PCIe dependency +in fsl_setup_indirect_pci. Or an 85xx developer could put something non-PCIe-related in fsl_setup_indirect_pci that 83xx would benefit from. -Alternatively, you could call it fsl_setup_indirect_pcie, and move the =20 +Alternatively, you could call it fsl_setup_indirect_pcie, and move the PCIe check into fsl_add_bridge(). --Scott= +-Scott diff --git a/a/content_digest b/N1/content_digest index d6f1ccc..27ff646 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,25 +6,25 @@ "Subject\0Re: [BUG] PCI related panic on powerpc based board with 3.10-rcX\0" "Date\0Thu, 13 Jun 2013 11:49:17 -0500\0" "To\0Rojhalat Ibrahim <imr@rtschenk.de>\0" - "Cc\0linuxppc-dev@lists.ozlabs.org" - linux-kernel@vger.kernel.org - " Michael Guntsche <michael.guntsche@it-loops.com>\0" + "Cc\0Michael Guntsche <michael.guntsche@it-loops.com>" + <linuxppc-dev@lists.ozlabs.org> + " <linux-kernel@vger.kernel.org>\0" "\00:1\0" "b\0" "On 06/13/2013 02:21:24 AM, Rojhalat Ibrahim wrote:\n" "> On Wednesday 12 June 2013 16:50:26 Scott Wood wrote:\n" "> > On 06/12/2013 03:19:30 AM, Rojhalat Ibrahim wrote:\n" "> > > On Tuesday 11 June 2013 12:28:59 Scott Wood wrote:\n" - "> > > > Yes, I figured it was non-PCIe because the code change that you =20\n" + "> > > > Yes, I figured it was non-PCIe because the code change that you \n" "> said\n" - "> > > > helped was on the non-PCIe branch of the if/else. Generally =20\n" + "> > > > helped was on the non-PCIe branch of the if/else. Generally \n" "> it's\n" "> > >\n" "> > > good\n" "> > >\n" "> > > > to explicitly mention the chip you're using, though.\n" "> > > >\n" - "> > > > fsl_setup_indirect_pci should be renamed to =20\n" + "> > > > fsl_setup_indirect_pci should be renamed to \n" "> fsl_setup_indirect_pcie.\n" "> > > > Your patch above should be applied, and fsl_setup_indirect_pcie\n" "> > >\n" @@ -36,13 +36,13 @@ "> > >\n" "> > > > -Scott\n" "> > >\n" - "> > > How about this patch? It uses setup_indirect_pci for the PCI case =20\n" + "> > > How about this patch? It uses setup_indirect_pci for the PCI case \n" "> in\n" "> > > mpc83xx_add_bridge. Additionally it adds a check in\n" "> > > fsl_setup_indirect_pci\n" "> > > to only use the modified read function in case of PCIe.\n" "> >\n" - "> > If we're adding the check to fsl_setup_indirect_pci, there's no =20\n" + "> > If we're adding the check to fsl_setup_indirect_pci, there's no \n" "> need to\n" "> > change the 83xx call back to setup_indirect_pci. I see that 85xx is\n" "> > also callirng fsl_setup_indirect_pci for both; it'd be good to be\n" @@ -52,31 +52,31 @@ "> > message?\n" "> >\n" "> > -Scott\n" - ">=20\n" - "> Where is it called for 85xx? As far as I can tell =20\n" + "> \n" + "> Where is it called for 85xx? As far as I can tell \n" "> fsl_setup_indirect_pci is\n" - "> called exactly once in fsl_add_bridge and nowhere else (after =20\n" + "> called exactly once in fsl_add_bridge and nowhere else (after \n" "> applying the\n" "> proposed patch).\n" "\n" "fsl_add_bridge() is where it's called for 85xx.\n" "\n" "> For 83xx the decision between PCI and PCIe has already been made at\n" - "> the point where the setup function is called. So IMO it doesn't make =20\n" + "> the point where the setup function is called. So IMO it doesn't make \n" "> sense\n" - "> to call fsl_setup_indirect_pci and do the check again. Moreover PCIe =20\n" + "> to call fsl_setup_indirect_pci and do the check again. Moreover PCIe \n" "> on 83xx\n" "> uses a completely different set of functions.\n" "\n" - "My concern is consistency. E.g. if 85xx is using =20\n" - "fsl_setup_indirect_pci for both, but 83xx isn't, then a developer using =20\n" - "83xx could end up breaking 85xx by introducing another PCIe dependency =20\n" - "in fsl_setup_indirect_pci. Or an 85xx developer could put something =20\n" + "My concern is consistency. E.g. if 85xx is using \n" + "fsl_setup_indirect_pci for both, but 83xx isn't, then a developer using \n" + "83xx could end up breaking 85xx by introducing another PCIe dependency \n" + "in fsl_setup_indirect_pci. Or an 85xx developer could put something \n" "non-PCIe-related in fsl_setup_indirect_pci that 83xx would benefit from.\n" "\n" - "Alternatively, you could call it fsl_setup_indirect_pcie, and move the =20\n" + "Alternatively, you could call it fsl_setup_indirect_pcie, and move the \n" "PCIe check into fsl_add_bridge().\n" "\n" - -Scott= + -Scott -af0c85e061314faa9f94c9e7a8e0ec46dde0a2ba1a2f29b091972b39903068a9 +97eb74ff34c8ab7ed968cb9ddfeddddc6303fbd35ea4ed28a3ba043135fa75ae
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.