- Sorry, it looks like I'm having difficulties with the mailing list -
please be patient, I'm mostly an hardware guy -
> The thread opener said he can set the non-standard rate of 250kBaud
> under Windows, so either that rate got added to the standard list or
> the driver nowadays also supports
On Thu, 4 Jul 2013 at 14:44, Frank Schäfer wrote:
Even more interesting would be the Windows driver that has been used
for reverse-engineering. ;) AFAIK, the standard Windows driver
doesn't use the second method (last checked 2-3 years ago)...
The thread opener said he can set the non-standa
Am 04.07.2013 14:44, schrieb Frank Schäfer:
> ...
> To summarize our current knowledge:
>
> divisor = 2^A * B
>
> with
>
> A = buf[1] & 0x0E
> B = buf[0] + (buf[1] & 0x01) << 8
Update / addition:
=> for B <= 8 the device always uses the maximum value B = 512 instead
=> for 8 < B < 1
Am 04.07.2013 00:52, schrieb Reinhard Max:
> On Wed, 3 Jul 2013 at 23:35, Frank Schäfer wrote:
>
>> When I wrote the patch in 2009, only the first baud rate programming
>> method was in place.
>> The second method has been added later with commit 8d48fdf6.
>
> Hmm - it would be interesting to know
On Wed, 3 Jul 2013 at 23:35, Frank Schäfer wrote:
When I wrote the patch in 2009, only the first baud rate programming
method was in place.
The second method has been added later with commit 8d48fdf6.
Hmm - it would be interesting to know what device and tests that
change was based on.
Hmm
Am 03.07.2013 22:07, schrieb Reinhard Max:
> On Tue, 2 Jul 2013 at 18:31, Frank Schäfer wrote:
>
>> I've set up a test environment (currently limited to 115.2 kbps) and
>> can confirm that this works ONLY with the following (currently
>> supported) baud rates: 75, 150, 300, 600, 1200, 1800, 2400, 3
On Tue, 2 Jul 2013 at 18:31, Frank Schäfer wrote:
I've set up a test environment (currently limited to 115.2 kbps) and
can confirm that this works ONLY with the following (currently
supported) baud rates: 75, 150, 300, 600, 1200, 1800, 2400, 3600,
4800, 7200, 9600, 14400, 19200, 28800, 38400,
Am 28.06.2013 15:53, schrieb Frank Schäfer:
...
> Am 27.06.2013 22:13, schrieb Reinhard Max:
>> 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 c
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
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
Am 27.06.2013 19:14, schrieb Reinhard Max:
> Thanks for jumping in, Frank.
>
> Frank Schäfer writes:
>
>> I didn't read the whole thread yet, but what I can say for sure is that
>> the device I tested did _NOT_ support any non-standard baud rates.
> Then I'd be interested if it really was a PL2303
On Thu, 27 Jun 2013 at 19:25, Greg KH wrote:
None of those datasheets really help as they do not describe exactly
how to set the baud rates (or much anything else), so we can't rely
on them at all, sorry.
Come on, the configuration values for the documented baud rates are
exactly the 32bit i
On Thu, Jun 27, 2013 at 03:32:20PM +0200, Reinhard Max wrote:
> On Thu, 27 Jun 2013 at 07:17, Greg KH wrote:
>
> >On Wed, Jun 26, 2013 at 12:03:23PM +0200, Reinhard Max wrote:
> >
> >>OTOH, why should a driver impose such a limit at all [...]
> >
> >Because that's the way the driver has successful
Thanks for jumping in, Frank.
Frank Schäfer writes:
> I didn't read the whole thread yet, but what I can say for sure is that
> the device I tested did _NOT_ support any non-standard baud rates.
Then I'd be interested if it really was a PL2303X as you wrote in your
comment, because Prolific say
Am 27.06.2013 15:32, schrieb Reinhard Max:
> On Thu, 27 Jun 2013 at 07:17, Greg KH wrote:
>
>> On Wed, Jun 26, 2013 at 12:03:23PM +0200, Reinhard Max wrote:
>>
>>> OTOH, why should a driver impose such a limit at all [...]
>>
>> Because that's the way the driver has successfully worked for the
>> p
On Thu, 27 Jun 2013 at 07:17, Greg KH wrote:
On Wed, Jun 26, 2013 at 12:03:23PM +0200, Reinhard Max wrote:
OTOH, why should a driver impose such a limit at all [...]
Because that's the way the driver has successfully worked for the
past 10+ years?
Well, this particular part was added less
On Thu, 27 Jun 2013 at 15:32, Reinhard Max wrote:
(a PL2303HX as per the comment)
Sorry, I meant PL2303X.
cu
Reinhard
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
On Wed, Jun 26, 2013 at 12:03:23PM +0200, Reinhard Max wrote:
> On Tue, 25 Jun 2013 at 19:14, Greg KH wrote:
>
> >On Tue, Jun 25, 2013 at 11:54:37AM +0200, Reinhard Max wrote:
> >
> >>So, how about starting to get rid of the baud rate list by
> >>skipping it for HX chips only until someone with a
On Tue, 25 Jun 2013 at 19:14, Greg KH wrote:
On Tue, Jun 25, 2013 at 11:54:37AM +0200, Reinhard Max wrote:
So, how about starting to get rid of the baud rate list by skipping
it for HX chips only until someone with a type_0 or type_1 devices
can confirm that it works there as well?
How abou
On Tue, Jun 25, 2013 at 11:54:37AM +0200, Reinhard Max wrote:
> Hi Greg,
>
> coincidentally, I also tested non-standard baudrates on a PL2303
> these days and was about to start a similar thread when I found this
> one...
>
> On Fri, 14 Jun 2013 at 18:58, Greg KH wrote:
>
> >On Fri, Jun 14, 2013
On Tue, Jun 25, 2013 at 11:54:37AM +0200, Reinhard Max wrote:
> BTW2, the open source OSX driver[2] to which Prolific links from
> their support page, detects the chip revision, based on the USB
> device release number instead of guessing it from other properties
> of the device.
That driver was b
Hi Greg,
coincidentally, I also tested non-standard baudrates on a PL2303 these
days and was about to start a similar thread when I found this one...
On Fri, 14 Jun 2013 at 18:58, Greg KH wrote:
On Fri, Jun 14, 2013 at 11:20:01AM +0200, Mastro Gippo wrote:
PS: this device (at least mine) WI
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Fri, Jun 14, 2013 at 11:20:01AM +0200, Mastro Gippo wrote:
> Hi Greg,
> thanks for your reply. I spent some free time this week trying to
> compile and use the modified driver, but I'm unable to comp
Hi Greg,
thanks for your reply. I spent some free time this week trying to
compile and use the modified driver, but I'm unable to compile it, I'm
not an expert in compiling linux drivers, I may reinstall a fresh
linux version this weekend as I think I messed up something.
BTW; I'm quite sure that t
On Sun, Jun 09, 2013 at 10:38:01AM +0200, Mastro Gippo wrote:
> Hello, I'm working with a PL2303 device and I had an issue with the
> driver. Basically, I can't set the baudrate to 250kbps, but everything
> is better explained here:
> http://stackoverflow.com/questions/1778/prolific-pl2303-seri
On Sun, 9 Jun 2013 10:38:01 +0200
Mastro Gippo wrote:
> Hello, I'm working with a PL2303 device and I had an issue with the
> driver. Basically, I can't set the baudrate to 250kbps, but everything
> is better explained here:
> http://stackoverflow.com/questions/1778/prolific-pl2303-serial-por
Hello, I'm working with a PL2303 device and I had an issue with the
driver. Basically, I can't set the baudrate to 250kbps, but everything
is better explained here:
http://stackoverflow.com/questions/1778/prolific-pl2303-serial-port-to-25bps
I think that removing lines from 332 to 348 of th
27 matches
Mail list logo
