linux-kernel - Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

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]

Date:	Mon, 30 Aug 2010 20:19:54 +0200
From:	"Mario 'BitKoenig' Holbe" <Mario.Holbe@...Ilmenau.DE>
To:	Ike Panhc <ike.pan@...onical.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Thomas Renninger <trenn@...e.de>,
	Alan Cox <alan@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Corentin Chary <corentincj@...aif.net>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	"Brown, Len" <len.brown@...el.com>,
	Matthew Garrett <mjg@...hat.com>
Subject: Re: [PATCH 0/8] [Resend] ideapad: using EC command to control
 rf/camera power

Hello Ike,

On Wed, Aug 25, 2010 at 07:59:30PM +0800, Ike Panhc wrote:
> On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> > On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
> >> Could you attach or upload the DSDT of S12 somewhere I can reach?
> > 
> > http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
> > 
> >> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
> >> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
> > 
> > Looks more fixed than on my S12, indeed.
> > I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
> > to read fixed values only, here on S12 PHSR (called from _CFG) seems to
> > do some kind of I/O operation. I'm not sure about this, but it somehow
> > looks like.
> > 
> It accesses something in system memory, but I have no idea what will happen
> after writing..

Well, the pattern looks like I/O - mmapped I/O.
        Store (Arg1, \_SB.INF0)
        Store (Arg0, \_SB.BCMD)
        Store (Zero, \_SB.SMIC)
        Store (\_SB.INF0, Local0)

Note that INF0 is written before and read after writing SMIC. Hence,
for this to be useful, something must have happened inbetween, i.e.
I/O :)

> There are two variables need to be written for turning on/off bluetooth. They are
> BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
> when enable bluetooth.

What exactly do you mean with "there are some sync failed"? I don't see
anything like that in the logs.

> This could be a plan. I have several idea to go and need your help.
> - Add some debug message to read BTST/BTEN when turning on/off bluetooth.
> - Force to set BTST/BTEN before reading _CFG
> - Provide a module parm to force enable rf devices.
> 
> Will have the drivers and please test it and let me know the result.

Hmmm, I don't know if I got you right. I didn't find any new drivers to
test, so I tried to add some more debug code myself. Hope this helps.
I added some code to show_ideapad_cam() to be able to asynchronously
trigger reading of BTST, BTEN, and BTPS. As before: the patch attached
is not for inclusion but to show what I did. I'm usually not a kernel
hacker, so please take a serious look at what I did before trusting the
results :)

I attached a full protocol of actions I performed including kernel
dmesges. Typed commands are prepended by #, manual actions and comments
are enclosed in <>, kernel messages are timestamped, the rest is output
of the commands.
Basically I did the following:
0. I started with a fresh powered up system, all RF devices powered on.
1. I hw-switched RF off and back on, which went okay.
2. I sw-switched BT off and back on, which resulted in erroneous
initialization.
3. I again sw-switched BT off and back on, which resulted in BT being
completely gone.
4. I hw-switched RF off and back on, which brought BT back and
operational.

> > I played with the hardware killswitch under Linux. The bluetooth device
> > disappears and re-appears there and always seems to initialize
> > correctly. No USB read errors this way.
...
> > I'm not exactly sure what this means - especially because I don't know
> > how the hardware killswitch works internally.
> > It *could* mean, the initialization problem is proably something that
> > could be dealt with in the USB layer long term (and would then probably
> > not have to be worked around anymore in ideapad_laptop). I'm not sure
> > about this, because this would mean the hard killswitch power-cut
> > somehow differs from the soft killswitch power-cut.
> Usually the hw rf switch turning off PHY only. When turning off, device and
> its driver is still there. I believe S12 is designed in this way after
> reading your test result.

Hmmm, I don't understand your reasoning here.
I said the device disappears and re-appears when using the hw rf switch,
this doesn't look like it would turn off PHY only.


best regards
   Mario
-- 
We know that communication is a problem, but the company is not going to
discuss it with the employees.
                       -- Switching supervisor, AT&T Long Lines Division

View attachment "ideapad_laptop.diff" of type "text/x-diff" (1652 bytes)

View attachment "protocol" of type "text/plain" (5755 bytes)

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