Thread: BFS for the power kernel
View Single Post
iDont is offline iDont
2011-09-27 , 19:28
Posts: 268 | Thanked: 1,053 times | Joined on May 2010 @ The Netherlands
#299
Originally Posted by Estel View Post
Hey iDont, I have idea, that may make BFS kernel even more bleeding-edge
Well, being bleeding-edge is not a goal in itself; it just happens to come with many goodies

Originally Posted by Estel View Post
As You may remember, there was a path in power-kernel tree, that allowed bq27x00_battery module and BME to live together (happily). Path was turned off, due to it being violating standards (theoretically, bq_27x00_battery and BME should not access same i2c). Ho ever, there was *never* true report of it causing any problems (every one I've heard of, resulted in finding other source of problems), so decision was rather "ideological" than practical. AFAIK, no one know why it worked perfectly (when theoretically, it should not), and we won't know, cause BME is closed source - there is possibility, that something there is also "out of standards"l, allowing combo to work

If You could enable it in BFS kernel, many, many people would be happy penguins (including me ). I'm sure it would bring quite wider audience for project, but, more importantly, it would be in spirit of project - incorporating features that are working great and bringing joy, but denied mainline
Yes, I've noticed the whole i2c-dev patch discussion on IRC. Personally, I think the patch should be left disabled. I know there aren't any confirmed reports on it causing trouble, but this doesn't alleviate the fact that you're removing a very important safety mechanism.

However, to give everyone some freedom of choice, I've created a patch that allows you to toggle the safety mechanism in question on or off at runtime. The patch consists of Matan's original patch + some sysfs code wrapped around it (from the kernel documentation, with love). I've used a slightly provocative name for the sysfs entry, but that seems only fair considering what you're actually doing .

If you understand the risks of the (original) patch, then here goes the tutorial:
Code:
Nokia-N900:~# cd /sys/kernel/n900/
Nokia-N900:/sys/kernel/n900# echo 1 > i2c-dev_break_ioctl
After enabling the hack, you can stop/start bme even though bq27x00_battery is loaded, as desired:
Code:
Nokia-N900:/sys/kernel/n900# modprobe bq27x00_battery
Nokia-N900:/sys/kernel/n900# stop bme
bme (stop) running, process 774
bme (stop) pre-stop, process 2184
	main process 774
bme (stop) stopping, process 774
bme (stop) killed, process 774
bme (stop) post-stop, process 2187
bme (stop) waiting
Nokia-N900:/sys/kernel/n900# start bme
bme (start) waiting
bme (start) starting
bme (start) pre-start, process 2201
bme (start) spawned, process 2207
bme (start) post-start, (main) process 2207
bme (start) running, process 2207
The above scenario will result in an instant reboot when i2c-dev_break_ioctl is 0. You can also verify that the pre-KP48 path is active by checking your kernel log:
Code:
Nokia-N900:/sys/kernel/n900# dmesg | grep HACK
[  351.532806] i2c-dev: HACK: omitting lock (EBUSY)
[  351.532836] i2c-dev: HACK: omitting lock (EBUSY)
after starting BME

Precompiled debs plus the patch itself can be found on kernel-bfs' garage page. Please test it and report back. I haven't got any previous experience with kobjects/sysfs, so some elements of the patch could probably be implemented in a cleaner manner. This doesn't affect its workings however. Feedback is appreciated / patches are welcome .

p.s. I'll send the patch to pali later as well.
edit 2: patch is sent. Pali replied that he's already working on a different solution which works by redirecting ioctls. That solution allows us to have both bq27x00_battery and bme working together without removing the safety mechanism in i2c-dev. There's no ETA on that yet though.
Last edited by iDont; 2011-09-29 at 17:02.
 

The Following 3 Users Say Thank You to iDont For This Useful Post: