Mailbox power channel missing responses about firmware

[popcornmix]

Can you check #47

[nomis]

I can't find the reference to the issue related to this, but in the Linux driver I send a message with just the MSB set to get the current state (which happens to turn everything off). There's also a hack in the latest kernel to send 0x0 on startup to do the same thing.

[swarren]

popcornmix, #47 looks very interesting, but I'd argue that this particular issue could be considered a bug in the existing power mailbox channel, rather than needing a new mailbox API.

lp0, yes, I did wonder about doing something like that to work around the issue, but unless it's documented as a legitimate usage of the mailbox API, I'm slightly hesitant to do that, since I have no idea what setting that MSB might mean to the VC. If BCM says it'll be fine though, it seems a reasonable enough workaround.

[popcornmix]

The API is working as designed, and changing this would break firmware/kernel compatibilty.
I'll make sure the desired API is supported in #47.

Sending bit 30 (not MSB) set is supported and will return current state.

[swarren]

I don't believe that fixing this would actually cause any compatibility issues.

All current drivers take explicit action to avoid sending a message requesting the same state as the current state, so that they don't hang up waiting for a response that won't come. As such, the scenario whose behavior would change isn't happening, so the change in behaviour wouldn't be noticed.

But that said, it setting bit 30 is a supported workaround to guarantee a response, that's fine too.

[nomis]

If the existing driver sent a device off message followed by a device on message, it could immediately read the response to the device off message by mistake.

[swarren]

I can't really see any problem here.

• Old FW, old kernel: No change.
• New FW, old kernel: FW supports new usage, but the kernel doesn't change so only sends commands and waits for responses it would have got anyway (i.e. as described above, avoids the problematic cases that'd change in the new FW, or it couldn't work with the old FW), so no change.
• New FW, new kernel: Works as expected.
• Old FW, new kernel: Admittedly doesn't work. But, if it's mandatory to support all new kernels on old FW, then we can't implement any new FW feature (e.g. issue #47) since any new kernel that uses the new FW feature would not work on an old FW.

[nomis]

Old kernel, new FW:

• Send power off
• Recv status (ignored, but stored by the driver)
• Send power on
• Read old status (as it was stored already)
• Recv new status

The mbox code in my branch will clear unread messages but there could still be an issue if you turn the power on for a device immediately after turning it off.

[swarren]

That seems like a bug; any time a message is sent, the driver should wait for the response. Otherwise even in normal operation irrespective of any FW change, you're going to get out-of-sync.