pt., 15 lut 2019 o 10:06 H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> napisał(a): > > Hi Philipp, > > > Am 14.02.2019 um 19:55 schrieb Philipp Rossak <embed3d@xxxxxxxxx>: > > > > > > > > On 14.02.19 19:28, Tony Lindgren wrote: > >> * Philipp Rossak <embed3d@xxxxxxxxx> [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@xxxxxxxxxxxxxxx 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 >
