Re: [PATCH v5 00/15] Add Broadcom VK driver

[Florian Fainelli]

On 9/30/2020 6:27 PM, Scott Branden wrote:
> This patch series drops previous patches in [1]
> that were incorporated by Kees Cook into patch series
> "Introduce partial kernel_read_file() support" [2].
>
> Remaining patches are contained in this series to add Broadcom VK driver.
> (which depends on request_firmware_into_buf API addition in
> other patch series [2] being applied first).
>
> Please note this patch series will not compile without [2].
>
> [1] https://lore.kernel.org/lkml/20200706232309.12010-1-scott.branden@xxxxxxxxxxxx/
> [2] https://lore.kernel.org/lkml/20200729175845.1745471-1-keescook@xxxxxxxxxxxx/

Disclaimer: I am well aware that it is the complete wild west right now 
as far as accelerators go and that every vendor (that I happen to work 
for, just not in the same group as Scott) is just seeking to get their 
drivers included upstream and hopefully for good reasons.

From a cursory look however, it sounds like there could be a little 
better re-utilization of standards, standard framework and interfaces:

- about 2/3 of your sysfs attributes should incline you to implement a 
HWMON device, not a complicated one, but anything that indicates 
current, power, temperature, alerts etc. should be considered

- cannot the firmware loading be supported over remoteproc somehow?

- could not the TTY interface be using virtio or an existing UART?

- what is the format of the message over BAR2 that you expose in patch 13?

Is there a reference user-space implementation that you can link to this 
patch submission in case people are curious?

Thanks
--
Florian