Fixes the following regression that has been introduced recently with commit
b2d6d98fc7:
With type_0 and type_1 chips
- all baud rates 1228800 baud are rounded up to 1228800 baud
- the device silently runs at 9600 baud for all baud rates 1228800 baud
Signed-off-by: Frank Schäfer fschaefer
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 215 +++
1 Datei geändert, 114 Zeilen hinzugefügt(+), 101 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index dd48317
for both methods so that the resulting baud rate would be the same.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 12
1 Datei geändert, 12 Zeilen hinzugefügt(+)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
some minor fixes, the handling of the special cases and further
code/algorithm descriptions.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Signed-off-by: Reinhard Max m...@suse.de
---
drivers/usb/serial/pl2303.c | 59 +++
1 Datei geändert, 49
of standard baud rates.
Remove the 50 baud value from the list of standard baud rates again, because
this list is only used with the direct baud rate encoding method and 50
baud is not supported with this method.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial
better (sets the baud rate more
precisely).
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c |6 +-
1 Datei geändert, 5 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 1e6de4c
-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 5085568..93a6465 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers
In opposition to the direct baud rate encoding method, the divisor based method
is not limited to a fixed set of standard baud rates. Hence there is no need to
round to the next nearest standard value.
Reported-by: Mastro Gippo gip...@gmail.com
Signed-off-by: Frank Schäfer fschaefer
maximum baud rates of 110% of the specified
limit,
so for now, increase the upper limit to this value.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Signed-off-by: Reinhard Max m...@suse.de
---
drivers/usb/serial/pl2303.c | 16
1 Datei geändert, 12 Zeilen hinzugefügt
with a PL2303HX 04463A (week 46, 2004, rev 3A).
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 61c9f9d
for both methods so that the
resulting baud rate would be the same.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 12
1 Datei geändert, 12 Zeilen hinzugefügt(+)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
some minor fixes, the handling of the special cases and
further code/algorithm descriptions.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Signed-off-by: Reinhard Max m...@suse.de
---
drivers/usb/serial/pl2303.c | 62 ---
1 Datei geändert, 52
In opposition to the direct baud rate encoding method, the divisor
based method is not limited to a fixed set of standard baud rates.
Hence, there is no need to round to the next nearest standard value.
Reported-by: Mastro Gippo gip...@gmail.com
Signed-off-by: Frank Schäfer fschaefer
with this method.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c |4 ++--
1 Datei geändert, 2 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 04390df..a0ea92e 100644
--- a/drivers/usb
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 215 +++
1 Datei geändert, 114 Zeilen hinzugefügt(+), 101 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index a0ea92e
- patch 1: specified the copyrights more precisely
Frank Schäfer (7):
pl2303: fix+improve the divsor based baud rate encoding method
pl2303: do not round to the next nearest standard baud rate for the
divisor based baud rate encoding method
pl2303: remove 50 baud from the list
maximum baud rates of 110% of the
specified limit, so for now, increase the upper limit to this value.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Signed-off-by: Reinhard Max m...@suse.de
---
drivers/usb/serial/pl2303.c | 16
1 Datei geändert, 12 Zeilen hinzugefügt
The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 15
the distinction further...
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 95 ---
1 Datei geändert, 72 Zeilen hinzugefügt(+), 23 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial
type information output.
Patch 3 finally improves the chip type detection/distinction by
splitting the HX chip type into 3 chip groups.
The 3 groups need to be split further, but we don't know yet how to do this.
Frank Schäfer (3):
pl2303: simplify the else-if contruct for type_1 chips
There is no need for two else-if constructs for the type_1 chip
detection in pl2303_startup(), so merge them.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c |5 ++---
1 Datei geändert, 2 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
diff --git
type information output.
Patch 3 finally improves the chip type detection/distinction by
splitting the HX chip type into 3 chip groups.
The 3 groups need to be split further, but we don't know yet how to do this.
Changes since v1:
- changed dev_info() in patch 2 to dev_dbg()
Frank Schäfer (3
the distinction further...
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 95 ---
1 Datei geändert, 72 Zeilen hinzugefügt(+), 23 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial
The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 15
://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225pcid=41
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 41 +++--
1 Datei geändert, 31 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
diff --git a/drivers/usb/serial
-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 43 ---
1 Datei geändert, 32 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index e7a84f0..bedf8e4 100644
Am 14.09.2013 12:13, schrieb Frank Schäfer:
According to Prolific, several (unauthorized) cheap and less functional
clones of the PL2303HX chip are in circulation. [1]
I've had the chance to test such a cloned device and it turned out that
it doesn't support any baud rates above 115200 baud
Am 14.09.2013 14:19, schrieb Greg KH:
On Sat, Sep 14, 2013 at 12:13:03PM +0200, Frank Schäfer wrote:
According to Prolific, several (unauthorized) cheap and less functional
clones of the PL2303HX chip are in circulation. [1]
No footnote showed up in this changelog comment, care to fix this up
://www.prolific.com.tw/US/ShowProduct.aspx?p_id=225pcid=41
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 43 ---
1 Datei geändert, 32 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-)
diff --git a/drivers/usb/serial
Am 25.10.2013 12:27, schrieb Mika Westerberg:
On Thu, Oct 24, 2013 at 03:20:02PM +0200, Frank Schäfer wrote:
Ok, this seems to be a HXD (HX rev. D) chip.
Could you please validate by checking what Prolifics CheckChipVersion
tool toll sais ?
It says: This is a PL-2303 HXD chip.
Good, so it's
Am 25.10.2013 15:17, schrieb Mika Westerberg:
On Fri, Oct 25, 2013 at 03:01:37PM +0200, Frank Schäfer wrote:
Tried few other baudrates 115200 and they don't work either.
Urgh... has this device ever been working at baud rates 115200 ?
I have only used it as a serial console for a device
Am 28.10.2013 09:27, schrieb Mika Westerberg:
On Fri, Oct 25, 2013 at 03:43:03PM +0200, Frank Schäfer wrote:
Am 25.10.2013 15:17, schrieb Mika Westerberg:
On Fri, Oct 25, 2013 at 03:01:37PM +0200, Frank Schäfer wrote:
Tried few other baudrates 115200 and they don't work either.
Urgh... has
back to the direct encoding method for baud rates = 115200, because
it's unclear if the old divisor based encoding algorithm works for them.
Reported-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 64
Am 29.10.2013 10:07, schrieb Mika Westerberg:
On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote:
Mika Westerberg has reported that the fixed+improved divisor based baud rate
encoding method doesn't work anymore with his HXD device.
So until we've found out what's going
Am 29.10.2013 18:12, schrieb Frank Schäfer:
Am 29.10.2013 10:07, schrieb Mika Westerberg:
On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote:
Mika Westerberg has reported that the fixed+improved divisor based baud
rate
encoding method doesn't work anymore with his HXD device.
So
Am 30.10.2013 09:45, schrieb Mika Westerberg:
On Tue, Oct 29, 2013 at 06:42:49PM +0100, Frank Schäfer wrote:
Am 29.10.2013 18:12, schrieb Frank Schäfer:
Am 29.10.2013 10:07, schrieb Mika Westerberg:
On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote:
Mika Westerberg has reported
Am 30.10.2013 23:07, schrieb Frank Schäfer:
Am 30.10.2013 09:45, schrieb Mika Westerberg:
On Tue, Oct 29, 2013 at 06:42:49PM +0100, Frank Schäfer wrote:
Am 29.10.2013 18:12, schrieb Frank Schäfer:
Am 29.10.2013 10:07, schrieb Mika Westerberg:
On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank
Am 31.10.2013 12:09, schrieb Mika Westerberg:
On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote:
Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11.
If it makes no difference, it's not a pl2303 issue.
I did that and the 3.11 pl2303.c works (whereas 3.12
Am 31.10.2013 13:03, schrieb Mika Westerberg:
On Thu, Oct 31, 2013 at 01:09:55PM +0200, Mika Westerberg wrote:
On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote:
Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11.
If it makes no difference, it's not a pl2303
Am 31.10.2013 13:30, schrieb Mika Westerberg:
On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote:
2) comment out the following line at the end of
pl2303_baudrate_encode_divisor_HXD():
baud = 1200 * 32 / ((1 buf[1]) * buf[0]);
This seems to fix the problem :)
Once the line
Am 31.10.2013 21:56, schrieb Johan Hovold:
On Thu, Oct 31, 2013 at 09:26:06PM +0100, Johan Hovold wrote:
On Thu, Oct 31, 2013 at 7:45 PM, Frank Schäfer wrote:
Am 31.10.2013 13:30, schrieb Mika Westerberg:
On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote:
2) comment out
Am 01.11.2013 11:06, schrieb Frank Schäfer:
Am 31.10.2013 21:56, schrieb Johan Hovold:
On Thu, Oct 31, 2013 at 09:26:06PM +0100, Johan Hovold wrote:
On Thu, Oct 31, 2013 at 7:45 PM, Frank Schäfer wrote:
Am 31.10.2013 13:30, schrieb Mika Westerberg:
On Thu, Oct 31, 2013 at 01:02:56PM +0100
Am 01.11.2013 11:22, schrieb Johan Hovold:
Greg, what do you say about this? Is reverting for 3.12 the correct way
to deal with this, and make sure these fairly invasive patches get some
more testing before being reapplied?
Reverting would mean reverting a whole bunch of commits though, as
Am 01.11.2013 11:39, schrieb Mika Westerberg:
On Fri, Nov 01, 2013 at 11:06:40AM +0100, Frank Schäfer wrote:
No need to revert all these patches, removing the calculation of the
resulting baud rateat the end of fcn pl2303_baudrate_encode_divisor()
should fix this issue.
The remaining question
baud rates can result
in identic encoded baud rates.
The solution is to save and compare the encoded settings instead.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
Cc: sta...@kernel.org
---
drivers/usb/serial/pl2303.c | 22 ++
1 Datei geändert, 14 Zeilen
Am 01.11.2013 11:59, schrieb Mika Westerberg:
On Fri, Nov 01, 2013 at 11:45:32AM +0100, Frank Schäfer wrote:
Am 01.11.2013 11:39, schrieb Mika Westerberg:
On Fri, Nov 01, 2013 at 11:06:40AM +0100, Frank Schäfer wrote:
No need to revert all these patches, removing the calculation
Am 01.11.2013 12:15, schrieb Johan Hovold:
On Fri, Nov 01, 2013 at 11:44:33AM +0100, Frank Schäfer wrote:
Am 01.11.2013 11:22, schrieb Johan Hovold:
Greg, what do you say about this? Is reverting for 3.12 the correct way
to deal with this, and make sure these fairly invasive patches get some
Am 01.11.2013 13:19, schrieb Mika Westerberg:
On Fri, Nov 01, 2013 at 12:49:22PM +0100, Frank Schäfer wrote:
Some PL2303 chips are reported to lose bytes if the serial settings are set
to
the same values as before.
At least HXD chips are affected, HX chips seem to be ok.
The current code
Am 01.11.2013 14:29, schrieb Johan Hovold:
On Fri, Nov 01, 2013 at 01:03:24PM +0100, Frank Schäfer wrote:
Am 01.11.2013 12:15, schrieb Johan Hovold:
On Fri, Nov 01, 2013 at 11:44:33AM +0100, Frank Schäfer wrote:
Am 01.11.2013 11:22, schrieb Johan Hovold:
I think that adding support for odd
Am 25.02.2013 21:54, schrieb Alan Stern:
Sarah (and anyone else who's interested):
A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
controllers. You pointed out that these are rather old components, not
being used in current systems, which is quite true.
Now I have
available with the modified
driver from Frank Schäfer.
What driver is that? The latest clone-related patch from Frank that I've
seen stated:
According to Prolific, several (unauthorized) cheap and less
functional clones of the PL2303HX chip are in circulation. [1]
I've had
and there is a good chance that we have to run after this
information one day...
Just my two cents.
Regards,
Frank Schäfer
Signed-off-by: Aaron Sanders aaron.sand...@hp.com
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 3b5ba4f..4d70809 100644
--- a/drivers/usb/serial
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
past 10+ years?
Am 27.06.2013 19:14, schrieb Reinhard Max:
Thanks for jumping in, Frank.
Frank Schäfer fschaefer.oss@... 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
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
Hi Johan,
first of all:
I see you've sent lots of great fixes and improvements for the
USB-serial drivers during last months.
I would like to thank you for all your work in this area !
One remark concerning this patch:
Am 26.06.2013 16:47, schrieb Johan Hovold:
Clean up baud-rate handling
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
Am 03.07.2013 12:45, schrieb Johan Hovold:
On Tue, Jul 02, 2013 at 05:44:01PM +0200, Frank Schäfer wrote:
- /* NOTE: Only the values defined in baud_sup are supported !
+ /*
+* NOTE: Only the values defined in baud_sup are supported!
* = if unsupported values are set
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, 3600
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 what
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 16 something
, ...).
Do we have any confirmation/feedback from users that one of these new
chip variants is working with the driver ?
Regards,
Frank Schäfer
--
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
Am 14.07.2013 19:20, schrieb Greg Kroah-Hartman:
On Sun, Jul 14, 2013 at 07:19:06PM +0200, Frank Sch?fer wrote:
Hi Greg,
the pl2303 driver currently knows 3 different chip types: type_0,
type_1 and HX.
What do we know about type_0 and type_1 ? Do we know any real chip
names ?
I don't know
Am 05.10.2012 18:44, schrieb Octavio Alvarez:
On 10/05/2012 07:56 AM, Alan Stern wrote:
On Mon, 9 Jul 2012, Octavio Alvarez wrote:
What happens if you unplug only the keyboard, or only the mouse?
The only thing I can confirm for now is that with both disconnected
the system consistently
Am 11.12.2012 17:48, schrieb Alan Stern:
[snip]
We really need to know which component is bad: the host controller or
the device.
It happens with all USB 1.1 devices I have (several mice and a HP
Deskjet 960c printer).
The same devices do not cause other machines to wake up, so I assume
it's
Am 12.12.2012 09:23, schrieb Lan Tianyu:
On 2012年12月12日 05:59, Frank Schäfer wrote:
Am 11.12.2012 17:48, schrieb Alan Stern:
[snip]
We really need to know which component is bad: the host controller or
the device.
It happens with all USB 1.1 devices I have (several mice and a HP
Deskjet
Am 13.12.2012 09:45, schrieb Lan Tianyu:
[snip]
I am curious about whether disabling usb device's wakeup rather than usb
hc's would make suspend work. Can you do a test?
Go to /sys/bus/usb/devices/ and enter the usb 1,1 device
directory(normally it will be something like1-1.1.)
run echo
Am 19.12.2012 16:29, schrieb Alan Stern:
On Wed, 19 Dec 2012, Lan Tianyu wrote:
...
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
@@ -238,6 +247,31 @@
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data =
Am 19.12.2012 20:35, schrieb Alan Stern:
On Wed, 19 Dec 2012, [ISO-8859-1] Frank Sch�fer wrote:
I can confirm that MCP55 has this bug and it should be safe to add
MCP65-78S, too, because MCP79 still has the bug.
By the way, you mentioned that runtime suspend seemed to work okay,
right? It
Am 21.12.2012 18:02, schrieb Alan Stern:
snip
On Fri, 21 Dec 2012, Frank Schäfer wrote:
00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev
a2) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Device 8234
Control: I/O+ Mem+ BusMaster- SpecCycle
Am 24.12.2012 20:23, schrieb Alan Stern:
On Fri, 21 Dec 2012, Frank Schäfer wrote:
Anyway, system still wakes up from S3 immediately.
It just occurred to me that not too long ago we learned about a BIOS
bug in ASUS systems that affects EHCI controllers during system suspend
(the workaround
Am 28.12.2012 01:10, schrieb Alan Stern:
On Wed, 26 Dec 2012, Octavio Alvarez wrote:
It can't hurt to try the test. Does the patch below make any
difference?
Thank you for the patch, but it makes no difference. :(
Too bad.
I looked for more instances of linux immediate wakeup and found
Am 03.01.2013 21:58, schrieb Alan Stern:
...
On Thu, 3 Jan 2013, Octavio Alvarez wrote:
If not, then what would the sanest default be? Where to document
this cas in a clean, user friendly way?
The sanest default is what my patch does: disable wakeup for OHCI
controllers on computers with
Am 04.01.2013 14:20, schrieb Roger Quadros:
Hi Gary,
On 01/04/2013 02:20 PM, Gary Thomas wrote:
On Thursday, January 3, 2013 9:21:19 AM UTC-7, Felipe Balbi wrote:
Hi,
On Wednesday, January 2, 2013 10:44:50 PM UTC+2, Gary Thomas wrote:
I have a video adapter attached to
Am 24.12.2014 um 11:51 schrieb Russell King - ARM Linux:
While testing an EM28xx based USB DVB stick which I've recently acquired,
I find that occasionally the driver stops responding after it returns
-EFBIG from one of its ioctls. I've no idea whether there's a previous
kernel version which
the way described in the old comment.
This definitely isn't my HX (rev A) nor my other HX knockoff.
This also isn't whatever chips Frank Schäfer used during 57ce61aad748
development.
100% correct.
Finally, this probably isn't this comment author's chip either. I bet
he wrote the comment
Am 13.07.2015 um 18:47 schrieb Johan Hovold:
On Mon, Jul 13, 2015 at 06:08:50PM +0200, Michał Pecio wrote:
Commit 57ce61aad748 might be helpful... ;)
Good luck,
Frank
Pretty much the same thing I have done, except that I didn't notice that
0 = 512 :)
Apparently, 57ce61aad748 fell
Am 15.07.2015 um 13:16 schrieb Johan Hovold:
Your changes caused a regression that was discovered mere days before
3.12 was released. At the time the reason had not been fully determined
so the patches were consequently reverted.
Simply not true, re-read the ML archieves.
In that case I
Am 14.07.2015 um 22:29 schrieb Greg KH:
On Tue, Jul 14, 2015 at 09:29:29PM +0200, Frank Schäfer wrote:
If you want to pick this up and improve the divisor calculations that'd
be great.
Maybe you should just start doing your job as the maintainer and accept
one of the patches people
Am 08.07.2015 um 12:51 schrieb Michał Pecio:
This commit fixes the following issues:
1. The 9th bit of buf was believed to be the LSB of divisor's
exponent, but the hardware interprets it as MSB (9th bit) of the
mantissa. The exponent is actually one bit shorter and applies
to base 4, not
Am 13.07.2015 um 18:08 schrieb Michał Pecio:
Commit 57ce61aad748 might be helpful... ;)
Good luck,
Frank
Pretty much the same thing I have done, except that I didn't notice that
0 = 512 :)
:)
Apparently, 57ce61aad748 fell victim of a mass-revert caused by some
underdebugged issues.
81 matches
Mail list logo
