Here is the problem with that. You use a different kernel to me and you don’t like to use systemd. Hence I will explain how to get this working, but you are going to have to do the coding and testing. To start with, which kernel are you using?
From the TPS65217 datasheet the ACI bit in the INT register (0x02) will be a 1 if the power status changed (either power on or power fail). The state of the power is in the status register (0xA) which is 0 for no power and 1 for power in valid range. So looking at the Interrupt routing, both events are reported. I would recommend changing the input key to something different to KEY_POWER because we do not want to modify the pwr button behavior.
if (int_reg & TPS65217_INT_ACI) {
/* Handle AC power status change /
dev_dbg(tps->dev, “AC power status change\n”);
/ Press KEY_POWER when AC not present */
input_report_key(tps->pwr_but, KEY_POWER,
~status_reg & TPS65217_STATUS_ACPWR);
input_sync(tps->pwr_but);
}
You might have to change input_report_key to input_report_switch as I’m not sure if we can extract the status from EV_KEY.
Using udev, the input key is linked to this systemd service poweroff.target
That’s not what I was saying at all. I’m saying if all this is that easy for you, then you should add this functionality, and be the community hero.
This sort of thing is definitely not above my pay grade, but I am not a kernel hacker, and I do not know the file structure all that well. So it would take me a while to to figure out everything I need to know, about everything I’d need. So if this thing is really that easy for you, why don’t you make a new LKM, something that takes an argument, or two. LIke g_multi where you pass in a path for the g_mass_storage bit of the driver. Except of course, you want to be able to set a time out for a shutdown.
Second, a kernel module should not require a specific init daemon. That goes against the whole point of Linux.
FYI I could do this entirely in userspace, really easily. Except I would have to poll, instead of using an interrupt, and I pretty much be writing duplicate code, or code that does a duplicate job. But passed that I really do not have to time for this, or to read through, and understand all the required Linux kernel, and LKMs to do this “properly”. It’s a lot of work for someone who really doesn’t know what they’re doing.
Lastly, when I say “really easily” I mean that I know it is possible and I know how to go about doing it. I’d just have to research many things to bring it all together. So would also take me a little while. Maybe a week, maybe two. Assuming I had the time.
Yep, it can be done in user space as well. Simply add sigaction to the tps65217 mfd driver. Here is an example of a standalone KM with a user space app. So now we do not use input key, but send events via kernel signals (similar to kill -9 pid or ctrl-c).
Kernel Code:
Well that is not how I’d do things, and I suppose that code if complete and integrated into the tps65217.c file, it might work . . .
But as I said that code is not complete, and is what looks like example code out of some Documentation/*txt file.
I just don’t understand what you are asking for. The code is self explanatory and with a little effort, you can make it work. My guess is you want me to add the include headers and create the Makefile and Kconfig files. If that is what you want, I can do it for you, but I thought you would know how to do this yourself. Take a book and read about sigaction. I’m sure you will find examples just like the ones I sent you. I’ve pulled code like this together for year to understand how comms works between the kernel and user space.
Regards,
John
I just don’t understand what you are asking for. The code is self explanatory and with a little effort, you can make it work. My guess is you want me to add the include headers and create the Makefile and Kconfig files. If that is what you want, I can do it for you, but I thought you would know how to do this yourself. Take a book and read about sigaction. I’m sure you will find examples just like the ones I sent you. I’ve pulled code like this together for year to understand how comms works between the kernel and user space.
Regards,
John
Dont do it for me, because I do not need it. Do it for all those interested people you mentioned before.
You say it’s easy, and you’re pasting in random code here in there, but I’ve yet to see you come up with a real, and solid solution. You keep talking around the subject like it’s simple . . .so put your money where your mouth is.
Either that, or stop “talking”, because you’re not helping anyone.
What a shitty attitude. I don’t mind helping people out who appreciate the help, but why would anyone help you when you all you do is complain about the help.
Regards,
John
What a shitty attitude. I don’t mind helping people out who appreciate the help, but why would anyone help you when you all you do is complain about the help.
Regards,
John
It’s not just anyone who gets this special treatment. Just you. I dont like you, have told you this repeatedly and yet you feel compelled to inject yourself into discussions I start, or participate in. I even told you I would have nothing further to say to you ever. And you again felt compelled to inject yourself into this discussion.
But hey, who knows, maybe someday you’ll get the hint.
Yep, perfectly clear. You are a hater and there is no hope for you. Strange how the few conflicts on this forum have always involved you as one of the parties. I don’t recall any other conflicts that did not involve you. Perhaps you need professional help to get over your anger issues. Anyway, good luck to you.
Regards,
John
I’m a hater of people who consistently have to have the last word on a subject they obviously know nothing about. All you did to this discussion was create confusion, and yet another rabbit hole to explore. You have not even answered my original question, and you do not even realize it.
I think my house mate put it perfectly.
Hello John,
I’ve read through this thread and am very interested in solving this problem (with your help) and posting the solution if successful. My goal is to switch to battery power without a shut down when AC power is removed. Currently, the kernel treats the removal of AC power as if the power button is pressed and a clean shut-down is issued. I’m using Mentorel’s Beaglebone uSomIQ v4 which is a ruggedized version of the BBB and have installed the 3.8.18-bone79 kernel and running Debian 11.
Where can I find the code you posted that needs to be modified? Specifically:
if (int_reg & TPS65217_INT_ACI) {
/* Handle AC power status change /
dev_dbg(tps->dev, “AC power status change\n”);
/ Press KEY_POWER when AC not present */
input_report_key(tps->pwr_but, KEY_POWER,
~status_reg & TPS65217_STATUS_ACPWR);
input_sync(tps->pwr_but);
}
I do not see any “tps65217” source files. A find -name tps65217 returns:
root@beaglebone:/# find -name tps65217
./usr/src/linux-headers-3.8.13-bone79/include/linux/mfd/tps65217.h
./usr/src/linux-headers-3.8.13-bone79/include/config/backlight/tps65217.h
./usr/src/linux-headers-3.8.13-bone79/include/config/mfd/tps65217.h
./usr/src/linux-headers-3.8.13-bone79/include/config/regulator/tps65217.h
./sys/bus/i2c/drivers/tps65217
./sys/bus/platform/devices/tps65217-pmic
./sys/bus/platform/devices/tps65217-bl
./sys/bus/platform/drivers/tps65217-pmic
./sys/bus/platform/drivers/tps65217-pmic/tps65217-pmic
./sys/bus/platform/drivers/tps65217-bl
./sys/devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/tps65217-pmic
./sys/devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/tps65217-bl
./proc/irq/7/tps65217
./root/boneDeviceTree/DTSource3.8.12/tps65217.dtsi
./root/boneDeviceTree/DTSource3.8.13/tps65217.dtsi
./root/boneDeviceTree/DTSource3.8.11/tps65217.dtsi
Thank you,
Bolek
Correct, it's a "built-in" kernel module, so if you want to modify it,
you'll have to rebuild the kernel..
Regards,
My solution was easier i thought.
Uninstall acpid
william@beaglebone:~$ cat /proc/interrupts
CPU0
. . .
197: 1 INTC 7 Level tps65217
. . .
Then when a battery is connected to the board through the 4 test points, and the board loses DC input, or the power button is cycles this file:
william@beaglebone:~$ cat /proc/irq/197/spurious
count 0
unhandled 0
last_unhandled 0 ms
count will increment.
However I’ve not yet tested this on a 3.8.x kernel. But at one point I did have this working on a 4.x image. I have not tested recently however( within the last few months ). At least one caveat that I can think of off hand however. The irq number changes from system to system. So additional string parsing would have to be done to find the actual file programmatically. But not impossible.