On Tue, Mar 01, 2016 at 10:40:53AM +0100, Ard Biesheuvel wrote:
> On 1 March 2016 at 10:36, Leif Lindholm <[email protected]> wrote:
> > On Tue, Mar 01, 2016 at 09:39:18AM +0100, Ard Biesheuvel wrote:
> >> >> As far as the Primecell ID is concerned, let's just whitelist whatever
> >> >> TC2 exposes, even if in error.
> >> >
> >> > You mean rather than mask the "stuck bit", specifically check if the
> >> > register is 0 or 2? (Where 2 is added as a #define to the header).
> >>
> >> I don't care deeply either way, but supporting the documented and the
> >> actual ID explicitly seems more correct, unless the difference is in
> >> the revision field?
> >
> > So ... PeriphID3 holds the "Configuration" bits, so in any case, they
> > would be irrelevant for identification.
>
> Well, the problem is not what they are called, it is what the
> refmanual of the IP block explicitly states its value can be expected
> to be.
Yes, and the public documentation found in the obvious place is not
for the part actually used on the platform, or at least not for the
same revision. More recent ARM documents tend to be less confusing on
which fields may be revision-sensitive or not.
The point is that the "configuration" bits have no bearing on which
component it is, they merely indicate implementation-time decisions
(things like configurable fifo depths, inclusion of randomly bolted
onto the side GPIO block, ...). These are not even necessarily
software-visible, and the lack of interest on behalf of the Linux
driver suggests this is the case here.
/
Leif
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
