This patch series modify the vme_user driver's place in
menuconfig (1/3), fixes a missing `depends on` line in a Kconfig file
(2/3), and rearrages the directory tree for the driver allowing a more
straightforward comprehension of its contents (3/3).
The 'vme_user/' driver is the only remaining vme-family driver in the
'staging/' tree, but its structure, entry in menuconfig and building
routines are still attached to the 'vme/' subtree now outside
'staging/'. The present patchset fixes it.
Signed-off-by: Bruno Moreira-Guedes <[email protected]>
---
CHANGE SUMMARY
Version: v1 v2 v3
[PATCH 1/3] * - *
[PATCH 2/3] - * *
[PATCH 3/3] - * *
CHANGELOG
[PATCH 0/3] staging: vme: Restructuring menuconfig and tree
v1:
Created PATCH 1/3 as a single patch
v2:
Added PATCH 2/3 and 3/3, turning it into a patchset
v3:
Fixed and improved commit messages according to previous comments by
Greg and Alison (to whom I'm indebted for their kind reviews). The
commit titles got changed to be more specific and use the present
imperative tense as for Alison's suggestions. The message body got
fixed according to Greg formatting comments. The changelogs were moved
to the cover letter as per another suggestion by Alison, and I added
missing details (like the update in the MAINTAINERS I failed to
mention in v2) and made textual improvements for clarity that I also
noticed.
[PATCH 1/3] staging: vme: Move vme_user to staging KConfig
v1:
- Sourced "drivers/staging/vme/devices/Kconfig" in
"drivers/staging/Kconfig" and unsourced in "drivers/vme/Kconfig".
v3:
- Modified the commit subject and text body.
[PATCH 2/3] staging: vme: Add VME_BUS dependency to Kconfig
v2:
- Added this patch to the patchset.
v3:
- Modified the commit subject and text body.
[PATCH 3/3] staging: vme: Move 'vme/devices' to 'vme_user/'
v2:
- Added this patch to the patchset
v3
- Modified the commit subject and text body.
Bruno Moreira-Guedes (3):
staging: vme: Adjusted VME_USER in Kconfig
staging: vme: Fix missing `depends on` at KConfig
staging: vme: "drivers/staging/vme" tree cleanup
MAINTAINERS | 2 +-
drivers/staging/Kconfig | 1 +
drivers/staging/Makefile | 2 +-
drivers/staging/vme/Makefile | 2 --
drivers/staging/{vme/devices => vme_user}/Kconfig | 2 +-
drivers/staging/{vme/devices => vme_user}/Makefile | 0
drivers/staging/{vme/devices => vme_user}/vme_user.c | 0
drivers/staging/{vme/devices => vme_user}/vme_user.h | 0
drivers/vme/Kconfig | 2 --
9 files changed, 4 insertions(+), 7 deletions(-)
delete mode 100644 drivers/staging/vme/Makefile
rename drivers/staging/{vme/devices => vme_user}/Kconfig (93%)
rename drivers/staging/{vme/devices => vme_user}/Makefile (100%)
rename drivers/staging/{vme/devices => vme_user}/vme_user.c (100%)
rename drivers/staging/{vme/devices => vme_user}/vme_user.h (100%)
--
2.35.3
On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> This patch series modify the vme_user driver's place in
> menuconfig (1/3), fixes a missing `depends on` line in a Kconfig file
> (2/3), and rearrages the directory tree for the driver allowing a more
> straightforward comprehension of its contents (3/3).
>
> The 'vme_user/' driver is the only remaining vme-family driver in the
> 'staging/' tree, but its structure, entry in menuconfig and building
> routines are still attached to the 'vme/' subtree now outside
> 'staging/'. The present patchset fixes it.
>
> Signed-off-by: Bruno Moreira-Guedes <[email protected]>
Hi Bruno,
I see your follow-on questions to GregKH about the 2 v2's and rolling
this set. I imagine you are going to work with many maintainers across
the kernel, so although understanding their processes is interesting and
useful, at some point just keeping your submittals clean, simple, and
straightforward is the more efficient path forward. If it were me, I think
I could get a v4 in GregKHs mailbox quicker than going around with him
on why his tools don't understand my oddities. (I admire your curiosity,
seriously! I'm just in a get it done and move on mood.)
In this case - you can see that this set is confusing because of the
v2, then v3 of a single patch. I suggest cleaning it up while GregKH is
sleeping ;) and get a clean v4 in his mbox.
Not sure your process - but if you are using git send-email, the
--dry-run option is how I do the final eye-balling of what I'm
about to send. Try that out.
The changelog below can be more succinct. I made a suggestion below.
> ---
> CHANGE SUMMARY
>
> Version: v1 v2 v3
> [PATCH 1/3] * - *
> [PATCH 2/3] - * *
> [PATCH 3/3] - * *
>
> CHANGELOG
> [PATCH 0/3] staging: vme: Restructuring menuconfig and tree
> v1:
> Created PATCH 1/3 as a single patch
> v2:
> Added PATCH 2/3 and 3/3, turning it into a patchset
> v3:
> Fixed and improved commit messages according to previous comments by
> Greg and Alison (to whom I'm indebted for their kind reviews). The
> commit titles got changed to be more specific and use the present
> imperative tense as for Alison's suggestions. The message body got
> fixed according to Greg formatting comments. The changelogs were moved
> to the cover letter as per another suggestion by Alison, and I added
> missing details (like the update in the MAINTAINERS I failed to
> mention in v2) and made textual improvements for clarity that I also
> noticed.
>
> [PATCH 1/3] staging: vme: Move vme_user to staging KConfig
> v1:
> - Sourced "drivers/staging/vme/devices/Kconfig" in
> "drivers/staging/Kconfig" and unsourced in "drivers/vme/Kconfig".
> v3:
> - Modified the commit subject and text body.
>
> [PATCH 2/3] staging: vme: Add VME_BUS dependency to Kconfig
> v2:
> - Added this patch to the patchset.
> v3:
> - Modified the commit subject and text body.
>
> [PATCH 3/3] staging: vme: Move 'vme/devices' to 'vme_user/'
> v2:
> - Added this patch to the patchset
> v3
> - Modified the commit subject and text body.
Changes in v4:
- Remove extraneous patch from set
Changes in v3:
- Move changelog to cover letter (Alison)
- Update commit messages and logs (Greg, Alison)
Changes in v2:
- Add new patch to set: Move 'vme/devices' to 'vme_user/'
- Add new patch to set: Add VME_BUS dependency to Kconfig
**I really want you to get this accepted before the next patch
comes along and removes the driver entirely :(.
Alison
>
> Bruno Moreira-Guedes (3):
> staging: vme: Adjusted VME_USER in Kconfig
> staging: vme: Fix missing `depends on` at KConfig
> staging: vme: "drivers/staging/vme" tree cleanup
>
> MAINTAINERS | 2 +-
> drivers/staging/Kconfig | 1 +
> drivers/staging/Makefile | 2 +-
> drivers/staging/vme/Makefile | 2 --
> drivers/staging/{vme/devices => vme_user}/Kconfig | 2 +-
> drivers/staging/{vme/devices => vme_user}/Makefile | 0
> drivers/staging/{vme/devices => vme_user}/vme_user.c | 0
> drivers/staging/{vme/devices => vme_user}/vme_user.h | 0
> drivers/vme/Kconfig | 2 --
> 9 files changed, 4 insertions(+), 7 deletions(-)
> delete mode 100644 drivers/staging/vme/Makefile
> rename drivers/staging/{vme/devices => vme_user}/Kconfig (93%)
> rename drivers/staging/{vme/devices => vme_user}/Makefile (100%)
> rename drivers/staging/{vme/devices => vme_user}/vme_user.c (100%)
> rename drivers/staging/{vme/devices => vme_user}/vme_user.h (100%)
>
> --
> 2.35.3
>
On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> This patch series modify the vme_user driver's place in
> menuconfig (1/3), fixes a missing `depends on` line in a Kconfig file
> (2/3), and rearrages the directory tree for the driver allowing a more
> straightforward comprehension of its contents (3/3).
>
> The 'vme_user/' driver is the only remaining vme-family driver in the
> 'staging/' tree, but its structure, entry in menuconfig and building
> routines are still attached to the 'vme/' subtree now outside
> 'staging/'. The present patchset fixes it.
>
> Signed-off-by: Bruno Moreira-Guedes <[email protected]>
What about deleting the vme drivers entirely?
Martyn, anyone still using these?
thanks,
greg k-h
On Thu, Apr 21, 2022 at 08:16:05PM +0100, Martyn Welch wrote:
> On Wed, 2022-04-20 at 18:43 +0200, Greg Kroah-Hartman wrote:
> > On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> > > This patch series modify the vme_user driver's place in
> > > menuconfig (1/3), fixes a missing `depends on` line in a Kconfig
> > > file
> > > (2/3), and rearrages the directory tree for the driver allowing a
> > > more
> > > straightforward comprehension of its contents (3/3).
> > >
> > > The 'vme_user/' driver is the only remaining vme-family driver in
> > > the
> > > 'staging/' tree, but its structure, entry in menuconfig and
> > > building
> > > routines are still attached to the 'vme/' subtree now outside
> > > 'staging/'. The present patchset fixes it.
> > >
> > > Signed-off-by: Bruno Moreira-Guedes <[email protected]>
> >
> > What about deleting the vme drivers entirely?
>
> I assume you're suggesting deleting the "vme_user" driver from the
> staging directory?
Yes, at the very least given that no one has tried to fix it up and get
it out of staging in many years.
> > Martyn, anyone still using these?
> >
>
> I'm fairly sure that the actual VME drivers for the hardware bridges
> (the bits not in staging) are still being used based on the
> conversations I've had today. I'm just trying to find out whether the
> vme_user bit is actively being used.
If the non-staging vme drivers are still being used, that's great. But
if not, those too should be dropped.
thanks,
greg k-h
On Wed, 2022-04-20 at 18:43 +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> > This patch series modify the vme_user driver's place in
> > menuconfig (1/3), fixes a missing `depends on` line in a Kconfig
> > file
> > (2/3), and rearrages the directory tree for the driver allowing a
> > more
> > straightforward comprehension of its contents (3/3).
> >
> > The 'vme_user/' driver is the only remaining vme-family driver in
> > the
> > 'staging/' tree, but its structure, entry in menuconfig and
> > building
> > routines are still attached to the 'vme/' subtree now outside
> > 'staging/'. The present patchset fixes it.
> >
> > Signed-off-by: Bruno Moreira-Guedes <[email protected]>
>
> What about deleting the vme drivers entirely?
I assume you're suggesting deleting the "vme_user" driver from the
staging directory?
> Martyn, anyone still using these?
>
I'm fairly sure that the actual VME drivers for the hardware bridges
(the bits not in staging) are still being used based on the
conversations I've had today. I'm just trying to find out whether the
vme_user bit is actively being used.
Martyn
> thanks,
>
> greg k-h
Hello,
On Fri, Apr 22, 2022 at 08:39:36AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 21, 2022 at 08:16:05PM +0100, Martyn Welch wrote:
> > On Wed, 2022-04-20 at 18:43 +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> > > > This patch series modify the vme_user driver's place in
> > > > menuconfig (1/3), fixes a missing `depends on` line in a Kconfig
> > > > file
> > > > (2/3), and rearrages the directory tree for the driver allowing a
> > > > more
> > > > straightforward comprehension of its contents (3/3).
> > > >
> > > > The 'vme_user/' driver is the only remaining vme-family driver in
> > > > the
> > > > 'staging/' tree, but its structure, entry in menuconfig and
> > > > building
> > > > routines are still attached to the 'vme/' subtree now outside
> > > > 'staging/'. The present patchset fixes it.
> > > >
> > > > Signed-off-by: Bruno Moreira-Guedes <[email protected]>
> > >
> > > What about deleting the vme drivers entirely?
> >
> > I assume you're suggesting deleting the "vme_user" driver from the
> > staging directory?
>
> Yes, at the very least given that no one has tried to fix it up and get
> it out of staging in many years.
While I cannot comment anything on that regard, I imagine the v4 I sent
a couple of days ago will wait for that decision, right?
Should I prepare a patch removing them and also submit so when it's
decided you can just pick one patch or the other?
>
> > > Martyn, anyone still using these?
> > >
> >
> > I'm fairly sure that the actual VME drivers for the hardware bridges
> > (the bits not in staging) are still being used based on the
> > conversations I've had today. I'm just trying to find out whether the
> > vme_user bit is actively being used.
>
> If the non-staging vme drivers are still being used, that's great. But
> if not, those too should be dropped.
>
> thanks,
>
> greg k-h
On Wed, Apr 27, 2022 at 09:18:51AM -0300, Bruno Moreira-Guedes wrote:
> Hello,
>
> On Fri, Apr 22, 2022 at 08:39:36AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Apr 21, 2022 at 08:16:05PM +0100, Martyn Welch wrote:
> > > On Wed, 2022-04-20 at 18:43 +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> > > > > This patch series modify the vme_user driver's place in
> > > > > menuconfig (1/3), fixes a missing `depends on` line in a Kconfig
> > > > > file
> > > > > (2/3), and rearrages the directory tree for the driver allowing a
> > > > > more
> > > > > straightforward comprehension of its contents (3/3).
> > > > >
> > > > > The 'vme_user/' driver is the only remaining vme-family driver in
> > > > > the
> > > > > 'staging/' tree, but its structure, entry in menuconfig and
> > > > > building
> > > > > routines are still attached to the 'vme/' subtree now outside
> > > > > 'staging/'. The present patchset fixes it.
> > > > >
> > > > > Signed-off-by: Bruno Moreira-Guedes <[email protected]>
> > > >
> > > > What about deleting the vme drivers entirely?
> > >
> > > I assume you're suggesting deleting the "vme_user" driver from the
> > > staging directory?
> >
> > Yes, at the very least given that no one has tried to fix it up and get
> > it out of staging in many years.
>
> While I cannot comment anything on that regard, I imagine the v4 I sent
> a couple of days ago will wait for that decision, right?
I do not know what you are referring to, sorry. My staging patch queue
is empty right now.
> Should I prepare a patch removing them and also submit so when it's
> decided you can just pick one patch or the other?
Let's wait on a removal patch for now.
thanks,
greg k-h
On Wed, Apr 27, 2022 at 02:31:38PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 27, 2022 at 09:18:51AM -0300, Bruno Moreira-Guedes wrote:
> > Hello,
> >
> > On Fri, Apr 22, 2022 at 08:39:36AM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Apr 21, 2022 at 08:16:05PM +0100, Martyn Welch wrote:
> > > > On Wed, 2022-04-20 at 18:43 +0200, Greg Kroah-Hartman wrote:
> > > > > On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> > > > > > This patch series modify the vme_user driver's place in
> > > > > > menuconfig (1/3), fixes a missing `depends on` line in a Kconfig
> > > > > > file
> > > > > > (2/3), and rearrages the directory tree for the driver allowing a
> > > > > > more
> > > > > > straightforward comprehension of its contents (3/3).
> > > > > >
> > > > > > The 'vme_user/' driver is the only remaining vme-family driver in
> > > > > > the
> > > > > > 'staging/' tree, but its structure, entry in menuconfig and
> > > > > > building
> > > > > > routines are still attached to the 'vme/' subtree now outside
> > > > > > 'staging/'. The present patchset fixes it.
> > > > > >
> > > > > > Signed-off-by: Bruno Moreira-Guedes <[email protected]>
> > > > >
> > > > > What about deleting the vme drivers entirely?
> > > >
> > > > I assume you're suggesting deleting the "vme_user" driver from the
> > > > staging directory?
> > >
> > > Yes, at the very least given that no one has tried to fix it up and get
> > > it out of staging in many years.
> >
> > While I cannot comment anything on that regard, I imagine the v4 I sent
> > a couple of days ago will wait for that decision, right?
>
> I do not know what you are referring to, sorry. My staging patch queue
> is empty right now.
Ohhh, okay, no problem, I have sent a v4 around 6 days ago and thought
you were waiting on this definition.
>
> > Should I prepare a patch removing them and also submit so when it's
> > decided you can just pick one patch or the other?
>
> Let's wait on a removal patch for now.
Sure, I'll be waiting for Martyn's response then, if he says it's still
in use I resend the last one.
>
> thanks,
>
> greg k-h
>
Sincerely,
Bruno
On Wed, Apr 27, 2022 at 09:41:14AM -0300, Bruno Moreira-Guedes wrote:
> On Wed, Apr 27, 2022 at 02:31:38PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 27, 2022 at 09:18:51AM -0300, Bruno Moreira-Guedes wrote:
> > > Hello,
> > >
> > > On Fri, Apr 22, 2022 at 08:39:36AM +0200, Greg Kroah-Hartman wrote:
> > > > On Thu, Apr 21, 2022 at 08:16:05PM +0100, Martyn Welch wrote:
> > > > > On Wed, 2022-04-20 at 18:43 +0200, Greg Kroah-Hartman wrote:
> > > > > > On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> > > > > > > This patch series modify the vme_user driver's place in
> > > > > > > menuconfig (1/3), fixes a missing `depends on` line in a Kconfig
> > > > > > > file
> > > > > > > (2/3), and rearrages the directory tree for the driver allowing a
> > > > > > > more
> > > > > > > straightforward comprehension of its contents (3/3).
> > > > > > >
> > > > > > > The 'vme_user/' driver is the only remaining vme-family driver in
> > > > > > > the
> > > > > > > 'staging/' tree, but its structure, entry in menuconfig and
> > > > > > > building
> > > > > > > routines are still attached to the 'vme/' subtree now outside
> > > > > > > 'staging/'. The present patchset fixes it.
> > > > > > >
> > > > > > > Signed-off-by: Bruno Moreira-Guedes <[email protected]>
> > > > > >
> > > > > > What about deleting the vme drivers entirely?
> > > > >
> > > > > I assume you're suggesting deleting the "vme_user" driver from the
> > > > > staging directory?
> > > >
> > > > Yes, at the very least given that no one has tried to fix it up and get
> > > > it out of staging in many years.
> > >
> > > While I cannot comment anything on that regard, I imagine the v4 I sent
> > > a couple of days ago will wait for that decision, right?
> >
> > I do not know what you are referring to, sorry. My staging patch queue
> > is empty right now.
> Ohhh, okay, no problem, I have sent a v4 around 6 days ago and thought
> you were waiting on this definition.
If I did not take it, please resend.
thanks,
greg k-h
On Wed, Apr 27, 2022 at 03:10:47PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 27, 2022 at 09:41:14AM -0300, Bruno Moreira-Guedes wrote:
> > On Wed, Apr 27, 2022 at 02:31:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Apr 27, 2022 at 09:18:51AM -0300, Bruno Moreira-Guedes wrote:
> > > > Hello,
> > > >
> > > > On Fri, Apr 22, 2022 at 08:39:36AM +0200, Greg Kroah-Hartman wrote:
> > > > > On Thu, Apr 21, 2022 at 08:16:05PM +0100, Martyn Welch wrote:
> > > > > > On Wed, 2022-04-20 at 18:43 +0200, Greg Kroah-Hartman wrote:
> > > > > > > On Mon, Apr 18, 2022 at 08:29:49PM -0300, Bruno Moreira-Guedes wrote:
> > > > > > > > This patch series modify the vme_user driver's place in
> > > > > > > > menuconfig (1/3), fixes a missing `depends on` line in a Kconfig
> > > > > > > > file
> > > > > > > > (2/3), and rearrages the directory tree for the driver allowing a
> > > > > > > > more
> > > > > > > > straightforward comprehension of its contents (3/3).
> > > > > > > >
> > > > > > > > The 'vme_user/' driver is the only remaining vme-family driver in
> > > > > > > > the
> > > > > > > > 'staging/' tree, but its structure, entry in menuconfig and
> > > > > > > > building
> > > > > > > > routines are still attached to the 'vme/' subtree now outside
> > > > > > > > 'staging/'. The present patchset fixes it.
> > > > > > > >
> > > > > > > > Signed-off-by: Bruno Moreira-Guedes <[email protected]>
> > > > > > >
> > > > > > > What about deleting the vme drivers entirely?
> > > > > >
> > > > > > I assume you're suggesting deleting the "vme_user" driver from the
> > > > > > staging directory?
> > > > >
> > > > > Yes, at the very least given that no one has tried to fix it up and get
> > > > > it out of staging in many years.
> > > >
> > > > While I cannot comment anything on that regard, I imagine the v4 I sent
> > > > a couple of days ago will wait for that decision, right?
> > >
> > > I do not know what you are referring to, sorry. My staging patch queue
> > > is empty right now.
> > Ohhh, okay, no problem, I have sent a v4 around 6 days ago and thought
> > you were waiting on this definition.
Bruno - I see your patches was applied to staging-testing
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/log/?h=staging-testing
>
> If I did not take it, please resend.
>
> thanks,
>
> greg k-h
>