linux-kernel - Re: [PATCH] usb: udc: add gadget state kobject uevent

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Jul 2013 16:33:43 +0800
From:	Rong Wang <wr011235813@...il.com>
To:	balbi@...com
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, Rong.Wang@....com
Subject: Re: [PATCH] usb: udc: add gadget state kobject uevent

On Wed, Jul 17, 2013 at 9:27 PM, Felipe Balbi <balbi@...com> wrote:
> On Wed, Jul 17, 2013 at 09:04:54PM +0800, Rong Wang wrote:
>> Hi Felipe,
>>
>> On Wed, Jul 17, 2013 at 3:57 PM, Felipe Balbi <balbi@...com> wrote:
>> > Hi,
>> >
>> > On Mon, Jul 15, 2013 at 11:31:17PM -0700, Greg KH wrote:
>> >> > The question is since we default GADGET, so the g_mass_storage.ko is
>> >> > installed early but connecting to a host PC
>> >> > is randomly, But the udev has no idea when a host PC connects our device.
>> >> >
>> >> > So we consider it's reasonable to let the udev know the GADGET device state.
>> >> > Is there any alternative to our question?
>> >>
>> >> I thought we already export events for gadget device states, have you
>> >> looked for them?  I can't dig through the code at the moment, but this
>> >> seems like a pretty common issue...
>> >>
>> >> Felipe, any ideas?
>> >
>> > we already expose that in sysfs. IIRC udev can act on sysfs changes,
>> > no ?
>>
>> I do not know if udev can polling sysfs file content change. I'll study this.
>>
>> But the change is triggered by calling usb_gadget_set_state, and I find
>> composite framework do not call this. Then we should do this common work
>> in every udc driver?
>
> yes. Only the UDC driver knows when the controller is moving among those
> states.

OK. I got that.

But I think it may be more reasonable for the udc driver to maintain a
work queue
to handle the state change since this operation mostly happen in ISR ?


>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/