Hi Abhishek, > Add Controller Suspend Event and Controller Resume Event to identify > suspend or resume of the Bluetooth stack has occurred. > > Also update Device Disconnected Event to indicate a new disconnect > reason: "Connection terminated by local host for suspend" > > Reviewed-by: Alain Michaud <alainm@xxxxxxxxxxxx> > Reviewed-by: Miao-chen Chou <mcchou@xxxxxxxxxxxx> > --- > > doc/mgmt-api.txt | 53 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt > index ca0d38469..f79c0222c 100644 > --- a/doc/mgmt-api.txt > +++ b/doc/mgmt-api.txt > @@ -3834,6 +3834,7 @@ Device Disconnected Event > 2 Connection terminated by local host > 3 Connection terminated by remote host > 4 Connection terminated due to authentication failure > + 5 Connection terminated by local host for suspend > > Note that the local/remote distinction just determines which side > terminated the low-level connection, regardless of the > @@ -4577,3 +4578,55 @@ Advertisement Monitor Removed Event > > The event will only be sent to management sockets other than the > one through which the command was sent. > + > + > +Controller Suspend Event > +======================== > + > + Event code: 0x002d > + Controller Index: <controller_id> > + Event Parameters: Suspend_State (1 octet) > + > + This event indicates that the controller is suspended for host suspend. > + > + Possible values for the Suspend_State parameter: > + 0 Running (not disconnected) > + 1 Disconnected and not scanning > + 2 Page scanning and/or passive scanning. > + > + The value 0 is used for the running state and may be sent if the > + controller could not be configured to suspend properly. does it make sense to send a suspend event with state suspend not succeeded. That doesn’t really fit well. > + > + This event will be sent to all management sockets. > + > + > +Controller Resume Event > +======================= > + > + Event code: 0x002e > + Controller Index: <controller_id> > + Event Parameters: Address (6 octets) > + Address_Type (1 octet) > + Wake_Reason (1 octet) > + > + This event indicates that the controller has resumed from suspend. > + > + Possible values for the Wake_Reason parameter: > + 0 Unexpected Event > + 1 Resume from non-Bluetooth wake source > + 2 Connection Request (BR/EDR) > + 3 Connection Complete (BR/EDR) > + 4 LE Advertisement > + 5 LE Direct Advertisement > + 6 LE Extended Advertisement > + > + We expect that only peer reconnections should wake us from the suspended > + state. Any other events that cause a wakeup will be marked as Unexpected > + Event. > + > + If the Wake_Reason was any of the expected wake reasons (values 2-6), > + the address of the peer device that caused the event will be shared in > + Address and Address_Type. Otherwise, Address and Address_Type will both > + be zero. So I would be using Wake_Reason as first argument. However do you need all this distinction. For example the Device Connected event could gain an extra Flags bit for wakeup. I would especially not make any distinction between the advertising types. I am in principal fine telling bluetoothd when suspend / resume happened, but letting HCI event specifics bleed into the mgmt API is not really helpful. Regards Marcel
