On Sun, Nov 1, 2009 at 10:00 AM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
> On Sun, Nov 1, 2009 at 7:33 AM, Frank Schaefer <schaefer.frank@xxxxxxx> wrote:
>> Jon Smirl schrieb:
>>> On Tue, Oct 20, 2009 at 4:00 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> I'm caught in this regression too, still broken in 2.6.31.5. I believe
>>> the hardware I'm using won't work without DTR/RTS turned on. So I
>>> suspect they aren't turned on by default anymore.
>>>
>>> I tried using picocom to force them on and I still couldn't get my
>>> hardware to respond. Chip is a FT232RL.
>>>
>>> I'm still poking around trying to figure out how to make it work again.
>>>
>> Confirmed, RTS+DTR are dropped by default since 2.6.31.
>>
>> It makes sense to enable them by default (if flow control is disabled
>> and baudrate is != B0) and this is what most other serial drivers do, too.
>> I will create a patch which restores the old behavior.
>>
>> However, this is not really a kernel bug or regression.
>> If an application needs specific settings to work properly, it should
>> always set them explicitly.
>> Assuming that the driver will choose the needed settings by default is
>> bad application design.
>
> App that broke for me is written in perl and looks like it is setting
> RTS handshaking.
>
> use Device::SerialPort;
> $ob->handshake("rts");
Adding $ob->rts_active(1); fixes the app.
That's a lot easier for me than changing the kernel on these machines.
>
> Maybe something is missing in the userspace libraries that is
> necessary for communicating this request into the kernel.
>
>>
>> Regards,
>> Frank Schaefer
>>
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@xxxxxxxxx
>
--
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
