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

[Poul-Henning Kamp]

--------
In message <20180129063950.GA59901 at bluezbox.com>, Oleksandr Tymoshenko writes:

>PWM drivers: https://reviews.freebsd.org/D14104

I'll test this in my next timeslot.

>We do not include these
>overlays in official snapshots and I think this should be fixed.

That's one of the details I ran into:  The DTS for the DTB
in the RaspBSD.org images is not in our tree.

Even if they are vendor-supplied, should they be in our tree for
reasons of completeness/documentation/reproducible builds etc. ?

>Summary: adding ofw_bus_status_okay check in probe method doesn't
>require any additional functionality, ignoring it is inconsistent
>with majority of FDT-based drivers' behavior.  There is trivial
>way to enable PWM device in platform-conformant way. Will you
>please commit fix for this bug? 

I prefer an architectural discussion about how we *want* this to
work in the long run first.

My input:

If I pick a RPI[23] out of the box, download a FreeBSD image,
put the card in and play around, I should be able to put a
LED in a breadboard and configure a line for PWM or attach
an I2C or SPI device without reboot between every single
experiment.

If I mount any kind of "cape" board, requiring a reboot is
a perfectly reasonable requirement (not to mention it being
sane ESD procedure.)

That may indicate an overall model where we distinguish between
"overlays loaded at boottime" and "no overlays loaded at
boot time" and behave more liberally in the second case.

Or maybe we just need a well hidden but powerful switch that
lets people say "God, Root, What difference?"

The crucial point is that we gain no friends or favours by enforcing
needless cumbersome procedures, like reboots, just because there
may some times be dangers without it, because very often the dangerous
things people want to do is getting their job done or develop
and improve FreeBSD.

I kindly point you to the wisdom of Kernighans "There is no
escape" critique of PASCAL.

(Service message to the non-ancient developers:  That this bit of
advice came from the bloke who had read Kernighan and therefore
implemented "kern.geom.debugflags=0x10" to defeat the consistency
protections in his new-fangled GEOM subsystem, even if it was
dangerous - and he never once regretted it.)

>All these best practices and guidelines are unwriteen, and
>they're not always implemented on older platforms. And it's the
>problem from which this situation has risen.

With the added cherry on top that RPi is a horrible platform which
nobody loves - except thousands of teachers, students, hackers and
other potential FreeBSD recruits.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.