mbox series

[v3,0/5] vchiq: Patch to separate platform and cdev code

Message ID cover.1625401927.git.ojaswin98@gmail.com (mailing list archive)
Headers show
Series vchiq: Patch to separate platform and cdev code | expand

Message

Ojaswin Mujoo July 4, 2021, 3:56 p.m. UTC
Hello,

This patchset adderesses the TODO item number 10 specified at:

    drivers/staging/vc04-services/interface/TODO

For reference, the task is:

    10) Reorganize file structure: Move char driver to it's own file and join
    both platform files

    The cdev is defined alongside with the platform code in vchiq_arm.c. It
    would be nice to completely decouple it from the actual core code. For
    instance to be able to use bcm2835-audio without having /dev/vchiq created.
    One could argue it's better for security reasons or general cleanliness. It
    could even be interesting to create two different kernel modules, something
    the likes of vchiq-core.ko and vchiq-dev.ko. This would also ease the
    upstreaming process.

A summary of the patches is as follows:

- Patch 1: Move cdev init code into a function
- Patch 2: Shift some devlarations from vchiq_arm.c to vchiq_arm.h for
           sharing
- Patch 3: Move vchiq cdev init code from vchiq_arm.c into vchiq_dev.c
- Patch 4: Decouple cdev code by defining a Kconfig entry to allow
           optional compilation of it.
- Patch 5: Merge code in vchiq_2835_arm.c to vchiq_arm.c

(More details can be found in the commit messages)

Changes since v2 [1]:

* In Patch 1, as suggested, I have added error handling code back to
  ensure the driver exits when there is an error in creating vchiq cdev
  
* I have built this patch against the right kernel (gregkh/staging,
  staging-next branch) to avoid introducing any unwanted inconsistencies
  like whitespace changes

I have tested the patch using vchiq_test utility on RPi 3B+.

Additionally, I had a small question regarding the next steps here
(quoting my cover letter from v2):

This question is more related to the next set of patches I'm
planning to submit. So the last thing left in this TODO is to
completely decouple vchiq platform and cdev code into 2 separate
modules and I am planning to do that in a different patchset. 

The approach I have in mind is to start by using EXPORT_SYMBOL to
export all the functions (and accessor functions for variables like
g_state) that would be required for cdev init. Majority of these
would be exported from vchiq_arm.c and vchiq_core.c, and will then be
used in vchiq-dev.ko. Is this the right way to approach this? 

Thank you in advance for the help. Please let me know if any changes/
additional info is required.

Regards,
Ojaswin

[1] v2: https://lkml.org/lkml/2021/6/20/63

Ojaswin Mujoo (5):
  staging: vchiq: Refactor vchiq cdev code
  staging: vchiq: Move certain declarations to vchiq_arm.h
  staging: vchiq: Move vchiq char driver to its own file
  staging: vchiq: Make creation of vchiq cdev optional
  staging: vchiq: Combine vchiq platform code into single file

 drivers/staging/vc04_services/Kconfig         |   10 +
 drivers/staging/vc04_services/Makefile        |    5 +-
 .../interface/vchiq_arm/vchiq_2835_arm.c      |  564 ----
 .../interface/vchiq_arm/vchiq_arm.c           | 2344 +++++------------
 .../interface/vchiq_arm/vchiq_arm.h           |   82 +
 .../interface/vchiq_arm/vchiq_dev.c           | 1440 ++++++++++
 6 files changed, 2265 insertions(+), 2180 deletions(-)
 delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
 create mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c

Comments

Stefan Wahren July 11, 2021, 10:29 a.m. UTC | #1
Hi Ojaswin,

Am 04.07.21 um 17:56 schrieb Ojaswin Mujoo:
> Hello,
>
> This patchset adderesses the TODO item number 10 specified at:
>
>     drivers/staging/vc04-services/interface/TODO
>
> For reference, the task is:
>
>     10) Reorganize file structure: Move char driver to it's own file and join
>     both platform files
>
>     The cdev is defined alongside with the platform code in vchiq_arm.c. It
>     would be nice to completely decouple it from the actual core code. For
>     instance to be able to use bcm2835-audio without having /dev/vchiq created.
>     One could argue it's better for security reasons or general cleanliness. It
>     could even be interesting to create two different kernel modules, something
>     the likes of vchiq-core.ko and vchiq-dev.ko. This would also ease the
>     upstreaming process.
>
> A summary of the patches is as follows:
>
> - Patch 1: Move cdev init code into a function
> - Patch 2: Shift some devlarations from vchiq_arm.c to vchiq_arm.h for
>            sharing
> - Patch 3: Move vchiq cdev init code from vchiq_arm.c into vchiq_dev.c
> - Patch 4: Decouple cdev code by defining a Kconfig entry to allow
>            optional compilation of it.
> - Patch 5: Merge code in vchiq_2835_arm.c to vchiq_arm.c
>
> (More details can be found in the commit messages)
>
> Changes since v2 [1]:
>
> * In Patch 1, as suggested, I have added error handling code back to
>   ensure the driver exits when there is an error in creating vchiq cdev
>   
> * I have built this patch against the right kernel (gregkh/staging,
>   staging-next branch) to avoid introducing any unwanted inconsistencies
>   like whitespace changes
>
> I have tested the patch using vchiq_test utility on RPi 3B+.
>
> Additionally, I had a small question regarding the next steps here
> (quoting my cover letter from v2):
>
> This question is more related to the next set of patches I'm
> planning to submit. So the last thing left in this TODO is to
> completely decouple vchiq platform and cdev code into 2 separate
> modules and I am planning to do that in a different patchset. 
>
> The approach I have in mind is to start by using EXPORT_SYMBOL to
> export all the functions (and accessor functions for variables like
> g_state) that would be required for cdev init. Majority of these
> would be exported from vchiq_arm.c and vchiq_core.c, and will then be
> used in vchiq-dev.ko. Is this the right way to approach this? 

i'm back from vacation and had some time for review. IMHO the patch
series is fine (except some nits in patch 5) regarding the task in the
TODO list. Making cdev a separate module is a cool idea, but it's not
really necessary for moving this driver out of staging. There are more
important things to do.

Thank you

Regards
Stefan

>
> Thank you in advance for the help. Please let me know if any changes/
> additional info is required.
>
> Regards,
> Ojaswin
>
> [1] v2: https://lkml.org/lkml/2021/6/20/63
>
> Ojaswin Mujoo (5):
>   staging: vchiq: Refactor vchiq cdev code
>   staging: vchiq: Move certain declarations to vchiq_arm.h
>   staging: vchiq: Move vchiq char driver to its own file
>   staging: vchiq: Make creation of vchiq cdev optional
>   staging: vchiq: Combine vchiq platform code into single file
>
>  drivers/staging/vc04_services/Kconfig         |   10 +
>  drivers/staging/vc04_services/Makefile        |    5 +-
>  .../interface/vchiq_arm/vchiq_2835_arm.c      |  564 ----
>  .../interface/vchiq_arm/vchiq_arm.c           | 2344 +++++------------
>  .../interface/vchiq_arm/vchiq_arm.h           |   82 +
>  .../interface/vchiq_arm/vchiq_dev.c           | 1440 ++++++++++
>  6 files changed, 2265 insertions(+), 2180 deletions(-)
>  delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>  create mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
>