Hello, I fully agree : @LinuxNew hello, what to say is very serious so please could you provide the source link referring to the Pinephone kill switches issue (need to reboot) ? Thank you
I am really interested to this phone, so if this failure is confirmed, it can become a serious trust issue from me regarding the privacy aspect of the Pinephone.
I had the impression that the switches on the Pinephone are a slightly different use case from those on the Librem 5.
You have to take the back off the Pinephone to change the switches and they are DIP switches, which makes me think that, yes, it is plausible that they are read once at boot time, but maybe that is fixable in software. (There might still be a delay in recognising the state change.)
Anyway here’s a pic: https://wiki.pine64.org/index.php/PinePhone#Killswitch_configuration
Yes, they are more like those configuration switches/jumpers on motherboard or other pcbs.
So it’s more to configure hardware features of the phone (in cold state) rather than shut/unshut components/ports. On the other hand all of those features must be working without rebooting the phone as they either retain their hot state (S3 is minimum) or sit on hot-pluggable bus (eg modem).
When I flip a switch on my Librem 5, the relevant module disappears immediately (give or take a few seconds) in the software. If I flip the WIFI switch off, the WIFI icon disappears and lshw no longer shows it. Switching it back on brings the device back almost instantly and eventually the WIFI reconnects to the saved network and it is back. I haven’t actually broken out the multimeter to check that power is actually disconnected, but maybe I will soon.
For the avoidance of confusion, including my own, you are talking about the Pinephone in this post, not the Librem 5. Right?
The Librem 5 kill switches work immediately without rebooting the phone or anything (sometimes the software takes a second to detect and display the change though, it depends on where the polling interval is when you trigger the switch).
I routinely use the WiFi kill switch when I leave the house to save battery by having it be completely off and not scanning networks I pass by. I could do it in software too but it’s actually faster and more convenient to do with the HKS than going into Settings at the moment.
Not to mention the fingerprinting that is done of your phone if the wireless client device implicitly transmits the id of any AP that it is interested in associating with.
I guess the kill switches are for serious tin foil hatters because I personally won’t make much use of them. They’re not for everyone and some are going to make a big deal about how they work 
I may misunderstand what’s going on with the pine phone, but my impression was that turning the switch off is instant. It cuts power to the peripheral, as wanted and expected. The issue is turning the switch on does not (reliably? vs ever?) reconnect the peripheral. This may be a software issue, where the dbus system or the kernel aren’t watching for new devices connecting on the integrated peripheral bus, or aren’t properly reinitializing a peripheral which died in an unspecified state. Or it may be a hardware issue, where the peripheral itself isn’t given power back properly, so hangs on reinitialization. If it’s a software issue, that can probably be fixed (might need to restart udev or something). If it’s a hardware issue, that kinda sucks, since the reboot time isn’t trivial.
On pine - only for modem and mic, for wifi and cameras it rather asks chip to stop working. And I suspect exactly to avoid re-initialisation issue (hw remains initialized, just enters powersave mode). So software should be able to pick it up after resume, but of course that feature may not yet be implemented in the kernel/userspace.
Does it ask nicely though? 
So if there is a backdoor in the WiFi and camera chip on Pine then it remains operating? Capture images on camera and transmit to bad guy via WiFi despite having operated the ‘kill’ switches?
Wifi yes, it runs own firmware so is a blackbox. I wasn’t even able to find consecutive answer what exactly the chip_en does, some references were pointing it merely disables BT, others that it drives entire chip into powersave.
Cameras - technically yes, the PWRDN signals the internal clock control to stop system clocks (but retain registers/ports) so technically there could be some backdoor signal to override pwrdn and re-enable the chip. Eg time sequence on reset line which controls the same subsys (that would need rogue kernel modeule). After all OV has own MCU inside.
A while ago I read that some modem, possibly the one used in the Pinephone, needed a 30 second delay to write stuff to flash/EE before power down. Otherwise one would risk bricking the modem.
I have searched for that post without finding it, did any of you read it too (or did I just dream this)?
If this is actually a problem, then the HKS will need additional circuitry. First assert the “shutdown, pretty please” signal, then cut power after sufficient delay. It’s a bit more involved, but certainly doable.
I don’t believe portable devices with removable battery will have such a design flaw. Because end user can always pull the battery from running device. If that bricks the modem - that’s a very bad component choice.
Bad design, indeed.
But look at the number of handheld devices where the battery is more or less impossible to remove and there are no switches to surprise the modem by cutting its power. I can understand if modem makers would say “hey, just do a proper shutdown” so they would not have to bother…
Thanks Caliga great info.
Hi Zero,
Please see the youtube video below, watch from 14:40 mins onwards.
This review is of the pinephone, and different OS and their operation on the pinephone, as you will hear at 14:40 onwards the reviewer discusses how he had to restart the phone for the HKS to work?
My point on this post was, HKS should work almost instantly, it should be a mechanical feature not software based, which leads me to suspect that the HKS on the pinephone are not the same as on the Librem 5…
There are comments by other viewers from youtube regarding this issue under the video.
Hi prog-amateur,
I have responded to this comment from another user mate, video and explanation at bottom of the page.
Correct kieran, see video at the bottom of the page.
Hi Iperkins2, video at the bottom of the page.