pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller hns@goldelico.com napisał(a):
Hi Philipp,
Am 14.02.2019 um 19:55 schrieb Philipp Rossak embed3d@gmail.com:
On 14.02.19 19:28, Tony Lindgren wrote:
- Philipp Rossak embed3d@gmail.com [190214 10:18]:
I set the displayed name to "OpenSGX Linux Driver Group" but that can be changed later, if necessary.
You might want to change it to something more specific like "OpenPVRSGX Linux Driver Group" :) There is already non-graphics related Intel SGX "opensgx": https://github.com/sslab-gatech/opensgx Regards, Tony
Thanks Tony!
I changed it and I also renamed the oranzation. So there is now a new link: https://github.com/openpvrsgx-devgroup
Only Two people in organization ? And is there anyone on irc ?
Fine!
I have tried to get in, but there seems to be no "request to join" button or something. So I'll send you my github user name by PM. Or if you can send a invitation by e-mails, just copy the list from this mail?
Next, I had asked postmaster@vger.kernel.org to get a mailing list for us, but they declined with only stating "it is not appropriate" because it is for kernel related topics. I asked again that we work for the Linux kernel and want to get it into staging, but that is still not appropriate. No further details, so that I do not know what really would be appropriate. Does it need Linus' approval or must be decided on some core developer meeting? But that is just my guess.
Finally, I have tested our omap3 version and it works fine in v4.15. But is broken in v4.16.17 and beyond. This problem did not get noticed in our automatic tests because they test only for module loading and /dev/pvrsrvkm existence and not for pvrsrvctl --start success.
Now, I found one bug in my patch set that prevented running v4.17 and later because the code was not compatible with CONFIG_RESET_CONTROLLER=y (which we do have enabled since v4.17). After fixing this, it still returns an EFAULT in some ioctl() during firmware download.
But I could reduce it to be introduced between v4.16.13 to v4.16.15. I am currently doing a bisect so that seems not to be far away from finding the problematic commit.
BR, NIkolaus