Char driver and Documentation fixes for 6.5-rc4

Here is a char driver fix and some documentation updates for 6.5-rc4
 that contain the following changes:
   - sram/genalloc bugfix for reported problem
   - security-bugs.rst update based on recent discussions
   - embargoed-hardware-issues minor cleanups and then partial revert for
     the project/company lists
 
 All of these have been in linux-next for a while with no reported
 problems, and the documentation updates have all been reviewed by the
 relevant developers.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 
 iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZMZD6A8cZ3JlZ0Brcm9h
 aC5jb20ACgkQMUfUDdst+ynxZACgksV7C7yJWTm9UfZNZ2ABUhj69aEAnR/X9tLr
 Sjtjo0iaoAZpE+2tjHt1
 =J/gW
 -----END PGP SIGNATURE-----

Merge tag 'char-misc-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

Pull char driver and Documentation fixes from Greg KH:
 "Here is a char driver fix and some documentation updates for 6.5-rc4
  that contain the following changes:

   - sram/genalloc bugfix for reported problem

   - security-bugs.rst update based on recent discussions

   - embargoed-hardware-issues minor cleanups and then partial revert
     for the project/company lists

  All of these have been in linux-next for a while with no reported
  problems, and the documentation updates have all been reviewed by the
  relevant developers"

* tag 'char-misc-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  misc/genalloc: Name subpools by of_node_full_name()
  Documentation: embargoed-hardware-issues.rst: add AMD to the list
  Documentation: embargoed-hardware-issues.rst: clean out empty and unused entries
  Documentation: security-bugs.rst: clarify CVE handling
  Documentation: security-bugs.rst: update preferences when dealing with the linux-distros group

Documentation/process/embargoed-hardware-issues.rst

@@ -254,7 +254,6 @@ an involved disclosed party. The current ambassadors list:
   Samsung	Javier González <javier.gonz@samsung.com>
 
   Microsoft	James Morris <jamorris@linux.microsoft.com>
-  VMware
   Xen		Andrew Cooper <andrew.cooper3@citrix.com>
 
   Canonical	John Johansen <john.johansen@canonical.com>
@@ -263,10 +262,8 @@ an involved disclosed party. The current ambassadors list:
   Red Hat	Josh Poimboeuf <jpoimboe@redhat.com>
   SUSE		Jiri Kosina <jkosina@suse.cz>
 
-  Amazon
   Google	Kees Cook <keescook@chromium.org>
 
-  GCC
   LLVM		Nick Desaulniers <ndesaulniers@google.com>
   ============= ========================================================
 

Documentation/process/security-bugs.rst

@@ -63,31 +63,28 @@ information submitted to the security list and any followup discussions
 of the report are treated confidentially even after the embargo has been
 lifted, in perpetuity.
 
-Coordination
-------------
+Coordination with other groups
+------------------------------
 
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed kernel upon public disclosure of the
-upstream fix. Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start. In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
+The kernel security team strongly recommends that reporters of potential
+security issues NEVER contact the "linux-distros" mailing list until
+AFTER discussing it with the kernel security team.  Do not Cc: both
+lists at once.  You may contact the linux-distros mailing list after a
+fix has been agreed on and you fully understand the requirements that
+doing so will impose on you and the kernel community.
+
+The different lists have different goals and the linux-distros rules do
+not contribute to actually fixing any potential security problems.
 
 CVE assignment
 --------------
 
-The security team does not normally assign CVEs, nor do we require them
-for reports or fixes, as this can needlessly complicate the process and
-may delay the bug handling. If a reporter wishes to have a CVE identifier
-assigned ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
+The security team does not assign CVEs, nor do we require them for
+reports or fixes, as this can needlessly complicate the process and may
+delay the bug handling.  If a reporter wishes to have a CVE identifier
+assigned, they should find one by themselves, for example by contacting
+MITRE directly.  However under no circumstances will a patch inclusion
+be delayed to wait for a CVE identifier to arrive.
 
 Non-disclosure agreements
 -------------------------

drivers/misc/sram.c

@@ -236,7 +236,7 @@ static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
 			}
 			if (!label)
 				block->label = devm_kasprintf(sram->dev, GFP_KERNEL,
-							      "%s", dev_name(sram->dev));
+							      "%s", of_node_full_name(child));
 			else
 				block->label = devm_kstrdup(sram->dev,
 							    label, GFP_KERNEL);

lib/genalloc.c

@@ -895,7 +895,7 @@ struct gen_pool *of_gen_pool_get(struct device_node *np,
 
 		of_property_read_string(np_pool, "label", &name);
 		if (!name)
-			name = np_pool->name;
+			name = of_node_full_name(np_pool);
 	}
 	if (pdev)
 		pool = gen_pool_get(&pdev->dev, name);