Messages in this thread | | | Date | Sat, 25 May 2013 21:25:51 +0200 | From | Oliver Schinagl <> | Subject | Re: [PATCH 1/2] Initial support for Allwinner's Security ID fuses |
| |
On 05/25/13 14:22, Maxime Ripard wrote: > Hi Oliver, > > On Fri, May 24, 2013 at 11:50:38PM +0200, Oliver Schinagl wrote: >> On 05/18/13 19:19, Oliver Schinagl wrote: >> <snip> >>>>> + >>>>> + >>>>> +/* We read the entire key, using a look up table. Returned is only the >>>>> + * requested byte. This is of course slower then it could be and uses 4 times >>>>> + * more reads as needed but keeps code a little simpler. >>>>> + */ >>>>> +u8 sunxi_sid_read_byte(const int key) >>>>> +{ >>>>> + u32 sid_key; >>>>> + u8 ret; >>>>> + >>>>> + ret = 0; >>>>> + if (likely((key <= SUNXI_SID_SIZE))) { >>>>> + sid_key = ioread32(p->sid_base + keys_lut[key >> 2]); >>>>> + switch (key % 4) { >>>>> + case 0: >>>>> + ret = (sid_key >> 24) & 0xff; >>>>> + break; >>>>> + case 1: >>>>> + ret = (sid_key >> 16) & 0xff; >>>>> + break; >>>>> + case 2: >>>>> + ret = (sid_key >> 8) & 0xff; >>>>> + break; >>>>> + case 3: >>>>> + ret = sid_key & 0xff; >>>>> + break; >>>>> + } >>>>> + } >>>> >>>> Come on, you can do better. This lookup table is useless. >>> I didn't want to depend on the fixed layout of memory, but consider it >>> removed. >> But i'm not smart enough :p >> >> We can either use the look up table (which does have benefits as its >> potentially more future proof), or do some ((key >> 2) << 2) to >> 'drop' the LSB's that we want to ignore (unless there's some smarter >> way). >> >> Personally, I think the LUT is a little cleaner and more readable, >> but I guess if you look at poor efficiency, the lut costs some >> memory, the left/right shift cost an additional >> 2 ... what you >> prefer. > > What about: > > val = ioread32be(base + (key / 4)); > val >>= (key % 4) * 8; > return val & 0xff; > > No lookup table, no weird swich statement, and you get the endianness > conversion only when you need it. Ok I think I like the Endianess, ioread32be does the right thing then? I'll read up on that. As for key / 4; how will that work without the lut?
Lets take byte 14 (out of the available 16). Byte 14 (0x0e) is located in SID_KEY3, so base + 0x0c. We need to write a whole 32bit word to keep with alignment, the registers go wakko if you do unaligned reads. So we need to read the entire 32 bits, then find our byte.
key / 4 for 14 yields 0x03. So we have base + 0x03, which is not what we want. We want base + 0x0c, which is either ((key >> 2) << 2)) Or, ((key / 4) * 4)) which to me, are both equally confusing. So we either use the look up table, which is a little cleaner and is a bit more future proof if either a) there's more 'eeprom like' storage which can be combined herein or b) 'a' next version has non-continuing regions. Granted neither is something to worry about right now.
Turl already mentioned the calculated shift, instead of the switch. I agree to also like it better and have already rewritten that bit.
If I made a really stupid thinking mistake or my math is somehow wrong, feel free to point it out :) I don't mind manning up to my mistakes :) > > Maxime >
| |