Arch Linux

I'm then disowning this package and flagging it out of date.
Thanks a lot for your comments and hope dkms-pl2501 will serve us well.

Ok now I remember, it sounded weird that 067b:0001 didn't work, sorry for the confusion.
My device has a feature controlled via a software for Windows which changes the device id from
Bus 001 Device 025: ID 067b:0001 Prolific Technology, Inc. PL2302 USB-USB Bridge
to
Bus 001 Device 023: ID 067b:2501 Prolific Technology, Inc. PL2501 USB-USB Bridge (USB 2.0)

Using this package what I obtain in dmesg is:
[362150.754096] usb 1-1.2: USB disconnect, device number 28
[362153.643632] usb 1-1.2: new high-speed USB device number 29 using ehci_hcd
The module plusb is NOT loaded in any case for the previously written reasons of conflicting modules.

I'm now switching to the dkms-pl2501 package, better suited.

Just wondering, why your 067b:0001 is not working anymore in linux-pf? Also, what is the patch you are using to make it work? Is this patch still valid for stock kernel?
I'm thinking maybe this package could combine both your patch and the patch to add PL-2501 device id.

I like the separate module approach better - it seems to be more stable (no overriding/precedence issues with original module and no dependency on upstream). So i'll be maintaining dkms-pl2501 separately unless there is a way to fix those issues.

my device is 067b:0001 and using the stock kernel works fine with plusb module.
in custom kernels like linux-pf my device was not working anymore and I had to patch plusb.c everytime :)

btw this package will be still maintained or dropped by for pl2501?

here, i crafted the one real fast: https://aur.archlinux.org/packages.php?ID=63807

I didn't give it any considerable test (like what would happen if both plusb and pl2501 modules are active).

i did try with the stock kernel (in the first place), same thing.

Are you saying that plusb is loaded for the 067b:2501 device? This shouldn't happen because this id is not available in original plusb. That's the whole reason for this patch.

BTW i like the idea of making it a separate module (like, pl2501) and using only PL-2501's id there (that is, 067b:2501).
This is going to be a trivial module and could be provided in the sources of this package.

no changes here instead.
modinfo and all the others tools still use the stock plusb.ko.gz module.
try it yourself with the stock linux kernel.

At last I renamed the whole thing (dkms module and source code) to pl2501 and everything works fine, except module autoloading which first loads (and use for usb device) the plusb module.
By preloading the module in modules-load.d at the system start or manually via modprobe, the device prefers the use of the already loaded module instead of loading the other from the disk.

no idea.. you could try reinstalling the dkms module, if it helps:

# modinfo plusb
filename: /lib/modules/3.6.2-1-ck/kernel/drivers/net/usb/plusb.ko
<snip>

# dkms remove -m plusb -v git -k $(uname -r)
<snip>

# modinfo plusb
filename: /lib/modules/3.6.2-1-ck/kernel/drivers/net/usb/plusb.ko.gz
<snip>

# dkms build -m plusb -v git
<snip>

# dkms install -m plusb -v git
<snip>

# modinfo plusb
filename: /lib/modules/3.6.2-1-ck/kernel/drivers/net/usb/plusb.ko
<snip>

As you can see, works fine here.

unfortunately this is not the case of my stock kernel.
$ dkms status
plusb, git, 3.6.2-1-ARCH, x86_64: installed
$ modinfo plusb
filename: /lib/modules/3.6.2-1-ARCH/kernel/drivers/net/usb/plusb.ko.gz
description: Prolific PL-2301/2302/25A1 USB Host to Host Link Driver

all the tools, including modprobe, modinfo, udev and its detection which loads the module, always pick the stock kernel module.
depmod itself cannot see the built kernel module if there's the stock one present:
$ depmod -av 2> /dev/null | grep plusb
/lib/modules/3.6.2-1-ARCH/kernel/drivers/net/usb/plusb.ko.gz needs "usb_register_driver": /lib/modules/3.6.2-1-ARCH/kernel/drivers/usb/core/usbcore.ko.gz
/lib/modules/3.6.2-1-ARCH/kernel/drivers/net/usb/plusb.ko.gz needs "usbnet_suspend": /lib/modules/3.6.2-1-ARCH/kernel/drivers/net/usb/usbnet.ko.gz

You are right that pulling the latest git version of plusb.c may not work for you (won't compile).
I thought about checking the currently running version of kernel and pulling that specific plusb.c version, but this could lead to problems with other installed kernels (still could not compile for them).
Since plusb.c doesn't change so often (and i'm saying it very gently), i decided to stick with pulling the latest one from git.

For DKMS priority. In my case, the priority is given to the module installed by DKMS. The man page for DKMS specifically mentions how saving and restoring of original kernel modules work.
Please check "dkms status" and "modinfo plusb" - it should work for you as well.

I will put GPL2 in license on the next update.

Thanks for your comments!

quote: BTW, if you help me specify the correct license, i would be more than happy :)

This simple patch could use the same license of the linux kernel package, eg GPL2

quote: It will be used instead of plusb module provided by your kernel (and handled by dkms). You don't have to anything manually - again, handled by DKMS.

DKMS handles well its work, to build the kernel module accordingly to the running kernel version but the priority (even from dkms) is always given to the official kernel version of the module:
Package installation: http://pastebin.com/6SHqtJnm

DKMS compiles and installs the module in the standard modules directory:
# ls -l /lib/modules/$(uname -r)/kernel/drivers/net/usb/plusb*
-rw-r--r-- 1 root root 6560 20 ott 14.43 /lib/modules/3.6.2-1-ARCH/kernel/drivers/net/usb/plusb.ko
-rw-r--r-- 1 root root 1586 13 ott 00.01 /lib/modules/3.6.2-1-ARCH/kernel/drivers/net/usb/plusb.ko.gz
The former is the custom module built by dkms, the latter is the stock plusb kernel module provided by linux package.

Immediately after installation: http://pastebin.com/9f7aLuAn
The stock kernel module is in use, modinfo and dmesg confirm that.

Attaching a plusb cable to my usb port my kernel continues to use the stock module:
[332130.152826] plusb 1-1.2:1.0: usb0: register 'plusb' at usb-0000:00:1a.0-1.2, Prolific PL-2301/PL-2302/PL-25A1, 4e:49:fd:21:19:b7

Whichever way to load the module I use what I always obtain is the stock kernel module in use.

As a countercheck if I remove the stock kernel module plusb everything starts to work as you expect: http://pastebin.com/iLaa05Hz
Obviously your package shouldn't NEVER EVER do nasty things like removing the stock kernel module.

A way to maintain the same module in two different locations is what it's needed but I'm not sure what this way could be.

quote: the version is hard coded throughout the package files right now

I think the best approach is to enforce the linux kernel dependences. Making your package to depend on the linux=version (or a less strictly >= 3.6 < 3.7) you can depend on the perfect kernel tag from the git code, downloading in this way the proper version of plusb.c. Your package would then follow the same version schema of the linux package.
Maybe there's a better/surer way to handle this but I'm not aware.
You could ask to the aur-general mailing list.

this is a long response so I'll split it in many comments.

quote: You comment about the package name also makes sense..

Oh well, I looked deeper your package and I cannot agree anymore with myself.

Your package name is actually dkms-plusb-pl2501 and its versios is git (no updates will be applied as long as git is not a number and aur cannot handle newer versions of this non-numbered package).
A git package uses always the latest available version but for a kernel module this is not the most savvy choice.
Your package cannot work with "any" versions of the linux kernel. I mean if I have the linux kernel 3.2.4 installed on my machine because the newer kernels don't handle well on my machine, actually this package would pull the latest stable version of plusb.c, which today is the v3.7-rc2 (Linus has commited it today). This could entirely break my machine because even a small change in the kernel code could result in a kernel panic.

Hi,

Thanks for the comments!

You are quite right about the linux-headers dependency. I think i will also put dkms as a dependency.
You comment about the package name also makes sense.. I just need to think about how to handle this in the best way (the version is hard coded throughout the package files right now).

It will be used instead of plusb module provided by your kernel (and handled by dkms). You don't have to anything manually - again, handled by DKMS.
BTW, if you help me specify the correct license, i would be more than happy :)

Hello

I think your package's missing the linux-headers dependency.
Furthermore the package name is wrong, accordingly to the Arch CVS guidelines [1] all the packages that use git repositories should be named as pkgname-git and the version number assumed is the current date.
How should it be used? The linux package already contains the plusb.ko.gz which is the default used when loading the plusb modules. Should I manually load it using insmod and the whole path?
Finally the used license is an unspecified custom.

[1] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines