Hi Dmitry, On Tue, Jun 18, 2024 at 09:59:07PM +0300, Dmitry Baryshkov wrote: > On Mon, Jun 03, 2024 at 02:24:53AM GMT, Dmitry Baryshkov wrote: > > The interface between UCSI and the glue driver is very low-level. It > > allows reading the UCSI data from any offset (but in reality the UCSI > > driver reads only VERSION, CCI an MESSAGE_IN data). All event handling > > is to be done by the glue driver (which already resulted in several > > similar-but-slightly different implementations). It leaves no place to > > optimize the write-read-read sequence for the command execution (which > > might be beneficial for some of the drivers), etc. > > > > The patchseries attempts to restructure the UCSI glue driver interface > > in order to provide sensible operations instead of a low-level read / > > write calls. > > > > If this approach is found to be acceptable, I plan to further rework the > > command interface, moving reading CCI and MESSAGE_IN to the common > > control code, which should simplify driver's implementation and remove > > necessity to split quirks between sync_control and read_message_in e.g. > > as implemented in the ucsi_ccg.c. > > > > Note, the series was tested only on the ucsi_glink platforms. Further > > testing is appreciated. > > Gracious ping for the reviews / comments. My endgoal is to simplify the > command submission interface, allowing us to handle odd commands in a > single function rather than having the code split between sync_write() > and notification handling. I don't have any objections. Just rebase these and drop the RFC. The patch 6/7 did not apply cleanly anymore on top of the two dependencies you listed. thanks, -- heikki
