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. > We really should macroise this up a bit better, like Linux does: > /* Some drivers don't use the struct amba_device */ > #define AMBA_CONFIG_BITS(a) (((a) >> 24) & 0xff) > #define AMBA_REV_BITS(a) (((a) >> 20) & 0x0f) > #define AMBA_MANF_BITS(a) (((a) >> 12) & 0xff) > #define AMBA_PART_BITS(a) ((a) & 0xfff) > > #define amba_config(d) AMBA_CONFIG_BITS((d)->periphid) > #define amba_rev(d) AMBA_REV_BITS((d)->periphid) > #define amba_manf(d) AMBA_MANF_BITS((d)->periphid) > #define amba_part(d) AMBA_PART_BITS((d)->periphid) > > (after proper extraction of the 32-bit value from the 4 registers of > course) > > Amusingly, the Linux driver ignores pretty much everything, and > accepts any primecell with ARM as designer. > Opens up for cute devicetree hacks, I guess... > As I said, I don't care deeply. If part and manufacturer is sufficient, then let's drop the other bits _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
