Re: USB: second device of same type not detected

Hi mr. Holan,

I have removed the serial number string descriptor from firmware
and now the driver handles multiple device instances.

Thank a lot for your suggestion,
PaoloC

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 06, 2004 9:48 PM
Subject: RE: [ntdev] 1394: second device of same type not detected

Read the USB 1.1 core specification. It is a special string descriptor.
Given that you don’t know what it is, I doubt your device has one.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
Sent: Tuesday, January 06, 2004 12:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394: second device of same type not detected

For DID I mean the Version Number of device descriptor.

Please, what do you mean for “unique serial number” ?

Thank you,
PaoloC

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 06, 2004 4:47 PM
Subject: RE: [ntdev] 1394: second device of same type not detected

Not sure what you mean by DID, but here is the general gist:

if your device has a serial number and 2 devices are plugged in with the
same serial number, the second will not be reported to the OS or the
machine will bugcheck (depends on the version of the USB stack). If
your device does not have a unique serial number, then for each port the
device is plugged into, it will be treated as a new device and there can
be as many of your device as there are ports.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
Sent: Tuesday, January 06, 2004 7:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394: second device of same type not detected

Does anybody know if the same problem (unique device ID) exists for USB
devices too ?
I am working on a USB driver & I am not able to load 2 devices with the
same
VID+PID+DID !

Best regards & happy new year,
PaoloC

----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 06, 2004 5:59 PM
Subject: Re: [ntdev] 1394: second device of same type not detected

> Robert Newton wrote:
>
> >>I developing a WDM driver for a firewire device. I used the 1394Diag
> >>example form the ddk as a starting point.
> >>I’m having some trouble detecting more than one device of the same
type
> >>(a device with same vendor and device id). The second device is
simply
> >>not detected. I’m getting a bus reset if the cable is plugged, but
thats
> >>all. The add_device function is not called.
> >>
> >>
> >
> >I’m not completely sure what id’s you’re working with. The
> >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> >vendor_id, chip_id_hi and chip_id_low.
> >
> >Vendor id should be an
> >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> >choose (split between device type id and device instance) however at
> >the end of the day, each device must have a unique number. (Although
I
> >have never experimented with giving 2 devices the same id so I can’t
> >say what happens when you do this.)
> >
> >Doing this I have never had any trouble getting multiple instances of
> >a device to show up at the same time.
> >
> >Rob
> >xxxxx@telusplanet.net
> >
> >
> Thank you for your clarification. It seems that the second device with
> the same id is not detected and that is what should happen because the
> ids must be unique.
> But what about the .inf file of a driver. My .inf file looks like
this:
> …
> [DeviceList]
> %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> …
> The “a35” is the OUI, but what about the “&1”. I thought that would be
> the device type id somehow. You said the other 48 bit are split
between
> device type id and device instance. The other 48 bit are set to
0xea68
> in my case (chip id high = 0). At the moment I don’t know where to
find
> the .inf-file equivalent of the device type in the config ROM .
> Thanks
> Uwe
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@tin.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@tin.it
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@tin.it
To unsubscribe send a blank email to xxxxx@lists.osr.com

You shouldn’t remove the string, rather the string should be unique for each
device. If you don’t have a string that creates more problems. Namely,
everytime you unplug the device and plug it into another port, that same
device will show up as a new device to Windows and will require you to
reload the drivers. If the device has a unique serial number string, then
the system will recognize the device wherever it is plugged in after drivers
have been loaded once. The string has to be unique per device however,
hence the name “serial number”. Sounds like you need to beat on your
firmware people to read the USB specs.


Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashua/patches/utility.htm

“PaoloC” wrote in message news:xxxxx@ntdev…
> Hi mr. Holan,
>
> I have removed the serial number string descriptor from firmware
> and now the driver handles multiple device instances.
>
> Thank a lot for your suggestion,
> PaoloC
>
>
> ----- Original Message -----
> From: “Doron Holan”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, January 06, 2004 9:48 PM
> Subject: RE: [ntdev] 1394: second device of same type not detected
>
>
> Read the USB 1.1 core specification. It is a special string descriptor.
> Given that you don’t know what it is, I doubt your device has one.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> Sent: Tuesday, January 06, 2004 12:43 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 1394: second device of same type not detected
>
> For DID I mean the Version Number of device descriptor.
>
> Please, what do you mean for “unique serial number” ?
>
> Thank you,
> PaoloC
>
> ----- Original Message -----
> From: “Doron Holan”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, January 06, 2004 4:47 PM
> Subject: RE: [ntdev] 1394: second device of same type not detected
>
>
> Not sure what you mean by DID, but here is the general gist:
>
> if your device has a serial number and 2 devices are plugged in with the
> same serial number, the second will not be reported to the OS or the
> machine will bugcheck (depends on the version of the USB stack). If
> your device does not have a unique serial number, then for each port the
> device is plugged into, it will be treated as a new device and there can
> be as many of your device as there are ports.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> Sent: Tuesday, January 06, 2004 7:13 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] 1394: second device of same type not detected
>
> Does anybody know if the same problem (unique device ID) exists for USB
> devices too ?
> I am working on a USB driver & I am not able to load 2 devices with the
> same
> VID+PID+DID !
>
> Best regards & happy new year,
> PaoloC
>
> ----- Original Message -----
> From: “uwe kirst”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, January 06, 2004 5:59 PM
> Subject: Re: [ntdev] 1394: second device of same type not detected
>
>
> > Robert Newton wrote:
> >
> > >>I developing a WDM driver for a firewire device. I used the 1394Diag
> > >>example form the ddk as a starting point.
> > >>I’m having some trouble detecting more than one device of the same
> type
> > >>(a device with same vendor and device id). The second device is
> simply
> > >>not detected. I’m getting a bus reset if the cable is plugged, but
> thats
> > >>all. The add_device function is not called.
> > >>
> > >>
> > >
> > >I’m not completely sure what id’s you’re working with. The
> > >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> > >vendor_id, chip_id_hi and chip_id_low.
> > >
> > >Vendor id should be an
> > >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> > >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> > >choose (split between device type id and device instance) however at
> > >the end of the day, each device must have a unique number. (Although
> I
> > >have never experimented with giving 2 devices the same id so I can’t
> > >say what happens when you do this.)
> > >
> > >Doing this I have never had any trouble getting multiple instances of
> > >a device to show up at the same time.
> > >
> > >Rob
> > >xxxxx@telusplanet.net
> > >
> > >
> > Thank you for your clarification. It seems that the second device with
> > the same id is not detected and that is what should happen because the
> > ids must be unique.
> > But what about the .inf file of a driver. My .inf file looks like
> this:
> > …
> > [DeviceList]
> > %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> > …
> > The “a35” is the OUI, but what about the “&1”. I thought that would be
> > the device type id somehow. You said the other 48 bit are split
> between
> > device type id and device instance. The other 48 bit are set to
> 0xea68
> > in my case (chip id high = 0). At the moment I don’t know where to
> find
> > the .inf-file equivalent of the device type in the config ROM .
> > Thanks
> > Uwe
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@tin.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@tin.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

Well, I will not be surprised if having the repeating unique IDs will cause
the OS to skip this device at all. I will neither be annoyed by this.

Sorry, but if the spec says “unique ID” - then you must provide the really
unique ID, and guarantee them to never repeat. If you cannot provide the
uniqueness guarantee - then just skip this ID, this is allowed by the USB spec.

Yes, having no unique ID (which is allowed) will surely lead to
consequences described by Bill - USBHUB will report the device as “having no
unique ID”, and thus Windows will treat each device insertion as a “new device”
(and yes, will create a new unique registry keys for it), will run INFs each
time, will bother the user each time and so on. Nevertheless, this is not a
spec violation, and this is at least predictable. But if the “unique ID”
repeats - then this is unpredictable, and Windows can behave any way with this.

I see no problem in Windows if it does not support the USB device with a
major USB spec violation.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Bill McKenzie”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 08, 2004 6:42 PM
Subject: Re:[ntdev] USB: second device of same type not detected

> You shouldn’t remove the string, rather the string should be unique for each
> device. If you don’t have a string that creates more problems. Namely,
> everytime you unplug the device and plug it into another port, that same
> device will show up as a new device to Windows and will require you to
> reload the drivers. If the device has a unique serial number string, then
> the system will recognize the device wherever it is plugged in after drivers
> have been loaded once. The string has to be unique per device however,
> hence the name “serial number”. Sounds like you need to beat on your
> firmware people to read the USB specs.
>
> –
> Bill McKenzie
> Compuware Corporation
> Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
> http://frontline.compuware.com/nashua/patches/utility.htm
>
>
> “PaoloC” wrote in message news:xxxxx@ntdev…
> > Hi mr. Holan,
> >
> > I have removed the serial number string descriptor from firmware
> > and now the driver handles multiple device instances.
> >
> > Thank a lot for your suggestion,
> > PaoloC
> >
> >
> > ----- Original Message -----
> > From: “Doron Holan”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 9:48 PM
> > Subject: RE: [ntdev] 1394: second device of same type not detected
> >
> >
> > Read the USB 1.1 core specification. It is a special string descriptor.
> > Given that you don’t know what it is, I doubt your device has one.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > Sent: Tuesday, January 06, 2004 12:43 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> > For DID I mean the Version Number of device descriptor.
> >
> > Please, what do you mean for “unique serial number” ?
> >
> > Thank you,
> > PaoloC
> >
> > ----- Original Message -----
> > From: “Doron Holan”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 4:47 PM
> > Subject: RE: [ntdev] 1394: second device of same type not detected
> >
> >
> > Not sure what you mean by DID, but here is the general gist:
> >
> > if your device has a serial number and 2 devices are plugged in with the
> > same serial number, the second will not be reported to the OS or the
> > machine will bugcheck (depends on the version of the USB stack). If
> > your device does not have a unique serial number, then for each port the
> > device is plugged into, it will be treated as a new device and there can
> > be as many of your device as there are ports.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > Sent: Tuesday, January 06, 2004 7:13 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> > Does anybody know if the same problem (unique device ID) exists for USB
> > devices too ?
> > I am working on a USB driver & I am not able to load 2 devices with the
> > same
> > VID+PID+DID !
> >
> > Best regards & happy new year,
> > PaoloC
> >
> > ----- Original Message -----
> > From: “uwe kirst”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 5:59 PM
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> >
> > > Robert Newton wrote:
> > >
> > > >>I developing a WDM driver for a firewire device. I used the 1394Diag
> > > >>example form the ddk as a starting point.
> > > >>I’m having some trouble detecting more than one device of the same
> > type
> > > >>(a device with same vendor and device id). The second device is
> > simply
> > > >>not detected. I’m getting a bus reset if the cable is plugged, but
> > thats
> > > >>all. The add_device function is not called.
> > > >>
> > > >>
> > > >
> > > >I’m not completely sure what id’s you’re working with. The
> > > >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> > > >vendor_id, chip_id_hi and chip_id_low.
> > > >
> > > >Vendor id should be an
> > > >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> > > >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> > > >choose (split between device type id and device instance) however at
> > > >the end of the day, each device must have a unique number. (Although
> > I
> > > >have never experimented with giving 2 devices the same id so I can’t
> > > >say what happens when you do this.)
> > > >
> > > >Doing this I have never had any trouble getting multiple instances of
> > > >a device to show up at the same time.
> > > >
> > > >Rob
> > > >xxxxx@telusplanet.net
> > > >
> > > >
> > > Thank you for your clarification. It seems that the second device with
> > > the same id is not detected and that is what should happen because the
> > > ids must be unique.
> > > But what about the .inf file of a driver. My .inf file looks like
> > this:
> > > …
> > > [DeviceList]
> > > %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> > > …
> > > The “a35” is the OUI, but what about the “&1”. I thought that would be
> > > the device type id somehow. You said the other 48 bit are split
> > between
> > > device type id and device instance. The other 48 bit are set to
> > 0xea68
> > > in my case (chip id high = 0). At the moment I don’t know where to
> > find
> > > the .inf-file equivalent of the device type in the config ROM .
> > > Thanks
> > > Uwe
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Well, I call it “flexibility” - the ability of giving the programmer leeway
enough to compensate for problems in the hardware. There should be a way to
accomodate it somehow. Heck, it used to be that software was written to the
hardware, eh ? Not the other way around.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Thursday, January 08, 2004 11:38 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] USB: second device of same type not detected

Well, I will not be surprised if having the repeating unique IDs will
cause
the OS to skip this device at all. I will neither be annoyed by this.

Sorry, but if the spec says “unique ID” - then you must provide the
really
unique ID, and guarantee them to never repeat. If you cannot provide the
uniqueness guarantee - then just skip this ID, this is allowed by the USB
spec.

Yes, having no unique ID (which is allowed) will surely lead to
consequences described by Bill - USBHUB will report the device as “having no
unique ID”, and thus Windows will treat each device insertion as a “new
device”
(and yes, will create a new unique registry keys for it), will run INFs each
time, will bother the user each time and so on. Nevertheless, this is not a
spec violation, and this is at least predictable. But if the “unique ID”
repeats - then this is unpredictable, and Windows can behave any way with
this.

I see no problem in Windows if it does not support the USB device with a
major USB spec violation.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Bill McKenzie”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 08, 2004 6:42 PM
Subject: Re:[ntdev] USB: second device of same type not detected

> You shouldn’t remove the string, rather the string should be unique for
each
> device. If you don’t have a string that creates more problems. Namely,
> everytime you unplug the device and plug it into another port, that same
> device will show up as a new device to Windows and will require you to
> reload the drivers. If the device has a unique serial number string, then
> the system will recognize the device wherever it is plugged in after
drivers
> have been loaded once. The string has to be unique per device however,
> hence the name “serial number”. Sounds like you need to beat on your
> firmware people to read the USB specs.
>
> –
> Bill McKenzie
> Compuware Corporation
> Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
> http://frontline.compuware.com/nashua/patches/utility.htm
>
>
> “PaoloC” wrote in message news:xxxxx@ntdev…
> > Hi mr. Holan,
> >
> > I have removed the serial number string descriptor from firmware
> > and now the driver handles multiple device instances.
> >
> > Thank a lot for your suggestion,
> > PaoloC
> >
> >
> > ----- Original Message -----
> > From: “Doron Holan”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 9:48 PM
> > Subject: RE: [ntdev] 1394: second device of same type not detected
> >
> >
> > Read the USB 1.1 core specification. It is a special string descriptor.
> > Given that you don’t know what it is, I doubt your device has one.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > Sent: Tuesday, January 06, 2004 12:43 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> > For DID I mean the Version Number of device descriptor.
> >
> > Please, what do you mean for “unique serial number” ?
> >
> > Thank you,
> > PaoloC
> >
> > ----- Original Message -----
> > From: “Doron Holan”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 4:47 PM
> > Subject: RE: [ntdev] 1394: second device of same type not detected
> >
> >
> > Not sure what you mean by DID, but here is the general gist:
> >
> > if your device has a serial number and 2 devices are plugged in with the
> > same serial number, the second will not be reported to the OS or the
> > machine will bugcheck (depends on the version of the USB stack). If
> > your device does not have a unique serial number, then for each port the
> > device is plugged into, it will be treated as a new device and there can
> > be as many of your device as there are ports.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > Sent: Tuesday, January 06, 2004 7:13 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> > Does anybody know if the same problem (unique device ID) exists for USB
> > devices too ?
> > I am working on a USB driver & I am not able to load 2 devices with the
> > same
> > VID+PID+DID !
> >
> > Best regards & happy new year,
> > PaoloC
> >
> > ----- Original Message -----
> > From: “uwe kirst”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 5:59 PM
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> >
> > > Robert Newton wrote:
> > >
> > > >>I developing a WDM driver for a firewire device. I used the 1394Diag
> > > >>example form the ddk as a starting point.
> > > >>I’m having some trouble detecting more than one device of the same
> > type
> > > >>(a device with same vendor and device id). The second device is
> > simply
> > > >>not detected. I’m getting a bus reset if the cable is plugged, but
> > thats
> > > >>all. The add_device function is not called.
> > > >>
> > > >>
> > > >
> > > >I’m not completely sure what id’s you’re working with. The
> > > >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> > > >vendor_id, chip_id_hi and chip_id_low.
> > > >
> > > >Vendor id should be an
> > > >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> > > >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> > > >choose (split between device type id and device instance) however at
> > > >the end of the day, each device must have a unique number. (Although
> > I
> > > >have never experimented with giving 2 devices the same id so I can’t
> > > >say what happens when you do this.)
> > > >
> > > >Doing this I have never had any trouble getting multiple instances of
> > > >a device to show up at the same time.
> > > >
> > > >Rob
> > > >xxxxx@telusplanet.net
> > > >
> > > >
> > > Thank you for your clarification. It seems that the second device with
> > > the same id is not detected and that is what should happen because the
> > > ids must be unique.
> > > But what about the .inf file of a driver. My .inf file looks like
> > this:
> > > …
> > > [DeviceList]
> > > %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> > > …
> > > The “a35” is the OUI, but what about the “&1”. I thought that would be
> > > the device type id somehow. You said the other 48 bit are split
> > between
> > > device type id and device instance. The other 48 bit are set to
> > 0xea68
> > > in my case (chip id high = 0). At the moment I don’t know where to
> > find
> > > the .inf-file equivalent of the device type in the config ROM .
> > > Thanks
> > > Uwe
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

Thank you for you explication Bill.

My device is a Cypress EzUsb MCU which doesn’t have any firmware loaded.
When device is plugged the driver is loaded, detects the default VID+PID and
loads the firmware
which has a different VID+PID.
Device disconnects USB and then reconnects with the new VID+PID.
So the driver is unloaded & then load again.
I am not interested in which port the device is plugged in & I do not known
how many devices will
be connected to the system.
So I think that removing the string descriptor may solve the problem of my
specific application.
Otherwise I will have to modify the driver to patch the firmware with a
unique serial number when performing
the firmware load process.

Best regards,
PaoloC

----- Original Message -----
From: “Bill McKenzie”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 08, 2004 4:42 PM
Subject: Re:[ntdev] USB: second device of same type not detected

> You shouldn’t remove the string, rather the string should be unique for
each
> device. If you don’t have a string that creates more problems. Namely,
> everytime you unplug the device and plug it into another port, that same
> device will show up as a new device to Windows and will require you to
> reload the drivers. If the device has a unique serial number string, then
> the system will recognize the device wherever it is plugged in after
drivers
> have been loaded once. The string has to be unique per device however,
> hence the name “serial number”. Sounds like you need to beat on your
> firmware people to read the USB specs.
>
> –
> Bill McKenzie
> Compuware Corporation
> Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
> http://frontline.compuware.com/nashua/patches/utility.htm
>
>
> “PaoloC” wrote in message news:xxxxx@ntdev…
> > Hi mr. Holan,
> >
> > I have removed the serial number string descriptor from firmware
> > and now the driver handles multiple device instances.
> >
> > Thank a lot for your suggestion,
> > PaoloC
> >
> >
> > ----- Original Message -----
> > From: “Doron Holan”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 9:48 PM
> > Subject: RE: [ntdev] 1394: second device of same type not detected
> >
> >
> > Read the USB 1.1 core specification. It is a special string descriptor.
> > Given that you don’t know what it is, I doubt your device has one.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > Sent: Tuesday, January 06, 2004 12:43 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> > For DID I mean the Version Number of device descriptor.
> >
> > Please, what do you mean for “unique serial number” ?
> >
> > Thank you,
> > PaoloC
> >
> > ----- Original Message -----
> > From: “Doron Holan”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 4:47 PM
> > Subject: RE: [ntdev] 1394: second device of same type not detected
> >
> >
> > Not sure what you mean by DID, but here is the general gist:
> >
> > if your device has a serial number and 2 devices are plugged in with the
> > same serial number, the second will not be reported to the OS or the
> > machine will bugcheck (depends on the version of the USB stack). If
> > your device does not have a unique serial number, then for each port the
> > device is plugged into, it will be treated as a new device and there can
> > be as many of your device as there are ports.
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > Sent: Tuesday, January 06, 2004 7:13 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> > Does anybody know if the same problem (unique device ID) exists for USB
> > devices too ?
> > I am working on a USB driver & I am not able to load 2 devices with the
> > same
> > VID+PID+DID !
> >
> > Best regards & happy new year,
> > PaoloC
> >
> > ----- Original Message -----
> > From: “uwe kirst”
> > To: “Windows System Software Devs Interest List”
> > Sent: Tuesday, January 06, 2004 5:59 PM
> > Subject: Re: [ntdev] 1394: second device of same type not detected
> >
> >
> > > Robert Newton wrote:
> > >
> > > >>I developing a WDM driver for a firewire device. I used the 1394Diag
> > > >>example form the ddk as a starting point.
> > > >>I’m having some trouble detecting more than one device of the same
> > type
> > > >>(a device with same vendor and device id). The second device is
> > simply
> > > >>not detected. I’m getting a bus reset if the cable is plugged, but
> > thats
> > > >>all. The add_device function is not called.
> > > >>
> > > >>
> > > >
> > > >I’m not completely sure what id’s you’re working with. The
> > > >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> > > >vendor_id, chip_id_hi and chip_id_low.
> > > >
> > > >Vendor id should be an
> > > >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> > > >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> > > >choose (split between device type id and device instance) however at
> > > >the end of the day, each device must have a unique number. (Although
> > I
> > > >have never experimented with giving 2 devices the same id so I can’t
> > > >say what happens when you do this.)
> > > >
> > > >Doing this I have never had any trouble getting multiple instances of
> > > >a device to show up at the same time.
> > > >
> > > >Rob
> > > >xxxxx@telusplanet.net
> > > >
> > > >
> > > Thank you for your clarification. It seems that the second device with
> > > the same id is not detected and that is what should happen because the
> > > ids must be unique.
> > > But what about the .inf file of a driver. My .inf file looks like
> > this:
> > > …
> > > [DeviceList]
> > > %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> > > …
> > > The “a35” is the OUI, but what about the “&1”. I thought that would be
> > > the device type id somehow. You said the other 48 bit are split
> > between
> > > device type id and device instance. The other 48 bit are set to
> > 0xea68
> > > in my case (chip id high = 0). At the moment I don’t know where to
> > find
> > > the .inf-file equivalent of the device type in the config ROM .
> > > Thanks
> > > Uwe
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@tin.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Okay, well a distinction should be made here. If this device is just for
you, or for your lab or what not, then by all means go the easiest route.
However, if this setup is going to find itself in a mass or semi-mass
produced hardware product, then you really ought to consider some scheme to
implement the serial number. It wouldn’t be that hard, and the user
experience would be worlds better. Like Max said, you won’t be violating
spec or anything. I just believe in making the customer’s experience as
pleasant as is reasonably possible. Just my $0.02.


Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashua/patches/utility.htm

“PaoloC” wrote in message news:xxxxx@ntdev…
> Thank you for you explication Bill.
>
> My device is a Cypress EzUsb MCU which doesn’t have any firmware loaded.
> When device is plugged the driver is loaded, detects the default VID+PID
and
> loads the firmware
> which has a different VID+PID.
> Device disconnects USB and then reconnects with the new VID+PID.
> So the driver is unloaded & then load again.
> I am not interested in which port the device is plugged in & I do not
known
> how many devices will
> be connected to the system.
> So I think that removing the string descriptor may solve the problem of my
> specific application.
> Otherwise I will have to modify the driver to patch the firmware with a
> unique serial number when performing
> the firmware load process.
>
> Best regards,
> PaoloC
>
> ----- Original Message -----
> From: “Bill McKenzie”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, January 08, 2004 4:42 PM
> Subject: Re:[ntdev] USB: second device of same type not detected
>
>
> > You shouldn’t remove the string, rather the string should be unique for
> each
> > device. If you don’t have a string that creates more problems. Namely,
> > everytime you unplug the device and plug it into another port, that same
> > device will show up as a new device to Windows and will require you to
> > reload the drivers. If the device has a unique serial number string,
then
> > the system will recognize the device wherever it is plugged in after
> drivers
> > have been loaded once. The string has to be unique per device however,
> > hence the name “serial number”. Sounds like you need to beat on your
> > firmware people to read the USB specs.
> >
> > –
> > Bill McKenzie
> > Compuware Corporation
> > Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
> > http://frontline.compuware.com/nashua/patches/utility.htm
> >
> >
> > “PaoloC” wrote in message news:xxxxx@ntdev…
> > > Hi mr. Holan,
> > >
> > > I have removed the serial number string descriptor from firmware
> > > and now the driver handles multiple device instances.
> > >
> > > Thank a lot for your suggestion,
> > > PaoloC
> > >
> > >
> > > ----- Original Message -----
> > > From: “Doron Holan”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Tuesday, January 06, 2004 9:48 PM
> > > Subject: RE: [ntdev] 1394: second device of same type not detected
> > >
> > >
> > > Read the USB 1.1 core specification. It is a special string
descriptor.
> > > Given that you don’t know what it is, I doubt your device has one.
> > >
> > > d
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > > Sent: Tuesday, January 06, 2004 12:43 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 1394: second device of same type not detected
> > >
> > > For DID I mean the Version Number of device descriptor.
> > >
> > > Please, what do you mean for “unique serial number” ?
> > >
> > > Thank you,
> > > PaoloC
> > >
> > > ----- Original Message -----
> > > From: “Doron Holan”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Tuesday, January 06, 2004 4:47 PM
> > > Subject: RE: [ntdev] 1394: second device of same type not detected
> > >
> > >
> > > Not sure what you mean by DID, but here is the general gist:
> > >
> > > if your device has a serial number and 2 devices are plugged in with
the
> > > same serial number, the second will not be reported to the OS or the
> > > machine will bugcheck (depends on the version of the USB stack). If
> > > your device does not have a unique serial number, then for each port
the
> > > device is plugged into, it will be treated as a new device and there
can
> > > be as many of your device as there are ports.
> > >
> > > d
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > > Sent: Tuesday, January 06, 2004 7:13 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 1394: second device of same type not detected
> > >
> > > Does anybody know if the same problem (unique device ID) exists for
USB
> > > devices too ?
> > > I am working on a USB driver & I am not able to load 2 devices with
the
> > > same
> > > VID+PID+DID !
> > >
> > > Best regards & happy new year,
> > > PaoloC
> > >
> > > ----- Original Message -----
> > > From: “uwe kirst”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Tuesday, January 06, 2004 5:59 PM
> > > Subject: Re: [ntdev] 1394: second device of same type not detected
> > >
> > >
> > > > Robert Newton wrote:
> > > >
> > > > >>I developing a WDM driver for a firewire device. I used the
1394Diag
> > > > >>example form the ddk as a starting point.
> > > > >>I’m having some trouble detecting more than one device of the same
> > > type
> > > > >>(a device with same vendor and device id). The second device is
> > > simply
> > > > >>not detected. I’m getting a bus reset if the cable is plugged, but
> > > thats
> > > > >>all. The add_device function is not called.
> > > > >>
> > > > >>
> > > > >
> > > > >I’m not completely sure what id’s you’re working with. The
> > > > >configuration ROM of each device needs a UNIQUE 64 bit id made up
of
> > > > >vendor_id, chip_id_hi and chip_id_low.
> > > > >
> > > > >Vendor id should be an
> > > > >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> > > > >other 48 bits (less if you purchase IAB instead or OUI) are yours
to
> > > > >choose (split between device type id and device instance) however
at
> > > > >the end of the day, each device must have a unique number.
(Although
> > > I
> > > > >have never experimented with giving 2 devices the same id so I
can’t
> > > > >say what happens when you do this.)
> > > > >
> > > > >Doing this I have never had any trouble getting multiple instances
of
> > > > >a device to show up at the same time.
> > > > >
> > > > >Rob
> > > > >xxxxx@telusplanet.net
> > > > >
> > > > >
> > > > Thank you for your clarification. It seems that the second device
with
> > > > the same id is not detected and that is what should happen because
the
> > > > ids must be unique.
> > > > But what about the .inf file of a driver. My .inf file looks like
> > > this:
> > > > …
> > > > [DeviceList]
> > > > %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> > > > …
> > > > The “a35” is the OUI, but what about the “&1”. I thought that would
be
> > > > the device type id somehow. You said the other 48 bit are split
> > > between
> > > > device type id and device instance. The other 48 bit are set to
> > > 0xea68
> > > > in my case (chip id high = 0). At the moment I don’t know where to
> > > find
> > > > the .inf-file equivalent of the device type in the config ROM .
> > > > Thanks
> > > > Uwe
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@tin.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

OK, write the LowerFilter to USB device class and patch the device
capabilities to indicate no unique ID capability. Also patch MN_QUERY_ID for
InstanceID.

Note: hardware is plenty and developed by many people, while Windows is
single and is responsible for running all these heaps of hardware together. So,
nothing fancy if Windows imposes requirements on hardware.

In modern world, both hardware and software is for a platform, which is
Windows + Intel’s architecture.

Also - spec-violating hardware must be fixed, and not by software patches.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Moreira, Alberto”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 08, 2004 7:48 PM
Subject: RE: Re:[ntdev] USB: second device of same type not detected

> Well, I call it “flexibility” - the ability of giving the programmer leeway
> enough to compensate for problems in the hardware. There should be a way to
> accomodate it somehow. Heck, it used to be that software was written to the
> hardware, eh ? Not the other way around.
>
> Alberto.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
> Sent: Thursday, January 08, 2004 11:38 AM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] USB: second device of same type not detected
>
>
> Well, I will not be surprised if having the repeating unique IDs will
> cause
> the OS to skip this device at all. I will neither be annoyed by this.
>
> Sorry, but if the spec says “unique ID” - then you must provide the
> really
> unique ID, and guarantee them to never repeat. If you cannot provide the
> uniqueness guarantee - then just skip this ID, this is allowed by the USB
> spec.
>
> Yes, having no unique ID (which is allowed) will surely lead to
> consequences described by Bill - USBHUB will report the device as “having no
> unique ID”, and thus Windows will treat each device insertion as a “new
> device”
> (and yes, will create a new unique registry keys for it), will run INFs each
> time, will bother the user each time and so on. Nevertheless, this is not a
> spec violation, and this is at least predictable. But if the “unique ID”
> repeats - then this is unpredictable, and Windows can behave any way with
> this.
>
> I see no problem in Windows if it does not support the USB device with a
> major USB spec violation.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Bill McKenzie”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, January 08, 2004 6:42 PM
> Subject: Re:[ntdev] USB: second device of same type not detected
>
>
> > You shouldn’t remove the string, rather the string should be unique for
> each
> > device. If you don’t have a string that creates more problems. Namely,
> > everytime you unplug the device and plug it into another port, that same
> > device will show up as a new device to Windows and will require you to
> > reload the drivers. If the device has a unique serial number string, then
> > the system will recognize the device wherever it is plugged in after
> drivers
> > have been loaded once. The string has to be unique per device however,
> > hence the name “serial number”. Sounds like you need to beat on your
> > firmware people to read the USB specs.
> >
> > –
> > Bill McKenzie
> > Compuware Corporation
> > Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
> > http://frontline.compuware.com/nashua/patches/utility.htm
> >
> >
> > “PaoloC” wrote in message news:xxxxx@ntdev…
> > > Hi mr. Holan,
> > >
> > > I have removed the serial number string descriptor from firmware
> > > and now the driver handles multiple device instances.
> > >
> > > Thank a lot for your suggestion,
> > > PaoloC
> > >
> > >
> > > ----- Original Message -----
> > > From: “Doron Holan”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Tuesday, January 06, 2004 9:48 PM
> > > Subject: RE: [ntdev] 1394: second device of same type not detected
> > >
> > >
> > > Read the USB 1.1 core specification. It is a special string descriptor.
> > > Given that you don’t know what it is, I doubt your device has one.
> > >
> > > d
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > > Sent: Tuesday, January 06, 2004 12:43 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 1394: second device of same type not detected
> > >
> > > For DID I mean the Version Number of device descriptor.
> > >
> > > Please, what do you mean for “unique serial number” ?
> > >
> > > Thank you,
> > > PaoloC
> > >
> > > ----- Original Message -----
> > > From: “Doron Holan”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Tuesday, January 06, 2004 4:47 PM
> > > Subject: RE: [ntdev] 1394: second device of same type not detected
> > >
> > >
> > > Not sure what you mean by DID, but here is the general gist:
> > >
> > > if your device has a serial number and 2 devices are plugged in with the
> > > same serial number, the second will not be reported to the OS or the
> > > machine will bugcheck (depends on the version of the USB stack). If
> > > your device does not have a unique serial number, then for each port the
> > > device is plugged into, it will be treated as a new device and there can
> > > be as many of your device as there are ports.
> > >
> > > d
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
> > > Sent: Tuesday, January 06, 2004 7:13 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] 1394: second device of same type not detected
> > >
> > > Does anybody know if the same problem (unique device ID) exists for USB
> > > devices too ?
> > > I am working on a USB driver & I am not able to load 2 devices with the
> > > same
> > > VID+PID+DID !
> > >
> > > Best regards & happy new year,
> > > PaoloC
> > >
> > > ----- Original Message -----
> > > From: “uwe kirst”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Tuesday, January 06, 2004 5:59 PM
> > > Subject: Re: [ntdev] 1394: second device of same type not detected
> > >
> > >
> > > > Robert Newton wrote:
> > > >
> > > > >>I developing a WDM driver for a firewire device. I used the 1394Diag
> > > > >>example form the ddk as a starting point.
> > > > >>I’m having some trouble detecting more than one device of the same
> > > type
> > > > >>(a device with same vendor and device id). The second device is
> > > simply
> > > > >>not detected. I’m getting a bus reset if the cable is plugged, but
> > > thats
> > > > >>all. The add_device function is not called.
> > > > >>
> > > > >>
> > > > >
> > > > >I’m not completely sure what id’s you’re working with. The
> > > > >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> > > > >vendor_id, chip_id_hi and chip_id_low.
> > > > >
> > > > >Vendor id should be an
> > > > >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> > > > >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> > > > >choose (split between device type id and device instance) however at
> > > > >the end of the day, each device must have a unique number. (Although
> > > I
> > > > >have never experimented with giving 2 devices the same id so I can’t
> > > > >say what happens when you do this.)
> > > > >
> > > > >Doing this I have never had any trouble getting multiple instances of
> > > > >a device to show up at the same time.
> > > > >
> > > > >Rob
> > > > >xxxxx@telusplanet.net
> > > > >
> > > > >
> > > > Thank you for your clarification. It seems that the second device with
> > > > the same id is not detected and that is what should happen because the
> > > > ids must be unique.
> > > > But what about the .inf file of a driver. My .inf file looks like
> > > this:
> > > > …
> > > > [DeviceList]
> > > > %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> > > > …
> > > > The “a35” is the OUI, but what about the “&1”. I thought that would be
> > > > the device type id somehow. You said the other 48 bit are split
> > > between
> > > > device type id and device instance. The other 48 bit are set to
> > > 0xea68
> > > > in my case (chip id high = 0). At the moment I don’t know where to
> > > find
> > > > the .inf-file equivalent of the device type in the config ROM .
> > > > Thanks
> > > > Uwe
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@tin.it
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> My device is a Cypress EzUsb MCU which doesn’t have any firmware loaded.

When device is plugged the driver is loaded, detects the default VID+PID and
loads the firmware
which has a different VID+PID.
Device disconnects USB and then reconnects with the new VID+PID.
So the driver is unloaded & then load again.

This works fine for plenty of hardware, including the BlueTooth dongles, for
instance. So, this is not a problem by itself.

Otherwise I will have to modify the driver to patch the firmware with a
unique serial number when performing
the firmware load process.

The unique serial number must be in HARDware, and the firmware must just report
it. Or there must not be any unique serials at all, and the facility must not
be reported as supported.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

PaoloC wrote:

Thank you for you explication Bill.

My device is a Cypress EzUsb MCU which doesn't have any firmware loaded.
When device is plugged the driver is loaded, detects the default VID+PID and
loads the firmware
which has a different VID+PID.

As far as I know, you can only do this with the EzUSB if your firmware comes
preinstalled in device ROM. Otherwise, the EzUSB will always enumerate with
its standard set of descriptors, which have no serial number. This will lead
Windows to assume it's a new device.

But I could be wrong.

Burk.

Burkhard Daniel
Professional System Software Engineering

xxxxx@system-software.net

> As far as I know, you can only do this with the EzUSB if your firmware
comes

preinstalled in device ROM.

I seem to recall that you can have a device id, or an id with descriptors,
or full firmware with descriptors in that serial rom. It sounds like he may
have picked the id+descriptors without firmware route.

(But for GODS sake, DON’T just use the default EZ-USB id before your
firmware loads! I’ve got three commercial devices on my machine that do
that now, and I’m always having troble with NT deciding that the SmartMedia
reader is a lan modem, or vice versa!)

Loren