[PATCH v2 4/5] drivers/mailbox: Add aspeed ast2400/ast2500 mbox driver

[Andrew Jeffery]

On Tue, 2017-01-10 at 11:07 +1100, Cyril Bur wrote:
> On Tue, 2017-01-10 at 09:25 +1030, Andrew Jeffery wrote:
> > On Tue, 2017-01-10 at 09:09 +1100, Cyril Bur wrote:
> > > On Sun, 2017-01-08 at 15:45 -0600, Benjamin Herrenschmidt wrote:
> > > > On Tue, 2017-01-03 at 11:54 +1030, Andrew Jeffery wrote:
> > > > > > > I think we should rename the IOCTL as what we do below
> > > > > > > doesn't
> > > > > > > necessarily raise an interrupt.
> > > > > > >  
> > > > > > 
> > > > > >  
> > > > > > Agreed, taking unput :). ASPEED_MBOX_IOCTL_WRITE_BYTE ?
> > > > > 
> > > > > That suggestion works for me.
> > > 
> > > Sorry about the blank one, I'll try typing something this time.
> > > 
> > > > If we are going to do that, maybe we should make this a write()
> > > > at a specific lpos...
> > > > 
> > > 
> > > Andrew, Joel what do you think of this, a write of count 1 at a
> > > specific pos. I like this since it removes ioctls all together
> > > and
> > > isn't any harder for userspace.
> > 
> > I'm in favour of removing the ioctl. So the logic would be:
> > 
> > 1. If lpos is zero, assume a MBOX_NUM_DATA_REGS-sized write as we
> > do
> > currently
> > 2. If lpos is non-zero, assume a single byte write
> > 
> 
> Ok so I started writing it - and I thought myself, wait why limit to
> single byte writes of lpos is non-zero... I mean, they can do what
> they
> want... what if they want to update two consequtive bytes, it seems
> silly to have to require two write()s to do that no?

Sure, that was predicated on not checking count. Which was partly what
the question below was about. If we check count then I don't see why
there would need to be constraints beyond the number of mailbox data
registers.

> 
> > On that, should we be testing the assumptions about buffer sizes?
> > Currently we don't (we use the MBOX_NUM_DATA_REGS rather than
> > count).
> > 
> > Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170110/ac65926e/attachment.sig>