David Woodhouse | bacfe09 | 2008-05-30 13:57:27 +0300 | [diff] [blame^] | 1 | /* |
| 2 | * Compact binary representation of ihex records. Some devices need their |
| 3 | * firmware loaded in strange orders rather than a single big blob, but |
| 4 | * actually parsing ihex-as-text within the kernel seems silly. Thus,... |
| 5 | */ |
| 6 | |
| 7 | #ifndef __LINUX_IHEX_H__ |
| 8 | #define __LINUX_IHEX_H__ |
| 9 | |
| 10 | #include <linux/types.h> |
| 11 | #include <linux/firmware.h> |
| 12 | |
| 13 | /* Intel HEX files actually limit the length to 256 bytes, but we have |
| 14 | drivers which would benefit from using separate records which are |
| 15 | longer than that, so we extend to 16 bits of length */ |
| 16 | struct ihex_binrec { |
| 17 | __be32 addr; |
| 18 | __be16 len; |
| 19 | uint8_t data[0]; |
| 20 | } __attribute__((aligned(4))); |
| 21 | |
| 22 | /* Find the next record, taking into account the 4-byte alignment */ |
| 23 | static inline const struct ihex_binrec * |
| 24 | ihex_next_binrec(const struct ihex_binrec *rec) |
| 25 | { |
| 26 | int next = ((be16_to_cpu(rec->len) + 5) & ~3) - 2; |
| 27 | rec = (void *)&rec->data[next]; |
| 28 | |
| 29 | return be16_to_cpu(rec->len) ? rec : NULL; |
| 30 | } |
| 31 | |
| 32 | /* Check that ihex_next_binrec() won't take us off the end of the image... */ |
| 33 | static inline int ihex_validate_fw(const struct firmware *fw) |
| 34 | { |
| 35 | const struct ihex_binrec *rec; |
| 36 | size_t ofs = 0; |
| 37 | |
| 38 | while (ofs <= fw->size - sizeof(*rec)) { |
| 39 | rec = (void *)&fw->data[ofs]; |
| 40 | |
| 41 | /* Zero length marks end of records */ |
| 42 | if (!be16_to_cpu(rec->len)) |
| 43 | return 0; |
| 44 | |
| 45 | /* Point to next record... */ |
| 46 | ofs += (sizeof(*rec) + be16_to_cpu(rec->len) + 3) & ~3; |
| 47 | } |
| 48 | return -EINVAL; |
| 49 | } |
| 50 | #endif /* __LINUX_IHEX_H__ */ |