[PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

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 <codeagain@codeagain.dev>
---
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v3 1/3] staging: vme: Move vme_user to staging KConfig

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

Currently, the VME_USER driver is in the staging tree Kconfig, unlike
other VME drivers already moved to the main portions of the kernel tree.
Its configuration is, however, nested into the VME_BUS config option,
which might be misleading.

Since the staging tree "[...] is used to hold stand-alone drivers and
filesystem that are not ready to be merged into the main portion of the
Linux kernel tree [...]"(from 
https://lore.kernel.org/all/20090320172502.GA14647@kroah.com/T/),
staging drivers should appear nested into the Main Menu -> Device
Drivers -> Staging Drivers to make sure the user don't pick it without
being fully aware of its staging status as it could be the case in
Menu -> Device Drivers -> VME bridge support (the current location).

With this change menuconfig users will clearly know this is not a driver
in the main portion of the kernel tree and decide whether to build it or
not with that clearly in mind.

This change goes into the same direction of commit
<4b4cdf3979c32fa3d042d150f49449c74d048553> ("STAGING: Move staging
drivers back to staging-specific menu")

Signed-off-by: Bruno Moreira-Guedes <codeagain@codeagain.dev>
---
 drivers/staging/Kconfig | 2 ++
 drivers/vme/Kconfig     | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index fc274737053d..e4dcf411030d 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -87,4 +87,6 @@ source "drivers/staging/fieldbus/Kconfig"
 source "drivers/staging/qlge/Kconfig"
 
 
+source "drivers/staging/vme/devices/Kconfig"
+
 endif # STAGING
diff --git a/drivers/vme/Kconfig b/drivers/vme/Kconfig
index 936392ca3c8c..c13dd9d2a604 100644
--- a/drivers/vme/Kconfig
+++ b/drivers/vme/Kconfig
@@ -15,6 +15,4 @@ source "drivers/vme/bridges/Kconfig"
 
 source "drivers/vme/boards/Kconfig"
 
-source "drivers/staging/vme/devices/Kconfig"
-
 endif # VME
-- 
2.35.3
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v2 2/3] staging: vme: Add VME_BUS dependency to Kconfig

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

The KConfig file for VME_USER ('drivers/staging/vme/devices/Kconfig')
sourced at "drivers/vme/boards/KConfig" misses a `depends on` line for
VME_BUS, which is unnoticeable for menuconfig users who aren't be able
to select it through this interface without setting the CONFIG_VME_BUS
option because it's nested on VME_BUS menu entry.

A patch to move appropriately this driver to the "Staging" submenu
([PATCH 1/3], originally sent as a single patch submitted at
https://lore.kernel.org/linux-staging/3fbc5325e94b9ae0666a1f5a56a4e5372bfcea1d.camel@codeagain.dev/T/#t),
however, unveiled this missing `depends on` line, since it moved the
`source` line for VME_USER's KConfig to somewhere else, allowing it to
be compiled without the support for VME_BUS. While it compiles fine and
seems to initialize the driver fine (tested both as module and as built-
in), it seems to make no sense having VME_USER without VME_BUS.

This patches addresses it by adding the VME_BUS to the `depends on` line
at "drivers/staging/vme/devices/Kconfig".

Signed-off-by: Bruno Moreira-Guedes <codeagain@codeagain.dev>
---
 drivers/staging/vme/devices/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vme/devices/Kconfig b/drivers/staging/vme/devices/Kconfig
index 5651bb16b28b..e8b4461bf27f 100644
--- a/drivers/staging/vme/devices/Kconfig
+++ b/drivers/staging/vme/devices/Kconfig
@@ -3,7 +3,7 @@ comment "VME Device Drivers"
 
 config VME_USER
 	tristate "VME user space access driver"
-	depends on STAGING
+	depends on STAGING && VME_BUS
 	help
 	  If you say Y here you want to be able to access a limited number of
 	  VME windows in a manner at least semi-compatible with the interface
-- 
2.35.3


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v3 3/3] staging: vme: Move 'vme/devices' to 'vme_user/'

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]

In <db3b9e990e75573402cda22faf933760f076c033> ("Staging: VME: move VME 
drivers out of staging") the vme code, board and bridge drivers were
moved out of the staging tree, remaining only the VME user device 
driver.

Since this driver is the only one remaining in staging, such multi-level
structure confuses more than helps. The current structure is as follows:

 - drivers/staging/vme/
                       Makefile
                       devices/
                               Kconfig
                               Makefile
                               vme_user.c
                               vme_user.h

The top-level Makefile has the only function of calling another Makefile
into the devices/ subdirectory. This latter only compiles the vme_user 
driver, since there is no other in the staging tree.

This patch removes the unnecessary Makefile from the 'vme/' dir, move
the contents of 'vme/devices' into the 'vme/' dir, and renames it to
'vme_user/' (the driver name), allowing a straightforward understanding
of this driver's contents. Furthermore, it updates the MAINTAINERS file
to properly reflect the new paths.

Signed-off-by: Bruno Moreira-Guedes <codeagain@codeagain.dev>
---
 MAINTAINERS                                          | 2 +-
 drivers/staging/Kconfig                              | 3 +--
 drivers/staging/Makefile                             | 2 +-
 drivers/staging/vme/Makefile                         | 2 --
 drivers/staging/{vme/devices => vme_user}/Kconfig    | 0
 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
 8 files changed, 3 insertions(+), 6 deletions(-)
 delete mode 100644 drivers/staging/vme/Makefile
 rename drivers/staging/{vme/devices => vme_user}/Kconfig (100%)
 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%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3ed62dcd144e..efc38961f792 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21010,7 +21010,7 @@ L:	linux-kernel@vger.kernel.org
 S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
 F:	Documentation/driver-api/vme.rst
-F:	drivers/staging/vme/
+F:	drivers/staging/vme_user/
 F:	drivers/vme/
 F:	include/linux/vme*
 
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e4dcf411030d..e117811ec832 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -86,7 +86,6 @@ source "drivers/staging/fieldbus/Kconfig"
 
 source "drivers/staging/qlge/Kconfig"
 
-
-source "drivers/staging/vme/devices/Kconfig"
+source "drivers/staging/vme_user/Kconfig"
 
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 65e317922e3f..db7287de0faf 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_OCTEON_ETHERNET)	+= octeon/
 obj-$(CONFIG_OCTEON_USB)	+= octeon-usb/
 obj-$(CONFIG_VT6655)		+= vt6655/
 obj-$(CONFIG_VT6656)		+= vt6656/
-obj-$(CONFIG_VME_BUS)		+= vme/
+obj-$(CONFIG_VME_BUS)		+= vme_user/
 obj-$(CONFIG_IIO)		+= iio/
 obj-$(CONFIG_FB_SM750)		+= sm750fb/
 obj-$(CONFIG_USB_EMXX)		+= emxx_udc/
diff --git a/drivers/staging/vme/Makefile b/drivers/staging/vme/Makefile
deleted file mode 100644
index cf2f686ccffe..000000000000
--- a/drivers/staging/vme/Makefile
+++ /dev/null
@@ -1,2 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-obj-y				+= devices/
diff --git a/drivers/staging/vme/devices/Kconfig b/drivers/staging/vme_user/Kconfig
similarity index 100%
rename from drivers/staging/vme/devices/Kconfig
rename to drivers/staging/vme_user/Kconfig
diff --git a/drivers/staging/vme/devices/Makefile b/drivers/staging/vme_user/Makefile
similarity index 100%
rename from drivers/staging/vme/devices/Makefile
rename to drivers/staging/vme_user/Makefile
diff --git a/drivers/staging/vme/devices/vme_user.c b/drivers/staging/vme_user/vme_user.c
similarity index 100%
rename from drivers/staging/vme/devices/vme_user.c
rename to drivers/staging/vme_user/vme_user.c
diff --git a/drivers/staging/vme/devices/vme_user.h b/drivers/staging/vme_user/vme_user.h
similarity index 100%
rename from drivers/staging/vme/devices/vme_user.h
rename to drivers/staging/vme_user/vme_user.h
-- 
2.35.3
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v3 2/3] staging: vme: Add VME_BUS dependency to Kconfig

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

The KConfig file for VME_USER ('drivers/staging/vme/devices/Kconfig')
sourced at "drivers/vme/boards/KConfig" misses a `depends on` line for
VME_BUS, which is unnoticeable for menuconfig users who aren't be able
to select it through this interface without setting the CONFIG_VME_BUS
option because it's nested on VME_BUS menu entry.

A patch to move appropriately this driver to the "Staging" submenu
([PATCH 1/3], originally sent as a single patch submitted at
https://lore.kernel.org/linux-staging/3fbc5325e94b9ae0666a1f5a56a4e5372bfcea1d.camel@codeagain.dev/T/#t),
however, unveiled this missing `depends on` line, since it moved the
`source` line for VME_USER's KConfig to somewhere else, allowing it to
be compiled without the support for VME_BUS. While it compiles fine and
seems to initialize the driver fine (tested both as module and as built-
in), it seems to make no sense having VME_USER without VME_BUS.

This patches addresses it by adding the VME_BUS to the `depends on` line
at "drivers/staging/vme/devices/Kconfig".

Signed-off-by: Bruno Moreira-Guedes <codeagain@codeagain.dev>
---
 drivers/staging/vme/devices/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vme/devices/Kconfig b/drivers/staging/vme/devices/Kconfig
index 5651bb16b28b..e8b4461bf27f 100644
--- a/drivers/staging/vme/devices/Kconfig
+++ b/drivers/staging/vme/devices/Kconfig
@@ -3,7 +3,7 @@ comment "VME Device Drivers"
 
 config VME_USER
 	tristate "VME user space access driver"
-	depends on STAGING
+	depends on STAGING && VME_BUS
 	help
 	  If you say Y here you want to be able to access a limited number of
 	  VME windows in a manner at least semi-compatible with the interface
-- 
2.35.3


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/3] staging: vme: Add VME_BUS dependency to Kconfig

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Please, disregard the following message as there's a typo in the prefix.

On Mon, Apr 18, 2022 at 08:31:09PM -0300, Bruno Moreira-Guedes wrote:
> The KConfig file for VME_USER ('drivers/staging/vme/devices/Kconfig')
> sourced at "drivers/vme/boards/KConfig" misses a `depends on` line for
> VME_BUS, which is unnoticeable for menuconfig users who aren't be able
> to select it through this interface without setting the CONFIG_VME_BUS
> option because it's nested on VME_BUS menu entry.
...
>  	  VME windows in a manner at least semi-compatible with the interface
> -- 
> 2.35.3
> 

It's already sent a new copy with the proper version number. Nothing's
changed except for the message ID and the v2 typo.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/3] staging: vme: Add VME_BUS dependency to Kconfig

[Greg Kroah-Hartman]

On Mon, Apr 18, 2022 at 08:39:29PM -0300, Bruno Moreira-Guedes wrote:
> Please, disregard the following message as there's a typo in the prefix.
> 
> On Mon, Apr 18, 2022 at 08:31:09PM -0300, Bruno Moreira-Guedes wrote:
> > The KConfig file for VME_USER ('drivers/staging/vme/devices/Kconfig')
> > sourced at "drivers/vme/boards/KConfig" misses a `depends on` line for
> > VME_BUS, which is unnoticeable for menuconfig users who aren't be able
> > to select it through this interface without setting the CONFIG_VME_BUS
> > option because it's nested on VME_BUS menu entry.
> ...
> >  	  VME windows in a manner at least semi-compatible with the interface
> > -- 
> > 2.35.3
> > 
> 
> It's already sent a new copy with the proper version number. Nothing's
> changed except for the message ID and the v2 typo.

I can't handle 2 v2 of this same commit, our tools get very confused (as
do people.)  Would you be able to unwind this if you were in my
position?

Please resubmit a v3 of this series with everything fixed up.

thanks,

greg k-h

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Greg Kroah-Hartman]

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 <codeagain@codeagain.dev>

What about deleting the vme drivers entirely?

Martyn, anyone still using these?

thanks,

greg k-h

Re: [PATCH v2 2/3] staging: vme: Add VME_BUS dependency to Kconfig

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

On Wed, Apr 20, 2022 at 06:43:12PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 18, 2022 at 08:39:29PM -0300, Bruno Moreira-Guedes wrote:
> > Please, disregard the following message as there's a typo in the prefix.
> > 
> > On Mon, Apr 18, 2022 at 08:31:09PM -0300, Bruno Moreira-Guedes wrote:
> > > The KConfig file for VME_USER ('drivers/staging/vme/devices/Kconfig')
> > > sourced at "drivers/vme/boards/KConfig" misses a `depends on` line for
> > > VME_BUS, which is unnoticeable for menuconfig users who aren't be able
> > > to select it through this interface without setting the CONFIG_VME_BUS
> > > option because it's nested on VME_BUS menu entry.
> > ...
> > >  	  VME windows in a manner at least semi-compatible with the interface
> > > -- 
> > > 2.35.3
> > > 
> > 
> > It's already sent a new copy with the proper version number. Nothing's
> > changed except for the message ID and the v2 typo.
> 
> I can't handle 2 v2 of this same commit, our tools get very confused (as
> do people.)  Would you be able to unwind this if you were in my
> position?
I really apologize for this confusion, I really did some mistakes on my
local branch and had to edit the patches manually to reapply them. While
working on that I accidentally missed to change the 'v2' to 'v3'. My
mistake.

Though, there's no 2 v2s, the new one I sent is a v3 as is the rest of
this thread. So, would it be necessary to unwind anything anyway? 

If this question happens to beb a bad one, my apologies again, I'll soon
do some effort to learn more about how things work from a maintainer's
perspective so next time I make a mistake I'll be able to take the best
curse of action straight away.

> 
> Please resubmit a v3 of this series with everything fixed up.
Did you mean a v4 in this case? Or just post the same patch again?

> 
> thanks,
> 
> greg k-h

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Alison Schofield]

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 <codeagain@codeagain.dev>

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
> 

Re: [PATCH v2 2/3] staging: vme: Add VME_BUS dependency to Kconfig

[Greg Kroah-Hartman]

On Wed, Apr 20, 2022 at 06:12:58PM -0300, Bruno Moreira-Guedes wrote:
> On Wed, Apr 20, 2022 at 06:43:12PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Apr 18, 2022 at 08:39:29PM -0300, Bruno Moreira-Guedes wrote:
> > > Please, disregard the following message as there's a typo in the prefix.
> > > 
> > > On Mon, Apr 18, 2022 at 08:31:09PM -0300, Bruno Moreira-Guedes wrote:
> > > > The KConfig file for VME_USER ('drivers/staging/vme/devices/Kconfig')
> > > > sourced at "drivers/vme/boards/KConfig" misses a `depends on` line for
> > > > VME_BUS, which is unnoticeable for menuconfig users who aren't be able
> > > > to select it through this interface without setting the CONFIG_VME_BUS
> > > > option because it's nested on VME_BUS menu entry.
> > > ...
> > > >  	  VME windows in a manner at least semi-compatible with the interface
> > > > -- 
> > > > 2.35.3
> > > > 
> > > 
> > > It's already sent a new copy with the proper version number. Nothing's
> > > changed except for the message ID and the v2 typo.
> > 
> > I can't handle 2 v2 of this same commit, our tools get very confused (as
> > do people.)  Would you be able to unwind this if you were in my
> > position?
> I really apologize for this confusion, I really did some mistakes on my
> local branch and had to edit the patches manually to reapply them. While
> working on that I accidentally missed to change the 'v2' to 'v3'. My
> mistake.
> 
> Though, there's no 2 v2s, the new one I sent is a v3 as is the rest of
> this thread. So, would it be necessary to unwind anything anyway? 

Yes, as I don't see a v3 here.  All I see is a mess of commits in a
thread and not a way to easily determine which ones to, and not to,
apply/ignore.

Make it blindingly obvious for me (and everyone else) which is your
latest patch series and which to apply/review.

Remember, some of us get thousands of emails a day to deal with, and
right now I have over 2000 in my review queue to get through.  Making my
life simpler is the best thing if you want your patch to be accepted.

thanks,

greg k-h

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Martyn Welch]

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 <codeagain@codeagain.dev>
> 
> 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

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Greg Kroah-Hartman]

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 <codeagain@codeagain.dev>
> > 
> > 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

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

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 <codeagain@codeagain.dev>
> > > 
> > > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Greg Kroah-Hartman]

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 <codeagain@codeagain.dev>
> > > > 
> > > > 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

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Bruno Moreira-Guedes]

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

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 <codeagain@codeagain.dev>
> > > > > 
> > > > > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Greg Kroah-Hartman]

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 <codeagain@codeagain.dev>
> > > > > > 
> > > > > > 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

Re: [PATCH v3 0/3] staging: vme: Cleanup driver tree old structures

[Alison Schofield]

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 <codeagain@codeagain.dev>
> > > > > > > 
> > > > > > > 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
>