On Tue, Dec 15, 2015 at 10:30:38AM -0500, João Paulo Rechi Vita wrote:
> This series is a request for comments on the driver for the "Asus Wireless
> Radio Control" device, as named on the vendor website, which handles
> notifications from the airplane mode hotkey and drives the airplane mode
> indicator LED. This device appears in the DSDT as "ASHS".
> 
> When the airplane mode hotkey is pressed a query 0x0B is started in the
> Embedded Controller, and all this query does is a notify ASHS with the value
> 0x88. ASHS also has one method HSWC, which can drive the airplane mode LED and
> query its status, according to its parameter.

Hi Joao,

Thanks for a detailed introduction, very helpful.

> 
> To properly drive the LED a new RFKill trigger was implemented, to track the
> global state of all RFKill switches in the system, and turn the LED ON when 
> all
> are blocked, and OFF otherwise. This code will have to go through review on
> linux-wireless, but first I wanted to get feedback on the WRC driver itself.

Apologies, I see I jumped the gun on this. I was rushed this afternoon and was
trying to avoid being the bottleneck. At least we won't have to wait long for
Johannes to decide after we're done with the review here.

> 
> There is one known issue: the airplane mode LED uses the same ID as the WLAN
> LED in asus-wmi, so at the moment to have the LED being driven correctly by
> asus-wrc I have to disable asus-wmi. Even with wapf=0, which does not register
> a WLAN LED in asus-wmi, the conflict still occurs because
> ASUS_WMI_DSTS_USER_BIT is set. Please advise on what is the best way to solve
> this problem.

I'm trying to make sense of these two, what is the common ID?

I see asus-wmi.c uses the dev_id ASUS_WMI_DEVID_WLAN_LED 0x0010012. The  ASL you
reference addresses 0x0203000F in OWGD and OWGS, but I don't yet see how they're
the same thing? Is this buried in the guts of the wmi system?

Regardless, it seems an update to asus nb wmi quirks so we don't setup rfkill
with the wmi driver at all. It would be preferable not to have to do it based on
DMI strings. Corentin, any insight you can offer here could be helpful in how to
identify these types of systems so we don't have to enumerate them one at a
time and make asus-wmi and asus-wrc play nice together.

Joao, it would be nice to consolidate on a naming scheme. hp-wireless,
dell-rbtn, *-rfill, etc. One of these should work for asus. Mousou used
asus-wireless which I'd prefer over another new term like wrc.

> 
> I've chosen to make this a separate module because this is a separate entry in
> the DSDT, and checkpatch told me to add an entry in MAINTAINERS in this case.
> Please let me know if any of this should have been done differently.
> 

Are you willing to be the maintainer for this driver? A response to patches to
this list within a week or so is all that's really required. This subsystem
depends on people with the hardware to help keep it it good shape.

-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" 
in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to