On Mon, Feb 18, 2019 at 08:38:52PM +0100, Heinrich Schuchardt wrote:
On 1/5/19 2:56 AM, Simon Glass wrote:
Hi Heinrich,
On Sun, 30 Dec 2018 at 01:33, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 12/29/18 2:39 PM, Simon Glass wrote:
Hi Heinrich,
On Wed, 26 Dec 2018 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
The 'exception' command allows to test exception handling.
This implementation supports ARM, x86, RISC-V and the following exceptions:
- 'breakpoint' - prefetch abort exception (ARM 32bit only)
- 'unaligned' - data abort exception (ARM only)
- 'undefined' - undefined instruction exception
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
v2: Split architecture specific code into separate files. Provide include for common code. Update MAINTAINERS file.
MAINTAINERS | 3 +++ cmd/Kconfig | 6 +++++ cmd/Makefile | 2 ++ cmd/arm/Makefile | 7 +++++ cmd/arm/exception.c | 61 +++++++++++++++++++++++++++++++++++++++++++ cmd/arm/exception64.c | 33 +++++++++++++++++++++++ cmd/riscv/Makefile | 3 +++ cmd/riscv/exception.c | 29 ++++++++++++++++++++ cmd/x86/Makefile | 1 + cmd/x86/exception.c | 29 ++++++++++++++++++++ include/exception.h | 58 ++++++++++++++++++++++++++++++++++++++++ 11 files changed, 232 insertions(+) create mode 100644 cmd/arm/Makefile create mode 100644 cmd/arm/exception.c create mode 100644 cmd/arm/exception64.c create mode 100644 cmd/riscv/Makefile create mode 100644 cmd/riscv/exception.c create mode 100644 cmd/x86/exception.c create mode 100644 include/exception.h
This needs something like Series-version: 2 (if you use patman) to set the version number in the header.
Sorry for the mishap.
Did you look at using a uclass and driver, like sysreset?
Yes I have considered using a u-class. But I could not see how adding a separate u-class file would save lines, make the coding less complex, or make the coding easier to maintain. A u-class would make sense if there were other consumers for exceptions but the exception command. But I cannot imagine any.
In some sense driver model matches consumers and producers. There are clearly multiple producers - you have effectively implemented an API in a few places. We even have multiple impls for each arch.
So I still favour a uclass, but since you are pretty adamant that we should not do it, I'm not going to insist.
Hello Tom,
in patchwork this patch is still in status 'NEW'.
It is unclear to me if you are going to merge it as is or if I should rework it.
I guess I hadn't made a decision here. I guess if you're really sure it doesn't need what Simon is suggesting, then yes, I'll pick this up as-is. Thanks!