Attention is currently required from: Felix Singer, Edward O'Callaghan.
4 comments:
Commit Message:
I'm missing the reason for the change. Especially because some
aspects regress. Programmers that register multiple masters would
need redundant code.
It also seems unclear if it would help with the `programmer` global
issue. There are more complex programmer drivers that most likely
have global state that isn't associated with a specific master. This
state needs a place eventually and moving everything into the masters
might not work out well.
Looking at the libflashrom API, we currently have a `flashctx` at
the chip level. This points to a master which gets us most of the
state, but not all of it yet. One way would be to extend this chain,
i.e. let the master point to a programmer context (something like
`struct programmer` + state), and that to a libflashrom context (to
be introduced into the API).
File flashrom.c:
Patch Set #4, Line 219: flash->mst->buses_supported & BUS_SPI
In case of multiple buses, this is not necessarily the bus that the flash
chip is connected to. I'm not sure if we store that information somewhere
in the `flashctx` yet.
Patch Set #4, Line 224: flash->mst->par.delay(usecs);
This could probably be better solved by having a common master struct,
e.g. common things behind `flash->mst` and there something like
`flash->mst->bus` that points to the bus specific things (the current
`flash->mst`).
File serprog.c:
We would need the delay here too, right? (rhetorical, see comment on
commit message)
To view, visit change 67393. To unsubscribe, or for help writing mail filters, visit settings.