[Skiboot] [PATCH v8 05/11] xscoms: read/write xscoms using ucall

[Ryan Grimm]

On Fri, 2020-08-28 at 14:50 +1000, Oliver O'Halloran wrote:
> > diff --git a/include/xscom.h b/include/xscom.h
> > index bd8bb89a..67a845fd 100644
> > --- a/include/xscom.h
> > +++ b/include/xscom.h
> > @@ -7,6 +7,7 @@
> >  #include <stdint.h>
> >  #include <processor.h>
> >  #include <cpu.h>
> > +#include <ultravisor.h>
> > 
> >  /*
> >   * SCOM "partID" definitions:
> > @@ -174,9 +175,13 @@ extern void _xscom_unlock(void);
> >  /* Targeted SCOM access */
> >  static inline int xscom_read(uint32_t partid, uint64_t pcb_addr,
> > uint64_t *val)
> >  {
> > +       if (uv_present)
> > +               return uv_xscom_read(partid, pcb_addr, val);
> >         return _xscom_read(partid, pcb_addr, val, true);
> >  }
> >  static inline int xscom_write(uint32_t partid, uint64_t pcb_addr,
> > uint64_t val) {
> > +       if (uv_present)
> > +               return uv_xscom_write(partid, pcb_addr, val);
> >         return _xscom_write(partid, pcb_addr, val, true);
> >  }
> 
> This should probably go into __xscom_write() since it'll break
> emulated scoms that we use for the OCMBs addresses on swift and P10.
> The UV would also need to support that, but I have some patches to
> use
> the xscom API to access other register spaces (e.g. PHB IODA tables)
> which this would also break.
> 

Does the attached patch look OK?  I stuck it in the __xscom functions
after the function checks the gcid.

-Ryan

> > 
> > 
> > _______________________________________________
> > Skiboot mailing list
> > Skiboot at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/skiboot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-xscoms-read-write-xscoms-using-ucall.patch
Type: text/x-patch
Size: 2759 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20200908/2ce9bf68/attachment.bin>