[PATCH 1/6] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service

[Michael Zoran]

> > Since the API is completely documented, I see no reason we or
> > anybody
> > couldn't essentially rewrite the driver while it's in staging.  I
> > just
> > think it would be best for everyone if the new version was a drop
> > in
> > replacement for the original version.  Essential an enhancement
> > rather
> > then a competitor.
> 
> I think my comments weren't fundamental changes, but you surely mean
> the devicetree ABI? I like to see this driver ASAP out of staging and
> i'm not interested to maintain 2 functional identical driver only to
> keep compability with the Foundation tree. Currently i'm afraid that
> we build up many drivers in staging, which need a complete rewrite
> later if they should come out of staging. It would be nice if we
> could avoid the situation we have with the thermal driver.
> 
> Stefan

The API I'm talking about here is the mailbox API that is used to talk
to the firmware.  The numbers and structures to pass are documented. 
Nothing prevents anybody from rewriting this driver and submitting it
to the appropriate subsystems.  It's certainly small enough.

If you really want working thermal or cpu speed drivers today, nothing
stops anybody from submitting the downstream drivers after doing some
minor touchups and submitting them to staging.  That would at least get
things working while people argue about what the correct DT nodes
should be.

I would also like to point out that the RPI 3 has been out for over a
year and nobody has been able to get working video out of it through
VC4 on a mainline tree.  At least until now.  So I'm not sure the best
way to go is for the expander driver to go under the GPIO subtree.