Thanks for your reply.
Ok, I have implemented what I think is a clean fix until the new framework
will be ready.
To avoid the libethdrivers to directly accessing the 'priv' field of the
mux_sys->priv, I have added one more function to the mux_sys API:
mux_sys_get_vaddr() that simply returns the vaddr of the mapped MUXC. I
have then extended the size of the area mapped to include the entire 16Kb
of the MUXC.
Then the libethdriver now uses the mux_sys_valid to check if the mux is
available, and if so, used it to retrieve the vaddr of the MUXC. If not it
proceed by privately mapping & unmapping the MUX when it's done.
My changes are in pull request #16:
I have tested it on my build and it works.
On Wed, Jul 4, 2018 at 9:38 PM, <Kofidoku.Atuah(a)data61.csiro.au> wrote:
Hey Fabrizio, I'm sorry we took so long to get
back to you:
The underlying problem here is that we haven't yet finished defining and
implementing a driver framework for our userspace code, so in order to
satisfy dependencies, we began stuffing them into the io_ops struct. So
since lots of devices depend on an initialized mux driver, what you see
here is the result of that, unfortunately -- the good news is that we're
currently defining a driver framework internally (
is one of
the draft pages of documentation -- but none of this is finalized) over the
course of this year.
What I'd recommend is that you use the helper function, mux_sys_valid() in
libplatsupport/arch_include/arm/platsupport/mux.h#L35) inside of the
ethernet driver, and map the whole 16K range inside of the IO-Ops
initializer -- essentially what's going on there is that there's a
dependency on the mux driver that's satisfied by the IO-Ops object.
Thanks very much for your patience, and this sort of thing should be
cleaned up soon.
Kofi Doku Atuah
DATA61 | CSIRO
Devel mailing list