All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: David Brownell <david-b@pacbell.net>
Cc: linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, Patrick Mochel <mochel@osdl.org>
Subject: Re: [linux-usb-devel] [RFC] USB driver conversion to "struct device_driver" for 2.5.32
Date: Thu, 29 Aug 2002 20:46:46 -0700	[thread overview]
Message-ID: <20020830034646.GA6486@kroah.com> (raw)
In-Reply-To: <3D6EB333.7050509@pacbell.net>

For the lkml readers, my original post (with patch) didn't seem to go
through to that list, it can be found at:
	http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103065990107372

On Thu, Aug 29, 2002 at 04:50:11PM -0700, David Brownell wrote:
> So to be sure I've got this right ... those modified driver
> entry points change things as follows:
> 
> >+	int (*probe) (struct usb_interface *intf,
> >+		      const struct usb_device_id *id);
> 
>  (a) the device (for urbs etc) is now implicit:
>        struct usb_device *dev = interface_to_usbdev (int):

Yes.

>  (b) the interface index should no longer matter

Yes.  But for those drivers that do care, they can get it with the new
usb_if_to_ifnum() function.  This will provide the _correct_ interface
number, the old interface only provided the index, which people seemed
to use as the ifnum.

>  (c) returns 0 (not void *) or -Errno (not null)

Yes.

>  (d) that void * handle is explicitly intf->dev.driver_data

Yes.  dev.driver_data should be wrapped by a function, like
pci_set_drvdata() and pci_get_drvdata() are for.

> >+	void (*disconnect) (struct usb_interface *intf);
> 
>   (a) and (d) above: same change

exactly.

> Makes me wonder about intf->private_data, which was the
> original version of intf->dev.driver_data.  Shouldn't that
> be removed too?

Yes it should.

> It's only used in the interface claiming calls (shouldn't they fit in
> with the driver model?) and usbfs just now.  Is that the usbfs work
> you mentioned?

Yes, that's the part that I am pretty sure is not working properly right
now, and is next on my list of things to clean up.

thanks,

greg k-h

      reply	other threads:[~2002-08-30  3:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-22 20:44 [RFC] USB driver conversion to "struct device_driver" for 2.5.31 Greg KH
2002-08-23 19:31 ` Greg KH
     [not found] ` <20020829221339.GA5074@kroah.com>
2002-08-29 23:50   ` [linux-usb-devel] [RFC] USB driver conversion to "struct device_driver" for 2.5.32 David Brownell
2002-08-30  3:46     ` Greg KH [this message]

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=20020830034646.GA6486@kroah.com \
    --to=greg@kroah.com \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=mochel@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.