| 49cad547 | 26-Jan-2015 |
Martin Dorwig <dorwig@tetronik.com> |
Export redesign
this is an atempt to make the export of functions typesafe.
I replaced the jumptable void ** by a struct (jt_funcs) with function pointers.
The EXPORT_FUNC macro now has 3 fixed para
Export redesign
this is an atempt to make the export of functions typesafe.
I replaced the jumptable void ** by a struct (jt_funcs) with function pointers.
The EXPORT_FUNC macro now has 3 fixed parameters and one
variadic parameter
The first is the name of the exported function,
the rest of the parameters are used to format a functionpointer
in the jumptable,
the EXPORT_FUNC macros are expanded three times,
1. to declare the members of the struct
2. to initialize the structmember pointers
3. to call the functions in stubs.c
Signed-off-by: Martin Dorwig <dorwig@tetronik.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(resending to the list since my tweaks are not quite trivial)
show more ...
|
| 9cc36a2b | 25-Jan-2015 |
Simon Glass <sjg@chromium.org> |
dm: core: Add a flag to control sequence numbering
At present we try to use the 'reg' property and device tree aliases to give
devices a sequence number. The 'reg' property is often actually a memor
dm: core: Add a flag to control sequence numbering
At present we try to use the 'reg' property and device tree aliases to give
devices a sequence number. The 'reg' property is often actually a memory
address, so the sequence numbers thus-obtained are not useful. It would be
better if the devices were just sequentially numbered in that case. In fact
neither I2C nor SPI use this feature, so drop it.
Some devices need us to look up an alias to number them within the uclass.
Add a flag to control this, so it is not done unless it is needed.
Adjust the tests to test this new behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
show more ...
|
| 5cfc662c | 06-Jan-2015 |
Simon Glass <sjg@chromium.org> |
dm: tegra: Bring in GPIO device tree binding
At present the tegra GPIO driver does not fully support the existing device
tree binding, but add the binding file to cover the existing partial support.
dm: tegra: Bring in GPIO device tree binding
At present the tegra GPIO driver does not fully support the existing device
tree binding, but add the binding file to cover the existing partial support.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 35ea1bfd | 06-Jan-2015 |
Simon Glass <sjg@chromium.org> |
dm: exynos: Bring in GPIO device tree binding
At present the exynos GPIO driver does not fully support the existing device
tree binding, but add the binding file to cover the existing partial suppor
dm: exynos: Bring in GPIO device tree binding
At present the exynos GPIO driver does not fully support the existing device
tree binding, but add the binding file to cover the existing partial support.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 37b608a5 | 22-Jan-2015 |
Masahiro Yamada <yamada.m@jp.panasonic.com> |
powerpc: remove icecube_5200, Lite5200, cpci5200, mecp5200, pf5200
These boards are still non-generic boards.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denk <wd@denx.d
powerpc: remove icecube_5200, Lite5200, cpci5200, mecp5200, pf5200
These boards are still non-generic boards.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
show more ...
|