From: Ojaswin Mujoo <ojaswin98@gmail.com>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
nsaenz@kernel.org, dan.carpenter@oracle.com,
phil@raspberrypi.com, linux-arm-kernel@lists.infradead.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] vchiq: Patch to separate platform and cdev code
Date: Sat, 24 Jul 2021 16:14:47 +0530 [thread overview]
Message-ID: <20210724104447.GA3435@ojas> (raw)
In-Reply-To: <702bc38c-8ea2-eb30-84db-a647140585f6@i2se.com>
On Fri, Jul 23, 2021 at 03:31:58PM +0200, Stefan Wahren wrote:
> Am 23.07.21 um 14:59 schrieb Ojaswin Mujoo:
> > On Fri, Jul 23, 2021 at 01:02:41PM +0200, Greg KH wrote:
> >> On Wed, Jul 21, 2021 at 09:50:48PM +0530, Ojaswin Mujoo wrote:
> >>> 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
> >>>
> >>> Changes since v3 [2]:
> >>>
> >>> * In Patch 5, replace forward declarations of some of the functions with
> >>> function definition
> >> You dropped the reviews of others, so now I need to wait for them again
> >> :(
> >>
> > Hello Greg,
> >
> > Apologies for that, I was under the impression that a new version
> > needed a separate review :(
> No, just the patches which had functional changes.
Ohh, noted.
> > If its okay, I can alternately resubmit this (as v5?) with Stefan's
> > Reviewed-By tags on unchanged commits intact. Let me know if that's okay
> > or if its better to wait out.
>
> No, please don't resubmit. I will do the review soon.
Thanks for the review and all the help, Stefan. It is much appreciated
:)
Regards,
Ojaswin
WARNING: multiple messages have this Message-ID (diff)
From: Ojaswin Mujoo <ojaswin98@gmail.com>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
nsaenz@kernel.org, dan.carpenter@oracle.com,
phil@raspberrypi.com, linux-arm-kernel@lists.infradead.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] vchiq: Patch to separate platform and cdev code
Date: Sat, 24 Jul 2021 16:14:47 +0530 [thread overview]
Message-ID: <20210724104447.GA3435@ojas> (raw)
In-Reply-To: <702bc38c-8ea2-eb30-84db-a647140585f6@i2se.com>
On Fri, Jul 23, 2021 at 03:31:58PM +0200, Stefan Wahren wrote:
> Am 23.07.21 um 14:59 schrieb Ojaswin Mujoo:
> > On Fri, Jul 23, 2021 at 01:02:41PM +0200, Greg KH wrote:
> >> On Wed, Jul 21, 2021 at 09:50:48PM +0530, Ojaswin Mujoo wrote:
> >>> 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
> >>>
> >>> Changes since v3 [2]:
> >>>
> >>> * In Patch 5, replace forward declarations of some of the functions with
> >>> function definition
> >> You dropped the reviews of others, so now I need to wait for them again
> >> :(
> >>
> > Hello Greg,
> >
> > Apologies for that, I was under the impression that a new version
> > needed a separate review :(
> No, just the patches which had functional changes.
Ohh, noted.
> > If its okay, I can alternately resubmit this (as v5?) with Stefan's
> > Reviewed-By tags on unchanged commits intact. Let me know if that's okay
> > or if its better to wait out.
>
> No, please don't resubmit. I will do the review soon.
Thanks for the review and all the help, Stefan. It is much appreciated
:)
Regards,
Ojaswin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-24 10:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 16:20 [PATCH v4 0/5] vchiq: Patch to separate platform and cdev code Ojaswin Mujoo
2021-07-21 16:20 ` Ojaswin Mujoo
2021-07-21 16:20 ` [PATCH v4 1/5] staging: vchiq: Refactor vchiq " Ojaswin Mujoo
2021-07-21 16:20 ` Ojaswin Mujoo
2021-07-21 16:20 ` [PATCH v4 2/5] staging: vchiq: Move certain declarations to vchiq_arm.h Ojaswin Mujoo
2021-07-21 16:20 ` Ojaswin Mujoo
2021-07-21 16:20 ` [PATCH v4 3/5] staging: vchiq: Move vchiq char driver to its own file Ojaswin Mujoo
2021-07-21 16:20 ` Ojaswin Mujoo
2021-07-21 16:20 ` [PATCH v4 4/5] staging: vchiq: Make creation of vchiq cdev optional Ojaswin Mujoo
2021-07-21 16:20 ` Ojaswin Mujoo
2021-07-27 13:25 ` Greg KH
2021-07-27 13:25 ` Greg KH
2021-07-27 16:55 ` Ojaswin Mujoo
2021-07-27 16:55 ` Ojaswin Mujoo
2021-07-21 16:20 ` [PATCH v4 5/5] staging: vchiq: Combine vchiq platform code into single file Ojaswin Mujoo
2021-07-21 16:20 ` Ojaswin Mujoo
2021-07-23 11:02 ` [PATCH v4 0/5] vchiq: Patch to separate platform and cdev code Greg KH
2021-07-23 11:02 ` Greg KH
2021-07-23 12:59 ` Ojaswin Mujoo
2021-07-23 12:59 ` Ojaswin Mujoo
2021-07-23 13:31 ` Stefan Wahren
2021-07-23 13:31 ` Stefan Wahren
2021-07-24 10:44 ` Ojaswin Mujoo [this message]
2021-07-24 10:44 ` Ojaswin Mujoo
2021-07-24 9:38 ` Stefan Wahren
2021-07-24 9:38 ` Stefan Wahren
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210724104447.GA3435@ojas \
--to=ojaswin98@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=nsaenz@kernel.org \
--cc=phil@raspberrypi.com \
--cc=stefan.wahren@i2se.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.