[Pdbg] [PATCH 2/7] libpdbg: Add pba hardware unit

[Amitay Isaacs]

On Mon, 2019-10-28 at 11:58 +1100, Alistair Popple wrote:
> On Thursday, 24 October 2019 12:48:42 PM AEDT Amitay Isaacs wrote:
> > Signed-off-by: Amitay Isaacs <amitay at ozlabs.org>
> > ---
> >  libpdbg/hwunit.h | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/libpdbg/hwunit.h b/libpdbg/hwunit.h
> > index 06e5fca..8d2a55f 100644
> > --- a/libpdbg/hwunit.h
> > +++ b/libpdbg/hwunit.h
> > @@ -65,6 +65,13 @@ struct mem {
> >  };
> >  #define target_to_mem(x) container_of(x, struct mem, target)
> >  
> > +struct pba {
> 
> This is an implementation of the memory interface/class so it should
> be 
> implemented as a struct mem interface rather than introducing another
> class as 
> it is accessing the same thing (ie. system memory) just via a
> different method.
> 
> See for example the way sbefifo-mem is implemented.

Yes, I thought about treating them as yet another mem class instance,
but then we don't have a way of clearly differentiating between two
instances of mem class and selecting the appropriate one.

If you want to treat them as the same class, then we need to add
alternate methods (e.g. read_pba) to the hwunit.  Users should not have
to worry about choosing the appropriate target (mem0-proc vs mem0-pba)
for a particuar access method.  That seems counter-intuitive.

> 
> > +	struct pdbg_target target;
> > +	int (*read)(struct pba *, uint64_t, uint8_t *, uint64_t,
> > uint8_t, bool);
> > +	int (*write)(struct pba *, uint64_t, uint8_t *, uint64_t,
> > uint8_t, bool);
> > +};
> > +#define target_to_pba(x) container_of(x, struct pba, target)
> > +
> >  struct sbefifo {
> >  	struct pdbg_target target;
> >  	int (*istep)(struct sbefifo *, uint32_t major, uint32_t minor);
> > 
> 
> 
> 

Amitay.
-- 

I'd like to be rich enough so I could throw soap away after the letters are
worn off. - Andy Rooney