Did you mean you have tried Shlomi's solution, but cause failure of N1's A1026 driver ??
On 7月9日, 上午9時40分, intersectRaven <rjg...@gmail.com> wrote: > Seems like it affects more drivers than just PMEM. I've reverted the > deletion and even tried the suggestions above. It will work for PMEM > but the N1's A1026 driver throws a tantrum when launching Google Voice > Search with the modifications to PMEM and the MISC commit reverted. > > On Jul 4, 9:33 am, intersectRaven <rjg...@gmail.com> wrote: > > > > > > > > > I actually just deleted the pmem check in it's open function since > > according to a more updated version in the codeaurora repositories, it > > could be removed. Of course, their pmem could have been updated to > > resolve this but I looked at it in a hurry. Haven't encountered any > > problems with it so far so it's good I think. We need more familiar > > developers to comment though. :) > > > On Jul 3, 7:10 pm, Shlomi Mor <shlomi....@gmail.com> wrote: > > > > Hi, > > > > I actually extended the if statement as follows: > > > if (file->private_data != NULL && file->private_data != &pmem[id].dev) > > > > Also, at the beginning of the has_allocation function I changed the if > > > statement: > > > if (unlikely(!file->private_data || file->private_data == &pmem[id].dev)) > > > > At least for the scenarios I am using this is working just fine. > > > > The only potential problem is that we are overriding the value that was > > > written by misc_open function. But, if I understand the the patch at > > > misc_open, it was added just in order to pass the miscdevice pointer to > > > the > > > opened device. The opened device is not obligated to use that pointer, and > > > it can override the private_data if it wants to. > > > I also found few other misc drivers who are overriding the private_data > > > field. > > > > Thanks, > > > Shlomi -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
