Re: Tiny Core v17.0 upgrade issues

[Stefann]

Boring update...
it still runs..

Code: [Select]

mon day:  5  8 | hh:mm:ss: 15:07:48 | Still alive after 0k + 1 loops
.............
mon day:  5  9 | hh:mm:ss: 15:09:47 | Still alive after 219k + 471 loops

[Stefann]

Bingo! crashed!
After 45 hours
The screensaver was not active but it did not help me much
flwm was active but did simply show a frozen screen.
I have no mouse but keyboard did not give any response.

I just restart without too much intelligence for reason I need the automizations that my application is running.
I will think of proper followup later, no time now.
I will anyways start it in text mode. "maybe console shows more clues when crashing in text mode"

But.... this is first time I was able to get TC17 crashing with a very simple isolated "crash testcase program" (as published few posts back).
==> I would say... "this is definitely a kext usb-serial-6.18.2-tinycore.tcz TC17 issue"

Any advice is welcome

Code: [Select]

First logging: mon day:  5  8 | hh:mm:ss: 15:07:48 | Still alive after 0k + 1 loops

.............

Last logging: mon day:  5 10 | hh:mm:ss: 12:21:54 | Still alive after 414k + 476 loops

[Rich]

Hi Stefann

... The screensaver was not active but it did not help me much
flwm was active but did simply show a frozen screen.
I have no mouse but keyboard did not give any response. ...

Did you try hitting  Ctrl-Alt-F1 ?
Normally that should switch you to the console so you can see messages.

Ctrl-Alt-F2  returns you to the GUI>

[Stefann]

Hi Stefann

... The screensaver was not active but it did not help me much
flwm was active but did simply show a frozen screen.
I have no mouse but keyboard did not give any response. ...

Did you try hitting  Ctrl-Alt-F1 ?
Normally that should switch you to the console so you can see messages.

Ctrl-Alt-F2  returns you to the GUI>

Ah.. no..
And I rebooted already.
I did not really have time to explore a lot.

Anyway..
It’s now running in textmode. Maybe it will crash as well.
At least “getting it to crash” is kind of predictable.
Both my application and this isolated crash program crashed after about 45 hrs.
I keep it running for 48 hrs again. If it does not crash I try again with gui and take your inputs.

Progress is slow but steady.

At some point I will also test TC16 to see whether it did break with TC16 or TC17

[Stefann]

boring update... its still running..

Code: [Select]

mon day:  5 10 | hh:mm:ss: 13:49:56 | Still alive after 0k + 1 loops
.....
mon day:  5 12 | hh:mm:ss: 15:04:58 | Still alive after 453k + 670 loops
Its now running significantly longer than previous run that crashed after about 414k loops.

Configuration changes are:
- I removed the "interrupt stress inducing lines" from the code because that did not seem to add much. It crashed after 45hours while "with the read() as part of my application" without additional stress it also crashed after 45hrs
- I now booted into text mode instead of GUI

So...
- either its natural variation
- or the lower stress increases the "time to crash" (maybe to indefinite)

I leave it running for an other day. If it did not crash by than I bring it back to previous configuration and try to crash it and look into console using the CTR-ALT-F1 & F2 keys.
Note,... It would have been much handier to keep the system in crashed state and await suggestions on this forum BUT the system is actively running my home automation. The home automation crashes it goes into all kind of "safe fallback modes" but I donot want to have it stalled for to long time. Also depends on my agenda. If I'm home I can afford it to be down better than when I'm not home.

[Stefann]

Ok... lots to say...

Yesterday I was off. Today the crash program was still running. I manually stopped it

Code: [Select]

mon day:  5 10 | hh:mm:ss: 13:49:56 | Still alive after 0k + 1 loops
.....
mon day:  5 14 | hh:mm:ss: 13:19:37 | Still alive after 878k + 109 loops
So:
- with crashprogram that no longer has "stress inducing interrupts" and "TC17 with text boot option" I see no crash in 4 days.

Next step I tried:
- install TC16
However... Install worked, but I did not get it running.
I tried TC16.0 and TC16.1 but for some reason I could not get them to run.

syslog did start but it looks like it stalls when trying to load core.gz.

I noticed that on my MacBook TC16 core.gz is downloaded as core.cpio. I tried booting core.cpio but without success.
I changed name in syslog.conf to core.cpio; I also tried renaming core.cpio to core.gz but neither worked.
>> I abandon that path.

Next step..
I downloaded sources from TC15, TC16 and TC17 and looked into ./drivers/usb/serial
I did run a diff on usb-serial.c
>> note, I have no clue whether this is the file I need, I just guessed based on filename.

The most suspicious difference I did see:

Code: [Select]

TC15:
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }

TC17:
< tty_port_tty_vhangup(&port->port);
This (I think) means that TC15 is testing tty to be valid before doing tty_vhangup() by calling tty while TC17 directly closes the port without testing whether the associated tty exists.

I did some google and found on https://docs.kernel.org/driver-api/tty/tty_port.html:

The tty port has a different lifetime to the tty so must be kept apart. In addition be careful as tty -> port mappings are valid for the life of the tty object but in many cases port -> tty mappings are valid only until a hangup so don’t use the wrong path.

please understand, I have no clue about the logic of this code, but I "can" imagine a hangup_command that is run in kernel mode on a non-existant port to cause a crash.

Next.....
- for now I started the crash-test again including stress commands and including gui. With a little luck it fails again in 45hr and than I can see whether I can jump out the gun with CNTR-ALT-F1 as suggested by @Rich.

Followup, and I could use some help here...
1/
It would be nice if I could understand why TC16 does not run. The diff between TC16 and TC17 on usb-serial.c is almost nothing.
> its above mention tty check
> and also use of "guard" instead of "spin_lock"
So if TC16 runs without crash it is a further evidence that the issue is in one of above 2 changes.

So... any advice on "why boot gets stuck on TC16" is welcome

2/
would there be any way that I could recompile the core with usb-serial.c fixed for the tty check?
Please understand that I have zero experience in compiling core.
I would also be very happy to test a core that someone prepared for me.

3/
Can anyone confirm that usb-serial-6.18.2-tinycore.tcz is indeed the usb-serial.c file??
Note,... would simply using  usb-serial-6.6.8-tinycore.tcz  (TC15) or  usb-serial-6.12.11-tinycore.tcz  (TC16) have any potential to work??
Especially the TC16 should have potential as the only difference is in the tty_vhangup() and the spinlock.

And/or... any way I could get a usb-serial-x.y.z-tinycore.tcz compiled for TC17 based on TC16 usb-serial.c?

For information
diff of usb-serial.c TC17 TC15

Code: [Select]

$$ TC17 crash work % diff TC17_drivers_usb_serial/usb-serial.c TC15_drivers_usb_serial/usb-serial.c
709c709
< guard(mutex)(&usb_dynids_lock);
---
> spin_lock(&drv->dynids.lock);
711a712
> spin_unlock(&drv->dynids.lock);
714a716
> spin_unlock(&drv->dynids.lock);
1178a1181
> struct tty_struct *tty;
1193c1196,1200
< tty_port_tty_vhangup(&port->port);
---
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }
1455c1462
<  * __usb_serial_register_drivers - register drivers for a usb-serial module
---
>  * usb_serial_register_drivers - register drivers for a usb-serial module
1457d1463
<  * @owner: owning module
1464,1466c1470,1472
< int __usb_serial_register_drivers(struct usb_serial_driver *const serial_drivers[],
<   struct module *owner, const char *name,
<   const struct usb_device_id *id_table)
---
> int usb_serial_register_drivers(struct usb_serial_driver *const serial_drivers[],
> const char *name,
> const struct usb_device_id *id_table)
1511d1516
< (*sd)->driver.owner = owner;
1519c1524
< rc = driver_attach(&udriver->driver);
---
> rc = driver_attach(&udriver->drvwrap.driver);
1530c1535
< EXPORT_SYMBOL_GPL(__usb_serial_register_drivers);
---
> EXPORT_SYMBOL_GPL(usb_serial_register_drivers);
diff of usb-serial.c TC17 TC16

Code: [Select]

$$ diff TC17_drivers_usb_serial/usb-serial.c TC16_drivers_usb_serial/usb-serial.c
709c709
< guard(mutex)(&usb_dynids_lock);
---
> spin_lock(&drv->dynids.lock);
711a712
> spin_unlock(&drv->dynids.lock);
714a716
> spin_unlock(&drv->dynids.lock);
1178a1181
> struct tty_struct *tty;
1193c1196,1200
< tty_port_tty_vhangup(&port->port);
---
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }

[Stefann]

to add,
I'm chatting with my brother, who is a bit of linux guru..

He also thinks these are suspicious:

<    guard(mutex)(&usb_dynids_lock);
---
>    spin_lock(&drv->dynids.lock);
711a712
>          spin_unlock(&drv->dynids.lock);
714a716
>    spin_unlock(&drv->dynids.lock);
1178a1181

Especially because the "spin_lock()" seems to be replaced by "guard()" but its unclear what happened to the 2x "spine_unlock()"

This folds back to Commit 0b3144d
https://github.com/torvalds/linux/commit/0b3144da31f855fce652303f588416a60991bdef

USB: make single lock for all usb dynamic id lists
There are a number of places where we accidentally pass in a constant
structure to later cast it off to a dynamic one, and then attempt to
grab a lock on it, which is not a good idea.  To help resolve this, move
the dynamic id lock out of the dynamic id structure for the driver and
into one single lock for all USB dynamic ids.  As this lock should never
have any real contention (it's only every accessed when a device is
added or removed, which is always serialized) there should not be any
difference except for some memory savings.

Note, this just converts the existing use of the dynamic id lock to the
new static lock, there is one place that is accessing the dynamic id
list without grabbing the lock, that will be fixed up in a follow-on
change.

tty-check change folds back to Commit 2b5eac0
https://github.com/torvalds/linux/commit/2b5eac0f8c6e79bc152c8804f9f88d16717013ab

tty: introduce and use tty_port_tty_vhangup() helper
This code (tty_get -> vhangup -> tty_put) is repeated on few places.
Introduce a helper similar to tty_port_tty_hangup() (asynchronous) to
handle even vhangup (synchronous).

And use it on those places.

In fact, reuse the tty_port_tty_hangup()'s code and call tty_vhangup()
depending on a new bool parameter.

I traced the code on this. As far as I can see the new code does no longer have the check on "tty being existing"

[Stefann]

I just notice my 2nd system has tc16 core.gz and vmlinuz that was working until I upgraded to tc17.
I will put those on my production system tomorrow. I expect that will work.
“Failing to boot TC16” is likely something stupid.

[Stefann]

All,... I can use some help..

You can read previous posts but if you don't want to spent the time, here is my help requests:

How can I create a dedicated usb-serial-x.y.z-tinycore.tcz?
I would like to change usb-serial.c and generate  usb-serial-x.y.z-tinycore.tcz for TC17 but do not know how to do that.
Any help/guidance is appreciated.
Modifications I want to do:
- fix check on tty before calling tty_vhangup(tty)
- fix spin_lock() and spin_unlock() calls
(check previous posts for rationale)

------
update on status,
- it did not crash yet but I stopped it manually
- I tried again to install TC16. I got the correct core.gz and vmlinuz from the downloaded .iso but for some reason it does not boot on my VIA eden 500MHz single core cpu. strange. TC15 works, TC17 also. I decided not to investigate this further as I do not want to run TC16 anyways.
- I tried to boot with kext usb-serial-6.12.11-tinycore.tcz (from TC16) on TC17 for reason this version does still have the "check on tty" and "spin_lock() and spin_unlock()" calls. I was well aware that using a TC16 kext on TC17 would likely not work but "why not try". But... indeed. the TC16 kext does not function on TC17. serial port does not function with that kext.
- I now restarted all, including my application with full serial port use on TC17. Back to original fail mode. This mode is likely to fail in about 15 hours. gui is on the console so WHEN it fails I can check messages using CNTRL-ALT-F1 to get to prompt.

Next thing I would like to try is TC17 with usb-serial-x.y.z-tinycore.tcz from recompiled usb-serial.c still with "check on tty" and "spin_lock() and spin_unlock()" calls. I however do not know how to create that. help/guidance would be appreciated!

[mocore]

How can I create a dedicated usb-serial-x.y.z-tinycore.tcz?
I would like to change usb-serial.c and generate  usb-serial-x.y.z-tinycore.tcz for TC17 but do not know how to do that.

could
" Help with compile of simple kernel module/driver" @ https://forum.tinycorelinux.net/index.php?topic=18974.msg116442#msg116442
offer some insight ? wrt
>create a dedicated abc-x.y.z-tinycore.tcz?
aka building the module

then (i presume!?!) just follow generic .tcz creation steps (eg squashfs the built module )
--edit--
https://wiki.tinycorelinux.net/doku.php?id=wiki:custom_kernel&s[]=kernel
https://unix.stackexchange.com/questions/208746/linux-kernel-module-building-prerequisites
https://unix.stackexchange.com/questions/115620/configuring-compiling-and-installing-a-custom-linux-kernel/115621#115621

[Stefann]

@mocore
Thanks!

that should indeed help me.
It will take some time. This is still a hobby and my time to spend on it is not endless.
I will go forward with this but as it is completely new to me I expect it will take me through a rough path. so yes... it will take some time. But I will get there.

[Stefann]

Pfew... I looked into this... I need some help...

What I achieved...
I successfully unsquashed usb-serial-6.18.2-tinycore.tcz. so now I have a list of files that is in it.
It basically contains:
/usr/local/lib/modules/6.18.2-tinycore/kernel/drivers/usb/misc/uss720.ko.gz
and
/usr/local/lib/modules/6.18.2-tinycore/kernel/drivers/usb/serial/[multiple files].gz

to my interest I see:
usb-serial-simple.ko.gz and usbserial.gz
>> mmmh... so far I did not pay attention to the simple version...

But....
I started reading wiki on creating kernel but I'm afraid "that is to much.." It's over my head....

I also did find "config-6.18.28-tinycore" on the download pages but have no clue what to do with it.

With that said...
- I do not need to fully create a new kernel
- I only need to rebuilt usb-serial-6.18.2-tinycore.tcz

I succeeded in the unsquash, I'm pretty sure I could also squash again to create a .tcz file
I DO have all the sources

What I need
So.. only thing (I think) I'm missing:
- makefile to get from usb-serial.c to usbserial.gz and from usb-serial-simple.c to usb-serial-simple.ko.gz

any tips??

[Rich]

Hi Stefann

... - I tried to boot with kext usb-serial-6.12.11-tinycore.tcz (from TC16) on TC17 for reason this version does still have the "check on tty" and "spin_lock() and spin_unlock()" calls. I was well aware that using a TC16 kext on TC17 would likely not work but "why not try". But... indeed. the TC16 kext does not function on TC17. serial port does not function with that kext. ...

You can not use a 6.12.11-tinycore kernel module with a 6.18.2-tinycore kernel.
If the version of the module does not match the version of the kernel, the
kernel will refuse to load it.

[Rich]

Hi Stefann

... It basically contains:
/usr/local/lib/modules/6.18.2-tinycore/kernel/drivers/usb/misc/uss720.ko.gz
and
/usr/local/lib/modules/6.18.2-tinycore/kernel/drivers/usb/serial/[multiple files].gz ...

You can find out which of those modules are being loaded with this command:

Code: [Select]

lsmod

... I also did find "config-6.18.28-tinycore" on the download pages but have no clue what to do with it. ...

That is the config file for a later kernel TC17 is being updated to.
config-6.18.2-tinycore is not the same as config-6.18.28-tinycore.

... With that said...
- I do not need to fully create a new kernel
- I only need to rebuilt usb-serial-6.18.2-tinycore.tcz ...

I think nowadays you need to recompile the kernel and all enabled modules.
Maybe wait for Juanito and/or Paul_123 to provide clarification on that point.

[Stefann]

Thanks @rich

Code: [Select]

tc@huis:~$ lsmod
Module                  Size  Used by    Not tainted
cifs                  454656  2
cifs_md4               12288  1 cifs
netfs                  36864  1 cifs
nls_ucs2_utils          8192  1 cifs
cpufreq_conservative    12288  0
cpufreq_userspace      12288  0
cpufreq_powersave      12288  0
ftdi_sio               36864  1
usbserial              20480  3 ftdi_sio
squashfs               36864 155
pcspkr                 12288  0
8139too                20480  0
8139cp                 20480  0
mii                    12288  2 8139too,8139cp
loop                   20480 310
So only usb_serilal.c and ftdi_sio.c are used

I checked diff between TC15 & TC17 on ftdi_sio.c as well. It does not show much suspect I think.
Only potential issue is mutex_lock/unlock around line 1441. But that's INserted to TC17, so "more save" and actually only to "get info" from the port so I do not expect that to get used during data_read.

I'm afraid a full kernel recompile is above my level.
SO... not sure how to navigate from here.
system is still running, hopefully a crash within 24hr and ability to see console messages.

I can fix my application by using non-blocking read but it would be good to find the kernel issue. As said... not sure how to navigate further.

Code: [Select]

$$ TC17 crash work % diff TC17_drivers_usb_serial/ftdi_sio.c TC15_drivers_usb_serial/ftdi_sio.c
631,632c631,634
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_TIAO_UMPA_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_NT_ORIONLXM_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, FTDI_TIAO_UMPA_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_NT_ORIONLXM_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
804,805d805
< { USB_DEVICE(FTDI_NDI_VID, FTDI_NDI_EMGUIDE_GEMINI_PID),
< .driver_info = (kernel_ulong_t)&ftdi_NDI_device_quirk },
843c843,844
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, CYBER_CORTEX_AV_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
848,853c849,860
< { USB_DEVICE_INTERFACE_NUMBER(FIC_VID, FIC_NEO1973_DEBUG_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_OOCDLINK_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, LMI_LM3S_DEVEL_BOARD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, LMI_LM3S_EVAL_BOARD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, LMI_LM3S_ICDI_BOARD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_TURTELIZER_PID, 1) },
---
> { USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, LMI_LM3S_DEVEL_BOARD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, LMI_LM3S_EVAL_BOARD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, LMI_LM3S_ICDI_BOARD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_TURTELIZER_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
895,896c902,905
< { USB_DEVICE_INTERFACE_NUMBER(ADI_VID, ADI_GNICE_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ADI_VID, ADI_GNICEPLUS_PID, 1) },
---
> { USB_DEVICE(ADI_VID, ADI_GNICE_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(ADI_VID, ADI_GNICEPLUS_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
902c911,912
< { USB_DEVICE_INTERFACE_NUMBER(MARVELL_VID, MARVELL_SHEEVAPLUG_PID, 1) },
---
> { USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
925,926c935,938
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, MARVELL_OPENRD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, TI_XDS100V2_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, TI_XDS100V2_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
935,937c947,952
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, XVERVE_SIGNALYZER_ST_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, XVERVE_SIGNALYZER_SLITE_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, XVERVE_SIGNALYZER_SH2_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, XVERVE_SIGNALYZER_ST_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, XVERVE_SIGNALYZER_SLITE_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, XVERVE_SIGNALYZER_SH2_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
942c957,958
< { USB_DEVICE_INTERFACE_NUMBER(IONICS_VID, IONICS_PLUGCOMPUTER_PID, 1) },
---
> { USB_DEVICE(IONICS_VID, IONICS_PLUGCOMPUTER_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
957,958c973,976
< { USB_DEVICE_INTERFACE_NUMBER(QIHARDWARE_VID, MILKYMISTONE_JTAGSERIAL_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ST_VID, ST_STMCLT_2232_PID, 1) },
---
> { USB_DEVICE(QIHARDWARE_VID, MILKYMISTONE_JTAGSERIAL_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(ST_VID, ST_STMCLT_2232_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
962c980,981
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
1017,1019c1036,1038
< { USB_DEVICE(FTDI_VID, ACTISENSE_UID_PID) },
< { USB_DEVICE(FTDI_VID, ACTISENSE_USA_PID) },
< { USB_DEVICE(FTDI_VID, ACTISENSE_NGX_PID) },
---
> { USB_DEVICE(FTDI_VID, ACTISENSE_D9AC_PID) },
> { USB_DEVICE(FTDI_VID, ACTISENSE_D9AD_PID) },
> { USB_DEVICE(FTDI_VID, ACTISENSE_D9AE_PID) },
1037c1056,1057
< { USB_DEVICE_INTERFACE_NUMBER(TI_VID, TI_CC3200_LAUNCHPAD_PID, 1) },
---
> { USB_DEVICE(TI_VID, TI_CC3200_LAUNCHPAD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
1055d1074
< { USB_DEVICE_INTERFACE_NUMBER(UBLOX_VID, UBLOX_EVK_M101_PID, 2) },
1057,1076c1076,1079
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_FALCONIA_JTAG_BUF_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_FALCONIA_JTAG_UNBUF_PID, 1) },
< /* GMC devices */
< { USB_DEVICE(GMC_VID, GMC_Z216C_PID) },
< /* Altera USB Blaster 3 */
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6022_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6025_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6026_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6026_PID, 3) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6029_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602A_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602A_PID, 3) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602C_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602D_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602D_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602E_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602E_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602E_PID, 3) },
< /* Abacus Electrics */
< { USB_DEVICE(FTDI_VID, ABACUS_OPTICAL_PROBE_PID) },
---
> { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_BUF_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_UNBUF_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
1441d1443
< mutex_lock(&priv->cfg_lock);
1445d1446
< mutex_unlock(&priv->cfg_lock);
1839c1840
< static int ftdi_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
---
> static void ftdi_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
1843d1843
< int result;
1852c1852
< result = ftdi_set_cbus_pins(port);
---
> ftdi_set_cbus_pins(port);
1855,1856d1854
<
< return result;
1874c1872
< static int ftdi_gpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
---
> static void ftdi_gpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
1879d1876
< int result;
1885c1882
< result = ftdi_set_cbus_pins(port);
---
> ftdi_set_cbus_pins(port);
1888,1889d1884
<
< return result;
2618c2613
< unsigned int cflag;
---
> unsigned int cflag = termios->c_cflag;
2876a2872
> .owner = THIS_MODULE,