Re: [Xen-devel] [PATCH] ACPICA: ACPI 6.0: Add support for IORT table.

[Julien Grall <julien.grall@xxxxxxx>]

Hi Jan,

On 23/02/17 15:02, Jan Beulich wrote:
> > > > On 23.02.17 at 14:59, <julien.grall@xxxxxxx> wrote:
> > On 23/02/17 07:39, Jan Beulich wrote:
> > > > > > On 22.02.17 at 21:29, <sgoel@xxxxxxxxxxxxxx> wrote:
> > > > Appreciate the feedback. I want to use these defines for parsing out SMMUv3
> > > > components defined in ACPI. Since, I am picking these defines directly from
> > > > Linux, I did not want to make this a part of a newly developed patch set.
> > > What's wrong with the patch here being part of a patch set, allowing
> > > reviewers to understand context?
> > The IORT will be used to retrieve information to configure different
> > drivers (ITS and SMMUs). All the drivers don't have dependency between
> > each other but the IORT. As they will be contributed by different
> > stakeholders, it would be good to get this header checked-in in Xen as
> > soon as possible to have a common ground for adding drivers.
> >
> > Ideally, I would like to see the IORT parsing going at the same time as
> > this header. So everyone could re-use it without having to depend on
> > unrelated series.
> Well, you basically confirm that the header on its own isn't of much
> use - you want parsing code to go in at the same time. That is what
> I'm asking for: Have some user of the new definitions to allow seeing
> context of what they are needed for.
I don't think the parsing is strictly necessary to have it at first, 
hence why I said ideally.
The IORT is clearly defined in the spec ([1]), so I don't see any risk 
to accept this header before hand. The benefits is we can get people 
starting to write code using IORT either for parsing or generating it.
Cheers,

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel