* Invitation: Justin Stitt's Intern Presentation @ Wed Aug 17, 2022 10am - 11am (PDT) (llvm@lists.linux.dev)
@ 2022-08-01 18:57 8% Nick Desaulniers
0 siblings, 0 replies; 200+ results
From: Nick Desaulniers @ 2022-08-01 18:57 UTC (permalink / raw)
To: llvm, gosst-kernel, android-llvm-dev, android-kernel-team,
kernel-dynamic-tools, natechancellor, Clang Built Linux
[-- Attachment #1.1: Type: text/plain, Size: 1909 bytes --]
Justin Stitt's Intern Presentation
Wednesday Aug 17, 2022 ⋅ 10am – 11am
Pacific Time - Los Angeles
Join with Google Meet
https://meet.google.com/wts-viup-bbu?hs=224
Join by phone
(US) +1 253-289-6982
PIN: 52630526169
More phone numbers
https://tel.meet/wts-viup-bbu?pin=4782004268358&hs=0
Join us for Justin's Intern presentation about work he did over the summer
regarding getting -Wformat enabled in the Linux kernel for Clang, and
profiling/performance work on building the Linux kernel faster with Clang.
Organizer
Nick Desaulniers
ndesaulniers@google.com
Guests
Nick Desaulniers - organizer
gosst-kernel
android-llvm-dev
android-kernel-team
kernel-dynamic-tools
natechancellor@gmail.com
Clang Built Linux
llvm@lists.linux.dev
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NGVoYWEyOWkxanEwYjU1cnQzNnJsNm5sOGggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb204ZjQwMzA4ZDgzMWNkMjM4MzBjMzRjNDg0YmIxOWQ0YzRkMmRlMmMx&ctz=America%2FLos_Angeles&hl=en&es=0
Reply for llvm@lists.linux.dev and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NGVoYWEyOWkxanEwYjU1cnQzNnJsNm5sOGggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb204ZjQwMzA4ZDgzMWNkMjM4MzBjMzRjNDg0YmIxOWQ0YzRkMmRlMmMx&ctz=America%2FLos_Angeles&hl=en&es=0
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
[-- Attachment #1.2: Type: text/html, Size: 31843 bytes --]
[-- Attachment #1.3: Type: text/calendar, Size: 2759 bytes --]
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220817T170000Z
DTEND:20220817T180000Z
DTSTAMP:20220801T185717Z
ORGANIZER;CN=Nick Desaulniers:mailto:ndesaulniers@google.com
UID:4ehaa29i1jq0b55rt36rl6nl8h@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=gosst-kernel;X-NUM-GUESTS=0:mailto:gosst-kernel@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Nick Desaulniers;X-NUM-GUESTS=0:mailto:ndesaulniers@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=android-llvm-dev;X-NUM-GUESTS=0:mailto:android-llvm-dev@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=android-kernel-team;X-NUM-GUESTS=0:mailto:android-kernel-team@googl
e.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=kernel-dynamic-tools;X-NUM-GUESTS=0:mailto:kernel-dynamic-tools@goo
gle.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=natechancellor@gmail.com;X-NUM-GUESTS=0:mailto:natechancellor@gmail
.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Clang Built Linux;X-NUM-GUESTS=0:mailto:clang-built-linux@googlegro
ups.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=llvm@lists.linux.dev;X-NUM-GUESTS=0:mailto:llvm@lists.linux.dev
X-GOOGLE-CONFERENCE:https://meet.google.com/wts-viup-bbu
X-MICROSOFT-CDO-OWNERAPPTID:-796859524
CREATED:20220801T185710Z
DESCRIPTION:Join us for Justin's Intern presentation about work he did over
the summer regarding getting -Wformat enabled in the Linux kernel for Clan
g\, and profiling/performance work on building the Linux kernel faster with
Clang.\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the description.\n\nTh
is event has a video call.\nJoin: https://meet.google.com/wts-viup-bbu\n(US
) +1 253-289-6982 PIN: 52630526169#\nView more phone numbers: https://tel.m
eet/wts-viup-bbu?pin=4782004268358&hs=7\n\nView your event at https://calen
dar.google.com/calendar/event?action=VIEW&eid=NGVoYWEyOWkxanEwYjU1cnQzNnJsN
m5sOGggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb204
ZjQwMzA4ZDgzMWNkMjM4MzBjMzRjNDg0YmIxOWQ0YzRkMmRlMmMx&ctz=America%2FLos_Ange
les&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220801T185714Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Justin Stitt's Intern Presentation
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
[-- Attachment #2: invite.ics --]
[-- Type: application/ics, Size: 2814 bytes --]
^ permalink raw reply [relevance 8%]
* [PATCH] MAINTAINERS: Add new IOMMU development mailing list
@ 2022-06-22 8:26 8% Joerg Roedel
0 siblings, 0 replies; 200+ results
From: Joerg Roedel @ 2022-06-22 8:26 UTC (permalink / raw)
To: linux-kernel; +Cc: iommu, Joerg Roedel, iommu
From: Joerg Roedel <jroedel@suse.de>
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fc9ead83d2a..b5bac297d63d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10354,6 +10354,7 @@ IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: Documentation/devicetree/bindings/iommu/
--
2.36.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [relevance 8%]
* Invitation: CBL meetup @ Sat Nov 11, 2023 5am - 2pm (PST) (llvm@lists.linux.dev)
@ 2023-06-23 21:01 8% Nick Desaulniers
0 siblings, 0 replies; 200+ results
From: Nick Desaulniers @ 2023-06-23 21:01 UTC (permalink / raw)
To: llvm, Kees Cook, Bill Wendling
[-- Attachment #1.1: Type: text/plain, Size: 1733 bytes --]
CBL meetup
Saturday Nov 11, 2023 ⋅ 5am – 2pm
Pacific Time - Los Angeles
Location
Omni Richmond Hotel, 100 S 12th St, Richmond, VA 23219, USA
https://www.google.com/maps/search/Omni+Richmond+Hotel,+100+S+12th+St,+Richmond,+VA+23219,+USA?hl=en
Join with Google Meet
https://meet.google.com/wnq-aaos-xdv?hs=224
Join by phone
(US) +1 509-676-2572
PIN: 449543701
More phone numbers
https://tel.meet/wnq-aaos-xdv?pin=3190412394780&hs=0
Organizer
Nick Desaulniers
ndesaulniers@google.com
Guests
Nick Desaulniers - organizer
Kees Cook
llvm@lists.linux.dev
Bill Wendling
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=N2xoN2F1YWNlZHU0Y2p0cjRjY3U2ajZpamcgbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb21lN2IwZWRhNDYyMTYzMTVjOGI5YzM5MmM3YTViOWJjNDk2OGJiZjQ2&ctz=America%2FLos_Angeles&hl=en&es=0
Reply for llvm@lists.linux.dev and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=N2xoN2F1YWNlZHU0Y2p0cjRjY3U2ajZpamcgbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb21lN2IwZWRhNDYyMTYzMTVjOGI5YzM5MmM3YTViOWJjNDk2OGJiZjQ2&ctz=America%2FLos_Angeles&hl=en&es=0
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
[-- Attachment #1.2: Type: text/html, Size: 32646 bytes --]
[-- Attachment #1.3: Type: text/calendar, Size: 2264 bytes --]
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/New_York:20231111T080000
DTEND;TZID=America/New_York:20231111T170000
DTSTAMP:20230623T210110Z
ORGANIZER;CN=Nick Desaulniers:mailto:ndesaulniers@google.com
UID:7lh7auacedu4cjtr4ccu6j6ijg@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Kees Cook;X-NUM-GUESTS=0:mailto:keescook@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=llvm@lists.linux.dev;X-NUM-GUESTS=0:mailto:llvm@lists.linux.dev
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Bill Wendling;X-NUM-GUESTS=0:mailto:morbo@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Nick Desaulniers;X-NUM-GUESTS=0:mailto:ndesaulniers@google.com
X-GOOGLE-CONFERENCE:https://meet.google.com/wnq-aaos-xdv
X-MICROSOFT-CDO-OWNERAPPTID:1743767684
CREATED:20230501T203621Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
:~:~:~:~:~:~:~:~::~:~::-\nJoin with Google Meet: https://meet.google.com/wn
q-aaos-xdv\nOr dial: (US) +1 509-676-2572 PIN: 449543701#\nMore phone numbe
rs: https://tel.meet/wnq-aaos-xdv?pin=3190412394780&hs=7\n\nLearn more abou
t Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease do n
ot edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20230623T210109Z
LOCATION:Omni Richmond Hotel\, 100 S 12th St\, Richmond\, VA 23219\, USA
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:CBL meetup
TRANSP:TRANSPARENT
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P1D
END:VALARM
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P7D
END:VALARM
END:VEVENT
END:VCALENDAR
[-- Attachment #2: invite.ics --]
[-- Type: application/ics, Size: 2329 bytes --]
^ permalink raw reply [relevance 8%]
* [PATCH 2/2] netfs: Add Jeff Layton as reviewer
@ 2024-01-22 11:50 8% ` David Howells
2024-01-22 11:50 8% ` David Howells
1 sibling, 0 replies; 200+ results
From: David Howells @ 2024-01-22 11:50 UTC (permalink / raw)
To: netfs
Cc: David Howells, Christian Brauner, Jeff Layton, Matthew Wilcox,
linux-cachefs, linux-afs, linux-cifs, linux-nfs, ceph-devel, v9fs,
linux-erofs, linux-fsdevel, linux-mm, linux-kernel
Add Jeff Layton as a reviewer in the MAINTAINERS file.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Jeff Layton <jlayton@kernel.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ab5858d24ffc..2f4f4bf2e7f8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8223,6 +8223,7 @@ F: include/linux/iomap.h
FILESYSTEMS [NETFS LIBRARY]
M: David Howells <dhowells@redhat.com>
+R: Jeff Layton <jlayton@kernel.org>
L: netfs@lists.linux.dev
L: linux-fsdevel@vger.kernel.org
S: Supported
^ permalink raw reply related [relevance 8%]
* [PATCH 2/2] netfs: Add Jeff Layton as reviewer
@ 2024-01-22 11:50 8% ` David Howells
0 siblings, 0 replies; 200+ results
From: David Howells @ 2024-01-22 11:50 UTC (permalink / raw)
To: netfs
Cc: linux-cifs, linux-nfs, v9fs, Jeff Layton, linux-kernel,
Matthew Wilcox, David Howells, linux-mm, linux-cachefs,
linux-fsdevel, ceph-devel, linux-erofs, linux-afs,
Christian Brauner
Add Jeff Layton as a reviewer in the MAINTAINERS file.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Jeff Layton <jlayton@kernel.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ab5858d24ffc..2f4f4bf2e7f8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8223,6 +8223,7 @@ F: include/linux/iomap.h
FILESYSTEMS [NETFS LIBRARY]
M: David Howells <dhowells@redhat.com>
+R: Jeff Layton <jlayton@kernel.org>
L: netfs@lists.linux.dev
L: linux-fsdevel@vger.kernel.org
S: Supported
^ permalink raw reply related [relevance 8%]
* [merged mm-stable] documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch removed from -mm tree
@ 2024-02-22 0:01 8% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-02-22 0:01 UTC (permalink / raw)
To: mm-commits, ying.huang, willy, osalvador, mhocko, lizhijian,
Jonathan.Cameron, gregkh, david, dave.jiang, dave.hansen,
dan.j.williams, vishal.l.verma, akpm
The quilt patch titled
Subject: Documentatiion/ABI: add ABI documentation for sys-bus-dax
has been removed from the -mm tree. Its filename was
documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Vishal Verma <vishal.l.verma@intel.com>
Subject: Documentatiion/ABI: add ABI documentation for sys-bus-dax
Date: Wed, 24 Jan 2024 12:03:48 -0800
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Link: https://lkml.kernel.org/r/20240124-vv-dax_abi-v7-3-20d16cb8d23d@intel.com
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Li Zhijian <lizhijian@fujitsu.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/testing/sysfs-bus-dax | 136 ++++++++++++++++++++++
1 file changed, 136 insertions(+)
--- /dev/null
+++ a/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,136 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range. The 'end' attribute
+ indicates the end physical address for the given range. The
+ 'page_offset' attribute indicates the offset of the current
+ range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
_
Patches currently in -mm which might be from vishal.l.verma@intel.com are
^ permalink raw reply [relevance 8%]
* [PATCH v7 3/5] Documentatiion/ABI: Add ABI documentation for sys-bus-dax
2024-01-24 20:03 10% ` [PATCH v7 5/5] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
@ 2024-01-24 20:03 9% ` Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2024-01-24 20:03 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang, Andrew Morton,
Oscar Salvador
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Greg Kroah-Hartman, Matthew Wilcox, linux-mm
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
Documentation/ABI/testing/sysfs-bus-dax | 136 ++++++++++++++++++++++++++++++++
1 file changed, 136 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
new file mode 100644
index 000000000000..6359f7bc9bf4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,136 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range. The 'end' attribute
+ indicates the end physical address for the given range. The
+ 'page_offset' attribute indicates the offset of the current
+ range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
--
2.43.0
^ permalink raw reply related [relevance 9%]
* [PATCH v6 1/4] Documentatiion/ABI: Add ABI documentation for sys-bus-dax
2023-12-15 5:25 10% ` [PATCH v6 4/4] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
@ 2023-12-15 5:25 9% ` Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-15 5:25 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang, Andrew Morton,
Oscar Salvador
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Greg Kroah-Hartman, linux-mm
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
Documentation/ABI/testing/sysfs-bus-dax | 136 ++++++++++++++++++++++++++++++++
1 file changed, 136 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
new file mode 100644
index 000000000000..6359f7bc9bf4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,136 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range. The 'end' attribute
+ indicates the end physical address for the given range. The
+ 'page_offset' attribute indicates the offset of the current
+ range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
--
2.41.0
^ permalink raw reply related [relevance 9%]
* [PATCH v5 1/4] Documentatiion/ABI: Add ABI documentation for sys-bus-dax
2023-12-14 7:37 10% ` [PATCH v5 4/4] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
@ 2023-12-14 7:37 9% ` Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-14 7:37 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang, Andrew Morton,
Oscar Salvador
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Greg Kroah-Hartman, linux-mm
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
Documentation/ABI/testing/sysfs-bus-dax | 136 ++++++++++++++++++++++++++++++++
1 file changed, 136 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
new file mode 100644
index 000000000000..6359f7bc9bf4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,136 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range. The 'end' attribute
+ indicates the end physical address for the given range. The
+ 'page_offset' attribute indicates the offset of the current
+ range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
--
2.41.0
^ permalink raw reply related [relevance 9%]
* + docs-update-ocfs2-devel-mailing-list-address.patch added to mm-hotfixes-unstable branch
@ 2023-07-02 17:36 9% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-07-02 17:36 UTC (permalink / raw)
To: mm-commits, piaojun, mark, junxiao.bi, jlbec, jiangqi903, ghe,
gechangwei, ailiop, akpm
The patch titled
Subject: docs: update ocfs2-devel mailing list address
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
docs-update-ocfs2-devel-mailing-list-address.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/docs-update-ocfs2-devel-mailing-list-address.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Anthony Iliopoulos <ailiop@suse.com>
Subject: docs: update ocfs2-devel mailing list address
Date: Wed, 28 Jun 2023 03:34:37 +0200
The ocfs2-devel mailing list has been migrated to the kernel.org
infrastructure, update all related documentation pointers to reflect the
change.
Link: https://lkml.kernel.org/r/20230628013437.47030-3-ailiop@suse.com
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Joseph Qi <jiangqi903@gmail.com>
Cc: Jun Piao <piaojun@huawei.com>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Mark Fasheh <mark@fasheh.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/obsolete/o2cb | 4 ++--
Documentation/ABI/removed/o2cb | 4 ++--
Documentation/ABI/stable/o2cb | 4 ++--
Documentation/ABI/testing/sysfs-ocfs2 | 12 ++++++------
Documentation/filesystems/dlmfs.rst | 2 +-
Documentation/filesystems/ocfs2.rst | 2 +-
fs/ocfs2/Kconfig | 6 +++---
7 files changed, 17 insertions(+), 17 deletions(-)
--- a/Documentation/ABI/obsolete/o2cb~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/obsolete/o2cb
@@ -1,11 +1,11 @@
What: /sys/o2cb
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Was renamed to /sys/fs/u2cb/
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
--- a/Documentation/ABI/removed/o2cb~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/removed/o2cb
@@ -1,10 +1,10 @@
What: /sys/o2cb symlink
Date: May 2011
KernelVersion: 3.0
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
removed when new versions of ocfs2-tools which know to look
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
software to look here, it should try /sys/fs/o2cb instead.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
--- a/Documentation/ABI/stable/o2cb~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/stable/o2cb
@@ -1,10 +1,10 @@
What: /sys/fs/o2cb/
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
--- a/Documentation/ABI/testing/sysfs-ocfs2~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/testing/sysfs-ocfs2
@@ -1,13 +1,13 @@
What: /sys/fs/ocfs2/
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2 directory contains knobs used by the
ocfs2-tools to interact with the filesystem.
What: /sys/fs/ocfs2/max_locking_protocol
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/max_locking_protocol file displays version
of ocfs2 locking supported by the filesystem. This version
@@ -28,7 +28,7 @@ Description:
What: /sys/fs/ocfs2/loaded_cluster_plugins
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/loaded_cluster_plugins file describes
the available plugins to support ocfs2 cluster operation.
@@ -48,7 +48,7 @@ Description:
What: /sys/fs/ocfs2/active_cluster_plugin
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/active_cluster_plugin displays which
cluster plugin is currently in use by the filesystem.
@@ -65,7 +65,7 @@ Description:
What: /sys/fs/ocfs2/cluster_stack
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/cluster_stack file contains the name
of current ocfs2 cluster stack. This value is set by
@@ -86,4 +86,4 @@ Description:
stack return an error.
Users:
- ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
+ ocfs2-tools <ocfs2-tools-devel@lists.linux.dev>
--- a/Documentation/filesystems/dlmfs.rst~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/filesystems/dlmfs.rst
@@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires
:Project web page: http://ocfs2.wiki.kernel.org
:Tools web page: https://github.com/markfasheh/ocfs2-tools
-:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+:OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
--- a/Documentation/filesystems/ocfs2.rst~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/filesystems/ocfs2.rst
@@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl".
Project web page: http://ocfs2.wiki.kernel.org
Tools git tree: https://github.com/markfasheh/ocfs2-tools
-OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
--- a/fs/ocfs2/Kconfig~docs-update-ocfs2-devel-mailing-list-address
+++ a/fs/ocfs2/Kconfig
@@ -17,9 +17,9 @@ config OCFS2_FS
You'll want to install the ocfs2-tools package in order to at least
get "mount.ocfs2".
- Project web page: https://oss.oracle.com/projects/ocfs2
- Tools web page: https://oss.oracle.com/projects/ocfs2-tools
- OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+ Project web page: https://ocfs2.wiki.kernel.org/
+ Tools web page: https://github.com/markfasheh/ocfs2-tools
+ OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
For more information on OCFS2, see the file
<file:Documentation/filesystems/ocfs2.rst>.
_
Patches currently in -mm which might be from ailiop@suse.com are
maintainers-update-ocfs2-devel-mailing-list-address.patch
docs-update-ocfs2-devel-mailing-list-address.patch
^ permalink raw reply [relevance 9%]
* [merged mm-hotfixes-stable] docs-update-ocfs2-devel-mailing-list-address.patch removed from -mm tree
@ 2023-07-09 0:30 9% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-07-09 0:30 UTC (permalink / raw)
To: mm-commits, piaojun, mark, junxiao.bi, jlbec, jiangqi903, ghe,
gechangwei, ailiop, akpm
The quilt patch titled
Subject: docs: update ocfs2-devel mailing list address
has been removed from the -mm tree. Its filename was
docs-update-ocfs2-devel-mailing-list-address.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Anthony Iliopoulos <ailiop@suse.com>
Subject: docs: update ocfs2-devel mailing list address
Date: Wed, 28 Jun 2023 03:34:37 +0200
The ocfs2-devel mailing list has been migrated to the kernel.org
infrastructure, update all related documentation pointers to reflect the
change.
Link: https://lkml.kernel.org/r/20230628013437.47030-3-ailiop@suse.com
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Acked-by: Joseph Qi <jiangqi903@gmail.com>
Acked-by: Joel Becker <jlbec@evilplan.org>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Mark Fasheh <mark@fasheh.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/obsolete/o2cb | 4 ++--
Documentation/ABI/removed/o2cb | 4 ++--
Documentation/ABI/stable/o2cb | 4 ++--
Documentation/ABI/testing/sysfs-ocfs2 | 12 ++++++------
Documentation/filesystems/dlmfs.rst | 2 +-
Documentation/filesystems/ocfs2.rst | 2 +-
fs/ocfs2/Kconfig | 6 +++---
7 files changed, 17 insertions(+), 17 deletions(-)
--- a/Documentation/ABI/obsolete/o2cb~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/obsolete/o2cb
@@ -1,11 +1,11 @@
What: /sys/o2cb
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Was renamed to /sys/fs/u2cb/
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
--- a/Documentation/ABI/removed/o2cb~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/removed/o2cb
@@ -1,10 +1,10 @@
What: /sys/o2cb symlink
Date: May 2011
KernelVersion: 3.0
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
removed when new versions of ocfs2-tools which know to look
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
software to look here, it should try /sys/fs/o2cb instead.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
--- a/Documentation/ABI/stable/o2cb~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/stable/o2cb
@@ -1,10 +1,10 @@
What: /sys/fs/o2cb/
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
--- a/Documentation/ABI/testing/sysfs-ocfs2~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/ABI/testing/sysfs-ocfs2
@@ -1,13 +1,13 @@
What: /sys/fs/ocfs2/
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2 directory contains knobs used by the
ocfs2-tools to interact with the filesystem.
What: /sys/fs/ocfs2/max_locking_protocol
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/max_locking_protocol file displays version
of ocfs2 locking supported by the filesystem. This version
@@ -28,7 +28,7 @@ Description:
What: /sys/fs/ocfs2/loaded_cluster_plugins
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/loaded_cluster_plugins file describes
the available plugins to support ocfs2 cluster operation.
@@ -48,7 +48,7 @@ Description:
What: /sys/fs/ocfs2/active_cluster_plugin
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/active_cluster_plugin displays which
cluster plugin is currently in use by the filesystem.
@@ -65,7 +65,7 @@ Description:
What: /sys/fs/ocfs2/cluster_stack
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/cluster_stack file contains the name
of current ocfs2 cluster stack. This value is set by
@@ -86,4 +86,4 @@ Description:
stack return an error.
Users:
- ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
+ ocfs2-tools <ocfs2-tools-devel@lists.linux.dev>
--- a/Documentation/filesystems/dlmfs.rst~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/filesystems/dlmfs.rst
@@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires
:Project web page: http://ocfs2.wiki.kernel.org
:Tools web page: https://github.com/markfasheh/ocfs2-tools
-:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+:OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
--- a/Documentation/filesystems/ocfs2.rst~docs-update-ocfs2-devel-mailing-list-address
+++ a/Documentation/filesystems/ocfs2.rst
@@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl".
Project web page: http://ocfs2.wiki.kernel.org
Tools git tree: https://github.com/markfasheh/ocfs2-tools
-OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
--- a/fs/ocfs2/Kconfig~docs-update-ocfs2-devel-mailing-list-address
+++ a/fs/ocfs2/Kconfig
@@ -17,9 +17,9 @@ config OCFS2_FS
You'll want to install the ocfs2-tools package in order to at least
get "mount.ocfs2".
- Project web page: https://oss.oracle.com/projects/ocfs2
- Tools web page: https://oss.oracle.com/projects/ocfs2-tools
- OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+ Project web page: https://ocfs2.wiki.kernel.org/
+ Tools web page: https://github.com/markfasheh/ocfs2-tools
+ OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
For more information on OCFS2, see the file
<file:Documentation/filesystems/ocfs2.rst>.
_
Patches currently in -mm which might be from ailiop@suse.com are
^ permalink raw reply [relevance 9%]
* [PATCH v3 1/2] Documentatiion/ABI: Add ABI documentation for sys-bus-dax
2023-12-11 22:52 10% ` [PATCH v3 2/2] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
@ 2023-12-11 22:52 9% ` Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-11 22:52 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
Documentation/ABI/testing/sysfs-bus-dax | 151 ++++++++++++++++++++++++++++++++
1 file changed, 151 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
new file mode 100644
index 000000000000..a61a7b186017
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,151 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'end' attribute indicates the
+ end physical address for the given range.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'page_offset' attribute indicates the
+ offset of the current range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
--
2.41.0
^ permalink raw reply related [relevance 9%]
* [PATCH v4 1/3] Documentatiion/ABI: Add ABI documentation for sys-bus-dax
2023-12-12 19:08 10% ` [PATCH v4 3/3] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
@ 2023-12-12 19:08 9% ` Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-12 19:08 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
Documentation/ABI/testing/sysfs-bus-dax | 151 ++++++++++++++++++++++++++++++++
1 file changed, 151 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
new file mode 100644
index 000000000000..a61a7b186017
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,151 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'end' attribute indicates the
+ end physical address for the given range.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'page_offset' attribute indicates the
+ offset of the current range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
--
2.41.0
^ permalink raw reply related [relevance 9%]
* Re: Create mm@lists.linux.dev
@ 2021-06-15 11:19 9% ` Christoph Lameter
0 siblings, 0 replies; 200+ results
From: Christoph Lameter @ 2021-06-15 11:19 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Johannes Weiner, Matthew Wilcox, helpdesk, Andrew Morton,
Naoya Horiguchi, Michal Hocko, Vladimir Davydov,
Jérôme Glisse, Mike Kravetz, Mike Rapoport, Will Deacon,
Aneesh Kumar K.V, Nick Piggin, Peter Zijlstra, Dennis Zhou,
Tejun Heo, David Rientjes, Vlastimil Babka, Hugh Dickins,
linux-mm
On Mon, 14 Jun 2021, Jason Gunthorpe wrote:
> linux-mm emails are often in my spam folder because it mangles
> DKIM. Other lists don't have this problem
>
> Jason
Also have experience with unreliable email delivery here.
So is mm@lists.linux.dev active now? How does one switch over?
^ permalink raw reply [relevance 9%]
* Re: [PATCH] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list
2022-01-26 22:22 15% [PATCH] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list Benson Leung
@ 2022-01-27 16:44 9% ` Benson Leung
0 siblings, 0 replies; 200+ results
From: Benson Leung @ 2022-01-27 16:44 UTC (permalink / raw)
To: Benson Leung, chrome-platform; +Cc: bleung, pmalani, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Wed, 26 Jan 2022 14:22:33 -0800, Benson Leung wrote:
>
Applied to for-next.
[1/1] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list
commit: 664de6a26b7f17eebca896c3e18201b15d5c7b19
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [relevance 9%]
* Welcome to ntb@lists.linux.dev
@ 2022-02-02 21:10 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2022-02-02 21:10 UTC (permalink / raw)
To: ntb
Hello, all:
You are receiving this message because you've been automatically subscribed to
the new NTB list, hosted at ntb@lists.linux.dev. This is a test message to
ensure that the archive is properly working. You should receive further
messages about the list migration from project administrators.
Best regards,
Konstantin
^ permalink raw reply [relevance 9%]
* KernelCI at lists.linux.dev
@ 2022-07-14 8:26 9% Guillaume Tucker
2022-07-14 14:51 9% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Guillaume Tucker @ 2022-07-14 8:26 UTC (permalink / raw)
To: helpdesk; +Cc: kernelci@groups.io
Hello,
The KernelCI community has been using kernelci@groups.io for a
few years, however it's less than ideal as messages have to be
moderated for all non-members. Also we've been getting closer to
the kernel community over the years and it isn't a great fit for
that. Would it be possible to create a kernelci@lists.linux.dev
mailing list so we would then transition away from groups.io?
Discussions on this list include general topics related to
KernelCI itself and some development topics, as well as kernel
issues reported by KernelCI such as follow-ups from bisection
reports. We don't really use the list as part of the KernelCI
core development workflow since that's all done on GitHub. So
it's really our main channel for communicating with the kernel
community.
Best wishes,
Guillaume
^ permalink raw reply [relevance 9%]
* Re: KernelCI at lists.linux.dev
2022-07-14 8:26 9% KernelCI at lists.linux.dev Guillaume Tucker
@ 2022-07-14 14:51 9% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2022-07-14 14:51 UTC (permalink / raw)
To: Guillaume Tucker; +Cc: helpdesk, kernelci@groups.io
On Thu, Jul 14, 2022 at 10:26:57AM +0200, Guillaume Tucker wrote:
> Hello,
>
> The KernelCI community has been using kernelci@groups.io for a
> few years, however it's less than ideal as messages have to be
> moderated for all non-members. Also we've been getting closer to
> the kernel community over the years and it isn't a great fit for
> that. Would it be possible to create a kernelci@lists.linux.dev
> mailing list so we would then transition away from groups.io?
For sure, I don't see why not. We can even import groups.io archives once the
migration is decided. If you do decide to move, just follow the procedure
described on
https://subspace.kernel.org/lists.linux.dev.html#requesting-list-hosting
Best regards,
Konstantin
^ permalink raw reply [relevance 9%]
* mptcp@lists.linux.dev
@ 2022-11-05 8:10 9% FedoraForum.org
0 siblings, 0 replies; 200+ results
From: FedoraForum.org @ 2022-11-05 8:10 UTC (permalink / raw)
To: mptcp
📠Have you ever tried this sex game before? GIVE IT A TRY: https://sklbx.com/ny3g0ufO?mkjo ðŸ“,
This is a message from Unregistered ( mailto: ) from the FedoraForum.org ( https://forums.fedoraforum.org/ ).
The message is as follows:
mptcp@lists.linux.dev
FedoraForum.org takes no responsibility for messages sent through its system.
^ permalink raw reply [relevance 9%]
* Re: dm-devel has migrated to lists.linux.dev
2023-10-06 23:29 10% dm-devel has migrated to lists.linux.dev Mike Snitzer
@ 2023-10-06 23:43 9% ` Mike Snitzer
2023-10-11 18:41 9% ` Mike Snitzer
2023-10-11 14:35 9% ` Mike Snitzer
0 siblings, 2 replies; 200+ results
From: Mike Snitzer @ 2023-10-06 23:43 UTC (permalink / raw)
To: dm-devel
On Fri, Oct 06 2023 at 7:29P -0400,
Mike Snitzer <snitzer@kernel.org> wrote:
> Hi,
>
> As a dm-devel@redhat.com subscriber, you have been silently subscribed
> to the new mailing list: dm-devel@lists.linux.dev.
>
> Effective immediately, all dm-devel email should be addressed to:
> dm-devel@lists.linux.dev
>
> (I say this but my "git pull" request that I just sent to Linus, to
> update the MAINTAINERS file accordingly, cc'd dm-devel@redhat.com --
> dm-devel@redhat.com will still function as it has, but nobody should
> use it moving forward).
>
> If you do send email to dm-devel@redhat.com you will get this
> auto-response:
>
> As of 2023.10.06: dm-devel@redhat.com has migrated to
> dm-devel@lists.linux.dev
>
> If you were a dm-devel@redhat.com subscriber you have been silently
> subscribed to dm-devel@lists.linux.dev
>
> NOTE: If you were a dm-devel@redhat.com subscriber but you disabled
> mail delivery: then you must subscribe to dm-devel@lists.linux.dev.
> To do so please send email to: dm-devel+subscribe@lists.linux.dev
>
> To unsubscribe from dm-devel@lists.linux.dev please send email to:
> dm-devel+unsubscribe@lists.linux.dev
Additional useful info:
Please be sure to update any dm-devel mail filter you may have to look
for this in mail headers:
List-Id: <dm-devel.lists.linux.dev>
Also, we will be backfilling "[dm-devel]" prefix for all list messages.
The dm-devel list archive is now here:
https://lore.kernel.org/dm-devel/
Please let me know if you have any questions or concerns.
Thanks,
Mike
^ permalink raw reply [relevance 9%]
* Re: PSA: the bridge list will be moving to lists.linux.dev
2023-11-01 20:10 9% [Bridge] PSA: the bridge list will be moving to lists.linux.dev Konstantin Ryabitsev
@ 2023-11-07 19:38 9% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-07 19:38 UTC (permalink / raw)
To: bridge
On Wed, 1 Nov 2023 at 16:10, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linux-foundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> *On November 7*, The bridge list will be migrated to live on lists.linux.dev,
> but the impact of this move should be minor:
Hi, all:
This work is complete -- the new list address is
bridge@lists.linux.dev, but the old address will continue to work for
the foreseeable future.
As a reminder, below is the impact of this migration:
> 1. The new canonical list address will be bridge@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/bridge/ with all prior
> archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <bridge.lists.linux-foundation.org>
> after: List-Id: <bridge.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after November 7).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [bridge] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
The list is now archived on https://lore.kernel.org/bridge/.
If something isn't working or looking right, please reach out to
helpdesk@kernel.org.
-K
^ permalink raw reply [relevance 9%]
* Re: PSA: the acpica-devel list is migrating to lists.linux.dev
2023-11-01 21:26 9% [Acpica-devel] PSA: the acpica-devel list is migrating to lists.linux.dev Konstantin Ryabitsev
@ 2023-11-07 19:41 9% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-07 19:41 UTC (permalink / raw)
To: acpica-devel
On Wed, 1 Nov 2023 at 17:26, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> The mailman-2 system running on lists.linuxfoundation.org is being
> decommissioned, so all lists currently hosted there will be found new homes.
> *On November 7*, The acpica-devel list will be migrated to live on
> lists.linux.dev, but the impact of this move should be minor:
Hello, all:
This work is complete and the list is now migrated to
acpica-devel@lists.linux.dev. The old address will continue to work
for the foreseeable future, so any existing conversations can be
continued without making any changes.
As a reminder, below is the impact of this move:
> 1. The new canonical list address will be acpica-devel@lists.linux.dev.
>
> 2. *The old address will continue to work* for the foreseeable future, so any
> existing conversations can continue and any new messages sent to the old
> list address will be properly delivered to all subscribers.
>
> 3. All members will be automatically subscribed to the new list, so no action
> is required on anyone's part to keep receiving list mail.
>
> 4. The list will be archived on https://lore.kernel.org/acpica-devel/ with all
> prior archives automatically imported.
>
> 5. The List-ID header will change, regardless to which address the message is
> sent:
>
> before: List-Id: <acpica-devel.lists.linuxfoundation.org>
> after: List-Id: <acpica-devel.lists.linux.dev>
>
> You will need to update your filtering rules if you filter based on the
> contents of that header (on or after November 7).
>
> 6. The mailman footer will no longer be added to message bodies and the
> subject will no longer be modified to insert [acpica-devel] (because this
> violates DMARC).
>
> 7. Subscribing and unsubscribing will be done using the mlmmj supported
> commands, documented at https://subspace.kernel.org/subscribing.html
The list is now archived on https://lore.kernel.org/acpica-devel/.
If something isn't working or looking right, please reach out to
helpdesk@kernel.org.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* + maintainers-update-clangbuiltlinux-mailing-list.patch added to -mm tree
@ 2021-08-31 22:48 9% akpm
0 siblings, 0 replies; 200+ results
From: akpm @ 2021-08-31 22:48 UTC (permalink / raw)
To: keescook, masahiroy, mm-commits, nathan, ndesaulniers,
samitolvanen
The patch titled
Subject: MAINTAINERS: update ClangBuiltLinux mailing list
has been added to the -mm tree. Its filename is
maintainers-update-clangbuiltlinux-mailing-list.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/maintainers-update-clangbuiltlinux-mailing-list.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/maintainers-update-clangbuiltlinux-mailing-list.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Nathan Chancellor <nathan@kernel.org>
Subject: MAINTAINERS: update ClangBuiltLinux mailing list
We are now at llvm@lists.linux.dev.
Link: https://lkml.kernel.org/r/20210825211823.6406-1-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/MAINTAINERS~maintainers-update-clangbuiltlinux-mailing-list
+++ a/MAINTAINERS
@@ -4504,7 +4504,7 @@ F: .clang-format
CLANG/LLVM BUILD SUPPORT
M: Nathan Chancellor <nathan@kernel.org>
M: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
W: https://clangbuiltlinux.github.io/
B: https://github.com/ClangBuiltLinux/linux/issues
@@ -4519,7 +4519,7 @@ M: Sami Tolvanen <samitolvanen@google.co
M: Kees Cook <keescook@chromium.org>
R: Nathan Chancellor <nathan@kernel.org>
R: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
B: https://github.com/ClangBuiltLinux/linux/issues
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
_
Patches currently in -mm which might be from nathan@kernel.org are
mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix-fix.patch
maintainers-update-clangbuiltlinux-mailing-list.patch
documentation-llvm-update-mailing-list.patch
documentation-llvm-update-irc-location.patch
^ permalink raw reply [relevance 9%]
* [PATCH v2 1/2] Documentatiion/ABI: Add ABI documentation for sys-bus-dax
2023-12-07 4:36 11% ` [PATCH v2 2/2] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
@ 2023-12-07 4:36 9% ` Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-07 4:36 UTC (permalink / raw)
To: Dave Jiang; +Cc: Dan Williams, linux-kernel, nvdimm, linux-cxl, Vishal Verma
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
Documentation/ABI/testing/sysfs-bus-dax | 151 ++++++++++++++++++++++++++++++++
1 file changed, 151 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
new file mode 100644
index 000000000000..a61a7b186017
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,151 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'end' attribute indicates the
+ end physical address for the given range.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'page_offset' attribute indicates the
+ offset of the current range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
--
2.41.0
^ permalink raw reply related [relevance 9%]
* [PATCH 2/2] docs: update ocfs2-devel mailing list address
@ 2023-06-28 1:34 9% ` Anthony Iliopoulos
0 siblings, 0 replies; 200+ results
From: Anthony Iliopoulos @ 2023-06-28 1:34 UTC (permalink / raw)
To: Mark Fasheh, Joel Becker, Joseph Qi; +Cc: ocfs2-devel, linux-kernel, linux-doc
The ocfs2-devel mailing list has been migrated to the kernel.org
infrastructure, update all related documentation pointers to reflect the
change.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
---
Documentation/ABI/obsolete/o2cb | 4 ++--
Documentation/ABI/removed/o2cb | 4 ++--
Documentation/ABI/stable/o2cb | 4 ++--
Documentation/ABI/testing/sysfs-ocfs2 | 12 ++++++------
Documentation/filesystems/dlmfs.rst | 2 +-
Documentation/filesystems/ocfs2.rst | 2 +-
fs/ocfs2/Kconfig | 6 +++---
7 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb
index fe7e45e17bc7..8f39b596731d 100644
--- a/Documentation/ABI/obsolete/o2cb
+++ b/Documentation/ABI/obsolete/o2cb
@@ -1,11 +1,11 @@
What: /sys/o2cb
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Was renamed to /sys/fs/u2cb/
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/removed/o2cb b/Documentation/ABI/removed/o2cb
index 20c91adca6d4..61cff238fbe8 100644
--- a/Documentation/ABI/removed/o2cb
+++ b/Documentation/ABI/removed/o2cb
@@ -1,10 +1,10 @@
What: /sys/o2cb symlink
Date: May 2011
KernelVersion: 3.0
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
removed when new versions of ocfs2-tools which know to look
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
software to look here, it should try /sys/fs/o2cb instead.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb
index b62a967f01a0..3a83b5c54e93 100644
--- a/Documentation/ABI/stable/o2cb
+++ b/Documentation/ABI/stable/o2cb
@@ -1,10 +1,10 @@
What: /sys/fs/o2cb/
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/testing/sysfs-ocfs2 b/Documentation/ABI/testing/sysfs-ocfs2
index b7cc516a8a8a..494d7c1ac710 100644
--- a/Documentation/ABI/testing/sysfs-ocfs2
+++ b/Documentation/ABI/testing/sysfs-ocfs2
@@ -1,13 +1,13 @@
What: /sys/fs/ocfs2/
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2 directory contains knobs used by the
ocfs2-tools to interact with the filesystem.
What: /sys/fs/ocfs2/max_locking_protocol
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/max_locking_protocol file displays version
of ocfs2 locking supported by the filesystem. This version
@@ -28,7 +28,7 @@ Description:
What: /sys/fs/ocfs2/loaded_cluster_plugins
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/loaded_cluster_plugins file describes
the available plugins to support ocfs2 cluster operation.
@@ -48,7 +48,7 @@ Description:
What: /sys/fs/ocfs2/active_cluster_plugin
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/active_cluster_plugin displays which
cluster plugin is currently in use by the filesystem.
@@ -65,7 +65,7 @@ Description:
What: /sys/fs/ocfs2/cluster_stack
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/cluster_stack file contains the name
of current ocfs2 cluster stack. This value is set by
@@ -86,4 +86,4 @@ Description:
stack return an error.
Users:
- ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
+ ocfs2-tools <ocfs2-tools-devel@lists.linux.dev>
diff --git a/Documentation/filesystems/dlmfs.rst b/Documentation/filesystems/dlmfs.rst
index 28dd41a63be2..7e2b1fd471d7 100644
--- a/Documentation/filesystems/dlmfs.rst
+++ b/Documentation/filesystems/dlmfs.rst
@@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires most of its infrastructure.
:Project web page: http://ocfs2.wiki.kernel.org
:Tools web page: https://github.com/markfasheh/ocfs2-tools
-:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+:OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
diff --git a/Documentation/filesystems/ocfs2.rst b/Documentation/filesystems/ocfs2.rst
index 42ca9a3d4c6e..5827062995cb 100644
--- a/Documentation/filesystems/ocfs2.rst
+++ b/Documentation/filesystems/ocfs2.rst
@@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl".
Project web page: http://ocfs2.wiki.kernel.org
Tools git tree: https://github.com/markfasheh/ocfs2-tools
-OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
diff --git a/fs/ocfs2/Kconfig b/fs/ocfs2/Kconfig
index 304d12186ccd..3123da7cfb30 100644
--- a/fs/ocfs2/Kconfig
+++ b/fs/ocfs2/Kconfig
@@ -17,9 +17,9 @@ config OCFS2_FS
You'll want to install the ocfs2-tools package in order to at least
get "mount.ocfs2".
- Project web page: https://oss.oracle.com/projects/ocfs2
- Tools web page: https://oss.oracle.com/projects/ocfs2-tools
- OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+ Project web page: https://ocfs2.wiki.kernel.org/
+ Tools web page: https://github.com/markfasheh/ocfs2-tools
+ OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
For more information on OCFS2, see the file
<file:Documentation/filesystems/ocfs2.rst>.
--
2.35.3
^ permalink raw reply related [relevance 9%]
* [PATCH 1/2] MAINTAINERS: Add our new mailing-list
@ 2021-03-31 13:08 9% Maxime Ripard
0 siblings, 0 replies; 200+ results
From: Maxime Ripard @ 2021-03-31 13:08 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec; +Cc: linux-arm-kernel, linux-sunxi
We've been struggling to get an LF-hosted mailing list for a while, but
now that lists.linux.dev is there we opted in.
Let's add it to MAINTAINERS.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..d8c00df4045c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1576,6 +1576,7 @@ R: Jernej Skrabec <jernej.skrabec@siol.net>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
+L: linux-sunxi@lists.linux.dev
F: arch/arm/mach-sunxi/
F: arch/arm64/boot/dts/allwinner/
F: drivers/clk/sunxi-ng/
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 9%]
* [PATCH v2 1/2] MAINTAINERS: add regressions mailing list
@ 2021-04-09 11:47 9% ` Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2021-04-09 11:47 UTC (permalink / raw)
To: Jonathan Corbet, Greg KH, Linus Torvalds
Cc: Randy Dunlap, linux-doc, linux-kernel
Add the newly created regression mailing list finally created after it
already had been agreed on during the maintainers summit 2017 (see
https://lwn.net/Articles/738216/ ). The topic was recently discussed
again, where an idea to create a broader list for all issues was
discussed, but Linus preferred a more targeted list:
https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
Hence, the creation for that list was asked for and granted:
https://bugzilla.kernel.org/show_bug.cgi?id=212557
In the end it became regressions@lists.linux.dev instead of
linux-regressions@lists.linux.dev as 'Linux' would have been redundant
in the latter case.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
v1->v2
* use the approach suggested by Greg, which doesn't have a K: entry,
but that is likely not much of a help anyway
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 83472755a255..2553fec1d272 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9730,6 +9730,11 @@ F: include/uapi/linux/sunrpc/
F: net/sunrpc/
F: Documentation/filesystems/nfs/
+KERNEL REGRESSIONS
+M: Thorsten Leemhuis <linux@leemhuis.info>
+L: regressions@lists.linux.dev
+S: Supported
+
KERNEL SELFTEST FRAMEWORK
M: Shuah Khan <shuah@kernel.org>
M: Shuah Khan <skhan@linuxfoundation.org>
--
2.30.2
^ permalink raw reply related [relevance 9%]
* Invitation: Clang Built Linux Meetup II turbo (2021) @ Fri Sep 17, 2021 8am - 2pm (PDT) (llvm@lists.linux.dev)
@ 2021-09-14 22:38 9% Nick Desaulniers
0 siblings, 0 replies; 200+ results
From: Nick Desaulniers @ 2021-09-14 22:38 UTC (permalink / raw)
To: llvm, Clang Built Linux, Kees Cook, Bill Wendling, masahiroy,
Arnd Bergmann, clang linux fellowship, broonie
[-- Attachment #1.1: Type: text/plain, Size: 1714 bytes --]
You have been invited to the following event.
Title: Clang Built Linux Meetup II turbo (2021)
https://github.com/ClangBuiltLinux/CBL-meetup-II-turbo
When: Fri Sep 17, 2021 8am – 2pm Pacific Time - Los Angeles
Joining info: Join with Google Meet
https://meet.google.com/afa-rwuq-cjw?hs=224
Join by phone
(US) +1 304-837-2121 (PIN: 754085626)
More phone numbers: https://tel.meet/afa-rwuq-cjw?pin=7299273353650&hs=0
Calendar: llvm@lists.linux.dev
Who:
* Nick Desaulniers - organizer
* Clang Built Linux
* Kees Cook
* Bill Wendling
* masahiroy@kernel.org
* Arnd Bergmann
* llvm@lists.linux.dev
* clang linux fellowship
* broonie@kernel.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=M3NhaG03bHNvZ2ZmdDhscmR0cGk3MzljcnUgbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb205MWRkZjg0NzllOTk3NDE4YzdhOGQ3OTNlNGVjMzE0YWMwZDE2ZDVh&ctz=America%2FLos_Angeles&hl=en&es=0
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account llvm@lists.linux.dev
because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
[-- Attachment #1.2: Type: text/html, Size: 15682 bytes --]
[-- Attachment #1.3: Type: text/calendar, Size: 2633 bytes --]
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20210917T150000Z
DTEND:20210917T210000Z
DTSTAMP:20210914T223844Z
ORGANIZER;CN=Nick Desaulniers:mailto:ndesaulniers@google.com
UID:3sahm7lsogfft8lrdtpi739cru@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Clang Built Linux;X-NUM-GUESTS=0:mailto:clang-built-linux@googlegro
ups.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Kees Cook;X-NUM-GUESTS=0:mailto:keescook@chromium.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Nick Desaulniers;X-NUM-GUESTS=0:mailto:ndesaulniers@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Bill Wendling;X-NUM-GUESTS=0:mailto:morbo@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=masahiroy@kernel.org;X-NUM-GUESTS=0:mailto:masahiroy@kernel.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Arnd Bergmann;X-NUM-GUESTS=0:mailto:arnd@linaro.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=llvm@lists.linux.dev;X-NUM-GUESTS=0:mailto:llvm@lists.linux.dev
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=clang linux fellowship;X-NUM-GUESTS=0:mailto:clang-linux-fellowship
@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=broonie@kernel.org;X-NUM-GUESTS=0:mailto:broonie@kernel.org
X-MICROSOFT-CDO-OWNERAPPTID:1293796827
CREATED:20210914T223841Z
DESCRIPTION:https://github.com/ClangBuiltLinux/CBL-meetup-II-turbo\n\n-::~:
~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
:~:~::-\nDo not edit this section of the description.\n\nThis event has a v
ideo call.\nJoin: https://meet.google.com/afa-rwuq-cjw\n(US) +1 304-837-212
1 PIN: 754085626#\nView more phone numbers: https://tel.meet/afa-rwuq-cjw?p
in=7299273353650&hs=7\n\nView your event at https://calendar.google.com/cal
endar/event?action=VIEW&eid=M3NhaG03bHNvZ2ZmdDhscmR0cGk3MzljcnUgbGx2bUBsaXN
0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb205MWRkZjg0NzllOTk3ND
E4YzdhOGQ3OTNlNGVjMzE0YWMwZDE2ZDVh&ctz=America%2FLos_Angeles&hl=en&es=1.\n-
::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
~:~::~:~::-
LAST-MODIFIED:20210914T223843Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Clang Built Linux Meetup II turbo (2021)
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
[-- Attachment #2: invite.ics --]
[-- Type: application/ics, Size: 2685 bytes --]
^ permalink raw reply [relevance 9%]
* Re: Create kdevops@lists.linux.dev
2023-08-17 0:00 9% Create kdevops@lists.linux.dev Luis Chamberlain
@ 2023-08-17 16:52 9% ` Shyam Kumar
0 siblings, 0 replies; 200+ results
From: Shyam Kumar @ 2023-08-17 16:52 UTC (permalink / raw)
To: Luis Chamberlain; +Cc: helpdesk, jlayton, amir73il, patches
Hello
The list is created. It is listed here :
https://subspace.kernel.org/lists.linux.dev.html
Thanks
shyam
On Thu, Aug 17, 2023 at 5:30 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> Address : kdevops@lists.linux.dev
> Description: Linux kernel kdevops project
> Owners : mcgrof@kernel.org, jlayton@kernel.org, amir73il@gmail.com
> Allow HTML : N
> Archives : Y
>
> Reasons for the list and additional info:
>
> kdevops [0] has picked up momentum over the years to the point we now
> have a community and reviewing patches is becoming more important.
> Although we are on github and gitlab and share an organization together
> I just noticed 3 pull requests have gone unnoticed for a while. So I'd
> prefer to just avoid web GUI pull requests and instead we deal with
> patches just as we do with Linux kernel subsystems.
>
> Luis
--
Regards
Shyam Kumar
The Linux Foundation Core Projects
^ permalink raw reply [relevance 9%]
* Re: [Cluster-devel] [ANNOUNCE] Goodbye cluster-devel, hello gfs2@lists.linux.dev
2023-08-29 17:07 10% ` Andrew Price
@ 2023-09-06 8:36 9% ` Andrew Price
-1 siblings, 0 replies; 200+ results
From: Andrew Price @ 2023-09-06 8:36 UTC (permalink / raw)
To: cluster-devel; +Cc: gfs2, linux-fsdevel
On 29/08/2023 18:07, Andrew Price wrote:
> Hi all,
>
> As cluster-devel is now only used for gfs2 and dlm development, we will
> be moving them to a new list hosted by kernel.org alongside other Linux
> subsystems' lists. The new list is gfs2@lists.linux.dev and it will be
> used for both gfs2 and dlm development.
>
> The Linux MAINTAINERS file and other references will be updated shortly
> to reflect the change. Information about the list hosting can be found
> here:
Updates to the MAINTAINERS file have now been merged into mainline so
gfs2@lists.linux.dev is now the official mailing list for gfs2 and dlm
development.
(CC+ linux-fsdevel for awareness.)
Thanks,
Andy
> https://subspace.kernel.org/lists.linux.dev.html
>
> To subscribe, send an email (the subject and body doesn't matter) to:
>
> Subscribe: gfs2+subscribe@lists.linux.dev
> Unsubscribe: gfs2+unsubscribe@lists.linux.dev
>
> If you prefer, the list can also be read via NNTP at:
>
> nntp://nntp.lore.kernel.org/dev.linux.lists.gfs2
>
> The archives can be found here:
>
> https://lore.kernel.org/gfs2/
>
> and filters can use the "List-Id: <gfs2.lists.linux.dev>" header.
>
> Thanks,
> Andy
^ permalink raw reply [relevance 9%]
* Re: [ANNOUNCE] Goodbye cluster-devel, hello gfs2@lists.linux.dev
@ 2023-09-06 8:36 9% ` Andrew Price
0 siblings, 0 replies; 200+ results
From: Andrew Price @ 2023-09-06 8:36 UTC (permalink / raw)
To: cluster-devel; +Cc: gfs2, linux-fsdevel
On 29/08/2023 18:07, Andrew Price wrote:
> Hi all,
>
> As cluster-devel is now only used for gfs2 and dlm development, we will
> be moving them to a new list hosted by kernel.org alongside other Linux
> subsystems' lists. The new list is gfs2@lists.linux.dev and it will be
> used for both gfs2 and dlm development.
>
> The Linux MAINTAINERS file and other references will be updated shortly
> to reflect the change. Information about the list hosting can be found
> here:
Updates to the MAINTAINERS file have now been merged into mainline so
gfs2@lists.linux.dev is now the official mailing list for gfs2 and dlm
development.
(CC+ linux-fsdevel for awareness.)
Thanks,
Andy
> https://subspace.kernel.org/lists.linux.dev.html
>
> To subscribe, send an email (the subject and body doesn't matter) to:
>
> Subscribe: gfs2+subscribe@lists.linux.dev
> Unsubscribe: gfs2+unsubscribe@lists.linux.dev
>
> If you prefer, the list can also be read via NNTP at:
>
> nntp://nntp.lore.kernel.org/dev.linux.lists.gfs2
>
> The archives can be found here:
>
> https://lore.kernel.org/gfs2/
>
> and filters can use the "List-Id: <gfs2.lists.linux.dev>" header.
>
> Thanks,
> Andy
^ permalink raw reply [relevance 9%]
* Updated invitation with note: Toolchains and Kernel MC @ Fri Sep 24, 2021 7am - 11am (PDT) (llvm@lists.linux.dev)
@ 2021-08-25 22:54 9% Nick Desaulniers
0 siblings, 0 replies; 200+ results
From: Nick Desaulniers @ 2021-08-25 22:54 UTC (permalink / raw)
To: llvm, Clang Built Linux, jemarch
[-- Attachment #1.1: Type: text/plain, Size: 1684 bytes --]
This event has been changed with this note:
"add title "Toolchains and Kernel MC""
Title: Toolchains and Kernel MC (changed)
https://linuxplumbersconf.org/event/11/sessions/107/#20210924
https://linuxplumbersconf.org/event/11/timetable/#all
When: Fri Sep 24, 2021 7am – 11am Pacific Time - Los Angeles
Joining info: Join with Google Meet
https://meet.google.com/nug-ienp-dtk?hs=224
Join by phone
(US) +1 401-830-3337 (PIN: 583983966)
More phone numbers: https://tel.meet/nug-ienp-dtk?pin=9387162795492&hs=0
Calendar: llvm@lists.linux.dev
Who:
* Nick Desaulniers - organizer
* Clang Built Linux
* llvm@lists.linux.dev
* jemarch@gnu.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=MGkwb2lkc2JtajdqdWllYW5namoxZDhmZDggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb20zMDY0ZDI3ZTY4ZGU1Yjg2MTJlMmE2ODU4OWE3YTE4OTFjNzljMTUz&ctz=America%2FLos_Angeles&hl=en&es=0
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account llvm@lists.linux.dev
because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
[-- Attachment #1.2: Type: text/html, Size: 13162 bytes --]
[-- Attachment #1.3: Type: text/calendar, Size: 1944 bytes --]
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20210924T140000Z
DTEND:20210924T180000Z
DTSTAMP:20210825T225436Z
ORGANIZER;CN=Nick Desaulniers:mailto:ndesaulniers@google.com
UID:0i0oidsbmj7juieangjj1d8fd8@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Clang Built Linux;X-NUM-GUESTS=0:mailto:clang-built-linux@googlegro
ups.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Nick Desaulniers;X-NUM-GUESTS=0:mailto:ndesaulniers@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=llvm@lists.linux.dev;X-NUM-GUESTS=0:mailto:llvm@lists.linux.dev
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=jemarch@gnu.org;X-NUM-GUESTS=0:mailto:jemarch@gnu.org
X-MICROSOFT-CDO-OWNERAPPTID:-883088066
CREATED:20210825T225401Z
DESCRIPTION:https://linuxplumbersconf.org/event/11/sessions/107/#20210924\n
https://linuxplumbersconf.org/event/11/timetable/#all\n\n-::~:~::~:~:~:~:~:
~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo n
ot edit this section of the description.\n\nThis event has a video call.\nJ
oin: https://meet.google.com/nug-ienp-dtk\n(US) +1 401-830-3337 PIN: 583983
966#\nView more phone numbers: https://tel.meet/nug-ienp-dtk?pin=9387162795
492&hs=7\n\nView your event at https://calendar.google.com/calendar/event?a
ction=VIEW&eid=MGkwb2lkc2JtajdqdWllYW5namoxZDhmZDggbGx2bUBsaXN0cy5saW51eC5k
ZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb20zMDY0ZDI3ZTY4ZGU1Yjg2MTJlMmE2ODU
4OWE3YTE4OTFjNzljMTUz&ctz=America%2FLos_Angeles&hl=en&es=0.\n-::~:~::~:~:~:
~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20210825T225435Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Toolchains and Kernel MC
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
[-- Attachment #2: invite.ics --]
[-- Type: application/ics, Size: 1985 bytes --]
^ permalink raw reply [relevance 9%]
* Create kdevops@lists.linux.dev
@ 2023-08-17 0:00 9% Luis Chamberlain
2023-08-17 16:52 9% ` Shyam Kumar
0 siblings, 1 reply; 200+ results
From: Luis Chamberlain @ 2023-08-17 0:00 UTC (permalink / raw)
To: helpdesk; +Cc: Luis Chamberlain, jlayton, amir73il, patches, Shyam Kumar
Address : kdevops@lists.linux.dev
Description: Linux kernel kdevops project
Owners : mcgrof@kernel.org, jlayton@kernel.org, amir73il@gmail.com
Allow HTML : N
Archives : Y
Reasons for the list and additional info:
kdevops [0] has picked up momentum over the years to the point we now
have a community and reviewing patches is becoming more important.
Although we are on github and gitlab and share an organization together
I just noticed 3 pull requests have gone unnoticed for a while. So I'd
prefer to just avoid web GUI pull requests and instead we deal with
patches just as we do with Linux kernel subsystems.
Luis
^ permalink raw reply [relevance 9%]
* Invitation: (No Subject) @ Fri Sep 24, 2021 7am - 11am (PDT) (llvm@lists.linux.dev)
@ 2021-08-25 22:54 9% Nick Desaulniers
0 siblings, 0 replies; 200+ results
From: Nick Desaulniers @ 2021-08-25 22:54 UTC (permalink / raw)
To: llvm, Clang Built Linux, jemarch
[-- Attachment #1.1: Type: text/plain, Size: 1624 bytes --]
You have been invited to the following event.
Title: (No Subject)
https://linuxplumbersconf.org/event/11/sessions/107/#20210924
https://linuxplumbersconf.org/event/11/timetable/#all
When: Fri Sep 24, 2021 7am – 11am Pacific Time - Los Angeles
Joining info: Join with Google Meet
https://meet.google.com/nug-ienp-dtk?hs=224
Join by phone
(US) +1 401-830-3337 (PIN: 583983966)
More phone numbers: https://tel.meet/nug-ienp-dtk?pin=9387162795492&hs=0
Calendar: llvm@lists.linux.dev
Who:
* Nick Desaulniers - organizer
* Clang Built Linux
* llvm@lists.linux.dev
* jemarch@gnu.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=MGkwb2lkc2JtajdqdWllYW5namoxZDhmZDggbGx2bUBsaXN0cy5saW51eC5kZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb20zMDY0ZDI3ZTY4ZGU1Yjg2MTJlMmE2ODU4OWE3YTE4OTFjNzljMTUz&ctz=America%2FLos_Angeles&hl=en&es=0
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account llvm@lists.linux.dev
because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
[-- Attachment #1.2: Type: text/html, Size: 13063 bytes --]
[-- Attachment #1.3: Type: text/calendar, Size: 1920 bytes --]
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20210924T140000Z
DTEND:20210924T180000Z
DTSTAMP:20210825T225403Z
ORGANIZER;CN=Nick Desaulniers:mailto:ndesaulniers@google.com
UID:0i0oidsbmj7juieangjj1d8fd8@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=Clang Built Linux;X-NUM-GUESTS=0:mailto:clang-built-linux@googlegro
ups.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Nick Desaulniers;X-NUM-GUESTS=0:mailto:ndesaulniers@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=llvm@lists.linux.dev;X-NUM-GUESTS=0:mailto:llvm@lists.linux.dev
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=jemarch@gnu.org;X-NUM-GUESTS=0:mailto:jemarch@gnu.org
X-MICROSOFT-CDO-OWNERAPPTID:-883088066
CREATED:20210825T225401Z
DESCRIPTION:https://linuxplumbersconf.org/event/11/sessions/107/#20210924\n
https://linuxplumbersconf.org/event/11/timetable/#all\n\n-::~:~::~:~:~:~:~:
~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo n
ot edit this section of the description.\n\nThis event has a video call.\nJ
oin: https://meet.google.com/nug-ienp-dtk\n(US) +1 401-830-3337 PIN: 583983
966#\nView more phone numbers: https://tel.meet/nug-ienp-dtk?pin=9387162795
492&hs=7\n\nView your event at https://calendar.google.com/calendar/event?a
ction=VIEW&eid=MGkwb2lkc2JtajdqdWllYW5namoxZDhmZDggbGx2bUBsaXN0cy5saW51eC5k
ZXY&tok=MjMjbmRlc2F1bG5pZXJzQGdvb2dsZS5jb20zMDY0ZDI3ZTY4ZGU1Yjg2MTJlMmE2ODU
4OWE3YTE4OTFjNzljMTUz&ctz=America%2FLos_Angeles&hl=en&es=1.\n-::~:~::~:~:~:
~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20210825T225402Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
[-- Attachment #2: invite.ics --]
[-- Type: application/ics, Size: 1961 bytes --]
^ permalink raw reply [relevance 9%]
* [PATCH] KVM: arm64: Advertise new kvmarm mailing list
@ 2022-10-01 9:12 9% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2022-10-01 9:12 UTC (permalink / raw)
To: kvmarm, kvmarm
Cc: James Morse, Suzuki K Poulose, Alexandru Elisei, Oliver Upton,
Catalin Marinas, Mark Rutland, Will Deacon, kvm, linux-arm-kernel
As announced on the kvmarm list, we're moving the mailing list over
to kvmarm@lists.linux.dev:
<quote>
As you probably all know, the kvmarm mailing has been hosted on
Columbia's machines for as long as the project existed (over 13
years). After all this time, the university has decided to retire the
list infrastructure and asked us to find a new hosting.
A new mailing list has been created on lists.linux.dev[1], and I'm
kindly asking everyone interested in following the KVM/arm64
developments to start subscribing to it (and start posting your
patches there). I hope that people will move over to it quickly enough
that we can soon give Columbia the green light to turn their systems
off.
Note that the new list will only get archived automatically once we
fully switch over, but I'll make sure we fill any gap and not lose any
message. In the meantime, please Cc both lists.
[...]
[1] https://subspace.kernel.org/lists.linux.dev.html
</quote>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 589517372408..f29f27717de4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11124,7 +11124,8 @@ R: Alexandru Elisei <alexandru.elisei@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Oliver Upton <oliver.upton@linux.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: kvmarm@lists.cs.columbia.edu (moderated for non-subscribers)
+L: kvmarm@lists.linux.dev
+L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
F: arch/arm64/include/asm/kvm*
--
2.34.1
^ permalink raw reply related [relevance 9%]
* Invitation: [PATCH] staging: rtl8723bs: remove possible deadlock when... @ Sat 2021-09-11 05:30 - 06:30 (CEST) (linux-staging@lists.linux.dev)
@ 2021-09-11 3:09 9% fmdefrancesco
0 siblings, 0 replies; 200+ results
From: fmdefrancesco @ 2021-09-11 3:09 UTC (permalink / raw)
To: linux-staging
[-- Attachment #1.1: Type: text/plain, Size: 1988 bytes --]
You have been invited to the following event.
Title: [PATCH] staging: rtl8723bs: remove possible deadlock when disconnect
Hi,
On 9/2/21 11:35 AM, Fabio Aiuto wrote:
> when turning off a connection, lockdep complains with the
> following warning (a modprobe has been done but the same
> happens with a disconnection from NetworkManager,
> it's enough to trigger a cfg80211_disconnect call):
>
> [ 682.855867] ======================================================
> [ 682.855877] WARNING: possible circular locking dependency detected
> [ 682.855887] 5.14.0-rc6+ #16 Tainted: G C OE
> [ 682.855898]
------------------------------------------------------...
When: Sat 2021-09-11 05:30 – 06:30 Central European Time - Rome
Joining info: Join with Google Meet
https://meet.google.com/dbz-zgqx-avd?hs=224
Calendar: linux-staging@lists.linux.dev
Who:
(Guest list has been hidden at organizer's request)
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=MGNiZHBnMzZsY2ppMjhidGlobG05aG05ZmQgbGludXgtc3RhZ2luZ0BsaXN0cy5saW51eC5kZXY&tok=MjMjZm1kZWZyYW5jZXNjb0BnbWFpbC5jb20yYTVmNDZlYzZlMzk0NzAzNzA0MGQ1YTdjYzgwYjlmNTNlZTI2ZTky&ctz=Europe%2FRome&hl=en&es=0
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account
linux-staging@lists.linux.dev because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
[-- Attachment #1.2: Type: text/html, Size: 9498 bytes --]
[-- Attachment #1.3: Type: text/calendar, Size: 1916 bytes --]
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20210911T033000Z
DTEND:20210911T043000Z
DTSTAMP:20210911T030943Z
ORGANIZER;CN=fmdefrancesco@gmail.com:mailto:fmdefrancesco@gmail.com
UID:0cbdpg36lcji28btihlm9hm9fd@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=linux-staging@lists.linux.dev;X-NUM-GUESTS=0:mailto:linux-staging@l
ists.linux.dev
X-MICROSOFT-CDO-OWNERAPPTID:2050649180
CREATED:20210911T030941Z
DESCRIPTION:Hi\,\n\n\nOn 9/2/21 11:35 AM\, Fabio Aiuto wrote:\n> when turni
ng off a connection\, lockdep complains with the\n> following warning (a mo
dprobe has been done but the same\n> happens with a disconnection from Netw
orkManager\,\n> it's enough to trigger a cfg80211_disconnect call):\n>\n> [
682.855867] ======================================================\n> [
682.855877] WARNING: possible circular locking dependency detected\n> [ 68
2.855887] 5.14.0-rc6+ #16 Tainted: G C OE\n> [ 682.855898] -------
-----------------------------------------------...\n\n-::~:~::~:~:~:~:~:~:~
:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not
edit this section of the description.\n\nThis event has a video call.\nJoin
: https://meet.google.com/dbz-zgqx-avd\n\nView your event at https://calend
ar.google.com/calendar/event?action=VIEW&eid=MGNiZHBnMzZsY2ppMjhidGlobG05aG
05ZmQgbGludXgtc3RhZ2luZ0BsaXN0cy5saW51eC5kZXY&tok=MjMjZm1kZWZyYW5jZXNjb0Bnb
WFpbC5jb20yYTVmNDZlYzZlMzk0NzAzNzA0MGQ1YTdjYzgwYjlmNTNlZTI2ZTky&ctz=Europe%
2FRome&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20210911T030941Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[PATCH] staging: rtl8723bs: remove possible deadlock when disconnec
t
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
[-- Attachment #2: invite.ics --]
[-- Type: application/ics, Size: 1957 bytes --]
^ permalink raw reply [relevance 9%]
* [PATCH] KVM: arm64: Advertise new kvmarm mailing list
@ 2022-10-01 9:12 9% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2022-10-01 9:12 UTC (permalink / raw)
To: kvmarm, kvmarm
Cc: James Morse, Suzuki K Poulose, Alexandru Elisei, Oliver Upton,
Catalin Marinas, Mark Rutland, Will Deacon, kvm, linux-arm-kernel
As announced on the kvmarm list, we're moving the mailing list over
to kvmarm@lists.linux.dev:
<quote>
As you probably all know, the kvmarm mailing has been hosted on
Columbia's machines for as long as the project existed (over 13
years). After all this time, the university has decided to retire the
list infrastructure and asked us to find a new hosting.
A new mailing list has been created on lists.linux.dev[1], and I'm
kindly asking everyone interested in following the KVM/arm64
developments to start subscribing to it (and start posting your
patches there). I hope that people will move over to it quickly enough
that we can soon give Columbia the green light to turn their systems
off.
Note that the new list will only get archived automatically once we
fully switch over, but I'll make sure we fill any gap and not lose any
message. In the meantime, please Cc both lists.
[...]
[1] https://subspace.kernel.org/lists.linux.dev.html
</quote>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 589517372408..f29f27717de4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11124,7 +11124,8 @@ R: Alexandru Elisei <alexandru.elisei@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Oliver Upton <oliver.upton@linux.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: kvmarm@lists.cs.columbia.edu (moderated for non-subscribers)
+L: kvmarm@lists.linux.dev
+L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
F: arch/arm64/include/asm/kvm*
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 9%]
* [PATCH] Update email address and mailing list for v9fs
@ 2023-04-01 19:06 9% Eric Van Hensbergen
0 siblings, 0 replies; 200+ results
From: Eric Van Hensbergen @ 2023-04-01 19:06 UTC (permalink / raw)
To: v9fs-developer
Cc: v9fs, ericvh, lucho, asmadeus, linux_oss, rminnich,
Eric Van Hensbergen
We've recently moved the mailing list to lists.linux.dev to move away
from the sourceforge infrastructure. This also updates the website
from the (no longer v9fs relevant?) swik.net address to the github
group which contains pointers to test cases, the protocol, servers,
etc. This also changes my email from my gmail to my kernel.org
address.
Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..6567bae7137b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -224,13 +224,13 @@ S: Orphan / Obsolete
F: drivers/net/ethernet/8390/
9P FILE SYSTEM
-M: Eric Van Hensbergen <ericvh@gmail.com>
+M: Eric Van Hensbergen <ericvh@kernel.org>
M: Latchesar Ionkov <lucho@ionkov.net>
M: Dominique Martinet <asmadeus@codewreck.org>
R: Christian Schoenebeck <linux_oss@crudebyte.com>
-L: v9fs-developer@lists.sourceforge.net
+L: v9fs@lists.linux.dev <v9fs@lists.linux.dev>
S: Maintained
-W: http://swik.net/v9fs
+W: http://github.com/v9fs
Q: http://patchwork.kernel.org/project/v9fs-devel/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
T: git git://github.com/martinetd/linux.git
---
base-commit: 707823e7f22f3864ddc7d85e8e9b614afe4f1b16
change-id: 20230401-ericvh-fix-maintainers-865452e6c43a
Best regards,
--
Eric Van Hensbergen <ericvh@kernel.org>
^ permalink raw reply related [relevance 9%]
* Re: PSA: generic patches@lists.linux.dev list
2021-11-29 21:56 10% PSA: generic patches@lists.linux.dev list Konstantin Ryabitsev
@ 2021-11-30 1:09 9% ` Lukas Bulwahn
0 siblings, 0 replies; 200+ results
From: Lukas Bulwahn @ 2021-11-30 1:09 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: users, workflows
On Tue, Nov 30, 2021 at 12:56 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Hi, all:
>
> We have a generically named list `patches@lists.linux.dev` that can be used as
> an address for sending patches.
>
> This can be useful for a number of reasons:
>
> 1. those maintainers already using lei [1] can list patches@lists.linux.dev as
> the mailing list address for their subsystem and receive mail sent to it
> via lei saved searches
> 2. mail sent to this address goes to public-inbox first, so it's likely to
> show up on lore.kernel.org very quickly, with fewest delays and omissions
> 3. you can use this address as an extra cc for mail sent to other lists that
> are less likely to preserve the message body as-is -- when retrieving mail
> with b4, it will give priority to the linux.dev address in the presence of
> duplicates.
>
> Mostly, it's a dumping ground for patches. We can even use it as "THE REST"
> address in MAINTAINERS to help offload some of the traffic from vger and make
> linux-kernel@vger.kernel.org less of a firehose and more amenable to actual
> discussions.
>
I always thought that sending patches to mailing lists has the beauty
that the technical discussion and decision on the actual change is
"seamlessly" connected on the same channel and allows simple
transition between those two categories. E.g., a discussion can evolve
into a proposition of a patch within the email thread or a patch can
spin-off a wider discussion on the software architecture or policies
in the development.
The proposition of patches@lists.linux.dev dedicated for patches vs.
other mails somehow is troubling to that beauty.
Also, I would not be surprised if besides the obvious disconnect
caused by two lists and the unclear situation of which email belongs
to which category (when does a technical discussion cause a patch
proposition, or when is a patch review evolving into a policy
discussion), we end up with two mailing lists, patches and
linux-kernel, that both lists still feel like two fire hoses similarly
uncontrollable as before. Or alternatively: any good filtering that
made it manageable before with one large list, would not look
significantly simpler just because there are now two lists with an
implicit categorization on its mail content.
Just thinking out loud,
Lukas
^ permalink raw reply [relevance 9%]
* [merged] maintainers-update-clangbuiltlinux-mailing-list.patch removed from -mm tree
@ 2021-09-09 21:04 9% akpm
0 siblings, 0 replies; 200+ results
From: akpm @ 2021-09-09 21:04 UTC (permalink / raw)
To: keescook, masahiroy, mm-commits, nathan, ndesaulniers,
samitolvanen
The patch titled
Subject: MAINTAINERS: update ClangBuiltLinux mailing list
has been removed from the -mm tree. Its filename was
maintainers-update-clangbuiltlinux-mailing-list.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Nathan Chancellor <nathan@kernel.org>
Subject: MAINTAINERS: update ClangBuiltLinux mailing list
We are now at llvm@lists.linux.dev.
Link: https://lkml.kernel.org/r/20210825211823.6406-1-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/MAINTAINERS~maintainers-update-clangbuiltlinux-mailing-list
+++ a/MAINTAINERS
@@ -4504,7 +4504,7 @@ F: .clang-format
CLANG/LLVM BUILD SUPPORT
M: Nathan Chancellor <nathan@kernel.org>
M: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
W: https://clangbuiltlinux.github.io/
B: https://github.com/ClangBuiltLinux/linux/issues
@@ -4519,7 +4519,7 @@ M: Sami Tolvanen <samitolvanen@google.co
M: Kees Cook <keescook@chromium.org>
R: Nathan Chancellor <nathan@kernel.org>
R: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
B: https://github.com/ClangBuiltLinux/linux/issues
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
_
Patches currently in -mm which might be from nathan@kernel.org are
^ permalink raw reply [relevance 9%]
* Returned mail: see transcript for details
@ 2022-03-17 9:30 9% Mail Delivery Subsystem
0 siblings, 0 replies; 200+ results
From: Mail Delivery Subsystem @ 2022-03-17 9:30 UTC (permalink / raw)
To: ntfs3
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
The original message was received at Thu, 17 Mar 2022 05:26:47 -0400
from atl4mhho02.myregisteredsite.com [209.17.115.107]
----- The following addresses had permanent fatal errors -----
<ntfs3@lists.linux.dev>
(reason: 550 5.7.1 Blocked by SpamAssassin)
----- Transcript of session follows -----
... while talking to smtp.subspace.kernel.org.:
>>> DATA
<<< 550 5.7.1 Blocked by SpamAssassin
554 5.0.0 Service unavailable
[-- Attachment #2: Type: message/delivery-status, Size: 325 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 20340 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 1743 bytes --]
Hi,
Your package is on the way!
We inform you that your shipment No. 1342380845800663937946 is still awaiting instructions from you.
Get notifications for DHL packages coming to you.
Estimated Delivery
Day 18-03-2022
11:45 AM - 3:45 PM
Track Your Package ›
DHL Ground
1Z4265670327926167
You will be prompted to accept Terms and Conditions to change delivery.
©2022 United Parcel Service of America, Inc. DHL, the DHL brandmark, and the color brown are trademarks of United Parcel Service of America, Inc. All rights reserved.
Please do not reply to this email.
Privacy Notice | Service Terms | Help & Support
[-- Attachment #3.1.2: Type: text/html, Size: 14295 bytes --]
^ permalink raw reply [relevance 9%]
* Undelivered Mail Returned to Sender
@ 2023-01-30 12:17 9% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-01-30 12:17 UTC (permalink / raw)
To: llvm
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 538 bytes --]
This is the mail system at host 157-7-214-225.localdomain.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<llvm@lists.linux.dev>: host smtp.subspace.kernel.org[44.238.234.78] said: 550
5.7.1 Blocked by SpamAssassin (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 352 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 7050 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 1474 bytes --]
あなたのアカウントは停止されました
※本メールは重要なお知らせのため、メールを受け取らない設定をされている方にもお送りしております。ご了承ください。
ログイン日時:01/30/2023 07:16:08 pm
こんにちは、アマゾンのアカウントを使って別のデバイスからログインしようと何度も試みられましたことを通知するメーセージです。お客さまのアカウントを保護するために、アカウントを一時的にロックしました｡
アカウントを引き続き使用するには、24時間前に情報を更新することをお勧めします。それ以外の場合、あなたのアカウントは永久ロック。
確認用アカウント
© 2023 Amazon.com, Inc. or its
affiliates. All rights reserved. Amazon, Amazon.co.jp, Amazon Prime, Prime
およびAmazon.co.jp のロゴは Amazon.com , Inc.またはその関連会社の商標です。 Amazon.com, 410
Terry Avenue N., Seattle, yw1kfbk2vrrlcrylkzs09m
[-- Attachment #3.1.2: Type: text/html, Size: 4664 bytes --]
^ permalink raw reply [relevance 9%]
* [PATCH] KVM: arm64: Advertise new kvmarm mailing list
@ 2022-10-01 9:12 9% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2022-10-01 9:12 UTC (permalink / raw)
To: kvmarm, kvmarm; +Cc: kvm, Will Deacon, Catalin Marinas, linux-arm-kernel
As announced on the kvmarm list, we're moving the mailing list over
to kvmarm@lists.linux.dev:
<quote>
As you probably all know, the kvmarm mailing has been hosted on
Columbia's machines for as long as the project existed (over 13
years). After all this time, the university has decided to retire the
list infrastructure and asked us to find a new hosting.
A new mailing list has been created on lists.linux.dev[1], and I'm
kindly asking everyone interested in following the KVM/arm64
developments to start subscribing to it (and start posting your
patches there). I hope that people will move over to it quickly enough
that we can soon give Columbia the green light to turn their systems
off.
Note that the new list will only get archived automatically once we
fully switch over, but I'll make sure we fill any gap and not lose any
message. In the meantime, please Cc both lists.
[...]
[1] https://subspace.kernel.org/lists.linux.dev.html
</quote>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 589517372408..f29f27717de4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11124,7 +11124,8 @@ R: Alexandru Elisei <alexandru.elisei@arm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
R: Oliver Upton <oliver.upton@linux.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: kvmarm@lists.cs.columbia.edu (moderated for non-subscribers)
+L: kvmarm@lists.linux.dev
+L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
F: arch/arm64/include/asm/kvm*
--
2.34.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [relevance 9%]
* Re: Bouncing messages from linux-staging@lists.linux.dev
[not found] <1620376201-3408-mlmmj-4f932172@lists.linux.dev>
@ 2021-05-07 9:08 9% ` Fabio Aiuto
0 siblings, 0 replies; 200+ results
From: Fabio Aiuto @ 2021-05-07 9:08 UTC (permalink / raw)
To: linux-staging
Hi all,
On Fri, May 07, 2021 at 08:30:01AM +0000, linux-staging+owner@lists.linux.dev wrote:
> Greetings!
>
> This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> mailing list.
>
> Some messages to you could not be delivered. If you're seeing this
> message it means things are back to normal, and it's merely for your
> information.
>
> Here is the list of the bounced messages:
> - 2608
>
>
what I'm supposed to do now if I'd want to retrieve the bounced message?
thank you in advance,
fabio
^ permalink raw reply [relevance 9%]
* [patch 096/147] MAINTAINERS: update ClangBuiltLinux mailing list
@ 2021-09-08 2:58 9% ` Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2021-09-08 2:58 UTC (permalink / raw)
To: akpm, keescook, linux-mm, masahiroy, mm-commits, nathan,
ndesaulniers, samitolvanen, torvalds
From: Nathan Chancellor <nathan@kernel.org>
Subject: MAINTAINERS: update ClangBuiltLinux mailing list
We are now at llvm@lists.linux.dev.
Link: https://lkml.kernel.org/r/20210825211823.6406-1-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/MAINTAINERS~maintainers-update-clangbuiltlinux-mailing-list
+++ a/MAINTAINERS
@@ -4504,7 +4504,7 @@ F: .clang-format
CLANG/LLVM BUILD SUPPORT
M: Nathan Chancellor <nathan@kernel.org>
M: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
W: https://clangbuiltlinux.github.io/
B: https://github.com/ClangBuiltLinux/linux/issues
@@ -4519,7 +4519,7 @@ M: Sami Tolvanen <samitolvanen@google.co
M: Kees Cook <keescook@chromium.org>
R: Nathan Chancellor <nathan@kernel.org>
R: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
B: https://github.com/ClangBuiltLinux/linux/issues
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
_
^ permalink raw reply [relevance 9%]
* [merged mm-stable] docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch removed from -mm tree
@ 2024-02-22 0:02 9% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-02-22 0:02 UTC (permalink / raw)
To: mm-commits, siyanteng, shuah, corbet, alexs, 2023002089, sj, akpm
The quilt patch titled
Subject: Docs/admin-guide/mm/damon/usage: document 'DEPRECATED' file of DAMON debugfs interface
has been removed from the -mm tree. Its filename was
docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: Docs/admin-guide/mm/damon/usage: document 'DEPRECATED' file of DAMON debugfs interface
Date: Mon, 29 Jan 2024 17:35:44 -0800
Document the newly added DAMON debugfs interface deprecation notice file
on the usage document.
Link: https://lkml.kernel.org/r/20240130013549.89538-6-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Alex Shi <alexs@kernel.org>
Cc: Hu Haowen <2023002089@link.tyut.edu.cn>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/Documentation/admin-guide/mm/damon/usage.rst~docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface
+++ a/Documentation/admin-guide/mm/damon/usage.rst
@@ -628,9 +628,16 @@ debugfs Interface (DEPRECATED!)
move, please report your usecase to damon@lists.linux.dev and
linux-mm@kvack.org.
-DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
-``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
-``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
+DAMON exports nine files, ``DEPRECATED``, ``attrs``, ``target_ids``,
+``init_regions``, ``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts``
+and ``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
+
+
+``DEPRECATED`` is a read-only file for the DAMON debugfs interface deprecation
+notice. Reading it returns the deprecation notice, as below::
+
+ # cat DEPRECATED
+ DAMON debugfs interface is deprecated, so users should move to DAMON_SYSFS. If you cannot, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.
Attributes
_
Patches currently in -mm which might be from sj@kernel.org are
docs-mm-damon-maintainer-profile-fix-reference-links-for-mm-stable-tree.patch
docs-mm-damon-move-the-list-of-damos-actions-to-design-doc.patch
docs-mm-damon-move-damon-operation-sets-list-from-the-usage-to-the-design-document.patch
docs-mm-damon-move-damon-operation-sets-list-from-the-usage-to-the-design-document-fix.patch
docs-mm-damon-move-monitoring-target-regions-setup-detail-from-the-usage-to-the-design-document.patch
docs-admin-guide-mm-damon-usage-fix-wrong-quotas-diabling-condition.patch
mm-damon-core-set-damos_quota-esz-as-public-field-and-document.patch
mm-damon-sysfs-schemes-implement-quota-effective_bytes-file.patch
mm-damon-sysfs-implement-a-kdamond-command-for-updating-schemes-effective-quotas.patch
docs-abi-damon-document-effective_bytes-sysfs-file.patch
docs-admin-guide-mm-damon-usage-document-effective_bytes-file.patch
mm-damon-move-comments-and-fields-for-damos-quota-prioritization-to-the-end.patch
mm-damon-core-split-out-quota-goal-related-fields-to-a-struct.patch
mm-damon-core-add-multiple-goals-per-damos_quota-and-helpers-for-those.patch
mm-damon-sysfs-use-only-quota-goals.patch
mm-damon-core-remove-goal-field-of-damos_quota.patch
mm-damon-core-let-goal-specified-with-only-target-and-current-values.patch
mm-damon-core-support-multiple-metrics-for-quota-goal.patch
mm-damon-core-implement-psi-metric-damos-quota-goal.patch
mm-damon-sysfs-schemes-support-psi-based-quota-auto-tune.patch
docs-mm-damon-design-document-quota-goal-self-tuning.patch
docs-abi-damon-document-quota-goal-metric-file.patch
docs-admin-guide-mm-damon-usage-document-quota-goal-metric-file.patch
docs-admin-guide-mm-damon-usage-document-quota-goal-metric-file-fix.patch
mm-damon-reclaim-implement-user-feedback-driven-quota-auto-tuning.patch
mm-damon-reclaim-implement-memory-psi-driven-quota-self-tuning.patch
docs-admin-guide-mm-damon-reclaim-document-auto-tuning-parameters.patch
^ permalink raw reply [relevance 9%]
* Re: KernelCI at lists.linux.dev
[not found] ` <1706552EEFF7A8A6.5263@groups.io>
@ 2022-11-18 10:04 9% ` Guillaume Tucker
0 siblings, 0 replies; 200+ results
From: Guillaume Tucker @ 2022-11-18 10:04 UTC (permalink / raw)
To: kernelci; +Cc: helpdesk, Konstantin Ryabitsev
On 29/07/2022 17:06, Guillaume Tucker wrote:
> On 15/07/2022 07:12, Guillaume Tucker wrote:
>> On 14/07/2022 16:51, Konstantin Ryabitsev wrote:
>>> On Thu, Jul 14, 2022 at 10:26:57AM +0200, Guillaume Tucker wrote:
>>>> Hello,
>>>>
>>>> The KernelCI community has been using kernelci@groups.io for a
>>>> few years, however it's less than ideal as messages have to be
>>>> moderated for all non-members. Also we've been getting closer to
>>>> the kernel community over the years and it isn't a great fit for
>>>> that. Would it be possible to create a kernelci@lists.linux.dev
>>>> mailing list so we would then transition away from groups.io?
>>>
>>> For sure, I don't see why not. We can even import groups.io archives once the
>>> migration is decided. If you do decide to move, just follow the procedure
>>> described on
>>> https://subspace.kernel.org/lists.linux.dev.html#requesting-list-hosting
>>
>> Thank you, I've just done that now.
>
> As we would like to move to the new list and stop using
> groups.io, it would seem useful to also import the list of
> subscribers from groups.io. Please let me know if you don't want
> to be subscribed to the new list by the end of next week (Aug 5).
The new mailing list has now been set up and is ready to be used!
Many thanks to Konstantin for taking care of this. All the
subscribers of kernelci@groups.io have been automatically added
and all the email archives have been imported.
The new mailing list address is kernelci@lists.linux.dev and you
should already have received a welcome email. The new archives
are available on https://lore.kernel.org/kernelci/. See
https://subspace.kernel.org/lists.linux.dev.html for more
details about how to subscribe / unsubscribe etc.
The old group is now obsolete so please don't send emails to it
any more. I've updated the home page with details about this:
https://groups.io/g/kernelci
It can't be locked but after a while we can remove all the
members and change the permissions so nobody can post to it any
more. We should wait for a little while before doing that to
ensure a smooth transition, probably until January.
Please let us know if you have any questions or comments. Enjoy
the new mailing list!
Best wishes,
Guillaume
^ permalink raw reply [relevance 9%]
* [PATCH] multipath-tools: update ml
@ 2023-12-15 23:32 9% Xose Vazquez Perez
0 siblings, 0 replies; 200+ results
From: Xose Vazquez Perez @ 2023-12-15 23:32 UTC (permalink / raw)
Cc: Xose Vazquez Perez, Martin Wilck, Benjamin Marzinski,
Christophe Varoqui, DM-DEVEL ML
Cc: Martin Wilck <mwilck@suse.com>
Cc: Benjamin Marzinski <bmarzins@redhat.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: DM-DEVEL ML <dm-devel@lists.linux.dev>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
libdmmp/docs/man/libdmmp.h.3 | 2 +-
libmultipath/hwtable.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libdmmp/docs/man/libdmmp.h.3 b/libdmmp/docs/man/libdmmp.h.3
index 45d5be3e..7c57041d 100644
--- a/libdmmp/docs/man/libdmmp.h.3
+++ b/libdmmp/docs/man/libdmmp.h.3
@@ -110,4 +110,4 @@ below in case you want to create your own log handler.
GPLv2+
.SH "BUG"
-Please report bug to <dm-devel@redhat.com>
+Please report bug to <dm-devel@lists.linux.dev>
diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
index ae6aac79..808af544 100644
--- a/libmultipath/hwtable.c
+++ b/libmultipath/hwtable.c
@@ -11,7 +11,7 @@
/*
* Tuning suggestions on these parameters should go to
- * dm-devel@redhat.com (subscribers-only, see README)
+ * <dm-devel@lists.linux.dev> (see README.md)
*
* You are welcome to claim maintainership over a controller
* family. Please mail the currently enlisted maintainer and
--
2.43.0
^ permalink raw reply related [relevance 9%]
* [PATCH v3] README: Update mailing list info
@ 2021-06-02 6:43 9% Daniel Wagner
0 siblings, 0 replies; 200+ results
From: Daniel Wagner @ 2021-06-02 6:43 UTC (permalink / raw)
To: connman; +Cc: Daniel Wagner
ConnMan is hosted on lists.linux.dev from now on. Update the entry and
also explain how to subscribe. While at it also mention the official
archive.
---
README | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 167f21ee1c23..e36d796c30a7 100644
--- a/README
+++ b/README
@@ -444,6 +444,12 @@ Information
===========
Mailing list:
- connman@connman.net
+ connman@lists.linux.dev
-You can report bugs to the mailing list.
+If you would like to subscribe to receive mail in your inbox, just
+send a (empty) message from your email account to
+
+ connman+subscribe@lists.linux.dev
+
+Maling list archive:
+ https://lore.kernel.org/connman
--
2.31.1
^ permalink raw reply related [relevance 9%]
* [PATCH 1/3] MAINTAINERS: Update ClangBuiltLinux mailing list
@ 2021-08-25 21:18 9% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-08-25 21:18 UTC (permalink / raw)
To: Andrew Morton, Masahiro Yamada, Kees Cook
Cc: Sami Tolvanen, Nick Desaulniers, linux-kernel, llvm,
clang-built-linux, Nathan Chancellor
We are now at llvm@lists.linux.dev.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c6b8a720c0bc..8e36f55430de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4504,7 +4504,7 @@ F: .clang-format
CLANG/LLVM BUILD SUPPORT
M: Nathan Chancellor <nathan@kernel.org>
M: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
W: https://clangbuiltlinux.github.io/
B: https://github.com/ClangBuiltLinux/linux/issues
@@ -4519,7 +4519,7 @@ M: Sami Tolvanen <samitolvanen@google.com>
M: Kees Cook <keescook@chromium.org>
R: Nathan Chancellor <nathan@kernel.org>
R: Nick Desaulniers <ndesaulniers@google.com>
-L: clang-built-linux@googlegroups.com
+L: llvm@lists.linux.dev
S: Supported
B: https://github.com/ClangBuiltLinux/linux/issues
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
base-commit: e22ce8eb631bdc47a4a4ea7ecf4e4ba499db4f93
--
2.33.0
^ permalink raw reply related [relevance 9%]
* [Tech-board-discuss] PSA: this list is moving to lists.linux.dev (no action required)
@ 2023-12-18 23:07 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 23:07 UTC (permalink / raw)
To: tech-board-discuss
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
to live on lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be tech-board-discuss@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/tech-board-discuss/ with
all prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <tech-board-discuss.lists.linuxfoundation.org>
after: List-Id: <tech-board-discuss.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [Tech-board-discuss] (because
this violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. I will follow up
on Thursday after the migration has been completed.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* Welcome to kernelci@lists.linux.dev
@ 2022-11-17 14:25 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2022-11-17 14:25 UTC (permalink / raw)
To: kernelci
Hello:
This is a welcome message to notify you that you've been auto-subscribed to
the new KernelCI mailing list at kernelci@lists.linux.dev. If you haven't
received this message, then you haven't been subscribed (in which case I'm
assuming you are reading this message on https://lore.kernel.org/kernelci/
:)).
If you've changed your mind and don't want to be on this list any longer,
please send a message to kernelci+unsubscribe@lists.linux.dev to be removed.
Best regards,
Konstantin
^ permalink raw reply [relevance 9%]
* Re: dm-devel has migrated to lists.linux.dev
2023-10-06 23:43 9% ` Mike Snitzer
2023-10-11 18:41 9% ` Mike Snitzer
@ 2023-10-11 14:35 9% ` Mike Snitzer
1 sibling, 0 replies; 200+ results
From: Mike Snitzer @ 2023-10-11 14:35 UTC (permalink / raw)
To: dm-devel
On Fri, Oct 06 2023 at 7:43P -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Fri, Oct 06 2023 at 7:29P -0400,
> Mike Snitzer <snitzer@kernel.org> wrote:
>
> > Hi,
> >
> > As a dm-devel@redhat.com subscriber, you have been silently subscribed
> > to the new mailing list: dm-devel@lists.linux.dev.
> >
> > Effective immediately, all dm-devel email should be addressed to:
> > dm-devel@lists.linux.dev
> >
> > (I say this but my "git pull" request that I just sent to Linus, to
> > update the MAINTAINERS file accordingly, cc'd dm-devel@redhat.com --
> > dm-devel@redhat.com will still function as it has, but nobody should
> > use it moving forward).
> >
> > If you do send email to dm-devel@redhat.com you will get this
> > auto-response:
> >
> > As of 2023.10.06: dm-devel@redhat.com has migrated to
> > dm-devel@lists.linux.dev
> >
> > If you were a dm-devel@redhat.com subscriber you have been silently
> > subscribed to dm-devel@lists.linux.dev
> >
> > NOTE: If you were a dm-devel@redhat.com subscriber but you disabled
> > mail delivery: then you must subscribe to dm-devel@lists.linux.dev.
> > To do so please send email to: dm-devel+subscribe@lists.linux.dev
> >
> > To unsubscribe from dm-devel@lists.linux.dev please send email to:
> > dm-devel+unsubscribe@lists.linux.dev
>
>
> Additional useful info:
>
> Please be sure to update any dm-devel mail filter you may have to look
> for this in mail headers:
> List-Id: <dm-devel.lists.linux.dev>
>
> Also, we will be backfilling "[dm-devel]" prefix for all list messages.
We cannot backfill the "[dm-devel]" prefix because that practice
breaks DKIM/DMARC.
Also, FYI: mail delivery has been disabled for all subscribers to
dm-devel@redhat.com, but the new list is subscribed and will relay any
mail sent to dm-devel@redhat.com to dm-devel@lists.linux.dev
(I've purposely sent this mail to dm-devel@redhat.com to test this
relay)
If/when you send mail to dm-devel@redhat.com you will still get an
autoresponse directing you to send future mail to
dm-devel@lists.linux.dev
Mike
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [relevance 9%]
* Re: dm-devel has migrated to lists.linux.dev
2023-10-06 23:43 9% ` Mike Snitzer
@ 2023-10-11 18:41 9% ` Mike Snitzer
2023-10-11 14:35 9% ` Mike Snitzer
1 sibling, 0 replies; 200+ results
From: Mike Snitzer @ 2023-10-11 18:41 UTC (permalink / raw)
To: dm-devel
[this is also test, to see if new list allows old list to email it]
On Fri, Oct 06 2023 at 7:43P -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Fri, Oct 06 2023 at 7:29P -0400,
> Mike Snitzer <snitzer@kernel.org> wrote:
>
> > Hi,
> >
> > As a dm-devel@redhat.com subscriber, you have been silently subscribed
> > to the new mailing list: dm-devel@lists.linux.dev.
> >
> > Effective immediately, all dm-devel email should be addressed to:
> > dm-devel@lists.linux.dev
> >
> > (I say this but my "git pull" request that I just sent to Linus, to
> > update the MAINTAINERS file accordingly, cc'd dm-devel@redhat.com --
> > dm-devel@redhat.com will still function as it has, but nobody should
> > use it moving forward).
> >
> > If you do send email to dm-devel@redhat.com you will get this
> > auto-response:
> >
> > As of 2023.10.06: dm-devel@redhat.com has migrated to
> > dm-devel@lists.linux.dev
> >
> > If you were a dm-devel@redhat.com subscriber you have been silently
> > subscribed to dm-devel@lists.linux.dev
> >
> > NOTE: If you were a dm-devel@redhat.com subscriber but you disabled
> > mail delivery: then you must subscribe to dm-devel@lists.linux.dev.
> > To do so please send email to: dm-devel+subscribe@lists.linux.dev
> >
> > To unsubscribe from dm-devel@lists.linux.dev please send email to:
> > dm-devel+unsubscribe@lists.linux.dev
>
>
> Additional useful info:
>
> Please be sure to update any dm-devel mail filter you may have to look
> for this in mail headers:
> List-Id: <dm-devel.lists.linux.dev>
>
> Also, we will be backfilling "[dm-devel]" prefix for all list messages.
We cannot backfill the "[dm-devel]" prefix because that practice
breaks DKIM/DMARC.
Also, FYI: mail delivery has been disabled for all subscribers to
dm-devel@redhat.com, but the new list is subscribed and will relay any
mail sent to dm-devel@redhat.com to dm-devel@lists.linux.dev
(I've purposely sent this mail to dm-devel@redhat.com to test this
relay)
If/when you send mail to dm-devel@redhat.com you will still get an
autoresponse directing you to send future mail to
dm-devel@lists.linux.dev
Mike
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [relevance 9%]
* [PATCH] KVM: arm64: Drop Columbia-hosted mailing list
@ 2023-01-13 13:28 9% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2023-01-13 13:28 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu
After many years of awesome service, the kvmarm mailing list hosted by
Columbia is being decommissioned, and replaced by kvmarm@lists.linux.dev.
Many thanks to Columbia for having hosted us for so long, and to the
kernel.org folks for giving us a new home.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6a0fc23455bd..d9a359a65d0f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11361,7 +11361,6 @@ R: Oliver Upton <oliver.upton@linux.dev>
R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.linux.dev
-L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
F: arch/arm64/include/asm/kvm*
--
2.34.1
^ permalink raw reply related [relevance 9%]
* PSA: this list has been migrated to lists.linux.dev
@ 2024-02-08 19:26 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2024-02-08 19:26 UTC (permalink / raw)
To: powertop
Hello, all:
Per previous discussions, this mailing list has been migrated to live on the
subspace.kernel.org system:
1. The new canonical list address is powertop@lists.linux.dev
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members have been automatically subscribed to the new list, so no
action is required on anyone's part to keep receiving list mail.
4. The list archives will be imported and available on
lore.kernel.org/powertop in the near future.
5. The List-ID header has changed, regardless to which address the message is
sent:
before: List-Id: <powertop.lists.linuxfoundation.org>
after: List-Id: <powertop.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header.
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [listname] (because this
violates DMARC).
7. Subscribing and unsubscribing is now done using mlmmj commands, see
https://subspace.kernel.org/subscribing.html for more info.
Please let me know if you have any concerns or comments.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [diamon-discuss] PSA: the diamon-discuss list will be moving to lists.linux.dev
@ 2023-11-21 20:43 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-21 20:43 UTC (permalink / raw)
To: diamon-discuss
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
Some time next week, the diamon-discuss list will be migrated to live on
lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be diamon-discuss@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/diamon-discuss/ with
all prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <diamon-discuss.lists.linuxfoundation.org>
after: List-Id: <diamon-discuss.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [diamon-discuss] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up next week with the exact date and time of the move.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [Printing-architecture] PSA: this list is moving to lists.linux.dev (no action required)
@ 2023-12-18 23:02 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 23:02 UTC (permalink / raw)
To: printing-architecture
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
to live on lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be printing-architecture@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/printing-architecture/
with all prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <printing-architecture.lists.linuxfoundation.org>
after: List-Id: <printing-architecture.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [Printing-architecture]
(because this violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. I will follow up
on Thursday after the migration has been completed.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [Accel-config] PSA: the accel-config list will be moving to lists.linux.dev
@ 2023-11-21 20:47 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-21 20:47 UTC (permalink / raw)
To: accel-config
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
Some time next week, the accel-config list will be migrated to live on
lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be accel-config@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/accel-config/ with
all prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <accel-config.lists.linuxfoundation.org>
after: List-Id: <accel-config.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [accel-config] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up next week with the exact date and time of the move.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [Lvfs-announce] PSA: this list is moving to lists.linux.dev (no action requried)
@ 2023-12-18 22:58 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 22:58 UTC (permalink / raw)
To: lvfs-announce
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
to live on lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be lvfs-announce@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/lvfs-announce/ with
all prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <lvfs-announce.lists.linuxfoundation.org>
after: List-Id: <lvfs-announce.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [Lvfs-announce] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. I will follow up
on Thursday after the migration has been completed.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [LVFS] PSA: this list is moving to lists.linux.dev (no action required)
@ 2023-12-18 22:54 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 22:54 UTC (permalink / raw)
To: lvfs-general
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
to live on lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be lvfs-general@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/lvfs-general/ with
all prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <lvfs-general.lists.linuxfoundation.org>
after: List-Id: <lvfs-general.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [LVFS] (because this violates
DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. I will follow up
on Thursday after the migration has been completed.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [Acpica-devel] PSA: the acpica-devel list is migrating to lists.linux.dev
@ 2023-11-01 21:26 9% Konstantin Ryabitsev
2023-11-07 19:41 9% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-11-01 21:26 UTC (permalink / raw)
To: acpica-devel
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
*On November 7*, The acpica-devel list will be migrated to live on
lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be acpica-devel@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/acpica-devel/ with all
prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <acpica-devel.lists.linuxfoundation.org>
after: List-Id: <acpica-devel.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after November 7).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [acpica-devel] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up on November 7 after the move has been completed.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [Fuego] PSA: the fuego list will be moving to lists.linux.dev
@ 2023-11-21 20:57 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-21 20:57 UTC (permalink / raw)
To: fuego
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
Some time next week, the fuego list will be migrated to live on
lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be fuego@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/fuego/ with all prior
archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <fuego.lists.linuxfoundation.org>
after: List-Id: <fuego.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [fuego] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up next week with the exact date and time of the move.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [SPDK] PSA: the spdk list will be moving to lists.linux.dev
@ 2023-11-21 21:38 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-21 21:38 UTC (permalink / raw)
To: spdk
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
Some time next week, the SPDK list will be migrated to live on
lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be spdk@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/spdk/ with all prior
archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <spdk.lists.linuxfoundation.org>
after: List-Id: <spdk.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [SPDK] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up next week with the exact date and time of the move.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [Tpm2] PSA: the tpm2 list will be moving to lists.linux.dev
@ 2023-11-21 21:21 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-21 21:21 UTC (permalink / raw)
To: tpm2
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
Some time next week, the tpm2 list will be migrated to live on
lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be tpm2@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/tpm2/ with all prior
archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <tpm2.lists.linuxfoundation.org>
after: List-Id: <tpm2.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [tpm2] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up next week with the exact date and time of the move.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [Opae] PSA: this list is moving to lists.linux.dev
@ 2023-12-18 23:00 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-12-18 23:00 UTC (permalink / raw)
To: opae
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
This Thursday, December 21, at 11AM PST (19:00 UTC), this list will be migrated
to live on lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be opae@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/opae/ with
all prior archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <opae.lists.linuxfoundation.org>
after: List-Id: <opae.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after the migration date).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [Opae] (because this violates
DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. I will follow up
on Thursday after the migration has been completed.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* Undelivered Mail Returned to Sender
@ 2023-02-10 4:18 9% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-02-10 4:18 UTC (permalink / raw)
To: llvm
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 541 bytes --]
This is the mail system at host i-17100000460103.localdomain.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<llvm@lists.linux.dev>: host smtp.subspace.kernel.org[44.238.234.78] said: 550
5.7.1 Blocked by SpamAssassin (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 355 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 31296 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 6312 bytes --]
利用実績の確認
この度はETCサービスをご利用いただきまして誠にありがとうございます。近いうちに弊社はシステムをアップグレードの予定です。ETCアカウントにアカウントリマインダーリスクが検出されました。ETC決済方法を再確認ください。このサービスを継続希望の場合は、下記のリンクをクリックして詳細をご確認ください。
ログインを続行します
■
注意事項
*02/10/2023 12:12:26 pm残念ながら、24時間以内に確認できなければ、
お客様のアカウントをロックしてETCサービ スを一時的に無効に変更することをお知らせ
します。*このメールは重要なお知らせとして、メー
ルを受信希望しないお客様にもお送りいたし ます。ご理解いただき、ありがとうございま
す。*このメールがご不明点がありましたら、ETC
サイトにご連絡ください。
ご迷惑とご心配をおかけして、深くお詫び申
し上げます。ご了承ありがとうございました。
発行者：
ＥＴＣ利用照会サービス事務局
you received this
message at llvm@lists.linux.devEast Nippon Expressway
Company Limited,935b8a0fbfcb26e8d5780052fa317ad1Metropolitan Expressway
Company Limited,yz2b2nwro2rwdmve77af7
[-- Attachment #3.1.2: Type: text/html, Size: 23908 bytes --]
^ permalink raw reply [relevance 9%]
* Undelivered Mail Returned to Sender
@ 2023-02-12 5:24 9% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-02-12 5:24 UTC (permalink / raw)
To: llvm
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 538 bytes --]
This is the mail system at host 157-7-204-178.localdomain.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<llvm@lists.linux.dev>: host smtp.subspace.kernel.org[44.238.234.78] said: 550
5.7.1 Blocked by SpamAssassin (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 352 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 31295 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 6308 bytes --]
利用実績の確認
この度はETCサービスをご利用いただきまして誠にありがとうございます。近いうちに弊社はシステムをアップグレードの予定です。ETCアカウントにアカウントリマインダーリスクが検出されました。ETC決済方法を再確認ください。このサービスを継続希望の場合は、下記のリンクをクリックして詳細をご確認ください。
ログインを続行します
■
注意事項
*02/11/2023 08:39:57 am残念ながら、24時間以内に確認できなければ、
お客様のアカウントをロックしてETCサービ スを一時的に無効に変更することをお知らせ
します。*このメールは重要なお知らせとして、メー
ルを受信希望しないお客様にもお送りいたし ます。ご理解いただき、ありがとうございま
す。*このメールがご不明点がありましたら、ETC
サイトにご連絡ください。
ご迷惑とご心配をおかけして、深くお詫び申
し上げます。ご了承ありがとうございました。
発行者：
ＥＴＣ利用照会サービス事務局
you received this
message at llvm@lists.linux.devEast Nippon Expressway
Company Limited,f9d56272e69967dda622790c87ce4337Metropolitan Expressway
Company Limited,ibiu1puzh49lnzlw9
[-- Attachment #3.1.2: Type: text/html, Size: 23913 bytes --]
^ permalink raw reply [relevance 9%]
* [Bridge] PSA: the bridge list will be moving to lists.linux.dev
@ 2023-11-01 20:10 9% Konstantin Ryabitsev
2023-11-07 19:38 9% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2023-11-01 20:10 UTC (permalink / raw)
To: bridge
Hello, all:
The mailman-2 system running on lists.linux-foundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
*On November 7*, The bridge list will be migrated to live on lists.linux.dev,
but the impact of this move should be minor:
1. The new canonical list address will be bridge@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The list will be archived on https://lore.kernel.org/bridge/ with all prior
archives automatically imported.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <bridge.lists.linux-foundation.org>
after: List-Id: <bridge.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after November 7).
6. The mailman footer will no longer be added to message bodies and the
subject will no longer be modified to insert [bridge] (because this
violates DMARC).
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up on November 7 after the move has been completed.
Best regards,
-K
^ permalink raw reply [relevance 9%]
* [PATCH] dm vdo: use a proper Makefile for dm-vdo
@ 2024-01-27 2:18 9% Matthew Sakai
0 siblings, 0 replies; 200+ results
From: Matthew Sakai @ 2024-01-27 2:18 UTC (permalink / raw)
To: dm-devel; +Cc: Mike Snitzer, Matthew Sakai
From: Mike Snitzer <snitzer@kernel.org>
Requires moving dm-vdo-target.c into drivers/md/dm-vdo/
This change adds a proper drivers/md/dm-vdo/Makefile and eliminates
the abnormal use of patsubst in drivers/md/Makefile -- which was the
cause of at least one build failure that was reported by the upstream
build bot.
Also, split out VDO's drivers/md/dm-vdo/Kconfig and include it from
drivers/md/Kconfig
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Matthew Sakai <msakai@redhat.com>
---
MAINTAINERS | 1 -
drivers/md/Kconfig | 18 +-------
drivers/md/Makefile | 3 +-
drivers/md/dm-vdo/Kconfig | 17 +++++++
drivers/md/dm-vdo/Makefile | 61 +++++++++++++++++++++++++
drivers/md/{ => dm-vdo}/dm-vdo-target.c | 52 ++++++++++-----------
6 files changed, 107 insertions(+), 45 deletions(-)
create mode 100644 drivers/md/dm-vdo/Kconfig
create mode 100644 drivers/md/dm-vdo/Makefile
rename drivers/md/{ => dm-vdo}/dm-vdo-target.c (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5357fbe1cc90..91254b134456 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6007,7 +6007,6 @@ M: dm-devel@lists.linux.dev
L: dm-devel@lists.linux.dev
S: Maintained
F: Documentation/admin-guide/device-mapper/vdo*.rst
-F: drivers/md/dm-vdo-target.c
F: drivers/md/dm-vdo/
DEVLINK
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 9c4039106384..e11659186fd0 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -532,22 +532,6 @@ config DM_FLAKEY
help
A target that intermittently fails I/O for debugging purposes.
-config DM_VDO
- tristate "VDO: deduplication and compression target"
- depends on 64BIT
- depends on BLK_DEV_DM
- select DM_BUFIO
- select LZ4_COMPRESS
- select LZ4_DECOMPRESS
- help
- This device mapper target presents a block device with
- deduplication, compression and thin-provisioning.
-
- To compile this code as a module, choose M here: the module will
- be called dm-vdo.
-
- If unsure, say N.
-
config DM_VERITY
tristate "Verity target support"
depends on BLK_DEV_DM
@@ -683,4 +667,6 @@ config DM_AUDIT
Enables audit logging of several security relevant events in the
particular device-mapper targets, especially the integrity target.
+source "drivers/md/dm-vdo/Kconfig"
+
endif # MD
diff --git a/drivers/md/Makefile b/drivers/md/Makefile
index 47444b393abb..64b8f4deed4a 100644
--- a/drivers/md/Makefile
+++ b/drivers/md/Makefile
@@ -25,7 +25,6 @@ dm-ebs-y += dm-ebs-target.o
dm-era-y += dm-era-target.o
dm-clone-y += dm-clone-target.o dm-clone-metadata.o
dm-verity-y += dm-verity-target.o
-dm-vdo-y += dm-vdo-target.o $(patsubst drivers/md/dm-vdo/%.c,dm-vdo/%.o,$(wildcard $(src)/dm-vdo/*.c))
dm-zoned-y += dm-zoned-target.o dm-zoned-metadata.o dm-zoned-reclaim.o
md-mod-y += md.o md-bitmap.o
@@ -75,7 +74,7 @@ obj-$(CONFIG_DM_ZERO) += dm-zero.o
obj-$(CONFIG_DM_RAID) += dm-raid.o
obj-$(CONFIG_DM_THIN_PROVISIONING) += dm-thin-pool.o
obj-$(CONFIG_DM_VERITY) += dm-verity.o
-obj-$(CONFIG_DM_VDO) += dm-vdo.o
+obj-$(CONFIG_DM_VDO) += dm-vdo/
obj-$(CONFIG_DM_CACHE) += dm-cache.o
obj-$(CONFIG_DM_CACHE_SMQ) += dm-cache-smq.o
obj-$(CONFIG_DM_EBS) += dm-ebs.o
diff --git a/drivers/md/dm-vdo/Kconfig b/drivers/md/dm-vdo/Kconfig
new file mode 100644
index 000000000000..111ecd2c2a24
--- /dev/null
+++ b/drivers/md/dm-vdo/Kconfig
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config DM_VDO
+ tristate "VDO: deduplication and compression target"
+ depends on 64BIT
+ depends on BLK_DEV_DM
+ select DM_BUFIO
+ select LZ4_COMPRESS
+ select LZ4_DECOMPRESS
+ help
+ This device mapper target presents a block device with
+ deduplication, compression and thin-provisioning.
+
+ To compile this code as a module, choose M here: the module will
+ be called dm-vdo.
+
+ If unsure, say N.
diff --git a/drivers/md/dm-vdo/Makefile b/drivers/md/dm-vdo/Makefile
new file mode 100644
index 000000000000..8f8d161a6dbe
--- /dev/null
+++ b/drivers/md/dm-vdo/Makefile
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_DM_VDO) += dm-vdo.o
+
+dm-vdo-objs := \
+ action-manager.o \
+ admin-state.o \
+ block-map.o \
+ chapter-index.o \
+ completion.o \
+ config.o \
+ constants.o \
+ data-vio.o \
+ dedupe.o \
+ delta-index.o \
+ dm-vdo-target.o \
+ dump.o \
+ encodings.o \
+ errors.o \
+ flush.o \
+ funnel-queue.o \
+ funnel-requestqueue.o \
+ funnel-workqueue.o \
+ geometry.o \
+ index-layout.o \
+ index.o \
+ index-page-map.o \
+ index-session.o \
+ int-map.o \
+ io-factory.o \
+ io-submitter.o \
+ logger.o \
+ logical-zone.o \
+ memory-alloc.o \
+ message-stats.o \
+ murmurhash3.o \
+ open-chapter.o \
+ packer.o \
+ permassert.o \
+ physical-zone.o \
+ pool-sysfs.o \
+ pool-sysfs-stats.o \
+ priority-table.o \
+ radix-sort.o \
+ recovery-journal.o \
+ repair.o \
+ slab-depot.o \
+ sparse-cache.o \
+ status-codes.o \
+ string-utils.o \
+ sysfs.o \
+ thread-cond-var.o \
+ thread-device.o \
+ thread-registry.o \
+ uds-sysfs.o \
+ uds-threads.o \
+ vdo.o \
+ vio.o \
+ volume-index.o \
+ volume.o \
+ wait-queue.o
diff --git a/drivers/md/dm-vdo-target.c b/drivers/md/dm-vdo/dm-vdo-target.c
similarity index 99%
rename from drivers/md/dm-vdo-target.c
rename to drivers/md/dm-vdo/dm-vdo-target.c
index 4fbc148681e5..fcba50d8d088 100644
--- a/drivers/md/dm-vdo-target.c
+++ b/drivers/md/dm-vdo/dm-vdo-target.c
@@ -13,32 +13,32 @@
#include <linux/mutex.h>
#include <linux/spinlock.h>
-#include "dm-vdo/admin-state.h"
-#include "dm-vdo/block-map.h"
-#include "dm-vdo/completion.h"
-#include "dm-vdo/constants.h"
-#include "dm-vdo/data-vio.h"
-#include "dm-vdo/dedupe.h"
-#include "dm-vdo/dump.h"
-#include "dm-vdo/encodings.h"
-#include "dm-vdo/errors.h"
-#include "dm-vdo/flush.h"
-#include "dm-vdo/io-submitter.h"
-#include "dm-vdo/logger.h"
-#include "dm-vdo/memory-alloc.h"
-#include "dm-vdo/message-stats.h"
-#include "dm-vdo/pool-sysfs.h"
-#include "dm-vdo/recovery-journal.h"
-#include "dm-vdo/repair.h"
-#include "dm-vdo/slab-depot.h"
-#include "dm-vdo/status-codes.h"
-#include "dm-vdo/string-utils.h"
-#include "dm-vdo/thread-device.h"
-#include "dm-vdo/thread-registry.h"
-#include "dm-vdo/types.h"
-#include "dm-vdo/uds-sysfs.h"
-#include "dm-vdo/vdo.h"
-#include "dm-vdo/vio.h"
+#include "admin-state.h"
+#include "block-map.h"
+#include "completion.h"
+#include "constants.h"
+#include "data-vio.h"
+#include "dedupe.h"
+#include "dump.h"
+#include "encodings.h"
+#include "errors.h"
+#include "flush.h"
+#include "io-submitter.h"
+#include "logger.h"
+#include "memory-alloc.h"
+#include "message-stats.h"
+#include "pool-sysfs.h"
+#include "recovery-journal.h"
+#include "repair.h"
+#include "slab-depot.h"
+#include "status-codes.h"
+#include "string-utils.h"
+#include "thread-device.h"
+#include "thread-registry.h"
+#include "types.h"
+#include "uds-sysfs.h"
+#include "vdo.h"
+#include "vio.h"
#define CURRENT_VERSION "8.3.0.65"
--
2.42.0
^ permalink raw reply related [relevance 9%]
* PSA: this list is moving to virtualization@lists.linux.dev
@ 2023-11-01 18:17 9% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-01 18:17 UTC (permalink / raw)
To: virtualization
Hello, all:
As stated before [1], this list cannot stay on its current mailman-2 system, so I
am proceeding with moving this list to lists.linux.dev. The current plan is to
move it next week on November 7 around 10:30 AM PST (18:30 UTC).
Here's the impact of this change:
1. *The old address will continue to work*, so any existing conversations can
continue and any new patches sent to the old list address will be properly
delivered to list subscribers. The new canonical list address will be
virtualization@lists.linux.dev.
2. All subscribers will be automatically moved to the new system, so no action
is required on anyone's part to keep their subscription.
3. The archive on https://lore.kernel.org/virtualization/ will be
automatically updated to track the new list address.
4. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: Linux virtualization <virtualization.lists.linux-foundation.org>
after: List-Id: <virtualization.lists.linux.dev>
5. The mailman footer will no longer be added to message bodies.
6. Subscribing and unsubscribing will be done using the mlmmj supported
commands, described at https://subspace.kernel.org/subscribing.html
I believe this switch will not cause any significant disruption. Once the
switch is completed, I will submit a patch to MAINTAINERS to update all
entries with the old address.
Please let me know if you have any questions or concerns.
Best regards,
-K
[1] https://lore.kernel.org/virtualization/20231027-unyielding-futuristic-lizard-d22a58@meerkat/
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [relevance 9%]
* Undelivered Mail Returned to Sender
@ 2022-08-04 12:05 10% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2022-08-04 12:05 UTC (permalink / raw)
To: linux-staging
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 807 bytes --]
This is the mail system at host kevin.daysix.co.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<james@daysix.co>: host aspmx.l.google.com[142.250.145.27] said: 550-5.2.1 The
user you are trying to contact is receiving mail at a rate that 550-5.2.1
prevents additional messages from being delivered. For more 550-5.2.1
information, please visit 550 5.2.1
https://support.google.com/mail/?p=ReceivingRatePerm
l5-20020a50d6c5000000b0043bc31ac7d0si1141475edj.211 - gsmtp (in reply to
RCPT TO command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 629 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 701 bytes --]
From: linux-staging@lists.linux.dev
To: james@daysix.co
Subject: 24-7 Scotland Contact Form: THE WORLD FINANCIAL CRISIS CAN MAKE YOU RICH!
Date: Thu, 4 Aug 2022 08:04:49 -0400 (EDT)
Message-ID: <20220804120449.908CF14CEAF@kevin.daysix.co>
From: Richardfef
Reply-To: linux-staging@lists.linux.dev
Message: A QUICK AND EFFECTIVE WAY TO GET RICH >>> https://telegra.ph/Cryptocurrency-makes-people-millionaires-at-15-people-per-hour---Page-994285-08-02 <<<
^ permalink raw reply [relevance 10%]
* 24-7 Scotland Contact Form: THE WORLD FINANCIAL CRISIS CAN MAKE YOU RICH!
@ 2022-08-04 12:04 10% linux-staging
0 siblings, 0 replies; 200+ results
From: linux-staging @ 2022-08-04 12:04 UTC (permalink / raw)
To: linux-staging
From: Richardfef
Reply-To: linux-staging@lists.linux.dev
Message: A QUICK AND EFFECTIVE WAY TO GET RICH >>> https://telegra.ph/Cryptocurrency-makes-people-millionaires-at-15-people-per-hour---Page-994285-08-02 <<<
^ permalink raw reply [relevance 10%]
* Patch "MAINTAINERS: move the staging subsystem to lists.linux.dev" has been added to the 5.11-stable tree
@ 2021-03-22 9:45 10% gregkh
0 siblings, 0 replies; 200+ results
From: gregkh @ 2021-03-22 9:45 UTC (permalink / raw)
To: gregkh, linux-staging, mchehab+huawei; +Cc: stable-commits
This is a note to let you know that I've just added the patch titled
MAINTAINERS: move the staging subsystem to lists.linux.dev
to the 5.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch
and it can be found in the queue-5.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From e06da9ea3e3f6746a849edeae1d09ee821f5c2ce Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Tue, 16 Mar 2021 11:23:11 +0100
Subject: MAINTAINERS: move the staging subsystem to lists.linux.dev
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e06da9ea3e3f6746a849edeae1d09ee821f5c2ce upstream.
The drivers/staging/ tree has a new mailing list,
linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
it so that we get patches sent to the proper place.
There was no need to specify a list for the hikey9xx driver, the tools
pick up the "base" list for drivers/staging/* so remove that line to
make the file simpler.
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8079,7 +8079,6 @@ F: drivers/crypto/hisilicon/sec2/sec_mai
HISILICON STAGING DRIVERS FOR HIKEY 960/970
M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-L: devel@driverdev.osuosl.org
S: Maintained
F: drivers/staging/hikey9xx/
@@ -16911,7 +16910,7 @@ F: drivers/staging/vt665?/
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: devel@driverdev.osuosl.org
+L: linux-staging@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
F: drivers/staging/
Patches currently in stable-queue which might be from gregkh@linuxfoundation.org are
queue-5.11/iio-adc-ad7949-fix-wrong-adc-result-due-to-incorrect-bit-mask.patch
queue-5.11/iio-hid-sensor-temperature-fix-issues-of-timestamp-channel.patch
queue-5.11/ext4-fix-error-handling-in-ext4_end_enable_verity.patch
queue-5.11/drm-amd-display-remove-mpc-gamut-remap-logic-for-dcn30.patch
queue-5.11/nfsd-don-t-abort-copies-early.patch
queue-5.11/s390-pci-fix-leak-of-pci-device-structure.patch
queue-5.11/ext4-fix-timer-use-after-free-on-failed-mount.patch
queue-5.11/nvme-tcp-fix-a-null-deref-when-receiving-a-0-length-r2t-pdu.patch
queue-5.11/kernel-fs-introduce-and-use-set_restart_fn-and-arch_set_restart_data.patch
queue-5.11/cifs-fix-allocation-size-on-newly-created-files.patch
queue-5.11/usb-storage-add-quirk-to-defeat-kindle-s-automatic-unload.patch
queue-5.11/afs-stop-listxattr-from-listing-afs.-attributes.patch
queue-5.11/nvme-fix-write-zeroes-limitations.patch
queue-5.11/asoc-intel-bytcr_rt5640-fix-hp-pavilion-x2-10-p0xx-ovcd-current-threshold.patch
queue-5.11/afs-fix-accessing-yfs-xattrs-on-a-non-yfs-server.patch
queue-5.11/ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch
queue-5.11/iio-adc-stm32-adc-add-has_iomem-dependency.patch
queue-5.11/alsa-hda-realtek-apply-headset-mic-quirks-for-xiaomi-redmibook-air.patch
queue-5.11/nvme-tcp-fix-possible-hang-when-failing-to-set-io-queues.patch
queue-5.11/net-qrtr-fix-__netdev_alloc_skb-call.patch
queue-5.11/btrfs-fix-slab-cache-flags-for-free-space-tree-bitmap.patch
queue-5.11/iommu-amd-move-stoney-ridge-check-to-detect_ivrs.patch
queue-5.11/thunderbolt-increase-runtime-pm-reference-count-on-dp-tunnel-discovery.patch
queue-5.11/iio-gyro-mpu3050-fix-error-handling-in-mpu3050_trigger_handler.patch
queue-5.11/alsa-dice-fix-null-pointer-dereference-when-node-is-disconnected.patch
queue-5.11/alsa-hda-realtek-apply-pin-quirk-for-xiaominotebook-pro.patch
queue-5.11/usb-typec-remove-vdo-part-of-tps6598x_rx_identity_reg-struct.patch
queue-5.11/sunrpc-fix-refcount-leak-for-rpc-auth-modules.patch
queue-5.11/maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch
queue-5.11/nvme-tcp-fix-misuse-of-__smp_processor_id-with-preemption-enabled.patch
queue-5.11/io_uring-ensure-that-sqpoll-thread-is-started-for-exit.patch
queue-5.11/asoc-codecs-wcd934x-add-a-sanity-check-in-set-channel-map.patch
queue-5.11/nfsd-fix-dest-to-src-mount-in-inter-server-copy.patch
queue-5.11/powerpc-force-inlining-of-cpu_has_feature-to-avoid-build-failure.patch
queue-5.11/btrfs-fix-race-when-cloning-extent-buffer-during-rewind-of-an-old-root.patch
queue-5.11/asoc-simple-card-utils-do-not-handle-device-clock.patch
queue-5.11/perf-x86-intel-fix-a-crash-caused-by-zero-pebs-status.patch
queue-5.11/nvmet-don-t-check-iosqes-iocqes-for-discovery-controllers.patch
queue-5.11/ext4-fix-rename-whiteout-with-fast-commit.patch
queue-5.11/risc-v-fix-out-of-bounds-accesses-in-init_resources.patch
queue-5.11/usbip-fix-incorrect-double-assignment-to-udc-ud.tcp_rx.patch
queue-5.11/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-840-g8.patch
queue-5.11/drm-amd-display-correct-algorithm-for-reversed-gamma.patch
queue-5.11/thunderbolt-initialize-hopid-idas-in-tb_switch_alloc.patch
queue-5.11/maintainers-move-some-real-subsystems-off-of-the-staging-mailing-list.patch
queue-5.11/ext4-fix-potential-error-in-ext4_do_update_inode.patch
queue-5.11/iio-adis16400-fix-an-error-code-in-adis16400_initial_setup.patch
queue-5.11/asoc-ak5558-add-module_device_table.patch
queue-5.11/iio-adc-adi-axi-adc-add-proper-kconfig-dependencies.patch
queue-5.11/zonefs-fix-o_append-async-write-handling.patch
queue-5.11/x86-introduce-ts_compat_restart-to-fix-get_nr_restart_syscall.patch
queue-5.11/scsi-ufs-ufs-mediatek-correct-operator.patch
queue-5.11/x86-ioapic-ignore-irq2-again.patch
queue-5.11/nfsd-repair-misuse-of-sv_lock-in-5.10.16-rt30.patch
queue-5.11/counter-stm32-timer-cnt-fix-ceiling-write-max-value.patch
queue-5.11/iio-hid-sensor-prox-fix-scale-not-correct-issue.patch
queue-5.11/asoc-sof-intel-unregister-dmic-device-on-probe-error.patch
queue-5.11/pstore-fix-warning-in-pstore_kill_sb.patch
queue-5.11/s390-pci-remove-superfluous-zdev-zbus-check.patch
queue-5.11/asoc-fsl_ssi-fix-tdm-slot-setup-for-i2s-mode.patch
queue-5.11/zonefs-fix-to-update-.i_wr_refcnt-correctly-in-zonefs_open_zone.patch
queue-5.11/ext4-stop-inode-update-before-return.patch
queue-5.11/iio-adc-qcom-spmi-vadc-add-default-scale-to-lr_mux2_bat_id-channel.patch
queue-5.11/iommu-amd-don-t-call-early_amd_iommu_init-when-amd-iommu-is-disabled.patch
queue-5.11/asoc-sof-intel-fix-wrong-poll-bits-in-dsp-power-down.patch
queue-5.11/zonefs-prevent-use-of-seq-files-as-swap-file.patch
queue-5.11/vhost-vdpa-set-v-config_ctx-to-null-if-eventfd_ctx_fdget-fails.patch
queue-5.11/iio-adc-ab8500-gpadc-fix-off-by-10-to-3.patch
queue-5.11/usb-gadget-configfs-fix-kasan-use-after-free.patch
queue-5.11/asoc-qcom-sdm845-fix-array-out-of-range-on-rx-slim-channels.patch
queue-5.11/cifs-warn-and-fail-if-trying-to-use-rootfs-without-the-config-option.patch
queue-5.11/asoc-qcom-lpass-cpu-fix-lpass-dai-ids-parse.patch
queue-5.11/vhost-vdpa-fix-use-after-free-of-v-config_ctx.patch
queue-5.11/perf-x86-intel-fix-unchecked-msr-access-error-caused-by-vlbr_event.patch
queue-5.11/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-850-g8.patch
queue-5.11/usb-typec-tcpm-invoke-power_supply_changed-for-tcpm-source-psy.patch
queue-5.11/alsa-usb-audio-fix-unintentional-sign-extension-issue.patch
queue-5.11/iommu-tegra-smmu-make-tegra_smmu_probe_device-to-handle-all-iommu-phandles.patch
queue-5.11/iio-hid-sensor-humidity-fix-alignment-issue-of-timestamp-channel.patch
queue-5.11/vfio-iommu_api-should-be-selected.patch
queue-5.11/iommu-amd-keep-track-of-amd_iommu_irq_remap-state.patch
queue-5.11/kbuild-fix-linux-version.h-for-empty-sublevel-or-patchlevel-again.patch
queue-5.11/revert-pm-runtime-update-device-status-before-letting-suppliers-suspend.patch
queue-5.11/i915-perf-start-hrtimer-only-if-sampling-the-oa-buffer.patch
queue-5.11/x86-move-ts_compat-back-to-asm-thread_info.h.patch
queue-5.11/svcrdma-disable-timeouts-on-rdma-backchannel.patch
queue-5.11/scsi-mpt3sas-do-not-use-gfp_kernel-in-atomic-context.patch
queue-5.11/asoc-ak4458-add-module_device_table.patch
queue-5.11/counter-stm32-timer-cnt-fix-ceiling-miss-alignment-with-reload-register.patch
queue-5.11/s390-pci-refactor-zpci_create_device.patch
queue-5.11/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-440-g8.patch
queue-5.11/scsi-myrs-fix-a-double-free-in-myrs_cleanup.patch
queue-5.11/nfsd-don-t-keep-looking-up-unhashed-files-in-the-nfsd-file-cache.patch
queue-5.11/scsi-lpfc-fix-some-error-codes-in-debugfs.patch
queue-5.11/asoc-qcom-sdm845-fix-array-out-of-bounds-access.patch
queue-5.11/spi-cadence-set-cqspi-to-the-driver_data-field-of-struct-device.patch
queue-5.11/drm-amd-display-copy-over-soc-values-before-bounding-box-creation.patch
queue-5.11/efivars-respect-efi_unsupported-return-from-firmware.patch
queue-5.11/pci-rpadlpar-fix-potential-drc_name-corruption-in-store-functions.patch
queue-5.11/usb-dwc3-gadget-prevent-ep-queuing-while-stopping-transfers.patch
queue-5.11/usb-dwc3-gadget-allow-runtime-suspend-if-udc-unbinded.patch
queue-5.11/s390-vtime-fix-increased-steal-time-accounting.patch
queue-5.11/vhost_vdpa-fix-the-missing-irq_bypass_unregister_producer-invocation.patch
queue-5.11/ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch
queue-5.11/riscv-correct-sparsemem-configuration.patch
queue-5.11/risc-v-correct-enum-sbi_ext_rfence_fid.patch
queue-5.11/alsa-hda-generic-fix-the-micmute-led-init-state.patch
^ permalink raw reply [relevance 10%]
* PSA: generic patches@lists.linux.dev list
@ 2021-11-29 21:56 10% Konstantin Ryabitsev
2021-11-30 1:09 9% ` Lukas Bulwahn
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2021-11-29 21:56 UTC (permalink / raw)
To: users, workflows
Hi, all:
We have a generically named list `patches@lists.linux.dev` that can be used as
an address for sending patches.
This can be useful for a number of reasons:
1. those maintainers already using lei [1] can list patches@lists.linux.dev as
the mailing list address for their subsystem and receive mail sent to it
via lei saved searches
2. mail sent to this address goes to public-inbox first, so it's likely to
show up on lore.kernel.org very quickly, with fewest delays and omissions
3. you can use this address as an extra cc for mail sent to other lists that
are less likely to preserve the message body as-is -- when retrieving mail
with b4, it will give priority to the linux.dev address in the presence of
duplicates.
Mostly, it's a dumping ground for patches. We can even use it as "THE REST"
address in MAINTAINERS to help offload some of the traffic from vger and make
linux-kernel@vger.kernel.org less of a firehose and more amenable to actual
discussions.
-K
^ permalink raw reply [relevance 10%]
* [RFC PATCH v1 1/2] docs: reporting-issue: rework the detailed guide
2024-03-26 12:21 13% ` [RFC PATCH v1 2/2] docs: reporting-issue: rework the TLDR Thorsten Leemhuis
@ 2024-03-26 12:21 10% ` Thorsten Leemhuis
1 sibling, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2024-03-26 12:21 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: regressions, linux-doc, linux-kernel, workflows
Rework the detailed step-by-step guide for various reasons:
* Simplify the search with the help of lore.kernel.org/all/, which did
not exist when the text was written.
* Make use of the recently added document
Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst,
which covers many steps this text partly covered way better.
* The 'quickly report a stable regression to the stable team' approach
hardly worked out: most of the time the regression was not known yet.
Try a different approach using the regressions list.
* Reports about stable/longterm regressions most of the time were
greeted with a brief reply along the lines of 'Is mainline affected as
well?'; this is needed to determine who is responsible, so we might as
well make the reporter check that before sending the report (which
verify-bugs-and-bisect-regressions.rst already tells them to do, too).
* A lot of fine tuning after seeing what people were struggling with.
FIXME: adjust the entries in the reference section to match these
changes.
Not-signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
.../admin-guide/reporting-issues.rst | 391 ++++++++++--------
1 file changed, 210 insertions(+), 181 deletions(-)
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 2fd5a030235ad0..e6083946c146e8 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -48,187 +48,216 @@ Once the report is out, answer any questions that come up and help where you
can. That includes keeping the ball rolling by occasionally retesting with newer
releases and sending a status update afterwards.
-Step-by-step guide how to report issues to the kernel maintainers
-=================================================================
-
-The above TL;DR outlines roughly how to report issues to the Linux kernel
-developers. It might be all that's needed for people already familiar with
-reporting issues to Free/Libre & Open Source Software (FLOSS) projects. For
-everyone else there is this section. It is more detailed and uses a
-step-by-step approach. It still tries to be brief for readability and leaves
-out a lot of details; those are described below the step-by-step guide in a
-reference section, which explains each of the steps in more detail.
-
-Note: this section covers a few more aspects than the TL;DR and does things in
-a slightly different order. That's in your interest, to make sure you notice
-early if an issue that looks like a Linux kernel problem is actually caused by
-something else. These steps thus help to ensure the time you invest in this
-process won't feel wasted in the end:
-
- * Are you facing an issue with a Linux kernel a hardware or software vendor
- provided? Then in almost all cases you are better off to stop reading this
- document and reporting the issue to your vendor instead, unless you are
- willing to install the latest Linux version yourself. Be aware the latter
- will often be needed anyway to hunt down and fix issues.
-
- * Perform a rough search for existing reports with your favorite internet
- search engine; additionally, check the archives of the `Linux Kernel Mailing
- List (LKML) <https://lore.kernel.org/lkml/>`_. If you find matching reports,
- join the discussion instead of sending a new one.
-
- * See if the issue you are dealing with qualifies as regression, security
- issue, or a really severe problem: those are 'issues of high priority' that
- need special handling in some steps that are about to follow.
-
- * Make sure it's not the kernel's surroundings that are causing the issue
- you face.
-
- * Create a fresh backup and put system repair and restore tools at hand.
-
- * Ensure your system does not enhance its kernels by building additional
- kernel modules on-the-fly, which solutions like DKMS might be doing locally
- without your knowledge.
-
- * Check if your kernel was 'tainted' when the issue occurred, as the event
- that made the kernel set this flag might be causing the issue you face.
-
- * Write down coarsely how to reproduce the issue. If you deal with multiple
- issues at once, create separate notes for each of them and make sure they
- work independently on a freshly booted system. That's needed, as each issue
- needs to get reported to the kernel developers separately, unless they are
- strongly entangled.
-
- * If you are facing a regression within a stable or longterm version line
- (say something broke when updating from 5.10.4 to 5.10.5), scroll down to
- 'Dealing with regressions within a stable and longterm kernel line'.
-
- * Locate the driver or kernel subsystem that seems to be causing the issue.
- Find out how and where its developers expect reports. Note: most of the
- time this won't be bugzilla.kernel.org, as issues typically need to be sent
- by mail to a maintainer and a public mailing list.
-
- * Search the archives of the bug tracker or mailing list in question
- thoroughly for reports that might match your issue. If you find anything,
- join the discussion instead of sending a new report.
-
-After these preparations you'll now enter the main part:
-
- * Unless you are already running the latest 'mainline' Linux kernel, better
- go and install it for the reporting process. Testing and reporting with
- the latest 'stable' Linux can be an acceptable alternative in some
- situations; during the merge window that actually might be even the best
- approach, but in that development phase it can be an even better idea to
- suspend your efforts for a few days anyway. Whatever version you choose,
- ideally use a 'vanilla' build. Ignoring these advices will dramatically
- increase the risk your report will be rejected or ignored.
-
- * Ensure the kernel you just installed does not 'taint' itself when
- running.
-
- * Reproduce the issue with the kernel you just installed. If it doesn't show
- up there, scroll down to the instructions for issues only happening with
- stable and longterm kernels.
-
- * Optimize your notes: try to find and write the most straightforward way to
- reproduce your issue. Make sure the end result has all the important
- details, and at the same time is easy to read and understand for others
- that hear about it for the first time. And if you learned something in this
- process, consider searching again for existing reports about the issue.
-
- * If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider
- decoding the kernel log to find the line of code that triggered the error.
-
- * If your problem is a regression, try to narrow down when the issue was
- introduced as much as possible.
-
- * Start to compile the report by writing a detailed description about the
- issue. Always mention a few things: the latest kernel version you installed
- for reproducing, the Linux Distribution used, and your notes on how to
- reproduce the issue. Ideally, make the kernel's build configuration
- (.config) and the output from ``dmesg`` available somewhere on the net and
- link to it. Include or upload all other information that might be relevant,
- like the output/screenshot of an Oops or the output from ``lspci``. Once
- you wrote this main part, insert a normal length paragraph on top of it
- outlining the issue and the impact quickly. On top of this add one sentence
- that briefly describes the problem and gets people to read on. Now give the
- thing a descriptive title or subject that yet again is shorter. Then you're
- ready to send or file the report like the MAINTAINERS file told you, unless
- you are dealing with one of those 'issues of high priority': they need
- special care which is explained in 'Special handling for high priority
- issues' below.
-
- * Wait for reactions and keep the thing rolling until you can accept the
- outcome in one way or the other. Thus react publicly and in a timely manner
- to any inquiries. Test proposed fixes. Do proactive testing: retest with at
- least every first release candidate (RC) of a new mainline version and
- report your results. Send friendly reminders if things stall. And try to
- help yourself, if you don't get any help or if it's unsatisfying.
-
-
-Reporting regressions within a stable and longterm kernel line
---------------------------------------------------------------
-
-This subsection is for you, if you followed above process and got sent here at
-the point about regression within a stable or longterm kernel version line. You
-face one of those if something breaks when updating from 5.10.4 to 5.10.5 (a
-switch from 5.9.15 to 5.10.5 does not qualify). The developers want to fix such
-regressions as quickly as possible, hence there is a streamlined process to
-report them:
-
- * Check if the kernel developers still maintain the Linux kernel version
- line you care about: go to the `front page of kernel.org
- <https://kernel.org/>`_ and make sure it mentions
- the latest release of the particular version line without an '[EOL]' tag.
-
- * Check the archives of the `Linux stable mailing list
- <https://lore.kernel.org/stable/>`_ for existing reports.
-
- * Install the latest release from the particular version line as a vanilla
- kernel. Ensure this kernel is not tainted and still shows the problem, as
- the issue might have already been fixed there. If you first noticed the
- problem with a vendor kernel, check a vanilla build of the last version
- known to work performs fine as well.
-
- * Send a short problem report to the Linux stable mailing list
- (stable@vger.kernel.org) and CC the Linux regressions mailing list
- (regressions@lists.linux.dev); if you suspect the cause in a particular
- subsystem, CC its maintainer and its mailing list. Roughly describe the
- issue and ideally explain how to reproduce it. Mention the first version
- that shows the problem and the last version that's working fine. Then
- wait for further instructions.
-
-The reference section below explains each of these steps in more detail.
-
-
-Reporting issues only occurring in older kernel version lines
--------------------------------------------------------------
-
-This subsection is for you, if you tried the latest mainline kernel as outlined
-above, but failed to reproduce your issue there; at the same time you want to
-see the issue fixed in a still supported stable or longterm series or vendor
-kernels regularly rebased on those. If that the case, follow these steps:
-
- * Prepare yourself for the possibility that going through the next few steps
- might not get the issue solved in older releases: the fix might be too big
- or risky to get backported there.
-
- * Perform the first three steps in the section "Dealing with regressions
- within a stable and longterm kernel line" above.
-
- * Search the Linux kernel version control system for the change that fixed
- the issue in mainline, as its commit message might tell you if the fix is
- scheduled for backporting already. If you don't find anything that way,
- search the appropriate mailing lists for posts that discuss such an issue
- or peer-review possible fixes; then check the discussions if the fix was
- deemed unsuitable for backporting. If backporting was not considered at
- all, join the newest discussion, asking if it's in the cards.
-
- * One of the former steps should lead to a solution. If that doesn't work
- out, ask the maintainers for the subsystem that seems to be causing the
- issue for advice; CC the mailing list for the particular subsystem as well
- as the stable mailing list.
-
-The reference section below explains each of these steps in more detail.
+The detailed step-by-step guide on reporting Linux kernel issues
+================================================================
+
+The short guide above might be all needed for people already familiar
+with reporting issues to Free/Libre & Open Source Software projects. For
+everyone else there is this more detailed step-by-step guide. It still tries to
+be brief and leaves a lot of details occasionally relevant to a reference
+section, which holds additional information for almost all of the steps.
+
+Note: this step-by-step guide covers more aspects than the short guide above and
+does things in a slightly different order; that is done in the reader's interest,
+to make sure you notice early on when on the wrong track.
+
+* Be aware you must have or install a fresh vanilla mainline kernel for
+ reporting; you furthermore must remove any software that builds or relies on
+ externally developed kernel modules possibly installed. There is also a decent
+ chance you will have to build a patched kernel yourself to help resolve the
+ issue.
+
+ In case that sounds do demanding to you, better report the issue to the vendor
+ who built your kernel (usually your Linux distributor or hardware manufacturer).
+
+* Skim the output of ``journalctl -k`` for any indicators of problems that might
+ lead to your bug.
+
+* Check if the kernel was already 'tainted' when the issue first occurred: the
+ event that led to this flag being set might cause your issue, even if it looks
+ totally unrelated.
+
+* Consider some glitch in your kernel's environment makes it misbehave -- like
+ a hardware defect, a mis-configured system firmware, an overclocked component,
+ a broken initramfs, an inconsistent file system, broken firmware files,
+ a pre-release compiler, or a malfunctioning/misconfigured Linux distribution.
+
+* If you deal with multiple issues at once, process them separately from now on.
+ If there is even a small chance they are related, briefly mention the other
+ issues in each of the reports later, ideally while linking to the others.
+
+* Search for fixes and earlier reports referring to an issue like yours. Start
+ by checking `lore <https://lore.kernel.org/all/>`_. Then perform a general
+ internet search. Consult :ref:`MAINTAINERS <maintainers>` to determine where
+ developers of the affected code expect bugs to be submitted to; if in a doubt,
+ use your best guess to determine the driver or kernel subsystem. If its
+ developers have a dedicated mailing list not archived on lore, search its
+ archives; when they are among the few that uses one of
+ various bug trackers, search it as well. Note, bugzilla.kernel.org
+ is the right place to file bugs only for a small percentage of the kernel; if
+ you submit bugs for other code there it most likely will be ignored.
+
+ If you find fixes, try them. If you find matching reports, evaluate whatever
+ is wiser: joining the discussion or reporting the problem anew. In the latter
+ case mention and link to the related report you found; after you submit it,
+ add a note to the related report along the lines of 'I have a problem that
+ might be the same or related, for details see <link_to_your_report>'.
+
+* Are you facing a regression? One still occurring with a less than two
+ (ideally: one) weeks old kernel from the affected series? A kernel that is
+ vanilla or close to it? Then send a brief (one or two short paragraphs) email
+ to <regressions@lists.linux.dev> asking if the problem is known already.
+ Consider proceeding with this guide immediately to confine the problem and
+ report it properly; definitely do so, if you don't receive any helpful
+ answer within three days.
+
+* Evaluate if the issue you are dealing with qualifies as regression, security
+ issue, or a really severe problem: those need special handling in some of the
+ following steps.
+
+* Write down coarsely how to reproduce the issue on a freshly booted system.
+
+* Verify the bug and potentially bisect any regression as described in
+ Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst;
+ alternatively handle the tasks it covers on your own:
+
+ * Verify the bug occurs with an up-to-date kernel. For regressions within a
+ still supported stable or longterm series this means the latest release from
+ that series. In all other cases, this means a mainline release, pre-release, or
+ snapshot ideally less than one week old and two at maximum; the latest release
+ from the newest stable series might work as well, especially if the series
+ is based on a mainline version released in the past two weeks.
+
+ * In case of a regression, consider bisecting it. If it is one within a stable
+ or longterm series, you must verify if current mainline is affected as well.
+
+ * All kernels used for verifying and reporting bugs must be free of externally
+ developed modules (like Nvidia's graphics drivers, OpenZFS, or VirtualBox's
+ host drivers). The kernels also should be built from pristine (aka 'vanilla')
+ Linux sources, but lightly patched might work, too. The kernels furthermore
+ should not be 'tainted' when the issue occurs.
+
+ Note, don't skip this step or take its demands lightheartedly, as there is a
+ decent chance your report otherwise will be ignored or welcomed brusquely.
+
+* If you learned anything new about the bug while following this guide so far,
+ consider searching once more for earlier reports and fixes.
+
+* Were you unable to reproduce a bug with a current mainline kernel you want to
+ see fixed in a stable or longterm series? A bug that is not a regression? Then
+ move over to ‘Resolving non-regressions only occurring in stable or longterm
+ kernels’.
+
+* Optional: if your failure involves a 'panic', 'Oops', 'warning', or 'BUG',
+ ideally decode the included stack trace.
+
+* Prepare the report by writing a detailed description of the issue.
+
+ Always mention the Linux distribution and the kernel version used for the
+ verification; also include your notes on how to reproduce the issue. If your
+ failure involves a 'panic', 'Oops', 'warning', or 'BUG', include a copy or
+ photo of it.
+
+ Most of the time you also want to describe relevant aspects of your
+ environment, like the machine's model name, the relevant hardware components,
+ or the version of related userspace drivers. Often you want to also save the
+ output of ``journalctl -k`` to a file you later attach to your report or
+ upload somewhere and link to.
+
+ If there other aspects about the environment likely are relevant, attach or
+ upload & link detailed information about is as well, like the output from
+ commands as ``lsblk``, ``lspci``, ``lsusb.py`` and
+ ``grep -s '' /sys/class/dmi/id/*``.
+
+ If anything in the attached or linked files is certainly relevant, ensure
+ to copy that part to the body of the report to make it easily accessible.
+ Furthermore make sure to not overload the report with many or huge
+ attachments: developers will ask for additional data when needed.
+
+ Ensure both the subject and the first sentence of the report outlines the core
+ of the problem and gets people interested enough to read on.
+
+ When finished, review and optimize the report once more to make it as
+ straightforward as possible and the core of the problem easy to grasp.
+
+* Submit your report in the appropriate way, which depends on the outcome of the
+ verification:
+
+ * In case you deal with a security issue, follow the instructions in
+ Documentation/process/security-bugs.rst.
+
+ * Are you facing a regression within a stable or longterm kernel series you
+ were unable to reproduce with a fresh mainline kernel? Then report it by
+ email to the stable team while CCing the regressions lists (To:
+ Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
+ Sasha Levin <sashal@kernel.org>; CC: stable@vger.kernel.org,
+ regressions@lists.linux.dev).
+
+ * In all other cases, submit the report as specified in MAINTAINERS. In case
+ of a regression you have to report by mail, CC the regressions list
+ (regressions@lists.linux.dev); when you know the culprit, also CC everyone
+ in its 'Signed-off-by' chain. In case of a regression you had to file in a
+ bug tracker, write a short heads-up email with a link to the report to the
+ list and everyone that signed the patch off, if the culprit is known.
+
+ Did you send the brief inquiry about a regression mentioned earlier? Then in
+ both of these cases keep it involved: either send your report as a reply to
+ the earlier inquiry while adding relevant recipients or send a quick note
+ with a link to the proper report.
+
+* Wait for reactions and keep the ball rolling until you can accept the outcome
+ in one way or the other. That among others means:
+
+ * React publicly and in a timely manner to any inquiries.
+
+ * Try to quickly test proposed fixes.
+
+ * Perform proactive testing: retest with at least every first release
+ candidate (e.g. -rc1) of a new mainline version and report your findings in
+ a reply to your report.
+
+ * If things stall for more than three or four weeks, check if that happened
+ due to an inadequate report of yours; if not, send a friendly inquiry.
+
+ * Be aware that nobody is obliged to help you, unless it is a recent
+ regression, a security issue, or a really severe problem; hence try to help
+ yourself, if you don't receive any or only unsatisfying help.
+
+Resolving non-regressions only occurring in stable or longterm kernels
+----------------------------------------------------------------------
+
+Are you facing an issue in a still supported stable or longterm series you were
+unable to reproduce with a fresh mainline kernel? An issue that is also not a
+regression and still happens in the series latest release? In that case follow
+these steps:
+
+* Prepare yourself for the possibility that trying to resolve the issue resolved
+ in the affected stable or longterm series might not work out: the fix might be
+ too big or risky to include there.
+
+* Search Linux' mainline Git repository or lore for the change that resolved the
+ issue; when unsuccessful, consider using a bisection to find it. Then check
+ the description of the fix for a 'stable tag', e.g, a line like
+ 'Cc: <stable@vger.kernel.org>':
+
+ * In case there is such a tag the change is already scheduled for backporting.
+ Usually it will be picked up within two or three weeks after being merged to
+ mainline. Note, a version number after the tag might limit backporting to a
+ series that is newer than the one you care for; plans to backport a change
+ sometimes are also discarded. In such cases search lore or contact the
+ involved developers for details, but you likely are out of luck.
+
+ * If there was no stable tag, search the mailing list archives if backporting
+ nevertheless is in the works. If not, search for the review of the fix and
+ check if backporting to stable and longterm kernels is planned or was
+ rejected. If it's neither, send a reply asking the developers if backporting
+ to the series is an option. Note, they might greenlight it, but unwilling to
+ handle the job themselves -- in that case consider testing and submitting the
+ fix and everything it depends on as explained in
+ Documentation/process/stable-kernel-rules.rst.
+
+ In case you have trouble locating the fix or the discussion about it, consider
+ asking the maintainers and developers of the affected subsystem for advice.
Reference section: Reporting issues to the kernel maintainers
--
2.44.0
^ permalink raw reply related [relevance 10%]
* [ANNOUNCE] NVDIMM development move to nvdimm@lists.linux.dev
@ 2021-04-20 20:34 10% Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2021-04-20 20:34 UTC (permalink / raw)
To: linux-nvdimm
There have been multiple occasions recently where people reported
trouble managing their subscription to linux-nvdimm@lists.01.org. The
spam filtering also appears less robust compared to other Linux
development lists.
There are also side benefits to being on kernel.org infrastructure as
it has a direct path to inject messages into the public-inbox
repository on lore, and feed the patchwork-bot.
You can find the subscription link here:
https://subspace.kernel.org/lists.linux.dev.html
For the v5.13 merge window I'll submit a patch to switch the list from
linux-nvdimm@lists.01.org to nvdimm@lists.linux.dev, and plan to
shutdown linux-nvdimm@ a couple months later around the v5.14 merge
window.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply [relevance 10%]
* + docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch added to mm-unstable branch
@ 2024-01-30 6:45 10% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-01-30 6:45 UTC (permalink / raw)
To: mm-commits, siyanteng, shuah, corbet, alexs, 2023002089, sj, akpm
The patch titled
Subject: Docs/admin-guide/mm/damon/usage: document 'DEPRECATED' file of DAMON debugfs interface
has been added to the -mm mm-unstable branch. Its filename is
docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: Docs/admin-guide/mm/damon/usage: document 'DEPRECATED' file of DAMON debugfs interface
Date: Mon, 29 Jan 2024 17:35:44 -0800
Document the newly added DAMON debugfs interface deprecation notice file
on the usage document.
Link: https://lkml.kernel.org/r/20240130013549.89538-6-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Alex Shi <alexs@kernel.org>
Cc: Hu Haowen <2023002089@link.tyut.edu.cn>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/Documentation/admin-guide/mm/damon/usage.rst~docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface
+++ a/Documentation/admin-guide/mm/damon/usage.rst
@@ -628,9 +628,16 @@ debugfs Interface (DEPRECATED!)
move, please report your usecase to damon@lists.linux.dev and
linux-mm@kvack.org.
-DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
-``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
-``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
+DAMON exports nine files, ``DEPRECATED``, ``attrs``, ``target_ids``,
+``init_regions``, ``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts``
+and ``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
+
+
+``DEPRECATED`` is a read-only file for the DAMON debugfs interface deprecation
+notice. Reading it returns the deprecation notice, as below::
+
+ # cat DEPRECATED
+ DAMON debugfs interface is deprecated, so users should move to DAMON_SYSFS. If you cannot, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.
Attributes
_
Patches currently in -mm which might be from sj@kernel.org are
docs-admin-guide-mm-damon-usage-use-sysfs-interface-for-tracepoints-example.patch
mm-damon-rename-config_damon_dbgfs-to-damon_dbgfs_deprecated.patch
mm-damon-dbgfs-implement-deprecation-notice-file.patch
mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch
docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch
selftets-damon-prepare-for-monitor_on-file-renaming.patch
mm-damon-dbgfs-rename-monitor_on-file-to-monitor_on_deprecated.patch
docs-admin-guide-mm-damon-usage-update-for-monitor_on-renaming.patch
docs-translations-damon-usage-update-for-monitor_on-renaming.patch
^ permalink raw reply [relevance 10%]
* Patch "MAINTAINERS: move the staging subsystem to lists.linux.dev" has been added to the 5.10-stable tree
@ 2021-03-22 9:57 10% gregkh
0 siblings, 0 replies; 200+ results
From: gregkh @ 2021-03-22 9:57 UTC (permalink / raw)
To: gregkh, linux-staging, mchehab+huawei; +Cc: stable-commits
This is a note to let you know that I've just added the patch titled
MAINTAINERS: move the staging subsystem to lists.linux.dev
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From e06da9ea3e3f6746a849edeae1d09ee821f5c2ce Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Tue, 16 Mar 2021 11:23:11 +0100
Subject: MAINTAINERS: move the staging subsystem to lists.linux.dev
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e06da9ea3e3f6746a849edeae1d09ee821f5c2ce upstream.
The drivers/staging/ tree has a new mailing list,
linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
it so that we get patches sent to the proper place.
There was no need to specify a list for the hikey9xx driver, the tools
pick up the "base" list for drivers/staging/* so remove that line to
make the file simpler.
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8001,7 +8001,6 @@ F: drivers/crypto/hisilicon/sec2/sec_mai
HISILICON STAGING DRIVERS FOR HIKEY 960/970
M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-L: devel@driverdev.osuosl.org
S: Maintained
F: drivers/staging/hikey9xx/
@@ -16665,7 +16664,7 @@ F: drivers/staging/vt665?/
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: devel@driverdev.osuosl.org
+L: linux-staging@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
F: drivers/staging/
Patches currently in stable-queue which might be from gregkh@linuxfoundation.org are
queue-5.10/iio-adc-ad7949-fix-wrong-adc-result-due-to-incorrect-bit-mask.patch
queue-5.10/genirq-disable-interrupts-for-force-threaded-handlers.patch
queue-5.10/iio-hid-sensor-temperature-fix-issues-of-timestamp-channel.patch
queue-5.10/ext4-fix-error-handling-in-ext4_end_enable_verity.patch
queue-5.10/nfsd-don-t-abort-copies-early.patch
queue-5.10/s390-pci-fix-leak-of-pci-device-structure.patch
queue-5.10/nvme-tcp-fix-a-null-deref-when-receiving-a-0-length-r2t-pdu.patch
queue-5.10/kernel-fs-introduce-and-use-set_restart_fn-and-arch_set_restart_data.patch
queue-5.10/static_call-fix-static_call_update-sanity-check.patch
queue-5.10/cifs-fix-allocation-size-on-newly-created-files.patch
queue-5.10/usb-storage-add-quirk-to-defeat-kindle-s-automatic-unload.patch
queue-5.10/afs-stop-listxattr-from-listing-afs.-attributes.patch
queue-5.10/serial-stm32-fix-dma-initialization-error-handling.patch
queue-5.10/nvme-fix-write-zeroes-limitations.patch
queue-5.10/asoc-intel-bytcr_rt5640-fix-hp-pavilion-x2-10-p0xx-ovcd-current-threshold.patch
queue-5.10/afs-fix-accessing-yfs-xattrs-on-a-non-yfs-server.patch
queue-5.10/ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch
queue-5.10/iio-adc-stm32-adc-add-has_iomem-dependency.patch
queue-5.10/alsa-hda-realtek-apply-headset-mic-quirks-for-xiaomi-redmibook-air.patch
queue-5.10/nvme-tcp-fix-possible-hang-when-failing-to-set-io-queues.patch
queue-5.10/net-qrtr-fix-__netdev_alloc_skb-call.patch
queue-5.10/btrfs-fix-slab-cache-flags-for-free-space-tree-bitmap.patch
queue-5.10/thunderbolt-increase-runtime-pm-reference-count-on-dp-tunnel-discovery.patch
queue-5.10/iio-gyro-mpu3050-fix-error-handling-in-mpu3050_trigger_handler.patch
queue-5.10/alsa-dice-fix-null-pointer-dereference-when-node-is-disconnected.patch
queue-5.10/alsa-hda-realtek-apply-pin-quirk-for-xiaominotebook-pro.patch
queue-5.10/usb-typec-remove-vdo-part-of-tps6598x_rx_identity_reg-struct.patch
queue-5.10/sunrpc-fix-refcount-leak-for-rpc-auth-modules.patch
queue-5.10/maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch
queue-5.10/nvme-tcp-fix-misuse-of-__smp_processor_id-with-preemption-enabled.patch
queue-5.10/io_uring-ensure-that-sqpoll-thread-is-started-for-exit.patch
queue-5.10/asoc-codecs-wcd934x-add-a-sanity-check-in-set-channel-map.patch
queue-5.10/nfsd-fix-dest-to-src-mount-in-inter-server-copy.patch
queue-5.10/powerpc-force-inlining-of-cpu_has_feature-to-avoid-build-failure.patch
queue-5.10/btrfs-fix-race-when-cloning-extent-buffer-during-rewind-of-an-old-root.patch
queue-5.10/asoc-simple-card-utils-do-not-handle-device-clock.patch
queue-5.10/perf-x86-intel-fix-a-crash-caused-by-zero-pebs-status.patch
queue-5.10/nvmet-don-t-check-iosqes-iocqes-for-discovery-controllers.patch
queue-5.10/ext4-fix-rename-whiteout-with-fast-commit.patch
queue-5.10/usbip-fix-incorrect-double-assignment-to-udc-ud.tcp_rx.patch
queue-5.10/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-840-g8.patch
queue-5.10/drm-amd-display-correct-algorithm-for-reversed-gamma.patch
queue-5.10/thunderbolt-initialize-hopid-idas-in-tb_switch_alloc.patch
queue-5.10/maintainers-move-some-real-subsystems-off-of-the-staging-mailing-list.patch
queue-5.10/ext4-fix-potential-error-in-ext4_do_update_inode.patch
queue-5.10/iio-adis16400-fix-an-error-code-in-adis16400_initial_setup.patch
queue-5.10/asoc-ak5558-add-module_device_table.patch
queue-5.10/iio-adc-adi-axi-adc-add-proper-kconfig-dependencies.patch
queue-5.10/zonefs-fix-o_append-async-write-handling.patch
queue-5.10/x86-introduce-ts_compat_restart-to-fix-get_nr_restart_syscall.patch
queue-5.10/scsi-ufs-ufs-mediatek-correct-operator.patch
queue-5.10/x86-ioapic-ignore-irq2-again.patch
queue-5.10/nfsd-repair-misuse-of-sv_lock-in-5.10.16-rt30.patch
queue-5.10/counter-stm32-timer-cnt-fix-ceiling-write-max-value.patch
queue-5.10/iio-hid-sensor-prox-fix-scale-not-correct-issue.patch
queue-5.10/asoc-sof-intel-unregister-dmic-device-on-probe-error.patch
queue-5.10/pstore-fix-warning-in-pstore_kill_sb.patch
queue-5.10/s390-pci-remove-superfluous-zdev-zbus-check.patch
queue-5.10/asoc-fsl_ssi-fix-tdm-slot-setup-for-i2s-mode.patch
queue-5.10/zonefs-fix-to-update-.i_wr_refcnt-correctly-in-zonefs_open_zone.patch
queue-5.10/ext4-stop-inode-update-before-return.patch
queue-5.10/iio-adc-qcom-spmi-vadc-add-default-scale-to-lr_mux2_bat_id-channel.patch
queue-5.10/asoc-sof-intel-fix-wrong-poll-bits-in-dsp-power-down.patch
queue-5.10/zonefs-prevent-use-of-seq-files-as-swap-file.patch
queue-5.10/vhost-vdpa-set-v-config_ctx-to-null-if-eventfd_ctx_fdget-fails.patch
queue-5.10/iio-adc-ab8500-gpadc-fix-off-by-10-to-3.patch
queue-5.10/usb-gadget-configfs-fix-kasan-use-after-free.patch
queue-5.10/asoc-qcom-sdm845-fix-array-out-of-range-on-rx-slim-channels.patch
queue-5.10/asoc-qcom-lpass-cpu-fix-lpass-dai-ids-parse.patch
queue-5.10/vhost-vdpa-fix-use-after-free-of-v-config_ctx.patch
queue-5.10/perf-x86-intel-fix-unchecked-msr-access-error-caused-by-vlbr_event.patch
queue-5.10/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-850-g8.patch
queue-5.10/usb-typec-tcpm-invoke-power_supply_changed-for-tcpm-source-psy.patch
queue-5.10/alsa-usb-audio-fix-unintentional-sign-extension-issue.patch
queue-5.10/iio-hid-sensor-humidity-fix-alignment-issue-of-timestamp-channel.patch
queue-5.10/vfio-iommu_api-should-be-selected.patch
queue-5.10/kbuild-fix-linux-version.h-for-empty-sublevel-or-patchlevel-again.patch
queue-5.10/revert-pm-runtime-update-device-status-before-letting-suppliers-suspend.patch
queue-5.10/i915-perf-start-hrtimer-only-if-sampling-the-oa-buffer.patch
queue-5.10/efi-use-32-bit-alignment-for-efi_guid_t-literals.patch
queue-5.10/x86-move-ts_compat-back-to-asm-thread_info.h.patch
queue-5.10/svcrdma-disable-timeouts-on-rdma-backchannel.patch
queue-5.10/asoc-ak4458-add-module_device_table.patch
queue-5.10/tty-serial-stm32-usart-remove-set-but-unused-cookie-.patch
queue-5.10/counter-stm32-timer-cnt-fix-ceiling-miss-alignment-with-reload-register.patch
queue-5.10/s390-pci-refactor-zpci_create_device.patch
queue-5.10/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-440-g8.patch
queue-5.10/scsi-myrs-fix-a-double-free-in-myrs_cleanup.patch
queue-5.10/nfsd-don-t-keep-looking-up-unhashed-files-in-the-nfsd-file-cache.patch
queue-5.10/x86-apic-of-fix-cpu-devicetree-node-lookups.patch
queue-5.10/scsi-lpfc-fix-some-error-codes-in-debugfs.patch
queue-5.10/asoc-qcom-sdm845-fix-array-out-of-bounds-access.patch
queue-5.10/spi-cadence-set-cqspi-to-the-driver_data-field-of-struct-device.patch
queue-5.10/efivars-respect-efi_unsupported-return-from-firmware.patch
queue-5.10/pci-rpadlpar-fix-potential-drc_name-corruption-in-store-functions.patch
queue-5.10/usb-dwc3-gadget-prevent-ep-queuing-while-stopping-transfers.patch
queue-5.10/firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch
queue-5.10/usb-dwc3-gadget-allow-runtime-suspend-if-udc-unbinded.patch
queue-5.10/s390-vtime-fix-increased-steal-time-accounting.patch
queue-5.10/vhost_vdpa-fix-the-missing-irq_bypass_unregister_producer-invocation.patch
queue-5.10/ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch
queue-5.10/riscv-correct-sparsemem-configuration.patch
queue-5.10/risc-v-correct-enum-sbi_ext_rfence_fid.patch
queue-5.10/alsa-hda-generic-fix-the-micmute-led-init-state.patch
^ permalink raw reply [relevance 10%]
* Re: Post to linux-staging@lists.linux.dev denied: [PATCH] staging: rtl8723bs: os_dep: remove unused variable
[not found] <1628081824-28535-mlmmj-16bf2009@lists.linux.dev>
@ 2021-08-04 13:45 10% ` SAURAV GIREPUNJE
0 siblings, 0 replies; 200+ results
From: SAURAV GIREPUNJE @ 2021-08-04 13:45 UTC (permalink / raw)
To: gregkh, fabioaiuto83, saurav.girepunje, marcocesati,
ross.schm.dev, insafonov, linux-staging
Cc: saurav.girepunje
On Wed, Aug 04, 2021 at 12:57:04PM +0000, linux-staging+owner@lists.linux.dev wrote:
> Greetings!
>
> This is the mlmmj program managing the <linux-staging@lists.linux.dev>
> mailing list.
>
> The message from <saurav.girepunje@gmail.com> with subject "[PATCH]
> staging: rtl8723bs: os_dep: remove unused variable" was unable to be
> delivered to the list because the list address was not found in either the
> To: or CC: header.
>
> (The denied message is below.)
> Date: Wed, 4 Aug 2021 18:26:57 +0530
> From: Saurav Girepunje <saurav.girepunje@gmail.com>
> To: gregkh@linuxfoundation.org;, fabioaiuto83@gmail.com;,
> saurav.girepunje@gmail.com;, marcocesati@gmail.com;,
> ross.schm.dev@gmail.com;, insafonov@gmail.com;,
> linux-staging@lists.linux.dev;, linux-kernel@vger.kernel.org;
> Cc: saurav.girepunje@hotmail.com
> Subject: [PATCH] staging: rtl8723bs: os_dep: remove unused variable
>
> Remove below unused static variable from os_intfs.c
> rtw_enusbss
> rtw_hwpdn_mode
> rtw_hwpwrp_detect
>
> Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
> ---
> drivers/staging/rtl8723bs/os_dep/os_intfs.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/os_intfs.c b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
> index 724909078d80..71c9e7eec206 100644
> --- a/drivers/staging/rtl8723bs/os_dep/os_intfs.c
> +++ b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
> @@ -109,11 +109,6 @@ static int rtw_antdiv_cfg = 1; /* 0:OFF , 1:ON, 2:decide by Efuse config */
> static int rtw_antdiv_type; /* 0:decide by efuse 1: for 88EE, 1Tx and 1RxCG are diversity.(2 Ant with SPDT), 2: for 88EE, 1Tx and 2Rx are diversity.(2 Ant, Tx and RxCG are both on aux port, RxCS is on main port), 3: for 88EE, 1Tx and 1RxCG are fixed.(1Ant, Tx and RxCG are both on aux port) */
>
>
> -static int rtw_enusbss;/* 0:disable, 1:enable */
> -
> -static int rtw_hwpdn_mode = 2;/* 0:disable, 1:enable, 2: by EFUSE config */
> -
> -static int rtw_hwpwrp_detect; /* HW power ping detect 0:disable , 1:enable */
>
> static int rtw_hw_wps_pbc;
>
> @@ -159,9 +154,6 @@ module_param(rtw_wifi_spec, int, 0644);
> module_param(rtw_antdiv_cfg, int, 0644);
> module_param(rtw_antdiv_type, int, 0644);
>
> -module_param(rtw_enusbss, int, 0644);
> -module_param(rtw_hwpdn_mode, int, 0644);
> -module_param(rtw_hwpwrp_detect, int, 0644);
>
> module_param(rtw_hw_wps_pbc, int, 0644);
>
> --
> 2.30.2
Hi,
My mails are not getting deliverd due to below reason
"unable to be delivered to the list because the list address was not
found in either the To: or CC: header."
However linux-staging@lists.linux.dev is in my To header.
Is anyone highlight what I am doing wrong.
saurav
^ permalink raw reply [relevance 10%]
* [merged mm-stable] dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch removed from -mm tree
@ 2024-02-22 0:01 10% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-02-22 0:01 UTC (permalink / raw)
To: mm-commits, ying.huang, willy, osalvador, mhocko, lizhijian,
Jonathan.Cameron, gregkh, david, dave.jiang, dave.hansen,
dan.j.williams, alison.schofield, vishal.l.verma, akpm
The quilt patch titled
Subject: dax: add a sysfs knob to control memmap_on_memory behavior
has been removed from the -mm tree. Its filename was
dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Vishal Verma <vishal.l.verma@intel.com>
Subject: dax: add a sysfs knob to control memmap_on_memory behavior
Date: Wed, 24 Jan 2024 12:03:50 -0800
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via pmem
or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above defaults
if needed.
Link: https://lkml.kernel.org/r/20240124-vv-dax_abi-v7-5-20d16cb8d23d@intel.com
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Huang, Ying <ying.huang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/testing/sysfs-bus-dax | 17 ++++++++
drivers/dax/bus.c | 43 ++++++++++++++++++++++
2 files changed, 60 insertions(+)
--- a/Documentation/ABI/testing/sysfs-bus-dax~dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior
+++ a/Documentation/ABI/testing/sysfs-bus-dax
@@ -134,3 +134,20 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: January, 2024
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
--- a/drivers/dax/bus.c~dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior
+++ a/drivers/dax/bus.c
@@ -1349,6 +1349,48 @@ static ssize_t numa_node_show(struct dev
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sysfs_emit(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ bool val;
+ int rc;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (val == true && !mhp_supports_memmap_on_memory()) {
+ dev_dbg(dev, "memmap_on_memory is not available\n");
+ return -EOPNOTSUPP;
+ }
+
+ rc = down_write_killable(&dax_dev_rwsem);
+ if (rc)
+ return rc;
+
+ if (dev_dax->memmap_on_memory != val && dev->driver &&
+ to_dax_drv(dev->driver)->type == DAXDRV_KMEM_TYPE) {
+ up_write(&dax_dev_rwsem);
+ return -EBUSY;
+ }
+
+ dev_dax->memmap_on_memory = val;
+ up_write(&dax_dev_rwsem);
+
+ return len;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1375,6 +1417,7 @@ static struct attribute *dev_dax_attribu
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
_
Patches currently in -mm which might be from vishal.l.verma@intel.com are
^ permalink raw reply [relevance 10%]
* [RFC PATCH v2 5/6] PCI/TSM: Authenticate devices via platform TSM
@ 2024-04-12 8:52 10% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2024-04-12 8:52 UTC (permalink / raw)
To: linux-coco
Cc: Wu Hao, Yilun Xu, Lukas Wunner, Samuel Ortiz,
Alexey Kardashevskiy, Bjorn Helgaas, Xu Yilun, bhelgaas,
kevin.tian, gregkh, linux-pci, lukas
The PCIe 6.1 specification, section 11, introduces the Trusted Execution
Environment (TEE) Device Interface Security Protocol (TDISP). This
interface definition builds upon Component Measurement and
Authentication (CMA), and link Integrity and Data Encryption (IDE). It
adds support for assigning devices (PCI physical or virtual function) to
a confidential VM such that the assigned device is enabled to access
guest private memory protected by technologies like Intel TDX, AMD
SEV-SNP, RISCV COVE, or ARM CCA.
The "TSM" (TEE Security Manager) is a concept in the TDISP specification
of an agent that mediates between a "DSM" (Device Security Manager) and
system software in both a VMM and a confidential VM. A VMM uses TSM ABIs
to setup link security and assign devices. A confidential VM uses TSM
ABIs to transition an assigned device into the TDISP "RUN" state and
validate its configuration. From a Linux perspective the TSM abstracts
many of the details of TDISP, IDE, and CMA. Some of those details leak
through at times, but for the most part TDISP is an internal
implementation detail of the TSM.
Similar to the PCI core extensions to support CONFIG_PCI_CMA,
CONFIG_PCI_TSM builds upon that to reuse the "authenticated" sysfs
attribute, and add more properties + controls in a tsm/ subdirectory of
the PCI device sysfs interface. Unlike CMA that can depend on a local to
the PCI core implementation, PCI_TSM needs to be prepared for late
loading of the platform TSM driver. Consider that the TSM driver may
itself be a PCI driver. Userspace can depend on the common TSM device
uevent to know when the PCI core has TSM services enabled. The PCI
device tsm/ subdirectory is supplemented by the TSM device pci/
directory for platform global TSM properties + controls.
The common verbs that the low-level TSM drivers implement are defined by
'enum pci_tsm_cmd'. For now only connect and disconnect are defined for
establishing a trust relationship between the host and the device,
securing the interconnect (optionally establishing IDE), and tearing
that down.
The locking allows for multiple devices to be executing commands
simultaneously, one outstanding command per-device and an rwsem flushes
all inflight commands when a TSM low-level driver/device is removed.
In addition to commands submitted through an 'exec' operation the
low-level TSM driver is notified of device arrival and departure events
via 'add' and 'del' operations. With those it can setup per-device
context, or filter devices that the TSM is not prepared to support.
Cc: Wu Hao <hao.wu@intel.com>
Cc: Yilun Xu <yilun.xu@intel.com>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Samuel Ortiz <sameo@rivosinc.com>
Cc: Alexey Kardashevskiy <aik@amd.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Co-developed-by: Xu Yilun <yilun.xu@linux.intel.com>
Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/testing/sysfs-bus-pci | 46 +++++
MAINTAINERS | 2
drivers/pci/Kconfig | 13 +
drivers/pci/Makefile | 2
drivers/pci/pci-sysfs.c | 4
drivers/pci/pci.h | 10 +
drivers/pci/probe.c | 1
drivers/pci/remove.c | 1
drivers/pci/tsm.c | 270 +++++++++++++++++++++++++++++++
drivers/virt/coco/host/tsm-core.c | 22 ++-
include/linux/pci-tsm.h | 80 +++++++++
include/linux/pci.h | 11 +
include/linux/tsm.h | 4
include/uapi/linux/pci_regs.h | 4
14 files changed, 466 insertions(+), 4 deletions(-)
create mode 100644 drivers/pci/tsm.c
create mode 100644 include/linux/pci-tsm.h
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index ecf47559f495..4ae50621e65b 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -500,3 +500,49 @@ Description:
console drivers from the device. Raw users of pci-sysfs
resourceN attributes must be terminated prior to resizing.
Success of the resizing operation is not guaranteed.
+
+What: /sys/bus/pci/devices/.../authenticated
+Date: March 2024
+Contact: linux-pci@vger.kernel.org
+Description:
+ This file contains 1 if the device authenticated successfully.
+ It contains 0 if the device failed authentication (and may thus
+ be malicious). There are 2 potential authentication methods:
+ native PCI CMA (Component Measurement and Authentication) and
+ PCI TSM (TEE Security Manager). In the PCI TSM case the device's
+ PCI CMA interface is subsumed by the TSM driver. A TSM
+ implementation uses its own private certificate store + keys to
+ authenticate the device. Without a TSM the kernel can
+ authenticate using its own certificate chain.
+
+ In the TSM case, "authenticated" is read-only (0444) and the
+ "tsm/connect" attribute reflects whether the device is TSM
+ "connected" which includes not only CMA authentication, but
+ optionally IDE (link Integrity and Data encryption) if the TSM
+ deems that is necessary. When the device is disconnected from
+ the TSM the kernel may attempt authentication with its own
+ certificate chain. See
+ Documentation/ABI/testing/sysfs-devices-spdm.
+
+ The file is not visible if authentication is unsupported by the
+ device, or if PCI CMA support is disabled and the TSM
+ driver has no available authentication methods for the device.
+
+What: /sys/bus/pci/devices/.../tsm/
+Date: March 2024
+Contact: linux-coco@lists.linux.dev
+Description:
+ This directory only appears if a device supports CMA and IDE,
+ and only after a TSM driver has loaded and evaluated this
+ PCI device. All present devices shall be dispositioned
+ after the 'add' event for /sys/class/tsm/tsm0 triggers.
+
+What: /sys/bus/pci/devices/.../tsm/connect
+Date: March 2024
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RW) Writing "1" to this file triggers the TSM to establish a
+ connection with the device. This typically includes an SPDM
+ (DMTF Security Protocols and Data Models) session over PCIe DOE
+ (Data Object Exchange) and may also include PCIe IDE (Integrity
+ and Data Encryption) establishment.
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bcd9d43ac..0e1d995e7a16 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22466,8 +22466,10 @@ M: Dan Williams <dan.j.williams@intel.com>
L: linux-coco@lists.linux.dev
S: Maintained
F: Documentation/ABI/testing/configfs-tsm
+F: drivers/pci/tsm.c
F: drivers/virt/coco/guest/tsm_report.c
F: drivers/virt/coco/host/
+F: include/linux/pci-tsm.h
F: include/linux/tsm.h
TTY LAYER AND SERIAL DRIVERS
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index d35001589d88..cd863c5e49ca 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -121,6 +121,19 @@ config XEN_PCIDEV_FRONTEND
config PCI_ATS
bool
+config PCI_TSM
+ bool "TEE Security Manager for PCI Device Security"
+ help
+ The TEE (Trusted Execution Environment) Device Interface
+ Security Protocol (TDISP) defines a "TSM" as a platform agent
+ that manages device authentication, link encryption, link
+ integrity protection, and assignment of PCI device functions
+ (virtual or physical) to confidential computing VMs that can
+ access (DMA) guest private memory.
+
+ Enable a platform TSM driver to use this capability.
+
+
config PCI_DOE
bool
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 175302036890..b9884a669c5f 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -35,6 +35,8 @@ obj-$(CONFIG_VGA_ARB) += vgaarb.o
obj-$(CONFIG_PCI_DOE) += doe.o
obj-$(CONFIG_PCI_DYNAMIC_OF_NODES) += of_property.o
+obj-$(CONFIG_PCI_TSM) += tsm.o
+
# Endpoint library must be initialized before its users
obj-$(CONFIG_PCI_ENDPOINT) += endpoint/
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 40cfa716392f..c6ea624dd76c 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1661,6 +1661,10 @@ const struct attribute_group *pci_dev_attr_groups[] = {
#endif
#ifdef CONFIG_PCIEASPM
&aspm_ctrl_attr_group,
+#endif
+#ifdef CONFIG_PCI_TSM
+ &pci_tsm_auth_attr_group,
+ &pci_tsm_attr_group,
#endif
NULL,
};
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 17fed1846847..9b864cbf8682 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -335,6 +335,16 @@ static inline void pci_doe_destroy(struct pci_dev *pdev) { }
static inline void pci_doe_disconnected(struct pci_dev *pdev) { }
#endif
+#ifdef CONFIG_PCI_TSM
+void pci_tsm_init(struct pci_dev *pdev);
+void pci_tsm_destroy(struct pci_dev *pdev);
+extern const struct attribute_group pci_tsm_attr_group;
+extern const struct attribute_group pci_tsm_auth_attr_group;
+#else
+static inline void pci_tsm_init(struct pci_dev *pdev) { }
+static inline void pci_tsm_destroy(struct pci_dev *pdev) { }
+#endif
+
/**
* pci_dev_set_io_state - Set the new error state if possible.
*
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 1325fbae2f28..d89b67541d02 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2481,6 +2481,7 @@ static void pci_init_capabilities(struct pci_dev *dev)
pci_dpc_init(dev); /* Downstream Port Containment */
pci_rcec_init(dev); /* Root Complex Event Collector */
pci_doe_init(dev); /* Data Object Exchange */
+ pci_tsm_init(dev); /* TEE Security Manager connection */
pcie_report_downtraining(dev);
pci_init_reset_methods(dev);
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index d749ea8250d6..d94b2458934a 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -39,6 +39,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
list_del(&dev->bus_list);
up_write(&pci_bus_sem);
+ pci_tsm_destroy(dev);
pci_doe_destroy(dev);
pcie_aspm_exit_link_state(dev);
pci_bridge_d3_update(dev);
diff --git a/drivers/pci/tsm.c b/drivers/pci/tsm.c
new file mode 100644
index 000000000000..9c5fb2c46662
--- /dev/null
+++ b/drivers/pci/tsm.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TEE Security Manager for the TEE Device Interface Security Protocol
+ * (TDISP, PCIe r6.1 sec 11)
+ *
+ * Copyright(c) 2024 Intel Corporation. All rights reserved.
+ */
+
+#define dev_fmt(fmt) "TSM: " fmt
+
+#include <linux/pci.h>
+#include <linux/pci-doe.h>
+#include <linux/sysfs.h>
+#include <linux/xarray.h>
+#include <linux/pci-tsm.h>
+#include <linux/bitfield.h>
+#include "pci.h"
+
+/* collect TSM capable devices to rendezvous with the tsm driver */
+static DEFINE_XARRAY(pci_tsm_devs);
+
+/*
+ * Provide a read/write lock against the init / exit of pdev tsm
+ * capabilities and arrival/departure of a tsm instance
+ */
+static DECLARE_RWSEM(pci_tsm_rwsem);
+static const struct pci_tsm_ops *tsm_ops;
+
+static int pci_tsm_disconnect(struct pci_dev *pdev)
+{
+ struct pci_tsm *pci_tsm = pdev->tsm;
+
+ lockdep_assert_held_read(&pci_tsm_rwsem);
+ scoped_cond_guard(mutex_intr, return -EINTR, &pci_tsm->exec_lock) {
+ int rc;
+
+ if (pci_tsm->state < PCI_TSM_CONNECT)
+ return 0;
+ if (pci_tsm->state < PCI_TSM_INIT)
+ return -ENXIO;
+
+ rc = tsm_ops->exec(pdev, TSM_EXEC_DISCONNECT);
+ if (rc)
+ return rc;
+ pci_tsm->state = PCI_TSM_INIT;
+ }
+ return 0;
+}
+
+static int pci_tsm_connect(struct pci_dev *pdev)
+{
+ struct pci_tsm *pci_tsm = pdev->tsm;
+
+ lockdep_assert_held_read(&pci_tsm_rwsem);
+ scoped_cond_guard(mutex_intr, return -EINTR, &pci_tsm->exec_lock) {
+ int rc;
+
+ if (pci_tsm->state >= PCI_TSM_CONNECT)
+ return 0;
+ if (pci_tsm->state < PCI_TSM_INIT)
+ return -ENXIO;
+
+ rc = tsm_ops->exec(pdev, TSM_EXEC_CONNECT);
+ if (rc)
+ return rc;
+ pci_tsm->state = PCI_TSM_CONNECT;
+ }
+ return 0;
+}
+
+static ssize_t connect_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ int rc;
+ bool connect;
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ rc = kstrtobool(buf, &connect);
+ if (rc)
+ return rc;
+
+ if (connect)
+ rc = pci_tsm_connect(pdev);
+ else
+ rc = pci_tsm_disconnect(pdev);
+ if (rc)
+ return rc;
+ return len;
+}
+
+static ssize_t connect_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ return sysfs_emit(buf, "%d\n", pdev->tsm->state >= PCI_TSM_CONNECT);
+}
+static DEVICE_ATTR_RW(connect);
+
+static bool pci_tsm_group_visible(struct kobject *kobj)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (pdev->tsm && pdev->tsm->state > PCI_TSM_IDLE)
+ return true;
+ return false;
+}
+DEFINE_SIMPLE_SYSFS_GROUP_VISIBLE(pci_tsm);
+
+static struct attribute *pci_tsm_attrs[] = {
+ &dev_attr_connect.attr,
+ NULL,
+};
+
+const struct attribute_group pci_tsm_attr_group = {
+ .name = "tsm",
+ .attrs = pci_tsm_attrs,
+ .is_visible = SYSFS_GROUP_VISIBLE(pci_tsm),
+};
+
+static ssize_t authenticated_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ /*
+ * When device authentication is TSM owned, 'authenticated' is
+ * identical to the connect state.
+ */
+ return connect_show(dev, attr, buf);
+}
+static DEVICE_ATTR_RO(authenticated);
+
+static struct attribute *pci_tsm_auth_attrs[] = {
+ &dev_attr_authenticated.attr,
+ NULL,
+};
+
+const struct attribute_group pci_tsm_auth_attr_group = {
+ .attrs = pci_tsm_auth_attrs,
+ .is_visible = SYSFS_GROUP_VISIBLE(pci_tsm),
+};
+
+static int pci_tsm_add(struct pci_dev *pdev)
+{
+ struct pci_tsm *pci_tsm = pdev->tsm;
+
+ lockdep_assert_held(&pci_tsm_rwsem);
+ if (!tsm_ops)
+ return 0;
+ if (pci_tsm->state < PCI_TSM_INIT) {
+ int rc = tsm_ops->add(pdev);
+
+ if (rc)
+ return rc;
+ }
+ pci_tsm->state = PCI_TSM_INIT;
+ return sysfs_update_group(&pdev->dev.kobj, &pci_tsm_attr_group);
+}
+
+static void pci_tsm_del(struct pci_dev *pdev)
+{
+ struct pci_tsm *pci_tsm = pdev->tsm;
+
+ lockdep_assert_held(&pci_tsm_rwsem);
+ /* shutdown sysfs operations before tsm delete */
+ scoped_guard(mutex, &pdev->tsm->exec_lock)
+ pci_tsm->state = PCI_TSM_IDLE;
+ sysfs_update_group(&pdev->dev.kobj, &pci_tsm_attr_group);
+ tsm_ops->del(pdev);
+}
+
+int pci_tsm_register(const struct pci_tsm_ops *ops)
+{
+ struct pci_dev *pdev;
+ unsigned long index;
+
+ if (!ops)
+ return 0;
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ if (tsm_ops)
+ return -EBUSY;
+ tsm_ops = ops;
+ xa_for_each(&pci_tsm_devs, index, pdev)
+ pci_tsm_add(pdev);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_tsm_register);
+
+void pci_tsm_unregister(const struct pci_tsm_ops *ops)
+{
+ struct pci_dev *pdev;
+ unsigned long index;
+
+ if (!ops)
+ return;
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ if (ops != tsm_ops)
+ return;
+ xa_for_each(&pci_tsm_devs, index, pdev)
+ pci_tsm_del(pdev);
+ tsm_ops = NULL;
+}
+EXPORT_SYMBOL_GPL(pci_tsm_unregister);
+
+int pci_tsm_doe_transfer(struct pci_dev *pdev, enum pci_doe_proto type,
+ const void *req, size_t req_sz, void *resp,
+ size_t resp_sz)
+{
+ if (!pdev->tsm || !pdev->tsm->doe_mb)
+ return -ENXIO;
+
+ return pci_doe(pdev->tsm->doe_mb, PCI_VENDOR_ID_PCI_SIG, type, req,
+ req_sz, resp, resp_sz);
+}
+EXPORT_SYMBOL_GPL(pci_tsm_doe_transfer);
+
+static unsigned long pci_tsm_devid(struct pci_dev *pdev)
+{
+ return FIELD_PREP(GENMASK(15, 0),
+ PCI_DEVID(pdev->bus->number, pdev->devfn)) |
+ FIELD_PREP(GENMASK(31, 16), pci_domain_nr(pdev->bus));
+}
+
+void pci_tsm_init(struct pci_dev *pdev)
+{
+ bool tee_cap;
+ u16 ide_cap;
+ int rc;
+
+ ide_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_IDE);
+ tee_cap = pdev->devcap & PCI_EXP_DEVCAP_TEE;
+
+ if (ide_cap || tee_cap)
+ pci_dbg(pdev,
+ "Device security capabailities detected (%s%s ), init TSM\n",
+ ide_cap ? " ide" : "", tee_cap ? " tee" : "");
+ else
+ return;
+
+ struct pci_tsm *pci_tsm __free(kfree) = kzalloc(sizeof(*pci_tsm), GFP_KERNEL);
+ if (!pci_tsm)
+ return;
+
+ pci_tsm->ide_cap = ide_cap;
+ mutex_init(&pci_tsm->exec_lock);
+
+ pci_tsm->doe_mb = pci_find_doe_mailbox(pdev, PCI_VENDOR_ID_PCI_SIG,
+ PCI_DOE_PROTO_CMA);
+ if (!pci_tsm->doe_mb)
+ return;
+
+ rc = xa_insert(&pci_tsm_devs, pci_tsm_devid(pdev), pdev, GFP_KERNEL);
+ if (rc) {
+ pci_dbg(pdev, "failed to register TSM capable device\n");
+ return;
+ }
+
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ pdev->tsm = no_free_ptr(pci_tsm);
+ pci_tsm_add(pdev);
+}
+
+void pci_tsm_destroy(struct pci_dev *pdev)
+{
+ guard(rwsem_write)(&pci_tsm_rwsem);
+ pci_tsm_del(pdev);
+ xa_erase(&pci_tsm_devs, pci_tsm_devid(pdev));
+ kfree(pdev->tsm);
+ pdev->tsm = NULL;
+}
diff --git a/drivers/virt/coco/host/tsm-core.c b/drivers/virt/coco/host/tsm-core.c
index 0ee738fc40ed..994a7f77c5c9 100644
--- a/drivers/virt/coco/host/tsm-core.c
+++ b/drivers/virt/coco/host/tsm-core.c
@@ -8,11 +8,13 @@
#include <linux/device.h>
#include <linux/module.h>
#include <linux/cleanup.h>
+#include <linux/pci-tsm.h>
static DECLARE_RWSEM(tsm_core_rwsem);
static struct class *tsm_class;
static struct tsm_subsys {
struct device dev;
+ const struct pci_tsm_ops *pci_ops;
} *tsm_subsys;
static struct tsm_subsys *
@@ -40,7 +42,8 @@ static void put_tsm_subsys(struct tsm_subsys *subsys)
DEFINE_FREE(put_tsm_subsys, struct tsm_subsys *,
if (!IS_ERR_OR_NULL(_T)) put_tsm_subsys(_T))
struct tsm_subsys *tsm_register(struct device *parent,
- const struct attribute_group **groups)
+ const struct attribute_group **groups,
+ const struct pci_tsm_ops *pci_ops)
{
struct device *dev;
int rc;
@@ -62,10 +65,20 @@ struct tsm_subsys *tsm_register(struct device *parent,
if (rc)
return ERR_PTR(rc);
+ rc = pci_tsm_register(pci_ops);
+ if (rc) {
+ dev_err(parent, "PCI initialization failure: %pe\n",
+ ERR_PTR(rc));
+ return ERR_PTR(rc);
+ }
+
rc = device_add(dev);
- if (rc)
+ if (rc) {
+ pci_tsm_unregister(pci_ops);
return ERR_PTR(rc);
+ }
+ subsys->pci_ops = pci_ops;
tsm_subsys = no_free_ptr(subsys);
return tsm_subsys;
@@ -74,13 +87,18 @@ EXPORT_SYMBOL_GPL(tsm_register);
void tsm_unregister(struct tsm_subsys *subsys)
{
+ const struct pci_tsm_ops *pci_ops;
+
guard(rwsem_write)(&tsm_core_rwsem);
if (!tsm_subsys || subsys != tsm_subsys) {
pr_warn("failed to unregister, not currently registered\n");
return;
}
+ pci_ops = subsys->pci_ops;
device_unregister(&subsys->dev);
+
+ pci_tsm_unregister(pci_ops);
tsm_subsys = NULL;
}
EXPORT_SYMBOL_GPL(tsm_unregister);
diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h
new file mode 100644
index 000000000000..d17f5e0574c4
--- /dev/null
+++ b/include/linux/pci-tsm.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PCI_TSM_H
+#define __PCI_TSM_H
+#include <linux/mutex.h>
+
+enum pci_tsm_cmd {
+ TSM_EXEC_CONNECT,
+ TSM_EXEC_DISCONNECT,
+};
+
+struct pci_dev;
+/**
+ * struct pci_tsm_ops - Low-level TSM-exported interface to the PCI core
+ * @add: accept device for tsm operation
+ * @del: teardown tsm context for @pdev
+ * @exec: synchronously execute @cmd
+ *
+ * Note that @add, and @del run in down_write(&pci_tsm_rswem) context to
+ * synchronize with TSM driver bind/unbind events and
+ * pci_device_add()/pci_destroy_dev(). @exec runs in
+ * @pdev->tsm->exec_lock context to synchronize @exec results with
+ * @pdev->tsm->state
+ */
+struct pci_tsm_ops {
+ int (*add)(struct pci_dev *pdev);
+ void (*del)(struct pci_dev *pdev);
+ int (*exec)(struct pci_dev *pdev, enum pci_tsm_cmd cmd);
+};
+
+enum pci_tsm_state {
+ PCI_TSM_IDLE,
+ PCI_TSM_INIT,
+ PCI_TSM_CONNECT,
+};
+
+/**
+ * struct pci_tsm - per device TSM context
+ * @state: reflect device initialized, connected, or bound
+ * @ide_cap: PCIe IDE Extended Capability offset
+ * @exec_lock: protect @state vs pci_tsm_ops.exec() results
+ * @doe_mb: PCIe Data Object Exchange mailbox
+ * @tsm_data: TSM driver private context
+ */
+struct pci_tsm {
+ enum pci_tsm_state state;
+ u16 ide_cap;
+ struct mutex exec_lock;
+ struct pci_doe_mb *doe_mb;
+ void *tsm_data;
+};
+
+enum pci_doe_proto {
+ PCI_DOE_PROTO_CMA = 1,
+ PCI_DOE_PROTO_SSESSION = 2,
+};
+
+#ifdef CONFIG_PCI_TSM
+int pci_tsm_register(const struct pci_tsm_ops *ops);
+void pci_tsm_unregister(const struct pci_tsm_ops *ops);
+int pci_tsm_doe_transfer(struct pci_dev *pdev, enum pci_doe_proto type,
+ const void *req, size_t req_sz, void *resp,
+ size_t resp_sz);
+#else
+static inline int pci_tsm_register(const struct pci_tsm_ops *ops)
+{
+ return 0;
+}
+static inline void pci_tsm_unregister(const struct pci_tsm_ops *ops)
+{
+}
+static inline int pci_tsm_doe_transfer(struct pci_dev *pdev,
+ enum pci_doe_proto type, const void *req,
+ size_t req_sz, void *resp,
+ size_t resp_sz)
+{
+ return -ENOENT;
+}
+
+#endif
+#endif /*__PCI_TSM_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 16493426a04f..dd4dc8719c5c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -515,6 +515,9 @@ struct pci_dev {
#endif
#ifdef CONFIG_PCI_DOE
struct xarray doe_mbs; /* Data Object Exchange mailboxes */
+#endif
+#ifdef CONFIG_PCI_TSM
+ struct pci_tsm *tsm; /* TSM operation state */
#endif
u16 acs_cap; /* ACS Capability offset */
phys_addr_t rom; /* Physical address if not from BAR */
@@ -550,6 +553,12 @@ static inline int pci_channel_offline(struct pci_dev *pdev)
return (pdev->error_state != pci_channel_io_normal);
}
+/* id resources that may be shared across host-bridges */
+struct pci_hb_id_pool {
+ int nr_stream_ids;
+ int nr_cxl_cache_ids;
+};
+
/*
* Currently in ACPI spec, for each PCI host bridge, PCI Segment
* Group number is limited to a 16-bit value, therefore (int)-1 is
@@ -568,6 +577,8 @@ struct pci_host_bridge {
void *sysdata;
int busnr;
int domain_nr;
+ struct pci_hb_id_pool __pool;
+ struct pci_hb_id_pool *pool; /* &self->__pool, unless shared */
struct list_head windows; /* resource_entry */
struct list_head dma_ranges; /* dma ranges resource list */
u8 (*swizzle_irq)(struct pci_dev *, u8 *); /* Platform IRQ swizzler */
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index 2867c2ecbd11..6481cc99ea6d 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -68,7 +68,9 @@ int tsm_report_register(const struct tsm_report_ops *ops, void *priv,
const struct config_item_type *type);
int tsm_report_unregister(const struct tsm_report_ops *ops);
struct tsm_subsys;
+struct pci_tsm_ops;
struct tsm_subsys *tsm_register(struct device *parent,
- const struct attribute_group **groups);
+ const struct attribute_group **groups,
+ const struct pci_tsm_ops *ops);
void tsm_unregister(struct tsm_subsys *subsys);
#endif /* __TSM_H */
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index a39193213ff2..9aaffa379cae 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -498,6 +498,7 @@
#define PCI_EXP_DEVCAP_PWR_VAL 0x03fc0000 /* Slot Power Limit Value */
#define PCI_EXP_DEVCAP_PWR_SCL 0x0c000000 /* Slot Power Limit Scale */
#define PCI_EXP_DEVCAP_FLR 0x10000000 /* Function Level Reset */
+#define PCI_EXP_DEVCAP_TEE 0x40000000 /* TEE I/O (TDISP) Support */
#define PCI_EXP_DEVCTL 0x08 /* Device Control */
#define PCI_EXP_DEVCTL_CERE 0x0001 /* Correctable Error Reporting En. */
#define PCI_EXP_DEVCTL_NFERE 0x0002 /* Non-Fatal Error Reporting Enable */
@@ -742,7 +743,8 @@
#define PCI_EXT_CAP_ID_PL_16GT 0x26 /* Physical Layer 16.0 GT/s */
#define PCI_EXT_CAP_ID_PL_32GT 0x2A /* Physical Layer 32.0 GT/s */
#define PCI_EXT_CAP_ID_DOE 0x2E /* Data Object Exchange */
-#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_DOE
+#define PCI_EXT_CAP_ID_IDE 0x30 /* Integrity and Data Encryption */
+#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_IDE
#define PCI_EXT_CAP_DSN_SIZEOF 12
#define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
^ permalink raw reply related [relevance 10%]
* Fwd: Bouncing messages from llvm@lists.linux.dev
[not found] ` <CAFP8O3+Lw0wKfWY-VA+tuAnVcjyN17E=yk6-VU5WcWG1xdH+UA@mail.gmail.com>
@ 2022-07-11 17:54 10% ` Nick Desaulniers
0 siblings, 0 replies; 200+ results
From: Nick Desaulniers @ 2022-07-11 17:54 UTC (permalink / raw)
To: postmaster; +Cc: clang-built-linux, Nathan Chancellor
Hi Post Master,
Any idea what's up with the below message?
To Fangrui, it sounded like his patch wasn't delivered to our list but
the message Fangrui sent was indeed posted.
https://lore.kernel.org/llvm/20220710071117.446112-1-maskray@google.com/
Can the error be reworded possibly to elucidate what's going on?
---------- Forwarded message ---------
From: Fangrui Song <maskray@google.com>
Date: Mon, Jul 11, 2022 at 10:36 AM
Subject: Fwd: Bouncing messages from llvm@lists.linux.dev
To: Nick Desaulniers <ndesaulniers@google.com>
---------- Forwarded message ---------
From: <llvm+owner@lists.linux.dev>
Date: Sun, Jul 10, 2022 at 3:30 PM
Subject: Bouncing messages from llvm@lists.linux.dev
To: <maskray@google.com>
Greetings!
This is the mlmmj program managing the <llvm@lists.linux.dev> mailing list.
Some messages to you could not be delivered. If you're seeing this
message it means things are back to normal, and it's merely for your
information.
Here is the list of the bounced messages:
- 11406
--
宋方睿
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [relevance 10%]
* Subscriber actions for migrating lists to lists.linux.dev
@ 2021-04-16 20:58 10% James Bottomley
2021-04-16 21:16 11% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: James Bottomley @ 2021-04-16 20:58 UTC (permalink / raw)
To: users, tools
I'm fairly certain all I need to do is a bit of duplicate message
elimination and to update my procmail rules, but on the latter, what is
the header I should be sorting on? For current kernel.org lists, it's
either X-Mailing-list: or List-ID: Will it be the same for
lists.linux.dev (so I just add to the domain in the rule)?
Ordinarily I'd just wait and see, but given the volumes involved I
wasn't keen on waking up to hundreds of emails suddenly in my INBOX
instead of the list folders.
James
^ permalink raw reply [relevance 10%]
* PSA: the linux-kernel-mentees list is migrating to lists.linux.dev
@ 2023-11-01 19:47 10% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-01 19:47 UTC (permalink / raw)
To: linux-kernel-mentees
Hello, all:
The mailman-2 system running on lists.linuxfoundation.org is being
decommissioned, so all lists currently hosted there will be found new homes.
*On November 7*, The linux-kernel-mentees list will be migrated to live on
lists.linux.dev, but the impact of this move should be minor:
1. The new canonical list address will be linux-kernel-mentees@lists.linux.dev.
2. *The old address will continue to work* for the foreseeable future, so any
existing conversations can continue and any new messages sent to the old
list address will be properly delivered to all subscribers.
3. All members will be automatically subscribed to the new list, so no action
is required on anyone's part to keep receiving list mail.
4. The archive on https://lore.kernel.org/linux-kernel-mentees/ will be
automatically updated to track the new list address.
5. The List-ID header will change, regardless to which address the message is
sent:
before: List-Id: <linux-kernel-mentees.lists.linuxfoundation.org>
after: List-Id: <linux-kernel-mentees.lists.linux.dev>
You will need to update your filtering rules if you filter based on the
contents of that header (on or after November 7).
6. The mailman footer will no longer be added to message bodies.
7. Subscribing and unsubscribing will be done using the mlmmj supported
commands, documented at https://subspace.kernel.org/subscribing.html
Please let me know if you have any questions or concerns. Otherwise, I will
follow up on November 7 after the move has been completed.
Best regards,
-K
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [relevance 10%]
* [PATCH] KVM: arm64: Drop Columbia-hosted mailing list
@ 2023-01-13 13:28 9% ` Marc Zyngier
0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2023-01-13 13:28 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu
After many years of awesome service, the kvmarm mailing list hosted by
Columbia is being decommissioned, and replaced by kvmarm@lists.linux.dev.
Many thanks to Columbia for having hosted us for so long, and to the
kernel.org folks for giving us a new home.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6a0fc23455bd..d9a359a65d0f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11361,7 +11361,6 @@ R: Oliver Upton <oliver.upton@linux.dev>
R: Zenghui Yu <yuzenghui@huawei.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: kvmarm@lists.linux.dev
-L: kvmarm@lists.cs.columbia.edu (deprecated, moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
F: arch/arm64/include/asm/kvm*
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 10%]
* [PATCH v4 14/15] x86/sev: Extend the config-fs attestation support for an SVSM
@ 2024-04-24 15:58 10% ` Tom Lendacky
0 siblings, 0 replies; 200+ results
From: Tom Lendacky @ 2024-04-24 15:58 UTC (permalink / raw)
To: linux-kernel, x86, linux-coco, svsm-devel
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
Michael Roth, Ashish Kalra
When an SVSM is present, the guest can also request attestation reports
from the SVSM. These SVSM attestation reports can be used to attest the
SVSM and any services running within the SVSM.
Extend the config-fs attestation support to allow for an SVSM attestation
report. This involves creating four (4) new config-fs attributes:
- 'service-provider' (input)
This attribute is used to determine whether the attestation request
should be sent to the specified service provider or to the SEV
firmware. The SVSM service provider is represented by the value
'svsm'.
- 'service_guid' (input)
Used for requesting the attestation of a single service within the
service provider. A null GUID implies that the SVSM_ATTEST_SERVICES
call should be used to request the attestation report. A non-null
GUID implies that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
- 'service_manifest_version' (input)
Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
represents a specific service manifest version be used for the
attestation report.
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation
report.
Only display these new attributes when running under an SVSM.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
Documentation/ABI/testing/configfs-tsm | 63 ++++++++
arch/x86/include/asm/sev.h | 31 +++-
arch/x86/kernel/sev.c | 50 +++++++
drivers/virt/coco/sev-guest/sev-guest.c | 186 ++++++++++++++++++++++++
drivers/virt/coco/tsm.c | 93 +++++++++++-
include/linux/tsm.h | 19 +++
6 files changed, 439 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
index dd24202b5ba5..bc8f6efa5d6f 100644
--- a/Documentation/ABI/testing/configfs-tsm
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -31,6 +31,18 @@ Description:
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+What: /sys/kernel/config/tsm/report/$name/manifestblob
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ manifest data is available.
+
+ See 'service_provider' for information on the format of the
+ manifest blob.
+
What: /sys/kernel/config/tsm/report/$name/provider
Date: September, 2023
KernelVersion: v6.7
@@ -80,3 +92,54 @@ Contact: linux-coco@lists.linux.dev
Description:
(RO) Indicates the minimum permissible value that can be written
to @privlevel.
+
+What: /sys/kernel/config/tsm/report/$name/service_provider
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Specifying the service provider via this attribute will create
+ an attestation report as specified by the service provider.
+ Currently supported service-providers are:
+ svsm
+
+ For the "svsm" service provider, see the Secure VM Service Module
+ for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What: /sys/kernel/config/tsm/report/$name/service_guid
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Specifying an empty/null GUID (00000000-0000-0000-0000-000000)
+ requests all active services within the service provider be
+ part of the attestation report. Specifying a GUID request
+ an attestation report of just the specified service using the
+ manifest form specified by the service_manifest_version
+ attribute.
+
+ See 'service_provider' for information on the format of the
+ service guid.
+
+What: /sys/kernel/config/tsm/report/$name/service_manifest_version
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Indicates the service manifest version requested for the
+ attestation report (default 0). If this field is not set by
+ the user, the default manifest version of the service (the
+ service's initial/first manifest version) is returned.
+
+ See 'service_provider' for information on the format of the
+ service manifest version.
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 64fcadd6d602..2c66e7f2a7c7 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -209,6 +209,27 @@ struct svsm_pvalidate_call {
struct svsm_pvalidate_entry entry[];
};
+/*
+ * The SVSM Attestation related structures
+ */
+struct svsm_location_entry {
+ u64 pa;
+ u32 len;
+ u8 rsvd[4];
+};
+
+struct svsm_attestation_call {
+ struct svsm_location_entry report_buffer;
+ struct svsm_location_entry nonce;
+ struct svsm_location_entry manifest_buffer;
+ struct svsm_location_entry certificates_buffer;
+
+ /* For attesting a single service */
+ u8 service_guid[16];
+ u32 service_manifest_version;
+ u8 rsvd[4];
+};
+
/*
* SVSM protocol structure
*/
@@ -232,6 +253,10 @@ struct svsm_call {
#define SVSM_CORE_CREATE_VCPU 2
#define SVSM_CORE_DELETE_VCPU 3
+#define SVSM_ATTEST_CALL(x) ((1ULL << 32) | (x))
+#define SVSM_ATTEST_SERVICES 0
+#define SVSM_ATTEST_SINGLE_SERVICE 1
+
#ifdef CONFIG_AMD_MEM_ENCRYPT
extern void __sev_es_ist_enter(struct pt_regs *regs);
extern void __sev_es_ist_exit(void);
@@ -302,6 +327,7 @@ bool snp_init(struct boot_params *bp);
void __noreturn snp_abort(void);
void snp_dmi_setup(void);
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio);
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input);
void snp_accept_memory(phys_addr_t start, phys_addr_t end);
u64 snp_get_unsupported_features(u64 status);
u64 sev_get_status(void);
@@ -332,7 +358,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
{
return -ENOTTY;
}
-
+static inline int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ return -ENOTTY;
+}
static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { }
static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
static inline u64 sev_get_status(void) { return 0; }
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 75f11da867a3..5e71c94b952c 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2390,6 +2390,56 @@ static int __init init_sev_config(char *str)
}
__setup("sev=", init_sev_config);
+static void update_attestation_input(struct svsm_call *call, struct svsm_attestation_call *input)
+{
+ /* If (new) lengths have been returned, propograte them up */
+ if (call->rcx_out != call->rcx)
+ input->manifest_buffer.len = call->rcx_out;
+
+ if (call->rdx_out != call->rdx)
+ input->certificates_buffer.len = call->rdx_out;
+
+ if (call->r8_out != call->r8)
+ input->report_buffer.len = call->r8_out;
+}
+
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ struct svsm_attestation_call *attest_call;
+ struct svsm_call call = {};
+ unsigned long flags;
+ u64 attest_call_pa;
+ int ret;
+
+ if (!vmpl)
+ return -EINVAL;
+
+ local_irq_save(flags);
+
+ call.caa = __svsm_get_caa();
+
+ attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer;
+ attest_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
+
+ *attest_call = *input;
+
+ /*
+ * Set input registers for the request and set RDX and R8 to known
+ * values in order to detect length values being returned in them.
+ */
+ call.rax = call_id;
+ call.rcx = attest_call_pa;
+ call.rdx = -1;
+ call.r8 = -1;
+ ret = svsm_protocol(&call);
+ update_attestation_input(&call, input);
+
+ local_irq_restore(flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(snp_issue_svsm_attestation_request);
+
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio)
{
struct ghcb_state state;
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index ec3d894cfe31..d37a8b27d12a 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -39,6 +39,8 @@
#define SNP_REQ_MAX_RETRY_DURATION (60*HZ)
#define SNP_REQ_RETRY_DELAY (2*HZ)
+#define SVSM_MAX_RETRIES 3
+
struct snp_guest_crypto {
struct crypto_aead *tfm;
u8 *iv, *authtag;
@@ -784,6 +786,148 @@ struct snp_msg_cert_entry {
u32 length;
};
+static int sev_svsm_report_new(struct tsm_report *report, void *data)
+{
+ unsigned int report_len, manifest_len, certificates_len;
+ void *report_blob, *manifest_blob, *certificates_blob;
+ struct svsm_attestation_call attest_call = {};
+ struct tsm_desc *desc = &report->desc;
+ unsigned int retry_count;
+ unsigned int size;
+ bool try_again;
+ void *buffer;
+ u64 call_id;
+ int ret;
+
+ /*
+ * Allocate pages for the request:
+ * - Report blob (4K)
+ * - Manifest blob (4K)
+ * - Certificate blob (16K)
+ *
+ * Above addresses must be 4K aligned
+ */
+ report_len = SZ_4K;
+ manifest_len = SZ_4K;
+ certificates_len = SEV_FW_BLOB_MAX_SIZE;
+
+ if (guid_is_null(&desc->service_guid)) {
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES);
+ } else {
+ export_guid(attest_call.service_guid, &desc->service_guid);
+ attest_call.service_manifest_version = desc->service_manifest_version;
+
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
+ }
+
+ retry_count = 0;
+
+retry:
+ size = report_len + manifest_len + certificates_len;
+ buffer = alloc_pages_exact(size, __GFP_ZERO);
+ if (!buffer)
+ return -ENOMEM;
+
+ report_blob = buffer;
+ attest_call.report_buffer.pa = __pa(report_blob);
+ attest_call.report_buffer.len = report_len;
+
+ manifest_blob = report_blob + report_len;
+ attest_call.manifest_buffer.pa = __pa(manifest_blob);
+ attest_call.manifest_buffer.len = manifest_len;
+
+ certificates_blob = manifest_blob + manifest_len;
+ attest_call.certificates_buffer.pa = __pa(certificates_blob);
+ attest_call.certificates_buffer.len = certificates_len;
+
+ attest_call.nonce.pa = __pa(desc->inblob);
+ attest_call.nonce.len = desc->inblob_len;
+
+ ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
+ switch (ret) {
+ case SVSM_SUCCESS:
+ break;
+ case SVSM_ERR_INVALID_PARAMETER:
+ ret = -EINVAL;
+
+ if (retry_count >= SVSM_MAX_RETRIES)
+ goto error;
+
+ try_again = false;
+
+ if (attest_call.report_buffer.len > report_len) {
+ report_len = PAGE_ALIGN(attest_call.report_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.manifest_buffer.len > manifest_len) {
+ manifest_len = PAGE_ALIGN(attest_call.manifest_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.certificates_buffer.len > certificates_len) {
+ certificates_len = PAGE_ALIGN(attest_call.certificates_buffer.len);
+ try_again = true;
+ }
+
+ /* If one of the buffers wasn't large enough, retry the request */
+ if (try_again) {
+ free_pages_exact(buffer, size);
+ retry_count++;
+ goto retry;
+ }
+
+ goto error;
+ case SVSM_ERR_BUSY:
+ ret = -EAGAIN;
+ goto error;
+ default:
+ pr_err_ratelimited("SVSM attestation request failed (%#x)\n", ret);
+ ret = -EINVAL;
+ goto error;
+ }
+
+ ret = -ENOMEM;
+
+ report_len = attest_call.report_buffer.len;
+ void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL);
+ if (!rbuf)
+ goto error;
+
+ memcpy(rbuf, report_blob, report_len);
+ report->outblob = no_free_ptr(rbuf);
+ report->outblob_len = report_len;
+
+ manifest_len = attest_call.manifest_buffer.len;
+ void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL);
+ if (!mbuf)
+ goto error;
+
+ memcpy(mbuf, manifest_blob, manifest_len);
+ report->manifestblob = no_free_ptr(mbuf);
+ report->manifestblob_len = manifest_len;
+
+ certificates_len = attest_call.certificates_buffer.len;
+ if (!certificates_len)
+ goto success;
+
+ void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL);
+ if (!cbuf)
+ goto error;
+
+ memcpy(cbuf, certificates_blob, certificates_len);
+ report->auxblob = no_free_ptr(cbuf);
+ report->auxblob_len = certificates_len;
+
+success:
+ ret = 0;
+
+error:
+ free_pages_exact(buffer, size);
+
+ return ret;
+}
+
static int sev_report_new(struct tsm_report *report, void *data)
{
struct snp_msg_cert_entry *cert_table;
@@ -798,6 +942,13 @@ static int sev_report_new(struct tsm_report *report, void *data)
if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
return -EINVAL;
+ if (desc->service_provider) {
+ if (strcmp(desc->service_provider, "svsm"))
+ return -EINVAL;
+
+ return sev_svsm_report_new(report, data);
+ }
+
void *buf __free(kvfree) = kvzalloc(size, GFP_KERNEL);
if (!buf)
return -ENOMEM;
@@ -886,9 +1037,44 @@ static int sev_report_new(struct tsm_report *report, void *data)
return 0;
}
+static bool sev_report_attr_visible(struct config_item *item,
+ struct configfs_attribute *attr, int n)
+{
+ switch (n) {
+ case TSM_REPORT_GENERATION:
+ case TSM_REPORT_PROVIDER:
+ case TSM_REPORT_PRIVLEVEL:
+ case TSM_REPORT_PRIVLEVEL_FLOOR:
+ return true;
+ case TSM_REPORT_SERVICE_PROVIDER:
+ case TSM_REPORT_SERVICE_GUID:
+ case TSM_REPORT_SERVICE_MANIFEST_VER:
+ return snp_get_vmpl();
+ }
+
+ return false;
+}
+
+static bool sev_report_bin_attr_visible(struct config_item *item,
+ struct configfs_bin_attribute *attr, int n)
+{
+ switch (n) {
+ case TSM_REPORT_INBLOB:
+ case TSM_REPORT_OUTBLOB:
+ case TSM_REPORT_AUXBLOB:
+ return true;
+ case TSM_REPORT_MANIFESTBLOB:
+ return snp_get_vmpl();
+ }
+
+ return false;
+}
+
static struct tsm_ops sev_tsm_ops = {
.name = KBUILD_MODNAME,
.report_new = sev_report_new,
+ .report_attr_visible = sev_report_attr_visible,
+ .report_bin_attr_visible = sev_report_bin_attr_visible,
};
static void unregister_sev_tsm(void *data)
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index dedb4f582630..3c9587e8746b 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -34,7 +34,7 @@ static DECLARE_RWSEM(tsm_rwsem);
* The attestation report format is TSM provider specific, when / if a standard
* materializes that can be published instead of the vendor layout. Until then
* the 'provider' attribute indicates the format of 'outblob', and optionally
- * 'auxblob'.
+ * 'auxblob' and 'manifestblob'.
*/
struct tsm_report_state {
@@ -47,6 +47,7 @@ struct tsm_report_state {
enum tsm_data_select {
TSM_REPORT,
TSM_CERTS,
+ TSM_MANIFEST,
};
static struct tsm_report *to_tsm_report(struct config_item *cfg)
@@ -118,6 +119,74 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
}
CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ size_t sp_len;
+ char *sp;
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ sp_len = (buf[len - 1] != '\n') ? len : len - 1;
+
+ sp = kstrndup(buf, sp_len, GFP_KERNEL);
+ if (!sp)
+ return -ENOMEM;
+ kfree(report->desc.service_provider);
+
+ report->desc.service_provider = sp;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_provider);
+
+static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ report->desc.service_guid = guid_null;
+
+ rc = guid_parse(buf, &report->desc.service_guid);
+ if (rc)
+ return rc;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_guid);
+
+static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.service_manifest_version = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
+
static ssize_t tsm_report_inblob_write(struct config_item *cfg,
const void *buf, size_t count)
{
@@ -162,6 +231,9 @@ static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
if (select == TSM_REPORT) {
out = report->outblob;
len = report->outblob_len;
+ } else if (select == TSM_MANIFEST) {
+ out = report->manifestblob;
+ len = report->manifestblob_len;
} else {
out = report->auxblob;
len = report->auxblob_len;
@@ -187,7 +259,7 @@ static ssize_t read_cached_report(struct tsm_report *report, void *buf,
/*
* A given TSM backend always fills in ->outblob regardless of
- * whether the report includes an auxblob or not.
+ * whether the report includes an auxblob/manifestblob or not.
*/
if (!report->outblob ||
state->read_generation != state->write_generation)
@@ -223,8 +295,10 @@ static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
kvfree(report->outblob);
kvfree(report->auxblob);
+ kvfree(report->manifestblob);
report->outblob = NULL;
report->auxblob = NULL;
+ report->manifestblob = NULL;
rc = ops->report_new(report, provider.data);
if (rc < 0)
return rc;
@@ -251,11 +325,23 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
}
CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
+static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_MANIFEST);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
+
static struct configfs_attribute *tsm_report_attrs[] = {
[TSM_REPORT_GENERATION] = &tsm_report_attr_generation,
[TSM_REPORT_PROVIDER] = &tsm_report_attr_provider,
[TSM_REPORT_PRIVLEVEL] = &tsm_report_attr_privlevel,
[TSM_REPORT_PRIVLEVEL_FLOOR] = &tsm_report_attr_privlevel_floor,
+ [TSM_REPORT_SERVICE_PROVIDER] = &tsm_report_attr_service_provider,
+ [TSM_REPORT_SERVICE_GUID] = &tsm_report_attr_service_guid,
+ [TSM_REPORT_SERVICE_MANIFEST_VER] = &tsm_report_attr_service_manifest_version,
NULL,
};
@@ -263,6 +349,7 @@ static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
[TSM_REPORT_INBLOB] = &tsm_report_attr_inblob,
[TSM_REPORT_OUTBLOB] = &tsm_report_attr_outblob,
[TSM_REPORT_AUXBLOB] = &tsm_report_attr_auxblob,
+ [TSM_REPORT_MANIFESTBLOB] = &tsm_report_attr_manifestblob,
NULL,
};
@@ -271,8 +358,10 @@ static void tsm_report_item_release(struct config_item *cfg)
struct tsm_report *report = to_tsm_report(cfg);
struct tsm_report_state *state = to_state(report);
+ kvfree(report->manifestblob);
kvfree(report->auxblob);
kvfree(report->outblob);
+ kfree(report->desc.service_provider);
kfree(state);
}
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index fa19291a9854..7c52a16a61c3 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -5,6 +5,7 @@
#include <linux/sizes.h>
#include <linux/types.h>
#include <linux/configfs.h>
+#include <linux/uuid.h>
#define TSM_INBLOB_MAX 64
#define TSM_OUTBLOB_MAX SZ_32K
@@ -20,11 +21,17 @@
* @privlevel: optional privilege level to associate with @outblob
* @inblob_len: sizeof @inblob
* @inblob: arbitrary input data
+ * @service_provider: optional name of where to obtain the tsm report blob
+ * @service_guid: optional service-provider service guid to attest
+ * @service_manifest_version: optional service-provider service manifest version requested
*/
struct tsm_desc {
unsigned int privlevel;
size_t inblob_len;
u8 inblob[TSM_INBLOB_MAX];
+ char *service_provider;
+ guid_t service_guid;
+ unsigned int service_manifest_version;
};
/**
@@ -34,6 +41,8 @@ struct tsm_desc {
* @outblob: generated evidence to provider to the attestation agent
* @auxblob_len: sizeof(@auxblob)
* @auxblob: (optional) auxiliary data to the report (e.g. certificate data)
+ * @manifestblob_len: sizeof(@manifestblob)
+ * @manifestblob: (optional) manifest data associated with the report
*/
struct tsm_report {
struct tsm_desc desc;
@@ -41,6 +50,8 @@ struct tsm_report {
u8 *outblob;
size_t auxblob_len;
u8 *auxblob;
+ size_t manifestblob_len;
+ u8 *manifestblob;
};
/**
@@ -49,12 +60,18 @@ struct tsm_report {
* @TSM_REPORT_PROVIDER: index of the provider name attribute
* @TSM_REPORT_PRIVLEVEL: index of the desired privilege level attribute
* @TSM_REPORT_PRIVLEVEL_FLOOR: index of the minimum allowed privileg level attribute
+ * @TSM_REPORT_SERVICE_PROVIDER: index of the service provider identifier attribute
+ * @TSM_REPORT_SERVICE_GUID: index of the service GUID attribute
+ * @TSM_REPORT_SERVICE_MANIFEST_VER: index of the service manifest version attribute
*/
enum tsm_attr_index {
TSM_REPORT_GENERATION,
TSM_REPORT_PROVIDER,
TSM_REPORT_PRIVLEVEL,
TSM_REPORT_PRIVLEVEL_FLOOR,
+ TSM_REPORT_SERVICE_PROVIDER,
+ TSM_REPORT_SERVICE_GUID,
+ TSM_REPORT_SERVICE_MANIFEST_VER,
};
/**
@@ -62,11 +79,13 @@ enum tsm_attr_index {
* @TSM_REPORT_INBLOB: index of the binary report input attribute
* @TSM_REPORT_OUTBLOB: index of the binary report output attribute
* @TSM_REPORT_AUXBLOB: index of the binary auxiliary data attribute
+ * @TSM_REPORT_MANIFESTBLOB: index of the binary manifest data attribute
*/
enum tsm_bin_attr_index {
TSM_REPORT_INBLOB,
TSM_REPORT_OUTBLOB,
TSM_REPORT_AUXBLOB,
+ TSM_REPORT_MANIFESTBLOB,
};
/**
--
2.43.2
^ permalink raw reply related [relevance 10%]
* Moving this list to lists.linux.dev
@ 2023-10-27 18:28 10% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-10-27 18:28 UTC (permalink / raw)
To: virtualization
Hello, everyone:
The mailman-2 system running lists.linux-foundation.org is overdue to be
retired, so we are working on finding better homes for the few remaining lists
that are still using it.
I propose migrating this list to lists.linux.dev, which is already hosting
many Linux development lists. The upcoming merge window should be a good time
to do it, as it usually results in lower mailing list traffic.
Here's how the process would go:
1. Set up virtualization@lists.linux.dev
2. Move all subscribers from the old list to the new
On the chosen flag day:
3. Remove all subscribers on the old list and add the new list address as
the only subscriber.
4. Submit a patch to MAINTAINERS so all instances of
virtualization@lists.linux-foundation.org are replaced with
virtualization@lists.linux.dev
At some point a few weeks later:
5. Close the old list and add an auto-responder with instructions where all
mail should be sent instead.
Does that work for everyone?
-K
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [relevance 10%]
* [PATCH] docs: update ofono mailing list
@ 2023-02-11 18:18 10% Alexandru Ardelean
0 siblings, 0 replies; 200+ results
From: Alexandru Ardelean @ 2023-02-11 18:18 UTC (permalink / raw)
To: ofono; +Cc: Alexandru Ardelean
I've re-sent some patches to 'ofono@lists.linux.dev' and it worked.
Initially, my patches/emails got denied by the email server (when sending
to ofono@ofono.org).
Checking 'https://lore.kernel.org/ofono/' it seems that my patches went
through, so it looks like the docs could use with an update.
The websites are not changed, as http://ofono.org redirects to
https://git.kernel.org/pub/scm/network/ofono/ofono.git
---
HACKING | 2 +-
README | 2 +-
doc/ofono-paper.txt | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/HACKING b/HACKING
index 15ea2912..8d67a19e 100644
--- a/HACKING
+++ b/HACKING
@@ -114,4 +114,4 @@ a feature that touches files under 'include/', 'src/' and 'drivers/'
directories, split in three separated patches, taking care not to
break compilation.
-4) Submit patches using git send-email to ofono@ofono.org
+4) Submit patches using git send-email to ofono@lists.linux.dev
diff --git a/README b/README
index 1c539995..e2a1c772 100644
--- a/README
+++ b/README
@@ -62,7 +62,7 @@ Information
===========
Mailing list:
- ofono@ofono.org
+ ofono@lists.linux.dev
IRC:
irc://irc.oftc.net/#ofono
diff --git a/doc/ofono-paper.txt b/doc/ofono-paper.txt
index ec6d01b9..a5321618 100644
--- a/doc/ofono-paper.txt
+++ b/doc/ofono-paper.txt
@@ -167,6 +167,6 @@ add telephony capabilities to Linux desktop and mobile devices.
6.0 Resources
Website: http://ofono.org
-Mailing List: ofono@ofono.org
+Mailing List: ofono@lists.linux.dev
IRC: #ofono on freenode
--
2.34.1
^ permalink raw reply related [relevance 10%]
* Re: Subscriber actions for migrating lists to lists.linux.dev
@ 2021-04-16 21:26 10% ` Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2021-04-16 21:26 UTC (permalink / raw)
To: James Bottomley; +Cc: users, tools
On Fri, Apr 16, 2021 at 02:22:58PM -0700, James Bottomley wrote:
> > The lists we're currently migrating are moving from other places --
> > either from domains we don't control (lists.01.org), or from domains
> > like lists.linuxfoundation.org where there are MLs that will likely
> > not enjoy mlmmj-style list management and will move to groups.io
> > instead after we cherry-pick the devel lists.
>
> OK, so for ksummit-discuss and it's ilk I need
>
> * ^List-Id: .*ksummit-discuss.lists.(linuxfoundation.org|linux.dev)
Note, that the new list is without the -discuss part, just
ksummit@lists.linux.dev, so you'll probably want:
* ^List-Id: .*ksummit.*\.lists\.linux.*
-K
^ permalink raw reply [relevance 10%]
* lvm-devel has migrated to lists.linux.dev [was: Re: Welcome to the "lvm-devel" mailing list]
[not found] <mailman.0.1697833396.3533474.lvm-devel@redhat.com>
@ 2023-10-20 21:34 10% ` Mike Snitzer
0 siblings, 0 replies; 200+ results
From: Mike Snitzer @ 2023-10-20 21:34 UTC (permalink / raw)
To: lvm-devel
Hi,
[Sorry for the noise of the previous mailman email, please ignore it.]
As a lvm-devel@redhat.com subscriber, you have been silently subscribed
to the new mailing list: lvm-devel@lists.linux.dev.
Effective immediately, all lvm-devel email should be addressed to:
lvm-devel@lists.linux.dev
If you do send email to lvm-devel@redhat.com you will get this
auto-response:
Your email to lvm-devel@redhat.com was delivered using
lvm-devel@lists.linux.dev because:
As of 2023.10.20: lvm-devel@redhat.com has migrated to
lvm-devel@lists.linux.dev
Please update the lvm-devel address to lvm-devel@lists.linux.dev
If you were a lvm-devel@redhat.com subscriber you have been silently
subscribed to lvm-devel@lists.linux.dev
Please be sure to update any lvm-devel mail filter you may have to look
for this in mail headers:
List-Id: <lvm-devel.lists.linux.dev>
NOTE: If you, or a friend, were a lvm-devel@redhat.com subscriber
with disabled mail delivery: then you must subscribe to
lvm-devel@lists.linux.dev. To do so please send email to:
lvm-devel+subscribe@lists.linux.dev
To unsubscribe from lvm-devel@lists.linux.dev please send email to:
lvm-devel+unsubscribe@lists.linux.dev
The lvm-devel list archive will soon be migrating here:
https://lore.kernel.org/lvm-devel/
Please let me know if you have any questions or concerns.
Thanks,
Mike
^ permalink raw reply [relevance 10%]
* Moving to llvm@lists.linux.dev
@ 2021-08-25 21:07 10% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-08-25 21:07 UTC (permalink / raw)
To: clang-built-linux, Philip Li, Veronika Kabatova, kernelci,
linaro-toolchain
Hi everyone,
We are shifting the ClangBuiltLinux mailing list from
clang-built-linux@googlegroups.com to llvm@lists.linux.dev. Google
Groups has served us well but moving to lists.linux.dev allows for
easier archival (as we will be on lore.kernel.org automatically) and
allows for people to subscribe to us easier, as they only need an email
address, rather than a Google account.
Please follow these directions to subscribe to the new mailing list:
https://subspace.kernel.org/index.html#subscribing
Some more information about lists.linux.dev:
https://www.kernel.org/lists-linux-dev.html
https://subspace.kernel.org/lists.linux.dev.html
I have added CI maintainers/mailing lists that send us regular reports
to this announcement. Please continue to send us emails about build
results, just switch the email from clang-built-linux@googlegroups.com
to llvm@lists.linux.dev so that they get archived as a part of lore and
can be easily searched, especially with the upcoming
https://x-lore.kernel.org/all/.
I will send a patch shortly to update MAINTAINERS.
Cheers,
Nathan
^ permalink raw reply [relevance 10%]
* [PATCH 1/2] netfs, cachefiles: Change mailing list
@ 2024-01-22 11:50 10% ` David Howells
2024-01-22 11:50 8% ` David Howells
1 sibling, 0 replies; 200+ results
From: David Howells @ 2024-01-22 11:50 UTC (permalink / raw)
To: netfs
Cc: David Howells, Christian Brauner, Jeff Layton, Matthew Wilcox,
linux-cachefs, linux-afs, linux-cifs, linux-nfs, ceph-devel, v9fs,
linux-erofs, linux-fsdevel, linux-mm, linux-kernel
The publicly accessible archives for Red Hat mailing lists stop at Oct
2023; messages sent after that time are in internal-only archives.
Change the netfs and cachefiles mailing list to one that has publicly
accessible archives:
netfs@lists.linux.dev
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jeff Layton <jlayton@kernel.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: netfs@lists.linux.dev
cc: linux-cachefs@redhat.com
cc: v9fs@lists.linux.dev
cc: linux-afs@lists.infradead.org
cc: ceph-devel@vger.kernel.org
cc: linux-cifs@vger.kernel.org
cc: linux-erofs@lists.ozlabs.org
cc: linux-nfs@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a69..ab5858d24ffc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4547,7 +4547,7 @@ F: drivers/net/ieee802154/ca8210.c
CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS
M: David Howells <dhowells@redhat.com>
-L: linux-cachefs@redhat.com (moderated for non-subscribers)
+L: netfs@lists.linux.dev
S: Supported
F: Documentation/filesystems/caching/cachefiles.rst
F: fs/cachefiles/
@@ -8223,7 +8223,7 @@ F: include/linux/iomap.h
FILESYSTEMS [NETFS LIBRARY]
M: David Howells <dhowells@redhat.com>
-L: linux-cachefs@redhat.com (moderated for non-subscribers)
+L: netfs@lists.linux.dev
L: linux-fsdevel@vger.kernel.org
S: Supported
F: Documentation/filesystems/caching/
^ permalink raw reply related [relevance 10%]
* [ANNOUNCE] Goodbye cluster-devel, hello gfs2@lists.linux.dev
@ 2023-08-29 17:07 10% ` Andrew Price
0 siblings, 0 replies; 200+ results
From: Andrew Price @ 2023-08-29 17:07 UTC (permalink / raw)
To: cluster-devel; +Cc: gfs2
Hi all,
As cluster-devel is now only used for gfs2 and dlm development, we will
be moving them to a new list hosted by kernel.org alongside other Linux
subsystems' lists. The new list is gfs2@lists.linux.dev and it will be
used for both gfs2 and dlm development.
The Linux MAINTAINERS file and other references will be updated shortly
to reflect the change. Information about the list hosting can be found here:
https://subspace.kernel.org/lists.linux.dev.html
To subscribe, send an email (the subject and body doesn't matter) to:
Subscribe: gfs2+subscribe@lists.linux.dev
Unsubscribe: gfs2+unsubscribe@lists.linux.dev
If you prefer, the list can also be read via NNTP at:
nntp://nntp.lore.kernel.org/dev.linux.lists.gfs2
The archives can be found here:
https://lore.kernel.org/gfs2/
and filters can use the "List-Id: <gfs2.lists.linux.dev>" header.
Thanks,
Andy
^ permalink raw reply [relevance 10%]
* [Cluster-devel] [ANNOUNCE] Goodbye cluster-devel, hello gfs2@lists.linux.dev
@ 2023-08-29 17:07 10% ` Andrew Price
0 siblings, 0 replies; 200+ results
From: Andrew Price @ 2023-08-29 17:07 UTC (permalink / raw)
To: cluster-devel; +Cc: gfs2
Hi all,
As cluster-devel is now only used for gfs2 and dlm development, we will
be moving them to a new list hosted by kernel.org alongside other Linux
subsystems' lists. The new list is gfs2@lists.linux.dev and it will be
used for both gfs2 and dlm development.
The Linux MAINTAINERS file and other references will be updated shortly
to reflect the change. Information about the list hosting can be found here:
https://subspace.kernel.org/lists.linux.dev.html
To subscribe, send an email (the subject and body doesn't matter) to:
Subscribe: gfs2+subscribe@lists.linux.dev
Unsubscribe: gfs2+unsubscribe@lists.linux.dev
If you prefer, the list can also be read via NNTP at:
nntp://nntp.lore.kernel.org/dev.linux.lists.gfs2
The archives can be found here:
https://lore.kernel.org/gfs2/
and filters can use the "List-Id: <gfs2.lists.linux.dev>" header.
Thanks,
Andy
^ permalink raw reply [relevance 10%]
* [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
@ 2024-03-25 22:26 10% ` Tom Lendacky
0 siblings, 0 replies; 200+ results
From: Tom Lendacky @ 2024-03-25 22:26 UTC (permalink / raw)
To: linux-kernel, x86, linux-coco, svsm-devel
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
Michael Roth, Ashish Kalra
When an SVSM is present, the guest can also request attestation reports
from the SVSM. These SVSM attestation reports can be used to attest the
SVSM and any services running within the SVSM.
Extend the config-fs attestation support to allow for an SVSM attestation
report. This involves creating four (4) new config-fs attributes:
- 'service-provider' (input)
This attribute is used to determine whether the attestation request
should be sent to the specified service provider or to the SEV
firmware. The SVSM service provider is represented by the value
'svsm'.
- 'service_guid' (input)
Used for requesting the attestation of a single service within the
service provider. A null GUID implies that the SVSM_ATTEST_SERVICES
call should be used to request the attestation report. A non-null
GUID implies that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
- 'service_manifest_version' (input)
Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
represents a specific service manifest version be used for the
attestation report.
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation
report.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
Documentation/ABI/testing/configfs-tsm | 69 +++++++++++
arch/x86/include/asm/sev.h | 31 ++++-
arch/x86/kernel/sev.c | 50 ++++++++
drivers/virt/coco/sev-guest/sev-guest.c | 151 ++++++++++++++++++++++++
drivers/virt/coco/tsm.c | 93 ++++++++++++++-
include/linux/tsm.h | 11 ++
6 files changed, 402 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
index dd24202b5ba5..72a7acdb5258 100644
--- a/Documentation/ABI/testing/configfs-tsm
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -31,6 +31,21 @@ Description:
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+What: /sys/kernel/config/tsm/report/$name/manifestblob
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ manifest data is available.
+
+ When @provider is "sev_guest" and the @service_provider is
+ "svsm" this file contains the service manifest used for the SVSM
+ attestation report from the Secure VM Service Module for SEV-SNP
+ Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
What: /sys/kernel/config/tsm/report/$name/provider
Date: September, 2023
KernelVersion: v6.7
@@ -80,3 +95,57 @@ Contact: linux-coco@lists.linux.dev
Description:
(RO) Indicates the minimum permissible value that can be written
to @privlevel.
+
+What: /sys/kernel/config/tsm/report/$name/service_provider
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Specifying the service provider via this attribute will create
+ an attestation report as specified by the service provider.
+ Currently supported service-providers are:
+ svsm
+
+ For the SVSM service provider, see the Secure VM Service Module
+ for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What: /sys/kernel/config/tsm/report/$name/service_guid
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Specifying an empty/null GUID (00000000-0000-0000-0000-000000)
+ requests all active services within the service provider be
+ part of the attestation report. Specifying a GUID request
+ an attestation report of just the specified service using the
+ manifest form specified by the service_manifest_version
+ attribute.
+
+ For the SVSM service provider, see the Secure VM Service Module
+ for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What: /sys/kernel/config/tsm/report/$name/service_manifest_version
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Indicates the service manifest version requested for the
+ attestation report. If this field is not set by the user,
+ the default manifest version of the service (the service's
+ initial/first manifest version) is returned. The initial
+ manifest version is always available.
+
+ For the SVSM service provider, see the Secure VM Service Module
+ for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 066eb0ba3d63..94af7fb7a8e1 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -209,6 +209,27 @@ struct svsm_pvalidate_call {
struct svsm_pvalidate_entry entry[];
};
+/*
+ * The SVSM Attestation related structures
+ */
+struct svsm_location_entry {
+ u64 pa;
+ u32 len;
+ u8 rsvd[4];
+};
+
+struct svsm_attestation_call {
+ struct svsm_location_entry report_buffer;
+ struct svsm_location_entry nonce;
+ struct svsm_location_entry manifest_buffer;
+ struct svsm_location_entry certificates_buffer;
+
+ /* For attesting a single service */
+ u8 service_guid[16];
+ u32 service_manifest_version;
+ u8 rsvd[4];
+};
+
/*
* SVSM protocol structure
*/
@@ -232,6 +253,10 @@ struct svsm_call {
#define SVSM_CORE_CREATE_VCPU 2
#define SVSM_CORE_DELETE_VCPU 3
+#define SVSM_ATTEST_CALL(x) ((1ULL << 32) | (x))
+#define SVSM_ATTEST_SERVICES 0
+#define SVSM_ATTEST_SINGLE_SERVICE 1
+
#ifdef CONFIG_AMD_MEM_ENCRYPT
extern void __sev_es_ist_enter(struct pt_regs *regs);
extern void __sev_es_ist_exit(void);
@@ -302,6 +327,7 @@ void snp_set_wakeup_secondary_cpu(void);
bool snp_init(struct boot_params *bp);
void __noreturn snp_abort(void);
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio);
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input);
void snp_accept_memory(phys_addr_t start, phys_addr_t end);
u64 snp_get_unsupported_features(u64 status);
u64 sev_get_status(void);
@@ -333,7 +359,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
{
return -ENOTTY;
}
-
+static inline int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ return -ENOTTY;
+}
static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { }
static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
static inline u64 sev_get_status(void) { return 0; }
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 7e2b9934a95d..0a06632898c6 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2400,6 +2400,56 @@ static int __init init_sev_config(char *str)
}
__setup("sev=", init_sev_config);
+static void update_attestation_input(struct svsm_call *call, struct svsm_attestation_call *input)
+{
+ /* If (new) lengths have been returned, propograte them up */
+ if (call->rcx_out != call->rcx)
+ input->manifest_buffer.len = call->rcx_out;
+
+ if (call->rdx_out != call->rdx)
+ input->certificates_buffer.len = call->rdx_out;
+
+ if (call->r8_out != call->r8)
+ input->report_buffer.len = call->r8_out;
+}
+
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ struct svsm_attestation_call *attest_call;
+ struct svsm_call call = {};
+ unsigned long flags;
+ u64 attest_call_pa;
+ int ret;
+
+ if (!vmpl)
+ return -EINVAL;
+
+ local_irq_save(flags);
+
+ call.caa = __svsm_get_caa();
+
+ attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer;
+ attest_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
+
+ *attest_call = *input;
+
+ /*
+ * Set input registers for the request and set RDX and R8 to known
+ * values in order to detect length values being returned in them.
+ */
+ call.rax = call_id;
+ call.rcx = attest_call_pa;
+ call.rdx = -1;
+ call.r8 = -1;
+ ret = svsm_protocol(&call);
+ update_attestation_input(&call, input);
+
+ local_irq_restore(flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(snp_issue_svsm_attestation_request);
+
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio)
{
struct ghcb_state state;
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index bba6531cb606..0d2c9926a97c 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -38,6 +38,8 @@
#define SNP_REQ_MAX_RETRY_DURATION (60*HZ)
#define SNP_REQ_RETRY_DELAY (2*HZ)
+#define SVSM_MAX_RETRIES 3
+
struct snp_guest_crypto {
struct crypto_aead *tfm;
u8 *iv, *authtag;
@@ -783,6 +785,148 @@ struct snp_msg_cert_entry {
u32 length;
};
+static int sev_svsm_report_new(struct tsm_report *report, void *data)
+{
+ unsigned int report_len, manifest_len, certificates_len;
+ void *report_blob, *manifest_blob, *certificates_blob;
+ struct svsm_attestation_call attest_call = {};
+ struct tsm_desc *desc = &report->desc;
+ unsigned int retry_count;
+ unsigned int size;
+ bool try_again;
+ void *buffer;
+ u64 call_id;
+ int ret;
+
+ /*
+ * Allocate pages for the request:
+ * - Report blob (4K)
+ * - Manifest blob (4K)
+ * - Certificate blob (16K)
+ *
+ * Above addresses must be 4K aligned
+ */
+ report_len = SZ_4K;
+ manifest_len = SZ_4K;
+ certificates_len = SEV_FW_BLOB_MAX_SIZE;
+
+ if (guid_is_null(&desc->service_guid)) {
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES);
+ } else {
+ export_guid(attest_call.service_guid, &desc->service_guid);
+ attest_call.service_manifest_version = desc->service_manifest_version;
+
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
+ }
+
+ retry_count = 0;
+
+retry:
+ size = report_len + manifest_len + certificates_len;
+ buffer = alloc_pages_exact(size, __GFP_ZERO);
+ if (!buffer)
+ return -ENOMEM;
+
+ report_blob = buffer;
+ attest_call.report_buffer.pa = __pa(report_blob);
+ attest_call.report_buffer.len = report_len;
+
+ manifest_blob = report_blob + report_len;
+ attest_call.manifest_buffer.pa = __pa(manifest_blob);
+ attest_call.manifest_buffer.len = manifest_len;
+
+ certificates_blob = manifest_blob + manifest_len;
+ attest_call.certificates_buffer.pa = __pa(certificates_blob);
+ attest_call.certificates_buffer.len = certificates_len;
+
+ attest_call.nonce.pa = __pa(desc->inblob);
+ attest_call.nonce.len = desc->inblob_len;
+
+ ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
+ switch (ret) {
+ case SVSM_SUCCESS:
+ break;
+ case SVSM_ERR_INVALID_PARAMETER:
+ ret = -EINVAL;
+
+ if (retry_count >= SVSM_MAX_RETRIES)
+ goto error;
+
+ try_again = false;
+
+ if (attest_call.report_buffer.len > report_len) {
+ report_len = PAGE_ALIGN(attest_call.report_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.manifest_buffer.len > manifest_len) {
+ manifest_len = PAGE_ALIGN(attest_call.manifest_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.certificates_buffer.len > certificates_len) {
+ certificates_len = PAGE_ALIGN(attest_call.certificates_buffer.len);
+ try_again = true;
+ }
+
+ /* If one of the buffers wasn't large enough, retry the request */
+ if (try_again) {
+ free_pages_exact(buffer, size);
+ retry_count++;
+ goto retry;
+ }
+
+ goto error;
+ case SVSM_ERR_BUSY:
+ ret = -EAGAIN;
+ goto error;
+ default:
+ pr_err_ratelimited("SVSM attestation request failed (%#x)\n", ret);
+ ret = -EINVAL;
+ goto error;
+ }
+
+ ret = -ENOMEM;
+
+ report_len = attest_call.report_buffer.len;
+ void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL);
+ if (!rbuf)
+ goto error;
+
+ memcpy(rbuf, report_blob, report_len);
+ report->outblob = no_free_ptr(rbuf);
+ report->outblob_len = report_len;
+
+ manifest_len = attest_call.manifest_buffer.len;
+ void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL);
+ if (!mbuf)
+ goto error;
+
+ memcpy(mbuf, manifest_blob, manifest_len);
+ report->manifestblob = no_free_ptr(mbuf);
+ report->manifestblob_len = manifest_len;
+
+ certificates_len = attest_call.certificates_buffer.len;
+ if (!certificates_len)
+ goto success;
+
+ void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL);
+ if (!cbuf)
+ goto error;
+
+ memcpy(cbuf, certificates_blob, certificates_len);
+ report->auxblob = no_free_ptr(cbuf);
+ report->auxblob_len = certificates_len;
+
+success:
+ ret = 0;
+
+error:
+ free_pages_exact(buffer, size);
+
+ return ret;
+}
+
static int sev_report_new(struct tsm_report *report, void *data)
{
struct snp_msg_cert_entry *cert_table;
@@ -797,6 +941,13 @@ static int sev_report_new(struct tsm_report *report, void *data)
if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
return -EINVAL;
+ if (desc->service_provider) {
+ if (strcmp(desc->service_provider, "svsm"))
+ return -EINVAL;
+
+ return sev_svsm_report_new(report, data);
+ }
+
void *buf __free(kvfree) = kvzalloc(size, GFP_KERNEL);
if (!buf)
return -ENOMEM;
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index d1c2db83a8ca..46f230bf13ac 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -35,7 +35,7 @@ static DECLARE_RWSEM(tsm_rwsem);
* The attestation report format is TSM provider specific, when / if a standard
* materializes that can be published instead of the vendor layout. Until then
* the 'provider' attribute indicates the format of 'outblob', and optionally
- * 'auxblob'.
+ * 'auxblob' and 'manifestblob'.
*/
struct tsm_report_state {
@@ -48,6 +48,7 @@ struct tsm_report_state {
enum tsm_data_select {
TSM_REPORT,
TSM_CERTS,
+ TSM_MANIFEST,
};
static struct tsm_report *to_tsm_report(struct config_item *cfg)
@@ -119,6 +120,74 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
}
CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+static ssize_t tsm_report_service_provider_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ size_t sp_len;
+ char *sp;
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ sp_len = (buf[len - 1] != '\n') ? len : len - 1;
+
+ sp = kstrndup(buf, sp_len, GFP_KERNEL);
+ if (!sp)
+ return -ENOMEM;
+ kfree(report->desc.service_provider);
+
+ report->desc.service_provider = sp;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_provider);
+
+static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ report->desc.service_guid = guid_null;
+
+ rc = guid_parse(buf, &report->desc.service_guid);
+ if (rc)
+ return rc;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_guid);
+
+static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.service_manifest_version = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
+
static ssize_t tsm_report_inblob_write(struct config_item *cfg,
const void *buf, size_t count)
{
@@ -163,6 +232,9 @@ static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
if (select == TSM_REPORT) {
out = report->outblob;
len = report->outblob_len;
+ } else if (select == TSM_MANIFEST) {
+ out = report->manifestblob;
+ len = report->manifestblob_len;
} else {
out = report->auxblob;
len = report->auxblob_len;
@@ -188,7 +260,7 @@ static ssize_t read_cached_report(struct tsm_report *report, void *buf,
/*
* A given TSM backend always fills in ->outblob regardless of
- * whether the report includes an auxblob or not.
+ * whether the report includes an auxblob/manifestblob or not.
*/
if (!report->outblob ||
state->read_generation != state->write_generation)
@@ -224,8 +296,10 @@ static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
kvfree(report->outblob);
kvfree(report->auxblob);
+ kvfree(report->manifestblob);
report->outblob = NULL;
report->auxblob = NULL;
+ report->manifestblob = NULL;
rc = ops->report_new(report, provider.data);
if (rc < 0)
return rc;
@@ -252,6 +326,15 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
}
CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
+static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_MANIFEST);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
+
#define TSM_DEFAULT_ATTRS() \
&tsm_report_attr_generation, \
&tsm_report_attr_provider
@@ -265,6 +348,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
TSM_DEFAULT_ATTRS(),
&tsm_report_attr_privlevel,
&tsm_report_attr_privlevel_floor,
+ &tsm_report_attr_service_provider,
+ &tsm_report_attr_service_guid,
+ &tsm_report_attr_service_manifest_version,
NULL,
};
@@ -280,6 +366,7 @@ static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
TSM_DEFAULT_BIN_ATTRS(),
&tsm_report_attr_auxblob,
+ &tsm_report_attr_manifestblob,
NULL,
};
@@ -288,8 +375,10 @@ static void tsm_report_item_release(struct config_item *cfg)
struct tsm_report *report = to_tsm_report(cfg);
struct tsm_report_state *state = to_state(report);
+ kvfree(report->manifestblob);
kvfree(report->auxblob);
kvfree(report->outblob);
+ kfree(report->desc.service_provider);
kfree(state);
}
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index 50c5769657d8..27cc97fe8dcd 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -4,6 +4,7 @@
#include <linux/sizes.h>
#include <linux/types.h>
+#include <linux/uuid.h>
#define TSM_INBLOB_MAX 64
#define TSM_OUTBLOB_MAX SZ_32K
@@ -19,11 +20,17 @@
* @privlevel: optional privilege level to associate with @outblob
* @inblob_len: sizeof @inblob
* @inblob: arbitrary input data
+ * @service_provider: optional name of where to obtain the tsm report blob
+ * @service_guid: optional service-provider service guid to attest
+ * @service_manifest_version: optional service-provider service manifest version requested
*/
struct tsm_desc {
unsigned int privlevel;
size_t inblob_len;
u8 inblob[TSM_INBLOB_MAX];
+ char *service_provider;
+ guid_t service_guid;
+ unsigned int service_manifest_version;
};
/**
@@ -33,6 +40,8 @@ struct tsm_desc {
* @outblob: generated evidence to provider to the attestation agent
* @auxblob_len: sizeof(@auxblob)
* @auxblob: (optional) auxiliary data to the report (e.g. certificate data)
+ * @manifestblob_len: sizeof(@manifestblob)
+ * @manifestblob: (optional) manifest data associated with the report
*/
struct tsm_report {
struct tsm_desc desc;
@@ -40,6 +49,8 @@ struct tsm_report {
u8 *outblob;
size_t auxblob_len;
u8 *auxblob;
+ size_t manifestblob_len;
+ u8 *manifestblob;
};
/**
--
2.43.2
^ permalink raw reply related [relevance 10%]
* dm-devel has migrated to lists.linux.dev
@ 2023-10-06 23:29 10% Mike Snitzer
2023-10-06 23:43 9% ` Mike Snitzer
0 siblings, 1 reply; 200+ results
From: Mike Snitzer @ 2023-10-06 23:29 UTC (permalink / raw)
To: dm-devel
Hi,
As a dm-devel@redhat.com subscriber, you have been silently subscribed
to the new mailing list: dm-devel@lists.linux.dev.
Effective immediately, all dm-devel email should be addressed to:
dm-devel@lists.linux.dev
(I say this but my "git pull" request that I just sent to Linus, to
update the MAINTAINERS file accordingly, cc'd dm-devel@redhat.com --
dm-devel@redhat.com will still function as it has, but nobody should
use it moving forward).
If you do send email to dm-devel@redhat.com you will get this
auto-response:
As of 2023.10.06: dm-devel@redhat.com has migrated to
dm-devel@lists.linux.dev
If you were a dm-devel@redhat.com subscriber you have been silently
subscribed to dm-devel@lists.linux.dev
NOTE: If you were a dm-devel@redhat.com subscriber but you disabled
mail delivery: then you must subscribe to dm-devel@lists.linux.dev.
To do so please send email to: dm-devel+subscribe@lists.linux.dev
To unsubscribe from dm-devel@lists.linux.dev please send email to:
dm-devel+unsubscribe@lists.linux.dev
Thanks,
Mike
^ permalink raw reply [relevance 10%]
* [PATCH v7 5/5] dax: add a sysfs knob to control memmap_on_memory behavior
@ 2024-01-24 20:03 10% ` Vishal Verma
2024-01-24 20:03 9% ` [PATCH v7 3/5] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2024-01-24 20:03 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang, Andrew Morton,
Oscar Salvador
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Greg Kroah-Hartman, Matthew Wilcox, linux-mm,
Li Zhijian, Jonathan Cameron
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via
pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above
defaults if needed.
Cc: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Huang, Ying <ying.huang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
drivers/dax/bus.c | 43 +++++++++++++++++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-dax | 17 +++++++++++++
2 files changed, 60 insertions(+)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 0fd948a4443e..27c86d0ca711 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1349,6 +1349,48 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sysfs_emit(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ bool val;
+ int rc;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (val == true && !mhp_supports_memmap_on_memory()) {
+ dev_dbg(dev, "memmap_on_memory is not available\n");
+ return -EOPNOTSUPP;
+ }
+
+ rc = down_write_killable(&dax_dev_rwsem);
+ if (rc)
+ return rc;
+
+ if (dev_dax->memmap_on_memory != val && dev->driver &&
+ to_dax_drv(dev->driver)->type == DAXDRV_KMEM_TYPE) {
+ up_write(&dax_dev_rwsem);
+ return -EBUSY;
+ }
+
+ dev_dax->memmap_on_memory = val;
+ up_write(&dax_dev_rwsem);
+
+ return len;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1375,6 +1417,7 @@ static struct attribute *dev_dax_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
index 6359f7bc9bf4..b34266bfae49 100644
--- a/Documentation/ABI/testing/sysfs-bus-dax
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -134,3 +134,20 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: January, 2024
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
--
2.43.0
^ permalink raw reply related [relevance 10%]
* [PATCH 1/2] netfs, cachefiles: Change mailing list
@ 2024-01-22 11:50 10% ` David Howells
0 siblings, 0 replies; 200+ results
From: David Howells @ 2024-01-22 11:50 UTC (permalink / raw)
To: netfs
Cc: linux-cifs, linux-nfs, v9fs, Jeff Layton, linux-kernel,
Matthew Wilcox, David Howells, linux-mm, linux-cachefs,
linux-fsdevel, ceph-devel, linux-erofs, linux-afs,
Christian Brauner
The publicly accessible archives for Red Hat mailing lists stop at Oct
2023; messages sent after that time are in internal-only archives.
Change the netfs and cachefiles mailing list to one that has publicly
accessible archives:
netfs@lists.linux.dev
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jeff Layton <jlayton@kernel.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: netfs@lists.linux.dev
cc: linux-cachefs@redhat.com
cc: v9fs@lists.linux.dev
cc: linux-afs@lists.infradead.org
cc: ceph-devel@vger.kernel.org
cc: linux-cifs@vger.kernel.org
cc: linux-erofs@lists.ozlabs.org
cc: linux-nfs@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a69..ab5858d24ffc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4547,7 +4547,7 @@ F: drivers/net/ieee802154/ca8210.c
CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS
M: David Howells <dhowells@redhat.com>
-L: linux-cachefs@redhat.com (moderated for non-subscribers)
+L: netfs@lists.linux.dev
S: Supported
F: Documentation/filesystems/caching/cachefiles.rst
F: fs/cachefiles/
@@ -8223,7 +8223,7 @@ F: include/linux/iomap.h
FILESYSTEMS [NETFS LIBRARY]
M: David Howells <dhowells@redhat.com>
-L: linux-cachefs@redhat.com (moderated for non-subscribers)
+L: netfs@lists.linux.dev
L: linux-fsdevel@vger.kernel.org
S: Supported
F: Documentation/filesystems/caching/
^ permalink raw reply related [relevance 10%]
* [PATCH v5 4/4] dax: add a sysfs knob to control memmap_on_memory behavior
@ 2023-12-14 7:37 10% ` Vishal Verma
2023-12-14 7:37 9% ` [PATCH v5 1/4] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-14 7:37 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang, Andrew Morton,
Oscar Salvador
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Greg Kroah-Hartman, linux-mm, Li Zhijian,
Jonathan Cameron
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via
pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above
defaults if needed.
Cc: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
drivers/dax/bus.c | 38 +++++++++++++++++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-dax | 17 +++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 6226de131d17..f4d3beec507c 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1245,6 +1245,43 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ struct dax_device_driver *dax_drv;
+ ssize_t rc;
+ bool val;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (val == true && !mhp_supports_memmap_on_memory()) {
+ dev_dbg(dev, "memmap_on_memory is not available\n");
+ return -EOPNOTSUPP;
+ }
+
+ guard(device)(dev);
+ dax_drv = to_dax_drv(dev->driver);
+ if (dax_drv && dev_dax->memmap_on_memory != val &&
+ dax_drv->type == DAXDRV_KMEM_TYPE)
+ return -EBUSY;
+ dev_dax->memmap_on_memory = val;
+
+ return len;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1271,6 +1308,7 @@ static struct attribute *dev_dax_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
index 6359f7bc9bf4..40d9965733b2 100644
--- a/Documentation/ABI/testing/sysfs-bus-dax
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -134,3 +134,20 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: October, 2023
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
--
2.41.0
^ permalink raw reply related [relevance 10%]
* [PATCH v2 11/14] x86/sev: Extend the config-fs attestation support for an SVSM
@ 2024-03-08 18:35 10% ` Tom Lendacky
0 siblings, 0 replies; 200+ results
From: Tom Lendacky @ 2024-03-08 18:35 UTC (permalink / raw)
To: linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
Michael Roth, Ashish Kalra
When an SVSM is present, the guest can also request attestation reports
from the SVSM. These SVSM attestation reports can be used to attest the
SVSM and any services running within the SVSM.
Extend the config-fs attestation support to allow for an SVSM attestation
report. This involves creating four (4) new config-fs attributes:
- 'svsm' (input)
This attribute is used to determine whether the attestation request
should be sent to the SVSM or to the SEV firmware.
- 'service_guid' (input)
Used for requesting the attestation of a single service within the
SVSM. A null GUID implies that the SVSM_ATTEST_SERVICES call should
be used to request the attestation report. A non-null GUID implies
that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
- 'service_manifest_version' (input)
Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
represents a specific service manifest version be used for the
attestation report.
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation
report.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
Documentation/ABI/testing/configfs-tsm | 59 ++++++++++
arch/x86/include/asm/sev.h | 31 ++++-
arch/x86/kernel/sev.c | 50 ++++++++
drivers/virt/coco/sev-guest/sev-guest.c | 147 ++++++++++++++++++++++++
drivers/virt/coco/tsm.c | 95 ++++++++++++++-
include/linux/tsm.h | 11 ++
6 files changed, 390 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
index dd24202b5ba5..a4663610bf7c 100644
--- a/Documentation/ABI/testing/configfs-tsm
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -31,6 +31,21 @@ Description:
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+What: /sys/kernel/config/tsm/report/$name/manifestblob
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ manifest data is available.
+
+ When @provider is "sev_guest" and the "svsm" attribute is set
+ this file contains the service manifest used for the SVSM
+ attestation report from Secure VM Service Module for SEV-SNP
+ Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
What: /sys/kernel/config/tsm/report/$name/provider
Date: September, 2023
KernelVersion: v6.7
@@ -80,3 +95,47 @@ Contact: linux-coco@lists.linux.dev
Description:
(RO) Indicates the minimum permissible value that can be written
to @privlevel.
+
+What: /sys/kernel/config/tsm/report/$name/svsm
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Specifying a 1 (or other boolean
+ equivalent, e.g. "Y") implies that the attestation report
+ should come from the SVSM.
+ Secure VM Service Module for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What: /sys/kernel/config/tsm/report/$name/service_guid
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Specifying a empty or null GUID
+ (00000000-0000-0000-0000-000000) requests all active services
+ within the SVSM be part of the attestation report. Specifying
+ a non-null GUID requests an attestation report of just the
+ specified service using the manifest form specified by the
+ service_manifest_version attribute.
+ Secure VM Service Module for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What: /sys/kernel/config/tsm/report/$name/service_manifest_version
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Indicates the service manifest
+ version requested for the attestation report. If this field
+ is not set by the user, the default manifest version of the
+ service (the service's initial/first manifest version) is
+ returned. The initial manifest version is always available.
+ Secure VM Service Module for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 34bc84aee969..76fabc7b5e97 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -209,6 +209,27 @@ struct svsm_pvalidate_call {
struct svsm_pvalidate_entry entry[];
};
+/*
+ * The SVSM Attestation related structures
+ */
+struct svsm_location_entry {
+ u64 pa;
+ u32 len;
+ u8 rsvd[4];
+};
+
+struct svsm_attestation_call {
+ struct svsm_location_entry report_buffer;
+ struct svsm_location_entry nonce;
+ struct svsm_location_entry manifest_buffer;
+ struct svsm_location_entry certificates_buffer;
+
+ /* For attesting a single service */
+ u8 service_guid[16];
+ u32 service_manifest_version;
+ u8 rsvd[4];
+};
+
/*
* SVSM protocol structure
*/
@@ -232,6 +253,10 @@ struct svsm_call {
#define SVSM_CORE_CREATE_VCPU 2
#define SVSM_CORE_DELETE_VCPU 3
+#define SVSM_ATTEST_CALL(x) ((1ULL << 32) | (x))
+#define SVSM_ATTEST_SERVICES 0
+#define SVSM_ATTEST_SINGLE_SERVICE 1
+
#ifdef CONFIG_AMD_MEM_ENCRYPT
extern void __sev_es_ist_enter(struct pt_regs *regs);
extern void __sev_es_ist_exit(void);
@@ -302,6 +327,7 @@ void snp_set_wakeup_secondary_cpu(void);
bool snp_init(struct boot_params *bp);
void __noreturn snp_abort(void);
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio);
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input);
void snp_accept_memory(phys_addr_t start, phys_addr_t end);
u64 snp_get_unsupported_features(u64 status);
u64 sev_get_status(void);
@@ -333,7 +359,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
{
return -ENOTTY;
}
-
+static inline int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ return -ENOTTY;
+}
static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { }
static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
static inline u64 sev_get_status(void) { return 0; }
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 8682af55802c..4e460d9eba77 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2402,6 +2402,56 @@ static int __init init_sev_config(char *str)
}
__setup("sev=", init_sev_config);
+static void update_attestation_input(struct svsm_call *call, struct svsm_attestation_call *input)
+{
+ /* If (new) lengths have been returned, propograte them up */
+ if (call->rcx_out != call->rcx)
+ input->manifest_buffer.len = call->rcx_out;
+
+ if (call->rdx_out != call->rdx)
+ input->certificates_buffer.len = call->rdx_out;
+
+ if (call->r8_out != call->r8)
+ input->report_buffer.len = call->r8_out;
+}
+
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ struct svsm_attestation_call *attest_call;
+ struct svsm_call call = {};
+ unsigned long flags;
+ u64 attest_call_pa;
+ int ret;
+
+ if (!vmpl)
+ return -EINVAL;
+
+ local_irq_save(flags);
+
+ call.caa = __svsm_get_caa();
+
+ attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer;
+ attest_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
+
+ *attest_call = *input;
+
+ /*
+ * Set input registers for the request and set RDX and R8 to known
+ * values in order to detect length values being returned in them.
+ */
+ call.rax = call_id;
+ call.rcx = attest_call_pa;
+ call.rdx = -1;
+ call.r8 = -1;
+ ret = svsm_protocol(&call);
+ update_attestation_input(&call, input);
+
+ local_irq_restore(flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(snp_issue_svsm_attestation_request);
+
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio)
{
struct ghcb_state state;
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index bba6531cb606..9daec0ea386e 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -38,6 +38,8 @@
#define SNP_REQ_MAX_RETRY_DURATION (60*HZ)
#define SNP_REQ_RETRY_DELAY (2*HZ)
+#define SVSM_MAX_RETRIES 3
+
struct snp_guest_crypto {
struct crypto_aead *tfm;
u8 *iv, *authtag;
@@ -783,6 +785,148 @@ struct snp_msg_cert_entry {
u32 length;
};
+static int sev_svsm_report_new(struct tsm_report *report, void *data)
+{
+ unsigned int report_len, manifest_len, certificates_len;
+ void *report_blob, *manifest_blob, *certificates_blob;
+ struct svsm_attestation_call attest_call = {};
+ struct tsm_desc *desc = &report->desc;
+ unsigned int retry_count;
+ unsigned int size;
+ bool try_again;
+ void *buffer;
+ u64 call_id;
+ int ret;
+
+ /*
+ * Allocate pages for the request:
+ * - Report blob (4K)
+ * - Manifest blob (4K)
+ * - Certificate blob (16K)
+ *
+ * Above addresses must be 4K aligned
+ */
+ report_len = SZ_4K;
+ manifest_len = SZ_4K;
+ certificates_len = SEV_FW_BLOB_MAX_SIZE;
+
+ retry_count = 0;
+
+retry:
+ size = report_len + manifest_len + certificates_len;
+ buffer = alloc_pages_exact(size, __GFP_ZERO);
+ if (!buffer)
+ return -ENOMEM;
+
+ report_blob = buffer;
+ attest_call.report_buffer.pa = __pa(report_blob);
+ attest_call.report_buffer.len = report_len;
+
+ manifest_blob = report_blob + report_len;
+ attest_call.manifest_buffer.pa = __pa(manifest_blob);
+ attest_call.manifest_buffer.len = manifest_len;
+
+ certificates_blob = manifest_blob + manifest_len;
+ attest_call.certificates_buffer.pa = __pa(certificates_blob);
+ attest_call.certificates_buffer.len = certificates_len;
+
+ attest_call.nonce.pa = __pa(desc->inblob);
+ attest_call.nonce.len = desc->inblob_len;
+
+ if (guid_is_null(&desc->service_guid)) {
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES);
+ } else {
+ export_guid(attest_call.service_guid, &desc->service_guid);
+ attest_call.service_manifest_version = desc->service_manifest_version;
+
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
+ }
+
+ ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
+ switch (ret) {
+ case SVSM_SUCCESS:
+ break;
+ case SVSM_ERR_INVALID_PARAMETER:
+ ret = -EINVAL;
+
+ if (retry_count >= SVSM_MAX_RETRIES)
+ goto error;
+
+ try_again = false;
+
+ if (attest_call.report_buffer.len > report_len) {
+ report_len = PAGE_ALIGN(attest_call.report_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.manifest_buffer.len > manifest_len) {
+ manifest_len = PAGE_ALIGN(attest_call.manifest_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.certificates_buffer.len > certificates_len) {
+ certificates_len = PAGE_ALIGN(attest_call.certificates_buffer.len);
+ try_again = true;
+ }
+
+ /* If one of the buffers wasn't large enough, retry the request */
+ if (try_again) {
+ free_pages_exact(buffer, size);
+ retry_count++;
+ goto retry;
+ }
+
+ goto error;
+ case SVSM_ERR_BUSY:
+ ret = -EAGAIN;
+ goto error;
+ default:
+ pr_err_ratelimited("SVSM attestation request failed (%#x)\n", ret);
+ ret = -EINVAL;
+ goto error;
+ }
+
+ ret = -ENOMEM;
+
+ report_len = attest_call.report_buffer.len;
+ void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL);
+ if (!rbuf)
+ goto error;
+
+ memcpy(rbuf, report_blob, report_len);
+ report->outblob = no_free_ptr(rbuf);
+ report->outblob_len = report_len;
+
+ manifest_len = attest_call.manifest_buffer.len;
+ void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL);
+ if (!mbuf)
+ goto error;
+
+ memcpy(mbuf, manifest_blob, manifest_len);
+ report->manifestblob = no_free_ptr(mbuf);
+ report->manifestblob_len = manifest_len;
+
+ certificates_len = attest_call.certificates_buffer.len;
+ if (!certificates_len)
+ goto success;
+
+ void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL);
+ if (!cbuf)
+ goto error;
+
+ memcpy(cbuf, certificates_blob, certificates_len);
+ report->auxblob = no_free_ptr(cbuf);
+ report->auxblob_len = certificates_len;
+
+success:
+ ret = 0;
+
+error:
+ free_pages_exact(buffer, size);
+
+ return ret;
+}
+
static int sev_report_new(struct tsm_report *report, void *data)
{
struct snp_msg_cert_entry *cert_table;
@@ -797,6 +941,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
return -EINVAL;
+ if (desc->svsm)
+ return sev_svsm_report_new(report, data);
+
void *buf __free(kvfree) = kvzalloc(size, GFP_KERNEL);
if (!buf)
return -ENOMEM;
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index d1c2db83a8ca..07b4c95ce704 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -35,7 +35,7 @@ static DECLARE_RWSEM(tsm_rwsem);
* The attestation report format is TSM provider specific, when / if a standard
* materializes that can be published instead of the vendor layout. Until then
* the 'provider' attribute indicates the format of 'outblob', and optionally
- * 'auxblob'.
+ * 'auxblob' and 'manifestblob'.
*/
struct tsm_report_state {
@@ -48,6 +48,7 @@ struct tsm_report_state {
enum tsm_data_select {
TSM_REPORT,
TSM_CERTS,
+ TSM_MANIFEST,
};
static struct tsm_report *to_tsm_report(struct config_item *cfg)
@@ -119,6 +120,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
}
CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+static ssize_t tsm_report_svsm_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ bool val;
+ int rc;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.svsm = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, svsm);
+
+static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ size_t guid_len;
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ /* Obtain the GUID string length */
+ guid_len = (len && buf[len - 1] == '\n') ? len - 1 : len;
+ if (guid_len && guid_len != UUID_STRING_LEN)
+ return -EINVAL;
+
+ if (guid_len == UUID_STRING_LEN) {
+ rc = guid_parse(buf, &report->desc.service_guid);
+ if (rc)
+ return rc;
+ } else {
+ report->desc.service_guid = guid_null;
+ }
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_guid);
+
+static ssize_t tsm_report_service_manifest_version_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.service_manifest_version = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_manifest_version);
+
static ssize_t tsm_report_inblob_write(struct config_item *cfg,
const void *buf, size_t count)
{
@@ -163,6 +235,9 @@ static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
if (select == TSM_REPORT) {
out = report->outblob;
len = report->outblob_len;
+ } else if (select == TSM_MANIFEST) {
+ out = report->manifestblob;
+ len = report->manifestblob_len;
} else {
out = report->auxblob;
len = report->auxblob_len;
@@ -188,7 +263,7 @@ static ssize_t read_cached_report(struct tsm_report *report, void *buf,
/*
* A given TSM backend always fills in ->outblob regardless of
- * whether the report includes an auxblob or not.
+ * whether the report includes an auxblob/manifestblob or not.
*/
if (!report->outblob ||
state->read_generation != state->write_generation)
@@ -224,8 +299,10 @@ static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
kvfree(report->outblob);
kvfree(report->auxblob);
+ kvfree(report->manifestblob);
report->outblob = NULL;
report->auxblob = NULL;
+ report->manifestblob = NULL;
rc = ops->report_new(report, provider.data);
if (rc < 0)
return rc;
@@ -252,6 +329,15 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
}
CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
+static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_MANIFEST);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
+
#define TSM_DEFAULT_ATTRS() \
&tsm_report_attr_generation, \
&tsm_report_attr_provider
@@ -265,6 +351,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
TSM_DEFAULT_ATTRS(),
&tsm_report_attr_privlevel,
&tsm_report_attr_privlevel_floor,
+ &tsm_report_attr_svsm,
+ &tsm_report_attr_service_guid,
+ &tsm_report_attr_service_manifest_version,
NULL,
};
@@ -280,6 +369,7 @@ static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
TSM_DEFAULT_BIN_ATTRS(),
&tsm_report_attr_auxblob,
+ &tsm_report_attr_manifestblob,
NULL,
};
@@ -288,6 +378,7 @@ static void tsm_report_item_release(struct config_item *cfg)
struct tsm_report *report = to_tsm_report(cfg);
struct tsm_report_state *state = to_state(report);
+ kvfree(report->manifestblob);
kvfree(report->auxblob);
kvfree(report->outblob);
kfree(state);
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index 50c5769657d8..c4aed3059500 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -4,6 +4,7 @@
#include <linux/sizes.h>
#include <linux/types.h>
+#include <linux/uuid.h>
#define TSM_INBLOB_MAX 64
#define TSM_OUTBLOB_MAX SZ_32K
@@ -19,11 +20,17 @@
* @privlevel: optional privilege level to associate with @outblob
* @inblob_len: sizeof @inblob
* @inblob: arbitrary input data
+ * @svsm: optional indicator of where to obtain the tsm report blob
+ * @service_guid: optional SVSM service guid to attest
+ * @service_manifest_version: optional SVSM service manifest version requested
*/
struct tsm_desc {
unsigned int privlevel;
size_t inblob_len;
u8 inblob[TSM_INBLOB_MAX];
+ bool svsm;
+ guid_t service_guid;
+ unsigned int service_manifest_version;
};
/**
@@ -33,6 +40,8 @@ struct tsm_desc {
* @outblob: generated evidence to provider to the attestation agent
* @auxblob_len: sizeof(@auxblob)
* @auxblob: (optional) auxiliary data to the report (e.g. certificate data)
+ * @manifestblob_len: sizeof(@manifestblob)
+ * @manifestblob: (optional) manifest data associated with the report
*/
struct tsm_report {
struct tsm_desc desc;
@@ -40,6 +49,8 @@ struct tsm_report {
u8 *outblob;
size_t auxblob_len;
u8 *auxblob;
+ size_t manifestblob_len;
+ u8 *manifestblob;
};
/**
--
2.43.2
^ permalink raw reply related [relevance 10%]
* [PATCH v6 4/4] dax: add a sysfs knob to control memmap_on_memory behavior
@ 2023-12-15 5:25 10% ` Vishal Verma
2023-12-15 5:25 9% ` [PATCH v6 1/4] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-15 5:25 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang, Andrew Morton,
Oscar Salvador
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Greg Kroah-Hartman, linux-mm, Li Zhijian,
Jonathan Cameron
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via
pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above
defaults if needed.
Cc: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
drivers/dax/bus.c | 36 +++++++++++++++++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-dax | 17 ++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 6226de131d17..3622b3d1c0de 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1245,6 +1245,41 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sysfs_emit(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ ssize_t rc;
+ bool val;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (val == true && !mhp_supports_memmap_on_memory()) {
+ dev_dbg(dev, "memmap_on_memory is not available\n");
+ return -EOPNOTSUPP;
+ }
+
+ guard(device)(dev);
+ if (dev_dax->memmap_on_memory != val && dev->driver &&
+ to_dax_drv(dev->driver)->type == DAXDRV_KMEM_TYPE)
+ return -EBUSY;
+ dev_dax->memmap_on_memory = val;
+
+ return len;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1271,6 +1306,7 @@ static struct attribute *dev_dax_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
index 6359f7bc9bf4..b34266bfae49 100644
--- a/Documentation/ABI/testing/sysfs-bus-dax
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -134,3 +134,20 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: January, 2024
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
--
2.41.0
^ permalink raw reply related [relevance 10%]
* [PATCH v2] MAINTAINERS: Use a proper mailinglist for NXP i.MX development
@ 2024-02-22 13:06 10% Daniel Baluta (OSS)
0 siblings, 0 replies; 200+ results
From: Daniel Baluta (OSS) @ 2024-02-22 13:06 UTC (permalink / raw)
To: shawnguo
Cc: kernel, f.fainelli, kuba, abel.vesa, haibo.chen, peng.fan,
shengjiu.wang, frank.li, laurentiu.palcu, mirela.rabulea,
linux-kernel, daniel.baluta, aisheng.dong, linux-imx, a.fatoum
From: Daniel Baluta <daniel.baluta@nxp.com>
So far we used an internal linux-imx@nxp.com email address to
gather all patches related to NXP i.MX development.
Let's switch to an open mailing list that provides ability
for people from the community to subscribe and also have
a proper archive.
List interface at: https://lists.linux.dev.
Archive is at: https://lore.kernel.org/imx/
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
---
Changes since v1:
- changed from R to L as per Ahmad suggestion
- removed name 'NXP Linux Team' from list name as per Aisheng suggestion
MAINTAINERS | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a69..2344eda616f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2156,7 +2156,7 @@ M: Shawn Guo <shawnguo@kernel.org>
M: Sascha Hauer <s.hauer@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
R: Fabio Estevam <festevam@gmail.com>
-R: NXP Linux Team <linux-imx@nxp.com>
+L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
@@ -8489,7 +8489,7 @@ FREESCALE IMX / MXC FEC DRIVER
M: Wei Fang <wei.fang@nxp.com>
R: Shenwei Wang <shenwei.wang@nxp.com>
R: Clark Wang <xiaoning.wang@nxp.com>
-R: NXP Linux Team <linux-imx@nxp.com>
+L: imx@lists.linux.dev
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/fsl,fec.yaml
@@ -8524,7 +8524,7 @@ F: drivers/i2c/busses/i2c-imx.c
FREESCALE IMX LPI2C DRIVER
M: Dong Aisheng <aisheng.dong@nxp.com>
L: linux-i2c@vger.kernel.org
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
F: drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -15704,7 +15704,7 @@ F: drivers/iio/gyro/fxas21002c_spi.c
NXP i.MX 7D/6SX/6UL/93 AND VF610 ADC DRIVER
M: Haibo Chen <haibo.chen@nxp.com>
L: linux-iio@vger.kernel.org
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/fsl,imx7d-adc.yaml
F: Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml
@@ -15741,7 +15741,7 @@ F: drivers/gpu/drm/imx/dcss/
NXP i.MX 8QXP ADC DRIVER
M: Cai Huoqing <cai.huoqing@linux.dev>
M: Haibo Chen <haibo.chen@nxp.com>
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
@@ -15749,7 +15749,7 @@ F: drivers/iio/adc/imx8qxp-adc.c
NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
M: Mirela Rabulea <mirela.rabulea@nxp.com>
-R: NXP Linux Team <linux-imx@nxp.com>
+L: imx@lists.linux.dev
L: linux-media@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
@@ -15759,7 +15759,7 @@ NXP i.MX CLOCK DRIVERS
M: Abel Vesa <abelvesa@kernel.org>
R: Peng Fan <peng.fan@nxp.com>
L: linux-clk@vger.kernel.org
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git clk/imx
F: Documentation/devicetree/bindings/clock/imx*
@@ -19630,7 +19630,7 @@ F: drivers/mmc/host/sdhci-of-at91.c
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) NXP i.MX DRIVER
M: Haibo Chen <haibo.chen@nxp.com>
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
L: linux-mmc@vger.kernel.org
S: Maintained
F: drivers/mmc/host/sdhci-esdhc-imx.c
--
2.25.1
^ permalink raw reply related [relevance 10%]
* [PATCH] MAINTAINERS: Use a proper mailinglist for NXP i.MX development
@ 2024-02-20 16:40 10% Daniel Baluta (OSS)
0 siblings, 0 replies; 200+ results
From: Daniel Baluta (OSS) @ 2024-02-20 16:40 UTC (permalink / raw)
To: shawnguo
Cc: aisheng.dong, kernel, f.fainelli, kuba, abel.vesa, haibo.chen,
peng.fan, shengjiu.wang, Frank.Li, laurentiu.palcu,
mirela.rabulea, linux-kernel, Daniel Baluta
From: Daniel Baluta <daniel.baluta@nxp.com>
So far we used an internal linux-imx@nxp.com email address to
gather all patches related to NXP i.MX development.
Let's switch to an open mailing list that provides ability
for people from the community to subscribe and also have
a proper archive.
List interface at: https://lists.linux.dev.
Archive is at: https://lore.kernel.org/imx/
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
---
Shawn, can you please pick this up via your tree?
MAINTAINERS | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d1052fa6a69..3db382dc8f7b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2156,7 +2156,7 @@ M: Shawn Guo <shawnguo@kernel.org>
M: Sascha Hauer <s.hauer@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
R: Fabio Estevam <festevam@gmail.com>
-R: NXP Linux Team <linux-imx@nxp.com>
+R: NXP Linux Team <imx@lists.linux.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
@@ -8489,7 +8489,7 @@ FREESCALE IMX / MXC FEC DRIVER
M: Wei Fang <wei.fang@nxp.com>
R: Shenwei Wang <shenwei.wang@nxp.com>
R: Clark Wang <xiaoning.wang@nxp.com>
-R: NXP Linux Team <linux-imx@nxp.com>
+R: NXP Linux Team <imx@lists.linux.dev>
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/fsl,fec.yaml
@@ -8524,7 +8524,7 @@ F: drivers/i2c/busses/i2c-imx.c
FREESCALE IMX LPI2C DRIVER
M: Dong Aisheng <aisheng.dong@nxp.com>
L: linux-i2c@vger.kernel.org
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
F: drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -15704,7 +15704,7 @@ F: drivers/iio/gyro/fxas21002c_spi.c
NXP i.MX 7D/6SX/6UL/93 AND VF610 ADC DRIVER
M: Haibo Chen <haibo.chen@nxp.com>
L: linux-iio@vger.kernel.org
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/fsl,imx7d-adc.yaml
F: Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml
@@ -15741,7 +15741,7 @@ F: drivers/gpu/drm/imx/dcss/
NXP i.MX 8QXP ADC DRIVER
M: Cai Huoqing <cai.huoqing@linux.dev>
M: Haibo Chen <haibo.chen@nxp.com>
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
@@ -15749,7 +15749,7 @@ F: drivers/iio/adc/imx8qxp-adc.c
NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
M: Mirela Rabulea <mirela.rabulea@nxp.com>
-R: NXP Linux Team <linux-imx@nxp.com>
+R: NXP Linux Team <imx@lists.linux.dev>
L: linux-media@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
@@ -15759,7 +15759,7 @@ NXP i.MX CLOCK DRIVERS
M: Abel Vesa <abelvesa@kernel.org>
R: Peng Fan <peng.fan@nxp.com>
L: linux-clk@vger.kernel.org
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git clk/imx
F: Documentation/devicetree/bindings/clock/imx*
@@ -19630,7 +19630,7 @@ F: drivers/mmc/host/sdhci-of-at91.c
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) NXP i.MX DRIVER
M: Haibo Chen <haibo.chen@nxp.com>
-L: linux-imx@nxp.com
+L: imx@lists.linux.dev
L: linux-mmc@vger.kernel.org
S: Maintained
F: drivers/mmc/host/sdhci-esdhc-imx.c
--
2.25.1
^ permalink raw reply related [relevance 10%]
* [PATCH v3 2/2] dax: add a sysfs knob to control memmap_on_memory behavior
@ 2023-12-11 22:52 10% ` Vishal Verma
2023-12-11 22:52 9% ` [PATCH v3 1/2] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-11 22:52 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Li Zhijian, Jonathan Cameron
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via
pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above
defaults if needed.
Cc: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
drivers/dax/bus.c | 47 +++++++++++++++++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-dax | 17 ++++++++++++
2 files changed, 64 insertions(+)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 1ff1ab5fa105..2871e5188f0d 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1270,6 +1270,52 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct device_driver *drv = dev->driver;
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ struct dax_region *dax_region = dev_dax->region;
+ struct dax_device_driver *dax_drv = to_dax_drv(drv);
+ ssize_t rc;
+ bool val;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (dev_dax->memmap_on_memory == val)
+ return len;
+
+ device_lock(dax_region->dev);
+ if (!dax_region->dev->driver) {
+ device_unlock(dax_region->dev);
+ return -ENXIO;
+ }
+
+ if (dax_drv->type == DAXDRV_KMEM_TYPE) {
+ device_unlock(dax_region->dev);
+ return -EBUSY;
+ }
+
+ device_lock(dev);
+ dev_dax->memmap_on_memory = val;
+ device_unlock(dev);
+
+ device_unlock(dax_region->dev);
+ return len;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1296,6 +1342,7 @@ static struct attribute *dev_dax_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
index a61a7b186017..b1fd8bf8a7de 100644
--- a/Documentation/ABI/testing/sysfs-bus-dax
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -149,3 +149,20 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: October, 2023
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
--
2.41.0
^ permalink raw reply related [relevance 10%]
* [PATCH v4 3/3] dax: add a sysfs knob to control memmap_on_memory behavior
@ 2023-12-12 19:08 10% ` Vishal Verma
2023-12-12 19:08 9% ` [PATCH v4 1/3] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-12 19:08 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, Dave Jiang
Cc: linux-kernel, nvdimm, linux-cxl, David Hildenbrand, Dave Hansen,
Huang Ying, Li Zhijian, Jonathan Cameron
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via
pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above
defaults if needed.
Cc: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
drivers/dax/bus.c | 32 ++++++++++++++++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-dax | 17 +++++++++++++++++
2 files changed, 49 insertions(+)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index ce1356ac6dc2..423adee6f802 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1245,6 +1245,37 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dax_device_driver *dax_drv = to_dax_drv(dev->driver);
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ ssize_t rc;
+ bool val;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ guard(device)(dev);
+ if (dev_dax->memmap_on_memory != val &&
+ dax_drv->type == DAXDRV_KMEM_TYPE)
+ return -EBUSY;
+ dev_dax->memmap_on_memory = val;
+
+ return len;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1271,6 +1302,7 @@ static struct attribute *dev_dax_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
index a61a7b186017..b1fd8bf8a7de 100644
--- a/Documentation/ABI/testing/sysfs-bus-dax
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -149,3 +149,20 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: October, 2023
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
--
2.41.0
^ permalink raw reply related [relevance 10%]
* [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
@ 2024-01-26 22:16 10% ` Tom Lendacky
0 siblings, 0 replies; 200+ results
From: Tom Lendacky @ 2024-01-26 22:16 UTC (permalink / raw)
To: linux-kernel, x86
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Dan Williams,
Michael Roth, Ashish Kalra
When an SVSM is present, the guest can also request attestation reports
from the SVSM. These SVSM attestation reports can be used to attest the
SVSM and any services running within the SVSM.
Extend the config-fs attestation support to allow for an SVSM attestation
report. This involves creating four (4) new config-fs attributes:
- 'svsm' (input)
This attribute is used to determine whether the attestation request
should be sent to the SVSM or to the SEV firmware.
- 'service_guid' (input)
Used for requesting the attestation of a single service within the
SVSM. A null GUID implies that the SVSM_ATTEST_SERVICES call should
be used to request the attestation report. A non-null GUID implies
that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
- 'service_version' (input)
Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
represents a specific service manifest version be used for the
attestation report.
- 'manifestblob' (output)
Used to return the service manifest associated with the attestation
report.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
Documentation/ABI/testing/configfs-tsm | 55 ++++++++++
arch/x86/include/asm/sev.h | 31 +++++-
arch/x86/kernel/sev.c | 50 +++++++++
drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++
drivers/virt/coco/tsm.c | 95 +++++++++++++++-
include/linux/tsm.h | 11 ++
6 files changed, 376 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
index dd24202b5ba5..c5423987d323 100644
--- a/Documentation/ABI/testing/configfs-tsm
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -31,6 +31,21 @@ Description:
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+What: /sys/kernel/config/tsm/report/$name/manifestblob
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ manifest data is available.
+
+ When @provider is "sev_guest" and the "svsm" attribute is set
+ this file contains the service manifest used for the SVSM
+ attestation report from Secure VM Service Module for SEV-SNP
+ Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
What: /sys/kernel/config/tsm/report/$name/provider
Date: September, 2023
KernelVersion: v6.7
@@ -80,3 +95,43 @@ Contact: linux-coco@lists.linux.dev
Description:
(RO) Indicates the minimum permissible value that can be written
to @privlevel.
+
+What: /sys/kernel/config/tsm/report/$name/svsm
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Specifying any non-zero value
+ implies that the attestation report should come from the SVSM.
+ Secure VM Service Module for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What: /sys/kernel/config/tsm/report/$name/service_guid
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Specifying a empty or null GUID
+ (00000000-0000-0000-0000-000000) requests all active services
+ within the SVSM be part of the attestation report. Specifying
+ a non-null GUID requests an attestation report of just the
+ specified service using the manifest form specified by the
+ service_version attribute.
+ Secure VM Service Module for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
+
+What: /sys/kernel/config/tsm/report/$name/service_version
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running
+ under an SVSM, like SEV-SNP. Indicates the service manifest
+ version requested for the attestation report.
+ Secure VM Service Module for SEV-SNP Guests v1.00 Section 7.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index b126e50a1358..4cafa92d1d3e 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -194,6 +194,27 @@ struct svsm_pvalidate_call {
struct svsm_pvalidate_entry entry[];
};
+/*
+ * The SVSM Attestation related structures
+ */
+struct svsm_location_entry {
+ u64 pa;
+ u32 len;
+ u8 rsvd[4];
+};
+
+struct svsm_attestation_call {
+ struct svsm_location_entry report_buffer;
+ struct svsm_location_entry nonce;
+ struct svsm_location_entry manifest_buffer;
+ struct svsm_location_entry certificates_buffer;
+
+ /* For attesting a single service */
+ u8 service_guid[16];
+ u32 service_version;
+ u8 rsvd[4];
+};
+
/*
* SVSM protocol structure
*/
@@ -217,6 +238,10 @@ struct svsm_call {
#define SVSM_CORE_CREATE_VCPU 2
#define SVSM_CORE_DELETE_VCPU 3
+#define SVSM_ATTEST_CALL(x) ((1ULL << 32) | (x))
+#define SVSM_ATTEST_SERVICES 0
+#define SVSM_ATTEST_SINGLE_SERVICE 1
+
#ifdef CONFIG_AMD_MEM_ENCRYPT
extern void __sev_es_ist_enter(struct pt_regs *regs);
extern void __sev_es_ist_exit(void);
@@ -287,6 +312,7 @@ void snp_set_wakeup_secondary_cpu(void);
bool snp_init(struct boot_params *bp);
void __init __noreturn snp_abort(void);
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio);
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input);
void snp_accept_memory(phys_addr_t start, phys_addr_t end);
u64 snp_get_unsupported_features(u64 status);
u64 sev_get_status(void);
@@ -316,7 +342,10 @@ static inline int snp_issue_guest_request(u64 exit_code, struct snp_req_data *in
{
return -ENOTTY;
}
-
+static inline int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ return -ENOTTY;
+}
static inline void snp_accept_memory(phys_addr_t start, phys_addr_t end) { }
static inline u64 snp_get_unsupported_features(u64 status) { return 0; }
static inline u64 sev_get_status(void) { return 0; }
diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
index 849df3aae4e1..83bc5efa8fcf 100644
--- a/arch/x86/kernel/sev.c
+++ b/arch/x86/kernel/sev.c
@@ -2378,6 +2378,56 @@ static int __init init_sev_config(char *str)
}
__setup("sev=", init_sev_config);
+static void update_attestation_input(struct svsm_call *call, struct svsm_attestation_call *input)
+{
+ /* If (new) lengths have been returned, propograte them up */
+ if (call->rcx_out != call->rcx)
+ input->manifest_buffer.len = call->rcx_out;
+
+ if (call->rdx_out != call->rdx)
+ input->certificates_buffer.len = call->rdx_out;
+
+ if (call->r8_out != call->r8)
+ input->report_buffer.len = call->r8_out;
+}
+
+int snp_issue_svsm_attestation_request(u64 call_id, struct svsm_attestation_call *input)
+{
+ struct svsm_attestation_call *attest_call;
+ struct svsm_call call = {};
+ unsigned long flags;
+ u64 attest_call_pa;
+ int ret;
+
+ if (!vmpl)
+ return -EINVAL;
+
+ local_irq_save(flags);
+
+ call.caa = __svsm_get_caa();
+
+ attest_call = (struct svsm_attestation_call *)call.caa->svsm_buffer;
+ attest_call_pa = __svsm_get_caa_pa() + offsetof(struct svsm_ca, svsm_buffer);
+
+ memcpy(attest_call, input, sizeof(*attest_call));
+
+ /*
+ * Set input registers for the request and set RDX and R8 to known
+ * values in order to detect length values being returned in them.
+ */
+ call.rax = call_id;
+ call.rcx = attest_call_pa;
+ call.rdx = -1;
+ call.r8 = -1;
+ ret = svsm_protocol(&call);
+ update_attestation_input(&call, input);
+
+ local_irq_restore(flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(snp_issue_svsm_attestation_request);
+
int snp_issue_guest_request(u64 exit_code, struct snp_req_data *input, struct snp_guest_request_ioctl *rio)
{
struct ghcb_state state;
diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
index 1ff897913bf4..3693373c4227 100644
--- a/drivers/virt/coco/sev-guest/sev-guest.c
+++ b/drivers/virt/coco/sev-guest/sev-guest.c
@@ -783,6 +783,140 @@ struct snp_msg_cert_entry {
u32 length;
};
+static int sev_svsm_report_new(struct tsm_report *report, void *data)
+{
+ unsigned int report_len, manifest_len, certificates_len;
+ void *report_blob, *manifest_blob, *certificates_blob;
+ struct svsm_attestation_call attest_call = {};
+ struct tsm_desc *desc = &report->desc;
+ unsigned int size;
+ bool try_again;
+ void *buffer;
+ u64 call_id;
+ int ret;
+
+ /*
+ * Allocate pages for the request:
+ * - Report blob (4K)
+ * - Manifest blob (4K)
+ * - Certificate blob (16K)
+ *
+ * Above addresses must be 4K aligned
+ */
+ report_len = SZ_4K;
+ manifest_len = SZ_4K;
+ certificates_len = SEV_FW_BLOB_MAX_SIZE;
+
+retry:
+ size = report_len + manifest_len + certificates_len;
+ buffer = alloc_pages_exact(size, __GFP_ZERO);
+ if (!buffer)
+ return -ENOMEM;
+
+ report_blob = buffer;
+ attest_call.report_buffer.pa = __pa(report_blob);
+ attest_call.report_buffer.len = report_len;
+
+ manifest_blob = report_blob + report_len;
+ attest_call.manifest_buffer.pa = __pa(manifest_blob);
+ attest_call.manifest_buffer.len = manifest_len;
+
+ certificates_blob = manifest_blob + manifest_len;
+ attest_call.certificates_buffer.pa = __pa(certificates_blob);
+ attest_call.certificates_buffer.len = certificates_len;
+
+ attest_call.nonce.pa = __pa(desc->inblob);
+ attest_call.nonce.len = desc->inblob_len;
+
+ if (guid_is_null(&desc->service_guid)) {
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SERVICES);
+ } else {
+ export_guid(attest_call.service_guid, &desc->service_guid);
+ attest_call.service_version = desc->service_version;
+
+ call_id = SVSM_ATTEST_CALL(SVSM_ATTEST_SINGLE_SERVICE);
+ }
+
+ ret = snp_issue_svsm_attestation_request(call_id, &attest_call);
+ switch (ret) {
+ case SVSM_SUCCESS:
+ break;
+ case SVSM_ERR_INVALID_PARAMETER:
+ try_again = false;
+
+ if (attest_call.report_buffer.len > report_len) {
+ report_len = PAGE_ALIGN(attest_call.report_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.manifest_buffer.len > manifest_len) {
+ manifest_len = PAGE_ALIGN(attest_call.manifest_buffer.len);
+ try_again = true;
+ }
+
+ if (attest_call.certificates_buffer.len > certificates_len) {
+ certificates_len = PAGE_ALIGN(attest_call.certificates_buffer.len);
+ try_again = true;
+ }
+
+ /* If one of the buffers wasn't large enough, retry the request */
+ if (try_again) {
+ free_pages_exact(buffer, size);
+ goto retry;
+ }
+
+ ret = -EINVAL;
+ goto error;
+ case SVSM_ERR_BUSY:
+ ret = -EAGAIN;
+ goto error;
+ default:
+ pr_err_ratelimited("SVSM attestation request failed (%#x)\n", ret);
+ ret = -EINVAL;
+ goto error;
+ }
+
+ ret = -ENOMEM;
+
+ report_len = attest_call.report_buffer.len;
+ void *rbuf __free(kvfree) = kvzalloc(report_len, GFP_KERNEL);
+ if (!rbuf)
+ goto error;
+
+ memcpy(rbuf, report_blob, report_len);
+ report->outblob = no_free_ptr(rbuf);
+ report->outblob_len = report_len;
+
+ manifest_len = attest_call.manifest_buffer.len;
+ void *mbuf __free(kvfree) = kvzalloc(manifest_len, GFP_KERNEL);
+ if (!mbuf)
+ goto error;
+
+ memcpy(mbuf, manifest_blob, manifest_len);
+ report->manifestblob = no_free_ptr(mbuf);
+ report->manifestblob_len = manifest_len;
+
+ certificates_len = attest_call.certificates_buffer.len;
+ if (!certificates_len)
+ goto success;
+
+ void *cbuf __free(kvfree) = kvzalloc(certificates_len, GFP_KERNEL);
+ if (!cbuf)
+ goto error;
+
+ memcpy(cbuf, certificates_blob, certificates_len);
+ report->auxblob = no_free_ptr(cbuf);
+ report->auxblob_len = certificates_len;
+
+success:
+ ret = 0;
+
+error:
+ free_pages_exact(buffer, size);
+
+ return ret;
+}
+
static int sev_report_new(struct tsm_report *report, void *data)
{
struct snp_msg_cert_entry *cert_table;
@@ -797,6 +931,9 @@ static int sev_report_new(struct tsm_report *report, void *data)
if (desc->inblob_len != SNP_REPORT_USER_DATA_SIZE)
return -EINVAL;
+ if (desc->svsm)
+ return sev_svsm_report_new(report, data);
+
void *buf __free(kvfree) = kvzalloc(size, GFP_KERNEL);
if (!buf)
return -ENOMEM;
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index d1c2db83a8ca..33fa26406bc6 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -35,7 +35,7 @@ static DECLARE_RWSEM(tsm_rwsem);
* The attestation report format is TSM provider specific, when / if a standard
* materializes that can be published instead of the vendor layout. Until then
* the 'provider' attribute indicates the format of 'outblob', and optionally
- * 'auxblob'.
+ * 'auxblob' and 'manifestblob'.
*/
struct tsm_report_state {
@@ -48,6 +48,7 @@ struct tsm_report_state {
enum tsm_data_select {
TSM_REPORT,
TSM_CERTS,
+ TSM_MANIFEST,
};
static struct tsm_report *to_tsm_report(struct config_item *cfg)
@@ -119,6 +120,77 @@ static ssize_t tsm_report_privlevel_floor_show(struct config_item *cfg,
}
CONFIGFS_ATTR_RO(tsm_report_, privlevel_floor);
+static ssize_t tsm_report_svsm_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.svsm = !!val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, svsm);
+
+static ssize_t tsm_report_service_guid_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ size_t guid_len;
+ int rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+
+ /* Obtain the GUID string length */
+ guid_len = (len && buf[len - 1] == '\n') ? len - 1 : len;
+ if (guid_len && guid_len != UUID_STRING_LEN)
+ return -EINVAL;
+
+ if (guid_len == UUID_STRING_LEN) {
+ rc = guid_parse(buf, &report->desc.service_guid);
+ if (rc)
+ return rc;
+ } else {
+ report->desc.service_guid = guid_null;
+ }
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_guid);
+
+static ssize_t tsm_report_service_version_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+ rc = try_advance_write_generation(report);
+ if (rc)
+ return rc;
+ report->desc.service_version = val;
+
+ return len;
+}
+CONFIGFS_ATTR_WO(tsm_report_, service_version);
+
static ssize_t tsm_report_inblob_write(struct config_item *cfg,
const void *buf, size_t count)
{
@@ -163,6 +235,9 @@ static ssize_t __read_report(struct tsm_report *report, void *buf, size_t count,
if (select == TSM_REPORT) {
out = report->outblob;
len = report->outblob_len;
+ } else if (select == TSM_MANIFEST) {
+ out = report->manifestblob;
+ len = report->manifestblob_len;
} else {
out = report->auxblob;
len = report->auxblob_len;
@@ -188,7 +263,7 @@ static ssize_t read_cached_report(struct tsm_report *report, void *buf,
/*
* A given TSM backend always fills in ->outblob regardless of
- * whether the report includes an auxblob or not.
+ * whether the report includes an auxblob/manifestblob or not.
*/
if (!report->outblob ||
state->read_generation != state->write_generation)
@@ -224,8 +299,10 @@ static ssize_t tsm_report_read(struct tsm_report *report, void *buf,
kvfree(report->outblob);
kvfree(report->auxblob);
+ kvfree(report->manifestblob);
report->outblob = NULL;
report->auxblob = NULL;
+ report->manifestblob = NULL;
rc = ops->report_new(report, provider.data);
if (rc < 0)
return rc;
@@ -252,6 +329,15 @@ static ssize_t tsm_report_auxblob_read(struct config_item *cfg, void *buf,
}
CONFIGFS_BIN_ATTR_RO(tsm_report_, auxblob, NULL, TSM_OUTBLOB_MAX);
+static ssize_t tsm_report_manifestblob_read(struct config_item *cfg, void *buf,
+ size_t count)
+{
+ struct tsm_report *report = to_tsm_report(cfg);
+
+ return tsm_report_read(report, buf, count, TSM_MANIFEST);
+}
+CONFIGFS_BIN_ATTR_RO(tsm_report_, manifestblob, NULL, TSM_OUTBLOB_MAX);
+
#define TSM_DEFAULT_ATTRS() \
&tsm_report_attr_generation, \
&tsm_report_attr_provider
@@ -265,6 +351,9 @@ static struct configfs_attribute *tsm_report_extra_attrs[] = {
TSM_DEFAULT_ATTRS(),
&tsm_report_attr_privlevel,
&tsm_report_attr_privlevel_floor,
+ &tsm_report_attr_svsm,
+ &tsm_report_attr_service_guid,
+ &tsm_report_attr_service_version,
NULL,
};
@@ -280,6 +369,7 @@ static struct configfs_bin_attribute *tsm_report_bin_attrs[] = {
static struct configfs_bin_attribute *tsm_report_bin_extra_attrs[] = {
TSM_DEFAULT_BIN_ATTRS(),
&tsm_report_attr_auxblob,
+ &tsm_report_attr_manifestblob,
NULL,
};
@@ -288,6 +378,7 @@ static void tsm_report_item_release(struct config_item *cfg)
struct tsm_report *report = to_tsm_report(cfg);
struct tsm_report_state *state = to_state(report);
+ kvfree(report->manifestblob);
kvfree(report->auxblob);
kvfree(report->outblob);
kfree(state);
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index de8324a2223c..7c36b8448b4f 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -4,6 +4,7 @@
#include <linux/sizes.h>
#include <linux/types.h>
+#include <linux/uuid.h>
#define TSM_INBLOB_MAX 64
#define TSM_OUTBLOB_MAX SZ_32K
@@ -19,11 +20,17 @@
* @privlevel: optional privilege level to associate with @outblob
* @inblob_len: sizeof @inblob
* @inblob: arbitrary input data
+ * @svsm: optional indicator of where to obtain the tsm report blob
+ * @service_guid: optional SVSM service guid to attest
+ * @service_version: optional SVSM service manifest version requested
*/
struct tsm_desc {
unsigned int privlevel;
size_t inblob_len;
u8 inblob[TSM_INBLOB_MAX];
+ bool svsm;
+ guid_t service_guid;
+ unsigned int service_version;
};
/**
@@ -33,6 +40,8 @@ struct tsm_desc {
* @outblob: generated evidence to provider to the attestation agent
* @auxblob_len: sizeof(@auxblob)
* @auxblob: (optional) auxiliary data to the report (e.g. certificate data)
+ * @manifestblob_len: sizeof(@manifestblob)
+ * @manifestblob: (optional) manifest data associated with the report
*/
struct tsm_report {
struct tsm_desc desc;
@@ -40,6 +49,8 @@ struct tsm_report {
u8 *outblob;
size_t auxblob_len;
u8 *auxblob;
+ size_t manifestblob_len;
+ u8 *manifestblob;
};
/**
--
2.42.0
^ permalink raw reply related [relevance 10%]
* [PATCH] MAINTAINERS: update mailing list address for NTB subsystem
@ 2022-02-02 21:19 10% Dave Jiang
0 siblings, 0 replies; 200+ results
From: Dave Jiang @ 2022-02-02 21:19 UTC (permalink / raw)
To: jdmason; +Cc: ntb, allenbh, linux-ntb
NTB mailing list is moving from linux-ntb@googlegroups.com to
ntb@lists.linux.dev in order to get better archive and lore support.
Update all entries in MAINTAINERS.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
---
MAINTAINERS | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f41088418aae..cb118eccab20 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13679,7 +13679,7 @@ F: scripts/nsdeps
NTB AMD DRIVER
M: Sanjay R Mehta <sanju.mehta@amd.com>
M: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
-L: linux-ntb@googlegroups.com
+L: ntb@lists.linux.dev
S: Supported
F: drivers/ntb/hw/amd/
@@ -13687,7 +13687,7 @@ NTB DRIVER CORE
M: Jon Mason <jdmason@kudzu.us>
M: Dave Jiang <dave.jiang@intel.com>
M: Allen Hubbe <allenbh@gmail.com>
-L: linux-ntb@googlegroups.com
+L: ntb@lists.linux.dev
S: Supported
W: https://github.com/jonmason/ntb/wiki
T: git git://github.com/jonmason/ntb.git
@@ -13699,13 +13699,13 @@ F: tools/testing/selftests/ntb/
NTB IDT DRIVER
M: Serge Semin <fancer.lancer@gmail.com>
-L: linux-ntb@googlegroups.com
+L: ntb@lists.linux.dev
S: Supported
F: drivers/ntb/hw/idt/
NTB INTEL DRIVER
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-ntb@googlegroups.com
+L: ntb@lists.linux.dev
S: Supported
W: https://github.com/davejiang/linux/wiki
T: git https://github.com/davejiang/linux.git
^ permalink raw reply related [relevance 10%]
* [ndctl PATCH] ndctl: Update nvdimm mailing list address
@ 2021-05-18 22:25 10% ` Vishal Verma
0 siblings, 0 replies; 200+ results
From: Vishal Verma @ 2021-05-18 22:25 UTC (permalink / raw)
To: nvdimm; +Cc: linux-nvdimm, Dan Williams, Vishal Verma
The 'nvdimm' mailing list has moved from lists.01.org to
lists.linux.dev. Update CONTRIBUTING.md and configure.ac to reflect
this.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
configure.ac | 2 +-
CONTRIBUTING.md | 7 ++++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5ec8d2f..dc39dbe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ AC_PREREQ(2.60)
m4_include([version.m4])
AC_INIT([ndctl],
GIT_VERSION,
- [linux-nvdimm@lists.01.org],
+ [nvdimm@lists.linux.dev],
[ndctl],
[https://github.com/pmem/ndctl])
AC_CONFIG_SRCDIR([ndctl/lib/libndctl.c])
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4c29d31..4f4865d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -6,13 +6,14 @@ The following is a set of guidelines that we adhere to, and request that
contributors follow.
1. The libnvdimm (kernel subsystem) and ndctl developers primarily use
- the [linux-nvdimm](https://lists.01.org/postorius/lists/linux-nvdimm.lists.01.org/)
+ the [nvdimm](https://subspace.kernel.org/lists.linux.dev.html)
mailing list for everything. It is recommended to send patches to
- **```linux-nvdimm@lists.01.org```**
+ **```nvdimm@lists.linux.dev```**
+ An archive is available on [lore](https://lore.kernel.org/nvdimm/)
1. Github [issues](https://github.com/pmem/ndctl/issues) are an acceptable
way to report a problem, but if you just have a question,
- [email](mailto:linux-nvdimm@lists.01.org) the above list.
+ [email](mailto:nvdimm@lists.linux.dev) the above list.
1. We follow the Linux Kernel [Coding Style Guide][cs] as applicable.
base-commit: a2a6fda4d7e93044fca4c67870d2ff7e193d3cf1
prerequisite-patch-id: 8fc5baaf64b312b2459acea255740f79a23b76cd
--
2.31.1
^ permalink raw reply related [relevance 10%]
* + docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch added to mm-unstable branch
@ 2023-09-10 20:47 10% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-09-10 20:47 UTC (permalink / raw)
To: mm-commits, rostedt, corbet, sj, akpm
The patch titled
Subject: Docs/admin-guide/mm/damon/usage: move debugfs intro to the bottom of the section
has been added to the -mm mm-unstable branch. Its filename is
docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: Docs/admin-guide/mm/damon/usage: move debugfs intro to the bottom of the section
Date: Thu, 7 Sep 2023 02:29:21 +0000
On the DAMON usage introduction section, the introduction of DAMON
debugfs interface, which is deprecated, is above kernel API, which is
actively supported. Move the DAMON debugfs intro to bottom, so that
readers have less chances to read it.
Link: https://lkml.kernel.org/r/20230907022929.91361-4-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/Documentation/admin-guide/mm/damon/usage.rst~docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section
+++ a/Documentation/admin-guide/mm/damon/usage.rst
@@ -20,18 +20,18 @@ DAMON provides below interfaces for diff
you can write and use your personalized DAMON sysfs wrapper programs that
reads/writes the sysfs files instead of you. The `DAMON user space tool
<https://github.com/awslabs/damo>`_ is one example of such programs.
-- *debugfs interface. (DEPRECATED!)*
- :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This is deprecated, so users should move to the
- :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
- move, please report your usecase to damon@lists.linux.dev and
- linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </mm/damon/api>`.
+- *debugfs interface. (DEPRECATED!)*
+ :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
+ <sysfs_interface>`. This is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
.. _sysfs_interface:
_
Patches currently in -mm which might be from sj@kernel.org are
docs-admin-guide-mm-damon-usage-fixup-missed-ref-keyword.patch
docs-admin-guide-mm-damon-usage-place-debugfs-usage-at-the-bottom.patch
docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch
docs-mm-damon-design-explicitly-introduce-nr_accesses.patch
docs-admin-guide-mm-damon-usage-explain-the-format-of-damon_aggregate-tracepoint.patch
docs-mm-damon-design-add-a-section-for-kdamond-and-damon-context.patch
docs-admin-guide-mm-damon-usage-link-design-doc-for-details-of-kdamond-and-context.patch
mm-damon-core-fix-a-comment-about-damon_set_attrs-call-timings.patch
mm-damon-core-add-more-comments-for-nr_accesses.patch
mm-damon-core-remove-duplicated-comment-for-watermarks-based-deactivation.patch
mm-damon-core-remove-struct-target-parameter-from-damon_aggregated-tracepoint.patch
^ permalink raw reply [relevance 10%]
* + documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch added to mm-unstable branch
@ 2024-01-26 2:16 10% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-01-26 2:16 UTC (permalink / raw)
To: mm-commits, ying.huang, willy, osalvador, nvdimm, mhocko,
lizhijian, Jonathan.Cameron, gregkh, david, dave.jiang,
dave.hansen, dan.j.williams, vishal.l.verma, akpm
The patch titled
Subject: Documentatiion/ABI: add ABI documentation for sys-bus-dax
has been added to the -mm mm-unstable branch. Its filename is
documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Vishal Verma <vishal.l.verma@intel.com>
Subject: Documentatiion/ABI: add ABI documentation for sys-bus-dax
Date: Wed, 24 Jan 2024 12:03:48 -0800
Add the missing sysfs ABI documentation for the device DAX subsystem.
Various ABI attributes under this have been present since v5.1, and more
have been added over time. In preparation for adding a new attribute,
add this file with the historical details.
Link: https://lkml.kernel.org/r/20240124-vv-dax_abi-v7-3-20d16cb8d23d@intel.com
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Li Zhijian <lizhijian@fujitsu.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <nvdimm@lists.linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/testing/sysfs-bus-dax | 136 ++++++++++++++++++++++
1 file changed, 136 insertions(+)
--- /dev/null
+++ a/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,136 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range. The 'end' attribute
+ indicates the end physical address for the given range. The
+ 'page_offset' attribute indicates the offset of the current
+ range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
_
Patches currently in -mm which might be from vishal.l.verma@intel.com are
dax-busc-replace-driver-core-lock-usage-by-a-local-rwsem.patch
dax-busc-replace-several-sprintf-with-sysfs_emit.patch
documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch
mm-memory_hotplug-export-mhp_supports_memmap_on_memory.patch
dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch
^ permalink raw reply [relevance 10%]
* linux-lvm has migrated to lists.linux.dev [was: Re: Welcome to the "linux-lvm" mailing list]
[not found] <mailman.0.1697833421.3533607.linux-lvm@redhat.com>
@ 2023-10-20 21:31 11% ` Mike Snitzer
0 siblings, 0 replies; 200+ results
From: Mike Snitzer @ 2023-10-20 21:31 UTC (permalink / raw)
To: linux-lvm
Hi,
[Sorry for the noise of the previous mailman email, please ignore it.]
As a linux-lvm@redhat.com subscriber, you have been silently subscribed
to the new mailing list: linux-lvm@lists.linux.dev.
Effective immediately, all linux-lvm email should be addressed to:
linux-lvm@lists.linux.dev
If you do send email to linux-lvm@redhat.com you will get this
auto-response:
Your email to linux-lvm@redhat.com was delivered using
linux-lvm@lists.linux.dev because:
As of 2023.10.20: linux-lvm@redhat.com has migrated to
linux-lvm@lists.linux.dev
Please update the linux-lvm address to linux-lvm@lists.linux.dev
If you were a linux-lvm@redhat.com subscriber you have been silently
subscribed to linux-lvm@lists.linux.dev
Please be sure to update any linux-lvm mail filter you may have to look
for this in mail headers:
List-Id: <linux-lvm.lists.linux.dev>
NOTE: If you, or a friend, were a linux-lvm@redhat.com subscriber
with disabled mail delivery: then you must subscribe to
linux-lvm@lists.linux.dev. To do so please send email to:
linux-lvm+subscribe@lists.linux.dev
To unsubscribe from linux-lvm@lists.linux.dev please send email to:
linux-lvm+unsubscribe@lists.linux.dev
The linux-lvm list archive is now here:
https://lore.kernel.org/linux-lvm/
Please let me know if you have any questions or concerns.
Thanks,
Mike
^ permalink raw reply [relevance 11%]
* [PATCH] MAINTAINERS: Move nvdimm mailing list
@ 2021-04-21 7:05 11% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2021-04-21 7:05 UTC (permalink / raw)
To: linux-nvdimm
Cc: Ira Weiny, Oliver O'Halloran, Matthew Wilcox, Jan Kara,
Jonathan Corbet, Dave Jiang, Vishal Verma, nvdimm, linux-kernel
After seeing some users have subscription management trouble, more spam
than other Linux development lists, and considering some of the benefits
of kernel.org hosted lists, nvdimm and persistent memory development is
moving to nvdimm@lists.linux.dev.
The old list will remain up until v5.14-rc1 and shutdown thereafter.
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Oliver O'Halloran <oohall@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/obsolete/sysfs-class-dax | 2 +
Documentation/ABI/removed/sysfs-bus-nfit | 2 +
Documentation/ABI/testing/sysfs-bus-nfit | 40 +++++++++++++------------
Documentation/ABI/testing/sysfs-bus-papr-pmem | 4 +--
Documentation/driver-api/nvdimm/nvdimm.rst | 2 +
MAINTAINERS | 14 ++++-----
6 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/Documentation/ABI/obsolete/sysfs-class-dax b/Documentation/ABI/obsolete/sysfs-class-dax
index 0faf1354cd05..5bcce27458e3 100644
--- a/Documentation/ABI/obsolete/sysfs-class-dax
+++ b/Documentation/ABI/obsolete/sysfs-class-dax
@@ -1,7 +1,7 @@
What: /sys/class/dax/
Date: May, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description: Device DAX is the device-centric analogue of Filesystem
DAX (CONFIG_FS_DAX). It allows memory ranges to be
allocated and mapped without need of an intervening file
diff --git a/Documentation/ABI/removed/sysfs-bus-nfit b/Documentation/ABI/removed/sysfs-bus-nfit
index ae8c1ca53828..277437005def 100644
--- a/Documentation/ABI/removed/sysfs-bus-nfit
+++ b/Documentation/ABI/removed/sysfs-bus-nfit
@@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/regionX/nfit/ecc_unit_size
Date: Aug, 2017
KernelVersion: v4.14 (Removed v4.18)
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Size of a write request to a DIMM that will not incur a
read-modify-write cycle at the memory controller.
diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit
index 63ef0b9ecce7..e7282d184a74 100644
--- a/Documentation/ABI/testing/sysfs-bus-nfit
+++ b/Documentation/ABI/testing/sysfs-bus-nfit
@@ -5,7 +5,7 @@ Interface Table (NFIT)' section in the ACPI specification
What: /sys/bus/nd/devices/nmemX/nfit/serial
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Serial number of the NVDIMM (non-volatile dual in-line
memory module), assigned by the module vendor.
@@ -14,7 +14,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/handle
Date: Apr, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The address (given by the _ADR object) of the device on its
parent bus of the NVDIMM device containing the NVDIMM region.
@@ -23,7 +23,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/device
Date: Apr, 2015
KernelVersion: v4.1
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Device id for the NVDIMM, assigned by the module vendor.
@@ -31,7 +31,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/rev_id
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Revision of the NVDIMM, assigned by the module vendor.
@@ -39,7 +39,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/phys_id
Date: Apr, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Handle (i.e., instance number) for the SMBIOS (system
management BIOS) Memory Device structure describing the NVDIMM
@@ -49,7 +49,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/flags
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The flags in the NFIT memory device sub-structure indicate
the state of the data on the nvdimm relative to its energy
@@ -68,7 +68,7 @@ What: /sys/bus/nd/devices/nmemX/nfit/format1
What: /sys/bus/nd/devices/nmemX/nfit/formats
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The interface codes indicate support for persistent memory
mapped directly into system physical address space and / or a
@@ -84,7 +84,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/vendor
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Vendor id of the NVDIMM.
@@ -92,7 +92,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/dsm_mask
Date: May, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported device specific control
functions relative to the NVDIMM command family supported by the
@@ -102,7 +102,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/family
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Displays the NVDIMM family command sets. Values
0, 1, 2 and 3 correspond to NVDIMM_FAMILY_INTEL,
@@ -118,7 +118,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/id
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI specification 6.2 section 5.2.25.9, defines an
identifier for an NVDIMM, which refelects the id attribute.
@@ -127,7 +127,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system vendor id of the NVDIMM non-volatile memory
subsystem controller.
@@ -136,7 +136,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_rev_id
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system revision id of the NVDIMM non-volatile memory subsystem
controller, assigned by the non-volatile memory subsystem
@@ -146,7 +146,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_device
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system device id for the NVDIMM non-volatile memory
subsystem controller, assigned by the non-volatile memory
@@ -156,7 +156,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/revision
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI NFIT table revision number.
@@ -164,7 +164,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/scrub
Date: Sep, 2016
KernelVersion: v4.9
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RW) This shows the number of full Address Range Scrubs (ARS)
that have been completed since driver load time. Userspace can
@@ -177,7 +177,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/hw_error_scrub
Date: Sep, 2016
KernelVersion: v4.9
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RW) Provides a way to toggle the behavior between just adding
the address (cache line) where the MCE happened to the poison
@@ -196,7 +196,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/dsm_mask
Date: Jun, 2017
KernelVersion: v4.13
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported bus specific control
functions. See the section named 'NVDIMM Root Device _DSMs' in
@@ -205,7 +205,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle
Date: Apr, 2020
KernelVersion: v5.8
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RW) The Intel platform implementation of firmware activate
support exposes an option let the platform force idle devices in
@@ -225,7 +225,7 @@ Description:
What: /sys/bus/nd/devices/regionX/nfit/range_index
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) A unique number provided by the BIOS to identify an address
range. Used by NVDIMM Region Mapping Structure to uniquely refer
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 8316c33862a0..92e2db0e2d3d 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/nmemX/papr/flags
Date: Apr, 2020
KernelVersion: v5.8
-Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report flags indicating various states of a
papr-pmem NVDIMM device. Each flag maps to a one or
@@ -36,7 +36,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
Date: May, 2020
KernelVersion: v5.9
-Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report various performance stats related to papr-scm NVDIMM
device. Each stat is reported on a new line with each line
diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst
index ef6d59e0978e..1d8302b89bd4 100644
--- a/Documentation/driver-api/nvdimm/nvdimm.rst
+++ b/Documentation/driver-api/nvdimm/nvdimm.rst
@@ -4,7 +4,7 @@ LIBNVDIMM: Non-Volatile Devices
libnvdimm - kernel / libndctl - userspace helper library
-linux-nvdimm@lists.01.org
+nvdimm@lists.linux.dev
Version 13
diff --git a/MAINTAINERS b/MAINTAINERS
index 9450e052f1b1..4d18fa67f71b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5146,7 +5146,7 @@ DEVICE DIRECT ACCESS (DAX)
M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
F: drivers/dax/
@@ -6887,7 +6887,7 @@ M: Dan Williams <dan.j.williams@intel.com>
R: Matthew Wilcox <willy@infradead.org>
R: Jan Kara <jack@suse.cz>
L: linux-fsdevel@vger.kernel.org
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
F: fs/dax.c
F: include/linux/dax.h
@@ -10146,7 +10146,7 @@ LIBNVDIMM BLK: MMIO-APERTURE DRIVER
M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
@@ -10157,7 +10157,7 @@ LIBNVDIMM BTT: BLOCK TRANSLATION TABLE
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dan Williams <dan.j.williams@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
@@ -10167,7 +10167,7 @@ LIBNVDIMM PMEM: PERSISTENT MEMORY DRIVER
M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
@@ -10175,7 +10175,7 @@ F: drivers/nvdimm/pmem*
LIBNVDIMM: DEVICETREE BINDINGS
M: Oliver O'Halloran <oohall@gmail.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
F: Documentation/devicetree/bindings/pmem/pmem-region.txt
@@ -10186,7 +10186,7 @@ M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
M: Ira Weiny <ira.weiny@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
^ permalink raw reply related [relevance 11%]
* [PATCH v2 2/2] dax: add a sysfs knob to control memmap_on_memory behavior
@ 2023-12-07 4:36 11% ` Vishal Verma
2023-12-07 4:36 9% ` [PATCH v2 1/2] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
1 sibling, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-07 4:36 UTC (permalink / raw)
To: Dave Jiang
Cc: Dan Williams, linux-kernel, nvdimm, linux-cxl, Vishal Verma,
David Hildenbrand, Dave Hansen, Huang Ying, Jonathan Cameron
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via
pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above
defaults if needed.
Cc: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
drivers/dax/bus.c | 40 +++++++++++++++++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-dax | 13 +++++++++++
2 files changed, 53 insertions(+)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 1ff1ab5fa105..11abb57cc031 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1270,6 +1270,45 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ struct dax_region *dax_region = dev_dax->region;
+ ssize_t rc;
+ bool val;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (dev_dax->memmap_on_memory == val)
+ return len;
+
+ device_lock(dax_region->dev);
+ if (!dax_region->dev->driver) {
+ device_unlock(dax_region->dev);
+ return -ENXIO;
+ }
+
+ device_lock(dev);
+ dev_dax->memmap_on_memory = val;
+ device_unlock(dev);
+
+ device_unlock(dax_region->dev);
+ return rc == 0 ? len : rc;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1296,6 +1335,7 @@ static struct attribute *dev_dax_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
index a61a7b186017..bb063a004e41 100644
--- a/Documentation/ABI/testing/sysfs-bus-dax
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -149,3 +149,16 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: October, 2023
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on+memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram).
--
2.41.0
^ permalink raw reply related [relevance 11%]
* [PATCH 2/2] dax: add a sysfs knob to control memmap_on_memory behavior
@ 2023-12-07 4:29 11% ` Vishal Verma
0 siblings, 0 replies; 200+ results
From: Vishal Verma @ 2023-12-07 4:29 UTC (permalink / raw)
To: Dan Williams, Vishal Verma
Cc: David Hildenbrand, Dave Jiang, Dave Hansen, Huang Ying,
Jonathan Cameron, nvdimm
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via
pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above
defaults if needed.
Cc: David Hildenbrand <david@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
drivers/dax/bus.c | 40 +++++++++++++++++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-dax | 13 +++++++++++
2 files changed, 53 insertions(+)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 1ff1ab5fa105..11abb57cc031 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -1270,6 +1270,45 @@ static ssize_t numa_node_show(struct device *dev,
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sprintf(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ struct dax_region *dax_region = dev_dax->region;
+ ssize_t rc;
+ bool val;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (dev_dax->memmap_on_memory == val)
+ return len;
+
+ device_lock(dax_region->dev);
+ if (!dax_region->dev->driver) {
+ device_unlock(dax_region->dev);
+ return -ENXIO;
+ }
+
+ device_lock(dev);
+ dev_dax->memmap_on_memory = val;
+ device_unlock(dev);
+
+ device_unlock(dax_region->dev);
+ return rc == 0 ? len : rc;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1296,6 +1335,7 @@ static struct attribute *dev_dax_attributes[] = {
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
index a61a7b186017..bb063a004e41 100644
--- a/Documentation/ABI/testing/sysfs-bus-dax
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -149,3 +149,16 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: October, 2023
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on+memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram).
--
2.41.0
^ permalink raw reply related [relevance 11%]
* [PATCH] MAINTAINERS: Add new IOMMU development mailing list
@ 2022-06-25 4:50 11% Satish Nagireddy
0 siblings, 0 replies; 200+ results
From: Satish Nagireddy @ 2022-06-25 4:50 UTC (permalink / raw)
To: satish.nagireddy1; +Cc: Joerg Roedel, stable
From: Joerg Roedel <jroedel@suse.de>
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches. After July 5th the old list will disappear.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20220624125139.412-1-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3cf9842d9233..36d1bc999815 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -427,6 +427,7 @@ ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
F: include/linux/acpi_viot.h
@@ -960,6 +961,7 @@ AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/amd/
@@ -5962,6 +5964,7 @@ M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -5974,6 +5977,7 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7558,6 +7562,7 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9977,6 +9982,7 @@ INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/intel/
@@ -10356,6 +10362,7 @@ IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: Documentation/devicetree/bindings/iommu/
@@ -12504,6 +12511,7 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/iommu/mediatek*
@@ -16545,6 +16553,7 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -19170,6 +19179,7 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -21844,6 +21854,7 @@ M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
--
2.32.1 (Apple Git-133)
--
*Confidentiality Note:* We care about protecting our proprietary
information, confidential material, and trade secrets. This message may
contain some or all of those things. Cruise will suffer material harm if
anyone other than the intended recipient disseminates or takes any action
based on this message. If you have received this message (including any
attachments) in error, please delete it immediately and notify the sender
promptly.
^ permalink raw reply related [relevance 11%]
* [PATCH] MAINTAINERS: update lists.linuxfoundation.org migrated lists
@ 2023-11-07 20:00 11% Konstantin Ryabitsev
0 siblings, 0 replies; 200+ results
From: Konstantin Ryabitsev @ 2023-11-07 20:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: virtualization, acpica-devel, bridge, linux-kernel,
Konstantin Ryabitsev
The mailman-2 system behind lists.linux[-]foundation.org is being
retired, so the lists are being migrated to lists.linux.dev. Since both
domains belong to LF and setting up proper forwards is possible, the old
addresses will continue to work for a while, but all new patches should
be sent to the new canonical addresses for each list.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
Linus:
Normally, these would go through individual subsystems, but it's one of
those one-off changes that don't really bubble up in a natural way. If
you would like to pull this in through someone else's tree, please let
me know to whom I should send this instead.
---
MAINTAINERS | 50 +++++++++++++++++++++++++-------------------------
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index dd5de540ec0b..9f155f96f0ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -309,7 +309,7 @@ ACPI COMPONENT ARCHITECTURE (ACPICA)
M: Robert Moore <robert.moore@intel.com>
M: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
L: linux-acpi@vger.kernel.org
-L: acpica-devel@lists.linuxfoundation.org
+L: acpica-devel@lists.linux.dev
S: Supported
W: https://acpica.org/
W: https://github.com/acpica/acpica/
@@ -6453,7 +6453,7 @@ F: drivers/gpu/drm/ast/
DRM DRIVER FOR BOCHS VIRTUAL GPU
M: Gerd Hoffmann <kraxel@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/gpu/drm/tiny/bochs.c
@@ -6699,7 +6699,7 @@ F: drivers/gpu/drm/tiny/repaper.c
DRM DRIVER FOR QEMU'S CIRRUS DEVICE
M: Dave Airlie <airlied@redhat.com>
M: Gerd Hoffmann <kraxel@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Obsolete
W: https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
T: git git://anongit.freedesktop.org/drm/drm-misc
@@ -6708,7 +6708,7 @@ F: drivers/gpu/drm/tiny/cirrus.c
DRM DRIVER FOR QXL VIRTUAL GPU
M: Dave Airlie <airlied@redhat.com>
M: Gerd Hoffmann <kraxel@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: spice-devel@lists.freedesktop.org
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
@@ -7775,7 +7775,7 @@ F: drivers/net/can/usb/etas_es58x/
ETHERNET BRIDGE
M: Roopa Prabhu <roopa@nvidia.com>
M: Nikolay Aleksandrov <razor@blackwall.org>
-L: bridge@lists.linux-foundation.org (moderated for non-subscribers)
+L: bridge@lists.linux.dev
L: netdev@vger.kernel.org
S: Maintained
W: http://www.linuxfoundation.org/en/Net:Bridge
@@ -16194,7 +16194,7 @@ M: Juergen Gross <jgross@suse.com>
R: Ajay Kaher <akaher@vmware.com>
R: Alexey Makhalov <amakhalov@vmware.com>
R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core
@@ -22734,7 +22734,7 @@ VIRTIO AND VHOST VSOCK DRIVER
M: Stefan Hajnoczi <stefanha@redhat.com>
M: Stefano Garzarella <sgarzare@redhat.com>
L: kvm@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: netdev@vger.kernel.org
S: Maintained
F: drivers/vhost/vsock.c
@@ -22746,7 +22746,7 @@ F: net/vmw_vsock/virtio_transport_common.c
VIRTIO BALLOON
M: "Michael S. Tsirkin" <mst@redhat.com>
M: David Hildenbrand <david@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/virtio/virtio_balloon.c
F: include/linux/balloon_compaction.h
@@ -22758,7 +22758,7 @@ M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/block/virtio_blk.c
F: drivers/scsi/virtio_scsi.c
@@ -22767,7 +22767,7 @@ F: include/uapi/linux/virtio_scsi.h
VIRTIO CONSOLE DRIVER
M: Amit Shah <amit@kernel.org>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/char/virtio_console.c
F: include/linux/virtio_console.h
@@ -22777,7 +22777,7 @@ VIRTIO CORE AND NET DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: Documentation/ABI/testing/sysfs-bus-vdpa
F: Documentation/ABI/testing/sysfs-class-vduse
@@ -22796,7 +22796,7 @@ F: tools/virtio/
VIRTIO CRYPTO DRIVER
M: Gonglei <arei.gonglei@huawei.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: linux-crypto@vger.kernel.org
S: Maintained
F: drivers/crypto/virtio/
@@ -22807,7 +22807,7 @@ M: Cornelia Huck <cohuck@redhat.com>
M: Halil Pasic <pasic@linux.ibm.com>
M: Eric Farman <farman@linux.ibm.com>
L: linux-s390@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: kvm@vger.kernel.org
S: Supported
F: arch/s390/include/uapi/asm/virtio-ccw.h
@@ -22817,7 +22817,7 @@ VIRTIO FILE SYSTEM
M: Vivek Goyal <vgoyal@redhat.com>
M: Stefan Hajnoczi <stefanha@redhat.com>
M: Miklos Szeredi <miklos@szeredi.hu>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: linux-fsdevel@vger.kernel.org
S: Supported
W: https://virtio-fs.gitlab.io/
@@ -22829,7 +22829,7 @@ VIRTIO GPIO DRIVER
M: Enrico Weigelt, metux IT consult <info@metux.net>
M: Viresh Kumar <vireshk@kernel.org>
L: linux-gpio@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/gpio/gpio-virtio.c
F: include/uapi/linux/virtio_gpio.h
@@ -22840,7 +22840,7 @@ M: Gerd Hoffmann <kraxel@redhat.com>
R: Gurchetan Singh <gurchetansingh@chromium.org>
R: Chia-I Wu <olvaffe@gmail.com>
L: dri-devel@lists.freedesktop.org
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/gpu/drm/virtio/
@@ -22850,7 +22850,7 @@ VIRTIO HOST (VHOST)
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
L: kvm@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: netdev@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
@@ -22866,7 +22866,7 @@ M: Jason Wang <jasowang@redhat.com>
M: Mike Christie <michael.christie@oracle.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/vhost/scsi.c
@@ -22874,7 +22874,7 @@ VIRTIO I2C DRIVER
M: Conghui Chen <conghui.chen@intel.com>
M: Viresh Kumar <viresh.kumar@linaro.org>
L: linux-i2c@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/i2c/busses/i2c-virtio.c
F: include/uapi/linux/virtio_i2c.h
@@ -22887,14 +22887,14 @@ F: include/uapi/linux/virtio_input.h
VIRTIO IOMMU DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/iommu/virtio-iommu.c
F: include/uapi/linux/virtio_iommu.h
VIRTIO MEM DRIVER
M: David Hildenbrand <david@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
W: https://virtio-mem.gitlab.io/
F: drivers/virtio/virtio_mem.c
@@ -22902,7 +22902,7 @@ F: include/uapi/linux/virtio_mem.h
VIRTIO PMEM DRIVER
M: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
S: Maintained
F: drivers/nvdimm/nd_virtio.c
F: drivers/nvdimm/virtio_pmem.c
@@ -22910,7 +22910,7 @@ F: drivers/nvdimm/virtio_pmem.c
VIRTIO SOUND DRIVER
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
M: "Michael S. Tsirkin" <mst@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: include/uapi/linux/virtio_snd.h
@@ -22968,7 +22968,7 @@ F: include/linux/vlynq.h
VM SOCKETS (AF_VSOCK)
M: Stefano Garzarella <sgarzare@redhat.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/vsockmon.c
@@ -23012,7 +23012,7 @@ VMWARE HYPERVISOR INTERFACE
M: Ajay Kaher <akaher@vmware.com>
M: Alexey Makhalov <amakhalov@vmware.com>
R: VMware PV-Drivers Reviewers <pv-drivers@vmware.com>
-L: virtualization@lists.linux-foundation.org
+L: virtualization@lists.linux.dev
L: x86@kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vmware
---
base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa
change-id: 20231107-lists-lf-org-move-bd3769e28849
Best regards,
--
Konstantin Ryabitsev <konstantin@linuxfoundation.org>
^ permalink raw reply related [relevance 11%]
* [ndctl PATCH] ndctl: Update nvdimm mailing list address
@ 2021-05-18 22:25 10% ` Vishal Verma
0 siblings, 0 replies; 200+ results
From: Vishal Verma @ 2021-05-18 22:25 UTC (permalink / raw)
To: nvdimm; +Cc: linux-nvdimm
The 'nvdimm' mailing list has moved from lists.01.org to
lists.linux.dev. Update CONTRIBUTING.md and configure.ac to reflect
this.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
configure.ac | 2 +-
CONTRIBUTING.md | 7 ++++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5ec8d2f..dc39dbe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ AC_PREREQ(2.60)
m4_include([version.m4])
AC_INIT([ndctl],
GIT_VERSION,
- [linux-nvdimm@lists.01.org],
+ [nvdimm@lists.linux.dev],
[ndctl],
[https://github.com/pmem/ndctl])
AC_CONFIG_SRCDIR([ndctl/lib/libndctl.c])
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4c29d31..4f4865d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -6,13 +6,14 @@ The following is a set of guidelines that we adhere to, and request that
contributors follow.
1. The libnvdimm (kernel subsystem) and ndctl developers primarily use
- the [linux-nvdimm](https://lists.01.org/postorius/lists/linux-nvdimm.lists.01.org/)
+ the [nvdimm](https://subspace.kernel.org/lists.linux.dev.html)
mailing list for everything. It is recommended to send patches to
- **```linux-nvdimm@lists.01.org```**
+ **```nvdimm@lists.linux.dev```**
+ An archive is available on [lore](https://lore.kernel.org/nvdimm/)
1. Github [issues](https://github.com/pmem/ndctl/issues) are an acceptable
way to report a problem, but if you just have a question,
- [email](mailto:linux-nvdimm@lists.01.org) the above list.
+ [email](mailto:nvdimm@lists.linux.dev) the above list.
1. We follow the Linux Kernel [Coding Style Guide][cs] as applicable.
base-commit: a2a6fda4d7e93044fca4c67870d2ff7e193d3cf1
prerequisite-patch-id: 8fc5baaf64b312b2459acea255740f79a23b76cd
--
2.31.1
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply related [relevance 11%]
* [PATCH 5.15 022/135] MAINTAINERS: Add new IOMMU development mailing list
@ 2022-06-27 11:20 11% ` Greg Kroah-Hartman
0 siblings, 0 replies; 200+ results
From: Greg Kroah-Hartman @ 2022-06-27 11:20 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joerg Roedel
From: Joerg Roedel <jroedel@suse.de>
commit c242507c1b895646b4a25060df13b6214805759f upstream.
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches. After July 5th the old list will disappear.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20220624125139.412-1-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -434,6 +434,7 @@ ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
F: include/linux/acpi_viot.h
@@ -941,6 +942,7 @@ AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/amd/
@@ -5602,6 +5604,7 @@ M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -5614,6 +5617,7 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Barry Song <song.bao.hua@hisilicon.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7115,6 +7119,7 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9457,6 +9462,7 @@ INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/intel/
@@ -9793,6 +9799,7 @@ IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: Documentation/devicetree/bindings/iommu/
@@ -11795,6 +11802,7 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/iommu/mediatek*
@@ -15554,6 +15562,7 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -17982,6 +17991,7 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -20562,6 +20572,7 @@ M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
^ permalink raw reply [relevance 11%]
* [PATCH 5.18 026/181] MAINTAINERS: Add new IOMMU development mailing list
@ 2022-06-27 11:19 11% ` Greg Kroah-Hartman
0 siblings, 0 replies; 200+ results
From: Greg Kroah-Hartman @ 2022-06-27 11:19 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joerg Roedel
From: Joerg Roedel <jroedel@suse.de>
commit c242507c1b895646b4a25060df13b6214805759f upstream.
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches. After July 5th the old list will disappear.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20220624125139.412-1-joro@8bytes.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -427,6 +427,7 @@ ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
F: include/linux/acpi_viot.h
@@ -960,6 +961,7 @@ AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/amd/
@@ -5898,6 +5900,7 @@ M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -5910,6 +5913,7 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7476,6 +7480,7 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9875,6 +9880,7 @@ INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/intel/
@@ -10253,6 +10259,7 @@ IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: Documentation/devicetree/bindings/iommu/
@@ -12369,6 +12376,7 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/iommu/mediatek*
@@ -16354,6 +16362,7 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -18939,6 +18948,7 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -21609,6 +21619,7 @@ M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
^ permalink raw reply [relevance 11%]
* [PATCH v2] MAINTAINERS: Add new IOMMU development mailing list
@ 2022-06-24 12:51 11% ` Joerg Roedel
0 siblings, 0 replies; 200+ results
From: Joerg Roedel @ 2022-06-24 12:51 UTC (permalink / raw)
To: linux-kernel; +Cc: iommu, iommu, Joerg Roedel, Christoph Hellwig, joro, stable
From: Joerg Roedel <jroedel@suse.de>
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches. After July 5th the old list will disappear.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3cf9842d9233..36d1bc999815 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -427,6 +427,7 @@ ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
F: include/linux/acpi_viot.h
@@ -960,6 +961,7 @@ AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/amd/
@@ -5962,6 +5964,7 @@ M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -5974,6 +5977,7 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7558,6 +7562,7 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9977,6 +9982,7 @@ INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/intel/
@@ -10356,6 +10362,7 @@ IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: Documentation/devicetree/bindings/iommu/
@@ -12504,6 +12511,7 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/iommu/mediatek*
@@ -16545,6 +16553,7 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -19170,6 +19179,7 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -21844,6 +21854,7 @@ M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
--
2.36.1
^ permalink raw reply related [relevance 11%]
* [PATCH] MAINTAINERS: Move nvdimm mailing list
@ 2021-04-21 7:05 11% ` Dan Williams
0 siblings, 0 replies; 200+ results
From: Dan Williams @ 2021-04-21 7:05 UTC (permalink / raw)
To: linux-nvdimm
Cc: Matthew Wilcox, Jan Kara, Jonathan Corbet, nvdimm, linux-kernel
After seeing some users have subscription management trouble, more spam
than other Linux development lists, and considering some of the benefits
of kernel.org hosted lists, nvdimm and persistent memory development is
moving to nvdimm@lists.linux.dev.
The old list will remain up until v5.14-rc1 and shutdown thereafter.
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Oliver O'Halloran <oohall@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Documentation/ABI/obsolete/sysfs-class-dax | 2 +
Documentation/ABI/removed/sysfs-bus-nfit | 2 +
Documentation/ABI/testing/sysfs-bus-nfit | 40 +++++++++++++------------
Documentation/ABI/testing/sysfs-bus-papr-pmem | 4 +--
Documentation/driver-api/nvdimm/nvdimm.rst | 2 +
MAINTAINERS | 14 ++++-----
6 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/Documentation/ABI/obsolete/sysfs-class-dax b/Documentation/ABI/obsolete/sysfs-class-dax
index 0faf1354cd05..5bcce27458e3 100644
--- a/Documentation/ABI/obsolete/sysfs-class-dax
+++ b/Documentation/ABI/obsolete/sysfs-class-dax
@@ -1,7 +1,7 @@
What: /sys/class/dax/
Date: May, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description: Device DAX is the device-centric analogue of Filesystem
DAX (CONFIG_FS_DAX). It allows memory ranges to be
allocated and mapped without need of an intervening file
diff --git a/Documentation/ABI/removed/sysfs-bus-nfit b/Documentation/ABI/removed/sysfs-bus-nfit
index ae8c1ca53828..277437005def 100644
--- a/Documentation/ABI/removed/sysfs-bus-nfit
+++ b/Documentation/ABI/removed/sysfs-bus-nfit
@@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/regionX/nfit/ecc_unit_size
Date: Aug, 2017
KernelVersion: v4.14 (Removed v4.18)
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Size of a write request to a DIMM that will not incur a
read-modify-write cycle at the memory controller.
diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit
index 63ef0b9ecce7..e7282d184a74 100644
--- a/Documentation/ABI/testing/sysfs-bus-nfit
+++ b/Documentation/ABI/testing/sysfs-bus-nfit
@@ -5,7 +5,7 @@ Interface Table (NFIT)' section in the ACPI specification
What: /sys/bus/nd/devices/nmemX/nfit/serial
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Serial number of the NVDIMM (non-volatile dual in-line
memory module), assigned by the module vendor.
@@ -14,7 +14,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/handle
Date: Apr, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The address (given by the _ADR object) of the device on its
parent bus of the NVDIMM device containing the NVDIMM region.
@@ -23,7 +23,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/device
Date: Apr, 2015
KernelVersion: v4.1
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Device id for the NVDIMM, assigned by the module vendor.
@@ -31,7 +31,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/rev_id
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Revision of the NVDIMM, assigned by the module vendor.
@@ -39,7 +39,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/phys_id
Date: Apr, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Handle (i.e., instance number) for the SMBIOS (system
management BIOS) Memory Device structure describing the NVDIMM
@@ -49,7 +49,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/flags
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The flags in the NFIT memory device sub-structure indicate
the state of the data on the nvdimm relative to its energy
@@ -68,7 +68,7 @@ What: /sys/bus/nd/devices/nmemX/nfit/format1
What: /sys/bus/nd/devices/nmemX/nfit/formats
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The interface codes indicate support for persistent memory
mapped directly into system physical address space and / or a
@@ -84,7 +84,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/vendor
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Vendor id of the NVDIMM.
@@ -92,7 +92,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/dsm_mask
Date: May, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported device specific control
functions relative to the NVDIMM command family supported by the
@@ -102,7 +102,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/family
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Displays the NVDIMM family command sets. Values
0, 1, 2 and 3 correspond to NVDIMM_FAMILY_INTEL,
@@ -118,7 +118,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/id
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI specification 6.2 section 5.2.25.9, defines an
identifier for an NVDIMM, which refelects the id attribute.
@@ -127,7 +127,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system vendor id of the NVDIMM non-volatile memory
subsystem controller.
@@ -136,7 +136,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_rev_id
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system revision id of the NVDIMM non-volatile memory subsystem
controller, assigned by the non-volatile memory subsystem
@@ -146,7 +146,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_device
Date: Apr, 2016
KernelVersion: v4.7
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system device id for the NVDIMM non-volatile memory
subsystem controller, assigned by the non-volatile memory
@@ -156,7 +156,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/revision
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI NFIT table revision number.
@@ -164,7 +164,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/scrub
Date: Sep, 2016
KernelVersion: v4.9
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RW) This shows the number of full Address Range Scrubs (ARS)
that have been completed since driver load time. Userspace can
@@ -177,7 +177,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/hw_error_scrub
Date: Sep, 2016
KernelVersion: v4.9
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RW) Provides a way to toggle the behavior between just adding
the address (cache line) where the MCE happened to the poison
@@ -196,7 +196,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/dsm_mask
Date: Jun, 2017
KernelVersion: v4.13
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported bus specific control
functions. See the section named 'NVDIMM Root Device _DSMs' in
@@ -205,7 +205,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle
Date: Apr, 2020
KernelVersion: v5.8
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RW) The Intel platform implementation of firmware activate
support exposes an option let the platform force idle devices in
@@ -225,7 +225,7 @@ Description:
What: /sys/bus/nd/devices/regionX/nfit/range_index
Date: Jun, 2015
KernelVersion: v4.2
-Contact: linux-nvdimm@lists.01.org
+Contact: nvdimm@lists.linux.dev
Description:
(RO) A unique number provided by the BIOS to identify an address
range. Used by NVDIMM Region Mapping Structure to uniquely refer
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 8316c33862a0..92e2db0e2d3d 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/nmemX/papr/flags
Date: Apr, 2020
KernelVersion: v5.8
-Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report flags indicating various states of a
papr-pmem NVDIMM device. Each flag maps to a one or
@@ -36,7 +36,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
Date: May, 2020
KernelVersion: v5.9
-Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report various performance stats related to papr-scm NVDIMM
device. Each stat is reported on a new line with each line
diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst
index ef6d59e0978e..1d8302b89bd4 100644
--- a/Documentation/driver-api/nvdimm/nvdimm.rst
+++ b/Documentation/driver-api/nvdimm/nvdimm.rst
@@ -4,7 +4,7 @@ LIBNVDIMM: Non-Volatile Devices
libnvdimm - kernel / libndctl - userspace helper library
-linux-nvdimm@lists.01.org
+nvdimm@lists.linux.dev
Version 13
diff --git a/MAINTAINERS b/MAINTAINERS
index 9450e052f1b1..4d18fa67f71b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5146,7 +5146,7 @@ DEVICE DIRECT ACCESS (DAX)
M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
F: drivers/dax/
@@ -6887,7 +6887,7 @@ M: Dan Williams <dan.j.williams@intel.com>
R: Matthew Wilcox <willy@infradead.org>
R: Jan Kara <jack@suse.cz>
L: linux-fsdevel@vger.kernel.org
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
F: fs/dax.c
F: include/linux/dax.h
@@ -10146,7 +10146,7 @@ LIBNVDIMM BLK: MMIO-APERTURE DRIVER
M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
@@ -10157,7 +10157,7 @@ LIBNVDIMM BTT: BLOCK TRANSLATION TABLE
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dan Williams <dan.j.williams@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
@@ -10167,7 +10167,7 @@ LIBNVDIMM PMEM: PERSISTENT MEMORY DRIVER
M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
@@ -10175,7 +10175,7 @@ F: drivers/nvdimm/pmem*
LIBNVDIMM: DEVICETREE BINDINGS
M: Oliver O'Halloran <oohall@gmail.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
F: Documentation/devicetree/bindings/pmem/pmem-region.txt
@@ -10186,7 +10186,7 @@ M: Dan Williams <dan.j.williams@intel.com>
M: Vishal Verma <vishal.l.verma@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
M: Ira Weiny <ira.weiny@intel.com>
-L: linux-nvdimm@lists.01.org
+L: nvdimm@lists.linux.dev
S: Supported
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
P: Documentation/nvdimm/maintainer-entry-profile.rst
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply related [relevance 11%]
* Re: Subscriber actions for migrating lists to lists.linux.dev
2021-04-16 20:58 10% Subscriber actions for migrating lists " James Bottomley
@ 2021-04-16 21:16 11% ` Konstantin Ryabitsev
0 siblings, 1 reply; 200+ results
From: Konstantin Ryabitsev @ 2021-04-16 21:16 UTC (permalink / raw)
To: James Bottomley; +Cc: users, tools
On Fri, Apr 16, 2021 at 01:58:22PM -0700, James Bottomley wrote:
> I'm fairly certain all I need to do is a bit of duplicate message
> elimination and to update my procmail rules, but on the latter, what is
> the header I should be sorting on? For current kernel.org lists, it's
> either X-Mailing-list: or List-ID: Will it be the same for
> lists.linux.dev (so I just add to the domain in the rule)?
We still add both List-Id and X-Mailing-List headers, but as "List-Id" is an
actual RFC standard, I suggest filtering based on that. E.g. for
linux-staging@lists.linux.dev we add the following headers:
X-Mailing-List: linux-staging@lists.linux.dev
List-Id: <linux-staging.lists.linux.dev>
List-Subscribe: <mailto:linux-staging+subscribe@lists.linux.dev>
List-Unsubscribe: <mailto:linux-staging+unsubscribe@lists.linux.dev>
> Ordinarily I'd just wait and see, but given the volumes involved I
> wasn't keen on waking up to hundreds of emails suddenly in my INBOX
> instead of the list folders.
Note, that once we get around to vger lists, we'll be preserving the address
and list-id without changes. The lists we're currently migrating are moving
from other places -- either from domains we don't control (lists.01.org), or
from domains like lists.linuxfoundation.org where there are MLs that will
likely not enjoy mlmmj-style list management and will move to groups.io
instead after we cherry-pick the devel lists.
-K
^ permalink raw reply [relevance 11%]
* [PATCH 5.18 028/112] MAINTAINERS: Remove iommu@lists.linux-foundation.org
@ 2022-07-11 9:06 11% ` Greg Kroah-Hartman
0 siblings, 0 replies; 200+ results
From: Greg Kroah-Hartman @ 2022-07-11 9:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joerg Roedel
From: Joerg Roedel <jroedel@suse.de>
commit c51b8f85c4157eb91c2f4ab34b0c52fea642e77c upstream.
The IOMMU mailing list has moved to iommu@lists.linux.dev
and the old list should bounce by now. Remove it from the
MAINTAINERS file.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20220706103331.10215-1-joro@8bytes.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 11 -----------
1 file changed, 11 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -426,7 +426,6 @@ F: drivers/acpi/*thermal*
ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
@@ -960,7 +959,6 @@ F: drivers/video/fbdev/geode/
AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -5899,7 +5897,6 @@ DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -5912,7 +5909,6 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7479,7 +7475,6 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9879,7 +9874,6 @@ F: drivers/hid/intel-ish-hid/
INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -10258,7 +10252,6 @@ F: include/linux/iomap.h
IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -12375,7 +12368,6 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
@@ -16361,7 +16353,6 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
@@ -18947,7 +18938,6 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -21618,7 +21608,6 @@ XEN SWIOTLB SUBSYSTEM
M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
^ permalink raw reply [relevance 11%]
* [PATCH] MAINTAINERS: Remove iommu@lists.linux-foundation.org
@ 2022-07-06 10:33 11% ` Joerg Roedel
0 siblings, 0 replies; 200+ results
From: Joerg Roedel @ 2022-07-06 10:33 UTC (permalink / raw)
To: linux-kernel; +Cc: iommu, iommu, Konstantin Ryabitsev, Joerg Roedel
From: Joerg Roedel <jroedel@suse.de>
The IOMMU mailing list has moved to iommu@lists.linux.dev
and the old list should bounce by now. Remove it from the
MAINTAINERS file.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 66bffb24a348..ead381fdfc5a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -426,7 +426,6 @@ F: drivers/acpi/*thermal*
ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
@@ -960,7 +959,6 @@ F: drivers/video/fbdev/geode/
AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -5979,7 +5977,6 @@ DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -5992,7 +5989,6 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7577,7 +7573,6 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9999,7 +9994,6 @@ F: drivers/hid/intel-ish-hid/
INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -10379,7 +10373,6 @@ F: include/linux/iomap.h
IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -12539,7 +12532,6 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
@@ -16591,7 +16583,6 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
@@ -19217,7 +19208,6 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -21893,7 +21883,6 @@ XEN SWIOTLB SUBSYSTEM
M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
--
2.36.1
^ permalink raw reply related [relevance 11%]
* [PATCH 5.15 2/2] MAINTAINERS: Remove iommu@lists.linux-foundation.org
@ 2023-08-23 17:57 11% ` Easwar Hariharan
0 siblings, 0 replies; 200+ results
From: Easwar Hariharan @ 2023-08-23 17:57 UTC (permalink / raw)
To: stable; +Cc: Joerg Roedel, open list
From: Joerg Roedel <jroedel@suse.de>
commit c51b8f85c4157eb91c2f4ab34b0c52fea642e77c upstream
The IOMMU mailing list has moved to iommu@lists.linux.dev
and the old list should bounce by now. Remove it from the
MAINTAINERS file.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20220706103331.10215-1-joro@8bytes.org
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
---
MAINTAINERS | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6c3f7ce19a79..5e69ba1220b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -433,7 +433,6 @@ F: drivers/acpi/acpi_video.c
ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
@@ -941,7 +940,6 @@ F: drivers/video/fbdev/geode/
AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -5597,7 +5595,6 @@ DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -5610,7 +5607,6 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7112,7 +7108,6 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9453,7 +9448,6 @@ F: drivers/hid/intel-ish-hid/
INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -9790,7 +9784,6 @@ F: include/linux/iomap.h
IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -11791,7 +11784,6 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
@@ -15551,7 +15543,6 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
@@ -17980,7 +17971,6 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -20561,7 +20551,6 @@ XEN SWIOTLB SUBSYSTEM
M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
--
2.25.1
^ permalink raw reply related [relevance 11%]
* [PATCH v2] MAINTAINERS: Add new IOMMU development mailing list
@ 2022-06-24 12:51 11% ` Joerg Roedel
0 siblings, 0 replies; 200+ results
From: Joerg Roedel @ 2022-06-24 12:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Joerg Roedel, iommu, stable, Christoph Hellwig, iommu
From: Joerg Roedel <jroedel@suse.de>
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches. After July 5th the old list will disappear.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3cf9842d9233..36d1bc999815 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -427,6 +427,7 @@ ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
F: include/linux/acpi_viot.h
@@ -960,6 +961,7 @@ AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/amd/
@@ -5962,6 +5964,7 @@ M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -5974,6 +5977,7 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7558,6 +7562,7 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9977,6 +9982,7 @@ INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: drivers/iommu/intel/
@@ -10356,6 +10362,7 @@ IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
F: Documentation/devicetree/bindings/iommu/
@@ -12504,6 +12511,7 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/iommu/mediatek*
@@ -16545,6 +16553,7 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -19170,6 +19179,7 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
@@ -21844,6 +21854,7 @@ M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux-foundation.org
+L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
--
2.36.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [relevance 11%]
* + dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch added to mm-unstable branch
@ 2024-01-26 2:16 11% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-01-26 2:16 UTC (permalink / raw)
To: mm-commits, ying.huang, willy, osalvador, nvdimm, mhocko,
lizhijian, Jonathan.Cameron, gregkh, david, dave.jiang,
dave.hansen, dan.j.williams, vishal.l.verma, akpm
The patch titled
Subject: dax: add a sysfs knob to control memmap_on_memory behavior
has been added to the -mm mm-unstable branch. Its filename is
dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Vishal Verma <vishal.l.verma@intel.com>
Subject: dax: add a sysfs knob to control memmap_on_memory behavior
Date: Wed, 24 Jan 2024 12:03:50 -0800
Add a sysfs knob for dax devices to control the memmap_on_memory setting
if the dax device were to be hotplugged as system memory.
The default memmap_on_memory setting for dax devices originating via pmem
or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to
preserve legacy behavior. For dax devices via CXL, the default is on.
The sysfs control allows the administrator to override the above defaults
if needed.
Link: https://lkml.kernel.org/r/20240124-vv-dax_abi-v7-5-20d16cb8d23d@intel.com
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Tested-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Huang, Ying <ying.huang@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <nvdimm@lists.linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/ABI/testing/sysfs-bus-dax | 17 ++++++++
drivers/dax/bus.c | 43 ++++++++++++++++++++++
2 files changed, 60 insertions(+)
--- a/Documentation/ABI/testing/sysfs-bus-dax~dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior
+++ a/Documentation/ABI/testing/sysfs-bus-dax
@@ -134,3 +134,20 @@ KernelVersion: v5.1
Contact: nvdimm@lists.linux.dev
Description:
(RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: January, 2024
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
--- a/drivers/dax/bus.c~dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior
+++ a/drivers/dax/bus.c
@@ -1349,6 +1349,48 @@ static ssize_t numa_node_show(struct dev
}
static DEVICE_ATTR_RO(numa_node);
+static ssize_t memmap_on_memory_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+
+ return sysfs_emit(buf, "%d\n", dev_dax->memmap_on_memory);
+}
+
+static ssize_t memmap_on_memory_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct dev_dax *dev_dax = to_dev_dax(dev);
+ bool val;
+ int rc;
+
+ rc = kstrtobool(buf, &val);
+ if (rc)
+ return rc;
+
+ if (val == true && !mhp_supports_memmap_on_memory()) {
+ dev_dbg(dev, "memmap_on_memory is not available\n");
+ return -EOPNOTSUPP;
+ }
+
+ rc = down_write_killable(&dax_dev_rwsem);
+ if (rc)
+ return rc;
+
+ if (dev_dax->memmap_on_memory != val && dev->driver &&
+ to_dax_drv(dev->driver)->type == DAXDRV_KMEM_TYPE) {
+ up_write(&dax_dev_rwsem);
+ return -EBUSY;
+ }
+
+ dev_dax->memmap_on_memory = val;
+ up_write(&dax_dev_rwsem);
+
+ return len;
+}
+static DEVICE_ATTR_RW(memmap_on_memory);
+
static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
@@ -1375,6 +1417,7 @@ static struct attribute *dev_dax_attribu
&dev_attr_align.attr,
&dev_attr_resource.attr,
&dev_attr_numa_node.attr,
+ &dev_attr_memmap_on_memory.attr,
NULL,
};
_
Patches currently in -mm which might be from vishal.l.verma@intel.com are
dax-busc-replace-driver-core-lock-usage-by-a-local-rwsem.patch
dax-busc-replace-several-sprintf-with-sysfs_emit.patch
documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch
mm-memory_hotplug-export-mhp_supports_memmap_on_memory.patch
dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch
^ permalink raw reply [relevance 11%]
* [RFC PATCH v2 2/4] tsm: Add RTMRs to the configfs-tsm hierarchy
@ 2024-01-28 21:25 11% ` Samuel Ortiz
0 siblings, 0 replies; 200+ results
From: Samuel Ortiz @ 2024-01-28 21:25 UTC (permalink / raw)
To: Dan Williams
Cc: Samuel Ortiz, Kuppuswamy Sathyanarayanan, Qinkun Bao, Yao, Jiewen,
Xing, Cedric, Dionna Amalie Glaze, biao.lu, linux-coco,
linux-integrity, linux-kernel
RTMRs are defined and managed by their corresponding TSM provider. As
such, they can be configured through the TSM configfs root.
An additional `rtmrs` directory is added by default under the `tsm` one,
where each supported RTMR can be configured:
mkdir /sys/kernel/config/tsm/rtmrs/rtmr0
echo 0 > /sys/kernel/config/tsm/rtmrs/rtmr0/index
An RTMR can not be extended nor read before its configured by assigning
it an index. It is the TSM backend responsibility and choice to map that
index to a hardware RTMR.
Signed-off-by: Samuel Ortiz <sameo@rivosinc.com>
---
Documentation/ABI/testing/configfs-tsm | 11 ++
drivers/virt/coco/tsm.c | 164 +++++++++++++++++++++++++
2 files changed, 175 insertions(+)
diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm
index dd24202b5ba5..590e103a9bcd 100644
--- a/Documentation/ABI/testing/configfs-tsm
+++ b/Documentation/ABI/testing/configfs-tsm
@@ -80,3 +80,14 @@ Contact: linux-coco@lists.linux.dev
Description:
(RO) Indicates the minimum permissible value that can be written
to @privlevel.
+
+What: /sys/kernel/config/tsm/rtmrs/$name/index
+Date: January, 2024
+KernelVersion: v6.8
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RW) A Runtime Measurement Register (RTMR) hardware index.
+ Once created under /sys/kernel/config/tsm/rtmrs/, an RTMR entry
+ can be mapped to a hardware RTMR by writing into its index
+ attribute. The TSM provider will then map the configfs entry to
+ its corresponding hardware register.
diff --git a/drivers/virt/coco/tsm.c b/drivers/virt/coco/tsm.c
index 1a8c3c096120..bb9ed2d2accc 100644
--- a/drivers/virt/coco/tsm.c
+++ b/drivers/virt/coco/tsm.c
@@ -419,6 +419,108 @@ static const struct config_item_type tsm_reports_type = {
.ct_group_ops = &tsm_report_group_ops,
};
+static ssize_t tsm_rtmr_index_store(struct config_item *cfg,
+ const char *buf, size_t len)
+{
+ struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
+ const struct tsm_ops *ops;
+ unsigned int val;
+ int rc;
+
+ rc = kstrtouint(buf, 0, &val);
+ if (rc)
+ return rc;
+
+ guard(rwsem_write)(&tsm_rwsem);
+
+ /* Index can only be configured once */
+ if (is_rtmr_configured(rtmr_state))
+ return -EBUSY;
+
+ /* Check that index stays within the TSM provided capabilities */
+ ops = provider.ops;
+ if (!ops)
+ return -ENOTTY;
+
+ if (val > ops->capabilities.num_rtmrs - 1)
+ return -EINVAL;
+
+ /* Check that this index is available */
+ if (tsm_rtmrs->rtmrs[val])
+ return -EINVAL;
+
+ rtmr_state->index = val;
+ rtmr_state->alg = ops->capabilities.rtmrs[val].hash_alg;
+
+ tsm_rtmrs->rtmrs[val] = rtmr_state;
+
+ return len;
+}
+
+static ssize_t tsm_rtmr_index_show(struct config_item *cfg,
+ char *buf)
+{
+ struct tsm_rtmr_state *rtmr_state = to_tsm_rtmr_state(cfg);
+
+ guard(rwsem_read)(&tsm_rwsem);
+
+ /* An RTMR is not available if it has not been configured */
+ if (!is_rtmr_configured(rtmr_state))
+ return -ENXIO;
+
+ return sysfs_emit(buf, "%u\n", rtmr_state->index);
+}
+CONFIGFS_ATTR(tsm_rtmr_, index);
+
+static struct configfs_attribute *tsm_rtmr_attrs[] = {
+ &tsm_rtmr_attr_index,
+ NULL,
+};
+
+static void tsm_rtmr_item_release(struct config_item *cfg)
+{
+ struct tsm_rtmr_state *state = to_tsm_rtmr_state(cfg);
+
+ kfree(state);
+}
+
+static struct configfs_item_operations tsm_rtmr_item_ops = {
+ .release = tsm_rtmr_item_release,
+};
+
+const struct config_item_type tsm_rtmr_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_attrs = tsm_rtmr_attrs,
+ .ct_item_ops = &tsm_rtmr_item_ops,
+};
+
+static struct config_item *tsm_rtmrs_make_item(struct config_group *group,
+ const char *name)
+{
+ struct tsm_rtmr_state *state;
+
+ guard(rwsem_read)(&tsm_rwsem);
+ if (!(provider.ops && (provider.ops->capabilities.num_rtmrs > 0)))
+ return ERR_PTR(-ENXIO);
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+ state->index = U32_MAX;
+
+ config_item_init_type_name(&state->cfg, name, &tsm_rtmr_type);
+ return &state->cfg;
+}
+
+static struct configfs_group_operations tsm_rtmrs_group_ops = {
+ .make_item = tsm_rtmrs_make_item,
+};
+
+static const struct config_item_type tsm_rtmrs_type = {
+ .ct_owner = THIS_MODULE,
+ .ct_group_ops = &tsm_rtmrs_group_ops,
+};
+
static const struct config_item_type tsm_root_group_type = {
.ct_owner = THIS_MODULE,
};
@@ -433,10 +535,48 @@ static struct configfs_subsystem tsm_configfs = {
.su_mutex = __MUTEX_INITIALIZER(tsm_configfs.su_mutex),
};
+static int tsm_rtmr_register(const struct tsm_ops *ops)
+{
+ struct config_group *rtmrs_group;
+
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ if (!ops || !ops->capabilities.num_rtmrs)
+ return 0;
+
+ if (ops->capabilities.num_rtmrs > TSM_MAX_RTMR)
+ return -EINVAL;
+
+ tsm_rtmrs = kzalloc(sizeof(struct tsm_rtmrs_state), GFP_KERNEL);
+ if (!tsm_rtmrs)
+ return -ENOMEM;
+
+ tsm_rtmrs->rtmrs = kcalloc(ops->capabilities.num_rtmrs,
+ sizeof(struct tsm_rtmr_state *),
+ GFP_KERNEL);
+ if (!tsm_rtmrs->rtmrs) {
+ kfree(tsm_rtmrs);
+ return -ENOMEM;
+ }
+
+ rtmrs_group = configfs_register_default_group(&tsm_configfs.su_group, "rtmrs",
+ &tsm_rtmrs_type);
+ if (IS_ERR(rtmrs_group)) {
+ kfree(tsm_rtmrs->rtmrs);
+ kfree(tsm_rtmrs);
+ return PTR_ERR(rtmrs_group);
+ }
+
+ tsm_rtmrs->group = rtmrs_group;
+
+ return 0;
+}
+
int tsm_register(const struct tsm_ops *ops, void *priv,
const struct config_item_type *type)
{
const struct tsm_ops *conflict;
+ int rc;
if (!type)
type = &tsm_report_default_type;
@@ -450,6 +590,10 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
return -EBUSY;
}
+ rc = tsm_rtmr_register(ops);
+ if (rc < 0)
+ return rc;
+
provider.ops = ops;
provider.data = priv;
provider.type = type;
@@ -457,11 +601,31 @@ int tsm_register(const struct tsm_ops *ops, void *priv,
}
EXPORT_SYMBOL_GPL(tsm_register);
+static int tsm_rtmr_unregister(const struct tsm_ops *ops)
+{
+ lockdep_assert_held_write(&tsm_rwsem);
+
+ if ((ops) && (ops->capabilities.num_rtmrs > 0)) {
+ configfs_unregister_default_group(tsm_rtmrs->group);
+ kfree(tsm_rtmrs->rtmrs);
+ kfree(tsm_rtmrs);
+ }
+
+ return 0;
+}
+
int tsm_unregister(const struct tsm_ops *ops)
{
+ int rc;
+
guard(rwsem_write)(&tsm_rwsem);
if (ops != provider.ops)
return -EBUSY;
+
+ rc = tsm_rtmr_unregister(ops);
+ if (rc < 0)
+ return rc;
+
provider.ops = NULL;
provider.data = NULL;
provider.type = NULL;
--
2.42.0
^ permalink raw reply related [relevance 11%]
* [PATCH] MAINTAINERS: Remove iommu@lists.linux-foundation.org
@ 2022-07-06 10:33 11% ` Joerg Roedel
0 siblings, 0 replies; 200+ results
From: Joerg Roedel @ 2022-07-06 10:33 UTC (permalink / raw)
To: linux-kernel; +Cc: iommu, Joerg Roedel, iommu, Konstantin Ryabitsev
From: Joerg Roedel <jroedel@suse.de>
The IOMMU mailing list has moved to iommu@lists.linux.dev
and the old list should bounce by now. Remove it from the
MAINTAINERS file.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 66bffb24a348..ead381fdfc5a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -426,7 +426,6 @@ F: drivers/acpi/*thermal*
ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
@@ -960,7 +959,6 @@ F: drivers/video/fbdev/geode/
AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -5979,7 +5977,6 @@ DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -5992,7 +5989,6 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7577,7 +7573,6 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9999,7 +9994,6 @@ F: drivers/hid/intel-ish-hid/
INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -10379,7 +10373,6 @@ F: include/linux/iomap.h
IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -12539,7 +12532,6 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
@@ -16591,7 +16583,6 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
@@ -19217,7 +19208,6 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -21893,7 +21883,6 @@ XEN SWIOTLB SUBSYSTEM
M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
--
2.36.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [relevance 12%]
* [outreachy+owner@lists.linux.dev: Bouncing messages from outreachy@lists.linux.dev]
@ 2022-10-25 23:03 12% Deepak R Varma
0 siblings, 0 replies; 200+ results
From: Deepak R Varma @ 2022-10-25 23:03 UTC (permalink / raw)
To: Outreachy Linux
----- Forwarded message from outreachy+owner@lists.linux.dev -----
Hello,
Looks like I am unable to receive my own email from the Outreachy mailbox. I am
not sure if this is related to the DKIM issue mentioned by Greg before. If it is
not, can you please suggest how to get this resolved?
Please note, I am still working with my email service provider to resolve the
DKIM issue.
Thank you,
./drv
Date: Tue, 25 Oct 2022 16:30:01 +0000
From: outreachy+owner@lists.linux.dev
To: drv@mailo.com
Subject: Bouncing messages from outreachy@lists.linux.dev
Greetings!
This is the mlmmj program managing the <outreachy@lists.linux.dev> mailing
list.
Some messages to you could not be delivered. This usually happens if we
have accepted a spam message that is being rejected by your mail host when
we try to deliver it, but may also be due to other reasons. Please review
the public list archives to check if you are missing any legitimate mail.
If you're seeing this message it usually means that things are back to
normal and no further action is required from you.
For internal tracking purposes, here is the list of bounced messages:
- 1263
- 1265
- 1268
----- End forwarded message -----
^ permalink raw reply [relevance 12%]
* Patch "MAINTAINERS: Remove iommu@lists.linux-foundation.org" has been added to the 5.18-stable tree
@ 2022-07-09 8:29 12% gregkh
0 siblings, 0 replies; 200+ results
From: gregkh @ 2022-07-09 8:29 UTC (permalink / raw)
To: gregkh, iommu, iommu, jroedel; +Cc: stable-commits
This is a note to let you know that I've just added the patch titled
MAINTAINERS: Remove iommu@lists.linux-foundation.org
to the 5.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
maintainers-remove-iommu-lists.linux-foundation.org.patch
and it can be found in the queue-5.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From c51b8f85c4157eb91c2f4ab34b0c52fea642e77c Mon Sep 17 00:00:00 2001
From: Joerg Roedel <jroedel@suse.de>
Date: Wed, 6 Jul 2022 12:33:31 +0200
Subject: MAINTAINERS: Remove iommu@lists.linux-foundation.org
From: Joerg Roedel <jroedel@suse.de>
commit c51b8f85c4157eb91c2f4ab34b0c52fea642e77c upstream.
The IOMMU mailing list has moved to iommu@lists.linux.dev
and the old list should bounce by now. Remove it from the
MAINTAINERS file.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Link: https://lore.kernel.org/r/20220706103331.10215-1-joro@8bytes.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 11 -----------
1 file changed, 11 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -426,7 +426,6 @@ F: drivers/acpi/*thermal*
ACPI VIOT DRIVER
M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: linux-acpi@vger.kernel.org
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/acpi/viot.c
@@ -960,7 +959,6 @@ F: drivers/video/fbdev/geode/
AMD IOMMU (AMD-VI)
M: Joerg Roedel <joro@8bytes.org>
R: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -5899,7 +5897,6 @@ DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
R: Robin Murphy <robin.murphy@arm.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -5912,7 +5909,6 @@ F: kernel/dma/
DMA MAPPING BENCHMARK
M: Xiang Chen <chenxiang66@hisilicon.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
F: kernel/dma/map_benchmark.c
F: tools/testing/selftests/dma/
@@ -7479,7 +7475,6 @@ F: drivers/gpu/drm/exynos/exynos_dp*
EXYNOS SYSMMU (IOMMU) driver
M: Marek Szyprowski <m.szyprowski@samsung.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
F: drivers/iommu/exynos-iommu.c
@@ -9879,7 +9874,6 @@ F: drivers/hid/intel-ish-hid/
INTEL IOMMU (VT-d)
M: David Woodhouse <dwmw2@infradead.org>
M: Lu Baolu <baolu.lu@linux.intel.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -10258,7 +10252,6 @@ F: include/linux/iomap.h
IOMMU DRIVERS
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
@@ -12375,7 +12368,6 @@ F: drivers/i2c/busses/i2c-mt65xx.c
MEDIATEK IOMMU DRIVER
M: Yong Wu <yong.wu@mediatek.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Supported
@@ -16361,7 +16353,6 @@ F: drivers/i2c/busses/i2c-qcom-cci.c
QUALCOMM IOMMU
M: Rob Clark <robdclark@gmail.com>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
L: linux-arm-msm@vger.kernel.org
S: Maintained
@@ -18947,7 +18938,6 @@ F: arch/x86/boot/video*
SWIOTLB SUBSYSTEM
M: Christoph Hellwig <hch@infradead.org>
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
@@ -21618,7 +21608,6 @@ XEN SWIOTLB SUBSYSTEM
M: Juergen Gross <jgross@suse.com>
M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
-L: iommu@lists.linux-foundation.org
L: iommu@lists.linux.dev
S: Supported
F: arch/x86/xen/*swiotlb*
Patches currently in stable-queue which might be from jroedel@suse.de are
queue-5.18/iommu-vt-d-fix-rid2pasid-setup-teardown-failure.patch
queue-5.18/iommu-vt-d-fix-pci-bus-rescan-device-hot-add.patch
queue-5.18/maintainers-remove-iommu-lists.linux-foundation.org.patch
^ permalink raw reply [relevance 12%]
* [PATCH 5/9] Docs/admin-guide/mm/damon/usage: document 'DEPRECATED' file of DAMON debugfs interface
2024-01-30 1:35 15% ` [PATCH 4/9] mm/damon/dbgfs: make debugfs interface deprecation message a macro SeongJae Park
@ 2024-01-30 1:35 12% ` SeongJae Park
1 sibling, 0 replies; 200+ results
From: SeongJae Park @ 2024-01-30 1:35 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, Jonathan Corbet, damon, linux-mm, linux-doc,
linux-kernel
Document the newly added DAMON debugfs interface deprecation notice file
on the usage document.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index f2feabb4bd35..5d3df18dfb9f 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -628,9 +628,16 @@ debugfs Interface (DEPRECATED!)
move, please report your usecase to damon@lists.linux.dev and
linux-mm@kvack.org.
-DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
-``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
-``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
+DAMON exports nine files, ``DEPRECATED``, ``attrs``, ``target_ids``,
+``init_regions``, ``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts``
+and ``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
+
+
+``DEPRECATED`` is a read-only file for the DAMON debugfs interface deprecation
+notice. Reading it returns the deprecation notice, as below::
+
+ # cat DEPRECATED
+ DAMON debugfs interface is deprecated, so users should move to DAMON_SYSFS. If you cannot, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.
Attributes
--
2.39.2
^ permalink raw reply related [relevance 12%]
* [merged mm-stable] docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch removed from -mm tree
@ 2023-10-04 20:18 12% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-10-04 20:18 UTC (permalink / raw)
To: mm-commits, rostedt, corbet, sj, akpm
The quilt patch titled
Subject: Docs/admin-guide/mm/damon/usage: move debugfs intro to the bottom of the section
has been removed from the -mm tree. Its filename was
docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: Docs/admin-guide/mm/damon/usage: move debugfs intro to the bottom of the section
Date: Thu, 7 Sep 2023 02:29:21 +0000
On the DAMON usage introduction section, the introduction of DAMON
debugfs interface, which is deprecated, is above kernel API, which is
actively supported. Move the DAMON debugfs intro to bottom, so that
readers have less chances to read it.
Link: https://lkml.kernel.org/r/20230907022929.91361-4-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/Documentation/admin-guide/mm/damon/usage.rst~docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section
+++ a/Documentation/admin-guide/mm/damon/usage.rst
@@ -20,18 +20,18 @@ DAMON provides below interfaces for diff
you can write and use your personalized DAMON sysfs wrapper programs that
reads/writes the sysfs files instead of you. The `DAMON user space tool
<https://github.com/awslabs/damo>`_ is one example of such programs.
-- *debugfs interface. (DEPRECATED!)*
- :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This is deprecated, so users should move to the
- :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
- move, please report your usecase to damon@lists.linux.dev and
- linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </mm/damon/api>`.
+- *debugfs interface. (DEPRECATED!)*
+ :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
+ <sysfs_interface>`. This is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
.. _sysfs_interface:
_
Patches currently in -mm which might be from sj@kernel.org are
^ permalink raw reply [relevance 12%]
* + mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch added to mm-unstable branch
@ 2023-02-10 22:30 12% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-02-10 22:30 UTC (permalink / raw)
To: mm-commits, rdunlap, corbet, sj, akpm
The patch titled
Subject: mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix
has been added to the -mm mm-unstable branch. Its filename is
mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix
Date: Fri, 10 Feb 2023 04:48:38 +0000
split DAMON debugfs file open warning message, per Randy
Link: https://lkml.kernel.org/r/20230209192009.7885-4-sj@kernel.org
Link: https://lkml.kernel.org/r/20230210044838.63723-4-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
--- a/mm/damon/dbgfs.c~mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix
+++ a/mm/damon/dbgfs.c
@@ -22,7 +22,10 @@ static DEFINE_MUTEX(damon_dbgfs_lock);
static void damon_dbgfs_warn_deprecation(void)
{
- pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n");
+ pr_warn_once("DAMON debugfs interface is deprecated, "
+ "so users should move to DAMON_SYSFS. If you cannot, "
+ "please report your usecase to damon@lists.linux.dev and "
+ "linux-mm@kvack.org.\n");
}
/*
_
Patches currently in -mm which might be from sj@kernel.org are
docs-admin-guide-mm-damon-usage-add-damon-debugfs-interface-deprecation-notice.patch
mm-damon-kconfig-add-damon-debugfs-interface-deprecation-notice.patch
mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message.patch
mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch
^ permalink raw reply [relevance 12%]
* [PATCH] MAINTAINERS: Add Robin Murphy as IOMMU SUBSYTEM reviewer
@ 2022-07-15 11:03 12% Joerg Roedel
0 siblings, 0 replies; 200+ results
From: Joerg Roedel @ 2022-07-15 11:03 UTC (permalink / raw)
To: iommu; +Cc: Will Deacon, Robin Murphy, linux-kernel, Joerg Roedel
From: Joerg Roedel <jroedel@suse.de>
Robin has been acting as a reviewer of the IOMMU Subsystem for a long
time. He is also defacto maintaining the IOMMU DMA-API Layer, so make
both roles official by adding Robin to the MAINTAINERS file.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
MAINTAINERS | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f9ed151ad4c..029f49f29982 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10448,9 +10448,20 @@ T: git git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git
F: fs/iomap/
F: include/linux/iomap.h
-IOMMU DRIVERS
+IOMMU DMA-API LAYER
+M: Robin Murphy <robin.murphy@arm.com>
+L: iommu@lists.linux.dev
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
+F: drivers/iommu/dma-iommu.c
+F: drivers/iommu/iova.c
+F: include/linux/dma-iommu.h
+F: include/linux/iova.h
+
+IOMMU SUBSYSTEM
M: Joerg Roedel <joro@8bytes.org>
M: Will Deacon <will@kernel.org>
+R: Robin Murphy <robin.murphy@arm.com>
L: iommu@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
--
2.36.1
^ permalink raw reply related [relevance 12%]
* [merged mm-stable] mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch removed from -mm tree
@ 2024-02-22 0:02 13% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-02-22 0:02 UTC (permalink / raw)
To: mm-commits, siyanteng, shuah, corbet, alexs, 2023002089, sj, akpm
The quilt patch titled
Subject: mm/damon/dbgfs: make debugfs interface deprecation message a macro
has been removed from the -mm tree. Its filename was
mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: mm/damon/dbgfs: make debugfs interface deprecation message a macro
Date: Mon, 29 Jan 2024 17:35:43 -0800
DAMON debugfs interface deprecation message is written twice, once for the
warning, and again for DEPRECATED file's read output. De-duplicate those
by defining the message as a macro and reuse.
[akpm@linux-foundation.org: s/comnst/const/]
Link: https://lkml.kernel.org/r/20240130013549.89538-5-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Alex Shi <alexs@kernel.org>
Cc: Hu Haowen <2023002089@link.tyut.edu.cn>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/damon/dbgfs.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/mm/damon/dbgfs.c~mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro
+++ a/mm/damon/dbgfs.c
@@ -15,6 +15,11 @@
#include <linux/page_idle.h>
#include <linux/slab.h>
+#define DAMON_DBGFS_DEPRECATION_NOTICE \
+ "DAMON debugfs interface is deprecated, so users should move " \
+ "to DAMON_SYSFS. If you cannot, please report your usecase to " \
+ "damon@lists.linux.dev and linux-mm@kvack.org.\n"
+
static struct damon_ctx **dbgfs_ctxs;
static int dbgfs_nr_ctxs;
static struct dentry **dbgfs_dirs;
@@ -22,10 +27,7 @@ static DEFINE_MUTEX(damon_dbgfs_lock);
static void damon_dbgfs_warn_deprecation(void)
{
- pr_warn_once("DAMON debugfs interface is deprecated, "
- "so users should move to DAMON_SYSFS. If you cannot, "
- "please report your usecase to damon@lists.linux.dev and "
- "linux-mm@kvack.org.\n");
+ pr_warn_once(DAMON_DBGFS_DEPRECATION_NOTICE);
}
/*
@@ -808,10 +810,7 @@ static void dbgfs_destroy_ctx(struct dam
static ssize_t damon_dbgfs_deprecated_read(struct file *file,
char __user *buf, size_t count, loff_t *ppos)
{
- static const char kbuf[512] = "DAMON debugfs interface is deprecated, "
- "so users should move to DAMON_SYSFS. If you cannot, "
- "please report your usecase to damon@lists.linux.dev and "
- "linux-mm@kvack.org.\n";
+ static const char kbuf[512] = DAMON_DBGFS_DEPRECATION_NOTICE;
return simple_read_from_buffer(buf, count, ppos, kbuf, strlen(kbuf));
}
_
Patches currently in -mm which might be from sj@kernel.org are
docs-mm-damon-maintainer-profile-fix-reference-links-for-mm-stable-tree.patch
docs-mm-damon-move-the-list-of-damos-actions-to-design-doc.patch
docs-mm-damon-move-damon-operation-sets-list-from-the-usage-to-the-design-document.patch
docs-mm-damon-move-damon-operation-sets-list-from-the-usage-to-the-design-document-fix.patch
docs-mm-damon-move-monitoring-target-regions-setup-detail-from-the-usage-to-the-design-document.patch
docs-admin-guide-mm-damon-usage-fix-wrong-quotas-diabling-condition.patch
mm-damon-core-set-damos_quota-esz-as-public-field-and-document.patch
mm-damon-sysfs-schemes-implement-quota-effective_bytes-file.patch
mm-damon-sysfs-implement-a-kdamond-command-for-updating-schemes-effective-quotas.patch
docs-abi-damon-document-effective_bytes-sysfs-file.patch
docs-admin-guide-mm-damon-usage-document-effective_bytes-file.patch
mm-damon-move-comments-and-fields-for-damos-quota-prioritization-to-the-end.patch
mm-damon-core-split-out-quota-goal-related-fields-to-a-struct.patch
mm-damon-core-add-multiple-goals-per-damos_quota-and-helpers-for-those.patch
mm-damon-sysfs-use-only-quota-goals.patch
mm-damon-core-remove-goal-field-of-damos_quota.patch
mm-damon-core-let-goal-specified-with-only-target-and-current-values.patch
mm-damon-core-support-multiple-metrics-for-quota-goal.patch
mm-damon-core-implement-psi-metric-damos-quota-goal.patch
mm-damon-sysfs-schemes-support-psi-based-quota-auto-tune.patch
docs-mm-damon-design-document-quota-goal-self-tuning.patch
docs-abi-damon-document-quota-goal-metric-file.patch
docs-admin-guide-mm-damon-usage-document-quota-goal-metric-file.patch
docs-admin-guide-mm-damon-usage-document-quota-goal-metric-file-fix.patch
mm-damon-reclaim-implement-user-feedback-driven-quota-auto-tuning.patch
mm-damon-reclaim-implement-memory-psi-driven-quota-self-tuning.patch
docs-admin-guide-mm-damon-reclaim-document-auto-tuning-parameters.patch
^ permalink raw reply [relevance 13%]
* [PATCH 03/11] Docs/admin-guide/mm/damon/usage: move debugfs intro to the bottom of the section
@ 2023-09-07 2:29 13% ` SeongJae Park
0 siblings, 0 replies; 200+ results
From: SeongJae Park @ 2023-09-07 2:29 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, Jonathan Corbet, damon, linux-mm, linux-doc,
linux-kernel
On the DAMON usage introduction section, the introduction of DAMON
debugfs interface, which is deprecated, is above kernel API, which is
actively supported. Move the DAMON debugfs intro to bottom, so that
readers have less chances to read it.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index bffe9dd9b0d6..e48101c777e1 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -20,18 +20,18 @@ DAMON provides below interfaces for different users.
you can write and use your personalized DAMON sysfs wrapper programs that
reads/writes the sysfs files instead of you. The `DAMON user space tool
<https://github.com/awslabs/damo>`_ is one example of such programs.
-- *debugfs interface. (DEPRECATED!)*
- :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This is deprecated, so users should move to the
- :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
- move, please report your usecase to damon@lists.linux.dev and
- linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </mm/damon/api>`.
+- *debugfs interface. (DEPRECATED!)*
+ :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
+ <sysfs_interface>`. This is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
.. _sysfs_interface:
--
2.25.1
^ permalink raw reply related [relevance 13%]
* [PATCH] README: Remove stray '@' from mailing list email
@ 2021-12-18 4:21 13% Ossama Othman
0 siblings, 0 replies; 200+ results
From: Ossama Othman @ 2021-12-18 4:21 UTC (permalink / raw)
To: ell; +Cc: Ossama Othman
---
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README b/README
index f02f767..99207e3 100644
--- a/README
+++ b/README
@@ -49,7 +49,7 @@ Information
===========
Mailing list:
- ell@@lists.linux.dev
+ ell@lists.linux.dev
IRC:
irc://irc.oftc.net/#ell
--
2.32.0
^ permalink raw reply related [relevance 13%]
* Re: [PATCH v2 0/3] mm/damon: deprecate DAMON debugfs interface
@ 2023-02-10 18:28 13% ` SeongJae Park
0 siblings, 0 replies; 200+ results
From: SeongJae Park @ 2023-02-10 18:28 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, Jonathan Corbet, damon, linux-mm, linux-doc,
linux-kernel, Randy Dunlap
On Fri, 10 Feb 2023 04:48:35 +0000 SeongJae Park <sj@kernel.org> wrote:
> Changes from v1
> (https://lore.kernel.org/damon/20230209192009.7885-1-sj@kernel.org/)
> - Split DAMON debugfs file open warning message (Randy Dunlap)
I usually sent this kind of update for after-merged-into-mm-unstable tree
patches individusally as fixup, but this time I sent whole patchset as a new
version, because I was out of my mind.
For someone who may prefer the usual for-fixup individual patch, attaching the
version below.
Thanks,
SJ
================================= 8< ==========================================
From: SeongJae Park <sj@kernel.org>
Date: Fri, 10 Feb 2023 04:37:19 +0000
Subject: [PATCH mm-unstable] mm/damon/dbgfs: break too long deprecation
warning message
DAMON debugfs interface deprecation message, which is introduced by
commit 234a68e24b12 ("mm/damon/dbgfs: print DAMON debugfs interface
deprecation message") of mm-unstable, is too long. Break down into
multiple strings for better code readability.
Fixes: 234a68e24b12 ("mm/damon/dbgfs: print DAMON debugfs interface deprecation message") # mm-unstable
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: SeongJae Park <sj@kernel.org>
---
mm/damon/dbgfs.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c
index e551a20b35e3..124f0f8c97b7 100644
--- a/mm/damon/dbgfs.c
+++ b/mm/damon/dbgfs.c
@@ -22,7 +22,10 @@ static DEFINE_MUTEX(damon_dbgfs_lock);
static void damon_dbgfs_warn_deprecation(void)
{
- pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n");
+ pr_warn_once("DAMON debugfs interface is deprecated, "
+ "so users should move to DAMON_SYSFS. If you cannot, "
+ "please report your usecase to damon@lists.linux.dev and "
+ "linux-mm@kvack.org.\n");
}
/*
--
2.25.1
^ permalink raw reply related [relevance 13%]
* [folded-merged] mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch removed from -mm tree
@ 2023-02-13 23:52 13% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2023-02-13 23:52 UTC (permalink / raw)
To: mm-commits, rdunlap, corbet, sj, akpm
The quilt patch titled
Subject: mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix
has been removed from the -mm tree. Its filename was
mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch
This patch was dropped because it was folded into mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message.patch
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix
Date: Fri, 10 Feb 2023 04:48:38 +0000
split DAMON debugfs file open warning message, per Randy
Link: https://lkml.kernel.org/r/20230209192009.7885-4-sj@kernel.org
Link: https://lkml.kernel.org/r/20230210044838.63723-4-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
--- a/mm/damon/dbgfs.c~mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix
+++ a/mm/damon/dbgfs.c
@@ -22,7 +22,10 @@ static DEFINE_MUTEX(damon_dbgfs_lock);
static void damon_dbgfs_warn_deprecation(void)
{
- pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n");
+ pr_warn_once("DAMON debugfs interface is deprecated, "
+ "so users should move to DAMON_SYSFS. If you cannot, "
+ "please report your usecase to damon@lists.linux.dev and "
+ "linux-mm@kvack.org.\n");
}
/*
_
Patches currently in -mm which might be from sj@kernel.org are
docs-admin-guide-mm-damon-usage-add-damon-debugfs-interface-deprecation-notice.patch
mm-damon-kconfig-add-damon-debugfs-interface-deprecation-notice.patch
mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message.patch
^ permalink raw reply [relevance 13%]
* [RFC PATCH v1 2/2] docs: reporting-issue: rework the TLDR
@ 2024-03-26 12:21 13% ` Thorsten Leemhuis
2024-03-26 12:21 10% ` [RFC PATCH v1 1/2] docs: reporting-issue: rework the detailed guide Thorsten Leemhuis
1 sibling, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2024-03-26 12:21 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: regressions, linux-doc, linux-kernel, workflows
Rework the TLDR (aka the short guide) for various reasons:
* People had to read it entirely and then act upon what they learned,
which from feedback I got was apparently somewhat hard and confusing
given everything we expect from bug reporters; this partly was because
the first paragraph covered a special case (regression in
stable/longterm kernel) and not the main aspect most people cared
about when they came to the document.
Use a step-by-step approach to avoid this.
* Make use of
Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
* The 'quickly report a stable regression to the stable team' approach
hardly worked out: most of the time the regression was not known yet.
Try a different approach using the regressions list.
* Reports about stable/longterm regressions most of the time were
greeted with a brief reply along the lines of 'Is mainline affected as
well?'; this is needed to determine who is responsible, so it might as
well make the reporter check that before sending the report (which
verify-bugs-and-bisect-regressions.rst already tells them to do, too).
Not-signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
.../admin-guide/reporting-issues.rst | 104 +++++++++++-------
1 file changed, 62 insertions(+), 42 deletions(-)
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index e6083946c146e8..5f3c840ab94524 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -5,48 +5,68 @@ Reporting issues
++++++++++++++++
-The short guide (aka TL;DR)
-===========================
-
-Are you facing a regression with vanilla kernels from the same stable or
-longterm series? One still supported? Then search the `LKML
-<https://lore.kernel.org/lkml/>`_ and the `Linux stable mailing list
-<https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
-you don't find any, install `the latest release from that series
-<https://kernel.org/>`_. If it still shows the issue, report it to the stable
-mailing list (stable@vger.kernel.org) and CC the regressions list
-(regressions@lists.linux.dev); ideally also CC the maintainer and the mailing
-list for the subsystem in question.
-
-In all other cases try your best guess which kernel part might be causing the
-issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
-expect to be told about problems, which most of the time will be by email with a
-mailing list in CC. Check the destination's archives for matching reports;
-search the `LKML <https://lore.kernel.org/lkml/>`_ and the web, too. If you
-don't find any to join, install `the latest mainline kernel
-<https://kernel.org/>`_. If the issue is present there, send a report.
-
-The issue was fixed there, but you would like to see it resolved in a still
-supported stable or longterm series as well? Then install its latest release.
-If it shows the problem, search for the change that fixed it in mainline and
-check if backporting is in the works or was discarded; if it's neither, ask
-those who handled the change for it.
-
-**General remarks**: When installing and testing a kernel as outlined above,
-ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
-sure it's built and running in a healthy environment and not already tainted
-before the issue occurs.
-
-If you are facing multiple issues with the Linux kernel at once, report each
-separately. While writing your report, include all information relevant to the
-issue, like the kernel and the distro used. In case of a regression, CC the
-regressions mailing list (regressions@lists.linux.dev) to your report. Also try
-to pin-point the culprit with a bisection; if you succeed, include its
-commit-id and CC everyone in the sign-off-by chain.
-
-Once the report is out, answer any questions that come up and help where you
-can. That includes keeping the ball rolling by occasionally retesting with newer
-releases and sending a status update afterwards.
+Reporting issues
+++++++++++++++++
+
+The short guide on reporting Linux kernel issues (aka "the TL;DR")
+==================================================================
+
+Rule out something external causes your kernel to misbehave: skim the output of
+``journalctl -k``; make sure the kernel is not tainted; consider a glitch in the
+environment (hardware, firmware, initramfs, distribution, file system, ...).
+
+If you deal with multiple issues, process each separately.
+
+Search `lore <https://lore.kernel.org/all/>`_ for earlier reports and fixes.
+Then the wider internet. Consult :ref:`MAINTAINERS <maintainers>` to determine
+how bugs for the affected driver or subsystem must be submitted. This is usually
+by mail and rarely bugzilla.kernel.org; if the driver or subsystem uses an
+externally archived list or one of various bug trackers, search those as well.
+
+In case you deal with a regression still occurring in a less than two (ideally:
+one) weeks old kernel that is vanilla or close to it: send a brief email to
+regressions@lists.linux.dev asking if the regression is known; consider
+continuing this guide right afterwards, but definitely do so if you do not
+receive a positive reply within three days.
+
+Verify the bug and in case of a regression potentially bisect it as described in
+Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst; alternatively
+perform these tasks through different measures as outlined in more detailed
+step-by-step guide below.
+
+Were you unable to reproduce a bug with a mainline kernel you want to see fixed
+in a stable or longterm series? A bug that is not a regression? Then move over
+to 'Resolving non-regressions only occurring in stable or longterm kernels'.
+
+Compile a report with all important details. This always includes the
+distribution and kernel version used. Most of the time you also want to describe
+relevant aspects of your system and make the kernel's log messages available; do
+the same for everything else most likely relevant. In case of a regression, make
+that aspect obvious in the title; also specify the last working and first broken
+early in the body.
+
+Submit your report in the appropriate way, which depends on the outcome of the
+verification:
+
+* Are you facing a regression within a stable or longterm kernel series you were
+ unable to reproduce in a mainline kernel? Then report it by email to the
+ stable team while CCing the regressions list (e.g. To: Greg Kroah-Hartman
+ <gregkh@linuxfoundation.org>, Sasha Levin <sashal@kernel.org>;
+ CC: stable@vger.kernel.org, regressions@lists.linux.dev) and everyone in the
+ culprit's 'Signed-off-by' chain.
+
+* In all other cases, submit the report as specified in MAINTAINERS. In case of
+ a regression you have to report by mail, CC the regressions list
+ (regressions@lists.linux.dev); when you know the culprit, also CC everyone in
+ its 'Signed-off-by' chain. In case of a regression you have to file in a bug
+ tracker, write a short heads-up email with a link to the report to the list
+ once you have done so -- if the culprit is known, CC everyone that signed the
+ culprit off, too.
+
+Answer any questions in a timely manner and help where you can to resolve the
+issue. Retest with at least every first release candidate (-rc1) of a new
+mainline version and report your findings.
+
The detailed step-by-step guide on reporting Linux kernel issues
================================================================
--
2.44.0
^ permalink raw reply related [relevance 13%]
* + mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch added to mm-unstable branch
@ 2024-01-30 6:45 13% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-01-30 6:45 UTC (permalink / raw)
To: mm-commits, siyanteng, shuah, corbet, alexs, 2023002089, sj, akpm
The patch titled
Subject: mm/damon/dbgfs: make debugfs interface deprecation message a macro
has been added to the -mm mm-unstable branch. Its filename is
mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: SeongJae Park <sj@kernel.org>
Subject: mm/damon/dbgfs: make debugfs interface deprecation message a macro
Date: Mon, 29 Jan 2024 17:35:43 -0800
DAMON debugfs interface deprecation message is written twice, once for the
warning, and again for DEPRECATED file's read output. De-duplicate those
by defining the message as a macro and reuse.
Link: https://lkml.kernel.org/r/20240130013549.89538-5-sj@kernel.org
Signed-off-by: SeongJae Park <sj@kernel.org>
Cc: Alex Shi <alexs@kernel.org>
Cc: Hu Haowen <2023002089@link.tyut.edu.cn>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/damon/dbgfs.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/mm/damon/dbgfs.c~mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro
+++ a/mm/damon/dbgfs.c
@@ -15,6 +15,11 @@
#include <linux/page_idle.h>
#include <linux/slab.h>
+#define DAMON_DBGFS_DEPRECATION_NOTICE \
+ "DAMON debugfs interface is deprecated, so users should move " \
+ "to DAMON_SYSFS. If you cannot, please report your usecase to " \
+ "damon@lists.linux.dev and linux-mm@kvack.org.\n"
+
static struct damon_ctx **dbgfs_ctxs;
static int dbgfs_nr_ctxs;
static struct dentry **dbgfs_dirs;
@@ -22,10 +27,7 @@ static DEFINE_MUTEX(damon_dbgfs_lock);
static void damon_dbgfs_warn_deprecation(void)
{
- pr_warn_once("DAMON debugfs interface is deprecated, "
- "so users should move to DAMON_SYSFS. If you cannot, "
- "please report your usecase to damon@lists.linux.dev and "
- "linux-mm@kvack.org.\n");
+ pr_warn_once(DAMON_DBGFS_DEPRECATION_NOTICE);
}
/*
@@ -808,10 +810,7 @@ static void dbgfs_destroy_ctx(struct dam
static ssize_t damon_dbgfs_deprecated_read(struct file *file,
char __user *buf, size_t count, loff_t *ppos)
{
- char kbuf[512] = "DAMON debugfs interface is deprecated, "
- "so users should move to DAMON_SYSFS. If you cannot, "
- "please report your usecase to damon@lists.linux.dev and "
- "linux-mm@kvack.org.\n";
+ char kbuf[512] = DAMON_DBGFS_DEPRECATION_NOTICE;
int len = strnlen(kbuf, 1024);
return simple_read_from_buffer(buf, count, ppos, kbuf, len);
_
Patches currently in -mm which might be from sj@kernel.org are
docs-admin-guide-mm-damon-usage-use-sysfs-interface-for-tracepoints-example.patch
mm-damon-rename-config_damon_dbgfs-to-damon_dbgfs_deprecated.patch
mm-damon-dbgfs-implement-deprecation-notice-file.patch
mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch
docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch
selftets-damon-prepare-for-monitor_on-file-renaming.patch
mm-damon-dbgfs-rename-monitor_on-file-to-monitor_on_deprecated.patch
docs-admin-guide-mm-damon-usage-update-for-monitor_on-renaming.patch
docs-translations-damon-usage-update-for-monitor_on-renaming.patch
^ permalink raw reply [relevance 13%]
* [PATCH] MAINTAINERS: Sort entries using parse-maintainers.pl
@ 2021-12-04 17:52 13% Jonathan Neuschäfer
0 siblings, 0 replies; 200+ results
From: Jonathan Neuschäfer @ 2021-12-04 17:52 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Jonathan Neuschäfer, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Nathan Chancellor, Nick Desaulniers,
linux-riscv, llvm
The MAINTAINERS file got slightly out of order again, making it
difficult to put new entries at the right (alphabetical) position.
Run parse-maintainers.pl to restore the alphabetical order.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
This patch applies cleanly to v5.16-rc3 and can then be cherry-picked
cleanly onto next-20211203, but applying it directly to next-20211203
(with "git am") fails:
error: patch failed: MAINTAINERS:967
error: MAINTAINERS: patch does not apply
Checkpatch warns about a few unordered "F:" lines within sections, but I
left those alone because I wanted this patch to be as automated as possible.
---
MAINTAINERS | 710 ++++++++++++++++++++++++++--------------------------
1 file changed, 355 insertions(+), 355 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 360e9aa0205d6..a8ae86e24cac0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -967,11 +967,6 @@ F: drivers/gpu/drm/amd/include/v9_structs.h
F: drivers/gpu/drm/amd/include/vi_structs.h
F: include/uapi/linux/kfd_ioctl.h
-AMD SPI DRIVER
-M: Sanjay R Mehta <sanju.mehta@amd.com>
-S: Maintained
-F: drivers/spi/spi-amd.c
-
AMD MP2 I2C DRIVER
M: Elie Morisse <syniurge@gmail.com>
M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
@@ -1006,13 +1001,6 @@ M: Tom Lendacky <thomas.lendacky@amd.com>
S: Supported
F: arch/arm64/boot/dts/amd/
-AMD XGBE DRIVER
-M: Tom Lendacky <thomas.lendacky@amd.com>
-L: netdev@vger.kernel.org
-S: Supported
-F: arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
-F: drivers/net/ethernet/amd/xgbe/
-
AMD SENSOR FUSION HUB DRIVER
M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
M: Basavaraj Natikar <basavaraj.natikar@amd.com>
@@ -1021,6 +1009,18 @@ S: Maintained
F: Documentation/hid/amd-sfh*
F: drivers/hid/amd-sfh-hid/
+AMD SPI DRIVER
+M: Sanjay R Mehta <sanju.mehta@amd.com>
+S: Maintained
+F: drivers/spi/spi-amd.c
+
+AMD XGBE DRIVER
+M: Tom Lendacky <thomas.lendacky@amd.com>
+L: netdev@vger.kernel.org
+S: Supported
+F: arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
+F: drivers/net/ethernet/amd/xgbe/
+
AMS AS73211 DRIVER
M: Christian Eggers <ceggers@arri.de>
L: linux-iio@vger.kernel.org
@@ -1409,6 +1409,16 @@ S: Maintained
F: drivers/net/arcnet/
F: include/uapi/linux/if_arcnet.h
+ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
+M: Arnd Bergmann <arnd@arndb.de>
+M: Olof Johansson <olof@lixom.net>
+M: soc@kernel.org
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
+F: arch/arm/boot/dts/Makefile
+F: arch/arm64/boot/dts/Makefile
+
ARM ARCHITECTED TIMER DRIVER
M: Mark Rutland <mark.rutland@arm.com>
M: Marc Zyngier <maz@kernel.org>
@@ -1525,22 +1535,6 @@ S: Odd Fixes
F: drivers/amba/
F: include/linux/amba/bus.h
-ARM PRIMECELL PL35X NAND CONTROLLER DRIVER
-M: Miquel Raynal <miquel.raynal@bootlin.com>
-M: Naga Sureshkumar Relli <nagasure@xilinx.com>
-L: linux-mtd@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
-F: drivers/mtd/nand/raw/pl35x-nand-controller.c
-
-ARM PRIMECELL PL35X SMC DRIVER
-M: Miquel Raynal <miquel.raynal@bootlin.com>
-M: Naga Sureshkumar Relli <nagasure@xilinx.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
-F: drivers/memory/pl353-smc.c
-
ARM PRIMECELL CLCD PL110 DRIVER
M: Russell King <linux@armlinux.org.uk>
S: Odd Fixes
@@ -1558,6 +1552,22 @@ S: Odd Fixes
F: drivers/mmc/host/mmci.*
F: include/linux/amba/mmci.h
+ARM PRIMECELL PL35X NAND CONTROLLER DRIVER
+M: Miquel Raynal <miquel.raynal@bootlin.com>
+M: Naga Sureshkumar Relli <nagasure@xilinx.com>
+L: linux-mtd@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
+F: drivers/mtd/nand/raw/pl35x-nand-controller.c
+
+ARM PRIMECELL PL35X SMC DRIVER
+M: Miquel Raynal <miquel.raynal@bootlin.com>
+M: Naga Sureshkumar Relli <nagasure@xilinx.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
+F: drivers/memory/pl353-smc.c
+
ARM PRIMECELL SSP PL022 SPI DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -1594,16 +1604,6 @@ F: Documentation/devicetree/bindings/iommu/arm,smmu*
F: drivers/iommu/arm/
F: drivers/iommu/io-pgtable-arm*
-ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
-M: Arnd Bergmann <arnd@arndb.de>
-M: Olof Johansson <olof@lixom.net>
-M: soc@kernel.org
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
-F: arch/arm/boot/dts/Makefile
-F: arch/arm64/boot/dts/Makefile
-
ARM SUB-ARCHITECTURES
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
@@ -2256,13 +2256,6 @@ F: arch/arm64/boot/dts/microchip/
F: drivers/pinctrl/pinctrl-microchip-sgpio.c
N: sparx5
-Microchip Timer Counter Block (TCB) Capture Driver
-M: Kamel Bouhara <kamel.bouhara@bootlin.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: linux-iio@vger.kernel.org
-S: Maintained
-F: drivers/counter/microchip-tcb-capture.c
-
ARM/MILBEAUT ARCHITECTURE
M: Taichi Sugaya <sugaya.taichi@socionext.com>
M: Takao Orito <orito.takao@socionext.com>
@@ -4106,29 +4099,6 @@ W: https://github.com/Cascoda/ca8210-linux.git
F: Documentation/devicetree/bindings/net/ieee802154/ca8210.txt
F: drivers/net/ieee802154/ca8210.c
-CANAAN/KENDRYTE K210 SOC FPIOA DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-riscv@lists.infradead.org
-L: linux-gpio@vger.kernel.org (pinctrl driver)
-F: Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
-F: drivers/pinctrl/pinctrl-k210.c
-
-CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-kernel@vger.kernel.org
-L: linux-riscv@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
-F: drivers/reset/reset-k210.c
-
-CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-riscv@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
-F: drivers/soc/canaan/
-F: include/soc/canaan/
-
CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS
M: David Howells <dhowells@redhat.com>
L: linux-cachefs@redhat.com (moderated for non-subscribers)
@@ -4251,6 +4221,29 @@ F: Documentation/networking/j1939.rst
F: include/uapi/linux/can/j1939.h
F: net/can/j1939/
+CANAAN/KENDRYTE K210 SOC FPIOA DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-riscv@lists.infradead.org
+L: linux-gpio@vger.kernel.org (pinctrl driver)
+F: Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
+F: drivers/pinctrl/pinctrl-k210.c
+
+CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-kernel@vger.kernel.org
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
+F: drivers/reset/reset-k210.c
+
+CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
+F: drivers/soc/canaan/
+F: include/soc/canaan/
+
CAPABILITIES
M: Serge Hallyn <serge@hallyn.com>
L: linux-security-module@vger.kernel.org
@@ -4500,17 +4493,17 @@ F: drivers/power/supply/cros_usbpd-charger.c
N: cros_ec
N: cros-ec
-CHROMEOS EC USB TYPE-C DRIVER
-M: Prashant Malani <pmalani@chromium.org>
-S: Maintained
-F: drivers/platform/chrome/cros_ec_typec.c
-
CHROMEOS EC USB PD NOTIFY DRIVER
M: Prashant Malani <pmalani@chromium.org>
S: Maintained
F: drivers/platform/chrome/cros_usbpd_notify.c
F: include/linux/platform_data/cros_usbpd_notify.h
+CHROMEOS EC USB TYPE-C DRIVER
+M: Prashant Malani <pmalani@chromium.org>
+S: Maintained
+F: drivers/platform/chrome/cros_ec_typec.c
+
CHRONTEL CH7322 CEC DRIVER
M: Joe Tessler <jrt@google.com>
L: linux-media@vger.kernel.org
@@ -4615,6 +4608,18 @@ M: Nelson Escobar <neescoba@cisco.com>
S: Supported
F: drivers/infiniband/hw/usnic/
+CLANG CONTROL FLOW INTEGRITY SUPPORT
+M: Sami Tolvanen <samitolvanen@google.com>
+M: Kees Cook <keescook@chromium.org>
+R: Nathan Chancellor <nathan@kernel.org>
+R: Nick Desaulniers <ndesaulniers@google.com>
+L: llvm@lists.linux.dev
+S: Supported
+B: https://github.com/ClangBuiltLinux/linux/issues
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
+F: include/linux/cfi.h
+F: kernel/cfi.c
+
CLANG-FORMAT FILE
M: Miguel Ojeda <ojeda@kernel.org>
S: Maintained
@@ -4634,18 +4639,6 @@ F: scripts/Makefile.clang
F: scripts/clang-tools/
K: \b(?i:clang|llvm)\b
-CLANG CONTROL FLOW INTEGRITY SUPPORT
-M: Sami Tolvanen <samitolvanen@google.com>
-M: Kees Cook <keescook@chromium.org>
-R: Nathan Chancellor <nathan@kernel.org>
-R: Nick Desaulniers <ndesaulniers@google.com>
-L: llvm@lists.linux.dev
-S: Supported
-B: https://github.com/ClangBuiltLinux/linux/issues
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
-F: include/linux/cfi.h
-F: kernel/cfi.c
-
CLEANCACHE API
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
L: linux-kernel@vger.kernel.org
@@ -5128,6 +5121,13 @@ S: Supported
W: http://www.chelsio.com
F: drivers/crypto/chelsio
+CXGB4 ETHERNET DRIVER (CXGB4)
+M: Raju Rangoju <rajur@chelsio.com>
+L: netdev@vger.kernel.org
+S: Supported
+W: http://www.chelsio.com
+F: drivers/net/ethernet/chelsio/cxgb4/
+
CXGB4 INLINE CRYPTO DRIVER
M: Ayush Sawal <ayush.sawal@chelsio.com>
M: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
@@ -5137,13 +5137,6 @@ S: Supported
W: http://www.chelsio.com
F: drivers/net/ethernet/chelsio/inline_crypto/
-CXGB4 ETHERNET DRIVER (CXGB4)
-M: Raju Rangoju <rajur@chelsio.com>
-L: netdev@vger.kernel.org
-S: Supported
-W: http://www.chelsio.com
-F: drivers/net/ethernet/chelsio/cxgb4/
-
CXGB4 ISCSI DRIVER (CXGB4I)
M: Karen Xie <kxie@chelsio.com>
L: linux-scsi@vger.kernel.org
@@ -5199,16 +5192,6 @@ CYCLADES PC300 DRIVER
S: Orphan
F: drivers/net/wan/pc300*
-CYPRESS_FIRMWARE MEDIA DRIVER
-M: Antti Palosaari <crope@iki.fi>
-L: linux-media@vger.kernel.org
-S: Maintained
-W: https://linuxtv.org
-W: http://palosaari.fi/linux/
-Q: http://patchwork.linuxtv.org/project/linux-media/list/
-T: git git://linuxtv.org/anttip/media_tree.git
-F: drivers/media/common/cypress_firmware*
-
CYPRESS CY8CTMA140 TOUCHSCREEN DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-input@vger.kernel.org
@@ -5222,6 +5205,16 @@ S: Maintained
F: Documentation/devicetree/bindings/input/cypress-sf.yaml
F: drivers/input/keyboard/cypress-sf.c
+CYPRESS_FIRMWARE MEDIA DRIVER
+M: Antti Palosaari <crope@iki.fi>
+L: linux-media@vger.kernel.org
+S: Maintained
+W: https://linuxtv.org
+W: http://palosaari.fi/linux/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/anttip/media_tree.git
+F: drivers/media/common/cypress_firmware*
+
CYTTSP TOUCHSCREEN DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-input@vger.kernel.org
@@ -5392,14 +5385,12 @@ L: Dell.Client.Kernel@dell.com
S: Maintained
F: drivers/platform/x86/dell/dell-wmi-descriptor.c
-DELL WMI SYSMAN DRIVER
-M: Divya Bharathi <divya.bharathi@dell.com>
-M: Prasanth Ksr <prasanth.ksr@dell.com>
+DELL WMI HARDWARE PRIVACY SUPPORT
+M: Perry Yuan <Perry.Yuan@dell.com>
L: Dell.Client.Kernel@dell.com
L: platform-driver-x86@vger.kernel.org
S: Maintained
-F: Documentation/ABI/testing/sysfs-class-firmware-attributes
-F: drivers/platform/x86/dell/dell-wmi-sysman/
+F: drivers/platform/x86/dell/dell-wmi-privacy.c
DELL WMI NOTIFICATIONS DRIVER
M: Matthew Garrett <mjg59@srcf.ucam.org>
@@ -5407,12 +5398,21 @@ M: Pali Rohár <pali@kernel.org>
S: Maintained
F: drivers/platform/x86/dell/dell-wmi-base.c
-DELL WMI HARDWARE PRIVACY SUPPORT
-M: Perry Yuan <Perry.Yuan@dell.com>
+DELL WMI SYSMAN DRIVER
+M: Divya Bharathi <divya.bharathi@dell.com>
+M: Prasanth Ksr <prasanth.ksr@dell.com>
L: Dell.Client.Kernel@dell.com
L: platform-driver-x86@vger.kernel.org
S: Maintained
-F: drivers/platform/x86/dell/dell-wmi-privacy.c
+F: Documentation/ABI/testing/sysfs-class-firmware-attributes
+F: drivers/platform/x86/dell/dell-wmi-sysman/
+
+DELTA DPS920AB PSU DRIVER
+M: Robert Marko <robert.marko@sartura.hr>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/dps920ab.rst
+F: drivers/hwmon/pmbus/dps920ab.c
DELTA ST MEDIA DRIVER
M: Hugues Fruchet <hugues.fruchet@foss.st.com>
@@ -5422,13 +5422,6 @@ W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/platform/sti/delta
-DELTA DPS920AB PSU DRIVER
-M: Robert Marko <robert.marko@sartura.hr>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/hwmon/dps920ab.rst
-F: drivers/hwmon/pmbus/dps920ab.c
-
DENALI NAND DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -5441,13 +5434,6 @@ S: Maintained
F: drivers/dma/dw-edma/
F: include/linux/dma/edma.h
-DESIGNWARE XDATA IP DRIVER
-M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
-L: linux-pci@vger.kernel.org
-S: Maintained
-F: Documentation/misc-devices/dw-xdata-pcie.rst
-F: drivers/misc/dw-xdata-pcie.c
-
DESIGNWARE USB2 DRD IP DRIVER
M: Minas Harutyunyan <hminas@synopsys.com>
L: linux-usb@vger.kernel.org
@@ -5462,6 +5448,13 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
F: drivers/usb/dwc3/
+DESIGNWARE XDATA IP DRIVER
+M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+L: linux-pci@vger.kernel.org
+S: Maintained
+F: Documentation/misc-devices/dw-xdata-pcie.rst
+F: drivers/misc/dw-xdata-pcie.c
+
DEVANTECH SRF ULTRASONIC RANGER IIO DRIVER
M: Andreas Klinger <ak@it-klinger.de>
L: linux-iio@vger.kernel.org
@@ -5691,6 +5684,12 @@ F: include/linux/dma/
F: include/linux/dmaengine.h
F: include/linux/of_dma.h
+DMA MAPPING BENCHMARK
+M: Barry Song <song.bao.hua@hisilicon.com>
+L: iommu@lists.linux-foundation.org
+F: kernel/dma/map_benchmark.c
+F: tools/testing/selftests/dma/
+
DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
@@ -5705,12 +5704,6 @@ F: include/linux/dma-mapping.h
F: include/linux/dma-map-ops.h
F: kernel/dma/
-DMA MAPPING BENCHMARK
-M: Barry Song <song.bao.hua@hisilicon.com>
-L: iommu@lists.linux-foundation.org
-F: kernel/dma/map_benchmark.c
-F: tools/testing/selftests/dma/
-
DMA-BUF HEAPS FRAMEWORK
M: Sumit Semwal <sumit.semwal@linaro.org>
R: Benjamin Gaignard <benjamin.gaignard@linaro.org>
@@ -5992,6 +5985,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
F: drivers/gpu/drm/tiny/hx8357d.c
+DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
+M: Deepak Rawat <drawat.floss@gmail.com>
+L: linux-hyperv@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/hyperv
+
DRM DRIVER FOR ILITEK ILI9225 PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
@@ -6137,14 +6138,6 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml
F: drivers/gpu/drm/panel/panel-samsung-s6d27a1.c
-DRM DRIVER FOR SITRONIX ST7703 PANELS
-M: Guido Günther <agx@sigxcpu.org>
-R: Purism Kernel Team <kernel@puri.sm>
-R: Ondrej Jirman <megous@megous.com>
-S: Maintained
-F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
-F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
-
DRM DRIVER FOR SAVAGE VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/savage/
@@ -6175,6 +6168,14 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
F: drivers/gpu/drm/panel/panel-sitronix-st7701.c
+DRM DRIVER FOR SITRONIX ST7703 PANELS
+M: Guido Günther <agx@sigxcpu.org>
+R: Purism Kernel Team <kernel@puri.sm>
+R: Ondrej Jirman <megous@megous.com>
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
+
DRM DRIVER FOR SITRONIX ST7735R PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
@@ -6369,14 +6370,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/hisilicon/
F: drivers/gpu/drm/hisilicon/
-DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
-M: Deepak Rawat <drawat.floss@gmail.com>
-L: linux-hyperv@vger.kernel.org
-L: dri-devel@lists.freedesktop.org
-S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
-F: drivers/gpu/drm/hyperv
-
DRM DRIVERS FOR LIMA
M: Qiang Yu <yuq825@gmail.com>
L: dri-devel@lists.freedesktop.org
@@ -6524,6 +6517,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/xlnx/
F: drivers/gpu/drm/xlnx/
+DRM GPU SCHEDULER
+M: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/scheduler/
+F: include/drm/gpu_scheduler.h
+
DRM PANEL DRIVERS
M: Thierry Reding <thierry.reding@gmail.com>
R: Sam Ravnborg <sam@ravnborg.org>
@@ -6544,14 +6545,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/gpu/drm/ttm/
F: include/drm/ttm/
-DRM GPU SCHEDULER
-M: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
-L: dri-devel@lists.freedesktop.org
-S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
-F: drivers/gpu/drm/scheduler/
-F: include/drm/gpu_scheduler.h
-
DSBR100 USB FM RADIO DRIVER
M: Alexey Klimov <klimov.linux@gmail.com>
L: linux-media@vger.kernel.org
@@ -6690,6 +6683,15 @@ F: Documentation/networking/net_dim.rst
F: include/linux/dim.h
F: lib/dim/
+DYNAMIC THERMAL POWER MANAGEMENT (DTPM)
+M: Daniel Lezcano <daniel.lezcano@kernel.org>
+L: linux-pm@vger.kernel.org
+S: Supported
+B: https://bugzilla.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
+F: drivers/powercap/dtpm*
+F: include/linux/dtpm.h
+
DZ DECSTATION DZ11 SERIAL DRIVER
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
S: Maintained
@@ -7037,22 +7039,22 @@ W: http://www.broadcom.com
F: drivers/infiniband/hw/ocrdma/
F: include/uapi/rdma/ocrdma-abi.h
-EMULEX/BROADCOM LPFC FC/FCOE SCSI DRIVER
+EMULEX/BROADCOM EFCT FC/FCOE SCSI TARGET DRIVER
M: James Smart <james.smart@broadcom.com>
-M: Dick Kennedy <dick.kennedy@broadcom.com>
+M: Ram Vegesna <ram.vegesna@broadcom.com>
L: linux-scsi@vger.kernel.org
+L: target-devel@vger.kernel.org
S: Supported
W: http://www.broadcom.com
-F: drivers/scsi/lpfc/
+F: drivers/scsi/elx/
-EMULEX/BROADCOM EFCT FC/FCOE SCSI TARGET DRIVER
+EMULEX/BROADCOM LPFC FC/FCOE SCSI DRIVER
M: James Smart <james.smart@broadcom.com>
-M: Ram Vegesna <ram.vegesna@broadcom.com>
+M: Dick Kennedy <dick.kennedy@broadcom.com>
L: linux-scsi@vger.kernel.org
-L: target-devel@vger.kernel.org
S: Supported
W: http://www.broadcom.com
-F: drivers/scsi/elx/
+F: drivers/scsi/lpfc/
ENE CB710 FLASH CARD READER DRIVER
M: Michał Mirosław <mirq-linux@rere.qmqm.pl>
@@ -8529,6 +8531,12 @@ W: http://www.highpoint-tech.com
F: Documentation/scsi/hptiop.rst
F: drivers/scsi/hptiop.c
+HIKEY960 ONBOARD USB GPIO HUB DRIVER
+M: John Stultz <john.stultz@linaro.org>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/misc/hisi_hikey_usb.c
+
HIPPI
M: Jes Sorensen <jes@trained-monkey.org>
L: linux-hippi@sunsite.dk
@@ -8599,12 +8607,6 @@ W: http://www.hisilicon.com
F: Documentation/devicetree/bindings/net/hisilicon*.txt
F: drivers/net/ethernet/hisilicon/
-HIKEY960 ONBOARD USB GPIO HUB DRIVER
-M: John Stultz <john.stultz@linaro.org>
-L: linux-kernel@vger.kernel.org
-S: Maintained
-F: drivers/misc/hisi_hikey_usb.c
-
HISILICON PMU DRIVER
M: Shaokun Zhang <zhangshaokun@hisilicon.com>
S: Supported
@@ -9630,18 +9632,18 @@ F: Documentation/admin-guide/media/ipu3_rcb.svg
F: Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst
F: drivers/staging/media/ipu3/
-INTEL IXP4XX CRYPTO SUPPORT
-M: Corentin Labbe <clabbe@baylibre.com>
-L: linux-crypto@vger.kernel.org
-S: Maintained
-F: drivers/crypto/ixp4xx_crypto.c
-
INTEL ISHTP ECLITE DRIVER
M: Sumesh K Naduvalath <sumesh.k.naduvalath@intel.com>
L: platform-driver-x86@vger.kernel.org
S: Supported
F: drivers/platform/x86/intel/ishtp_eclite.c
+INTEL IXP4XX CRYPTO SUPPORT
+M: Corentin Labbe <clabbe@baylibre.com>
+L: linux-crypto@vger.kernel.org
+S: Maintained
+F: drivers/crypto/ixp4xx_crypto.c
+
INTEL IXP4XX QMGR, NPE, ETHERNET and HSS SUPPORT
M: Krzysztof Halasa <khalasa@piap.pl>
S: Maintained
@@ -9784,6 +9786,21 @@ S: Maintained
F: arch/x86/include/asm/intel_scu_ipc.h
F: drivers/platform/x86/intel_scu_*
+INTEL SGX
+M: Jarkko Sakkinen <jarkko@kernel.org>
+R: Dave Hansen <dave.hansen@linux.intel.com>
+L: linux-sgx@vger.kernel.org
+S: Supported
+Q: https://patchwork.kernel.org/project/intel-sgx/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/sgx
+F: Documentation/x86/sgx.rst
+F: arch/x86/entry/vdso/vsgx.S
+F: arch/x86/include/asm/sgx.h
+F: arch/x86/include/uapi/asm/sgx.h
+F: arch/x86/kernel/cpu/sgx/*
+F: tools/testing/selftests/sgx/*
+K: \bSGX_
+
INTEL SKYLAKE INT3472 ACPI DEVICE DRIVER
M: Daniel Scally <djrscally@gmail.com>
S: Maintained
@@ -9878,21 +9895,6 @@ F: Documentation/x86/intel_txt.rst
F: arch/x86/kernel/tboot.c
F: include/linux/tboot.h
-INTEL SGX
-M: Jarkko Sakkinen <jarkko@kernel.org>
-R: Dave Hansen <dave.hansen@linux.intel.com>
-L: linux-sgx@vger.kernel.org
-S: Supported
-Q: https://patchwork.kernel.org/project/intel-sgx/list/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/sgx
-F: Documentation/x86/sgx.rst
-F: arch/x86/entry/vdso/vsgx.S
-F: arch/x86/include/asm/sgx.h
-F: arch/x86/include/uapi/asm/sgx.h
-F: arch/x86/kernel/cpu/sgx/*
-F: tools/testing/selftests/sgx/*
-K: \bSGX_
-
INTERCONNECT API
M: Georgi Djakov <djakov@kernel.org>
L: linux-pm@vger.kernel.org
@@ -11298,6 +11300,12 @@ F: drivers/mailbox/arm_mhuv2.c
F: include/linux/mailbox/arm_mhuv2_message.h
F: Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
+MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
+M: Michael Kerrisk <mtk.manpages@gmail.com>
+L: linux-man@vger.kernel.org
+S: Maintained
+W: http://www.kernel.org/doc/man-pages
+
MANAGEMENT COMPONENT TRANSPORT PROTOCOL (MCTP)
M: Jeremy Kerr <jk@codeconstruct.com.au>
M: Matt Johnston <matt@codeconstruct.com.au>
@@ -11310,12 +11318,6 @@ F: include/net/mctpdevice.h
F: include/net/netns/mctp.h
F: net/mctp/
-MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
-M: Michael Kerrisk <mtk.manpages@gmail.com>
-L: linux-man@vger.kernel.org
-S: Maintained
-W: http://www.kernel.org/doc/man-pages
-
MARDUK (CREATOR CI40) DEVICE TREE SUPPORT
M: Rahul Bedarkar <rahulbedarkar89@gmail.com>
L: linux-mips@vger.kernel.org
@@ -11634,12 +11636,6 @@ L: netdev@vger.kernel.org
S: Supported
F: drivers/net/phy/mxl-gpy.c
-MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
-R: Yasushi SHOJI <yashi@spacecubics.com>
-L: linux-can@vger.kernel.org
-S: Maintained
-F: drivers/net/can/usb/mcba_usb.c
-
MCAN MMIO DEVICE DRIVER
M: Chandrasekar Ramakrishnan <rcsekar@samsung.com>
L: linux-can@vger.kernel.org
@@ -11649,6 +11645,12 @@ F: drivers/net/can/m_can/m_can.c
F: drivers/net/can/m_can/m_can.h
F: drivers/net/can/m_can/m_can_platform.c
+MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
+R: Yasushi SHOJI <yashi@spacecubics.com>
+L: linux-can@vger.kernel.org
+S: Maintained
+F: drivers/net/can/usb/mcba_usb.c
+
MCP2221A MICROCHIP USB-HID TO I2C BRIDGE DRIVER
M: Rishi Gupta <gupt21@gmail.com>
L: linux-i2c@vger.kernel.org
@@ -12041,13 +12043,6 @@ S: Maintained
F: Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
F: drivers/clk/ralink/clk-mt7621.c
-MEDIATEK MT7621/28/88 I2C DRIVER
-M: Stefan Roese <sr@denx.de>
-L: linux-i2c@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
-F: drivers/i2c/busses/i2c-mt7621.c
-
MEDIATEK MT7621 PCIE CONTROLLER DRIVER
M: Sergio Paracuellos <sergio.paracuellos@gmail.com>
S: Maintained
@@ -12060,6 +12055,13 @@ S: Maintained
F: Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
F: drivers/phy/ralink/phy-mt7621-pci.c
+MEDIATEK MT7621/28/88 I2C DRIVER
+M: Stefan Roese <sr@denx.de>
+L: linux-i2c@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
+F: drivers/i2c/busses/i2c-mt7621.c
+
MEDIATEK NAND CONTROLLER DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -12591,6 +12593,13 @@ S: Supported
F: drivers/misc/atmel-ssc.c
F: include/linux/atmel-ssc.h
+Microchip Timer Counter Block (TCB) Capture Driver
+M: Kamel Bouhara <kamel.bouhara@bootlin.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: drivers/counter/microchip-tcb-capture.c
+
MICROCHIP USB251XB DRIVER
M: Richard Leitner <richard.leitner@skidata.com>
L: linux-usb@vger.kernel.org
@@ -13691,13 +13700,6 @@ F: drivers/iio/gyro/fxas21002c_core.c
F: drivers/iio/gyro/fxas21002c_i2c.c
F: drivers/iio/gyro/fxas21002c_spi.c
-NXP i.MX CLOCK DRIVERS
-M: Abel Vesa <abel.vesa@nxp.com>
-L: linux-clk@vger.kernel.org
-L: linux-imx@nxp.com
-S: Maintained
-F: drivers/clk/imx/
-
NXP i.MX 8MQ DCSS DRIVER
M: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
R: Lucas Stach <l.stach@pengutronix.de>
@@ -13713,6 +13715,21 @@ S: Supported
F: Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
F: drivers/iio/adc/imx8qxp-adc.c
+NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
+M: Mirela Rabulea <mirela.rabulea@nxp.com>
+R: NXP Linux Team <linux-imx@nxp.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
+F: drivers/media/platform/imx-jpeg
+
+NXP i.MX CLOCK DRIVERS
+M: Abel Vesa <abel.vesa@nxp.com>
+L: linux-clk@vger.kernel.org
+L: linux-imx@nxp.com
+S: Maintained
+F: drivers/clk/imx/
+
NXP PF8100/PF8121A/PF8200 PMIC REGULATOR DEVICE DRIVER
M: Jagan Teki <jagan@amarulasolutions.com>
S: Maintained
@@ -13750,19 +13767,12 @@ F: include/drm/i2c/tda998x.h
F: include/dt-bindings/display/tda998x.h
K: "nxp,tda998x"
-NXP TFA9879 DRIVER
-M: Peter Rosin <peda@axentia.se>
-L: alsa-devel@alsa-project.org (moderated for non-subscribers)
-S: Maintained
-F: Documentation/devicetree/bindings/sound/tfa9879.txt
-F: sound/soc/codecs/tfa9879*
-
-NXP/Goodix TFA989X (TFA1) DRIVER
-M: Stephan Gerhold <stephan@gerhold.net>
+NXP TFA9879 DRIVER
+M: Peter Rosin <peda@axentia.se>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
-F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
-F: sound/soc/codecs/tfa989x.c
+F: Documentation/devicetree/bindings/sound/tfa9879.txt
+F: sound/soc/codecs/tfa9879*
NXP-NCI NFC DRIVER
R: Charles Gorand <charles.gorand@effinnov.com>
@@ -13771,13 +13781,12 @@ S: Supported
F: Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml
F: drivers/nfc/nxp-nci
-NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
-M: Mirela Rabulea <mirela.rabulea@nxp.com>
-R: NXP Linux Team <linux-imx@nxp.com>
-L: linux-media@vger.kernel.org
+NXP/Goodix TFA989X (TFA1) DRIVER
+M: Stephan Gerhold <stephan@gerhold.net>
+L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
-F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
-F: drivers/media/platform/imx-jpeg
+F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
+F: sound/soc/codecs/tfa989x.c
NZXT-KRAKEN2 HARDWARE MONITORING DRIVER
M: Jonas Malaco <jonas@protocubo.io>
@@ -14567,6 +14576,14 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/pci/controller/dwc/*layerscape*
+PCI DRIVER FOR FU740
+M: Paul Walmsley <paul.walmsley@sifive.com>
+M: Greentime Hu <greentime.hu@sifive.com>
+L: linux-pci@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
+F: drivers/pci/controller/dwc/pcie-fu740.c
+
PCI DRIVER FOR GENERIC OF HOSTS
M: Will Deacon <will@kernel.org>
L: linux-pci@vger.kernel.org
@@ -14585,14 +14602,6 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
F: drivers/pci/controller/dwc/*imx6*
-PCI DRIVER FOR FU740
-M: Paul Walmsley <paul.walmsley@sifive.com>
-M: Greentime Hu <greentime.hu@sifive.com>
-L: linux-pci@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
-F: drivers/pci/controller/dwc/pcie-fu740.c
-
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
@@ -14865,14 +14874,6 @@ L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/pci/controller/dwc/pcie-qcom.c
-PCIE ENDPOINT DRIVER FOR QUALCOMM
-M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-L: linux-pci@vger.kernel.org
-L: linux-arm-msm@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
-F: drivers/pci/controller/dwc/pcie-qcom-ep.c
-
PCIE DRIVER FOR ROCKCHIP
M: Shawn Lin <shawn.lin@rock-chips.com>
L: linux-pci@vger.kernel.org
@@ -14894,6 +14895,14 @@ L: linux-pci@vger.kernel.org
S: Maintained
F: drivers/pci/controller/dwc/*spear*
+PCIE ENDPOINT DRIVER FOR QUALCOMM
+M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+L: linux-pci@vger.kernel.org
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
+F: drivers/pci/controller/dwc/pcie-qcom-ep.c
+
PCMCIA SUBSYSTEM
M: Dominik Brodowski <linux@dominikbrodowski.net>
S: Odd Fixes
@@ -15153,13 +15162,6 @@ M: Logan Gunthorpe <logang@deltatee.com>
S: Maintained
F: drivers/dma/plx_dma.c
-PM6764TR DRIVER
-M: Charles Hsu <hsu.yungteng@gmail.com>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/hwmon/pm6764tr.rst
-F: drivers/hwmon/pmbus/pm6764tr.c
-
PM-GRAPH UTILITY
M: "Todd E Brandt" <todd.e.brandt@linux.intel.com>
L: linux-pm@vger.kernel.org
@@ -15169,6 +15171,13 @@ B: https://bugzilla.kernel.org/buglist.cgi?component=pm-graph&product=Tools
T: git git://github.com/intel/pm-graph
F: tools/power/pm-graph
+PM6764TR DRIVER
+M: Charles Hsu <hsu.yungteng@gmail.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/pm6764tr.rst
+F: drivers/hwmon/pmbus/pm6764tr.c
+
PMBUS HARDWARE MONITORING DRIVERS
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
@@ -15249,15 +15258,6 @@ F: include/linux/pm_*
F: include/linux/powercap.h
F: kernel/configs/nopm.config
-DYNAMIC THERMAL POWER MANAGEMENT (DTPM)
-M: Daniel Lezcano <daniel.lezcano@kernel.org>
-L: linux-pm@vger.kernel.org
-S: Supported
-B: https://bugzilla.kernel.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
-F: drivers/powercap/dtpm*
-F: include/linux/dtpm.h
-
POWER STATE COORDINATION INTERFACE (PSCI)
M: Mark Rutland <mark.rutland@arm.com>
M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
@@ -16272,12 +16272,6 @@ S: Supported
F: Documentation/devicetree/bindings/i2c/renesas,riic.yaml
F: drivers/i2c/busses/i2c-riic.c
-RENESAS USB PHY DRIVER
-M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
-L: linux-renesas-soc@vger.kernel.org
-S: Maintained
-F: drivers/phy/renesas/phy-rcar-gen3-usb*.c
-
RENESAS RZ/G2L A/D DRIVER
M: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
L: linux-iio@vger.kernel.org
@@ -16286,6 +16280,12 @@ S: Supported
F: Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
F: drivers/iio/adc/rzg2l_adc.c
+RENESAS USB PHY DRIVER
+M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+L: linux-renesas-soc@vger.kernel.org
+S: Maintained
+F: drivers/phy/renesas/phy-rcar-gen3-usb*.c
+
RESET CONTROLLER FRAMEWORK
M: Philipp Zabel <p.zabel@pengutronix.de>
S: Maintained
@@ -17116,6 +17116,15 @@ F: block/sed*
F: include/linux/sed*
F: include/uapi/linux/sed*
+SECURE MONITOR CALL(SMC) CALLING CONVENTION (SMCCC)
+M: Mark Rutland <mark.rutland@arm.com>
+M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+M: Sudeep Holla <sudeep.holla@arm.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/firmware/smccc/
+F: include/linux/arm-smccc.h
+
SECURITY CONTACT
M: Security Officers <security@kernel.org>
S: Supported
@@ -17523,15 +17532,6 @@ M: Nicolas Pitre <nico@fluxnic.net>
S: Odd Fixes
F: drivers/net/ethernet/smsc/smc91x.*
-SECURE MONITOR CALL(SMC) CALLING CONVENTION (SMCCC)
-M: Mark Rutland <mark.rutland@arm.com>
-M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-M: Sudeep Holla <sudeep.holla@arm.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: drivers/firmware/smccc/
-F: include/linux/arm-smccc.h
-
SMM665 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
@@ -18713,6 +18713,14 @@ M: Thierry Reding <thierry.reding@gmail.com>
S: Supported
F: drivers/pwm/pwm-tegra.c
+TEGRA QUAD SPI DRIVER
+M: Thierry Reding <thierry.reding@gmail.com>
+M: Jonathan Hunter <jonathanh@nvidia.com>
+M: Sowjanya Komatineni <skomatineni@nvidia.com>
+L: linux-tegra@vger.kernel.org
+S: Maintained
+F: drivers/spi/spi-tegra210-quad.c
+
TEGRA SERIAL DRIVER
M: Laxman Dewangan <ldewangan@nvidia.com>
S: Supported
@@ -18723,14 +18731,6 @@ M: Laxman Dewangan <ldewangan@nvidia.com>
S: Supported
F: drivers/spi/spi-tegra*
-TEGRA QUAD SPI DRIVER
-M: Thierry Reding <thierry.reding@gmail.com>
-M: Jonathan Hunter <jonathanh@nvidia.com>
-M: Sowjanya Komatineni <skomatineni@nvidia.com>
-L: linux-tegra@vger.kernel.org
-S: Maintained
-F: drivers/spi/spi-tegra210-quad.c
-
TEGRA VIDEO DRIVER
M: Thierry Reding <thierry.reding@gmail.com>
M: Jonathan Hunter <jonathanh@nvidia.com>
@@ -18779,13 +18779,6 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: sound/soc/ti/
-TEXAS INSTRUMENTS' DAC7612 DAC DRIVER
-M: Ricardo Ribalda <ribalda@kernel.org>
-L: linux-iio@vger.kernel.org
-S: Supported
-F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
-F: drivers/iio/dac/ti-dac7612.c
-
TEXAS INSTRUMENTS DMA DRIVERS
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: dmaengine@vger.kernel.org
@@ -18799,6 +18792,22 @@ F: include/linux/dma/k3-udma-glue.h
F: include/linux/dma/ti-cppi5.h
F: include/linux/dma/k3-psil.h
+TEXAS INSTRUMENTS TPS23861 PoE PSE DRIVER
+M: Robert Marko <robert.marko@sartura.hr>
+M: Luka Perkov <luka.perkov@sartura.hr>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
+F: Documentation/hwmon/tps23861.rst
+F: drivers/hwmon/tps23861.c
+
+TEXAS INSTRUMENTS' DAC7612 DAC DRIVER
+M: Ricardo Ribalda <ribalda@kernel.org>
+L: linux-iio@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
+F: drivers/iio/dac/ti-dac7612.c
+
TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER
M: Nishanth Menon <nm@ti.com>
M: Tero Kristo <kristo@kernel.org>
@@ -18823,15 +18832,6 @@ F: include/dt-bindings/soc/ti,sci_pm_domain.h
F: include/linux/soc/ti/ti_sci_inta_msi.h
F: include/linux/soc/ti/ti_sci_protocol.h
-TEXAS INSTRUMENTS TPS23861 PoE PSE DRIVER
-M: Robert Marko <robert.marko@sartura.hr>
-M: Luka Perkov <luka.perkov@sartura.hr>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
-F: Documentation/hwmon/tps23861.rst
-F: drivers/hwmon/tps23861.c
-
TEXAS INSTRUMENTS' TMP117 TEMPERATURE SENSOR DRIVER
M: Puranjay Mohan <puranjay12@gmail.com>
L: linux-iio@vger.kernel.org
@@ -19732,6 +19732,13 @@ L: linux-usb@vger.kernel.org
S: Supported
F: drivers/usb/class/usblp.c
+USB QMI WWAN NETWORK DRIVER
+M: Bjørn Mork <bjorn@mork.no>
+L: netdev@vger.kernel.org
+S: Maintained
+F: Documentation/ABI/testing/sysfs-class-net-qmi
+F: drivers/net/usb/qmi_wwan.c
+
USB RAW GADGET DRIVER
R: Andrey Konovalov <andreyknvl@gmail.com>
L: linux-usb@vger.kernel.org
@@ -19740,13 +19747,6 @@ F: Documentation/usb/raw-gadget.rst
F: drivers/usb/gadget/legacy/raw_gadget.c
F: include/uapi/linux/usb/raw_gadget.h
-USB QMI WWAN NETWORK DRIVER
-M: Bjørn Mork <bjorn@mork.no>
-L: netdev@vger.kernel.org
-S: Maintained
-F: Documentation/ABI/testing/sysfs-class-net-qmi
-F: drivers/net/usb/qmi_wwan.c
-
USB RTL8150 DRIVER
M: Petko Manolov <petkan@nucleusys.com>
L: linux-usb@vger.kernel.org
@@ -20062,6 +20062,14 @@ S: Maintained
F: drivers/media/common/videobuf2/*
F: include/media/videobuf2-*
+VIDTV VIRTUAL DIGITAL TV DRIVER
+M: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+W: https://linuxtv.org
+T: git git://linuxtv.org/media_tree.git
+F: drivers/media/test-drivers/vidtv/*
+
VIMC VIRTUAL MEDIA CONTROLLER DRIVER
M: Helen Koike <helen.koike@collabora.com>
R: Shuah Khan <skhan@linuxfoundation.org>
@@ -20091,6 +20099,16 @@ F: include/uapi/linux/virtio_vsock.h
F: net/vmw_vsock/virtio_transport.c
F: net/vmw_vsock/virtio_transport_common.c
+VIRTIO BALLOON
+M: "Michael S. Tsirkin" <mst@redhat.com>
+M: David Hildenbrand <david@redhat.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/virtio/virtio_balloon.c
+F: include/uapi/linux/virtio_balloon.h
+F: include/linux/balloon_compaction.h
+F: mm/balloon_compaction.c
+
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
@@ -20128,16 +20146,6 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: tools/virtio/
-VIRTIO BALLOON
-M: "Michael S. Tsirkin" <mst@redhat.com>
-M: David Hildenbrand <david@redhat.com>
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/virtio/virtio_balloon.c
-F: include/uapi/linux/virtio_balloon.h
-F: include/linux/balloon_compaction.h
-F: mm/balloon_compaction.c
-
VIRTIO CRYPTO DRIVER
M: Gonglei <arei.gonglei@huawei.com>
L: virtualization@lists.linux-foundation.org
@@ -20199,6 +20207,15 @@ F: drivers/vhost/
F: include/linux/vhost_iotlb.h
F: include/uapi/linux/vhost.h
+VIRTIO I2C DRIVER
+M: Conghui Chen <conghui.chen@intel.com>
+M: Viresh Kumar <viresh.kumar@linaro.org>
+L: linux-i2c@vger.kernel.org
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/i2c/busses/i2c-virtio.c
+F: include/uapi/linux/virtio_i2c.h
+
VIRTIO INPUT DRIVER
M: Gerd Hoffmann <kraxel@redhat.com>
S: Maintained
@@ -20220,6 +20237,13 @@ W: https://virtio-mem.gitlab.io/
F: drivers/virtio/virtio_mem.c
F: include/uapi/linux/virtio_mem.h
+VIRTIO PMEM DRIVER
+M: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/nvdimm/virtio_pmem.c
+F: drivers/nvdimm/nd_virtio.c
+
VIRTIO SOUND DRIVER
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
M: "Michael S. Tsirkin" <mst@redhat.com>
@@ -20229,22 +20253,6 @@ S: Maintained
F: include/uapi/linux/virtio_snd.h
F: sound/virtio/*
-VIRTIO I2C DRIVER
-M: Conghui Chen <conghui.chen@intel.com>
-M: Viresh Kumar <viresh.kumar@linaro.org>
-L: linux-i2c@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/i2c/busses/i2c-virtio.c
-F: include/uapi/linux/virtio_i2c.h
-
-VIRTIO PMEM DRIVER
-M: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/nvdimm/virtio_pmem.c
-F: drivers/nvdimm/nd_virtio.c
-
VIRTUAL BOX GUEST DEVICE DRIVER
M: Hans de Goede <hdegoede@redhat.com>
M: Arnd Bergmann <arnd@arndb.de>
@@ -20274,14 +20282,6 @@ W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/test-drivers/vivid/*
-VIDTV VIRTUAL DIGITAL TV DRIVER
-M: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
-L: linux-media@vger.kernel.org
-S: Maintained
-W: https://linuxtv.org
-T: git git://linuxtv.org/media_tree.git
-F: drivers/media/test-drivers/vidtv/*
-
VLYNQ BUS
M: Florian Fainelli <f.fainelli@gmail.com>
L: openwrt-devel@lists.openwrt.org (subscribers-only)
@@ -20289,18 +20289,6 @@ S: Maintained
F: drivers/vlynq/vlynq.c
F: include/linux/vlynq.h
-VME SUBSYSTEM
-M: Martyn Welch <martyn@welchs.me.uk>
-M: Manohar Vanga <manohar.vanga@gmail.com>
-M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-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/vme/
-F: include/linux/vme*
-
VM SOCKETS (AF_VSOCK)
M: Stefano Garzarella <sgarzare@redhat.com>
L: virtualization@lists.linux-foundation.org
@@ -20314,6 +20302,18 @@ F: include/uapi/linux/vsockmon.h
F: net/vmw_vsock/
F: tools/testing/vsock/
+VME SUBSYSTEM
+M: Martyn Welch <martyn@welchs.me.uk>
+M: Manohar Vanga <manohar.vanga@gmail.com>
+M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+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/vme/
+F: include/linux/vme*
+
VMWARE BALLOON DRIVER
M: Nadav Amit <namit@vmware.com>
M: "VMware, Inc." <pv-drivers@vmware.com>
--
2.30.2
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [relevance 13%]
* [PATCH v1 1/1] MAINTAINERS: Sort sections with parse-maintainers.pl help
@ 2021-11-17 19:05 13% ` Andy Shevchenko
0 siblings, 0 replies; 200+ results
From: Andy Shevchenko @ 2021-11-17 19:05 UTC (permalink / raw)
To: linux-kernel, linux-riscv, llvm
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Nathan Chancellor,
Nick Desaulniers, Joe Perches, Linus Torvalds, Andy Shevchenko
Sort sections with parse-maintainers.pl help since quite a few
got unsorted from the previous run.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
MAINTAINERS | 710 ++++++++++++++++++++++++++--------------------------
1 file changed, 355 insertions(+), 355 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2345ce8521..1154c83ee3c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -967,11 +967,6 @@ F: drivers/gpu/drm/amd/include/v9_structs.h
F: drivers/gpu/drm/amd/include/vi_structs.h
F: include/uapi/linux/kfd_ioctl.h
-AMD SPI DRIVER
-M: Sanjay R Mehta <sanju.mehta@amd.com>
-S: Maintained
-F: drivers/spi/spi-amd.c
-
AMD MP2 I2C DRIVER
M: Elie Morisse <syniurge@gmail.com>
M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
@@ -1006,13 +1001,6 @@ M: Tom Lendacky <thomas.lendacky@amd.com>
S: Supported
F: arch/arm64/boot/dts/amd/
-AMD XGBE DRIVER
-M: Tom Lendacky <thomas.lendacky@amd.com>
-L: netdev@vger.kernel.org
-S: Supported
-F: arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
-F: drivers/net/ethernet/amd/xgbe/
-
AMD SENSOR FUSION HUB DRIVER
M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
M: Basavaraj Natikar <basavaraj.natikar@amd.com>
@@ -1021,6 +1009,18 @@ S: Maintained
F: Documentation/hid/amd-sfh*
F: drivers/hid/amd-sfh-hid/
+AMD SPI DRIVER
+M: Sanjay R Mehta <sanju.mehta@amd.com>
+S: Maintained
+F: drivers/spi/spi-amd.c
+
+AMD XGBE DRIVER
+M: Tom Lendacky <thomas.lendacky@amd.com>
+L: netdev@vger.kernel.org
+S: Supported
+F: arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
+F: drivers/net/ethernet/amd/xgbe/
+
AMS AS73211 DRIVER
M: Christian Eggers <ceggers@arri.de>
L: linux-iio@vger.kernel.org
@@ -1409,6 +1409,16 @@ S: Maintained
F: drivers/net/arcnet/
F: include/uapi/linux/if_arcnet.h
+ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
+M: Arnd Bergmann <arnd@arndb.de>
+M: Olof Johansson <olof@lixom.net>
+M: soc@kernel.org
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
+F: arch/arm/boot/dts/Makefile
+F: arch/arm64/boot/dts/Makefile
+
ARM ARCHITECTED TIMER DRIVER
M: Mark Rutland <mark.rutland@arm.com>
M: Marc Zyngier <maz@kernel.org>
@@ -1525,22 +1535,6 @@ S: Odd Fixes
F: drivers/amba/
F: include/linux/amba/bus.h
-ARM PRIMECELL PL35X NAND CONTROLLER DRIVER
-M: Miquel Raynal <miquel.raynal@bootlin.com>
-M: Naga Sureshkumar Relli <nagasure@xilinx.com>
-L: linux-mtd@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
-F: drivers/mtd/nand/raw/pl35x-nand-controller.c
-
-ARM PRIMECELL PL35X SMC DRIVER
-M: Miquel Raynal <miquel.raynal@bootlin.com>
-M: Naga Sureshkumar Relli <nagasure@xilinx.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
-F: drivers/memory/pl353-smc.c
-
ARM PRIMECELL CLCD PL110 DRIVER
M: Russell King <linux@armlinux.org.uk>
S: Odd Fixes
@@ -1558,6 +1552,22 @@ S: Odd Fixes
F: drivers/mmc/host/mmci.*
F: include/linux/amba/mmci.h
+ARM PRIMECELL PL35X NAND CONTROLLER DRIVER
+M: Miquel Raynal <miquel.raynal@bootlin.com>
+M: Naga Sureshkumar Relli <nagasure@xilinx.com>
+L: linux-mtd@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
+F: drivers/mtd/nand/raw/pl35x-nand-controller.c
+
+ARM PRIMECELL PL35X SMC DRIVER
+M: Miquel Raynal <miquel.raynal@bootlin.com>
+M: Naga Sureshkumar Relli <nagasure@xilinx.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
+F: drivers/memory/pl353-smc.c
+
ARM PRIMECELL SSP PL022 SPI DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -1594,16 +1604,6 @@ F: Documentation/devicetree/bindings/iommu/arm,smmu*
F: drivers/iommu/arm/
F: drivers/iommu/io-pgtable-arm*
-ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
-M: Arnd Bergmann <arnd@arndb.de>
-M: Olof Johansson <olof@lixom.net>
-M: soc@kernel.org
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
-F: arch/arm/boot/dts/Makefile
-F: arch/arm64/boot/dts/Makefile
-
ARM SUB-ARCHITECTURES
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
@@ -2256,13 +2256,6 @@ F: arch/arm64/boot/dts/microchip/
F: drivers/pinctrl/pinctrl-microchip-sgpio.c
N: sparx5
-Microchip Timer Counter Block (TCB) Capture Driver
-M: Kamel Bouhara <kamel.bouhara@bootlin.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: linux-iio@vger.kernel.org
-S: Maintained
-F: drivers/counter/microchip-tcb-capture.c
-
ARM/MIOA701 MACHINE SUPPORT
M: Robert Jarzmik <robert.jarzmik@free.fr>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -4095,29 +4088,6 @@ W: https://github.com/Cascoda/ca8210-linux.git
F: Documentation/devicetree/bindings/net/ieee802154/ca8210.txt
F: drivers/net/ieee802154/ca8210.c
-CANAAN/KENDRYTE K210 SOC FPIOA DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-riscv@lists.infradead.org
-L: linux-gpio@vger.kernel.org (pinctrl driver)
-F: Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
-F: drivers/pinctrl/pinctrl-k210.c
-
-CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-kernel@vger.kernel.org
-L: linux-riscv@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
-F: drivers/reset/reset-k210.c
-
-CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-riscv@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
-F: drivers/soc/canaan/
-F: include/soc/canaan/
-
CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS
M: David Howells <dhowells@redhat.com>
L: linux-cachefs@redhat.com (moderated for non-subscribers)
@@ -4240,6 +4210,29 @@ F: Documentation/networking/j1939.rst
F: include/uapi/linux/can/j1939.h
F: net/can/j1939/
+CANAAN/KENDRYTE K210 SOC FPIOA DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-riscv@lists.infradead.org
+L: linux-gpio@vger.kernel.org (pinctrl driver)
+F: Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
+F: drivers/pinctrl/pinctrl-k210.c
+
+CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-kernel@vger.kernel.org
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
+F: drivers/reset/reset-k210.c
+
+CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
+F: drivers/soc/canaan/
+F: include/soc/canaan/
+
CAPABILITIES
M: Serge Hallyn <serge@hallyn.com>
L: linux-security-module@vger.kernel.org
@@ -4489,17 +4482,17 @@ F: drivers/power/supply/cros_usbpd-charger.c
N: cros_ec
N: cros-ec
-CHROMEOS EC USB TYPE-C DRIVER
-M: Prashant Malani <pmalani@chromium.org>
-S: Maintained
-F: drivers/platform/chrome/cros_ec_typec.c
-
CHROMEOS EC USB PD NOTIFY DRIVER
M: Prashant Malani <pmalani@chromium.org>
S: Maintained
F: drivers/platform/chrome/cros_usbpd_notify.c
F: include/linux/platform_data/cros_usbpd_notify.h
+CHROMEOS EC USB TYPE-C DRIVER
+M: Prashant Malani <pmalani@chromium.org>
+S: Maintained
+F: drivers/platform/chrome/cros_ec_typec.c
+
CHRONTEL CH7322 CEC DRIVER
M: Joe Tessler <jrt@google.com>
L: linux-media@vger.kernel.org
@@ -4604,6 +4597,18 @@ M: Nelson Escobar <neescoba@cisco.com>
S: Supported
F: drivers/infiniband/hw/usnic/
+CLANG CONTROL FLOW INTEGRITY SUPPORT
+M: Sami Tolvanen <samitolvanen@google.com>
+M: Kees Cook <keescook@chromium.org>
+R: Nathan Chancellor <nathan@kernel.org>
+R: Nick Desaulniers <ndesaulniers@google.com>
+L: llvm@lists.linux.dev
+S: Supported
+B: https://github.com/ClangBuiltLinux/linux/issues
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
+F: include/linux/cfi.h
+F: kernel/cfi.c
+
CLANG-FORMAT FILE
M: Miguel Ojeda <ojeda@kernel.org>
S: Maintained
@@ -4623,18 +4628,6 @@ F: scripts/Makefile.clang
F: scripts/clang-tools/
K: \b(?i:clang|llvm)\b
-CLANG CONTROL FLOW INTEGRITY SUPPORT
-M: Sami Tolvanen <samitolvanen@google.com>
-M: Kees Cook <keescook@chromium.org>
-R: Nathan Chancellor <nathan@kernel.org>
-R: Nick Desaulniers <ndesaulniers@google.com>
-L: llvm@lists.linux.dev
-S: Supported
-B: https://github.com/ClangBuiltLinux/linux/issues
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
-F: include/linux/cfi.h
-F: kernel/cfi.c
-
CLEANCACHE API
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
L: linux-kernel@vger.kernel.org
@@ -5117,6 +5110,13 @@ S: Supported
W: http://www.chelsio.com
F: drivers/crypto/chelsio
+CXGB4 ETHERNET DRIVER (CXGB4)
+M: Raju Rangoju <rajur@chelsio.com>
+L: netdev@vger.kernel.org
+S: Supported
+W: http://www.chelsio.com
+F: drivers/net/ethernet/chelsio/cxgb4/
+
CXGB4 INLINE CRYPTO DRIVER
M: Ayush Sawal <ayush.sawal@chelsio.com>
M: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
@@ -5126,13 +5126,6 @@ S: Supported
W: http://www.chelsio.com
F: drivers/net/ethernet/chelsio/inline_crypto/
-CXGB4 ETHERNET DRIVER (CXGB4)
-M: Raju Rangoju <rajur@chelsio.com>
-L: netdev@vger.kernel.org
-S: Supported
-W: http://www.chelsio.com
-F: drivers/net/ethernet/chelsio/cxgb4/
-
CXGB4 ISCSI DRIVER (CXGB4I)
M: Karen Xie <kxie@chelsio.com>
L: linux-scsi@vger.kernel.org
@@ -5188,16 +5181,6 @@ CYCLADES PC300 DRIVER
S: Orphan
F: drivers/net/wan/pc300*
-CYPRESS_FIRMWARE MEDIA DRIVER
-M: Antti Palosaari <crope@iki.fi>
-L: linux-media@vger.kernel.org
-S: Maintained
-W: https://linuxtv.org
-W: http://palosaari.fi/linux/
-Q: http://patchwork.linuxtv.org/project/linux-media/list/
-T: git git://linuxtv.org/anttip/media_tree.git
-F: drivers/media/common/cypress_firmware*
-
CYPRESS CY8CTMA140 TOUCHSCREEN DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-input@vger.kernel.org
@@ -5211,6 +5194,16 @@ S: Maintained
F: Documentation/devicetree/bindings/input/cypress-sf.yaml
F: drivers/input/keyboard/cypress-sf.c
+CYPRESS_FIRMWARE MEDIA DRIVER
+M: Antti Palosaari <crope@iki.fi>
+L: linux-media@vger.kernel.org
+S: Maintained
+W: https://linuxtv.org
+W: http://palosaari.fi/linux/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/anttip/media_tree.git
+F: drivers/media/common/cypress_firmware*
+
CYTTSP TOUCHSCREEN DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-input@vger.kernel.org
@@ -5381,14 +5374,12 @@ L: Dell.Client.Kernel@dell.com
S: Maintained
F: drivers/platform/x86/dell/dell-wmi-descriptor.c
-DELL WMI SYSMAN DRIVER
-M: Divya Bharathi <divya.bharathi@dell.com>
-M: Prasanth Ksr <prasanth.ksr@dell.com>
+DELL WMI HARDWARE PRIVACY SUPPORT
+M: Perry Yuan <Perry.Yuan@dell.com>
L: Dell.Client.Kernel@dell.com
L: platform-driver-x86@vger.kernel.org
S: Maintained
-F: Documentation/ABI/testing/sysfs-class-firmware-attributes
-F: drivers/platform/x86/dell/dell-wmi-sysman/
+F: drivers/platform/x86/dell/dell-wmi-privacy.c
DELL WMI NOTIFICATIONS DRIVER
M: Matthew Garrett <mjg59@srcf.ucam.org>
@@ -5396,12 +5387,21 @@ M: Pali Rohár <pali@kernel.org>
S: Maintained
F: drivers/platform/x86/dell/dell-wmi-base.c
-DELL WMI HARDWARE PRIVACY SUPPORT
-M: Perry Yuan <Perry.Yuan@dell.com>
+DELL WMI SYSMAN DRIVER
+M: Divya Bharathi <divya.bharathi@dell.com>
+M: Prasanth Ksr <prasanth.ksr@dell.com>
L: Dell.Client.Kernel@dell.com
L: platform-driver-x86@vger.kernel.org
S: Maintained
-F: drivers/platform/x86/dell/dell-wmi-privacy.c
+F: Documentation/ABI/testing/sysfs-class-firmware-attributes
+F: drivers/platform/x86/dell/dell-wmi-sysman/
+
+DELTA DPS920AB PSU DRIVER
+M: Robert Marko <robert.marko@sartura.hr>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/dps920ab.rst
+F: drivers/hwmon/pmbus/dps920ab.c
DELTA ST MEDIA DRIVER
M: Hugues Fruchet <hugues.fruchet@foss.st.com>
@@ -5411,13 +5411,6 @@ W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/platform/sti/delta
-DELTA DPS920AB PSU DRIVER
-M: Robert Marko <robert.marko@sartura.hr>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/hwmon/dps920ab.rst
-F: drivers/hwmon/pmbus/dps920ab.c
-
DENALI NAND DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -5430,13 +5423,6 @@ S: Maintained
F: drivers/dma/dw-edma/
F: include/linux/dma/edma.h
-DESIGNWARE XDATA IP DRIVER
-M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
-L: linux-pci@vger.kernel.org
-S: Maintained
-F: Documentation/misc-devices/dw-xdata-pcie.rst
-F: drivers/misc/dw-xdata-pcie.c
-
DESIGNWARE USB2 DRD IP DRIVER
M: Minas Harutyunyan <hminas@synopsys.com>
L: linux-usb@vger.kernel.org
@@ -5451,6 +5437,13 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
F: drivers/usb/dwc3/
+DESIGNWARE XDATA IP DRIVER
+M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+L: linux-pci@vger.kernel.org
+S: Maintained
+F: Documentation/misc-devices/dw-xdata-pcie.rst
+F: drivers/misc/dw-xdata-pcie.c
+
DEVANTECH SRF ULTRASONIC RANGER IIO DRIVER
M: Andreas Klinger <ak@it-klinger.de>
L: linux-iio@vger.kernel.org
@@ -5680,6 +5673,12 @@ F: include/linux/dma/
F: include/linux/dmaengine.h
F: include/linux/of_dma.h
+DMA MAPPING BENCHMARK
+M: Barry Song <song.bao.hua@hisilicon.com>
+L: iommu@lists.linux-foundation.org
+F: kernel/dma/map_benchmark.c
+F: tools/testing/selftests/dma/
+
DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
@@ -5694,12 +5693,6 @@ F: include/linux/dma-mapping.h
F: include/linux/dma-map-ops.h
F: kernel/dma/
-DMA MAPPING BENCHMARK
-M: Barry Song <song.bao.hua@hisilicon.com>
-L: iommu@lists.linux-foundation.org
-F: kernel/dma/map_benchmark.c
-F: tools/testing/selftests/dma/
-
DMA-BUF HEAPS FRAMEWORK
M: Sumit Semwal <sumit.semwal@linaro.org>
R: Benjamin Gaignard <benjamin.gaignard@linaro.org>
@@ -5981,6 +5974,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
F: drivers/gpu/drm/tiny/hx8357d.c
+DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
+M: Deepak Rawat <drawat.floss@gmail.com>
+L: linux-hyperv@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/hyperv
+
DRM DRIVER FOR ILITEK ILI9225 PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
@@ -6126,14 +6127,6 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml
F: drivers/gpu/drm/panel/panel-samsung-s6d27a1.c
-DRM DRIVER FOR SITRONIX ST7703 PANELS
-M: Guido Günther <agx@sigxcpu.org>
-R: Purism Kernel Team <kernel@puri.sm>
-R: Ondrej Jirman <megous@megous.com>
-S: Maintained
-F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
-F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
-
DRM DRIVER FOR SAVAGE VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/savage/
@@ -6164,6 +6157,14 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
F: drivers/gpu/drm/panel/panel-sitronix-st7701.c
+DRM DRIVER FOR SITRONIX ST7703 PANELS
+M: Guido Günther <agx@sigxcpu.org>
+R: Purism Kernel Team <kernel@puri.sm>
+R: Ondrej Jirman <megous@megous.com>
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
+
DRM DRIVER FOR SITRONIX ST7735R PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
@@ -6358,14 +6359,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/hisilicon/
F: drivers/gpu/drm/hisilicon/
-DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
-M: Deepak Rawat <drawat.floss@gmail.com>
-L: linux-hyperv@vger.kernel.org
-L: dri-devel@lists.freedesktop.org
-S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
-F: drivers/gpu/drm/hyperv
-
DRM DRIVERS FOR LIMA
M: Qiang Yu <yuq825@gmail.com>
L: dri-devel@lists.freedesktop.org
@@ -6513,6 +6506,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/xlnx/
F: drivers/gpu/drm/xlnx/
+DRM GPU SCHEDULER
+M: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/scheduler/
+F: include/drm/gpu_scheduler.h
+
DRM PANEL DRIVERS
M: Thierry Reding <thierry.reding@gmail.com>
R: Sam Ravnborg <sam@ravnborg.org>
@@ -6533,14 +6534,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/gpu/drm/ttm/
F: include/drm/ttm/
-DRM GPU SCHEDULER
-M: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
-L: dri-devel@lists.freedesktop.org
-S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
-F: drivers/gpu/drm/scheduler/
-F: include/drm/gpu_scheduler.h
-
DSBR100 USB FM RADIO DRIVER
M: Alexey Klimov <klimov.linux@gmail.com>
L: linux-media@vger.kernel.org
@@ -6679,6 +6672,15 @@ F: Documentation/networking/net_dim.rst
F: include/linux/dim.h
F: lib/dim/
+DYNAMIC THERMAL POWER MANAGEMENT (DTPM)
+M: Daniel Lezcano <daniel.lezcano@kernel.org>
+L: linux-pm@vger.kernel.org
+S: Supported
+B: https://bugzilla.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
+F: drivers/powercap/dtpm*
+F: include/linux/dtpm.h
+
DZ DECSTATION DZ11 SERIAL DRIVER
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
S: Maintained
@@ -7026,22 +7028,22 @@ W: http://www.broadcom.com
F: drivers/infiniband/hw/ocrdma/
F: include/uapi/rdma/ocrdma-abi.h
-EMULEX/BROADCOM LPFC FC/FCOE SCSI DRIVER
+EMULEX/BROADCOM EFCT FC/FCOE SCSI TARGET DRIVER
M: James Smart <james.smart@broadcom.com>
-M: Dick Kennedy <dick.kennedy@broadcom.com>
+M: Ram Vegesna <ram.vegesna@broadcom.com>
L: linux-scsi@vger.kernel.org
+L: target-devel@vger.kernel.org
S: Supported
W: http://www.broadcom.com
-F: drivers/scsi/lpfc/
+F: drivers/scsi/elx/
-EMULEX/BROADCOM EFCT FC/FCOE SCSI TARGET DRIVER
+EMULEX/BROADCOM LPFC FC/FCOE SCSI DRIVER
M: James Smart <james.smart@broadcom.com>
-M: Ram Vegesna <ram.vegesna@broadcom.com>
+M: Dick Kennedy <dick.kennedy@broadcom.com>
L: linux-scsi@vger.kernel.org
-L: target-devel@vger.kernel.org
S: Supported
W: http://www.broadcom.com
-F: drivers/scsi/elx/
+F: drivers/scsi/lpfc/
ENE CB710 FLASH CARD READER DRIVER
M: Michał Mirosław <mirq-linux@rere.qmqm.pl>
@@ -8518,6 +8520,12 @@ W: http://www.highpoint-tech.com
F: Documentation/scsi/hptiop.rst
F: drivers/scsi/hptiop.c
+HIKEY960 ONBOARD USB GPIO HUB DRIVER
+M: John Stultz <john.stultz@linaro.org>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/misc/hisi_hikey_usb.c
+
HIPPI
M: Jes Sorensen <jes@trained-monkey.org>
L: linux-hippi@sunsite.dk
@@ -8588,12 +8596,6 @@ W: http://www.hisilicon.com
F: Documentation/devicetree/bindings/net/hisilicon*.txt
F: drivers/net/ethernet/hisilicon/
-HIKEY960 ONBOARD USB GPIO HUB DRIVER
-M: John Stultz <john.stultz@linaro.org>
-L: linux-kernel@vger.kernel.org
-S: Maintained
-F: drivers/misc/hisi_hikey_usb.c
-
HISILICON PMU DRIVER
M: Shaokun Zhang <zhangshaokun@hisilicon.com>
S: Supported
@@ -9619,18 +9621,18 @@ F: Documentation/admin-guide/media/ipu3_rcb.svg
F: Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst
F: drivers/staging/media/ipu3/
-INTEL IXP4XX CRYPTO SUPPORT
-M: Corentin Labbe <clabbe@baylibre.com>
-L: linux-crypto@vger.kernel.org
-S: Maintained
-F: drivers/crypto/ixp4xx_crypto.c
-
INTEL ISHTP ECLITE DRIVER
M: Sumesh K Naduvalath <sumesh.k.naduvalath@intel.com>
L: platform-driver-x86@vger.kernel.org
S: Supported
F: drivers/platform/x86/intel/ishtp_eclite.c
+INTEL IXP4XX CRYPTO SUPPORT
+M: Corentin Labbe <clabbe@baylibre.com>
+L: linux-crypto@vger.kernel.org
+S: Maintained
+F: drivers/crypto/ixp4xx_crypto.c
+
INTEL IXP4XX QMGR, NPE, ETHERNET and HSS SUPPORT
M: Krzysztof Halasa <khalasa@piap.pl>
S: Maintained
@@ -9773,6 +9775,21 @@ S: Maintained
F: arch/x86/include/asm/intel_scu_ipc.h
F: drivers/platform/x86/intel_scu_*
+INTEL SGX
+M: Jarkko Sakkinen <jarkko@kernel.org>
+R: Dave Hansen <dave.hansen@linux.intel.com>
+L: linux-sgx@vger.kernel.org
+S: Supported
+Q: https://patchwork.kernel.org/project/intel-sgx/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/sgx
+F: Documentation/x86/sgx.rst
+F: arch/x86/entry/vdso/vsgx.S
+F: arch/x86/include/asm/sgx.h
+F: arch/x86/include/uapi/asm/sgx.h
+F: arch/x86/kernel/cpu/sgx/*
+F: tools/testing/selftests/sgx/*
+K: \bSGX_
+
INTEL SKYLAKE INT3472 ACPI DEVICE DRIVER
M: Daniel Scally <djrscally@gmail.com>
S: Maintained
@@ -9867,21 +9884,6 @@ F: Documentation/x86/intel_txt.rst
F: arch/x86/kernel/tboot.c
F: include/linux/tboot.h
-INTEL SGX
-M: Jarkko Sakkinen <jarkko@kernel.org>
-R: Dave Hansen <dave.hansen@linux.intel.com>
-L: linux-sgx@vger.kernel.org
-S: Supported
-Q: https://patchwork.kernel.org/project/intel-sgx/list/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/sgx
-F: Documentation/x86/sgx.rst
-F: arch/x86/entry/vdso/vsgx.S
-F: arch/x86/include/asm/sgx.h
-F: arch/x86/include/uapi/asm/sgx.h
-F: arch/x86/kernel/cpu/sgx/*
-F: tools/testing/selftests/sgx/*
-K: \bSGX_
-
INTERCONNECT API
M: Georgi Djakov <djakov@kernel.org>
L: linux-pm@vger.kernel.org
@@ -11287,6 +11289,12 @@ F: drivers/mailbox/arm_mhuv2.c
F: include/linux/mailbox/arm_mhuv2_message.h
F: Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
+MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
+M: Michael Kerrisk <mtk.manpages@gmail.com>
+L: linux-man@vger.kernel.org
+S: Maintained
+W: http://www.kernel.org/doc/man-pages
+
MANAGEMENT COMPONENT TRANSPORT PROTOCOL (MCTP)
M: Jeremy Kerr <jk@codeconstruct.com.au>
M: Matt Johnston <matt@codeconstruct.com.au>
@@ -11299,12 +11307,6 @@ F: include/net/mctpdevice.h
F: include/net/netns/mctp.h
F: net/mctp/
-MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
-M: Michael Kerrisk <mtk.manpages@gmail.com>
-L: linux-man@vger.kernel.org
-S: Maintained
-W: http://www.kernel.org/doc/man-pages
-
MARDUK (CREATOR CI40) DEVICE TREE SUPPORT
M: Rahul Bedarkar <rahulbedarkar89@gmail.com>
L: linux-mips@vger.kernel.org
@@ -11623,12 +11625,6 @@ L: netdev@vger.kernel.org
S: Supported
F: drivers/net/phy/mxl-gpy.c
-MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
-R: Yasushi SHOJI <yashi@spacecubics.com>
-L: linux-can@vger.kernel.org
-S: Maintained
-F: drivers/net/can/usb/mcba_usb.c
-
MCAN MMIO DEVICE DRIVER
M: Chandrasekar Ramakrishnan <rcsekar@samsung.com>
L: linux-can@vger.kernel.org
@@ -11638,6 +11634,12 @@ F: drivers/net/can/m_can/m_can.c
F: drivers/net/can/m_can/m_can.h
F: drivers/net/can/m_can/m_can_platform.c
+MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
+R: Yasushi SHOJI <yashi@spacecubics.com>
+L: linux-can@vger.kernel.org
+S: Maintained
+F: drivers/net/can/usb/mcba_usb.c
+
MCP2221A MICROCHIP USB-HID TO I2C BRIDGE DRIVER
M: Rishi Gupta <gupt21@gmail.com>
L: linux-i2c@vger.kernel.org
@@ -12030,13 +12032,6 @@ S: Maintained
F: Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
F: drivers/clk/ralink/clk-mt7621.c
-MEDIATEK MT7621/28/88 I2C DRIVER
-M: Stefan Roese <sr@denx.de>
-L: linux-i2c@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
-F: drivers/i2c/busses/i2c-mt7621.c
-
MEDIATEK MT7621 PCIE CONTROLLER DRIVER
M: Sergio Paracuellos <sergio.paracuellos@gmail.com>
S: Maintained
@@ -12049,6 +12044,13 @@ S: Maintained
F: Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
F: drivers/phy/ralink/phy-mt7621-pci.c
+MEDIATEK MT7621/28/88 I2C DRIVER
+M: Stefan Roese <sr@denx.de>
+L: linux-i2c@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
+F: drivers/i2c/busses/i2c-mt7621.c
+
MEDIATEK NAND CONTROLLER DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -12580,6 +12582,13 @@ S: Supported
F: drivers/misc/atmel-ssc.c
F: include/linux/atmel-ssc.h
+Microchip Timer Counter Block (TCB) Capture Driver
+M: Kamel Bouhara <kamel.bouhara@bootlin.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: drivers/counter/microchip-tcb-capture.c
+
MICROCHIP USB251XB DRIVER
M: Richard Leitner <richard.leitner@skidata.com>
L: linux-usb@vger.kernel.org
@@ -13680,13 +13689,6 @@ F: drivers/iio/gyro/fxas21002c_core.c
F: drivers/iio/gyro/fxas21002c_i2c.c
F: drivers/iio/gyro/fxas21002c_spi.c
-NXP i.MX CLOCK DRIVERS
-M: Abel Vesa <abel.vesa@nxp.com>
-L: linux-clk@vger.kernel.org
-L: linux-imx@nxp.com
-S: Maintained
-F: drivers/clk/imx/
-
NXP i.MX 8MQ DCSS DRIVER
M: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
R: Lucas Stach <l.stach@pengutronix.de>
@@ -13702,6 +13704,21 @@ S: Supported
F: Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
F: drivers/iio/adc/imx8qxp-adc.c
+NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
+M: Mirela Rabulea <mirela.rabulea@nxp.com>
+R: NXP Linux Team <linux-imx@nxp.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
+F: drivers/media/platform/imx-jpeg
+
+NXP i.MX CLOCK DRIVERS
+M: Abel Vesa <abel.vesa@nxp.com>
+L: linux-clk@vger.kernel.org
+L: linux-imx@nxp.com
+S: Maintained
+F: drivers/clk/imx/
+
NXP PF8100/PF8121A/PF8200 PMIC REGULATOR DEVICE DRIVER
M: Jagan Teki <jagan@amarulasolutions.com>
S: Maintained
@@ -13739,19 +13756,12 @@ F: include/drm/i2c/tda998x.h
F: include/dt-bindings/display/tda998x.h
K: "nxp,tda998x"
-NXP TFA9879 DRIVER
-M: Peter Rosin <peda@axentia.se>
-L: alsa-devel@alsa-project.org (moderated for non-subscribers)
-S: Maintained
-F: Documentation/devicetree/bindings/sound/tfa9879.txt
-F: sound/soc/codecs/tfa9879*
-
-NXP/Goodix TFA989X (TFA1) DRIVER
-M: Stephan Gerhold <stephan@gerhold.net>
+NXP TFA9879 DRIVER
+M: Peter Rosin <peda@axentia.se>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
-F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
-F: sound/soc/codecs/tfa989x.c
+F: Documentation/devicetree/bindings/sound/tfa9879.txt
+F: sound/soc/codecs/tfa9879*
NXP-NCI NFC DRIVER
R: Charles Gorand <charles.gorand@effinnov.com>
@@ -13760,13 +13770,12 @@ S: Supported
F: Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml
F: drivers/nfc/nxp-nci
-NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
-M: Mirela Rabulea <mirela.rabulea@nxp.com>
-R: NXP Linux Team <linux-imx@nxp.com>
-L: linux-media@vger.kernel.org
+NXP/Goodix TFA989X (TFA1) DRIVER
+M: Stephan Gerhold <stephan@gerhold.net>
+L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
-F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
-F: drivers/media/platform/imx-jpeg
+F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
+F: sound/soc/codecs/tfa989x.c
NZXT-KRAKEN2 HARDWARE MONITORING DRIVER
M: Jonas Malaco <jonas@protocubo.io>
@@ -14556,6 +14565,14 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/pci/controller/dwc/*layerscape*
+PCI DRIVER FOR FU740
+M: Paul Walmsley <paul.walmsley@sifive.com>
+M: Greentime Hu <greentime.hu@sifive.com>
+L: linux-pci@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
+F: drivers/pci/controller/dwc/pcie-fu740.c
+
PCI DRIVER FOR GENERIC OF HOSTS
M: Will Deacon <will@kernel.org>
L: linux-pci@vger.kernel.org
@@ -14574,14 +14591,6 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
F: drivers/pci/controller/dwc/*imx6*
-PCI DRIVER FOR FU740
-M: Paul Walmsley <paul.walmsley@sifive.com>
-M: Greentime Hu <greentime.hu@sifive.com>
-L: linux-pci@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
-F: drivers/pci/controller/dwc/pcie-fu740.c
-
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
@@ -14854,14 +14863,6 @@ L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/pci/controller/dwc/pcie-qcom.c
-PCIE ENDPOINT DRIVER FOR QUALCOMM
-M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-L: linux-pci@vger.kernel.org
-L: linux-arm-msm@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
-F: drivers/pci/controller/dwc/pcie-qcom-ep.c
-
PCIE DRIVER FOR ROCKCHIP
M: Shawn Lin <shawn.lin@rock-chips.com>
L: linux-pci@vger.kernel.org
@@ -14883,6 +14884,14 @@ L: linux-pci@vger.kernel.org
S: Maintained
F: drivers/pci/controller/dwc/*spear*
+PCIE ENDPOINT DRIVER FOR QUALCOMM
+M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+L: linux-pci@vger.kernel.org
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
+F: drivers/pci/controller/dwc/pcie-qcom-ep.c
+
PCMCIA SUBSYSTEM
M: Dominik Brodowski <linux@dominikbrodowski.net>
S: Odd Fixes
@@ -15142,13 +15151,6 @@ M: Logan Gunthorpe <logang@deltatee.com>
S: Maintained
F: drivers/dma/plx_dma.c
-PM6764TR DRIVER
-M: Charles Hsu <hsu.yungteng@gmail.com>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/hwmon/pm6764tr.rst
-F: drivers/hwmon/pmbus/pm6764tr.c
-
PM-GRAPH UTILITY
M: "Todd E Brandt" <todd.e.brandt@linux.intel.com>
L: linux-pm@vger.kernel.org
@@ -15158,6 +15160,13 @@ B: https://bugzilla.kernel.org/buglist.cgi?component=pm-graph&product=Tools
T: git git://github.com/intel/pm-graph
F: tools/power/pm-graph
+PM6764TR DRIVER
+M: Charles Hsu <hsu.yungteng@gmail.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/pm6764tr.rst
+F: drivers/hwmon/pmbus/pm6764tr.c
+
PMBUS HARDWARE MONITORING DRIVERS
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
@@ -15238,15 +15247,6 @@ F: include/linux/pm_*
F: include/linux/powercap.h
F: kernel/configs/nopm.config
-DYNAMIC THERMAL POWER MANAGEMENT (DTPM)
-M: Daniel Lezcano <daniel.lezcano@kernel.org>
-L: linux-pm@vger.kernel.org
-S: Supported
-B: https://bugzilla.kernel.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
-F: drivers/powercap/dtpm*
-F: include/linux/dtpm.h
-
POWER STATE COORDINATION INTERFACE (PSCI)
M: Mark Rutland <mark.rutland@arm.com>
M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
@@ -16261,12 +16261,6 @@ S: Supported
F: Documentation/devicetree/bindings/i2c/renesas,riic.yaml
F: drivers/i2c/busses/i2c-riic.c
-RENESAS USB PHY DRIVER
-M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
-L: linux-renesas-soc@vger.kernel.org
-S: Maintained
-F: drivers/phy/renesas/phy-rcar-gen3-usb*.c
-
RENESAS RZ/G2L A/D DRIVER
M: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
L: linux-iio@vger.kernel.org
@@ -16275,6 +16269,12 @@ S: Supported
F: Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
F: drivers/iio/adc/rzg2l_adc.c
+RENESAS USB PHY DRIVER
+M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+L: linux-renesas-soc@vger.kernel.org
+S: Maintained
+F: drivers/phy/renesas/phy-rcar-gen3-usb*.c
+
RESET CONTROLLER FRAMEWORK
M: Philipp Zabel <p.zabel@pengutronix.de>
S: Maintained
@@ -17105,6 +17105,15 @@ F: block/sed*
F: include/linux/sed*
F: include/uapi/linux/sed*
+SECURE MONITOR CALL(SMC) CALLING CONVENTION (SMCCC)
+M: Mark Rutland <mark.rutland@arm.com>
+M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+M: Sudeep Holla <sudeep.holla@arm.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/firmware/smccc/
+F: include/linux/arm-smccc.h
+
SECURITY CONTACT
M: Security Officers <security@kernel.org>
S: Supported
@@ -17512,15 +17521,6 @@ M: Nicolas Pitre <nico@fluxnic.net>
S: Odd Fixes
F: drivers/net/ethernet/smsc/smc91x.*
-SECURE MONITOR CALL(SMC) CALLING CONVENTION (SMCCC)
-M: Mark Rutland <mark.rutland@arm.com>
-M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-M: Sudeep Holla <sudeep.holla@arm.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: drivers/firmware/smccc/
-F: include/linux/arm-smccc.h
-
SMM665 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
@@ -18701,6 +18701,14 @@ M: Thierry Reding <thierry.reding@gmail.com>
S: Supported
F: drivers/pwm/pwm-tegra.c
+TEGRA QUAD SPI DRIVER
+M: Thierry Reding <thierry.reding@gmail.com>
+M: Jonathan Hunter <jonathanh@nvidia.com>
+M: Sowjanya Komatineni <skomatineni@nvidia.com>
+L: linux-tegra@vger.kernel.org
+S: Maintained
+F: drivers/spi/spi-tegra210-quad.c
+
TEGRA SERIAL DRIVER
M: Laxman Dewangan <ldewangan@nvidia.com>
S: Supported
@@ -18711,14 +18719,6 @@ M: Laxman Dewangan <ldewangan@nvidia.com>
S: Supported
F: drivers/spi/spi-tegra*
-TEGRA QUAD SPI DRIVER
-M: Thierry Reding <thierry.reding@gmail.com>
-M: Jonathan Hunter <jonathanh@nvidia.com>
-M: Sowjanya Komatineni <skomatineni@nvidia.com>
-L: linux-tegra@vger.kernel.org
-S: Maintained
-F: drivers/spi/spi-tegra210-quad.c
-
TEGRA VIDEO DRIVER
M: Thierry Reding <thierry.reding@gmail.com>
M: Jonathan Hunter <jonathanh@nvidia.com>
@@ -18767,13 +18767,6 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: sound/soc/ti/
-TEXAS INSTRUMENTS' DAC7612 DAC DRIVER
-M: Ricardo Ribalda <ribalda@kernel.org>
-L: linux-iio@vger.kernel.org
-S: Supported
-F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
-F: drivers/iio/dac/ti-dac7612.c
-
TEXAS INSTRUMENTS DMA DRIVERS
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: dmaengine@vger.kernel.org
@@ -18787,6 +18780,22 @@ F: include/linux/dma/k3-udma-glue.h
F: include/linux/dma/ti-cppi5.h
F: include/linux/dma/k3-psil.h
+TEXAS INSTRUMENTS TPS23861 PoE PSE DRIVER
+M: Robert Marko <robert.marko@sartura.hr>
+M: Luka Perkov <luka.perkov@sartura.hr>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
+F: Documentation/hwmon/tps23861.rst
+F: drivers/hwmon/tps23861.c
+
+TEXAS INSTRUMENTS' DAC7612 DAC DRIVER
+M: Ricardo Ribalda <ribalda@kernel.org>
+L: linux-iio@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
+F: drivers/iio/dac/ti-dac7612.c
+
TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER
M: Nishanth Menon <nm@ti.com>
M: Tero Kristo <kristo@kernel.org>
@@ -18811,15 +18820,6 @@ F: include/dt-bindings/soc/ti,sci_pm_domain.h
F: include/linux/soc/ti/ti_sci_inta_msi.h
F: include/linux/soc/ti/ti_sci_protocol.h
-TEXAS INSTRUMENTS TPS23861 PoE PSE DRIVER
-M: Robert Marko <robert.marko@sartura.hr>
-M: Luka Perkov <luka.perkov@sartura.hr>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
-F: Documentation/hwmon/tps23861.rst
-F: drivers/hwmon/tps23861.c
-
TEXAS INSTRUMENTS' TMP117 TEMPERATURE SENSOR DRIVER
M: Puranjay Mohan <puranjay12@gmail.com>
L: linux-iio@vger.kernel.org
@@ -19719,6 +19719,13 @@ L: linux-usb@vger.kernel.org
S: Supported
F: drivers/usb/class/usblp.c
+USB QMI WWAN NETWORK DRIVER
+M: Bjørn Mork <bjorn@mork.no>
+L: netdev@vger.kernel.org
+S: Maintained
+F: Documentation/ABI/testing/sysfs-class-net-qmi
+F: drivers/net/usb/qmi_wwan.c
+
USB RAW GADGET DRIVER
R: Andrey Konovalov <andreyknvl@gmail.com>
L: linux-usb@vger.kernel.org
@@ -19727,13 +19734,6 @@ F: Documentation/usb/raw-gadget.rst
F: drivers/usb/gadget/legacy/raw_gadget.c
F: include/uapi/linux/usb/raw_gadget.h
-USB QMI WWAN NETWORK DRIVER
-M: Bjørn Mork <bjorn@mork.no>
-L: netdev@vger.kernel.org
-S: Maintained
-F: Documentation/ABI/testing/sysfs-class-net-qmi
-F: drivers/net/usb/qmi_wwan.c
-
USB RTL8150 DRIVER
M: Petko Manolov <petkan@nucleusys.com>
L: linux-usb@vger.kernel.org
@@ -20049,6 +20049,14 @@ S: Maintained
F: drivers/media/common/videobuf2/*
F: include/media/videobuf2-*
+VIDTV VIRTUAL DIGITAL TV DRIVER
+M: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+W: https://linuxtv.org
+T: git git://linuxtv.org/media_tree.git
+F: drivers/media/test-drivers/vidtv/*
+
VIMC VIRTUAL MEDIA CONTROLLER DRIVER
M: Helen Koike <helen.koike@collabora.com>
R: Shuah Khan <skhan@linuxfoundation.org>
@@ -20078,6 +20086,16 @@ F: include/uapi/linux/virtio_vsock.h
F: net/vmw_vsock/virtio_transport.c
F: net/vmw_vsock/virtio_transport_common.c
+VIRTIO BALLOON
+M: "Michael S. Tsirkin" <mst@redhat.com>
+M: David Hildenbrand <david@redhat.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/virtio/virtio_balloon.c
+F: include/uapi/linux/virtio_balloon.h
+F: include/linux/balloon_compaction.h
+F: mm/balloon_compaction.c
+
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
@@ -20115,16 +20133,6 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: tools/virtio/
-VIRTIO BALLOON
-M: "Michael S. Tsirkin" <mst@redhat.com>
-M: David Hildenbrand <david@redhat.com>
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/virtio/virtio_balloon.c
-F: include/uapi/linux/virtio_balloon.h
-F: include/linux/balloon_compaction.h
-F: mm/balloon_compaction.c
-
VIRTIO CRYPTO DRIVER
M: Gonglei <arei.gonglei@huawei.com>
L: virtualization@lists.linux-foundation.org
@@ -20186,6 +20194,15 @@ F: drivers/vhost/
F: include/linux/vhost_iotlb.h
F: include/uapi/linux/vhost.h
+VIRTIO I2C DRIVER
+M: Conghui Chen <conghui.chen@intel.com>
+M: Viresh Kumar <viresh.kumar@linaro.org>
+L: linux-i2c@vger.kernel.org
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/i2c/busses/i2c-virtio.c
+F: include/uapi/linux/virtio_i2c.h
+
VIRTIO INPUT DRIVER
M: Gerd Hoffmann <kraxel@redhat.com>
S: Maintained
@@ -20207,6 +20224,13 @@ W: https://virtio-mem.gitlab.io/
F: drivers/virtio/virtio_mem.c
F: include/uapi/linux/virtio_mem.h
+VIRTIO PMEM DRIVER
+M: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/nvdimm/virtio_pmem.c
+F: drivers/nvdimm/nd_virtio.c
+
VIRTIO SOUND DRIVER
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
M: "Michael S. Tsirkin" <mst@redhat.com>
@@ -20216,22 +20240,6 @@ S: Maintained
F: include/uapi/linux/virtio_snd.h
F: sound/virtio/*
-VIRTIO I2C DRIVER
-M: Conghui Chen <conghui.chen@intel.com>
-M: Viresh Kumar <viresh.kumar@linaro.org>
-L: linux-i2c@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/i2c/busses/i2c-virtio.c
-F: include/uapi/linux/virtio_i2c.h
-
-VIRTIO PMEM DRIVER
-M: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/nvdimm/virtio_pmem.c
-F: drivers/nvdimm/nd_virtio.c
-
VIRTUAL BOX GUEST DEVICE DRIVER
M: Hans de Goede <hdegoede@redhat.com>
M: Arnd Bergmann <arnd@arndb.de>
@@ -20261,14 +20269,6 @@ W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/test-drivers/vivid/*
-VIDTV VIRTUAL DIGITAL TV DRIVER
-M: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
-L: linux-media@vger.kernel.org
-S: Maintained
-W: https://linuxtv.org
-T: git git://linuxtv.org/media_tree.git
-F: drivers/media/test-drivers/vidtv/*
-
VLYNQ BUS
M: Florian Fainelli <f.fainelli@gmail.com>
L: openwrt-devel@lists.openwrt.org (subscribers-only)
@@ -20276,18 +20276,6 @@ S: Maintained
F: drivers/vlynq/vlynq.c
F: include/linux/vlynq.h
-VME SUBSYSTEM
-M: Martyn Welch <martyn@welchs.me.uk>
-M: Manohar Vanga <manohar.vanga@gmail.com>
-M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-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/vme/
-F: include/linux/vme*
-
VM SOCKETS (AF_VSOCK)
M: Stefano Garzarella <sgarzare@redhat.com>
L: virtualization@lists.linux-foundation.org
@@ -20301,6 +20289,18 @@ F: include/uapi/linux/vsockmon.h
F: net/vmw_vsock/
F: tools/testing/vsock/
+VME SUBSYSTEM
+M: Martyn Welch <martyn@welchs.me.uk>
+M: Manohar Vanga <manohar.vanga@gmail.com>
+M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+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/vme/
+F: include/linux/vme*
+
VMWARE BALLOON DRIVER
M: Nadav Amit <namit@vmware.com>
M: "VMware, Inc." <pv-drivers@vmware.com>
--
2.33.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [relevance 13%]
* [PATCH v1 1/1] MAINTAINERS: Sort sections with parse-maintainers.pl help
@ 2021-11-17 19:05 13% ` Andy Shevchenko
0 siblings, 0 replies; 200+ results
From: Andy Shevchenko @ 2021-11-17 19:05 UTC (permalink / raw)
To: linux-kernel, linux-riscv, llvm
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Nathan Chancellor,
Nick Desaulniers, Joe Perches, Linus Torvalds, Andy Shevchenko
Sort sections with parse-maintainers.pl help since quite a few
got unsorted from the previous run.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
MAINTAINERS | 710 ++++++++++++++++++++++++++--------------------------
1 file changed, 355 insertions(+), 355 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2345ce8521..1154c83ee3c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -967,11 +967,6 @@ F: drivers/gpu/drm/amd/include/v9_structs.h
F: drivers/gpu/drm/amd/include/vi_structs.h
F: include/uapi/linux/kfd_ioctl.h
-AMD SPI DRIVER
-M: Sanjay R Mehta <sanju.mehta@amd.com>
-S: Maintained
-F: drivers/spi/spi-amd.c
-
AMD MP2 I2C DRIVER
M: Elie Morisse <syniurge@gmail.com>
M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
@@ -1006,13 +1001,6 @@ M: Tom Lendacky <thomas.lendacky@amd.com>
S: Supported
F: arch/arm64/boot/dts/amd/
-AMD XGBE DRIVER
-M: Tom Lendacky <thomas.lendacky@amd.com>
-L: netdev@vger.kernel.org
-S: Supported
-F: arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
-F: drivers/net/ethernet/amd/xgbe/
-
AMD SENSOR FUSION HUB DRIVER
M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
M: Basavaraj Natikar <basavaraj.natikar@amd.com>
@@ -1021,6 +1009,18 @@ S: Maintained
F: Documentation/hid/amd-sfh*
F: drivers/hid/amd-sfh-hid/
+AMD SPI DRIVER
+M: Sanjay R Mehta <sanju.mehta@amd.com>
+S: Maintained
+F: drivers/spi/spi-amd.c
+
+AMD XGBE DRIVER
+M: Tom Lendacky <thomas.lendacky@amd.com>
+L: netdev@vger.kernel.org
+S: Supported
+F: arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
+F: drivers/net/ethernet/amd/xgbe/
+
AMS AS73211 DRIVER
M: Christian Eggers <ceggers@arri.de>
L: linux-iio@vger.kernel.org
@@ -1409,6 +1409,16 @@ S: Maintained
F: drivers/net/arcnet/
F: include/uapi/linux/if_arcnet.h
+ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
+M: Arnd Bergmann <arnd@arndb.de>
+M: Olof Johansson <olof@lixom.net>
+M: soc@kernel.org
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
+F: arch/arm/boot/dts/Makefile
+F: arch/arm64/boot/dts/Makefile
+
ARM ARCHITECTED TIMER DRIVER
M: Mark Rutland <mark.rutland@arm.com>
M: Marc Zyngier <maz@kernel.org>
@@ -1525,22 +1535,6 @@ S: Odd Fixes
F: drivers/amba/
F: include/linux/amba/bus.h
-ARM PRIMECELL PL35X NAND CONTROLLER DRIVER
-M: Miquel Raynal <miquel.raynal@bootlin.com>
-M: Naga Sureshkumar Relli <nagasure@xilinx.com>
-L: linux-mtd@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
-F: drivers/mtd/nand/raw/pl35x-nand-controller.c
-
-ARM PRIMECELL PL35X SMC DRIVER
-M: Miquel Raynal <miquel.raynal@bootlin.com>
-M: Naga Sureshkumar Relli <nagasure@xilinx.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
-F: drivers/memory/pl353-smc.c
-
ARM PRIMECELL CLCD PL110 DRIVER
M: Russell King <linux@armlinux.org.uk>
S: Odd Fixes
@@ -1558,6 +1552,22 @@ S: Odd Fixes
F: drivers/mmc/host/mmci.*
F: include/linux/amba/mmci.h
+ARM PRIMECELL PL35X NAND CONTROLLER DRIVER
+M: Miquel Raynal <miquel.raynal@bootlin.com>
+M: Naga Sureshkumar Relli <nagasure@xilinx.com>
+L: linux-mtd@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
+F: drivers/mtd/nand/raw/pl35x-nand-controller.c
+
+ARM PRIMECELL PL35X SMC DRIVER
+M: Miquel Raynal <miquel.raynal@bootlin.com>
+M: Naga Sureshkumar Relli <nagasure@xilinx.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
+F: drivers/memory/pl353-smc.c
+
ARM PRIMECELL SSP PL022 SPI DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -1594,16 +1604,6 @@ F: Documentation/devicetree/bindings/iommu/arm,smmu*
F: drivers/iommu/arm/
F: drivers/iommu/io-pgtable-arm*
-ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
-M: Arnd Bergmann <arnd@arndb.de>
-M: Olof Johansson <olof@lixom.net>
-M: soc@kernel.org
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
-F: arch/arm/boot/dts/Makefile
-F: arch/arm64/boot/dts/Makefile
-
ARM SUB-ARCHITECTURES
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
@@ -2256,13 +2256,6 @@ F: arch/arm64/boot/dts/microchip/
F: drivers/pinctrl/pinctrl-microchip-sgpio.c
N: sparx5
-Microchip Timer Counter Block (TCB) Capture Driver
-M: Kamel Bouhara <kamel.bouhara@bootlin.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: linux-iio@vger.kernel.org
-S: Maintained
-F: drivers/counter/microchip-tcb-capture.c
-
ARM/MIOA701 MACHINE SUPPORT
M: Robert Jarzmik <robert.jarzmik@free.fr>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -4095,29 +4088,6 @@ W: https://github.com/Cascoda/ca8210-linux.git
F: Documentation/devicetree/bindings/net/ieee802154/ca8210.txt
F: drivers/net/ieee802154/ca8210.c
-CANAAN/KENDRYTE K210 SOC FPIOA DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-riscv@lists.infradead.org
-L: linux-gpio@vger.kernel.org (pinctrl driver)
-F: Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
-F: drivers/pinctrl/pinctrl-k210.c
-
-CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-kernel@vger.kernel.org
-L: linux-riscv@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
-F: drivers/reset/reset-k210.c
-
-CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
-M: Damien Le Moal <damien.lemoal@wdc.com>
-L: linux-riscv@lists.infradead.org
-S: Maintained
-F: Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
-F: drivers/soc/canaan/
-F: include/soc/canaan/
-
CACHEFILES: FS-CACHE BACKEND FOR CACHING ON MOUNTED FILESYSTEMS
M: David Howells <dhowells@redhat.com>
L: linux-cachefs@redhat.com (moderated for non-subscribers)
@@ -4240,6 +4210,29 @@ F: Documentation/networking/j1939.rst
F: include/uapi/linux/can/j1939.h
F: net/can/j1939/
+CANAAN/KENDRYTE K210 SOC FPIOA DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-riscv@lists.infradead.org
+L: linux-gpio@vger.kernel.org (pinctrl driver)
+F: Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
+F: drivers/pinctrl/pinctrl-k210.c
+
+CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-kernel@vger.kernel.org
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
+F: drivers/reset/reset-k210.c
+
+CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
+M: Damien Le Moal <damien.lemoal@wdc.com>
+L: linux-riscv@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
+F: drivers/soc/canaan/
+F: include/soc/canaan/
+
CAPABILITIES
M: Serge Hallyn <serge@hallyn.com>
L: linux-security-module@vger.kernel.org
@@ -4489,17 +4482,17 @@ F: drivers/power/supply/cros_usbpd-charger.c
N: cros_ec
N: cros-ec
-CHROMEOS EC USB TYPE-C DRIVER
-M: Prashant Malani <pmalani@chromium.org>
-S: Maintained
-F: drivers/platform/chrome/cros_ec_typec.c
-
CHROMEOS EC USB PD NOTIFY DRIVER
M: Prashant Malani <pmalani@chromium.org>
S: Maintained
F: drivers/platform/chrome/cros_usbpd_notify.c
F: include/linux/platform_data/cros_usbpd_notify.h
+CHROMEOS EC USB TYPE-C DRIVER
+M: Prashant Malani <pmalani@chromium.org>
+S: Maintained
+F: drivers/platform/chrome/cros_ec_typec.c
+
CHRONTEL CH7322 CEC DRIVER
M: Joe Tessler <jrt@google.com>
L: linux-media@vger.kernel.org
@@ -4604,6 +4597,18 @@ M: Nelson Escobar <neescoba@cisco.com>
S: Supported
F: drivers/infiniband/hw/usnic/
+CLANG CONTROL FLOW INTEGRITY SUPPORT
+M: Sami Tolvanen <samitolvanen@google.com>
+M: Kees Cook <keescook@chromium.org>
+R: Nathan Chancellor <nathan@kernel.org>
+R: Nick Desaulniers <ndesaulniers@google.com>
+L: llvm@lists.linux.dev
+S: Supported
+B: https://github.com/ClangBuiltLinux/linux/issues
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
+F: include/linux/cfi.h
+F: kernel/cfi.c
+
CLANG-FORMAT FILE
M: Miguel Ojeda <ojeda@kernel.org>
S: Maintained
@@ -4623,18 +4628,6 @@ F: scripts/Makefile.clang
F: scripts/clang-tools/
K: \b(?i:clang|llvm)\b
-CLANG CONTROL FLOW INTEGRITY SUPPORT
-M: Sami Tolvanen <samitolvanen@google.com>
-M: Kees Cook <keescook@chromium.org>
-R: Nathan Chancellor <nathan@kernel.org>
-R: Nick Desaulniers <ndesaulniers@google.com>
-L: llvm@lists.linux.dev
-S: Supported
-B: https://github.com/ClangBuiltLinux/linux/issues
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/clang/features
-F: include/linux/cfi.h
-F: kernel/cfi.c
-
CLEANCACHE API
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
L: linux-kernel@vger.kernel.org
@@ -5117,6 +5110,13 @@ S: Supported
W: http://www.chelsio.com
F: drivers/crypto/chelsio
+CXGB4 ETHERNET DRIVER (CXGB4)
+M: Raju Rangoju <rajur@chelsio.com>
+L: netdev@vger.kernel.org
+S: Supported
+W: http://www.chelsio.com
+F: drivers/net/ethernet/chelsio/cxgb4/
+
CXGB4 INLINE CRYPTO DRIVER
M: Ayush Sawal <ayush.sawal@chelsio.com>
M: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
@@ -5126,13 +5126,6 @@ S: Supported
W: http://www.chelsio.com
F: drivers/net/ethernet/chelsio/inline_crypto/
-CXGB4 ETHERNET DRIVER (CXGB4)
-M: Raju Rangoju <rajur@chelsio.com>
-L: netdev@vger.kernel.org
-S: Supported
-W: http://www.chelsio.com
-F: drivers/net/ethernet/chelsio/cxgb4/
-
CXGB4 ISCSI DRIVER (CXGB4I)
M: Karen Xie <kxie@chelsio.com>
L: linux-scsi@vger.kernel.org
@@ -5188,16 +5181,6 @@ CYCLADES PC300 DRIVER
S: Orphan
F: drivers/net/wan/pc300*
-CYPRESS_FIRMWARE MEDIA DRIVER
-M: Antti Palosaari <crope@iki.fi>
-L: linux-media@vger.kernel.org
-S: Maintained
-W: https://linuxtv.org
-W: http://palosaari.fi/linux/
-Q: http://patchwork.linuxtv.org/project/linux-media/list/
-T: git git://linuxtv.org/anttip/media_tree.git
-F: drivers/media/common/cypress_firmware*
-
CYPRESS CY8CTMA140 TOUCHSCREEN DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-input@vger.kernel.org
@@ -5211,6 +5194,16 @@ S: Maintained
F: Documentation/devicetree/bindings/input/cypress-sf.yaml
F: drivers/input/keyboard/cypress-sf.c
+CYPRESS_FIRMWARE MEDIA DRIVER
+M: Antti Palosaari <crope@iki.fi>
+L: linux-media@vger.kernel.org
+S: Maintained
+W: https://linuxtv.org
+W: http://palosaari.fi/linux/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/anttip/media_tree.git
+F: drivers/media/common/cypress_firmware*
+
CYTTSP TOUCHSCREEN DRIVER
M: Linus Walleij <linus.walleij@linaro.org>
L: linux-input@vger.kernel.org
@@ -5381,14 +5374,12 @@ L: Dell.Client.Kernel@dell.com
S: Maintained
F: drivers/platform/x86/dell/dell-wmi-descriptor.c
-DELL WMI SYSMAN DRIVER
-M: Divya Bharathi <divya.bharathi@dell.com>
-M: Prasanth Ksr <prasanth.ksr@dell.com>
+DELL WMI HARDWARE PRIVACY SUPPORT
+M: Perry Yuan <Perry.Yuan@dell.com>
L: Dell.Client.Kernel@dell.com
L: platform-driver-x86@vger.kernel.org
S: Maintained
-F: Documentation/ABI/testing/sysfs-class-firmware-attributes
-F: drivers/platform/x86/dell/dell-wmi-sysman/
+F: drivers/platform/x86/dell/dell-wmi-privacy.c
DELL WMI NOTIFICATIONS DRIVER
M: Matthew Garrett <mjg59@srcf.ucam.org>
@@ -5396,12 +5387,21 @@ M: Pali Rohár <pali@kernel.org>
S: Maintained
F: drivers/platform/x86/dell/dell-wmi-base.c
-DELL WMI HARDWARE PRIVACY SUPPORT
-M: Perry Yuan <Perry.Yuan@dell.com>
+DELL WMI SYSMAN DRIVER
+M: Divya Bharathi <divya.bharathi@dell.com>
+M: Prasanth Ksr <prasanth.ksr@dell.com>
L: Dell.Client.Kernel@dell.com
L: platform-driver-x86@vger.kernel.org
S: Maintained
-F: drivers/platform/x86/dell/dell-wmi-privacy.c
+F: Documentation/ABI/testing/sysfs-class-firmware-attributes
+F: drivers/platform/x86/dell/dell-wmi-sysman/
+
+DELTA DPS920AB PSU DRIVER
+M: Robert Marko <robert.marko@sartura.hr>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/dps920ab.rst
+F: drivers/hwmon/pmbus/dps920ab.c
DELTA ST MEDIA DRIVER
M: Hugues Fruchet <hugues.fruchet@foss.st.com>
@@ -5411,13 +5411,6 @@ W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/platform/sti/delta
-DELTA DPS920AB PSU DRIVER
-M: Robert Marko <robert.marko@sartura.hr>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/hwmon/dps920ab.rst
-F: drivers/hwmon/pmbus/dps920ab.c
-
DENALI NAND DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -5430,13 +5423,6 @@ S: Maintained
F: drivers/dma/dw-edma/
F: include/linux/dma/edma.h
-DESIGNWARE XDATA IP DRIVER
-M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
-L: linux-pci@vger.kernel.org
-S: Maintained
-F: Documentation/misc-devices/dw-xdata-pcie.rst
-F: drivers/misc/dw-xdata-pcie.c
-
DESIGNWARE USB2 DRD IP DRIVER
M: Minas Harutyunyan <hminas@synopsys.com>
L: linux-usb@vger.kernel.org
@@ -5451,6 +5437,13 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
F: drivers/usb/dwc3/
+DESIGNWARE XDATA IP DRIVER
+M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+L: linux-pci@vger.kernel.org
+S: Maintained
+F: Documentation/misc-devices/dw-xdata-pcie.rst
+F: drivers/misc/dw-xdata-pcie.c
+
DEVANTECH SRF ULTRASONIC RANGER IIO DRIVER
M: Andreas Klinger <ak@it-klinger.de>
L: linux-iio@vger.kernel.org
@@ -5680,6 +5673,12 @@ F: include/linux/dma/
F: include/linux/dmaengine.h
F: include/linux/of_dma.h
+DMA MAPPING BENCHMARK
+M: Barry Song <song.bao.hua@hisilicon.com>
+L: iommu@lists.linux-foundation.org
+F: kernel/dma/map_benchmark.c
+F: tools/testing/selftests/dma/
+
DMA MAPPING HELPERS
M: Christoph Hellwig <hch@lst.de>
M: Marek Szyprowski <m.szyprowski@samsung.com>
@@ -5694,12 +5693,6 @@ F: include/linux/dma-mapping.h
F: include/linux/dma-map-ops.h
F: kernel/dma/
-DMA MAPPING BENCHMARK
-M: Barry Song <song.bao.hua@hisilicon.com>
-L: iommu@lists.linux-foundation.org
-F: kernel/dma/map_benchmark.c
-F: tools/testing/selftests/dma/
-
DMA-BUF HEAPS FRAMEWORK
M: Sumit Semwal <sumit.semwal@linaro.org>
R: Benjamin Gaignard <benjamin.gaignard@linaro.org>
@@ -5981,6 +5974,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
F: drivers/gpu/drm/tiny/hx8357d.c
+DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
+M: Deepak Rawat <drawat.floss@gmail.com>
+L: linux-hyperv@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/hyperv
+
DRM DRIVER FOR ILITEK ILI9225 PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
@@ -6126,14 +6127,6 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml
F: drivers/gpu/drm/panel/panel-samsung-s6d27a1.c
-DRM DRIVER FOR SITRONIX ST7703 PANELS
-M: Guido Günther <agx@sigxcpu.org>
-R: Purism Kernel Team <kernel@puri.sm>
-R: Ondrej Jirman <megous@megous.com>
-S: Maintained
-F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
-F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
-
DRM DRIVER FOR SAVAGE VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/savage/
@@ -6164,6 +6157,14 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
F: drivers/gpu/drm/panel/panel-sitronix-st7701.c
+DRM DRIVER FOR SITRONIX ST7703 PANELS
+M: Guido Günther <agx@sigxcpu.org>
+R: Purism Kernel Team <kernel@puri.sm>
+R: Ondrej Jirman <megous@megous.com>
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
+
DRM DRIVER FOR SITRONIX ST7735R PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
@@ -6358,14 +6359,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/hisilicon/
F: drivers/gpu/drm/hisilicon/
-DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
-M: Deepak Rawat <drawat.floss@gmail.com>
-L: linux-hyperv@vger.kernel.org
-L: dri-devel@lists.freedesktop.org
-S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
-F: drivers/gpu/drm/hyperv
-
DRM DRIVERS FOR LIMA
M: Qiang Yu <yuq825@gmail.com>
L: dri-devel@lists.freedesktop.org
@@ -6513,6 +6506,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/xlnx/
F: drivers/gpu/drm/xlnx/
+DRM GPU SCHEDULER
+M: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/scheduler/
+F: include/drm/gpu_scheduler.h
+
DRM PANEL DRIVERS
M: Thierry Reding <thierry.reding@gmail.com>
R: Sam Ravnborg <sam@ravnborg.org>
@@ -6533,14 +6534,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/gpu/drm/ttm/
F: include/drm/ttm/
-DRM GPU SCHEDULER
-M: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
-L: dri-devel@lists.freedesktop.org
-S: Maintained
-T: git git://anongit.freedesktop.org/drm/drm-misc
-F: drivers/gpu/drm/scheduler/
-F: include/drm/gpu_scheduler.h
-
DSBR100 USB FM RADIO DRIVER
M: Alexey Klimov <klimov.linux@gmail.com>
L: linux-media@vger.kernel.org
@@ -6679,6 +6672,15 @@ F: Documentation/networking/net_dim.rst
F: include/linux/dim.h
F: lib/dim/
+DYNAMIC THERMAL POWER MANAGEMENT (DTPM)
+M: Daniel Lezcano <daniel.lezcano@kernel.org>
+L: linux-pm@vger.kernel.org
+S: Supported
+B: https://bugzilla.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
+F: drivers/powercap/dtpm*
+F: include/linux/dtpm.h
+
DZ DECSTATION DZ11 SERIAL DRIVER
M: "Maciej W. Rozycki" <macro@orcam.me.uk>
S: Maintained
@@ -7026,22 +7028,22 @@ W: http://www.broadcom.com
F: drivers/infiniband/hw/ocrdma/
F: include/uapi/rdma/ocrdma-abi.h
-EMULEX/BROADCOM LPFC FC/FCOE SCSI DRIVER
+EMULEX/BROADCOM EFCT FC/FCOE SCSI TARGET DRIVER
M: James Smart <james.smart@broadcom.com>
-M: Dick Kennedy <dick.kennedy@broadcom.com>
+M: Ram Vegesna <ram.vegesna@broadcom.com>
L: linux-scsi@vger.kernel.org
+L: target-devel@vger.kernel.org
S: Supported
W: http://www.broadcom.com
-F: drivers/scsi/lpfc/
+F: drivers/scsi/elx/
-EMULEX/BROADCOM EFCT FC/FCOE SCSI TARGET DRIVER
+EMULEX/BROADCOM LPFC FC/FCOE SCSI DRIVER
M: James Smart <james.smart@broadcom.com>
-M: Ram Vegesna <ram.vegesna@broadcom.com>
+M: Dick Kennedy <dick.kennedy@broadcom.com>
L: linux-scsi@vger.kernel.org
-L: target-devel@vger.kernel.org
S: Supported
W: http://www.broadcom.com
-F: drivers/scsi/elx/
+F: drivers/scsi/lpfc/
ENE CB710 FLASH CARD READER DRIVER
M: Michał Mirosław <mirq-linux@rere.qmqm.pl>
@@ -8518,6 +8520,12 @@ W: http://www.highpoint-tech.com
F: Documentation/scsi/hptiop.rst
F: drivers/scsi/hptiop.c
+HIKEY960 ONBOARD USB GPIO HUB DRIVER
+M: John Stultz <john.stultz@linaro.org>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/misc/hisi_hikey_usb.c
+
HIPPI
M: Jes Sorensen <jes@trained-monkey.org>
L: linux-hippi@sunsite.dk
@@ -8588,12 +8596,6 @@ W: http://www.hisilicon.com
F: Documentation/devicetree/bindings/net/hisilicon*.txt
F: drivers/net/ethernet/hisilicon/
-HIKEY960 ONBOARD USB GPIO HUB DRIVER
-M: John Stultz <john.stultz@linaro.org>
-L: linux-kernel@vger.kernel.org
-S: Maintained
-F: drivers/misc/hisi_hikey_usb.c
-
HISILICON PMU DRIVER
M: Shaokun Zhang <zhangshaokun@hisilicon.com>
S: Supported
@@ -9619,18 +9621,18 @@ F: Documentation/admin-guide/media/ipu3_rcb.svg
F: Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst
F: drivers/staging/media/ipu3/
-INTEL IXP4XX CRYPTO SUPPORT
-M: Corentin Labbe <clabbe@baylibre.com>
-L: linux-crypto@vger.kernel.org
-S: Maintained
-F: drivers/crypto/ixp4xx_crypto.c
-
INTEL ISHTP ECLITE DRIVER
M: Sumesh K Naduvalath <sumesh.k.naduvalath@intel.com>
L: platform-driver-x86@vger.kernel.org
S: Supported
F: drivers/platform/x86/intel/ishtp_eclite.c
+INTEL IXP4XX CRYPTO SUPPORT
+M: Corentin Labbe <clabbe@baylibre.com>
+L: linux-crypto@vger.kernel.org
+S: Maintained
+F: drivers/crypto/ixp4xx_crypto.c
+
INTEL IXP4XX QMGR, NPE, ETHERNET and HSS SUPPORT
M: Krzysztof Halasa <khalasa@piap.pl>
S: Maintained
@@ -9773,6 +9775,21 @@ S: Maintained
F: arch/x86/include/asm/intel_scu_ipc.h
F: drivers/platform/x86/intel_scu_*
+INTEL SGX
+M: Jarkko Sakkinen <jarkko@kernel.org>
+R: Dave Hansen <dave.hansen@linux.intel.com>
+L: linux-sgx@vger.kernel.org
+S: Supported
+Q: https://patchwork.kernel.org/project/intel-sgx/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/sgx
+F: Documentation/x86/sgx.rst
+F: arch/x86/entry/vdso/vsgx.S
+F: arch/x86/include/asm/sgx.h
+F: arch/x86/include/uapi/asm/sgx.h
+F: arch/x86/kernel/cpu/sgx/*
+F: tools/testing/selftests/sgx/*
+K: \bSGX_
+
INTEL SKYLAKE INT3472 ACPI DEVICE DRIVER
M: Daniel Scally <djrscally@gmail.com>
S: Maintained
@@ -9867,21 +9884,6 @@ F: Documentation/x86/intel_txt.rst
F: arch/x86/kernel/tboot.c
F: include/linux/tboot.h
-INTEL SGX
-M: Jarkko Sakkinen <jarkko@kernel.org>
-R: Dave Hansen <dave.hansen@linux.intel.com>
-L: linux-sgx@vger.kernel.org
-S: Supported
-Q: https://patchwork.kernel.org/project/intel-sgx/list/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/sgx
-F: Documentation/x86/sgx.rst
-F: arch/x86/entry/vdso/vsgx.S
-F: arch/x86/include/asm/sgx.h
-F: arch/x86/include/uapi/asm/sgx.h
-F: arch/x86/kernel/cpu/sgx/*
-F: tools/testing/selftests/sgx/*
-K: \bSGX_
-
INTERCONNECT API
M: Georgi Djakov <djakov@kernel.org>
L: linux-pm@vger.kernel.org
@@ -11287,6 +11289,12 @@ F: drivers/mailbox/arm_mhuv2.c
F: include/linux/mailbox/arm_mhuv2_message.h
F: Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
+MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
+M: Michael Kerrisk <mtk.manpages@gmail.com>
+L: linux-man@vger.kernel.org
+S: Maintained
+W: http://www.kernel.org/doc/man-pages
+
MANAGEMENT COMPONENT TRANSPORT PROTOCOL (MCTP)
M: Jeremy Kerr <jk@codeconstruct.com.au>
M: Matt Johnston <matt@codeconstruct.com.au>
@@ -11299,12 +11307,6 @@ F: include/net/mctpdevice.h
F: include/net/netns/mctp.h
F: net/mctp/
-MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
-M: Michael Kerrisk <mtk.manpages@gmail.com>
-L: linux-man@vger.kernel.org
-S: Maintained
-W: http://www.kernel.org/doc/man-pages
-
MARDUK (CREATOR CI40) DEVICE TREE SUPPORT
M: Rahul Bedarkar <rahulbedarkar89@gmail.com>
L: linux-mips@vger.kernel.org
@@ -11623,12 +11625,6 @@ L: netdev@vger.kernel.org
S: Supported
F: drivers/net/phy/mxl-gpy.c
-MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
-R: Yasushi SHOJI <yashi@spacecubics.com>
-L: linux-can@vger.kernel.org
-S: Maintained
-F: drivers/net/can/usb/mcba_usb.c
-
MCAN MMIO DEVICE DRIVER
M: Chandrasekar Ramakrishnan <rcsekar@samsung.com>
L: linux-can@vger.kernel.org
@@ -11638,6 +11634,12 @@ F: drivers/net/can/m_can/m_can.c
F: drivers/net/can/m_can/m_can.h
F: drivers/net/can/m_can/m_can_platform.c
+MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
+R: Yasushi SHOJI <yashi@spacecubics.com>
+L: linux-can@vger.kernel.org
+S: Maintained
+F: drivers/net/can/usb/mcba_usb.c
+
MCP2221A MICROCHIP USB-HID TO I2C BRIDGE DRIVER
M: Rishi Gupta <gupt21@gmail.com>
L: linux-i2c@vger.kernel.org
@@ -12030,13 +12032,6 @@ S: Maintained
F: Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
F: drivers/clk/ralink/clk-mt7621.c
-MEDIATEK MT7621/28/88 I2C DRIVER
-M: Stefan Roese <sr@denx.de>
-L: linux-i2c@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
-F: drivers/i2c/busses/i2c-mt7621.c
-
MEDIATEK MT7621 PCIE CONTROLLER DRIVER
M: Sergio Paracuellos <sergio.paracuellos@gmail.com>
S: Maintained
@@ -12049,6 +12044,13 @@ S: Maintained
F: Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
F: drivers/phy/ralink/phy-mt7621-pci.c
+MEDIATEK MT7621/28/88 I2C DRIVER
+M: Stefan Roese <sr@denx.de>
+L: linux-i2c@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
+F: drivers/i2c/busses/i2c-mt7621.c
+
MEDIATEK NAND CONTROLLER DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -12580,6 +12582,13 @@ S: Supported
F: drivers/misc/atmel-ssc.c
F: include/linux/atmel-ssc.h
+Microchip Timer Counter Block (TCB) Capture Driver
+M: Kamel Bouhara <kamel.bouhara@bootlin.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: drivers/counter/microchip-tcb-capture.c
+
MICROCHIP USB251XB DRIVER
M: Richard Leitner <richard.leitner@skidata.com>
L: linux-usb@vger.kernel.org
@@ -13680,13 +13689,6 @@ F: drivers/iio/gyro/fxas21002c_core.c
F: drivers/iio/gyro/fxas21002c_i2c.c
F: drivers/iio/gyro/fxas21002c_spi.c
-NXP i.MX CLOCK DRIVERS
-M: Abel Vesa <abel.vesa@nxp.com>
-L: linux-clk@vger.kernel.org
-L: linux-imx@nxp.com
-S: Maintained
-F: drivers/clk/imx/
-
NXP i.MX 8MQ DCSS DRIVER
M: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
R: Lucas Stach <l.stach@pengutronix.de>
@@ -13702,6 +13704,21 @@ S: Supported
F: Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
F: drivers/iio/adc/imx8qxp-adc.c
+NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
+M: Mirela Rabulea <mirela.rabulea@nxp.com>
+R: NXP Linux Team <linux-imx@nxp.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
+F: drivers/media/platform/imx-jpeg
+
+NXP i.MX CLOCK DRIVERS
+M: Abel Vesa <abel.vesa@nxp.com>
+L: linux-clk@vger.kernel.org
+L: linux-imx@nxp.com
+S: Maintained
+F: drivers/clk/imx/
+
NXP PF8100/PF8121A/PF8200 PMIC REGULATOR DEVICE DRIVER
M: Jagan Teki <jagan@amarulasolutions.com>
S: Maintained
@@ -13739,19 +13756,12 @@ F: include/drm/i2c/tda998x.h
F: include/dt-bindings/display/tda998x.h
K: "nxp,tda998x"
-NXP TFA9879 DRIVER
-M: Peter Rosin <peda@axentia.se>
-L: alsa-devel@alsa-project.org (moderated for non-subscribers)
-S: Maintained
-F: Documentation/devicetree/bindings/sound/tfa9879.txt
-F: sound/soc/codecs/tfa9879*
-
-NXP/Goodix TFA989X (TFA1) DRIVER
-M: Stephan Gerhold <stephan@gerhold.net>
+NXP TFA9879 DRIVER
+M: Peter Rosin <peda@axentia.se>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
-F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
-F: sound/soc/codecs/tfa989x.c
+F: Documentation/devicetree/bindings/sound/tfa9879.txt
+F: sound/soc/codecs/tfa9879*
NXP-NCI NFC DRIVER
R: Charles Gorand <charles.gorand@effinnov.com>
@@ -13760,13 +13770,12 @@ S: Supported
F: Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml
F: drivers/nfc/nxp-nci
-NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
-M: Mirela Rabulea <mirela.rabulea@nxp.com>
-R: NXP Linux Team <linux-imx@nxp.com>
-L: linux-media@vger.kernel.org
+NXP/Goodix TFA989X (TFA1) DRIVER
+M: Stephan Gerhold <stephan@gerhold.net>
+L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
-F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
-F: drivers/media/platform/imx-jpeg
+F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
+F: sound/soc/codecs/tfa989x.c
NZXT-KRAKEN2 HARDWARE MONITORING DRIVER
M: Jonas Malaco <jonas@protocubo.io>
@@ -14556,6 +14565,14 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: drivers/pci/controller/dwc/*layerscape*
+PCI DRIVER FOR FU740
+M: Paul Walmsley <paul.walmsley@sifive.com>
+M: Greentime Hu <greentime.hu@sifive.com>
+L: linux-pci@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
+F: drivers/pci/controller/dwc/pcie-fu740.c
+
PCI DRIVER FOR GENERIC OF HOSTS
M: Will Deacon <will@kernel.org>
L: linux-pci@vger.kernel.org
@@ -14574,14 +14591,6 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
F: drivers/pci/controller/dwc/*imx6*
-PCI DRIVER FOR FU740
-M: Paul Walmsley <paul.walmsley@sifive.com>
-M: Greentime Hu <greentime.hu@sifive.com>
-L: linux-pci@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
-F: drivers/pci/controller/dwc/pcie-fu740.c
-
PCI DRIVER FOR INTEL IXP4XX
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
@@ -14854,14 +14863,6 @@ L: linux-arm-msm@vger.kernel.org
S: Maintained
F: drivers/pci/controller/dwc/pcie-qcom.c
-PCIE ENDPOINT DRIVER FOR QUALCOMM
-M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-L: linux-pci@vger.kernel.org
-L: linux-arm-msm@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
-F: drivers/pci/controller/dwc/pcie-qcom-ep.c
-
PCIE DRIVER FOR ROCKCHIP
M: Shawn Lin <shawn.lin@rock-chips.com>
L: linux-pci@vger.kernel.org
@@ -14883,6 +14884,14 @@ L: linux-pci@vger.kernel.org
S: Maintained
F: drivers/pci/controller/dwc/*spear*
+PCIE ENDPOINT DRIVER FOR QUALCOMM
+M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+L: linux-pci@vger.kernel.org
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
+F: drivers/pci/controller/dwc/pcie-qcom-ep.c
+
PCMCIA SUBSYSTEM
M: Dominik Brodowski <linux@dominikbrodowski.net>
S: Odd Fixes
@@ -15142,13 +15151,6 @@ M: Logan Gunthorpe <logang@deltatee.com>
S: Maintained
F: drivers/dma/plx_dma.c
-PM6764TR DRIVER
-M: Charles Hsu <hsu.yungteng@gmail.com>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/hwmon/pm6764tr.rst
-F: drivers/hwmon/pmbus/pm6764tr.c
-
PM-GRAPH UTILITY
M: "Todd E Brandt" <todd.e.brandt@linux.intel.com>
L: linux-pm@vger.kernel.org
@@ -15158,6 +15160,13 @@ B: https://bugzilla.kernel.org/buglist.cgi?component=pm-graph&product=Tools
T: git git://github.com/intel/pm-graph
F: tools/power/pm-graph
+PM6764TR DRIVER
+M: Charles Hsu <hsu.yungteng@gmail.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/pm6764tr.rst
+F: drivers/hwmon/pmbus/pm6764tr.c
+
PMBUS HARDWARE MONITORING DRIVERS
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
@@ -15238,15 +15247,6 @@ F: include/linux/pm_*
F: include/linux/powercap.h
F: kernel/configs/nopm.config
-DYNAMIC THERMAL POWER MANAGEMENT (DTPM)
-M: Daniel Lezcano <daniel.lezcano@kernel.org>
-L: linux-pm@vger.kernel.org
-S: Supported
-B: https://bugzilla.kernel.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
-F: drivers/powercap/dtpm*
-F: include/linux/dtpm.h
-
POWER STATE COORDINATION INTERFACE (PSCI)
M: Mark Rutland <mark.rutland@arm.com>
M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
@@ -16261,12 +16261,6 @@ S: Supported
F: Documentation/devicetree/bindings/i2c/renesas,riic.yaml
F: drivers/i2c/busses/i2c-riic.c
-RENESAS USB PHY DRIVER
-M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
-L: linux-renesas-soc@vger.kernel.org
-S: Maintained
-F: drivers/phy/renesas/phy-rcar-gen3-usb*.c
-
RENESAS RZ/G2L A/D DRIVER
M: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
L: linux-iio@vger.kernel.org
@@ -16275,6 +16269,12 @@ S: Supported
F: Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
F: drivers/iio/adc/rzg2l_adc.c
+RENESAS USB PHY DRIVER
+M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+L: linux-renesas-soc@vger.kernel.org
+S: Maintained
+F: drivers/phy/renesas/phy-rcar-gen3-usb*.c
+
RESET CONTROLLER FRAMEWORK
M: Philipp Zabel <p.zabel@pengutronix.de>
S: Maintained
@@ -17105,6 +17105,15 @@ F: block/sed*
F: include/linux/sed*
F: include/uapi/linux/sed*
+SECURE MONITOR CALL(SMC) CALLING CONVENTION (SMCCC)
+M: Mark Rutland <mark.rutland@arm.com>
+M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+M: Sudeep Holla <sudeep.holla@arm.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/firmware/smccc/
+F: include/linux/arm-smccc.h
+
SECURITY CONTACT
M: Security Officers <security@kernel.org>
S: Supported
@@ -17512,15 +17521,6 @@ M: Nicolas Pitre <nico@fluxnic.net>
S: Odd Fixes
F: drivers/net/ethernet/smsc/smc91x.*
-SECURE MONITOR CALL(SMC) CALLING CONVENTION (SMCCC)
-M: Mark Rutland <mark.rutland@arm.com>
-M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-M: Sudeep Holla <sudeep.holla@arm.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: drivers/firmware/smccc/
-F: include/linux/arm-smccc.h
-
SMM665 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
@@ -18701,6 +18701,14 @@ M: Thierry Reding <thierry.reding@gmail.com>
S: Supported
F: drivers/pwm/pwm-tegra.c
+TEGRA QUAD SPI DRIVER
+M: Thierry Reding <thierry.reding@gmail.com>
+M: Jonathan Hunter <jonathanh@nvidia.com>
+M: Sowjanya Komatineni <skomatineni@nvidia.com>
+L: linux-tegra@vger.kernel.org
+S: Maintained
+F: drivers/spi/spi-tegra210-quad.c
+
TEGRA SERIAL DRIVER
M: Laxman Dewangan <ldewangan@nvidia.com>
S: Supported
@@ -18711,14 +18719,6 @@ M: Laxman Dewangan <ldewangan@nvidia.com>
S: Supported
F: drivers/spi/spi-tegra*
-TEGRA QUAD SPI DRIVER
-M: Thierry Reding <thierry.reding@gmail.com>
-M: Jonathan Hunter <jonathanh@nvidia.com>
-M: Sowjanya Komatineni <skomatineni@nvidia.com>
-L: linux-tegra@vger.kernel.org
-S: Maintained
-F: drivers/spi/spi-tegra210-quad.c
-
TEGRA VIDEO DRIVER
M: Thierry Reding <thierry.reding@gmail.com>
M: Jonathan Hunter <jonathanh@nvidia.com>
@@ -18767,13 +18767,6 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: sound/soc/ti/
-TEXAS INSTRUMENTS' DAC7612 DAC DRIVER
-M: Ricardo Ribalda <ribalda@kernel.org>
-L: linux-iio@vger.kernel.org
-S: Supported
-F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
-F: drivers/iio/dac/ti-dac7612.c
-
TEXAS INSTRUMENTS DMA DRIVERS
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: dmaengine@vger.kernel.org
@@ -18787,6 +18780,22 @@ F: include/linux/dma/k3-udma-glue.h
F: include/linux/dma/ti-cppi5.h
F: include/linux/dma/k3-psil.h
+TEXAS INSTRUMENTS TPS23861 PoE PSE DRIVER
+M: Robert Marko <robert.marko@sartura.hr>
+M: Luka Perkov <luka.perkov@sartura.hr>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
+F: Documentation/hwmon/tps23861.rst
+F: drivers/hwmon/tps23861.c
+
+TEXAS INSTRUMENTS' DAC7612 DAC DRIVER
+M: Ricardo Ribalda <ribalda@kernel.org>
+L: linux-iio@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
+F: drivers/iio/dac/ti-dac7612.c
+
TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER
M: Nishanth Menon <nm@ti.com>
M: Tero Kristo <kristo@kernel.org>
@@ -18811,15 +18820,6 @@ F: include/dt-bindings/soc/ti,sci_pm_domain.h
F: include/linux/soc/ti/ti_sci_inta_msi.h
F: include/linux/soc/ti/ti_sci_protocol.h
-TEXAS INSTRUMENTS TPS23861 PoE PSE DRIVER
-M: Robert Marko <robert.marko@sartura.hr>
-M: Luka Perkov <luka.perkov@sartura.hr>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
-F: Documentation/hwmon/tps23861.rst
-F: drivers/hwmon/tps23861.c
-
TEXAS INSTRUMENTS' TMP117 TEMPERATURE SENSOR DRIVER
M: Puranjay Mohan <puranjay12@gmail.com>
L: linux-iio@vger.kernel.org
@@ -19719,6 +19719,13 @@ L: linux-usb@vger.kernel.org
S: Supported
F: drivers/usb/class/usblp.c
+USB QMI WWAN NETWORK DRIVER
+M: Bjørn Mork <bjorn@mork.no>
+L: netdev@vger.kernel.org
+S: Maintained
+F: Documentation/ABI/testing/sysfs-class-net-qmi
+F: drivers/net/usb/qmi_wwan.c
+
USB RAW GADGET DRIVER
R: Andrey Konovalov <andreyknvl@gmail.com>
L: linux-usb@vger.kernel.org
@@ -19727,13 +19734,6 @@ F: Documentation/usb/raw-gadget.rst
F: drivers/usb/gadget/legacy/raw_gadget.c
F: include/uapi/linux/usb/raw_gadget.h
-USB QMI WWAN NETWORK DRIVER
-M: Bjørn Mork <bjorn@mork.no>
-L: netdev@vger.kernel.org
-S: Maintained
-F: Documentation/ABI/testing/sysfs-class-net-qmi
-F: drivers/net/usb/qmi_wwan.c
-
USB RTL8150 DRIVER
M: Petko Manolov <petkan@nucleusys.com>
L: linux-usb@vger.kernel.org
@@ -20049,6 +20049,14 @@ S: Maintained
F: drivers/media/common/videobuf2/*
F: include/media/videobuf2-*
+VIDTV VIRTUAL DIGITAL TV DRIVER
+M: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+W: https://linuxtv.org
+T: git git://linuxtv.org/media_tree.git
+F: drivers/media/test-drivers/vidtv/*
+
VIMC VIRTUAL MEDIA CONTROLLER DRIVER
M: Helen Koike <helen.koike@collabora.com>
R: Shuah Khan <skhan@linuxfoundation.org>
@@ -20078,6 +20086,16 @@ F: include/uapi/linux/virtio_vsock.h
F: net/vmw_vsock/virtio_transport.c
F: net/vmw_vsock/virtio_transport_common.c
+VIRTIO BALLOON
+M: "Michael S. Tsirkin" <mst@redhat.com>
+M: David Hildenbrand <david@redhat.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/virtio/virtio_balloon.c
+F: include/uapi/linux/virtio_balloon.h
+F: include/linux/balloon_compaction.h
+F: mm/balloon_compaction.c
+
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
@@ -20115,16 +20133,6 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: tools/virtio/
-VIRTIO BALLOON
-M: "Michael S. Tsirkin" <mst@redhat.com>
-M: David Hildenbrand <david@redhat.com>
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/virtio/virtio_balloon.c
-F: include/uapi/linux/virtio_balloon.h
-F: include/linux/balloon_compaction.h
-F: mm/balloon_compaction.c
-
VIRTIO CRYPTO DRIVER
M: Gonglei <arei.gonglei@huawei.com>
L: virtualization@lists.linux-foundation.org
@@ -20186,6 +20194,15 @@ F: drivers/vhost/
F: include/linux/vhost_iotlb.h
F: include/uapi/linux/vhost.h
+VIRTIO I2C DRIVER
+M: Conghui Chen <conghui.chen@intel.com>
+M: Viresh Kumar <viresh.kumar@linaro.org>
+L: linux-i2c@vger.kernel.org
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/i2c/busses/i2c-virtio.c
+F: include/uapi/linux/virtio_i2c.h
+
VIRTIO INPUT DRIVER
M: Gerd Hoffmann <kraxel@redhat.com>
S: Maintained
@@ -20207,6 +20224,13 @@ W: https://virtio-mem.gitlab.io/
F: drivers/virtio/virtio_mem.c
F: include/uapi/linux/virtio_mem.h
+VIRTIO PMEM DRIVER
+M: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/nvdimm/virtio_pmem.c
+F: drivers/nvdimm/nd_virtio.c
+
VIRTIO SOUND DRIVER
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
M: "Michael S. Tsirkin" <mst@redhat.com>
@@ -20216,22 +20240,6 @@ S: Maintained
F: include/uapi/linux/virtio_snd.h
F: sound/virtio/*
-VIRTIO I2C DRIVER
-M: Conghui Chen <conghui.chen@intel.com>
-M: Viresh Kumar <viresh.kumar@linaro.org>
-L: linux-i2c@vger.kernel.org
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/i2c/busses/i2c-virtio.c
-F: include/uapi/linux/virtio_i2c.h
-
-VIRTIO PMEM DRIVER
-M: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
-L: virtualization@lists.linux-foundation.org
-S: Maintained
-F: drivers/nvdimm/virtio_pmem.c
-F: drivers/nvdimm/nd_virtio.c
-
VIRTUAL BOX GUEST DEVICE DRIVER
M: Hans de Goede <hdegoede@redhat.com>
M: Arnd Bergmann <arnd@arndb.de>
@@ -20261,14 +20269,6 @@ W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/test-drivers/vivid/*
-VIDTV VIRTUAL DIGITAL TV DRIVER
-M: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
-L: linux-media@vger.kernel.org
-S: Maintained
-W: https://linuxtv.org
-T: git git://linuxtv.org/media_tree.git
-F: drivers/media/test-drivers/vidtv/*
-
VLYNQ BUS
M: Florian Fainelli <f.fainelli@gmail.com>
L: openwrt-devel@lists.openwrt.org (subscribers-only)
@@ -20276,18 +20276,6 @@ S: Maintained
F: drivers/vlynq/vlynq.c
F: include/linux/vlynq.h
-VME SUBSYSTEM
-M: Martyn Welch <martyn@welchs.me.uk>
-M: Manohar Vanga <manohar.vanga@gmail.com>
-M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-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/vme/
-F: include/linux/vme*
-
VM SOCKETS (AF_VSOCK)
M: Stefano Garzarella <sgarzare@redhat.com>
L: virtualization@lists.linux-foundation.org
@@ -20301,6 +20289,18 @@ F: include/uapi/linux/vsockmon.h
F: net/vmw_vsock/
F: tools/testing/vsock/
+VME SUBSYSTEM
+M: Martyn Welch <martyn@welchs.me.uk>
+M: Manohar Vanga <manohar.vanga@gmail.com>
+M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+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/vme/
+F: include/linux/vme*
+
VMWARE BALLOON DRIVER
M: Nadav Amit <namit@vmware.com>
M: "VMware, Inc." <pv-drivers@vmware.com>
--
2.33.0
^ permalink raw reply related [relevance 13%]
* [PATCH v3] MAINTAINERS: merge SWIOTLB SUBSYSTEM into DMA MAPPING HELPERS
@ 2022-09-22 10:00 13% Lukas Bulwahn
0 siblings, 0 replies; 200+ results
From: Lukas Bulwahn @ 2022-09-22 10:00 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Juergen Gross, Stefano Stabellini, kernel-janitors, linux-kernel,
Lukas Bulwahn
Commit 78013eaadf69 ("x86: remove the IOMMU table infrastructure")
refactored the generic swiotlb/swiotlb-xen setup into pci-dma.c, but
misses to adjust MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about
broken references.
As only include/linux/swiotlb.h is unique to the SWIOTLB SUBSYSTEM section
and Christoph is maintainer of DMA MAPPING HELPERS and SWIOTLB SUBSYSTEM,
just merge those two sections.
Leave the small architecture-dependent pieces to the arch maintainers.
Further, update the XEN SWIOTLB SUBSYSTEM to include all swiotlb-xen
headers and replace the pattern in drivers with the specific one file that
matches this pattern.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Acked-by: Juergen Gross <jgross@suse.com>
---
v1: https://lore.kernel.org/lkml/20220601075613.28245-1-lukas.bulwahn@gmail.com/
v1 -> v2: https://lore.kernel.org/lkml/20220919084744.3043-1-lukas.bulwahn@gmail.com/
addressed Christoph's comment, removed arch/*/kernel/pci-swiotlb.c
added Juergen's ack
v2 -> v3:
merged sections as requested by Christoph
Christoph, please pick this minor non-urgent clean-up patch for swiotlb.
MAINTAINERS | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d06f0b2861a..52f31f11bb0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6166,6 +6166,7 @@ F: include/asm-generic/dma-mapping.h
F: include/linux/dma-direct.h
F: include/linux/dma-mapping.h
F: include/linux/dma-map-ops.h
+F: include/linux/swiotlb.h
F: kernel/dma/
DMA MAPPING BENCHMARK
@@ -19739,16 +19740,6 @@ S: Maintained
F: Documentation/admin-guide/svga.rst
F: arch/x86/boot/video*
-SWIOTLB SUBSYSTEM
-M: Christoph Hellwig <hch@infradead.org>
-L: iommu@lists.linux.dev
-S: Supported
-W: http://git.infradead.org/users/hch/dma-mapping.git
-T: git git://git.infradead.org/users/hch/dma-mapping.git
-F: arch/*/kernel/pci-swiotlb.c
-F: include/linux/swiotlb.h
-F: kernel/dma/swiotlb.c
-
SWITCHDEV
M: Jiri Pirko <jiri@resnulli.us>
M: Ivan Vecera <ivecera@redhat.com>
@@ -22457,8 +22448,10 @@ M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux.dev
S: Supported
-F: arch/x86/xen/*swiotlb*
-F: drivers/xen/*swiotlb*
+F: arch/*/include/asm/xen/swiotlb-xen.h
+F: drivers/xen/swiotlb-xen.c
+F: include/xen/arm/swiotlb-xen.h
+F: include/xen/swiotlb-xen.h
XFS FILESYSTEM
C: irc://irc.oftc.net/xfs
--
2.17.1
^ permalink raw reply related [relevance 13%]
* [PATCH v2] MAINTAINERS: refurbish SWIOTLB SUBSYSTEM sections after refactoring
@ 2022-09-19 8:47 14% Lukas Bulwahn
0 siblings, 0 replies; 200+ results
From: Lukas Bulwahn @ 2022-09-19 8:47 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Juergen Gross, Stefano Stabellini, kernel-janitors, linux-kernel,
Lukas Bulwahn
Commit 78013eaadf69 ("x86: remove the IOMMU table infrastructure")
refactored the generic swiotlb/swiotlb-xen setup into pci-dma.c, but
misses to adjust MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about
broken references.
Update the SWIOTLB SUBSYSTEM to contain the architecture-independent
pieces for swiotlb, but leave the small architecture-dependent pieces to
the architecture maintainers.
Further, update the XEN SWIOTLB SUBSYSTEM to include all swiotlb-xen
headers and replace the pattern in drivers with the specific one file that
matches this pattern.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Acked-by: Juergen Gross <jgross@suse.com>
---
v1: https://lore.kernel.org/lkml/20220601075613.28245-1-lukas.bulwahn@gmail.com/
v1 -> v2:
addressed Christoph's comment, removed arch/*/kernel/pci-swiotlb.c
added Juergen's ack
Christoph, please pick this minor non-urgent clean-up patch for swiotlb.
MAINTAINERS | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index babb441f7474..69d58c43bd6a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19699,7 +19699,6 @@ L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
-F: arch/*/kernel/pci-swiotlb.c
F: include/linux/swiotlb.h
F: kernel/dma/swiotlb.c
@@ -22403,8 +22402,10 @@ M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux.dev
S: Supported
-F: arch/x86/xen/*swiotlb*
-F: drivers/xen/*swiotlb*
+F: arch/*/include/asm/xen/swiotlb-xen.h
+F: drivers/xen/swiotlb-xen.c
+F: include/xen/arm/swiotlb-xen.h
+F: include/xen/swiotlb-xen.h
XFS FILESYSTEM
C: irc://irc.oftc.net/xfs
--
2.17.1
^ permalink raw reply related [relevance 14%]
* [PATCH v2] MAINTAINERS: refurbish SWIOTLB SUBSYSTEM sections after refactoring
@ 2022-09-19 8:44 14% Lukas Bulwahn
0 siblings, 0 replies; 200+ results
From: Lukas Bulwahn @ 2022-09-19 8:44 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Juergen Gross, Stefano Stabellini, kernel-janitors, linux-kernel,
Lukas Bulwahn
Commit 78013eaadf69 ("x86: remove the IOMMU table infrastructure")
refactored the generic swiotlb/swiotlb-xen setup into pci-dma.c, but
misses to adjust MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about
broken references.
Update the SWIOTLB SUBSYSTEM to contain the architecture-independent
pieces for swiotlb, but leave the small architecture-dependent pieces to
the architecture maintainers.
Further, update the XEN SWIOTLB SUBSYSTEM to include all swiotlb-xen
headers and replace the pattern in drivers with the specific one file that
matches this pattern.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Acked-by: Juergen Gross <jgross@suse.com>
---
v1: https://lore.kernel.org/lkml/20220601075613.28245-1-lukas.bulwahn@gmail.com/
v1 -> v2:
addressed Christoph's comment, removed arch/*/kernel/pci-swiotlb.c
added Juergen's ack
Christoph, please pick this minor non-urgent clean-up patch for swiotlb.
MAINTAINERS | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index babb441f7474..69d58c43bd6a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19699,7 +19699,6 @@ L: iommu@lists.linux.dev
S: Supported
W: http://git.infradead.org/users/hch/dma-mapping.git
T: git git://git.infradead.org/users/hch/dma-mapping.git
-F: arch/*/kernel/pci-swiotlb.c
F: include/linux/swiotlb.h
F: kernel/dma/swiotlb.c
@@ -22403,8 +22402,10 @@ M: Stefano Stabellini <sstabellini@kernel.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
L: iommu@lists.linux.dev
S: Supported
-F: arch/x86/xen/*swiotlb*
-F: drivers/xen/*swiotlb*
+F: arch/*/include/asm/xen/swiotlb-xen.h
+F: drivers/xen/swiotlb-xen.c
+F: include/xen/arm/swiotlb-xen.h
+F: include/xen/swiotlb-xen.h
XFS FILESYSTEM
C: irc://irc.oftc.net/xfs
--
2.17.1
^ permalink raw reply related [relevance 14%]
* Undeliverable: looking for agent/distributor/whole seller in every country. òøÎòìÕ×
[not found] <57FE55D35BCEFA4A7BA648A7E2564770@lists.linux.dev>
@ 2022-09-10 1:05 14% ` postmaster
0 siblings, 0 replies; 200+ results
From: postmaster @ 2022-09-10 1:05 UTC (permalink / raw)
To: nvdimm
[-- Attachment #1.1: Type: text/plain, Size: 8890 bytes --]
[https://products.office.com/en-us/CMSImages/Office365Logo_Orange.png?version=b8d100a9-0a8b-8e6a-88e1-ef488fee0470]
Your message to info@morgansolicitors.com couldn't be delivered.
info wasn't found at morgansolicitors.com.
nvdimm Office 365 info
Action Required Recipient
Unknown To address
How to Fix It
The address may be misspelled or may not exist. Try one or more of the following:
* Send the message again following these steps: In Outlook, open this non-delivery report (NDR) and choose Send Again from the Report ribbon. In Outlook on the web, select this NDR, then select the link "To send this message again, click here." Then delete and retype the entire recipient address. If prompted with an Auto-Complete List suggestion don't select it. After typing the complete address, click Send.
* Contact the recipient (by phone, for example) to check that the address exists and is correct.
* The recipient may have set up email forwarding to an incorrect address. Ask them to check that any forwarding they've set up is working correctly.
* Clear the recipient Auto-Complete List in Outlook or Outlook on the web by following the steps in this article: Fix email delivery issues for error code 5.1.10 in Office 365<https://go.microsoft.com/fwlink/?LinkId=532972>, and then send the message again. Retype the entire recipient address before selecting Send.
If the problem continues, forward this message to your email admin. If you're an email admin, refer to the More Info for Email Admins section below.
Was this helpful? Send feedback to Microsoft<https://go.microsoft.com/fwlink/?LinkId=525921>.
________________________________
More Info for Email Admins
Status code: 550 5.1.10
This error occurs because the sender sent a message to an email address hosted by Office 365 but the address is incorrect or doesn't exist at the destination domain. The error is reported by the recipient domain's email server, but most often it must be fixed by the person who sent the message. If the steps in the How to Fix It section above don't fix the problem, and you're the email admin for the recipient, try one or more of the following:
The email address exists and is correct - Confirm that the recipient address exists, is correct, and is accepting messages.
Synchronize your directories - If you have a hybrid environment and are using directory synchronization make sure the recipient's email address is synced correctly in both Office 365 and in your on-premises directory.
Errant forwarding rule - Check for forwarding rules that aren't behaving as expected. Forwarding can be set up by an admin via mail flow rules or mailbox forwarding address settings, or by the recipient via the Inbox Rules feature.
Recipient has a valid license - Make sure the recipient has an Office 365 license assigned to them. The recipient's email admin can use the Office 365 admin center to assign a license (Users > Active Users > select the recipient > Assigned License > Edit).
Mail flow settings and MX records are not correct - Misconfigured mail flow or MX record settings can cause this error. Check your Office 365 mail flow settings to make sure your domain and any mail flow connectors are set up correctly. Also, work with your domain registrar to make sure the MX records for your domain are configured correctly.
For more information and additional tips to fix this issue, see Fix email delivery issues for error code 5.1.10 in Office 365<https://go.microsoft.com/fwlink/?LinkId=532972>.
Original Message Details
Created Date: 9/10/2022 1:05:09 AM
Sender Address: nvdimm@lists.linux.dev
Recipient Address: info@morgansolicitors.com
Subject: looking for agent/distributor/whole seller in every country. òøÎòìÕ×
Error Details
Reported error: 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient info@morgansolicitors.com not found by SMTP address lookup
DSN generated by: AM7PR02MB5846.eurprd02.prod.outlook.com
Message Hops
HOP TIME (UTC) FROM TO WITH RELAY TIME
1 9/10/2022
1:05:05 AM lists.linux.dev mx-inbound22-18.eu-west-2b.ess.aws.cudaops.com *
2 9/10/2022
1:05:14 AM egress-ip15b.ess.uk.barracuda.com VE1EUR03FT013.mail.protection.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 9 sec
3 9/10/2022
1:05:15 AM VE1EUR03FT013.eop-EUR03.prod.protection.outlook.com AS9PR06CA0769.outlook.office365.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 1 sec
4 9/10/2022
1:05:15 AM AS9PR06CA0769.eurprd06.prod.outlook.com AM7PR02MB5846.eurprd02.prod.outlook.com Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) *
Original Message Headers
Received: from AS9PR06CA0769.eurprd06.prod.outlook.com (2603:10a6:20b:484::24)
by AM7PR02MB5846.eurprd02.prod.outlook.com (2603:10a6:20b:107::10) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.19; Sat, 10 Sep
2022 01:05:15 +0000
Received: from VE1EUR03FT013.eop-EUR03.prod.protection.outlook.com
(2603:10a6:20b:484:cafe::cb) by AS9PR06CA0769.outlook.office365.com
(2603:10a6:20b:484::24) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.13 via Frontend
Transport; Sat, 10 Sep 2022 01:05:15 +0000
Authentication-Results: spf=softfail (sender IP is 35.176.92.116)
smtp.mailfrom=lists.linux.dev; dkim=none (message not signed)
header.d=none;dmarc=fail action=none header.from=lists.linux.dev;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
lists.linux.dev discourages use of 35.176.92.116 as permitted sender)
Received: from egress-ip15b.ess.uk.barracuda.com (35.176.92.116) by
VE1EUR03FT013.mail.protection.outlook.com (10.152.19.37) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.5612.13 via Frontend Transport; Sat, 10 Sep 2022 01:05:14 +0000
Received: from lists.linux.dev (unknown [115.209.79.125]) by mx-inbound22-18.eu-west-2b.ess.aws.cudaops.com; Sat, 10 Sep 2022 01:05:05 +0000
From: "zH1S93" <nvdimm@lists.linux.dev>
Subject: looking for agent/distributor/whole seller in every country.
=?UTF-8?B?w7LDuMOOw7LDrMOVw5c=?=
To: "info" <info@morgansolicitors.com>
Content-Type: multipart/mixed; charset=UTF-8; boundary="7dpnHqF=_TTs28HAZMqJHUgQnODRifOame"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: xmwa9257@21cn.com
Date: Sat, 10 Sep 2022 09:05:09 +0800
Message-ID: <57FE55D35BCEFA4A7BA648A7E2564770@lists.linux.dev>
X-Mailer: DM Pro6 [GB - 6.2.5.18]
X-BESS-ID: 1662771905-205650-5378-26572-1
X-BESS-VER: 2019.1_20220817.2044
X-BESS-Apparent-Source-IP: 115.209.79.125
X-BESS-Spam-Status: SCORE=2.60 using account:ESS152179 scores of QUARANTINE_LEVEL=5.0 KILL_LEVEL=0.0 tests=HTML_IMAGE_ONLY_04_2, HTML_MESSAGE, HTML_IMAGE_ONLY_04, BSF_SC0_SA453_SF_RN, MIME_HTML_ONLY, BSF_SC0_SA912_RP_FR, MPART_ALT_DIFF, RDNS_NONE, BSF_SPF_SOFTFAIL
Received-SPF: softfail (mx-inbound22-18.eu-west-2b.ess.aws.cudaops.com: domain of transitioning nvdimm@lists.linux.dev does not designate 115.209.79.125 as permitted sender)
X-BESS-Spam-Report: Code version 3.2, rules version 3.2.2.242684 [from cloudscan13-
152.eu-west-2a.ess.aws.cudaops.com]
Rule breakdown below
pts rule name description
---- ---------------------- --------------------------------
0.34 HTML_IMAGE_ONLY_04_2 META: HTML: images with 0-400 bytes of words
0.00 HTML_MESSAGE BODY: HTML included in message
0.00 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words
2.00 BSF_SC0_SA453_SF_RN META: Custom Rule SA453_SF_RN
0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.01 BSF_SC0_SA912_RP_FR META: Custom Rule BSF_SC0_SA912_RP_FR
0.14 MPART_ALT_DIFF BODY: HTML and text parts are different
0.10 RDNS_NONE META: Delivered to trusted network by a host with no rDNS
0.00 BSF_SPF_SOFTFAIL META: Custom Rule SPF Softfail
X-BESS-Spam-Score: 2.60
X-BESS-BRTS-Status: 1
Return-Path: nvdimm@lists.linux.dev
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: d5e77ab3-cbed-479e-b95f-01b6598d5f12:0
X-Matching-Connectors: 133072455151202128;(a2d90363-ffe5-4c65-4bdc-08d63ff0702e,7a092ad1-dce9-46e5-b6e2-08d84dd689e1,ca32cd50-f792-469f-8107-08d481decdc1,2a0acee6-7994-4830-10da-08d97dcc90cd);()
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VE1EUR03FT013:EE_|AM7PR02MB5846:EE_
X-MS-Office365-Filtering-Correlation-Id: 75aa7411-7259-4688-630d-08da92c8851f
[-- Attachment #1.2: Type: text/html, Size: 33802 bytes --]
[-- Attachment #2: Type: message/delivery-status, Size: 399 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 143891 bytes --]
From: "zH1S93" <nvdimm@lists.linux.dev>
To: "info" <info@morgansolicitors.com>
Subject: looking for agent/distributor/whole seller in every country. òøÎòìÕ×
Date: Sat, 10 Sep 2022 09:05:09 +0800
Message-ID: <57FE55D35BCEFA4A7BA648A7E2564770@lists.linux.dev>
[-- Attachment #3.1.1.1: Type: text/html, Size: 223 bytes --]
[-- Attachment #3.1.2: i481.jpg --]
[-- Type: application/octet-stream, Size: 103070 bytes --]
^ permalink raw reply [relevance 14%]
* + maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch added to mm-hotfixes-unstable branch
@ 2024-03-19 20:34 15% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-03-19 20:34 UTC (permalink / raw)
To: mm-commits, msakai, jserv, dm-devel, visitorckw, akpm
The patch titled
Subject: MAINTAINERS: remove incorrect M: tag for dm-devel@lists.linux.dev
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Kuan-Wei Chiu <visitorckw@gmail.com>
Subject: MAINTAINERS: remove incorrect M: tag for dm-devel@lists.linux.dev
Date: Wed, 20 Mar 2024 02:18:42 +0800
The dm-devel@lists.linux.dev mailing list should only be listed under the
L: (List) tag in the MAINTAINERS file. However, it was incorrectly listed
under both L: and M: (Maintainers) tags, which is not accurate. Remove
the M: tag for dm-devel@lists.linux.dev in the MAINTAINERS file to reflect
the correct categorization.
Link: https://lkml.kernel.org/r/20240319181842.249547-1-visitorckw@gmail.com
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Cc: Ching-Chun (Jim) Huang <jserv@ccns.ncku.edu.tw>
Cc: Matthew Sakai <msakai@redhat.com>
Cc: Michael Sclafani <dm-devel@lists.linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
--- a/MAINTAINERS~maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev
+++ a/MAINTAINERS
@@ -6159,7 +6159,6 @@ F: include/uapi/linux/dm-*.h
DEVICE-MAPPER VDO TARGET
M: Matthew Sakai <msakai@redhat.com>
-M: dm-devel@lists.linux.dev
L: dm-devel@lists.linux.dev
S: Maintained
F: Documentation/admin-guide/device-mapper/vdo*.rst
_
Patches currently in -mm which might be from visitorckw@gmail.com are
maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch
^ permalink raw reply [relevance 15%]
* [PATCH] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list
@ 2022-01-26 22:22 15% Benson Leung
2022-01-27 16:44 9% ` Benson Leung
0 siblings, 1 reply; 200+ results
From: Benson Leung @ 2022-01-26 22:22 UTC (permalink / raw)
To: chrome-platform; +Cc: linux-kernel, bleung, bleung, pmalani
Signed-off-by: Benson Leung <bleung@chromium.org>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..cad7b0fff9f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4537,6 +4537,7 @@ F: drivers/input/touchscreen/chipone_icn8505.c
CHROME HARDWARE PLATFORM SUPPORT
M: Benson Leung <bleung@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
F: drivers/platform/chrome/
@@ -4544,6 +4545,7 @@ F: drivers/platform/chrome/
CHROMEOS EC CODEC DRIVER
M: Cheng-Yi Chiang <cychiang@chromium.org>
R: Guenter Roeck <groeck@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
F: sound/soc/codecs/cros_ec_codec.*
@@ -4551,6 +4553,7 @@ F: sound/soc/codecs/cros_ec_codec.*
CHROMEOS EC SUBDRIVERS
M: Benson Leung <bleung@chromium.org>
R: Guenter Roeck <groeck@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: drivers/power/supply/cros_usbpd-charger.c
N: cros_ec
@@ -4558,11 +4561,13 @@ N: cros-ec
CHROMEOS EC USB TYPE-C DRIVER
M: Prashant Malani <pmalani@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: drivers/platform/chrome/cros_ec_typec.c
CHROMEOS EC USB PD NOTIFY DRIVER
M: Prashant Malani <pmalani@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: drivers/platform/chrome/cros_usbpd_notify.c
F: include/linux/platform_data/cros_usbpd_notify.h
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related [relevance 15%]
* [PATCH] MAINTAINERS: move the staging subsystem to lists.linux.dev
@ 2021-03-16 10:23 15% ` gregkh
0 siblings, 0 replies; 200+ results
From: gregkh @ 2021-03-16 10:23 UTC (permalink / raw)
To: linux-staging, devel
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, linux-kernel
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The drivers/staging/ tree has a new mailing list,
linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
it so that we get patches sent to the proper place.
There was no need to specify a list for the hikey9xx driver, the tools
pick up the "base" list for drivers/staging/* so remove that line to
make the file simpler.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d7c25c0fc08a..9e876927c60d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8116,7 +8116,6 @@ F: drivers/crypto/hisilicon/sec2/sec_main.c
HISILICON STAGING DRIVERS FOR HIKEY 960/970
M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-L: devel@driverdev.osuosl.org
S: Maintained
F: drivers/staging/hikey9xx/
@@ -17040,7 +17039,7 @@ F: drivers/staging/vt665?/
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: devel@driverdev.osuosl.org
+L: linux-staging@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
F: drivers/staging/
--
2.30.2
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply related [relevance 15%]
* [PATCH 5.11 115/120] MAINTAINERS: move the staging subsystem to lists.linux.dev
@ 2021-03-22 12:28 15% ` Greg Kroah-Hartman
0 siblings, 0 replies; 200+ results
From: Greg Kroah-Hartman @ 2021-03-22 12:28 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mauro Carvalho Chehab
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e06da9ea3e3f6746a849edeae1d09ee821f5c2ce upstream.
The drivers/staging/ tree has a new mailing list,
linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
it so that we get patches sent to the proper place.
There was no need to specify a list for the hikey9xx driver, the tools
pick up the "base" list for drivers/staging/* so remove that line to
make the file simpler.
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8079,7 +8079,6 @@ F: drivers/crypto/hisilicon/sec2/sec_mai
HISILICON STAGING DRIVERS FOR HIKEY 960/970
M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-L: devel@driverdev.osuosl.org
S: Maintained
F: drivers/staging/hikey9xx/
@@ -16911,7 +16910,7 @@ F: drivers/staging/vt665?/
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: devel@driverdev.osuosl.org
+L: linux-staging@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
F: drivers/staging/
^ permalink raw reply [relevance 15%]
* [PATCH 5.10 152/157] MAINTAINERS: move the staging subsystem to lists.linux.dev
@ 2021-03-22 12:28 15% ` Greg Kroah-Hartman
0 siblings, 0 replies; 200+ results
From: Greg Kroah-Hartman @ 2021-03-22 12:28 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mauro Carvalho Chehab
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e06da9ea3e3f6746a849edeae1d09ee821f5c2ce upstream.
The drivers/staging/ tree has a new mailing list,
linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
it so that we get patches sent to the proper place.
There was no need to specify a list for the hikey9xx driver, the tools
pick up the "base" list for drivers/staging/* so remove that line to
make the file simpler.
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8001,7 +8001,6 @@ F: drivers/crypto/hisilicon/sec2/sec_mai
HISILICON STAGING DRIVERS FOR HIKEY 960/970
M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-L: devel@driverdev.osuosl.org
S: Maintained
F: drivers/staging/hikey9xx/
@@ -16665,7 +16664,7 @@ F: drivers/staging/vt665?/
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: devel@driverdev.osuosl.org
+L: linux-staging@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
F: drivers/staging/
^ permalink raw reply [relevance 15%]
* [PATCH] MAINTAINERS: move the staging subsystem to lists.linux.dev
@ 2021-03-16 10:23 15% ` gregkh
0 siblings, 0 replies; 200+ results
From: gregkh @ 2021-03-16 10:23 UTC (permalink / raw)
To: linux-staging, devel
Cc: linux-kernel, Mauro Carvalho Chehab, Greg Kroah-Hartman
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The drivers/staging/ tree has a new mailing list,
linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to
it so that we get patches sent to the proper place.
There was no need to specify a list for the hikey9xx driver, the tools
pick up the "base" list for drivers/staging/* so remove that line to
make the file simpler.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d7c25c0fc08a..9e876927c60d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8116,7 +8116,6 @@ F: drivers/crypto/hisilicon/sec2/sec_main.c
HISILICON STAGING DRIVERS FOR HIKEY 960/970
M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-L: devel@driverdev.osuosl.org
S: Maintained
F: drivers/staging/hikey9xx/
@@ -17040,7 +17039,7 @@ F: drivers/staging/vt665?/
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: devel@driverdev.osuosl.org
+L: linux-staging@lists.linux.dev
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
F: drivers/staging/
--
2.30.2
^ permalink raw reply related [relevance 15%]
* [PATCH 4/9] mm/damon/dbgfs: make debugfs interface deprecation message a macro
@ 2024-01-30 1:35 15% ` SeongJae Park
2024-01-30 1:35 12% ` [PATCH 5/9] Docs/admin-guide/mm/damon/usage: document 'DEPRECATED' file of DAMON debugfs interface SeongJae Park
1 sibling, 0 replies; 200+ results
From: SeongJae Park @ 2024-01-30 1:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: SeongJae Park, damon, linux-mm, linux-kernel
DAMON debugfs interface deprecation message is written twice, once for
the warning, and again for DEPRECATED file's read output. De-duplicate
those by defining the message as a macro and reuse.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
mm/damon/dbgfs.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c
index fc6ece5a9f37..fbc0cd63f34c 100644
--- a/mm/damon/dbgfs.c
+++ b/mm/damon/dbgfs.c
@@ -15,6 +15,11 @@
#include <linux/page_idle.h>
#include <linux/slab.h>
+#define DAMON_DBGFS_DEPRECATION_NOTICE \
+ "DAMON debugfs interface is deprecated, so users should move " \
+ "to DAMON_SYSFS. If you cannot, please report your usecase to " \
+ "damon@lists.linux.dev and linux-mm@kvack.org.\n"
+
static struct damon_ctx **dbgfs_ctxs;
static int dbgfs_nr_ctxs;
static struct dentry **dbgfs_dirs;
@@ -22,10 +27,7 @@ static DEFINE_MUTEX(damon_dbgfs_lock);
static void damon_dbgfs_warn_deprecation(void)
{
- pr_warn_once("DAMON debugfs interface is deprecated, "
- "so users should move to DAMON_SYSFS. If you cannot, "
- "please report your usecase to damon@lists.linux.dev and "
- "linux-mm@kvack.org.\n");
+ pr_warn_once(DAMON_DBGFS_DEPRECATION_NOTICE);
}
/*
@@ -808,10 +810,7 @@ static void dbgfs_destroy_ctx(struct damon_ctx *ctx)
static ssize_t damon_dbgfs_deprecated_read(struct file *file,
char __user *buf, size_t count, loff_t *ppos)
{
- char kbuf[512] = "DAMON debugfs interface is deprecated, "
- "so users should move to DAMON_SYSFS. If you cannot, "
- "please report your usecase to damon@lists.linux.dev and "
- "linux-mm@kvack.org.\n";
+ char kbuf[512] = DAMON_DBGFS_DEPRECATION_NOTICE;
int len = strnlen(kbuf, 1024);
return simple_read_from_buffer(buf, count, ppos, kbuf, len);
--
2.39.2
^ permalink raw reply related [relevance 15%]
* [merged mm-hotfixes-stable] maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch removed from -mm tree
@ 2024-03-26 18:08 16% Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2024-03-26 18:08 UTC (permalink / raw)
To: mm-commits, msakai, jserv, dm-devel, visitorckw, akpm
The quilt patch titled
Subject: MAINTAINERS: remove incorrect M: tag for dm-devel@lists.linux.dev
has been removed from the -mm tree. Its filename was
maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Kuan-Wei Chiu <visitorckw@gmail.com>
Subject: MAINTAINERS: remove incorrect M: tag for dm-devel@lists.linux.dev
Date: Wed, 20 Mar 2024 02:18:42 +0800
The dm-devel@lists.linux.dev mailing list should only be listed under the
L: (List) tag in the MAINTAINERS file. However, it was incorrectly listed
under both L: and M: (Maintainers) tags, which is not accurate. Remove
the M: tag for dm-devel@lists.linux.dev in the MAINTAINERS file to reflect
the correct categorization.
Link: https://lkml.kernel.org/r/20240319181842.249547-1-visitorckw@gmail.com
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Cc: Ching-Chun (Jim) Huang <jserv@ccns.ncku.edu.tw>
Cc: Matthew Sakai <msakai@redhat.com>
Cc: Michael Sclafani <dm-devel@lists.linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
--- a/MAINTAINERS~maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev
+++ a/MAINTAINERS
@@ -6173,7 +6173,6 @@ F: include/uapi/linux/dm-*.h
DEVICE-MAPPER VDO TARGET
M: Matthew Sakai <msakai@redhat.com>
-M: dm-devel@lists.linux.dev
L: dm-devel@lists.linux.dev
S: Maintained
F: Documentation/admin-guide/device-mapper/vdo*.rst
_
Patches currently in -mm which might be from visitorckw@gmail.com are
^ permalink raw reply [relevance 16%]
* [PATCH] MAINTAINERS: update Allwinner sunXi SoC support entry
@ 2023-02-08 14:28 16% ` Trevor Woerner
0 siblings, 0 replies; 200+ results
From: Trevor Woerner @ 2023-02-08 14:28 UTC (permalink / raw)
To: linux-kernel, Paul Walmsley, Palmer Dabbelt, Albert Ou; +Cc: linux-riscv
Update the information in the "Allwinner sunXi SoC support" block:
- include more RISC-V information
- move the block to keep it in alphabetical order
- "L" before "T" (as reported by checkpatch.pl)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
MAINTAINERS | 36 +++++++++++++++++++-----------------
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b8ad844bca77..ff39d34cb4ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1856,23 +1856,6 @@ M: Emilio López <emilio@elopez.com.ar>
S: Maintained
F: drivers/clk/sunxi/
-ARM/Allwinner sunXi SoC support
-M: Chen-Yu Tsai <wens@csie.org>
-M: Jernej Skrabec <jernej.skrabec@gmail.com>
-M: Samuel Holland <samuel@sholland.org>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
-L: linux-sunxi@lists.linux.dev
-F: arch/arm/mach-sunxi/
-F: arch/arm64/boot/dts/allwinner/
-F: drivers/clk/sunxi-ng/
-F: drivers/pinctrl/sunxi/
-F: drivers/soc/sunxi/
-N: allwinner
-N: sun[x456789]i
-N: sun[25]0i
-
ARM/Amlogic Meson SoC CLOCK FRAMEWORK
M: Neil Armstrong <neil.armstrong@linaro.org>
M: Jerome Brunet <jbrunet@baylibre.com>
@@ -2620,6 +2603,25 @@ F: arch/arm/boot/dts/rtd*
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
+ARM/RISC-V/Allwinner sunXi SoC support
+M: Chen-Yu Tsai <wens@csie.org>
+M: Jernej Skrabec <jernej.skrabec@gmail.com>
+M: Samuel Holland <samuel@sholland.org>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-riscv@lists.infradead.org
+L: linux-sunxi@lists.linux.dev
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
+F: arch/arm/mach-sunxi/
+F: arch/arm64/boot/dts/allwinner/
+F: arch/riscv/boot/dts/allwinner/
+F: drivers/clk/sunxi-ng/
+F: drivers/pinctrl/sunxi/
+F: drivers/soc/sunxi/
+N: allwinner
+N: sun[x456789]i
+N: sun[25]0i
+
ARM/RISC-V/RENESAS ARCHITECTURE
M: Geert Uytterhoeven <geert+renesas@glider.be>
M: Magnus Damm <magnus.damm@gmail.com>
--
2.36.0.rc2.17.g4027e30c53
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [relevance 16%]
* [PATCH] MAINTAINERS: update Allwinner sunXi SoC support entry
@ 2023-02-08 14:28 16% ` Trevor Woerner
0 siblings, 0 replies; 200+ results
From: Trevor Woerner @ 2023-02-08 14:28 UTC (permalink / raw)
To: linux-kernel, Paul Walmsley, Palmer Dabbelt, Albert Ou; +Cc: linux-riscv
Update the information in the "Allwinner sunXi SoC support" block:
- include more RISC-V information
- move the block to keep it in alphabetical order
- "L" before "T" (as reported by checkpatch.pl)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
MAINTAINERS | 36 +++++++++++++++++++-----------------
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b8ad844bca77..ff39d34cb4ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1856,23 +1856,6 @@ M: Emilio López <emilio@elopez.com.ar>
S: Maintained
F: drivers/clk/sunxi/
-ARM/Allwinner sunXi SoC support
-M: Chen-Yu Tsai <wens@csie.org>
-M: Jernej Skrabec <jernej.skrabec@gmail.com>
-M: Samuel Holland <samuel@sholland.org>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
-L: linux-sunxi@lists.linux.dev
-F: arch/arm/mach-sunxi/
-F: arch/arm64/boot/dts/allwinner/
-F: drivers/clk/sunxi-ng/
-F: drivers/pinctrl/sunxi/
-F: drivers/soc/sunxi/
-N: allwinner
-N: sun[x456789]i
-N: sun[25]0i
-
ARM/Amlogic Meson SoC CLOCK FRAMEWORK
M: Neil Armstrong <neil.armstrong@linaro.org>
M: Jerome Brunet <jbrunet@baylibre.com>
@@ -2620,6 +2603,25 @@ F: arch/arm/boot/dts/rtd*
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
+ARM/RISC-V/Allwinner sunXi SoC support
+M: Chen-Yu Tsai <wens@csie.org>
+M: Jernej Skrabec <jernej.skrabec@gmail.com>
+M: Samuel Holland <samuel@sholland.org>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-riscv@lists.infradead.org
+L: linux-sunxi@lists.linux.dev
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
+F: arch/arm/mach-sunxi/
+F: arch/arm64/boot/dts/allwinner/
+F: arch/riscv/boot/dts/allwinner/
+F: drivers/clk/sunxi-ng/
+F: drivers/pinctrl/sunxi/
+F: drivers/soc/sunxi/
+N: allwinner
+N: sun[x456789]i
+N: sun[25]0i
+
ARM/RISC-V/RENESAS ARCHITECTURE
M: Geert Uytterhoeven <geert+renesas@glider.be>
M: Magnus Damm <magnus.damm@gmail.com>
--
2.36.0.rc2.17.g4027e30c53
^ permalink raw reply related [relevance 16%]
* Undelivered Mail Returned to Sender
@ 2022-08-29 11:30 16% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2022-08-29 11:30 UTC (permalink / raw)
To: ksummit
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 714 bytes --]
This message is generated by xinnetmail
您收到的是来自新网专业邮件系统的信件.
非常抱歉通知您，这封信无法投递到对方。请看附件，如需更多帮助，请联系管理员。
为了提高处理效率，您可以将此退信，作为附件的形式转发给系统管理员，谢谢！
This is the mail system at host mxf.global-mail.cn.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
错误如下：
<sales@yxhuawei.com>: host 58.221.79.22[58.221.79.22] said: 550 no such user
here (umail mta) (in reply to RCPT TO command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 386 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 1094 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 15 bytes --]
From: "vhJ8A" <ksummit@lists.linux.dev>
To: "sales" <sales@yxhuawei.com>
Subject: 85520
Date: Mon, 29 Aug 2022 19:30:17 +0800
Message-ID: <202208291930104817545@lists.linux.dev>
^ permalink raw reply [relevance 16%]
* Returned mail: see transcript for details
@ 2022-08-27 21:03 17% Mail Delivery Subsystem
0 siblings, 0 replies; 200+ results
From: Mail Delivery Subsystem @ 2022-08-27 21:03 UTC (permalink / raw)
To: linux-coco
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
The original message was received at Sat, 27 Aug 2022 21:03:14 GMT
from m0074417.ppops.net [127.0.0.1]
----- The following addresses had permanent fatal errors -----
<pelcoservice-shanghai@pelco.com>
(reason: 550-5.1.1 The email account that you tried to reach does not exist. Please try)
----- Transcript of session follows -----
... while talking to aspmx.l.google.com.:
>>> DATA
<<< 550-5.1.1 The email account that you tried to reach does not exist. Please try
<<< 550-5.1.1 double-checking the recipient's email address for typos or
<<< 550-5.1.1 unnecessary spaces. Learn more at
<<< 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser y195-20020a814bcc000000b00340c82a1872si1084437ywa.317 - gsmtp
550 5.1.1 <pelcoservice-shanghai@pelco.com>... User unknown
<<< 503 5.5.1 RCPT first. y195-20020a814bcc000000b00340c82a1872si1084437ywa.317 - gsmtp
[-- Attachment #2: Type: message/delivery-status, Size: 468 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 6231 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 3117 bytes --]
From: "4C9f00e" <linux-coco@lists.linux.dev>
To: "PelcoService-Shanghai" <PelcoService-Shanghai@pelco.com>
Date: Sun, 28 Aug 2022 05:03:14 +0800
Message-ID: <202208280503119295000@lists.linux.dev>
^ permalink raw reply [relevance 17%]
* Non recapitabile: 帮助外贸人快速找到客户源\uC3D6\uCE56\uB745\uC99D\uBA8C\uC823\uB9DE\uCC80
[not found] <202210130337302514010@lists.linux.dev>
@ 2022-10-12 19:37 17% ` postmaster
0 siblings, 0 replies; 200+ results
From: postmaster @ 2022-10-12 19:37 UTC (permalink / raw)
To: linux-coco
[-- Attachment #1.1: Type: text/plain, Size: 402 bytes --]
Il recapito non è riuscito per i seguenti destinatari o gruppi:
feedback (feedback@comune.brisighella.ra.it)<mailto:feedback@comune.brisighella.ra.it>
L'indirizzo di posta elettronica specificato non è stato trovato. Verifica l'indirizzo di posta elettronica del destinatario e prova a inviare di nuovo il messaggio. Se il problema persiste, contatta l'amministratore della posta elettronica.
[-- Attachment #1.2: Type: text/html, Size: 705 bytes --]
[-- Attachment #2: Type: message/delivery-status, Size: 428 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 1385 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 323 bytes --]
From: 74THa8E <linux-coco@lists.linux.dev>
To: feedback <feedback@comune.brisighella.ra.it>
Subject: 帮助外贸人快速找到客户源\uC3D6\uCE56\uB745\uC99D\uBA8C\uC823\uB9DE\uCC80
Date: Thu, 13 Oct 2022 03:37:42 +0800
Message-ID: <202210130337302514010@lists.linux.dev>
^ permalink raw reply [relevance 17%]
* [PATCH] MAINTAINERS: Add chrome-platform@lists.linux.dev to all Chrome OS entries
@ 2022-03-16 18:49 17% Guenter Roeck
0 siblings, 0 replies; 200+ results
From: Guenter Roeck @ 2022-03-16 18:49 UTC (permalink / raw)
To: chrome-platform; +Cc: Benson Leung, Guenter Roeck, Rajat Jain
Add the chrome-platform@lists.linux.dev mailing list to all Chrome OS
maintainer entries to ensure that people copy the list when submitting
Chrome OS specific patches. This also helps ensuring that patches are
available in a patchwork instance.
Cc: Benson Leung <bleung@chromium.org>
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e127c2fb08a7..bc275698e7c2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4541,6 +4541,7 @@ F: drivers/input/touchscreen/chipone_icn8505.c
CHROME HARDWARE PLATFORM SUPPORT
M: Benson Leung <bleung@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
F: drivers/platform/chrome/
@@ -4549,6 +4550,7 @@ CHROMEOS EC CODEC DRIVER
M: Cheng-Yi Chiang <cychiang@chromium.org>
M: Tzung-Bi Shih <tzungbi@google.com>
R: Guenter Roeck <groeck@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
F: sound/soc/codecs/cros_ec_codec.*
@@ -4556,6 +4558,7 @@ F: sound/soc/codecs/cros_ec_codec.*
CHROMEOS EC SUBDRIVERS
M: Benson Leung <bleung@chromium.org>
R: Guenter Roeck <groeck@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: drivers/power/supply/cros_usbpd-charger.c
N: cros_ec
@@ -4563,11 +4566,13 @@ N: cros-ec
CHROMEOS EC USB TYPE-C DRIVER
M: Prashant Malani <pmalani@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: drivers/platform/chrome/cros_ec_typec.c
CHROMEOS EC USB PD NOTIFY DRIVER
M: Prashant Malani <pmalani@chromium.org>
+L: chrome-platform@lists.linux.dev
S: Maintained
F: drivers/platform/chrome/cros_usbpd_notify.c
F: include/linux/platform_data/cros_usbpd_notify.h
--
2.35.1
^ permalink raw reply related [relevance 17%]
* Mail delivery failed: returning message to sender
[not found] <625918748262f@lists.linux.dev>
@ 2022-04-20 8:14 19% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2022-04-20 8:14 UTC (permalink / raw)
To: chrome-platform
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
info@mt.lr-dev.com
host mt.lr-dev.com [51.89.228.47]
SMTP error from remote mail server after initial connection:
451 Temporary local problem - please try later:
retry timeout exceeded
jeca@logicreplace.com
host _dc-mx.5bf3870e7dde.logicreplace.com [109.203.109.139]
SMTP error from remote mail server after initial connection:
451 Temporary local problem - please try later:
retry timeout exceeded
[-- Attachment #2: Type: message/delivery-status, Size: 473 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 1489 bytes --]
From: <chrome-platform@lists.linux.dev>
To: info@mt.lr-dev.com, jeca@logicreplace.com
Subject: FW: [#15451]:
Date: Fri, 15 Apr 2022 08:02:12 +0100
Message-ID: <625918748262f@lists.linux.dev>
A web form was submitted on MotocrossTracks.com.
---------------------------------------------
Dear 💛 Have you ever tried this sex game before? GIVE IT A TRY:
https://cutt.us/2tLQy?0tb 💛,
Thank you for making contact MotocrossTracks.com. We will respond as soon as
possible.
Ticket ID: 15451
Subject: Contact
Name: 💛 Have you ever tried this sex game before? GIVE IT A TRY:
https://cutt.us/2tLQy?0tb 💛
Email: chrome-platform@lists.linux.dev
Phone Number: 911160405701
Message:
---------------------------------------------
vtjhkh
---------------------------------------------
Thank you,
MotocrossTracks.com
http://www.motocrosstracks.com
^ permalink raw reply [relevance 19%]
* Mail delivery failed: returning message to sender
[not found] <20230814091553.68398532BA78381E@lists.linux.dev>
@ 2023-08-14 8:15 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 8:15 UTC (permalink / raw)
To: damon
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
damon@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 216 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3164 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2342 bytes --]
From: lists.linux.devAdministrator<damon@lists.linux.dev>
To: damon@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 09:15:53 +0100
Message-ID: <20230814091553.68398532BA78381E@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814093047.3B521F5FA66C0D10@lists.linux.dev>
@ 2023-08-14 8:30 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 8:30 UTC (permalink / raw)
To: fsverity
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
fsverity@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 219 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3197 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2360 bytes --]
From: lists.linux.devAdministrator<fsverity@lists.linux.dev>
To: fsverity@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 09:30:47 +0100
Message-ID: <20230814093047.3B521F5FA66C0D10@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814093908.58A41D84261385F6@lists.linux.dev>
@ 2023-08-14 8:39 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 8:39 UTC (permalink / raw)
To: imx
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
imx@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 214 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3142 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2330 bytes --]
From: lists.linux.devAdministrator<imx@lists.linux.dev>
To: imx@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 09:39:08 +0100
Message-ID: <20230814093908.58A41D84261385F6@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814101407.E583F8A1584FBF9E@lists.linux.dev>
@ 2023-08-14 9:14 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:14 UTC (permalink / raw)
To: iommu
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
iommu@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 216 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3164 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2342 bytes --]
From: lists.linux.devAdministrator<iommu@lists.linux.dev>
To: iommu@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:14:07 +0100
Message-ID: <20230814101407.E583F8A1584FBF9E@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814102412.45D084CD67ABFEB1@lists.linux.dev>
@ 2023-08-14 9:24 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:24 UTC (permalink / raw)
To: kvmarm
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
kvmarm@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 217 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3175 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2348 bytes --]
From: lists.linux.devAdministrator<kvmarm@lists.linux.dev>
To: kvmarm@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:24:13 +0100
Message-ID: <20230814102412.45D084CD67ABFEB1@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814102730.62A81ABA2617AADC@lists.linux.dev>
@ 2023-08-14 9:27 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:27 UTC (permalink / raw)
To: llvm
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
llvm@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 215 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3153 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2336 bytes --]
From: lists.linux.devAdministrator<llvm@lists.linux.dev>
To: llvm@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:27:30 +0100
Message-ID: <20230814102730.62A81ABA2617AADC@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814102751.31AD0FD42294B28C@lists.linux.dev>
@ 2023-08-14 9:27 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:27 UTC (permalink / raw)
To: loongarch
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
loongarch@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 220 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3208 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2366 bytes --]
From: lists.linux.devAdministrator<loongarch@lists.linux.dev>
To: loongarch@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:27:51 +0100
Message-ID: <20230814102751.31AD0FD42294B28C@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814103628.32A9B9B6C52A1DE3@lists.linux.dev>
@ 2023-08-14 9:36 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:36 UTC (permalink / raw)
To: mhi
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
mhi@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 214 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3142 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2330 bytes --]
From: lists.linux.devAdministrator<mhi@lists.linux.dev>
To: mhi@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:36:28 +0100
Message-ID: <20230814103628.32A9B9B6C52A1DE3@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814104255.C2BBCDDA9B815FB6@lists.linux.dev>
@ 2023-08-14 9:42 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:42 UTC (permalink / raw)
To: nvdimm
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
nvdimm@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 217 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3175 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2348 bytes --]
From: lists.linux.devAdministrator<nvdimm@lists.linux.dev>
To: nvdimm@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:42:55 +0100
Message-ID: <20230814104255.C2BBCDDA9B815FB6@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814104639.54BEF81890F70DC4@lists.linux.dev>
@ 2023-08-14 9:46 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:46 UTC (permalink / raw)
To: patches
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
patches@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 218 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3186 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2354 bytes --]
From: lists.linux.devAdministrator<patches@lists.linux.dev>
To: patches@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:46:39 +0100
Message-ID: <20230814104639.54BEF81890F70DC4@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816100303.E4027DC3296C6D15@lists.linux.dev>
@ 2023-08-16 9:03 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 9:03 UTC (permalink / raw)
To: regressions
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
regressions@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 222 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3230 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2378 bytes --]
From: lists.linux.devAdministrator<regressions@lists.linux.dev>
To: regressions@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 10:03:03 +0100
Message-ID: <20230816100303.E4027DC3296C6D15@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816100304.F9930AA917EDA9DA@lists.linux.dev>
@ 2023-08-16 9:03 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 9:03 UTC (permalink / raw)
To: imx
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
imx@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 214 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3142 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2330 bytes --]
From: lists.linux.devAdministrator<imx@lists.linux.dev>
To: imx@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 10:03:04 +0100
Message-ID: <20230816100304.F9930AA917EDA9DA@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816113304.228C7B2568AFF488@lists.linux.dev>
@ 2023-08-16 10:33 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 10:33 UTC (permalink / raw)
To: nvdimm
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
nvdimm@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 217 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3175 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2348 bytes --]
From: lists.linux.devAdministrator<nvdimm@lists.linux.dev>
To: nvdimm@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 11:33:04 +0100
Message-ID: <20230816113304.228C7B2568AFF488@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816113737.044F6D5996B8EF88@lists.linux.dev>
@ 2023-08-16 10:37 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 10:37 UTC (permalink / raw)
To: loongarch
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
loongarch@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 220 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3208 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2366 bytes --]
From: lists.linux.devAdministrator<loongarch@lists.linux.dev>
To: loongarch@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 11:37:38 +0100
Message-ID: <20230816113737.044F6D5996B8EF88@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816115124.E887BBA760932448@lists.linux.dev>
@ 2023-08-16 10:51 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 10:51 UTC (permalink / raw)
To: patches
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
patches@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 218 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3186 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2354 bytes --]
From: lists.linux.devAdministrator<patches@lists.linux.dev>
To: patches@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 11:51:24 +0100
Message-ID: <20230816115124.E887BBA760932448@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816120404.72EB41734ED057E8@lists.linux.dev>
@ 2023-08-16 11:04 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 11:04 UTC (permalink / raw)
To: llvm
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
llvm@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 215 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3153 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2336 bytes --]
From: lists.linux.devAdministrator<llvm@lists.linux.dev>
To: llvm@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 12:04:04 +0100
Message-ID: <20230816120404.72EB41734ED057E8@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816120406.444E5852DC7BE3EF@lists.linux.dev>
@ 2023-08-16 11:04 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 11:04 UTC (permalink / raw)
To: asahi
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
asahi@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 216 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3164 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2342 bytes --]
From: lists.linux.devAdministrator<asahi@lists.linux.dev>
To: asahi@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 12:04:06 +0100
Message-ID: <20230816120406.444E5852DC7BE3EF@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816120531.057CDA36916887DA@lists.linux.dev>
@ 2023-08-16 11:05 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 11:05 UTC (permalink / raw)
To: kvmarm
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
kvmarm@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 217 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3175 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2348 bytes --]
From: lists.linux.devAdministrator<kvmarm@lists.linux.dev>
To: kvmarm@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 12:05:31 +0100
Message-ID: <20230816120531.057CDA36916887DA@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816120550.67970145FA271048@lists.linux.dev>
@ 2023-08-16 11:05 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 11:05 UTC (permalink / raw)
To: fsverity
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
fsverity@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 219 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3197 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2360 bytes --]
From: lists.linux.devAdministrator<fsverity@lists.linux.dev>
To: fsverity@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 12:05:50 +0100
Message-ID: <20230816120550.67970145FA271048@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816120551.D77682163964749B@lists.linux.dev>
@ 2023-08-16 11:05 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 11:05 UTC (permalink / raw)
To: iommu
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
iommu@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 216 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3164 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2342 bytes --]
From: lists.linux.devAdministrator<iommu@lists.linux.dev>
To: iommu@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 12:05:51 +0100
Message-ID: <20230816120551.D77682163964749B@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816120650.BE2BBAFE768CB5F4@lists.linux.dev>
@ 2023-08-16 11:06 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 11:06 UTC (permalink / raw)
To: mhi
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
mhi@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 214 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3142 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2330 bytes --]
From: lists.linux.devAdministrator<mhi@lists.linux.dev>
To: mhi@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 12:06:50 +0100
Message-ID: <20230816120650.BE2BBAFE768CB5F4@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* 未送达:
[not found] <644079563177$43710a80$455500b1$@lists.linux.dev>
@ 2022-07-04 17:31 20% ` postmaster
0 siblings, 0 replies; 200+ results
From: postmaster @ 2022-07-04 17:31 UTC (permalink / raw)
To: regressions
[-- Attachment #1.1: Type: text/plain, Size: 1349 bytes --]
向以下收件人或组传递邮件失败:
allen (allen@excebest.com.tw)<mailto:allen@excebest.com.tw>
找不到您输入的电子邮件地址。请检查收件人的电子邮件地址并尝试重新发送邮件。如果问题仍然存在，请与您的电子邮件管理员联系。
供管理员使用的诊断信息:
生成服务器: server.excebest.com.tw
allen@excebest.com.tw
Remote Server returned '550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup'
原始邮件头:
Received: from server.excebest.com.tw (60.249.3.158) by server.excebest.com.tw
(60.249.3.158) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Tue, 5 Jul 2022
01:31:22 +0800
Received: from lists.linux.dev (183.143.33.90) by server.excebest.com.tw
(60.249.3.158) with Microsoft SMTP Server id 15.2.1118.9 via Frontend
Transport; Tue, 5 Jul 2022 01:31:21 +0800
Thread-Index: AdW0g4iKd9u//1Dy9U69hq2QMQOTyQ==
Content-Language: zh-cn
From: "ulli@ligist.at" <regressions@lists.linux.dev>
To: allen <allen@excebest.com.tw>
Content-Type: multipart/mixed; charset="GB2312";
boundary="----=_NextPart_707_2D48_77379C37.2006A3FE"
MIME-Version: 1.0
Date: Tue, 5 Jul 2022 01:32:03 +0800
Message-ID: <644079563177$43710a80$455500b1$@lists.linux.dev>
X-Mailer: Microsoft Outlook 16.0
Return-Path: regressions@lists.linux.dev
[-- Attachment #1.2: Type: text/html, Size: 1814 bytes --]
[-- Attachment #2: Type: message/delivery-status, Size: 334 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 72097 bytes --]
From: "ulli@ligist.at" <regressions@lists.linux.dev>
To: allen <allen@excebest.com.tw>
Date: Tue, 5 Jul 2022 01:32:03 +0800
Message-ID: <644079563177$43710a80$455500b1$@lists.linux.dev>
[-- Attachment #3.1.1.1: Type: text/html, Size: 64 bytes --]
[-- Attachment #3.1.2: MiiUT.jpg --]
[-- Type: application/octet-stream, Size: 52204 bytes --]
^ permalink raw reply [relevance 20%]
* [PATCH v1] docs: reporting-issues.rst: CC subsystem and maintainers on regressions
@ 2021-04-15 10:29 20% Thorsten Leemhuis
0 siblings, 0 replies; 200+ results
From: Thorsten Leemhuis @ 2021-04-15 10:29 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel
When reporting a regression, users ideally should CC the subsystem and
its maintainers, as that will ensure they get aware of the regression
quickly. And if the culprit is known, they should also CC everyone who
signed if off; the text mentioned the latter in once place already, but
forgot to do so in two other areas where it's relevant.
While fixing this also remind readers to check the mailing list archives
for issues that need to be reported to a bug tracker, as someone might
have reported it by mail only.
All of this got triggered by a recent report where these changes would
have made a difference.
Link: https://lore.kernel.org/lkml/dff6badf-58f5-98c8-871c-94d901ac6919@leemhuis.info/
Link: https://lore.kernel.org/lkml/CAJZ5v0hX2StQVttAciHYH-urUH+Hi92z9z2ZbcNgQPt0E2Jpwg@mail.gmail.com/
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
.../admin-guide/reporting-issues.rst | 49 ++++++++++++-------
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 48b4d0ef2b09..18d8e25ba9df 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -24,7 +24,8 @@ longterm series? One still supported? Then search the `LKML
you don't find any, install `the latest release from that series
<https://kernel.org/>`_. If it still shows the issue, report it to the stable
mailing list (stable@vger.kernel.org) and CC the regressions list
-(regressions@lists.linux.dev).
+(regressions@lists.linux.dev); ideally also CC the maintainer and the mailing
+list for the subsystem in question.
In all other cases try your best guess which kernel part might be causing the
issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
@@ -48,8 +49,9 @@ before the issue occurs.
If you are facing multiple issues with the Linux kernel at once, report each
separately. While writing your report, include all information relevant to the
issue, like the kernel and the distro used. In case of a regression, CC the
-regressions mailing list (regressions@lists.linux.dev) to your report; also try
-to include the commit-id of the change causing it, which a bisection can find.
+regressions mailing list (regressions@lists.linux.dev) to your report. Also try
+to pin-point the culprit with a bisection; if you succeed, include its
+commit-id and CC everyone in the sign-off-by chain.
Once the report is out, answer any questions that come up and help where you
can. That includes keeping the ball rolling by occasionally retesting with newer
@@ -198,10 +200,11 @@ report them:
* Send a short problem report to the Linux stable mailing list
(stable@vger.kernel.org) and CC the Linux regressions mailing list
- (regressions@lists.linux.dev). Roughly describe the issue and ideally
- explain how to reproduce it. Mention the first version that shows the
- problem and the last version that's working fine. Then wait for further
- instructions.
+ (regressions@lists.linux.dev); if you suspect the cause in a particular
+ subsystem, CC its maintainer and its mailing list. Roughly describe the
+ issue and ideally explain how to reproduce it. Mention the first version
+ that shows the problem and the last version that's working fine. Then
+ wait for further instructions.
The reference section below explains each of these steps in more detail.
@@ -768,7 +771,9 @@ regular internet search engine and add something like
the results to the archives at that URL.
It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
-at this point.
+at this point. If your report needs to be filed in a bug tracker, you may want
+to check the mailing list archives for the subsystem as well, as someone might
+have reported it only there.
For details how to search and what to do if you find matching reports see
"Search for existing reports, first run" above.
@@ -1249,9 +1254,10 @@ and the oldest where the issue occurs (say 5.8-rc1).
When sending the report by mail, CC the Linux regressions mailing list
(regressions@lists.linux.dev). In case the report needs to be filed to some web
-tracker, proceed to do so; once filed, forward the report by mail to the
-regressions list. Make sure to inline the forwarded report, hence do not attach
-it. Also add a short note at the top where you mention the URL to the ticket.
+tracker, proceed to do so. Once filed, forward the report by mail to the
+regressions list; CC the maintainer and the mailing list for the subsystem in
+question. Make sure to inline the forwarded report, hence do not attach it.
+Also add a short note at the top where you mention the URL to the ticket.
When mailing or forwarding the report, in case of a successful bisection add the
author of the culprit to the recipients; also CC everyone in the signed-off-by
@@ -1536,17 +1542,20 @@ Report the regression
*Send a short problem report to the Linux stable mailing list
(stable@vger.kernel.org) and CC the Linux regressions mailing list
- (regressions@lists.linux.dev). Roughly describe the issue and ideally
- explain how to reproduce it. Mention the first version that shows the
- problem and the last version that's working fine. Then wait for further
- instructions.*
+ (regressions@lists.linux.dev); if you suspect the cause in a particular
+ subsystem, CC its maintainer and its mailing list. Roughly describe the
+ issue and ideally explain how to reproduce it. Mention the first version
+ that shows the problem and the last version that's working fine. Then
+ wait for further instructions.*
When reporting a regression that happens within a stable or longterm kernel
line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
-the start to get the issue reported quickly. Hence a rough description is all
-it takes.
+the start to get the issue reported quickly. Hence a rough description to the
+stable and regressions mailing list is all it takes; but in case you suspect
+the cause in a particular subsystem, CC its maintainers and its mailing list
+as well, because that will speed things up.
-But note, it helps developers a great deal if you can specify the exact version
+And note, it helps developers a great deal if you can specify the exact version
that introduced the problem. Hence if possible within a reasonable time frame,
try to find that version using vanilla kernels. Lets assume something broke when
your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
@@ -1563,7 +1572,9 @@ pinpoint the exact change that causes the issue (which then can easily get
reverted to fix the issue quickly). Hence consider to do a proper bisection
right away if time permits. See the section 'Special care for regressions' and
the document 'Documentation/admin-guide/bug-bisect.rst' for details how to
-perform one.
+perform one. In case of a successful bisection add the author of the culprit to
+the recipients; also CC everyone in the signed-off-by chain, which you find at
+the end of its commit message.
Reference for "Reporting issues only occurring in older kernel version lines"
base-commit: 6161a4b18a66746c3f5afa72c054d7e58e49c847
--
2.30.2
^ permalink raw reply related [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814102700.7F5D13F4B03D7D17@lists.linux.dev>
@ 2023-08-14 9:27 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:27 UTC (permalink / raw)
To: linux-coco
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
linux-coco@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 221 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3219 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2372 bytes --]
From: lists.linux.devAdministrator<linux-coco@lists.linux.dev>
To: linux-coco@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:27:00 +0100
Message-ID: <20230814102700.7F5D13F4B03D7D17@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814102704.252CCD7AE5C5FBA6@lists.linux.dev>
@ 2023-08-14 9:27 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:27 UTC (permalink / raw)
To: linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
linux-sunxi@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 222 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3230 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2378 bytes --]
From: lists.linux.devAdministrator<linux-sunxi@lists.linux.dev>
To: linux-sunxi@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:27:04 +0100
Message-ID: <20230814102704.252CCD7AE5C5FBA6@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230814102704.8CF24EB60A0CCCC4@lists.linux.dev>
@ 2023-08-14 9:27 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-14 9:27 UTC (permalink / raw)
To: linux-staging
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
linux-staging@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 224 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3254 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2390 bytes --]
From: lists.linux.devAdministrator<linux-staging@lists.linux.dev>
To: linux-staging@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 14 Aug 2023 10:27:04 +0100
Message-ID: <20230814102704.8CF24EB60A0CCCC4@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816100258.B626FAF3CD9EBBD6@lists.linux.dev>
@ 2023-08-16 9:03 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 9:03 UTC (permalink / raw)
To: linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
linux-sunxi@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 222 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3230 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2378 bytes --]
From: lists.linux.devAdministrator<linux-sunxi@lists.linux.dev>
To: linux-sunxi@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 10:02:58 +0100
Message-ID: <20230816100258.B626FAF3CD9EBBD6@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816113242.DA07B8DB3BA1A07D@lists.linux.dev>
@ 2023-08-16 10:32 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 10:32 UTC (permalink / raw)
To: linux-staging
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
linux-staging@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 224 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3254 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2390 bytes --]
From: lists.linux.devAdministrator<linux-staging@lists.linux.dev>
To: linux-staging@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 11:32:42 +0100
Message-ID: <20230816113242.DA07B8DB3BA1A07D@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* Mail delivery failed: returning message to sender
[not found] <20230816120528.99581B15228A21F9@lists.linux.dev>
@ 2023-08-16 11:05 20% ` Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2023-08-16 11:05 UTC (permalink / raw)
To: linux-coco
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
linux-coco@lists.linux.dev
host smtp.subspace.kernel.org [44.238.234.78]
SMTP error from remote mail server after end of data:
550 5.7.1 Blocked by SpamAssassin
[-- Attachment #2: Type: message/delivery-status, Size: 221 bytes --]
[-- Attachment #3: Type: message/rfc822, Size: 3219 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2372 bytes --]
From: lists.linux.devAdministrator<linux-coco@lists.linux.dev>
To: linux-coco@lists.linux.dev
Subject: ⚠️ WARNING:Some Emails Could not be delivered
Date: 16 Aug 2023 12:05:28 +0100
Message-ID: <20230816120528.99581B15228A21F9@lists.linux.dev>
^ permalink raw reply [relevance 20%]
* [ndctl PATCH v2 1/2] CONTRIBUTING.md: document cxl mailing list
@ 2023-05-31 2:24 22% Li Zhijian
0 siblings, 0 replies; 200+ results
From: Li Zhijian @ 2023-05-31 2:24 UTC (permalink / raw)
To: nvdimm; +Cc: linux-cxl, dave.jiang, Li Zhijian
Any change and question relevant to should also CC to the CXL mailing
list.
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
V2: add reviewed tag
---
CONTRIBUTING.md | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4f4865db9da4..7d1e7f64984f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -5,15 +5,21 @@ Thank you for taking the time to contribute to ndctl.
The following is a set of guidelines that we adhere to, and request that
contributors follow.
+1. **NOTE**: ndctl utils have extended to support CXL CLI, so any change
+ and question relevant to CXL should also CC to the CXL mailing list
+ **```linux-cxl@vger.kernel.org```**.
+
1. The libnvdimm (kernel subsystem) and ndctl developers primarily use
the [nvdimm](https://subspace.kernel.org/lists.linux.dev.html)
mailing list for everything. It is recommended to send patches to
- **```nvdimm@lists.linux.dev```**
- An archive is available on [lore](https://lore.kernel.org/nvdimm/)
+ **```nvdimm@lists.linux.dev```** and CC **```linux-cxl@vger.kernel.org```** if needed.
+ The archives are available on [nvdimm](https://lore.kernel.org/nvdimm/) and
+ [cxl](https://lore.kernel.org/linux-cxl/)
1. Github [issues](https://github.com/pmem/ndctl/issues) are an acceptable
way to report a problem, but if you just have a question,
- [email](mailto:nvdimm@lists.linux.dev) the above list.
+ [email](mailto:nvdimm@lists.linux.dev) the above list and CC
+ `linux-cxl@linux-cxl@vger.kernel.org` if needed.
1. We follow the Linux Kernel [Coding Style Guide][cs] as applicable.
--
2.29.2
^ permalink raw reply related [relevance 22%]
* [ndctl PATCH 1/2] CONTRIBUTING.md: document cxl mailing list
@ 2023-05-23 3:57 22% Li Zhijian
0 siblings, 0 replies; 200+ results
From: Li Zhijian @ 2023-05-23 3:57 UTC (permalink / raw)
To: nvdimm; +Cc: linux-cxl, Li Zhijian
Any change and question relevant to should also CC to the CXL mailing
list.
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
CONTRIBUTING.md | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4f4865db9da4..c5eb391122d5 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -5,15 +5,21 @@ Thank you for taking the time to contribute to ndctl.
The following is a set of guidelines that we adhere to, and request that
contributors follow.
+1. **NOTE**: ndctl utils have extended to support CXL CLI, so any change
+ and question relevant to CXL should also CC to the CXL mailing list
+ **```linux-cxl@vger.kernel.org```**.
+
1. The libnvdimm (kernel subsystem) and ndctl developers primarily use
the [nvdimm](https://subspace.kernel.org/lists.linux.dev.html)
mailing list for everything. It is recommended to send patches to
- **```nvdimm@lists.linux.dev```**
- An archive is available on [lore](https://lore.kernel.org/nvdimm/)
+ **```nvdimm@lists.linux.dev```** and CC **```linux-cxl@vger.kernel.org```** if needed.
+ The archives are available on [nvdimm](https://lore.kernel.org/nvdimm/) and
+ [cxl](https://lore.kernel.org/linux-cxl/)
1. Github [issues](https://github.com/pmem/ndctl/issues) are an acceptable
way to report a problem, but if you just have a question,
- [email](mailto:nvdimm@lists.linux.dev) the above list.
+ [email](mailto:nvdimm@lists.linux.dev) the above list and CC `linux-cxl@linux-cxl@vger.kernel.org`
+ if needed.
1. We follow the Linux Kernel [Coding Style Guide][cs] as applicable.
--
2.29.2
^ permalink raw reply related [relevance 22%]
* [PATCH] MAINTAINERS: Remove incorrect M: tag for dm-devel@lists.linux.dev
@ 2024-03-19 18:18 23% Kuan-Wei Chiu
0 siblings, 0 replies; 200+ results
From: Kuan-Wei Chiu @ 2024-03-19 18:18 UTC (permalink / raw)
To: msakai, akpm; +Cc: dm-devel, linux-kernel, jserv, Kuan-Wei Chiu
The dm-devel@lists.linux.dev mailing list should only be listed under
the L: (List) tag in the MAINTAINERS file. However, it was incorrectly
listed under both L: and M: (Maintainers) tags, which is not accurate.
Remove the M: tag for dm-devel@lists.linux.dev in the MAINTAINERS file
to reflect the correct categorization.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 82896c3e0559..e0a4e0def090 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6172,7 +6172,6 @@ F: include/uapi/linux/dm-*.h
DEVICE-MAPPER VDO TARGET
M: Matthew Sakai <msakai@redhat.com>
-M: dm-devel@lists.linux.dev
L: dm-devel@lists.linux.dev
S: Maintained
F: Documentation/admin-guide/device-mapper/vdo*.rst
--
2.34.1
^ permalink raw reply related [relevance 23%]
* Undelivered Mail Returned to Sender
@ 2021-10-15 8:31 28% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2021-10-15 8:31 UTC (permalink / raw)
To: linux-staging
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 550 bytes --]
This is the mail system at host bizcloud-send.auscott.com.au.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<linux-staging@lists.linux.dev>: host smtp.subspace.kernel.org[44.238.234.78]
said: 550 5.7.1 Blocked by SpamAssassin (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 429 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 7893 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 6986 bytes --]
From: IT HelpDesk lists.linux.dev <linux-staging@lists.linux.dev>
To: linux-staging@lists.linux.dev
Subject: Password for linux-staging@lists.linux.dev expires today 15-10-2021
Date: 15 Oct 2021 01:20:31 -0700
Message-ID: <20211015012031.8AF45A6C39D603DF@lists.linux.dev>
^ permalink raw reply [relevance 28%]
* Undelivered Mail Returned to Sender
@ 2021-10-18 16:27 28% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2021-10-18 16:27 UTC (permalink / raw)
To: linux-staging
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 554 bytes --]
This is the mail system at host bizcloud-send.saneequipments.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<linux-staging@lists.linux.dev>: host smtp.subspace.kernel.org[44.238.234.78]
said: 550 5.7.1 Blocked by SpamAssassin (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 434 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 3422 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 2653 bytes --]
From: e-Mail Server lists.linux.dev <linux-staging@lists.linux.dev>
To: linux-staging@lists.linux.dev
Subject: linux-staging@lists.linux.dev disconnected! Re-confirm to fix now!
Date: 18 Oct 2021 08:45:58 -0700
Message-ID: <20211018084558.8F13650FEF67E906@lists.linux.dev>
^ permalink raw reply [relevance 28%]
* Undelivered Mail Returned to Sender
@ 2021-11-11 12:18 28% Mail Delivery System
0 siblings, 0 replies; 200+ results
From: Mail Delivery System @ 2021-11-11 12:18 UTC (permalink / raw)
To: linux-staging
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 552 bytes --]
This is the mail system at host bizcloud-send.greenmatch.co.uk.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<linux-staging@lists.linux.dev>: host smtp.subspace.kernel.org[44.238.234.78]
said: 550 5.7.1 Blocked by SpamAssassin (in reply to end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 431 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 11499 bytes --]
[-- Attachment #3.1: Type: text/html, Size: 10461 bytes --]
From: e-Mail Server lists.linux.dev <linux-staging@lists.linux.dev>
To: linux-staging@lists.linux.dev
Subject: At 11/11/2021 11:38:31 a.m. linux-staging@lists.linux.dev failed to sync and returned 14 incoming messages.
Date: 11 Nov 2021 11:38:31 -0800
Message-ID: <20211111113831.B7970036F2451BB6@lists.linux.dev>
^ permalink raw reply [relevance 28%]
Results 1-200 of ~10000 next [<= 8%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-11-11 12:18 28% Undelivered Mail Returned to Sender Mail Delivery System
2021-10-15 8:31 28% Mail Delivery System
2021-10-18 16:27 28% Mail Delivery System
2024-03-19 18:18 23% [PATCH] MAINTAINERS: Remove incorrect M: tag for dm-devel@lists.linux.dev Kuan-Wei Chiu
2023-05-31 2:24 22% [ndctl PATCH v2 1/2] CONTRIBUTING.md: document cxl mailing list Li Zhijian
2023-05-23 3:57 22% [ndctl PATCH " Li Zhijian
[not found] <20230814104639.54BEF81890F70DC4@lists.linux.dev>
2023-08-14 9:46 20% ` Mail delivery failed: returning message to sender Mail Delivery System
[not found] <20230814093908.58A41D84261385F6@lists.linux.dev>
2023-08-14 8:39 20% ` Mail Delivery System
[not found] <20230816120531.057CDA36916887DA@lists.linux.dev>
2023-08-16 11:05 20% ` Mail Delivery System
[not found] <20230816100303.E4027DC3296C6D15@lists.linux.dev>
2023-08-16 9:03 20% ` Mail Delivery System
[not found] <20230814102700.7F5D13F4B03D7D17@lists.linux.dev>
2023-08-14 9:27 20% ` Mail Delivery System
[not found] <20230816120404.72EB41734ED057E8@lists.linux.dev>
2023-08-16 11:04 20% ` Mail Delivery System
[not found] <20230814102704.252CCD7AE5C5FBA6@lists.linux.dev>
2023-08-14 9:27 20% ` Mail Delivery System
[not found] <20230814102730.62A81ABA2617AADC@lists.linux.dev>
2023-08-14 9:27 20% ` Mail Delivery System
[not found] <644079563177$43710a80$455500b1$@lists.linux.dev>
2022-07-04 17:31 20% ` 未送达: postmaster
[not found] <20230814102751.31AD0FD42294B28C@lists.linux.dev>
2023-08-14 9:27 20% ` Mail delivery failed: returning message to sender Mail Delivery System
[not found] <20230816113304.228C7B2568AFF488@lists.linux.dev>
2023-08-16 10:33 20% ` Mail Delivery System
[not found] <20230814101407.E583F8A1584FBF9E@lists.linux.dev>
2023-08-14 9:14 20% ` Mail Delivery System
[not found] <20230814102412.45D084CD67ABFEB1@lists.linux.dev>
2023-08-14 9:24 20% ` Mail Delivery System
[not found] <20230816120551.D77682163964749B@lists.linux.dev>
2023-08-16 11:05 20% ` Mail Delivery System
[not found] <20230816115124.E887BBA760932448@lists.linux.dev>
2023-08-16 10:51 20% ` Mail Delivery System
[not found] <20230816113737.044F6D5996B8EF88@lists.linux.dev>
2023-08-16 10:37 20% ` Mail Delivery System
[not found] <20230814102704.8CF24EB60A0CCCC4@lists.linux.dev>
2023-08-14 9:27 20% ` Mail Delivery System
[not found] <20230816120406.444E5852DC7BE3EF@lists.linux.dev>
2023-08-16 11:04 20% ` Mail Delivery System
[not found] <20230816120550.67970145FA271048@lists.linux.dev>
2023-08-16 11:05 20% ` Mail Delivery System
[not found] <20230816100258.B626FAF3CD9EBBD6@lists.linux.dev>
2023-08-16 9:03 20% ` Mail Delivery System
[not found] <20230814104255.C2BBCDDA9B815FB6@lists.linux.dev>
2023-08-14 9:42 20% ` Mail Delivery System
[not found] <20230816100304.F9930AA917EDA9DA@lists.linux.dev>
2023-08-16 9:03 20% ` Mail Delivery System
2021-04-15 10:29 20% [PATCH v1] docs: reporting-issues.rst: CC subsystem and maintainers on regressions Thorsten Leemhuis
[not found] <20230816120528.99581B15228A21F9@lists.linux.dev>
2023-08-16 11:05 20% ` Mail delivery failed: returning message to sender Mail Delivery System
[not found] <20230816120650.BE2BBAFE768CB5F4@lists.linux.dev>
2023-08-16 11:06 20% ` Mail Delivery System
[not found] <20230814091553.68398532BA78381E@lists.linux.dev>
2023-08-14 8:15 20% ` Mail Delivery System
[not found] <20230814103628.32A9B9B6C52A1DE3@lists.linux.dev>
2023-08-14 9:36 20% ` Mail Delivery System
[not found] <20230814093047.3B521F5FA66C0D10@lists.linux.dev>
2023-08-14 8:30 20% ` Mail Delivery System
[not found] <20230816113242.DA07B8DB3BA1A07D@lists.linux.dev>
2023-08-16 10:32 20% ` Mail Delivery System
[not found] <625918748262f@lists.linux.dev>
2022-04-20 8:14 19% ` Mail Delivery System
[not found] <202210130337302514010@lists.linux.dev>
2022-10-12 19:37 17% ` Non recapitabile: 帮助外贸人快速找到客户源\uC3D6\uCE56\uB745\uC99D\uBA8C\uC823\uB9DE\uCC80 postmaster
2022-03-16 18:49 17% [PATCH] MAINTAINERS: Add chrome-platform@lists.linux.dev to all Chrome OS entries Guenter Roeck
2022-08-27 21:03 17% Returned mail: see transcript for details Mail Delivery Subsystem
2022-08-29 11:30 16% Undelivered Mail Returned to Sender Mail Delivery System
2024-03-26 18:08 16% [merged mm-hotfixes-stable] maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch removed from -mm tree Andrew Morton
2023-02-08 14:28 16% [PATCH] MAINTAINERS: update Allwinner sunXi SoC support entry Trevor Woerner
2023-02-08 14:28 16% ` Trevor Woerner
2021-03-16 10:23 15% [PATCH] MAINTAINERS: move the staging subsystem to lists.linux.dev gregkh
2021-03-16 10:23 15% ` gregkh
2024-03-19 20:34 15% + maintainers-remove-incorrect-m-tag-for-dm-devel-listslinuxdev.patch added to mm-hotfixes-unstable branch Andrew Morton
2022-01-26 22:22 15% [PATCH] MAINTAINERS: platform-chrome: Add new chrome-platform@lists.linux.dev list Benson Leung
2022-01-27 16:44 9% ` Benson Leung
2022-09-19 8:44 14% [PATCH v2] MAINTAINERS: refurbish SWIOTLB SUBSYSTEM sections after refactoring Lukas Bulwahn
[not found] <57FE55D35BCEFA4A7BA648A7E2564770@lists.linux.dev>
2022-09-10 1:05 14% ` Undeliverable: looking for agent/distributor/whole seller in every country. òøÎòìÕ× postmaster
2022-09-19 8:47 14% [PATCH v2] MAINTAINERS: refurbish SWIOTLB SUBSYSTEM sections after refactoring Lukas Bulwahn
2021-12-18 4:21 13% [PATCH] README: Remove stray '@' from mailing list email Ossama Othman
2023-02-13 23:52 13% [folded-merged] mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch removed from -mm tree Andrew Morton
2022-09-22 10:00 13% [PATCH v3] MAINTAINERS: merge SWIOTLB SUBSYSTEM into DMA MAPPING HELPERS Lukas Bulwahn
2021-12-04 17:52 13% [PATCH] MAINTAINERS: Sort entries using parse-maintainers.pl Jonathan Neuschäfer
2024-02-22 0:02 13% [merged mm-stable] mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch removed from -mm tree Andrew Morton
2024-01-30 6:45 13% + mm-damon-dbgfs-make-debugfs-interface-deprecation-message-a-macro.patch added to mm-unstable branch Andrew Morton
2021-11-17 19:05 13% [PATCH v1 1/1] MAINTAINERS: Sort sections with parse-maintainers.pl help Andy Shevchenko
2021-11-17 19:05 13% ` Andy Shevchenko
2022-10-25 23:03 12% [outreachy+owner@lists.linux.dev: Bouncing messages from outreachy@lists.linux.dev] Deepak R Varma
2023-02-10 22:30 12% + mm-damon-dbgfs-print-damon-debugfs-interface-deprecation-message-fix.patch added to mm-unstable branch Andrew Morton
2022-07-09 8:29 12% Patch "MAINTAINERS: Remove iommu@lists.linux-foundation.org" has been added to the 5.18-stable tree gregkh
2022-07-06 10:33 12% [PATCH] MAINTAINERS: Remove iommu@lists.linux-foundation.org Joerg Roedel
2022-07-06 10:33 11% ` Joerg Roedel
2023-10-04 20:18 12% [merged mm-stable] docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch removed from -mm tree Andrew Morton
2022-07-15 11:03 12% [PATCH] MAINTAINERS: Add Robin Murphy as IOMMU SUBSYTEM reviewer Joerg Roedel
2022-06-24 12:51 11% [PATCH v2] MAINTAINERS: Add new IOMMU development mailing list Joerg Roedel
2022-06-24 12:51 11% ` Joerg Roedel
[not found] <mailman.0.1697833421.3533607.linux-lvm@redhat.com>
2023-10-20 21:31 11% ` linux-lvm has migrated to lists.linux.dev [was: Re: Welcome to the "linux-lvm" mailing list] Mike Snitzer
2021-04-21 7:05 11% [PATCH] MAINTAINERS: Move nvdimm mailing list Dan Williams
2021-04-21 7:05 11% ` Dan Williams
2024-01-26 2:16 11% + dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch added to mm-unstable branch Andrew Morton
2021-05-18 22:25 11% [ndctl PATCH] ndctl: Update nvdimm mailing list address Vishal Verma
2021-05-18 22:25 10% ` Vishal Verma
2023-11-07 20:00 11% [PATCH] MAINTAINERS: update lists.linuxfoundation.org migrated lists Konstantin Ryabitsev
2022-06-25 4:50 11% [PATCH] MAINTAINERS: Add new IOMMU development mailing list Satish Nagireddy
2022-08-04 12:05 10% Undelivered Mail Returned to Sender Mail Delivery System
2021-11-29 21:56 10% PSA: generic patches@lists.linux.dev list Konstantin Ryabitsev
2021-11-30 1:09 9% ` Lukas Bulwahn
2024-02-22 0:01 10% [merged mm-stable] dax-add-a-sysfs-knob-to-control-memmap_on_memory-behavior.patch removed from -mm tree Andrew Morton
2023-10-06 23:29 10% dm-devel has migrated to lists.linux.dev Mike Snitzer
2023-10-06 23:43 9% ` Mike Snitzer
2023-10-11 18:41 9% ` Mike Snitzer
2023-10-11 14:35 9% ` Mike Snitzer
2021-04-16 20:58 10% Subscriber actions for migrating lists " James Bottomley
2021-04-16 21:16 11% ` Konstantin Ryabitsev
2021-04-16 21:22 ` James Bottomley
2021-04-16 21:26 10% ` Konstantin Ryabitsev
2022-08-04 12:04 10% 24-7 Scotland Contact Form: THE WORLD FINANCIAL CRISIS CAN MAKE YOU RICH! linux-staging
2024-02-22 13:06 10% [PATCH v2] MAINTAINERS: Use a proper mailinglist for NXP i.MX development Daniel Baluta (OSS)
[not found] <1657492202-18435-mlmmj-51d729a7@lists.linux.dev>
[not found] ` <CAFP8O3+Lw0wKfWY-VA+tuAnVcjyN17E=yk6-VU5WcWG1xdH+UA@mail.gmail.com>
2022-07-11 17:54 10% ` Fwd: Bouncing messages from llvm@lists.linux.dev Nick Desaulniers
2024-02-20 16:40 10% [PATCH] MAINTAINERS: Use a proper mailinglist for NXP i.MX development Daniel Baluta (OSS)
[not found] <mailman.0.1697833396.3533474.lvm-devel@redhat.com>
2023-10-20 21:34 10% ` lvm-devel has migrated to lists.linux.dev [was: Re: Welcome to the "lvm-devel" mailing list] Mike Snitzer
2022-02-02 21:19 10% [PATCH] MAINTAINERS: update mailing list address for NTB subsystem Dave Jiang
2023-09-10 20:47 10% + docs-admin-guide-mm-damon-usage-move-debugfs-intro-to-the-bottom-of-the-section.patch added to mm-unstable branch Andrew Morton
2023-02-11 18:18 10% [PATCH] docs: update ofono mailing list Alexandru Ardelean
2021-03-22 9:57 10% Patch "MAINTAINERS: move the staging subsystem to lists.linux.dev" has been added to the 5.10-stable tree gregkh
[not found] <1628081824-28535-mlmmj-16bf2009@lists.linux.dev>
2021-08-04 13:45 10% ` Post to linux-staging@lists.linux.dev denied: [PATCH] staging: rtl8723bs: os_dep: remove unused variable SAURAV GIREPUNJE
2023-08-29 17:07 10% [Cluster-devel] [ANNOUNCE] Goodbye cluster-devel, hello gfs2@lists.linux.dev Andrew Price
2023-08-29 17:07 10% ` Andrew Price
2023-09-06 8:36 9% ` Andrew Price
2023-09-06 8:36 9% ` [Cluster-devel] " Andrew Price
2023-01-13 13:28 10% [PATCH] KVM: arm64: Drop Columbia-hosted mailing list Marc Zyngier
2023-01-13 13:28 9% ` Marc Zyngier
2021-03-22 9:45 10% Patch "MAINTAINERS: move the staging subsystem to lists.linux.dev" has been added to the 5.11-stable tree gregkh
2023-10-27 18:28 10% Moving this list to lists.linux.dev Konstantin Ryabitsev
2021-08-25 21:07 10% Moving to llvm@lists.linux.dev Nathan Chancellor
2024-01-30 6:45 10% + docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch added to mm-unstable branch Andrew Morton
2024-01-26 2:16 10% + documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch " Andrew Morton
2021-04-20 20:34 10% [ANNOUNCE] NVDIMM development move to nvdimm@lists.linux.dev Dan Williams
2023-11-01 19:47 10% PSA: the linux-kernel-mentees list is migrating to lists.linux.dev Konstantin Ryabitsev
2021-08-25 22:54 9% Invitation: (No Subject) @ Fri Sep 24, 2021 7am - 11am (PDT) (llvm@lists.linux.dev) Nick Desaulniers
2023-12-15 23:32 9% [PATCH] multipath-tools: update ml Xose Vazquez Perez
2023-08-17 0:00 9% Create kdevops@lists.linux.dev Luis Chamberlain
2023-08-17 16:52 9% ` Shyam Kumar
2023-12-18 23:00 9% [Opae] PSA: this list is moving to lists.linux.dev Konstantin Ryabitsev
2022-10-01 9:12 9% [PATCH] KVM: arm64: Advertise new kvmarm mailing list Marc Zyngier
2022-10-01 9:12 9% ` Marc Zyngier
2022-10-01 9:12 9% ` Marc Zyngier
2023-12-18 23:07 9% [Tech-board-discuss] PSA: this list is moving to lists.linux.dev (no action required) Konstantin Ryabitsev
2023-02-10 4:18 9% Undelivered Mail Returned to Sender Mail Delivery System
2023-12-18 22:54 9% [LVFS] PSA: this list is moving to lists.linux.dev (no action required) Konstantin Ryabitsev
2022-11-17 14:25 9% Welcome to kernelci@lists.linux.dev Konstantin Ryabitsev
2023-11-01 21:26 9% [Acpica-devel] PSA: the acpica-devel list is migrating to lists.linux.dev Konstantin Ryabitsev
2023-11-07 19:41 9% ` Konstantin Ryabitsev
2022-02-02 21:10 9% Welcome to ntb@lists.linux.dev Konstantin Ryabitsev
2021-09-14 22:38 9% Invitation: Clang Built Linux Meetup II turbo (2021) @ Fri Sep 17, 2021 8am - 2pm (PDT) (llvm@lists.linux.dev) Nick Desaulniers
[not found] <1620376201-3408-mlmmj-4f932172@lists.linux.dev>
2021-05-07 9:08 9% ` Bouncing messages from linux-staging@lists.linux.dev Fabio Aiuto
2021-06-02 6:43 9% [PATCH v3] README: Update mailing list info Daniel Wagner
2023-02-12 5:24 9% Undelivered Mail Returned to Sender Mail Delivery System
2023-11-21 21:21 9% [Tpm2] PSA: the tpm2 list will be moving to lists.linux.dev Konstantin Ryabitsev
2023-11-21 20:57 9% [Fuego] PSA: the fuego " Konstantin Ryabitsev
2021-09-09 21:04 9% [merged] maintainers-update-clangbuiltlinux-mailing-list.patch removed from -mm tree akpm
2023-11-21 20:43 9% [diamon-discuss] PSA: the diamon-discuss list will be moving to lists.linux.dev Konstantin Ryabitsev
2024-02-22 0:02 9% [merged mm-stable] docs-admin-guide-mm-damon-usage-document-deprecated-file-of-damon-debugfs-interface.patch removed from -mm tree Andrew Morton
2021-08-25 21:18 9% [PATCH 1/3] MAINTAINERS: Update ClangBuiltLinux mailing list Nathan Chancellor
2024-02-08 19:26 9% PSA: this list has been migrated to lists.linux.dev Konstantin Ryabitsev
2021-03-31 13:08 9% [PATCH 1/2] MAINTAINERS: Add our new mailing-list Maxime Ripard
2023-11-21 20:47 9% [Accel-config] PSA: the accel-config list will be moving to lists.linux.dev Konstantin Ryabitsev
2023-12-18 22:58 9% [Lvfs-announce] PSA: this list is moving to lists.linux.dev (no action requried) Konstantin Ryabitsev
[not found] <YMJLJR/atypu++qU@casper.infradead.org>
2021-06-10 19:44 ` Create mm@lists.linux.dev Johannes Weiner
2021-06-14 14:25 ` Jason Gunthorpe
2021-06-15 11:19 9% ` Christoph Lameter
2022-03-17 9:30 9% Returned mail: see transcript for details Mail Delivery Subsystem
2023-04-01 19:06 9% [PATCH] Update email address and mailing list for v9fs Eric Van Hensbergen
2021-08-31 22:48 9% + maintainers-update-clangbuiltlinux-mailing-list.patch added to -mm tree akpm
2024-01-27 2:18 9% [PATCH] dm vdo: use a proper Makefile for dm-vdo Matthew Sakai
2023-11-01 18:17 9% PSA: this list is moving to virtualization@lists.linux.dev Konstantin Ryabitsev
2023-11-21 21:38 9% [SPDK] PSA: the spdk list will be moving to lists.linux.dev Konstantin Ryabitsev
2022-11-05 8:10 9% mptcp@lists.linux.dev FedoraForum.org
2023-07-09 0:30 9% [merged mm-hotfixes-stable] docs-update-ocfs2-devel-mailing-list-address.patch removed from -mm tree Andrew Morton
2021-08-25 22:54 9% Updated invitation with note: Toolchains and Kernel MC @ Fri Sep 24, 2021 7am - 11am (PDT) (llvm@lists.linux.dev) Nick Desaulniers
2023-07-02 17:36 9% + docs-update-ocfs2-devel-mailing-list-address.patch added to mm-hotfixes-unstable branch Andrew Morton
2022-07-14 8:26 9% KernelCI at lists.linux.dev Guillaume Tucker
2022-07-14 14:51 9% ` Konstantin Ryabitsev
2022-07-15 5:12 ` Guillaume Tucker
[not found] ` <1706552EEFF7A8A6.5263@groups.io>
2022-11-18 10:04 9% ` Guillaume Tucker
2023-11-01 20:10 9% [Bridge] PSA: the bridge list will be moving to lists.linux.dev Konstantin Ryabitsev
2023-11-07 19:38 9% ` Konstantin Ryabitsev
2021-09-11 3:09 9% Invitation: [PATCH] staging: rtl8723bs: remove possible deadlock when... @ Sat 2021-09-11 05:30 - 06:30 (CEST) (linux-staging@lists.linux.dev) fmdefrancesco
2023-01-30 12:17 9% Undelivered Mail Returned to Sender Mail Delivery System
2023-12-18 23:02 9% [Printing-architecture] PSA: this list is moving to lists.linux.dev (no action required) Konstantin Ryabitsev
2022-08-01 18:57 8% Invitation: Justin Stitt's Intern Presentation @ Wed Aug 17, 2022 10am - 11am (PDT) (llvm@lists.linux.dev) Nick Desaulniers
2022-06-22 8:26 8% [PATCH] MAINTAINERS: Add new IOMMU development mailing list Joerg Roedel
2024-02-22 0:01 8% [merged mm-stable] documentatiion-abi-add-abi-documentation-for-sys-bus-dax.patch removed from -mm tree Andrew Morton
2023-06-23 21:01 8% Invitation: CBL meetup @ Sat Nov 11, 2023 5am - 2pm (PST) (llvm@lists.linux.dev) Nick Desaulniers
2022-07-11 9:06 [PATCH 5.18 000/112] 5.18.11-rc1 review Greg Kroah-Hartman
2022-07-11 9:06 11% ` [PATCH 5.18 028/112] MAINTAINERS: Remove iommu@lists.linux-foundation.org Greg Kroah-Hartman
2023-12-11 22:52 [PATCH v3 0/2] Add DAX ABI for memmap_on_memory Vishal Verma
2023-12-11 22:52 10% ` [PATCH v3 2/2] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2023-12-11 22:52 9% ` [PATCH v3 1/2] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
2024-03-08 18:35 [PATCH v2 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-03-08 18:35 10% ` [PATCH v2 11/14] x86/sev: Extend the config-fs attestation support for " Tom Lendacky
2023-02-10 4:48 [PATCH v2 0/3] mm/damon: deprecate DAMON debugfs interface SeongJae Park
2023-02-10 18:28 13% ` SeongJae Park
2022-06-27 11:20 [PATCH 5.15 000/135] 5.15.51-rc1 review Greg Kroah-Hartman
2022-06-27 11:20 11% ` [PATCH 5.15 022/135] MAINTAINERS: Add new IOMMU development mailing list Greg Kroah-Hartman
2023-12-07 4:36 [PATCH v2 0/2] Add DAX ABI for memmap_on_memory Vishal Verma
2023-12-07 4:36 11% ` [PATCH v2 2/2] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2023-12-07 4:36 9% ` [PATCH v2 1/2] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
2024-01-30 1:35 [PATCH 0/9] mm/damon: make DAMON debugfs interface deprecation unignorable SeongJae Park
2024-01-30 1:35 15% ` [PATCH 4/9] mm/damon/dbgfs: make debugfs interface deprecation message a macro SeongJae Park
2024-01-30 1:35 12% ` [PATCH 5/9] Docs/admin-guide/mm/damon/usage: document 'DEPRECATED' file of DAMON debugfs interface SeongJae Park
2024-01-28 21:25 [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI Samuel Ortiz
2024-01-28 21:25 11% ` [RFC PATCH v2 2/4] tsm: Add RTMRs to the configfs-tsm hierarchy Samuel Ortiz
2023-12-14 7:37 [PATCH v5 0/4] Add DAX ABI for memmap_on_memory Vishal Verma
2023-12-14 7:37 10% ` [PATCH v5 4/4] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2023-12-14 7:37 9% ` [PATCH v5 1/4] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
2024-04-12 8:51 [RFC PATCH v2 0/6] Towards a shared TSM sysfs-ABI for Confidential Computing Dan Williams
2024-04-12 8:52 10% ` [RFC PATCH v2 5/6] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2024-01-26 22:15 [PATCH 00/11] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-01-26 22:16 10% ` [PATCH 10/11] x86/sev: Extend the config-fs attestation support for " Tom Lendacky
2021-03-22 12:25 [PATCH 5.10 000/157] 5.10.26-rc1 review Greg Kroah-Hartman
2021-03-22 12:28 15% ` [PATCH 5.10 152/157] MAINTAINERS: move the staging subsystem to lists.linux.dev Greg Kroah-Hartman
2023-12-15 5:25 [PATCH v6 0/4] Add DAX ABI for memmap_on_memory Vishal Verma
2023-12-15 5:25 10% ` [PATCH v6 4/4] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2023-12-15 5:25 9% ` [PATCH v6 1/4] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
2023-08-23 17:57 [PATCH 5.15 0/2] Fixup IOMMU list in MAINTAINERS Easwar Hariharan
2023-08-23 17:57 11% ` [PATCH 5.15 2/2] MAINTAINERS: Remove iommu@lists.linux-foundation.org Easwar Hariharan
2021-09-08 2:52 incoming Andrew Morton
2021-09-08 2:58 9% ` [patch 096/147] MAINTAINERS: update ClangBuiltLinux mailing list Andrew Morton
2023-09-07 2:29 [PATCH 00/11] mm/damon: misc fixups for documents, comments and its tracepoint SeongJae Park
2023-09-07 2:29 13% ` [PATCH 03/11] Docs/admin-guide/mm/damon/usage: move debugfs intro to the bottom of the section SeongJae Park
2024-01-22 11:49 [PATCH 0/2] netfs, cachefiles: Update MAINTAINERS records David Howells
2024-01-22 11:50 10% ` [PATCH 1/2] netfs, cachefiles: Change mailing list David Howells
2024-01-22 11:50 10% ` David Howells
2024-01-22 11:50 8% ` [PATCH 2/2] netfs: Add Jeff Layton as reviewer David Howells
2024-01-22 11:50 8% ` David Howells
2024-04-24 15:57 [PATCH v4 00/15] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-04-24 15:58 10% ` [PATCH v4 14/15] x86/sev: Extend the config-fs attestation support for " Tom Lendacky
2021-04-09 11:47 [PATCH v2 0/2] Mention regression mailing list in reporting-bugs and MAINTAINERS Thorsten Leemhuis
2021-04-09 11:47 9% ` [PATCH v2 1/2] MAINTAINERS: add regressions mailing list Thorsten Leemhuis
2023-12-12 19:08 [PATCH v4 0/3] Add DAX ABI for memmap_on_memory Vishal Verma
2023-12-12 19:08 10% ` [PATCH v4 3/3] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2023-12-12 19:08 9% ` [PATCH v4 1/3] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
2024-01-24 20:03 [PATCH v7 0/5] Add DAX ABI for memmap_on_memory Vishal Verma
2024-01-24 20:03 10% ` [PATCH v7 5/5] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2024-01-24 20:03 9% ` [PATCH v7 3/5] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
2023-12-07 4:29 [PATCH 0/2] Add DAX ABI for memmap_on_memory Vishal Verma
2023-12-07 4:29 11% ` [PATCH 2/2] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2022-06-27 11:19 [PATCH 5.18 000/181] 5.18.8-rc1 review Greg Kroah-Hartman
2022-06-27 11:19 11% ` [PATCH 5.18 026/181] MAINTAINERS: Add new IOMMU development mailing list Greg Kroah-Hartman
2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-03-25 22:26 10% ` [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for " Tom Lendacky
2023-06-28 1:34 [PATCH 0/2] update ocfs2-devel mailing list addresses Anthony Iliopoulos
2023-06-28 1:34 9% ` [PATCH 2/2] docs: update ocfs2-devel mailing list address Anthony Iliopoulos
2024-03-26 12:21 [RFC PATCH v1 0/2] docs: reporting-issues: rework while involving the 'verify bugs' text Thorsten Leemhuis
2024-03-26 12:21 13% ` [RFC PATCH v1 2/2] docs: reporting-issue: rework the TLDR Thorsten Leemhuis
2024-03-26 12:21 10% ` [RFC PATCH v1 1/2] docs: reporting-issue: rework the detailed guide Thorsten Leemhuis
2021-03-22 12:26 [PATCH 5.11 000/120] 5.11.9-rc1 review Greg Kroah-Hartman
2021-03-22 12:28 15% ` [PATCH 5.11 115/120] MAINTAINERS: move the staging subsystem to lists.linux.dev Greg Kroah-Hartman
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.