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

[Emmanuel Vadot]

 So, almost a week after this commit, let's recap.

 - phk@ commit an hack to allow the pwm driver on rpi to always attach
even if it's not enabled in the dts.
 - I say to him that it's a really bad move and that he should use dtb
overlays (which thanks to kevans@ are in a really better state now).
 - His answer is that as long as you don't set the pwm sysctls you will
be fine (which is true) and that he want to be able to load dtb
overlays without rebooting (or a way to modify the existing dtb loaded
in the kernel).
 - I reply that changing the dtb should go with overlays and that
nobody is working on loading overlays at runtime.
 - His reply starts with "That doesn't make *any* UX sense."
 - The "problem" is we (FreeBSD) choose to followed the standard that is
Flattened Device Tree and stick to it for arm (at least) platform.
 - phk@ says that if a user kldload the pwm driver on a rpi the pwm
subsystem should be in a usable state. And doesn't want to talk anymore
("Over&Out).
 - jhb@ and imp@ talk about ways to improve the fdt subsystem.
 - ian@ point to phk@ that the 'status' line in the dts control more
than a device but also pinmuxing (switching pins on the SoC to the
correct function) and that is it done at startup and not at the driver
attach. And that the rpi platform needs some love as it doesn't have a
proper pinmux driver.
 - phk@ points out that there is no doc about doing a pinmux driver
(which is true, unless you consider code as documentation or even
help/advice from other arm developpers).

 But.

 - We still have this driver that doesn't follow the standard we said we
want to adhere to.
 - Nobody except me explicitly request phk@ to revert his commit (which
he didn't do).
 - One day after everything was back to normal and everybody forgot
about this.

 So.

 - We have a commiter that commited something for his own need: he
wanted to use the pwm on his rpi, coded a driver (this part is good)
but feel that the standard we were using was crap and commited his work
without talking with arm developper on what the proper way to do it was.
 - Even after some developpers point out that it wasn't the way to go
he didn't revert his commit. And even he didn't say that he won't, his
mail suggest that he will not.
 - Now we have a crappy driver in the tree.

 What's next ?

 Cheers,

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