4396dc9c71
This API had several issues: - The parameter types and order were inconsistent with e.g. bt_le_adv_start() - There were no real users of num_params, which just caused increased code size and memory consumption for no good reason. - The error handling policy was arbitrary: if one of the notifications would fail it would be impossible for the caller to know if some notifications succeeded, i.e. at what point the failure happened. Some callers might also want to make note of the failure but continue trying to notify for the remaining parameters. The first issue is easily fixable, but because of the other two I think it's best we don't have this code as part of the stack, rather require whoever needs it to do the for loop themselves. It's just a few lines of code, so the benefit of having this in the stack was anyway quite minimal. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> |
||
|---|---|---|
| .. | ||
| bredr.c | ||
| bt.c | ||
| bt.h | ||
| CMakeLists.txt | ||
| gatt.c | ||
| hci.c | ||
| hci.h | ||
| Kconfig | ||
| l2cap.c | ||
| ll.c | ||
| ll.h | ||
| rfcomm.c | ||
| ticker.c | ||