From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Wed, 22 Oct 2014 15:14:10 -0700 Subject: [U-Boot] u-boot, fsl_espi.c driver In-Reply-To: References: <5436B704.2060502@freescale.com> <5436CEA7.6040006@freescale.com> Message-ID: <54482C32.7000203@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 Jagan and Mingkai, Would you take a look when you have a chance? York On 10/22/2014 03:12 PM, Joakim Tjernlund wrote: > York Sun wrote on 2014/10/09 20:06:31: >> >> 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 > > No reaction from maintainers, I don't think this driver is still > maintained. > > Jocke >