From: Ojaswin Mujoo <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
Subject: [PATCH 0/1] Request to review progress decoupling vchiq platform code
Date: Tue, 15 Jun 2021 01:02:32 +0530 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
I'm working on addressing item 10 of the following TODO list:
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
This patch is the first step towards decoupling the platform and the cdev code.
It moves all the cdev related code from vchiq_arm.c to vchiq_dev.c. However, for
now, I have aimed to keep the functionality untouched, hence the platform code
still calls the cdev initialisation function, and isn't truly decoupled yet.
The summary of the changes is as follows:
* Definition of functions and variables shared by cdev and platform
code are moved to vchiq_arm.h while declaration stays in vchiq_arm.c
* Declaration and definition of functions and variables only used by
cdev code are moved to vchiq_dev.c file.
* Defined vchiq_deregister_chrdev() and vchiq_register_chrdev(..) in
vchiq_dev.c which handle cdev creation and deletion. They are called by the
platfrom code during probe().
I mainly wanted to put this patch out to see if I have the right idea of the
task at hand and to ensure I'm heading into the right direction. I would love to
hear your thoughts and suggestions on this. Once I have some feedback on this, I
can accordingly work towards a newer version to completely decouple the code.
Lastly, I had some questions related to the the task:
1. So regarding the following line in the TODO:
"For instance to be able to use bcm2835-audio without having /dev/vchiq
I was wondering about the possible ways to achieve this. Specifically, I was
thinking of the following 2 ways:
1.1 Making a KConfig entry for Cdev creation, like CONFIG_VCHIQ_CDEV, and
then do something like:
/* platform init code */
/* Call cdev register function */
1.2 The second approach is creating an entirely separate module for the cdev,
as suggested in the TODO.
So I'm just wondering what the right approach should be?
2. Second, I currently tested by installing my patches to a pi3 B+ and running
`cat /dev/vchiq` to compare the output with the original kernel. Also, to
see if the platform code works without the cdev code, I commented out the
call to vchiq_register_cdev() and made sure the platform device (and
children) was registered but the char device was not present. However, I'm
not sure if these tests are comprehensive enough. What would be the right way
to test my changes?
3. Lastly, I think the git diff is acting up a bit because of the code
rearrangement. I tried to check online if this is normal or if I messed it
up somehow, but couldn't find much. Can someone please confirm this?
Thank you in advance for looking into this and for helping me out upto this
Ojaswin Mujoo (1):
staging: vchiq: Move vchiq char driver to its own file
drivers/staging/vc04_services/Makefile | 1 +
.../interface/vchiq_arm/vchiq_arm.c | 1885 ++---------------
.../interface/vchiq_arm/vchiq_arm.h | 73 +
.../interface/vchiq_arm/vchiq_dev.c | 1488 +++++++++++++
4 files changed, 1770 insertions(+), 1677 deletions(-)
create mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
next reply other threads:[~2021-06-14 19:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 19:32 Ojaswin Mujoo [this message]
2021-06-14 19:33 ` [PATCH 1/1] staging: vchiq: Move vchiq char driver to its own file Ojaswin Mujoo
2021-06-14 22:06 ` [PATCH 0/1] Request to review progress decoupling vchiq platform code Stefan Wahren
2021-06-15 17:10 ` Ojaswin Mujoo
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).