linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Nicolas GUILBAUD <nicolas.guilbaud.wj@rdf.renesas.com>
Cc: Suraj Sumangala <suraj@Atheros.com>,
	Suraj Sumangala <Suraj.Sumangala@Atheros.com>,
	linux-bluetooth@vger.kernel.org,
	Jothikumar Mothilal <Jothikumar.Mothilal@Atheros.com>
Subject: RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
Date: Fri, 17 Sep 2010 08:00:16 +0900	[thread overview]
Message-ID: <1284678016.2405.145.camel@localhost.localdomain> (raw)
In-Reply-To: <A9AC1023FCA4654D92AC24C2A8F6A09201A2B923@renesas4bis.renesas-rdf.local>

Hi Nicolas,

> >>> I would really appreciate if you can give me any idea about working
> >>> around the above mentioned issues.
> >>
> >> if we talk about the SAP server role found in a mobile phone, then that
> >> support clearly needs to interact with the telephony stack. Since when
> >> SAP is active the telephony stack needs to be suspended and all SIM
> >> transaction being forwarded.
> >>
> >> Currently I would be thinking that the SAP implementation should be done
> >> inside oFono actually. Since then you have direct access to the
> >> hardware. The D-Bus approach just doesn't sound correct to me. I could
> >> be of course wrong, but I can't wrap my mind around on how you can make
> >> this work.
> >>
> >> Even with file descriptor passing this doesn't look like the right
> >> approach. If we need a hardware abstraction than we either use oFono or
> >> we have to create some SAP hardware access abstraction.
> >
> >The advantage I thought d-bus has would be the generic interface it 
> >could provide. But, if we have a system with direct access to the Sim 
> >access hardware, D-bus could possibly become a bottleneck.
> >
> >I would really appreciate if others who have worked with Sim Access and 
> >OFono can give their comments.
> >
> >Also, please share some information on regarding the SIM reader 
> >implementation in linux based systems.
> >
> >>
> >> The SAP client role found a carkit is obviously a different story.
>
> I agree with Marcel, because in standard Mobile phone implementation, the SIM card is directly connected to the Modem. To access the SIM card, AT command (or proprietary commands) are needed, oFono implements both of them to access SIM card in Modem side, but in my understanding there is no possibilities to disconnect modem (in oFono) due to SIM SAP.

that is just because we haven't gotten there yet. Of course if SAP takes
over we have to shutdown oFono's handling of the modem. This could be
done similar to the support for Lockdown we have in the oFono TODO list.

> In the case where SIM card is connected to the Application processor (Linux side), it's missing the SIM stack (APDU server...). I don't find any SIM implementation in Linux, may be we have to specify it. 

There is a framework for card services in general, but I think that is
just pure overhead for this.

And to be honest, my current thinking is that even for pure SIM card
readers with APDU mode, we might wanna support them via oFono anyway.
Having to add SAP support in multiple levels is a bad idea.

However in the end this all depends on the hardware and right now I have
not had access to SAP capable hardware. Or maybe I did and I didn't know
it yet. Do we have any target hardware in mind?

Regards

Marcel



  parent reply	other threads:[~2010-09-16 23:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 10:43 [RFC] BlueZ D-Bus Sim Access Profile Server API description Suraj Sumangala
2010-09-13 10:59 ` Johan Hedberg
2010-09-13 11:31   ` Suraj Sumangala
2010-09-13 13:20     ` Johan Hedberg
2010-09-13 15:18       ` Suraj Sumangala
2010-09-13 16:47         ` Johan Hedberg
2010-09-14  5:00           ` Suraj Sumangala
2010-09-13 12:11 ` Waldemar.Rymarkiewicz
2010-09-13 12:29   ` Suraj Sumangala
2010-09-13 12:47     ` Waldemar.Rymarkiewicz
2010-09-13 15:25       ` Suraj Sumangala
2010-09-14  5:42 ` Marcel Holtmann
2010-09-14  6:28   ` Suraj Sumangala
2010-09-15  3:44     ` Marcel Holtmann
2010-09-15  6:14       ` Suraj Sumangala
2010-09-15  7:32         ` Nicolas GUILBAUD
2010-09-15  8:24           ` Suraj Sumangala
2010-09-15  8:56             ` Nicolas GUILBAUD
2010-09-16 23:00           ` Marcel Holtmann [this message]
2010-09-17 11:01             ` Nicolas GUILBAUD
2010-09-18  0:16               ` Marcel Holtmann
2010-09-15  9:18       ` Waldemar.Rymarkiewicz
2010-09-16  7:50         ` Suraj Sumangala
2010-09-16 23:04         ` Marcel Holtmann

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=1284678016.2405.145.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=Jothikumar.Mothilal@Atheros.com \
    --cc=Suraj.Sumangala@Atheros.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=nicolas.guilbaud.wj@rdf.renesas.com \
    --cc=suraj@Atheros.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).