Re: Proposed modification to PL2303 driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 27.06.2013 22:13, schrieb Reinhard Max:
> On Thu, 27 Jun 2013 at 20:53, Frank Schäfer wrote:
>
>> Am 27.06.2013 19:14, schrieb Reinhard Max:
>>
>>> But the same datasheets also contain the statement I cited before,
>>> that the baud rate generator can be programmed to *any* baud rate
>>> between 75 and the limit of the respective chip.
>>
>> Well, all I can say is that the latter doesn't apply to my device.
>> When has this datasheet been released ?
>
> April 2004 (Page 6, 2nd paragraph):
> http://www.ak-modul-bus.de/cat/documentation/ds_pl2303x_v11.pdf

Assuming that I bought my device somewhere around 2005-2006 and the chip
inside isn't much older, this datasheet would be wrong.
Or maybe they forgot to mention that you need to adjust the crystal
frequency, too. ;)

>
> Also on page 10 of the 2006 release of the same document:
> http://prolificusa.com/pdf/PL-2303XA.pdf
>
>> I also fixed the driver to report the baud rate it actually uses. ;)
>> Applications can check the resulting baud rate and decide if it is
>> sufficient for their purpose.
>
> ... which makes them dependent on this particular driver?
> Or are other drivers doing the same?

Well, I didn't check the other drivers recently and the situation has
improved over the last years, but AFAIK there is no unified driver
behavior. :(
There is a consensus that all drivers should report the actually
set/used baud rate (instead of the requested one). This has been fixed
in many drivers.
I'm not sure about the baud rate determination. IMHO, it should be
unified, too.
IIRC, some drivers round downwards, others to the next nearest value and
some might still simply reject unsupported values.

>
>> Throwing an error if the device can not be set exactly to the
>> requested baud rate isn't a good idea, because
>> a) even good hardware usually doesn't allow real continuous baud rate
>> adjustment
>> b) communication works fine as long as the baud rate deviance is
>> within an acceptable limit (which differs between applications)
>
> Those points apply to the small roundings that are needed to get to
> the next rate that is technically possible, but I don't think they are
> valid for roundings to the next value in the default list, which might
> be too far off to get a usable connection.

What is a "small rounding" ? What does "too far of" mean in values ?
Absolute or relative tolerance ?
Again, this strongly depends on the application which is why the kernel
should leave this decision to userspace.


>
>> Does your device use a generic (Prolific) USB ID ?
>
> Yes.

Ok, then I think it is unlikely that it is a custom chip version.

>
> But I am interested in improving this driver generally, not only to
> get it working on my particular device, which BTW is a data cable for
> Siemens mobile phones as it is often used by hobbyists to communicate
> with embedded hardware.

Yeah, I would really like to see more baud rates beeing supported by the
driver, too.

Let me look at this stuff again when I'm back at home next week.
Maybe we are lucky and can find a way to distinguish between both chip
variants.

Regards,
Frank

>
>
> cu
>     Reinhard

--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux