svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules

Rodney W. Grimes freebsd at pdx.rh.CN85.dnsmgr.net
Sat Jan 27 21:32:35 UTC 2018


> On Sat, 27 Jan 2018 12:13:57 -0800
> Adrian Chadd <adrian.chadd at gmail.com> wrote:
> 
> > Hi,
> > 
> > Find the middle ground. Don't dissuade the developer too much.
> 
>  This is what happened two years ago when I started hacking on the
> allwinner SoCs :
> 
>  - I asked what should be done for bringing a new board
>  - andrew@ told me that we first need to switch to upstream dts and
> update drivers.
>  - Guess what, I did that.

Great, thats good co-operatation and communications, sometimes though
it is not so smooth.  The better we become at dealing with the not
so smooth the faster forward progress can be made.

> > Here's an example:
> > 
> > Make the driver follow DTS, allow a tunable/kenv check for it to
> > override whether it needs to be in the DTS or not (the "keep phk happy
> > for now" compromise) and have it default to obeying the device tree.
> > 
> > That way phk is kept happy and the defaults are the same as normal-ish
> > ARM /and/ you have a springboard to experiment with extending FDT
> > overlays at runtime for people who wish to do so.
> 
>  I don't care about keeping phk@ (or any other developer) happy, we
> have a standard, let's stick to it.

*sigh*  Let me ask you if you do not care about keeping any other
developers happy, why should any of them be concerned about keeping
you happy?  We need to always try to find middle ground and
co-operate in positive ways.

On the "we have a standard" front, well when standards get in the way
of forward progress they are often side stepped.  Maybe this standard
is not such a good standard and warts are going to form around it. I
have seen some discusssion at least on ways to improve the current
situation, hopefully someone takes them and runs with them.

Others have pointed out they do not like the current model in that
it gets in the way of developement progress.   I can see this point.
I can see phk's points, and I can see your points.

IMHO if we shove the standard down our own throats we are in
effect cutting our hands off in the process, not somethig we
really want to do is it?

> > (I personally hate having to edit the dts/recompile/reboot for every
> > test hardware change; it makes breadboarding things up kinda
> > hilariously annoying.)
> 
>  Use overlays then. And if you don't want to reboot provide patch for
> loading overlays at runtime.

Are those the only solutions?

> > -adrian
> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the svn-src-head mailing list