Re: [PATCH v4 RESEND] hid-ft260: Add serial driver

[Michael Zaidman <michael.zaidman@gmail.com>]

On Sun, Jan 21, 2024 at 11:12:54AM +0200, Michael Zaidman wrote:
> On Sun, Jan 21, 2024 at 11:13:36AM +1300, Daniel Beer wrote:
> > On Sat, Jan 20, 2024 at 08:41:28PM +0200, Michael Zaidman wrote:
> > > Hi Daniel and Christina,
> > > 
> > > My concern with the implemented workaround is that sending a dummy report
> > > every 4.8 seconds eliminates the chip's power save mode functionality.
> > > 
> > > I did more testing and figured out that the baud rates 4800 and below work
> > > fine with power saving mode and do not require this workaround.
> > > 
> > > So, I modified the code, making it dependent on the baud rate in this commit:
> > > https://github.com/MichaelZaidman/hid-ft260/commit/b5a2ad68c7cebbaaba0aa1675ae376f2895e19aa
> > > 
> > > 
> > > Another improvement is not to activate the wakeup workaround if power
> > > saving mode is not enabled in EEPROM.
> > > https://github.com/MichaelZaidman/hid-ft260/commit/0a41f3f3a4c664edc3bb90718807f2e62fe6d375
> > > 
> > > For UART testing, I sent files via picocom opened on ttyUSB0 (ch340 USB
> > > dongle device) connected to ft260 UART, receiving and displaying the
> > > trafic in screen manager utility.
> > > 
> > > --Michael
> > 
> > Hi Michael,
> > 
> > That sounds like a good idea to me. Are you planning to submit your
> > improved version from here?
> > 
> > I don't have any FT260 hardware with me any more, so there's
> > unfortunately not much I can do now to help, aside from answering
> > questions.
> > 
> > Cheers,
> > Daniel
> > 
> 
> Yeah, I mean to do more testing, and then I will submit a new patch set
> based on your work.
> 
> --Michael
>
Hi Daniel,

I pushed changes into https://github.com/MichaelZaidman/hid-ft260/tree/uart
branch and would appreciate your review and feedback before preparing the
cumulative patch set.

I addressed the first FIXME. Please correct me if I did not get right what
you meant.

I am still doubting regarding the second FIXME. I see only three tty drivers
are using the kfifo_avail and kfifo_len to retrieve the write room and number
of chars in the buffer, and neither use locking. What was your concern?

Thanks,
Michael