|
@@ -23,3 +23,34 @@ there's a lot code that got built that's probably unnecessary these
|
|
|
days. Once we have the set of VCHI-using drivers we want in tree, we
|
|
|
should be able to do a sweep of the code to see what's left that's
|
|
|
unused.
|
|
|
+
|
|
|
+3) Make driver more portable
|
|
|
+
|
|
|
+Building this driver with arm/multi_v7_defconfig or arm64/defconfig
|
|
|
+leads to data corruption during the following command:
|
|
|
+
|
|
|
+ vchiq_test -f 1
|
|
|
+
|
|
|
+This should be fixed.
|
|
|
+
|
|
|
+4) Fix kernel module support
|
|
|
+
|
|
|
+Even the VPU firmware doesn't support a VCHI re-connect, the driver
|
|
|
+should properly handle a module unload. This also includes that all
|
|
|
+resouces must be freed (kthreads, debugfs entries, ...) and global
|
|
|
+variables avoided.
|
|
|
+
|
|
|
+5) Fix stack hog
|
|
|
+
|
|
|
+Running make checkstack shows that vchiq_dump_service_use_state() has
|
|
|
+an extensive stack usage. Maybe other functions are also affected.
|
|
|
+
|
|
|
+6) Cleanup logging mechanism
|
|
|
+
|
|
|
+The driver should probably be using the standard kernel logging mechanisms
|
|
|
+such as dev_info, dev_dbg, and friends.
|
|
|
+
|
|
|
+7) Documentation
|
|
|
+
|
|
|
+A short top-down description of this driver's architecture (function of
|
|
|
+kthreads, userspace, limitations) could be very helpful for reviewers.
|