public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Nate <stoddarn@msoe.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Restricting CDC-ACM devices
Date: Wed, 22 Aug 2007 14:47:12 -0700	[thread overview]
Message-ID: <20070822214712.GA4046@kroah.com> (raw)
In-Reply-To: <17603.12.191.136.2.1187819526.squirrel@myweb.msoe.edu>

On Wed, Aug 22, 2007 at 04:52:06PM -0500, Nate wrote:
> Thank you for your responses.  Please don't take my repeated questioning
> of your answers as me being difficult, I'm just trying to get a better
> understanding.
> 
> 
> > Well, just messing with the device ids is not that tough of a patch to
> > keep up to date over time, so you might just try that if necessary.
> 
> That is a good point.  I may also be adding some extra logic to check
> other fields to confirm compatibility before allowing a usb device to be
> bound to the CDC-ACM driver.  That is still probably pretty small piece of
> code in the probe function, but I'm just concerned that over time more
> logic would be added and other developers will be maintaining the code.

Well, this is of course the easiest way to achive what you are wanting
to do.  Only you can answer the "how I'm going to maintain this in the
future" question :)

> > Yes.  You can manually bind and unbind all PCI and USB devices from
> > their drivers from userspace.  So you do have full control over this
> > already, no kernel changes needed.
> 
> Does this require my userspace applications to poll the USB devices
> (/proc/bus/usb/devices) and then disconnect/connect my driver every time a
> USB device using CDC-ACM is connected?  Is this what is normally done? 
> Does this cause a noticeable performance hit when the driver is cycled
> like this?  If I don't enable CDC-ACM in make menuconfig, can I still bind
> it to a USB device from userspace?

No, you still need the driver to be around :)

Anyway, you can get a notification from udev whenever a device is bound
to the cdc-acm driver, and then trigger your "disconnect/connect" script
on that.

> I don't know if this matters, but I wanted to add some use case details:
> This driver will be running on a <200 MHz processor and there can be a
> number of connects/disconnect of the device in a short time from the
> users.

I don't know how fast the above will all work out, you are going to have
to test it yourself, sorry.

hope this helps,

greg k-h

  reply	other threads:[~2007-08-22 22:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1187716018.731090.165620@j4g2000prf.googlegroups.com>
     [not found] ` <20070821171018.C964B5F778@attila.bofh.it>
2007-08-21 22:03   ` Restricting CDC-ACM devices Nate
2007-08-22  5:46     ` Greg KH
2007-08-22 14:41       ` Nate
2007-08-22 18:55         ` Greg KH
2007-08-22 21:52           ` Nate
2007-08-22 21:47             ` Greg KH [this message]
2007-08-27 15:58               ` Nate

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070822214712.GA4046@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stoddarn@msoe.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox