On Fri, Feb 20, 2015 at 01:34:16PM +0000, Julien Grall wrote: > On 20/02/15 12:35, Ian Campbell wrote: > > On Fri, 2015-01-30 at 18:49 +0000, Julien Grall wrote: > >> From: Andreas Herrmann <andreas.herrm...@calxeda.com> > >> > >> If DT information lists one stream ID twice for the master devices of > >> an SMMU this can cause a multi match when stream ID matching is used. > >> For stream ID indexing this might trigger an overwrite of an S2CR that > >> is already in use. > >> > >> So better check for duplicates when DT information is parsed. > >> > >> Taken from the linux ML: > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html > >> > >> Cc: Andreas Herrmann <herrmann.der.u...@googlemail.com> > >> Signed-off-by: Andreas Herrmann <andreas.herrm...@calxeda.com> > >> Signed-off-by: Julien Grall <julien.gr...@linaro.org> > > > > I think you were going to drop this one as it is not strictly required? > > > > I'm still not entirely clear on the motivation for this patch, looking > > at the v2 thread I see "But, the developer made have written by mistake > > twice the streamid for the device." which I think you were saying that > > the DT might, hypothetically, be wrong and have duplicated IDs, is that > > right? > > > > Is it a hypothetical problem or have we seen it in a real device-tree? > > It's an hypothetical problem. The algo on the next patch won't work > correctly otherwise.
Seconded -- this patch is to avoid potential problems if the DT information is bogus. As the algorithm of the other patch assumes there are no duplicate streamids I needed to double-check it. Of course I had created special DTs containing this kind of error to test the check. > I may need to rework a bit the next patch if we drop it. I think it's easier to keep the check when DT information is gathered. Alternative would be to drop it and to be prepared for potential bug reports about multi-match errors or random other problems in case of an overwrite of an already configured S2CR. Andreas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
