Any News on cut-and-paste bug?

[John G. Heim]

On 05/01/13 10:45, Samuel Thibault wrote:
> John G. Heim, le Wed 01 May 2013 10:42:39 -0500, a écrit :
>> All I wanted to do was get rid of what I suspected was a call to a function
>> that apparently did nothing and the subsequent erroring out. But nobody
>> seemed to know what the function did or if they did, they weren't sharing.
>> They did, however, take the time to criticize the speakup code itself.
>
> Do you have a reference of the thread? (like the precise date when it
> happened, or the subject, etc.)

Here are 2 of the messages I posted. I haven't found an archive of the 
linux-kernel list. But I haven't looked too hard.  But these messages 
show the exact date and subject line of the 2 threads  on the list.

On 03/03/12 11:18, John G. Heim wrote:
 >Subject: speakup bug
 > I need help fixing a bug in the driver for serial hardware  speech
 > synths in the speakup screen reader. According to the comments in the
 > code, it is in a part of the code that is trying to "steal" the serial
 > port.
 >
 > First it calls request_region and when that fails (it always fails), it
 > calls         __release_region(&then it calls release_region again to
 > see if __release_region worked. But it never works because the region
 > being requested is already taken.
 >
 > The code in question is in 2 source code files in
 > drivers/staging/speakup. It starts in serialio.c on line 38. Here it
 > calls a function named synth_request_region which in turn, calls
 > request_region. On line 41 it calls __release_region, and on line 42 it
 > calls synth_request_region again. The function synth_request_region
 > (which calls request_region) is in a file named synth.c. But this code
 > always fails.  Here is a kind of simplified version of it...
 >
 > int error;
 > struct resource tmp;
 > tmp .name = "ltlk";
 > tmps.start = 0x3F8;
 > tmp.end = 0x3FF;
 > tmp.flags = IORESOURCE_BUSY;
 > error = request_resource (&ioport_resource, &tmp);
 >
 > The error returned is always -16. I looked at the code in
 > kernel/resource.c where the request_region function is  defined. It
 > builds a linked list of resources with start & end addresses. If you
 > request a region that is already within the start-end range of a
 > resource already in the list, it returns an error code. But it looks as
 > if the region for a serial port, 0x3f8 - 0x3ff,  in ioport_resource
 > cannot be reserved because the entire range from 0x000 through 0xcf7 is
 > already taken by something named "PCI Bus 0000:00".  Therefore calling
 > request_resource always fails and the driver for the speech synth errors
 > out.
 >
 > And therefore I can't use my hardware speech synth without modifying the
 > kernel code.  If you comment out the line that checks the return code
 > from request_region, it works. So you have to modify  the kernel code
 > and compile a custom kernel to use a hardware speech synth. That's not
 > such a problem for me but it is for a lot of people. Plus, the grml live
 > CD doesn't work with hardware speech.  That is a problem for me.
 >
 > Can anyone tell me how to fix this so it can be patched in the official
 > kernel code?
 >


On 05/11/12 10:36, John Heim wrote:
 >Subject: patch for speakup serial hardware synths
 > A few weeks ago I asked about a problem with the speakup screen reader
 > code. It does not work with serial hardware speech synthesizers. But I
 > managed to get it working. How can I submit my fix for integration into
 > the kernel code. The patch file can be downloaded here:
 > http://www.math.wisc.edu/~jheim/downloads/patch-2012-03-06.patch
 >
 > To install it you cd to the linux source directory and do this:
 > patch -i patch-2012-03-06.patch drivers/staging/speakup/serialio.c"
 >