Am 25.05.2015 um 11:41 schrieb Wolfgang Denk:
Dear Fabio,

In message <caomzo5dfpujmgf_sornagtxexzbq1-bvtfvtbntmy40qpdw...@mail.gmail.com> 
you wrote:

"If the gpio command would be enabled, it would even be possible to reset the
BRCM- WLAN and Bluetooth modules by just adding some stuff to uEnv.txt."

This sounds like a real hack for me, sorry.

Consider it as an example for being able to do many different things
that have not even been thought of at the time of implementations. to
try out things.  Maybe we decide later to implement the features a C
code, but for testing or working aound problems is is always nice to
have scripting capabilities.

Exactly. It's just another example besides the possibility to choose the correct dtb based on the board revision without modifying u-boot at all (if gpio would be enabled). And also the example is a hack, that's the stuff which is necessary very often, until someone fixes something in a driver (and managed it to get the fix upstream), or even to circumvent problems with some HW.

Btw., in regard to the above specific hack, the same problem (failure to upload firmware because it's already uploaded) exists for Bluetooth too. Personally I've modified (hacked) the wandboard-rfkill-driver a year ago to disable the regulator of the brcm-module completely for some milliseconds at startup (and when the module is unloaded, to save power). But that involves having to manage own patches for the kernel, so I might even prefer to use just a hack in uEnv.txt to fix the reset problem with the brcm-module.

Besides that I don't really care what a maintainer said to some previous similiar problem. Maintainers are humans too, maybe he just had forgotten about the gpio-command.

Regards,

Alexander Holler
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to