York Sun <york...@freescale.com> wrote on 2014/10/09 20:06:31: > > Dear Joakim, > > On 10/09/2014 10:43 AM, Joakim Tjernlund wrote: > > York Sun <york...@freescale.com> 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. > Great, I do have some ideas on what to do ishould there be any interest. Jocke _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot