diff options
author | David Woodhouse <dwmw2@infradead.org> | 2008-05-30 06:57:27 -0400 |
---|---|---|
committer | David Woodhouse <David.Woodhouse@intel.com> | 2008-07-10 09:47:36 -0400 |
commit | bacfe09dd7545467965e8d8f1eab20bc62dce00d (patch) | |
tree | 1f8b50e22439ef6d65089b3c5f875a6943b9c9df /include/linux/ihex.h | |
parent | 88ecf814c47f577248751ddbe9626d98aeef5783 (diff) |
ihex.h: binary representation of ihex records
Some devices need their firmware as a set of {address, len, data...}
records in some specific order rather than a simple blob.
The normal way of doing this kind of thing is 'ihex', which is a text
format and not entirely suitable for use in the kernel.
This provides a binary representation which is very similar, but much
more compact -- and a helper routine to skip to the next record,
because the alignment constraints mean that everybody will screw it up
for themselves otherwise.
Also a helper function which can verify that a 'struct firmware'
contains a valid set of ihex records, and that following them won't run
off the end of the loaded data.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Diffstat (limited to 'include/linux/ihex.h')
-rw-r--r-- | include/linux/ihex.h | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/include/linux/ihex.h b/include/linux/ihex.h new file mode 100644 index 000000000000..df89edd890ae --- /dev/null +++ b/include/linux/ihex.h | |||
@@ -0,0 +1,50 @@ | |||
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__ */ | ||