Prev: EFI runtime-services on x86_64
Next: kcryptd oops when resuming with TuxOnIce with KDBoops afterwards
From: Greg KH on 30 Jul 2010 17:30 On Fri, Jul 30, 2010 at 11:57:35AM -0700, David Brownell wrote: > > > > > We shouldn't be using _any_ netchip > > ids anymore now that we > > have our own vendor id assigned to us. > > That's too extreme; the original handful of > NetChip IDs were (and are!!) correctly assigned, > and there's no reason to change them. In fact, > there's a lot of reason to continue using them > while config files and drivers expect to see > those specific IDs (as is reasonable). That's > to avoid breaking working configs... True, I was thinking that for the class-type devices, we could use the linux foundation vid, as changing them shouldn't matter right? Or does Windows really care about the vid/pid for a class device somehow? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 30 Jul 2010 18:20 On Fri, Jul 30, 2010 at 03:01:50PM -0700, David Brownell wrote: > > > > That's too extreme; the original handful of > > > NetChip IDs were (and are!!) correctly assigned, > > > and there's no reason to change them.� In fact, > > > there's a lot of reason to continue using them > > > while config files and drivers expect to see > > > those specific IDs (as is reasonable).� That's > > > to avoid breaking working configs... > > > > True, I was thinking that for the class-type devices, we > > could use the > > linux foundation vid, as changing them shouldn't > > matter right? > > There are INF files using NetChip IDs, so > changing them would break stuff. > > Newer interfaces using new VIDS/PIDS? Fine. > > > > Or does Windows really care about the vid/pid for > > a class device somehow? > > My understanding is that it does, since it really > doesn't have a good concept of "class" being the > generic thing. INF files embed VIDS/PIDS even > for drivers implementing class specs. MSFT was > being stupid again... Ok, fair enough. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michał Nazarewicz on 2 Aug 2010 13:20 > On Fri, Jul 30, 2010 at 06:48:41PM +0200, Michał Nazarewicz wrote: >> So, to fix the situation, I need to ask Greg for the IDs? On Fri, 30 Jul 2010 18:54:50 +0200, Greg KH <greg(a)kroah.com> wrote: > Yes you do. Could I ask for two IDs then. One for the Multifunction Composite Gadget (g_multi) and another for FunctionFS Gadget (g_ffs). Or is there some kind of procedure for that? Again, sorry for all the confusion. As soon as the gadgets will get their own IDs I'll repost the patches with fixed IDs and David's suggestions taken into consideration. -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 2 Aug 2010 19:00
On Mon, Aug 02, 2010 at 07:14:08PM +0200, Michał Nazarewicz wrote: > >On Fri, Jul 30, 2010 at 06:48:41PM +0200, Michał Nazarewicz wrote: > >>So, to fix the situation, I need to ask Greg for the IDs? > > On Fri, 30 Jul 2010 18:54:50 +0200, Greg KH <greg(a)kroah.com> wrote: > >Yes you do. > > Could I ask for two IDs then. One for the Multifunction Composite > Gadget (g_multi) You now have device id 0104 reserved for this. > and another for FunctionFS Gadget (g_ffs). You now have device id 0105 reserved for this. > Or is there some kind of procedure for that? Heh, nope, you just have to ask and have code that needs it. To keep everyone straight, here's the currently reserved device ids managed by us: 1d6b Linux Foundation 0001 1.1 root hub 0002 2.0 root hub 0003 3.0 root hub 0100 PTP Gadget 0101 Audio Gadget 0102 EEM Gadget 0103 NCM (Ethernet) Gadget 0104 Multifunction Composite Gadget 0105 FunctionFS Gadget thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |