Hi Dmitriy, On Mon, Jun 20, 2011, Dmitriy Paliy wrote: > On Mon, Jun 20, 2011 at 12:31 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > > Coding-style wise your read_link_key call should be checking for < 0 or > > specifically for -ENOENT (you're calling the function as if it returned > > a boolean value). However, I'm thinking we might just store the > > no-bonding info in the device struct itself so you don't need to consult > > the storage in this case. I.e. in addition to device_is_paired there'd > > also be a device_is_bonded function which'd make the logic like: > > > > if (device_is_paired(device) && !device_is_bonded(device)) > > device_set_paired(device, FALSE); > > > > Thoughts? Have you checked that this works both with hciops and mgmtops? > > New ..is_bonded sounds a bit redundant since it is quite > straightforward to check it from storage, but also ok. It's still a file-system access for something that we could easily have available as a flag in runtime memory. Even if you did do the file-system read it'd make the code more readable if you had this wrapped into a device_is_bonded function. > I didnt touch mgmtops at all. Could you provide more inputs about what > exactly the issue is? I didn't say that there is an issue. I just asked if you've checked that this works with mgmtops since the signaling between the kernel, adapter_ops and the core bluetooth daemon is quite different wrt pairing in that case. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
