Re: [PATCH] sony-laptop: support rfkill via ACPI interfaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 21, 2009 at 04:35:13AM +0000, Matthew Garrett wrote:
> On Sat, Mar 21, 2009 at 01:00:10PM +0900, Mattia Dongili wrote:
> > On Fri, Mar 20, 2009 at 02:00:04PM +0000, Matthew Garrett wrote:
> > > I had one machine where ECON seemed to need to be called explicitly, but 
> > > I can't remember the details now. Calling it probably wouldn't hurt 
> > > anything.
> > 
> > seems to be a TT and Z specific thing though. The DSDT on other models
> > doesn't provide the ECON method.
> 
> Yeah. As I said, I don't think there's any harm in causing it - I think 
> I was getting more promising results from hotkey events in the Z when I 
> called ECON, but I don't have access to that machine right now and never 
> got it finished off.

Sounds reasonable.

> > > The numbers correspond to enabling all events. I couldn't think of any 
> > > reason why we'd only want to enable a subset. The current nc setup code 
> > > seems to enable some events and then disable them again, which I don't 
> > > really understand.
> > 
> > Well, the current sequence was taken from a trace in windows on a Vaio C
> > Type, then it demonstrated to be helpful on other models as well.
> > The SN07[1] method is very different from the Z and TT type to the AR, C,
> > FE, FZ and N so I'm starting to suspect that we're just seeing a new
> > generation of SNC based models. I'll see if some users with older models
> > can give the new sequence a go.
> 
> Looking through, the implementation seems quite different but the 
> functionality seems the same - the newer machines seem to return values 
> directly, whereas older ones tended to trap into SMM. The wireless 
> control (at least, the enumeration call I make) seems to be a noop on 
> these older machines. It /looks/ like we can probably get some sort of 
> versioning information about the interface by calling SN00. I think that 
> would probably be a better approach than using DMI for this.

sure, that DMI whitelist is already annoying in its current shape.
Getting the ACPI tables to tell us what SNC version we are looking at
would be so much better.
I just grepped the DSDTs I have here and this is what I got:
DSDT.c1s.dsl:                    Name (SNI4, 0x344A0001)
DSDT.c71bw.dsl:                    Name (SNI4, 0x344A0001)
DSDT.fe21b.dsl:                    Name (SNI4, 0x334A0000)
DSDT.fe31m.dsl:                    Name (SNI4, 0x334A0000)
DSDT.fe41z.dsl:                    Name (SNI4, 0x334A0000)
DSDT.fe830fe.dsl:                    Name (SNI4, 0x334A0000)
DSDT.fz15.dsl:                    Name (SNI4, 0x374A0000)
DSDT.fz180e.dsl:                    Name (SNI4, 0x374A0000)
DSDT.n370e.dsl:                    Name (SNI4, 0x344A0001)
DSDT.tt11lnb.dsl:                        Store (0x344D0000, Index (CFGI, 0x04))
DSDT.z11awn.dsl:                        Store (0x334D0000, Index (CFGI, 0x04))
DSDT.z11vn.dsl:                        Store (0x334D0000, Index (CFGI, 0x04))
DSDT.z26gn.dsl:                        Store (0x334D0000, Index (CFGI, 0x04))
DSDT.z90s.dsl:                        Store (0x334D0000, Index (CFGI, 0x04))
VGN-AR31S-R0200J6.dsl:                    Name (SNI4, 0x364A0000)
VGN-AR370E-R0200J6.dsl:                    Name (SNI4, 0x364A0000)
VGN-C1S.dsl:                    Name (SNI4, 0x344A0001)
VGN-C1ZB-R0034J4.dsl:                    Name (SNI4, 0x344A0001)
VGN-C240E-R0080J4.dsl:                    Name (SNI4, 0x344A0001)
VGN-C2S-R0080J4.dsl:                    Name (SNI4, 0x344A0001)
VGN-C2Z-R0080J4.dsl:                    Name (SNI4, 0x344A0001)
VGN-FE11H-R0072J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE11H-R0074J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE11M-R0172J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE21M-R0130J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE31M.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE41E-R0190J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE41M-R0190J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE41Z-R0200J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE550G-R0074J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE590P-R0072J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE660G-R0133J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE770G-R0173J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE830.dsl:                    Name (SNI4, 0x334A0000)
VGN-FE880EH-R0200J3.dsl:                    Name (SNI4, 0x334A0000)
VGN-N130G-R0020J4.dsl:                    Name (SNI4, 0x344A0001)
VGN-N230E-R0070J4.dsl:                    Name (SNI4, 0x344A0001)

SNI4 or CFGI+0x04 is the only differing number and is returned with
SN00(4).

> I've put this into rawhide, so I suspect we'll hear complaints if it 
> breaks things for anybody.

want to try to push your patch to mainline or would you prefer to wait?
IMO pushing it and eventually fixing support for 0x344a000[10] models is
fine. After all your snc_setup code could be easily plugged into the DMI
list for the time being and Z and TT users would be happy.
-- 
mattia
:wq!
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux