Re: About PPTT find_acpi_cpu_topology_package()

[Sudeep Holla <sudeep.holla@arm.com>]

On Wed, Feb 12, 2020 at 02:41:04PM +0000, John Garry wrote:
> On 12/02/2020 13:55, Sudeep Holla wrote:
> > On Wed, Feb 12, 2020 at 12:48:33PM +0000, John Garry wrote:
> > > On 12/02/2020 11:59, Sudeep Holla wrote:
> >
> > [...]
> >
>
> Hi Sudeep,
>
> > > > Yes, as mentioned above. We are not going to do extra work for lazy firmware.
> > >
> > > I don't think it's reasonable to just label this as lazy. The table may just
> > > not have the flag set unintentionally. FW and software guys make mistakes,
> > > like the mistakes in PPTT, itself.
> > >
> >
> > We are not talking about flags, it's UID and it is pretty important if
> > there are more than one objects of same time.
> >
>
> I am talking about the Processor ID valid flag, which is specifically
> related.
>

Ah OK, sorry I had forgotten the specific. I recall it now.

> > > > Linux also will be lazy on such platform and provide weird unique numbers
> > > > like in the above case you have mentioned.
> > >
> > > Personally I think that the kernel can be do better than provide meaningless
> > > values like this, since it knows the processor IDs and which physical
> > > package they belong to.
> > >
> >
> > This was discussed quite a lot, I can dig and point you to it. That's the
> > reason for choosing offset. We are *not going back* to this again. Fix the
> > firmware before it gets copied for all future platforms and Linux has to
> > deal with that *forever*.
>
> I would liked to have been made aware earlier of the oversight. Quite often
> we only find problems when someone or something complains.
>

Agreed.

> It is a strange API to provide offsets like this, and I did not realize that
> they were actually being exposed to userspace.
>

We couldn't come up with something that produces same result always and
obtained from firmware data. Yes that being in the user-space was the main
concern for not generating it in the Linux as we can't guarantee to generate
same ID for a given physical socket. Depends on the order in which we boot
them or something similar.

> >
> > > If not, at least make the user know of potential deficiencies in the table.
> > >
> >
> > How ? What are your suggestions ? Does adding a warning or note that UID
> > is missing and offset is chosen help ?
>
> I'd say so. I know now, but let's save others the potential hassle. And
> having this debate again.
>

No argument there. I agree completely.

> I am kind of fine with that.
>
> How about something like this:
>

Looks good to me. Please post the patch. I am not sure on Rafael's
preference on such lengthy warnings(does it need to be split ?)

--
Regards,
Sudeep