No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.
Just wrote sample
ftdi_fake.c Linux 2.6.x kernel module to invetsigate this if is it possible to attach USB device with unchanged FTDI_VID= 0x403 (hex) and PID= 0x0 (0)
#include <linux/module.h> // included for all kernel modules
#include <linux/kernel.h> // included for KERN_INFO
#include <linux/init.h> // included for __init and __exit macros
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/tty_driver.h>
#include <linux/tty_flip.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <asm/uaccess.h>
#include <linux/usb.h>
#include <linux/serial.h>
#include <linux/usb/serial.h>
/*
* * Version Information
* */
#define DRIVER_VERSION "v0.0.1"
#define DRIVER_AUTHOR "Eneuro"
#define DRIVER_DESC "A Simple walk around FTDI fake PID "
#define FTDI_VID 0x0403 /* FTDI vendor Id */
///#define FTDI_232RL_PID 0xFBFA /* FTDI 232RL PID 0xFBFA or 0x6001 */
#define FTDI_FAKE_PID 0x0 /* FTDI fake PID */
static int debug;
static __u16 vendor = FTDI_VID;
static __u16 product= FTDI_FAKE_PID;
static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
MODULE_DEVICE_TABLE(usb, id_table);
static int __init ftdi_fake_init(void)
{
dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {
printk(KERN_INFO "The key is to set to default product ID in Linux FTDI driver to 0x0 and add it to FTDI usb device id's table !!!" );
}
printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ": "
DRIVER_DESC "\n");
/* printk(KERN_INFO "\n" ); */
printk(KERN_INFO "vid: 0x%x\n", vendor );
printk(KERN_INFO "pid: 0x%x\n", product );
return 0; // Non-zero return means that the module couldn't be loaded.
}
static void __exit hello_cleanup(void)
{
printk(KERN_INFO "Cleaning up module.\n");
}
module_init(ftdi_fake_init);
module_exit(hello_cleanup);
MODULE_LICENSE("GPL");
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
module_param(debug, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, "Debug enabled or not");
module_param(vendor, ushort, 0);
MODULE_PARM_DESC(vendor, "User specified FTDI vendor ID (default="
__MODULE_STRING(FTDI_VID)")");
module_param(product, ushort, 0);
MODULE_PARM_DESC(product, "User specified FTDI product ID (default="
__MODULE_STRING(FTDI_FAKE_PID)")" );
This module does nothing for the moment, only print kernel messages when successfully loaded and outputs detected USB device vid and pid visible in
$ dmesg output, added usb aliases for this fake pid,
As you can notice changed also main module init condition to accept this fake PID=0
Than change this code module init code to accept this FTDI fake PID 0 :
static int __init ftdi_fake_init(void)
{
dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {
The key is to add this fake PID to this table I guess too
static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
so, this will create alias for 0x403, 0x0 usb device to be able to attach it to our driver
"usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*"
Additionaly, we probably want in module init, after detecting we have bricked FTDI with PID==0,
overwrite it to proper
product (PID) value, while probably there is another stuff which connects to device so it needs proper PID in variable
product later.
But for the moment, one need to ensure that Linux will be able to attach bricked usb chip to this
ftdi_fake module I've wrote,
so after recompiling, installing (copying it) in /lib/modules/...../ (where ftdi_sio sits ) we need also recreate those aliases with:
# depmod -a
Than we should be able see in module info this alias for our fake module, by typing:
$ modinfo ftdi_fake
alias: usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*
depends: usbserial
vermagic: 2.6.30.10-105.2.23.fc11.x86_64 SMP mod_unload
parm: debug:Debug enabled or not (bool)
parm: vendor:User specified vendor ID (default=0x0403) (ushort)
parm: product:User specified product ID (ushort)
If this attaching worked, than overriding product variable in module init to PID of 232RL which I'm not sure but based on oryginal header files is 0xFBFA, maybe could allow use this bricked device under Linux without any problems, if it is possible to attach usb device with PID 0 as I wrote earlier
#define FTDI_232RL_PID 0xFBFA
product= FTDI_232RL_PID;
Unfortunate, I have no bricked FTDI stuff, so can not test it, but if you want take this
ftdi_fake.c source code and recompile on 2.6.x Linux machine with oryginal FTDI Makefile but change names inside from
ftdi_sio to
ftdi_fake They changed this PID to 0 while they know from Linux source that they make this devices also useless under Linux without extra work, while in their Linux manuals they suggest using standard Linux ftdi_sio kernel module, and those modules has condition of vendor and product to be >0 before any other initializations in 2.6.x kernels More details there
https://www.eevblog.com/forum/reviews/what-should-ftdi%27s-next-driver-update-look-like/msg540077/#msg540077, while this thread is spammed by a210210200 .