From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Thu, 9 Oct 2014 11:06:31 -0700 Subject: [U-Boot] u-boot, fsl_espi.c driver In-Reply-To: References: <5436B704.2060502@freescale.com> Message-ID: <5436CEA7.6040006@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Joakim, On 10/09/2014 10:43 AM, Joakim Tjernlund wrote: > York Sun wrote on 2014/10/09 18:25:40: >> >> Dear Joakim, >> >> Thanks for raising a concern. >> >> It's not fair to blame the last person who submitted a patch. We are all > working > > No of course not, I just noticed you guys had been in there and patched up > some problem > so I hoped you would be interested to fix the remaining problems. This > driver should never > have been committed in the first place. > >> to make it better as an opensource comminuty. You have done a good job > to hack >> it to work. Would it be nicer if you can submit this or improved patch > to u-boot >> community for further review and testing, after putting informing commit >> message? The mailing list address is CC'ed. > > Main problem with this driver is that TX does not work for: > len > max_tran_len (nor does RX) > does not TX the last odd bytes(len % 4 != 0) > Does not work with TX only(RX buf == NULL) > > Silently ignores SPI_LSB_FIRST > > On top of that it uses malloc all over and copies data back and forth for > no good > reason, image a big SPI transfer with many MB(like my FPGA load). > > I am not in a good position fix this properly as my FPGA is TX only so I > cannot test > RX at all(which is broken by my hack) > > Finally, just to illustrate the merits of this driver, after transmission > is done > there is: > if (*buffer == 0x0b) { > data_in += tran_len; > data_len -= tran_len; > *(int *)buffer += tran_len; > } > what is the magic 0x0b test all about? > Thanks for the report. Driver maintainer (CC'ed) will take a look. York