diff for duplicates of <5615B4BA.2060002@intel.com> diff --git a/a/1.txt b/N1/1.txt index 90ba0f6..135e53f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -9,23 +9,23 @@ On 10/6/2015 1:08 PM, David Woodhouse wrote: > prefix is not officially assigned but that's really a trivial piece of > bureaucracy. > ->> I guess it?s up to Catalin, but disabling for ARM seems like a good idea +>> I guess it¹s up to Catalin, but disabling for ARM seems like a good idea >> right now, another option is to add tests to FWTS. > I understand the motivation to avoid embracing a whole bunch of crappy > bindings. But I think that eschewing PRP0001 is the wrong technical > approach to achieving that. > -> It has false negatives ? as soon as you have a *single* existing DT +> It has false negatives — as soon as you have a *single* existing DT > binding, perhaps something as simple as the serial port bindings from > the CHRP days, you'll be in a situation where you can't use that. > I've *got* hardware where I need to advertise a serial port with a > clock-frequency property because it *isn't* compatible with PNP0501. > -> And it has false positives ? there's nothing to prevent people from +> And it has false positives — there's nothing to prevent people from > doing ACPI-style bindings with crappy device bindings which also aren't > approved. > -> I think it's utterly na?ve to believe that simply avoiding the use of +> I think it's utterly naïve to believe that simply avoiding the use of > PRP0001 + compatible for matching is going to have *any* significant > beneficial effect whatsoever. It only makes life harder for all > concerned. @@ -34,7 +34,7 @@ On 10/6/2015 1:08 PM, David Woodhouse wrote: > CONFIG_UNAPPROVED_BINDINGS (which can't be set on ARM64), and those > drivers which use bindings that *aren't* approved by Catalin's crack > team of reviewers need to depend on !UNAPPROVED_BINDINGS. To be honest, -> I still think even *that* is somewhat na?ve, but it's still a better +> I still think even *that* is somewhat naïve, but it's still a better > way of implementing what you're actually trying to achieve, however > optimistic you have to be to think it'll ever work in practice. > diff --git a/a/content_digest b/N1/content_digest index 87e5391..c6fe5c8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,10 +12,20 @@ "ref\0560C993D.8090308@redhat.com\0" "ref\0D23813FF.33566%charles.garcia-tobin@arm.com\0" "ref\01444129723.4674.236.camel@infradead.org\0" - "From\0rafael.j.wysocki@intel.com (Rafael J. Wysocki)\0" - "Subject\0[PATCH 2/2] Convert smsc911x to use ACPI as well as DT\0" + "From\0Rafael J. Wysocki <rafael.j.wysocki@intel.com>\0" + "Subject\0Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT\0" "Date\0Thu, 8 Oct 2015 02:11:38 +0200\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0David Woodhouse <dwmw2@infradead.org>" + " Charles Garcia-Tobin <charles.garcia-tobin@arm.com>\0" + "Cc\0ahs3@redhat.com <ahs3@redhat.com>" + Catalin Marinas <Catalin.Marinas@arm.com> + steve.glendinning@shawell.net <steve.glendinning@shawell.net> + netdev@vger.kernel.org <netdev@vger.kernel.org> + Jeremy Linton <Jeremy.Linton@arm.com> + hanjun.guo@linaro.org <hanjun.guo@linaro.org> + suravee.suthikulpanit@amd.com <suravee.suthikulpanit@amd.com> + grant.likely@linaro.org <grant.likely@linaro.org> + " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0" "\00:1\0" "b\0" "On 10/6/2015 1:08 PM, David Woodhouse wrote:\n" @@ -29,23 +39,23 @@ "> prefix is not officially assigned but that's really a trivial piece of\n" "> bureaucracy.\n" ">\n" - ">> I guess it?s up to Catalin, but disabling for ARM seems like a good idea\n" + ">> I guess it\302\271s up to Catalin, but disabling for ARM seems like a good idea\n" ">> right now, another option is to add tests to FWTS.\n" "> I understand the motivation to avoid embracing a whole bunch of crappy\n" "> bindings. But I think that eschewing PRP0001 is the wrong technical\n" "> approach to achieving that.\n" ">\n" - "> It has false negatives ? as soon as you have a *single* existing DT\n" + "> It has false negatives \342\200\224 as soon as you have a *single* existing DT\n" "> binding, perhaps something as simple as the serial port bindings from\n" "> the CHRP days, you'll be in a situation where you can't use that.\n" "> I've *got* hardware where I need to advertise a serial port with a\n" "> clock-frequency property because it *isn't* compatible with PNP0501.\n" ">\n" - "> And it has false positives ? there's nothing to prevent people from\n" + "> And it has false positives \342\200\224 there's nothing to prevent people from\n" "> doing ACPI-style bindings with crappy device bindings which also aren't\n" "> approved.\n" ">\n" - "> I think it's utterly na?ve to believe that simply avoiding the use of\n" + "> I think it's utterly na\303\257ve to believe that simply avoiding the use of\n" "> PRP0001 + compatible for matching is going to have *any* significant\n" "> beneficial effect whatsoever. It only makes life harder for all\n" "> concerned.\n" @@ -54,7 +64,7 @@ "> CONFIG_UNAPPROVED_BINDINGS (which can't be set on ARM64), and those\n" "> drivers which use bindings that *aren't* approved by Catalin's crack\n" "> team of reviewers need to depend on !UNAPPROVED_BINDINGS. To be honest,\n" - "> I still think even *that* is somewhat na?ve, but it's still a better\n" + "> I still think even *that* is somewhat na\303\257ve, but it's still a better\n" "> way of implementing what you're actually trying to achieve, however\n" "> optimistic you have to be to think it'll ever work in practice.\n" ">\n" @@ -95,4 +105,4 @@ "Thanks,\n" Rafael -89ef0dbf926da2e0a3a8ead145e509f02ffe3fb3741436e2a5a93b7b9a753d7e +1768a4b93192b58b15e6c2b9b9a5a6a919861c3ac042fb1ddd51be315a8b718e
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.