On Sat, 3 Mar 2007 08:24:00 +0100, Oliver Neukum wrote:
>Am Freitag, 2. März 2007 22:12 schrieb Adam J. Richter:
>> When I plug in a pl2303-based usb serial device, the device is
>> supposed to appear as /dev/tts/USB0 (character device 188, 0).
>> However, under kernels t
When I plug in a pl2303-based usb serial device, the device is
supposed to appear as /dev/tts/USB0 (character device 188, 0).
However, under kernels that I have tried from 2.6.20-git3 through
2.6.21-rc2-git1, /dev/tts/USB is created, and
attempting to open that file returns a "no such devic
When I plug in a pl2303-based usb serial device, the device is
supposed to appear as /dev/tts/USB0 (character device 188, 0).
However, under kernels that I have tried from 2.6.20-git3 through
2.6.21-rc2-git1, /dev/tts/USB is created, and
attempting to open that file returns a "no such devic
On Sun, 27 Nov 2005, Alan Stern wrote:
>On Sun, 27 Nov 2005, Adam J. Richter wrote:
[...]
>> 2.6.15-rc2-git6, during "modprobe ehci-hcd" blocks forever.
>>
>> I can still type and have my text echoed back to me, and I
>> can use the con
physical remove and reinsert
the flash disk. I suspect that this is some kind of BIOS interaction
problem, but I'm just guessing.
Adam J. Richter
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
encourage you to integrate and forward it until there is a
better fix.
--
Adam J. Richter __ __ 575 Oroville Road
[EMAIL PROTECTED] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
&q
suring that the condition is executed even if assertions are
compiled out.
--
Adam J. Richter __ __ 575 Oroville Road
[EMAIL PROTECTED] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
no relevant side-effects. In this case, the
condition does have an important side effect: it takes the lock. It
must be executed, regardless of whether the system is compiled for
assertion debugging or not. Therefore, BUG_ON() should not be used in
this case.
Adam J. Rich
Sorry, I forgot to attach the patch to my previous email.
--
Adam J. Richter __ __ 575 Oroville Road
[EMAIL PROTECTED] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
see Brad Hards has the most recent
copyright notice on hub.c, so I'm emailing this to Brad and
linux-usb-devel. I'd appreciate it someone would let me know either
that they're integrating this patch for submission to Linus or that
there is something else I should do to get this patc
are caught (the return values
from pci_map_single et al are currently often ignored).
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States o
have not done so already. Thanks
in advance.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "
now.
What is the purpose of reserving two bytes at the front of
the skbuff? I don't see them being used anywhere.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-663
(it is set, but never used)
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Softwar
You should also delete the line that calls skb_reserve.
It was an accident that I left it in the patch that I submitted.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261
dev_kfree_skb_irq, resulting in a bunch of
warning messages. I have put "(v2)" in the subject line of this
message to avoid confusion about which is the latest patch.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
eliminating the copy of received packets, but
I thought I out to submit just the transmit fix first for clarity, and
because it might take me a little while to get the receive fix right.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED
on all of these machines, although I have
not tried doing anything with a USB device other than looking at the
device ID information.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6
ll be worth defining appropriate macros so that other architectures
that do not have this problem would not have to use kmalloc/kfree
unnecessarily.
Thanks for the pointer though. I will look into it some more.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 10
t
I want to eliminate eventually. There are other cases (which currently
call usb_control_cmd), where I think I would want to still have the
performance benefit of using the stack rather than kmalloc/kfree.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTEC
ctually using. Users
do not need to pay performance costs on real platforms to support
nonexistent platforms.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a
4GB (i.e., not a HIGHMEM page). Based on what
DMA-mapping.txt, I assume that if the behavior of __get_free_pages
were changed that pci_{,un}map_single would be changed accordingly.
(If you're dealing with a potentially highmem address, the routines
pci_{,un}map_page apparently provides simil
ory range
accessible by PCI bus mastering.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1
nified"
context diff format. Normally, unified diffs are much more readable,
but, in this case, the context diff format makes it much clearer. I
can resubmit it as a unidiff if that is important. The patch is against
linux-2.5.1-pre8, but should apply equally well to 2.4.x and the cv
ch
is probably a lot simpler than having them spend lawyer and management
time on writing new terms.
I have cc'ed this to linux-kernel because there is a
current discussion going on there on this subject that I had just
responded to.
Adam J. Richter __ __ 4880 Ste
q);
do {
result = read(devicefd, &eventbuf, sizeof(eventbuf));
...do something about the event...
} while (result > 0 || (result == -1 && errno == EAGAIN));
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Sui
river. I look
forward to including the GPL'ed part in our build tree.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States
Oops. I wrote:
>[...] and I see a name of the person to contact about the driver [...]
That should read "and I _don't_ see a name of the person to contact
about the driver." Sorry for the confusing typo.
Adam J. Richter __ __ 4880 Stevens Creek Blvd
inary would be GPL incompatible. Besides the legal issues, that would
interfere with distributions that either do not include unfree software
or that keep unfree software in a separate area.
As far as I know, including the source code part should be fine.
Adam J. Ri
Stuart MacDonald <[EMAIL PROTECTED]> writes:
>From: "Adam J. Richter" <[EMAIL PROTECTED]>
>> In the case of USB
>> kernel modules, I believe it actually infringes Yggdrasil copyrights.
>I'm curious to exactly what you mean by that. It seems
&g
at GPL on whitehead_fw.h was for real.
Since it is, I guess should make separate firmware package for the
GPL-compatible firmwares, which could be included in more distributions.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
You can email him for it
([EMAIL PROTECTED]).
Did I miss any?
If one of these other tools turns out to be fully GPL
compatible and can have the right comand line options to work
with hot plugging (and works), then my preference would be to conve
Greg KH <[EMAIL PROTECTED]> writes:
>On Wed, Apr 18, 2001 at 03:48:09AM -0700, Adam J. Richter wrote:
>> ftp://ftp.yggdrasil.com/private/adam/ezusb/nofirmware-linux-2.4.3.patch
>> contains my first effort at removing the ezusb firmware from the kernel
>> and removal of
be good to
have an ezusb_firmware.free package that could be incorporated
into distributions (or categorizations within distributions) that consist
of free software.
Thanks.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
Brad, Ted,
Loading the firmware will normally be totally transparent
to the user. The hot plugging software will take care of it.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1
tested any
of this.
By the way, I did not include it in this patch, but looks like
get_string_desc in linux/drivers/usb/serial/io_edgeport.c is not
used.
Any feedback would be appreciated, especially regarding whether any of
this actually works.
Adam J. Richter __ __ 4880 Stevens
ort too.
Greg has indicated that might beat me to this.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fa
I'll try
to have an updated version and firmware files tomorrow.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +
amount of unswappable kernel memory, and increase flexibility for
EZ-USB-based development. It really would be the right thing to
do technically in the absense of any legal or free software issue.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECT
perately.
>
>Alan
No. The fact that it is technically possible to develop
software to bundle something separately does not mean that you
have bundled it separately.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
t have any EZUSB device on which to try it, so
I have no idea if it works, and I have not converted the keyspan*fw.h
files to data files for it yet. However, any input, experimentation
or comments are welcome.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL
uot;otherwise comingled" to describe all
cases that are not mere aggregation, including, for example, the
putting the keyspan firmware under its current copying conditions
in a module that includes GPL'ed code.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 1
ata file, and kernel
ioctl to support this. (By the way, in that case, we would probably
choose to distribute the program--assuming that it's GPL compatible--and
just include instructions on where to obtain the data files.)
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite
kernel or module
binary that contains GPL'ed material is more than mere aggregation,
regardless of which part of the computing hardware makes most use of
it.
As always, I am not a lawyer, so don't rely on this as legal
advice.
Adam J. Richter __ __ 4880 Stevens C
ser level program
for uploading firmware, which could be distributed separately under
any old copyright (although I believe keyspan has permanently lost any
trade secret restrictions on the code which was published in the
intervining kernel releases).
Adam J. Richter __ __ 4
d and mouse input go through
something like gpm anyhow. One example is the PDA
remote control I described. A more immediately applicable
example is that I would like to support multiple
monitor+keyboard+mouse workstations per c
lp data structure, since that information is
always reread from hardware by the ioctl that retrieves the information,
so the stored value is never used. It just wastes memory. I think
that patch has fallen through the cracks and I need to resubmit it.
I think everyone liked the patch when I ori
ystem has been written in use for a while. The only action that I'm
trying to decide on is whether I should look at trying to develop a
scheme for kernel-centric HID hotplug support (with its own
MODULE_DEVICE_TABLE, etc.), which I currently think will result in a
very limiting system due to the
sing to embed something like
a terrain map in the kernel.
What I am most interested in is _numbers_ rather than what one
might call "performance FUD." Any statistics on required latencies,
etc., would be very helpful.
Anyhow, thanks for the insightful input.
Adam J.
for including them in the kernel, although I
would be more reassured in this feeling if I had some numbers on what kind
of latency is needed for joysticks and the like in things like fast video
games.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, S
50 matches
Mail list logo
