[U-Boot] u-boot, fsl_espi.c driver

Joakim Tjernlund
2014-10-09T21:13:24Z

York Sun <yorksun@freescale.com> wrote on 2014/10/09 20:06:31:
>
> Dear Joakim,
>
> On 10/09/2014 10:43 AM, Joakim Tjernlund wrote:
> > York Sun <yorksun@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