Hi Takashi,
On Fri, 2018-09-28 at 12:44 +0900, Takashi Sakamoto wrote:
Hi Scott,
On Sep 24 2018 18:32, Scott Bahling wrote:
The kernel was unstable and the system hard locked frequently with the patches enabled (with and without the GFP_KERNEL patch). But I was able to map out all the controller functions to the bits in the first 16 quadlets. I will write up my findings and send them later.
I'm sorry but I have applied wrong changes to the remote branch for kernel patch. It includes three issues:
- call vfree() to memory object allocated by kmalloc()
- bring kernel oops due to double free corruption of 'tscm->status'
- invalid page mapping of 'tscm->status' to process' VMA
I pushed additional three patches. Would you please test with them?
- 1777454 firewire-tascam: fix kernel oops to call vfree() to memory
object allocated by kmalloc
- e11d941 firewire-tascam: fix double free corruption
- 5e7fef9 firewire-tascam: use one page for mmap(2)ed data
Espeially, when allocating in kernel logical space instead of kernel virtual space, I should have kept one page for 'tscm->status' because kmalloc() allocates memory object unaligned to page boundary by kernel SLAB/SLOB/SLUB allocaters. This is a cause which you cannot see updated data. A page mapped to process' VMA doesn't include region of 'tscm->status' data correctly.
Again, I'm sorry to lost your time due to this kind of my stupid codes...
No worries! It did not waste too much time at all. I assumed it's just quick test code anyway. I was able to get the button press events and control levels mapped to the quadlet bits which was my goal (I'm still documenting my findings).
I will test your new patches this weekend and let you know if it works better.
Are you still thinking to try to make mmap the solution to pass the control data to userspace, or do we need to find another method in the long run?
Regards,
Scott