[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1453721243.19708.16.camel@suse.com>
Date: Mon, 25 Jan 2016 12:27:23 +0100
From: Oliver Neukum <oneukum@...e.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Michal Malý <madcatxster@...oid-pointer.net>,
Bjørn Mork <bjorn@...k.no>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
dmitry.torokhov@...il.com, jikos@...nel.org, elias.vds@...il.com,
edwin@...ds.nl, simon@...gewell.org
Subject: Re: [PATCH 0/2] Add a skeleton module to perform a basic
initialization on certain USB devices
On Sun, 2016-01-24 at 14:48 -0800, Greg KH wrote:
> On Sun, Jan 24, 2016 at 11:05:05PM +0100, Oliver Neukum wrote:
> > On Sat, 2016-01-23 at 08:39 -0800, Greg KH wrote:
> > > Have your program install a udev rule to make it run automatically
> > > when
> > > the device is plugged in, and then just file a bug with the different
> > > distros to have them pick up your program and add it to their
> > > releases.
> > > With free services like Github to host the code, and OBS to build
> > > packages for every different distro out there, there has never been an
> > > easier time to get programs to distros.
> > >
> > > So please just do this in userspace, we don't like to take kernel
> > > drivers for functions that can be done in userspace.
> >
> > That raises a point. If we wish to do port power switching
> > as a form of runtime PM, we will need to do mode switching
> > in kernel space. The notion that this can be done in user space
> > is likely to become wrong as things develop.
>
> Maybe, if a device doesn't remember it's "mode" after sleeping, then it
> might get messy, it will be interesting to see how that works out over
> time...
We are cutting power. So unless they have a battery or are self powered,
I don't see how they could retain their mode. But it is a mess.
Regards
Oliver
Powered by blists - more mailing lists