linux-kernel - Re: [PATCH 3/5] HSI: ssi-protocol: export modem info via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160131183410.GC18175@earth>
Date:	Sun, 31 Jan 2016 19:34:10 +0100
From:	Sebastian Reichel <sre@...nel.org>
To:	Pavel Machek <pavel@....cz>
Cc:	Tony Lindgren <tony@...mide.com>,
	Benoît Cousson <bcousson@...libre.com>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Pali Rohár <pali.rohar@...il.com>,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] HSI: ssi-protocol: export modem info via sysfs

Hi Pavel,

On Sun, Jan 31, 2016 at 06:36:05PM +0100, Pavel Machek wrote:
> On Sun 2016-01-31 02:19:45, Sebastian Reichel wrote:
> > Currently userspace knows about the rapuyama version by
> > checking, which gpios have been exported. This does no
> > longer work with kernel based power management, so export
> > a sysfs file, which provides the rapuyama generation. Also
> 
> Umm. So patches 1-2 make it impossible for existing userspace to
> detect modem version?
> 
> Even if we re-add the capability with this patch, that makes it bad
> idea, no?

Thanks for having a look at the patches :) Looks like my commit
messages are not verbose enough to show the whole thing. Let me
try a more verbose explanation:

The N900 and the N950 have more or less the same modem, but with
different GPIOs. That basically means, that the powerup/down
sequence works differently. OFono has code for supporting power
management of both modems by detecting, that some gpios have not
been exported. (So if, for some reason, you have not exported
some of the GPIOs it will also think, that you have an N950 modem)

For kernel based PM there won't be any GPIOs exported, so OFono
cannot derive modem generation information from them. OTOH it
no longer needs to, since the kernel will take care of the
difference between the power up/down sequence. OFono only uses
the derived modem generation information for the different power
sequence.

Unfortunately there is another difference between the N900 and N950
modem, that is not yet covered by OFono at all: The N950 has a
broken CBS interface. So the current OFono code base is broken for
the N950, even though it can power it up. The broken N950 CBS
interface is currently not handled by either ofono, fso-gsmd or
sscd. Thus using an explicit new interface is not a problem IMHO.

Anyways, after this patchset you have the following methods for
using the modem:

1. The existing way using pm=1, which is still the default for now.
2. The existing way using pm=1 + rapuyama_version to check if all
   GPIOs are there.
3. The new way using pm=2. You can use rapuyama_version for avoiding
   the CBS interface on N950.

I don't think we can easily remove pm=1 support, since it will be
needed by existing userspace software. I do think though, that we
can change the default from pm=1 to pm=2 when support for the new
interface has been integrated into userspace software for some time
(e.g. 1 year after it has been merged).

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)