All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: "Gu, Chao Jie" <chao.jie.gu@intel.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH v3 2/4] shared/gatt-client: Add CSRK part to support signed write
Date: Sat, 27 Sep 2014 10:51:21 +0200	[thread overview]
Message-ID: <BCAE391F-397F-402C-8179-675E53BD4F1A@holtmann.org> (raw)
In-Reply-To: <3D02B219753AD44CBDDDE484323B17741130B3FA@SHSMSX104.ccr.corp.intel.com>

Hi Chao Jie,

>>> +bool bt_gatt_client_set_local_csrk(struct bt_gatt_client *client,
>>> +				bool valid_local_csrk,
>>> +				uint8_t key[16]);
>> 
>> why do we have the parameter valid_local_csrk. I find that highly confusing. If you
>> do not have a valid CSRK, then do not call this function. It should be that simple.
>> 
> 
> My initial purpose to set this parameter valid_local_csrk here, user can call one API
> to set flag valid_local_csrk ture/false and CSRK key in one time.
> According to your proposal, I think it really result in confusion for user.
> 
> So for more clear to call API , I think we should split two API for upper layer:
> 1. When we need to set CSRK , check the CSRK is valid , then call bt_gatt_client_set_local_csrk
>  Just to pass one parameter key to function and in the function to set flag valid_local_csrk is true.
> 
> 2 When two device dispair each other, we should give user possibility to unset flag and CSRK.
>  So in this condition , we have to create bt_gatt_client_unset_local_csrk(struct bt_gatt_client *client)
>  to clear CSRK and set flag valid_local_csrk to false.
> 
> Do you think this thought would be ok for you?

I am not really worried about these details anyway. If you remove the bond between two devices, then the connection will be terminated. Which means that next time around you get a new bt_att object. If you do not have any CSRK the next time, you just not set them in the first place.

Regards

Marcel


  reply	other threads:[~2014-09-27  8:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26  7:48 [PATCH v3 0/4] support signed write command Gu Chaojie
2014-09-26  7:48 ` [PATCH v3 1/4] shared/att.c: Add signed command outgoing and CSRK function Gu Chaojie
2014-09-26 22:30   ` Lukasz Rymanowski
2014-09-27  9:26     ` Gu, Chao Jie
2014-09-29  8:08       ` Lukasz Rymanowski
2014-09-29  8:48         ` Gu, Chao Jie
2014-09-26  7:48 ` [PATCH v3 2/4] shared/gatt-client: Add CSRK part to support signed write Gu Chaojie
2014-09-26  9:55   ` Marcel Holtmann
2014-09-27  8:42     ` Gu, Chao Jie
2014-09-27  8:51       ` Marcel Holtmann [this message]
2014-09-26 22:35   ` Lukasz Rymanowski
2014-09-27  9:36     ` Gu, Chao Jie
2014-09-29  8:09       ` Lukasz Rymanowski
2014-09-29  8:53         ` Gu, Chao Jie
2014-09-26  7:48 ` [PATCH v3 3/4] tools/btgatt-client: Add signed write CSRK option Gu Chaojie
2014-09-26  7:48 ` [PATCH v3 4/4] Modify Makefile.tool to link Gu Chaojie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BCAE391F-397F-402C-8179-675E53BD4F1A@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=chao.jie.gu@intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.