Any News on cut-and-paste bug?

[John G. Heim]

But that's no answer.  This is the same problem I had with the responses 
  I got on the linux-kernel list. I asked extremely specific  questions 
below and just saying no isn't enough.  Specifically, what is wrong with 
my patch? Does speakup need to call request_reggion at all? If so, why,? 
  What does request_region do? It looks as if request_region always 
fails if you request a region at the address of the serial port even if 
the serial port is not in use? Why is that?  If this behaviour is by 
design, what is the speakup code supposed to do instead?

You can say nothing. Say you're too busy or whatever. But don't just say no.

On 05/01/13 11:30, covici at ccs.covici.com wrote:
> I would not accept that fix in the kernel, either -- nice workaround,
> but its just hiding the real problem.
>
> John G. Heim <jheim at math.wisc.edu> wrote:
>
>>
>>
>> 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"
>>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup at linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>