[PATCH V2 0/3] Add vchi_queue_kernel_message and vchi_queue_user_message

[Michael Zoran]

On Wed, 2017-01-25 at 06:23 -0800, Michael Zoran wrote:
> On Wed, 2017-01-25 at 17:12 +0300, Dan Carpenter wrote:
> > > Again, that's not my decision.  I can go either way.  But if the
> > > decision was made to delete it, I think the 4.10 version should
> > > also be
> > > deleted because the same logic applies.  Nothing uses it 4.10
> > > either
> > > and 4.10 is still an RC.
> > 
> > Nah.  No rush.  We can delete it in another kernel release or two
> > if
> > we
> > can't figure out the issue.
> > 
> > Let's first figure out why the other code hasn't been upstreamed. 
> > You
> > must have at least looked at it to be sending these patches.  Do
> > you
> > know what the story is?
> 
> No, not really.  Some of it may simply be that nobody has taken the
> time to upstream them.
> 
> Some of it my be the nature of the RPI which is fundamentially(at
> least
> the history of it), a toy.  Either for children or people that want
> to
> tinker with things.  So some of the downstream code doesn't always
> follow all the rules that upstream drivers would.  Because like I
> said
> at least historically, it's a toy.
> 
> I have submitted some small changes to the drivers that hook into
> vc04_services mostly for HDMI audio.   But it's only small changes...
> 
> Like I said, my goal here was simply to get ARM64 to work on the RPI3
> and HDMI audio was important to me.   And vc04_services was necessary

So Greg/Dan/Eric:

Have we come to any conclusion on how things are going to proceed with
this driver?

If you want to upstream the other drivers, that's fine by me.  In my
spare time I'll try to submit improvements to them.  But at the same
time, I didn't upstream vc04_services, so I don't see why the burden or
decision to upstream the other drivers should necessarily fall on me.  
I didn't write any of these drivers...  I'm just some guy that's trying
to submit improvements to them specifically for ARM64...