Any News on cut-and-paste bug?

[covici at ccs.covici.com]

What I mean is that the error code is there for some reason -- its
trying to warn you of something, so investigation is needed and a real
solution found.  I would look at the 8250 module and see how it does the
registration/release itself.  However, maybe we need to go to a
different way of doing this -- this is some of what I want to discuss on
the call.

John G. Heim <jheim at math.wisc.edu> wrote:

> 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
> >
> _______________________________________________
> Speakup mailing list
> Speakup at linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici at ccs.covici.com