Searched hist:a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 (Results 1 – 8 of 8) sorted by relevance
| /openbmc/linux/drivers/bluetooth/ |
| H A D | hci_bcsp.c | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| /openbmc/linux/net/bluetooth/ |
| H A D | hci_sysfs.c | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| H A D | hci_sock.c | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| H A D | hci_conn.c | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| H A D | hci_event.c | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| H A D | hci_core.c | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| /openbmc/linux/include/net/bluetooth/ |
| H A D | hci.h | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| H A D | hci_core.h | diff a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 Sat Oct 20 06:33:56 CDT 2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|