From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Shtylyov Subject: Re: [RFC PATCH] usb/acpi: Add support usb port power off mechanism for device fixed on the motherboard Date: Sat, 12 May 2012 16:47:58 +0400 Message-ID: <4FAE5BFE.4000904@mvista.com> References: <4FAD3A51.4010803@intel.com> <20120511181256.GD18754@xanatos> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-lpp01m010-f46.google.com ([209.85.215.46]:60348 "EHLO mail-lpp01m010-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751786Ab2ELMs3 (ORCPT ); Sat, 12 May 2012 08:48:29 -0400 Received: by lahd3 with SMTP id d3so2464682lah.19 for ; Sat, 12 May 2012 05:48:27 -0700 (PDT) In-Reply-To: <20120511181256.GD18754@xanatos> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Sarah Sharp Cc: Alan Stern , Lan Tianyu , lenb@kernel.org, gregkh@linuxfoundation.org, linux-acpi@vger.kernel.org, linux-usb@vger.kernel.org Hello. On 11-05-2012 22:12, Sarah Sharp wrote: >>> For external ports, this should be associated with sys file control. The users >>> need to determine when they should be power off. >> You don't mean "external", you mean "not described as unconnectable by >> ACPI". >>> So I should work on the external ports without devices firstly and >>> add the sys file for user to control? >> Yes, I think so. It will be less controversial and probably simpler. >> When that mechanism is ready, you should be able to use it >> automatically for unconnectable ports. >> One tricky thing: In theory, there should be a separate sysfs file for >> each port. That seems like a lot of overhead though; is there any way >> to present the information in a single file that won't offend sysfs >> purists? > Tianyu proposed having one file per hub, with a bit field that > controlled each port power. However, I was concerned about different > userspace applications racing with each other to turn or off ports. For > example, one app could read the bit field, attempt to power off just > port 1, but before it can write to the sysfs file, a second app powers > on port2, and the first app then writes to the sysfs file, leaving port > 1 powered off, and port 2 powered off, which is not what the second app > wanted. > But if you can think of a better way to coalesce the port power off > mechanisms into one file, we're all ears. :) How about two files? You write 1 to the bit that matcheas port you want powered on in the 'poweron' file, and vice versa, you write 1 to the bit that matches port you want powered off in the 'poweroff' file. > Sarah Sharp WBR, Sergei