* RE: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Torreno, Alexis Czezar @ 2026-04-17 1:04 UTC (permalink / raw)
To: Conor Dooley, Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <20260416-scoring-secluding-c7a7235b181a@spud>
> > >
> > > On the previous version, you got an LLM comment about not having the
> > > interrupts property amongst other things.
> > > I think the other things got implemented, but I didn't see any reply
> > > to the bot about that?
I wasn't sure if it was that type of bot. I'll try replying on the other patch review.
I just added a note in the cover letter change log about the lacking smbalert.
> > > I think the answer is that it shouldn't because the pin it
> > > referenced doesn't exist, but when looking at the schematic I have
> > > to wonder if
> >
> > I had to look this up in the datasheet. A SMBus chip with no alert pin
> > is a bit odd, but you are correct.
> >
> > > there should be an interrupts property for dealing with "pgood"?
> > >
> > FWIW, I have never seen that. Normally such pins are used to take
> > devices out of reset.
>
> It's an output on this device seemingly. I don't care if the driver ignores it, but
> for completeness (and we like completeness with
> bindings) I think it should be documented as an interrupt or gpio.
Alright, I'll add it as an interrupt: optional power-good signal
Regards,
Alexis
^ permalink raw reply
* Re: [PATCH V10 00/10] famfs: port into fuse
From: Joanne Koong @ 2026-04-17 0:44 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Dan Williams, Gregory Price, John Groves, Miklos Szeredi,
Bernd Schubert, John Groves, Dan J Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Randy Dunlap, Jeff Layton, Amir Goldstein, Jonathan Cameron,
Stefan Hajnoczi, Josef Bacik, Bagas Sanjaya, Chen Linxuan,
James Morse, Fuad Tabba, Sean Christopherson, Shivank Garg,
Ackerley Tng, Aravind Ramesh, Ajay Joshi, venkataravis@micron.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org,
linux-fsdevel@vger.kernel.org
In-Reply-To: <20260416224331.GD114184@frogsfrogsfrogs>
On Thu, Apr 16, 2026 at 3:43 PM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Thu, Apr 16, 2026 at 01:53:27PM -0700, Dan Williams wrote:
> >
> >
> > On Thu, Apr 16, 2026, at 1:14 PM, Gregory Price wrote:
> > > On Thu, Apr 16, 2026 at 08:56:46AM -0700, Joanne Koong wrote:
> > >> On Tue, Apr 14, 2026 at 5:10 PM John Groves <John@groves.net> wrote:
> > >> >
> > >> > There is a FUSE_DAX_FMAP capability that the kernel may advertise or not
> > >> > at init time; this capability "is" the famfs GET_FMAP AND GET_DAXDEV
> > >> > commands. In the future, if we find a way to use BPF (or some other
> > >> > mechanism) to avoid needing those fuse messages, the kernel could be updated
> > >> > to NEVER advertise the FUSE_DAX_FMAP capability. All of the famfs-specific
> > >> > code could be taken out of kernels that never advertise that capability.
> > >>
> > >> I’m not sure the capability bit can be used like that (though I am
> > >> hoping it can!). As I understand it, once the kernel advertises a
> > >> capability, it must continue supporting it in future kernels else
> > >> userspace programs that rely on it will break.
>
> So don't break fuse servers. If you wanted to (say) get rid of
> GET_FMAP in favor of IOMAP_BEGIN, you could alter libfuse to translate a
> fuse server's ->get_fmap implementation into the equivalent
> ->iomap_begin, and eventually the kernel can stop making GET_FMAP calls
> to userspace.
I don't think it's this simple. We can't assume libfuse is the only
way servers talk to the kernel. Some servers use the /dev/fuse
interface directly. And, as I understand it, this would still break
users who are on older versions of libfuse if they upgrade to a newer
kernel.
My reason for pushing back isn't because I don't want this to work; I
just want to make sure that if we're going to rely on this as a safety
hatch, then we can actually do it.
Going back to what Dan said about using the capability bits for
deprecation, "In some future kernel the famfs native option disappears
after a deprecation period" - what does the deprecation period/process
look like? Do you have to wait a certain amount of time before it can
be fully removed or is it pretty immediate?
>
> The trouble here is that I've also seen half a dozen projects vendoring
> libfuse so that's a nightmare that will have to be dealt with. But
> maybe that doesn't even matter, because...
>
> > > FUSE_DAX_FMAP is already conditional on CONFIG_FUSE_DAX, the kernel is
> > > not required to continue advertising FUSE_DAX_FMAP in perpetuity.
> > >
> > > Setting CONFIG_FUSE_DAX=n does not mean userland "is broken", this would
> > > only be the case if FUSE_DAX_FMAP was advertised but not actually
> > > supported.
>
> ...the memory interleaving is a rather interesting quality of famfs.
> There's no good way to express a formulaic meta-mapping in traditional
> iomap parlance, and famfs needs that to interleave across memory
> controllers/dimm boxen/whatever. Throwing individual iomaps at the
> kernel is a very inefficient way to do that. So I don't think there's a
> good reason to get rid of GET_FMAP at this time...
So could we make the interleaving part generic then? Striped /
interleaved layouts are used elsewhere (eg RAID-0, md-stripe, etc.) -
could we add a generic interleave descriptor to the uapi and use that
for what famfs needs?
>
> > > If DAX were removed from the kernel (unlikely, but stick with me) this
> > > would be equivalent to permanently changing CONFIG_FUSE_DAX to always
> > > off, and there would be no squabbles over whether that particular
> > > change broke userland (there would be much strife over removing dax).
>
> ...however the strongest case (IMO) would be if (having merged famfs) we
> then merge fuse-iomap after famfs. Then we extend the existing
> fuse-iomap-bpf prototype to allow per-mount and per-inode iomap bpf ops.
> That enables us to analyze thoroughly the performance characteristics of:
>
> a) Using GET_FMAP as-is
>
> b) Uploading raw iomaps (HA)
>
> c) Uploading a single bpf program to make iomaps, exchanging fmap-style
> mapping data into a bpf map, and having the single bpf program walk
> through the map
>
> d) Uploading a custom bpf program per famfs file to make iomaps. No
> bpfmap required, but the setup and compilation are now much more complex
>
> Then we'll finally know which approach is the best, having broken the
> Gordian Knot of how to merge famfs and fuse-iomap.
>
> If we decide that (c) or (d) are actually better, then guess what? To
> get any of the iomap functionality, you have to set an inode flag, and
> that (FUSE_CAP_FAMFS && FUSE_CAP_IOMAP && FUSE_ATTR_IOMAP) is the signal
> for "don't call GET_FMAP". FUSE_CAP_FAMFS && (!FUSE_CAP_IOMAP ||
> !FUSE_ATTR_IOMAP) means "call GET_FMAP".
>
> Yes, we burn a couple of fuse command values to find out, but that's all.
>
> (TBH I still dislike GET_DAXDEV, that really should just be another
> application of backing files, and the backing file id gets passed to
> GET_FMAP.)
>
> What do you all think of doing that?
To be completely honest, this is orthogonal to what I was hoping we
could discuss on this thread. My main concern is the GET_FMAP part.
Can we make it more generic to other interleaved/striped layouts?
Thanks,
Joanne
>
> > > While not a deprecation method, this is what capability bits are
> > > designed for. Same as cpuid capability bits - just because the bit is
> > > there doesn't mean a processor is required to support it in perpetuity.
> > >
> > > They're only required to support it if the bit is turned on.
> > >
> >
> > Right, if the protocol on day one is "user space must ask which method
> > is available", then userspace can not be surprised when one option
> > disappears. So to give time for the bpf approach to mature the kernel
> > can do something like "famfs and bpf mapping support are available".
> > In some future kernel the famfs native option disappears after a
> > deprecation period.
> >
> > When folks ask 10 years from now why this ever supported optionality
> > the explanation is "oh because famfs enjoyed first mover advantage to
> > prove out fs semantics layered on dax devices", or "turns out there
> > are some cases where bpf is not fast enough but it still stops the
> > proliferation of more in kernel mapping implementations".
>
> Yes. We're not *capable* of determining the best mechanism unless we
> can start shipping these things to users to get their feedback. Only
> then can we iterate and make real improvements.
>
> > Something like FUSE_DAX_FMAP is always available but the backend to
> > that is optionally native vs bpf. ...or some other arrangement to make
> > it clear that native might be gone someday.
>
> --D
^ permalink raw reply
* Re: [PATCH v11 02/20] gpu: nova-core: gsp: Extract usable FB region from GSP
From: John Hubbard @ 2026-04-16 23:26 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260415210548.3776595-2-joelagnelf@nvidia.com>
On 4/15/26 2:05 PM, Joel Fernandes wrote:
...
Apologies, I found one more minor thing, while looking at a
subsequent patch in this series:
> impl MessageFromGsp for GetGspStaticInfoReply {
> const FUNCTION: MsgFunction = MsgFunction::GetGspStaticInfo;
> type Message = GspStaticConfigInfo;
> - type InitError = Infallible;
> + type InitError = Error;
>
> fn read(
> msg: &Self::Message,
> @@ -205,6 +209,7 @@ fn read(
> ) -> Result<Self, Self::InitError> {
> Ok(GetGspStaticInfoReply {
> gpu_name: msg.gpu_name_str(),
> + usable_fb_region: msg.first_usable_fb_region().ok_or(ENODEV)?,
OK, failing out is correct here. But in addition, we should also
log this at dev_err!() level. This is rare, surprising, and actionable,
so perfect for that level of logging.
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v10 08/12] kvm: Define EXPORT_STATIC_CALL_FOR_KVM()
From: Pawan Gupta @ 2026-04-16 23:12 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <aeFmYd1ybZnVlAYW@google.com>
On Thu, Apr 16, 2026 at 03:44:49PM -0700, Sean Christopherson wrote:
> I think I'd prefer to require EXPORT_SYMBOL_FOR_KVM and EXPORT_STATIC_CALL_FOR_KVM
> to come as a pair from arch code. I can't think of a scenario where arch code
> should override one but not the other.
Right, will change as you suggested.
^ permalink raw reply
* Re: [PATCH v11 02/20] gpu: nova-core: gsp: Extract usable FB region from GSP
From: John Hubbard @ 2026-04-16 23:04 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260415210548.3776595-2-joelagnelf@nvidia.com>
On 4/15/26 2:05 PM, Joel Fernandes wrote:
...
> + /// Extracts the first usable FB region from GSP firmware data.
> + ///
> + /// Returns the first region suitable for driver memory allocation as a [`Range<u64>`].
> + /// Usable regions are those that satisfy all the following properties:
> + /// - Are not reserved for firmware internal use.
> + /// - Are not protected (hardware-enforced access restrictions).
> + /// - Support compression (can use GPU memory compression for bandwidth).
> + /// - Support ISO (isochronous memory for display requiring guaranteed bandwidth).
> + ///
> + /// TODO: Multiple discontinuous usable regions of RAM are possible in
> + /// special cases. We need to support it (to also match Nouveau's behavior).
Please let's not (ever) mention Nouveau in in-code comments. So far we
have held the line on that.
I think the TODO itself (again, without referring to Nouveau) could go into
Documentation/gpu/nova/core/todo.rst
instead of here. But if you really must have it here, then OK.
> + pub(crate) fn first_usable_fb_region(&self) -> Option<Range<u64>> {
> + self.fb_regions().find_map(|reg| {
> + // Filter: not reserved, not protected, supports compression and ISO.
> + if reg.reserved == 0
> + && reg.bProtected == 0
> + && reg.supportCompressed != 0
> + && reg.supportISO != 0
> + {
> + reg.limit.checked_add(1).map(|end| reg.base..end)
> + } else {
> + None
> + }
> + })
> + }
> }
>
> // SAFETY: Padding is explicit and will not contain uninitialized data.
With "Nouveau" references removed,
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v11 01/20] gpu: nova-core: gsp: Return GspStaticInfo from boot()
From: John Hubbard @ 2026-04-16 22:57 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260415210548.3776595-1-joelagnelf@nvidia.com>
On 4/15/26 2:05 PM, Joel Fernandes wrote:
> Refactor the GSP boot function to return GetGspStaticInfoReply.
>
> This enables access required for memory management initialization to:
> - bar1_pde_base: BAR1 page directory base.
> - bar2_pde_base: BAR2 page directory base.
> - usable memory regions in video memory.
>
> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/gpu.rs | 9 +++++++--
> drivers/gpu/nova-core/gsp/boot.rs | 9 ++++++---
> 2 files changed, 13 insertions(+), 5 deletions(-)
Hi Joel,
Looks nice, just a tiny nit about a comment below, but either way,
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
>
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index 0f6fe9a1b955..b4da4a1ae156 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -21,7 +21,10 @@
> },
> fb::SysmemFlush,
> gfw,
> - gsp::Gsp,
> + gsp::{
> + commands::GetGspStaticInfoReply,
> + Gsp, //
> + },
> regs,
> };
>
> @@ -238,6 +241,8 @@ pub(crate) struct Gpu {
> /// GSP runtime data. Temporarily an empty placeholder.
> #[pin]
> gsp: Gsp,
> + /// Static GPU information from GSP.
> + gsp_static_info: GetGspStaticInfoReply,
Unless we have more to say, I'd suggest deleting the comment,
because it adds zero new information, at least as currently
written.
And I checked around: contrary to what I initially believed,
there doesn't seem to be a requirement to add this kind of
boilerplate--fortunately.
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v11 07/20] gpu: nova-core: mm: Add TLB flush support
From: Danilo Krummrich @ 2026-04-16 22:53 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <1e3c423e-1cf5-48b1-b012-c4af0eb6b95f@nvidia.com>
On Fri Apr 17, 2026 at 12:18 AM CEST, Joel Fernandes wrote:
> On 4/16/2026 5:45 PM, Danilo Krummrich wrote:
>> Why do we need the try_access() dance in the first place? I assume this ends up
>> being called from the BarAccess destructor?
>
> BarAccess is different. The try_access() calls here are in tlb.rs and
> pramin.rs for Bar0.
Yes, and we shouldn't need them in the first place; we should have a
&Device<Bound> in all call paths this is called from.
>> If so, I think this is solvable. Gary and me are currently working on
>> higher-ranked types and a chained Devres type.
>
> Hmm, the issue here is we cannot hold revocable guard while sleeping, but
> we have read the bar as a condition in the body of the poll.
No, you should just require a &Device<Bound>; or maybe we can utilize the
mentioned higher-ranked types and DevresChain once we have it. But in any case
you shouldn't need try_access() here.
>> With that, such use-cases should be cleanly solvable without the need for
>> try_access().
>>
>> Besides that, I can't find where BarAccess is ever constructed.
>
> BarUser::map() constructs it.
I'm well aware, but absolutely nothing calls BarUser::map(). :)
>> It already has a lifetime 'a for &'a Bar1, so I don't see why you can't do the
>> same for Bar0.>
>> But again, I don't see this being constructed and I'm not sure the whole
>> construct works in the first place.
>
> BarAccess uses &'a Bar1 because it's a short-lived scoped object. In long
> lived objects I am trying to avoid this.
Don't get me wrong, if a lifetime is sufficient -- that's great! But I'm
suspicious whether it actually is, since BarAccess is never actually constructed
and hence I can't see how it would be used.
^ permalink raw reply
* Re: [PATCH v10 09/12] x86/vmscape: Use static_call() for predictor flush
From: Sean Christopherson @ 2026-04-16 22:45 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260414-vmscape-bhb-v10-9-efa924abae5f@linux.intel.com>
On Tue, Apr 14, 2026, Pawan Gupta wrote:
> Adding more mitigation options at exit-to-userspace for VMSCAPE would
> usually require a series of checks to decide which mitigation to use. In
> this case, the mitigation is done by calling a function, which is decided
> at boot. So, adding more feature flags and multiple checks can be avoided
> by using static_call() to the mitigating function.
>
> Replace the flag-based mitigation selector with a static_call(). This also
> frees the existing X86_FEATURE_IBPB_EXIT_TO_USER.
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Tested-by: Jon Kohler <jon@nutanix.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
For the KVM change,
Acked-by: Sean Christopherson <seanjc@google.com>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 45d7cfedc507..5582056b2fa1 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -11463,7 +11463,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> * set for the CPU that actually ran the guest, and not the CPU that it
> * may migrate to.
> */
> - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> + if (static_call_query(vmscape_predictor_flush))
> this_cpu_write(x86_predictor_flush_exit_to_user, true);
>
> /*
^ permalink raw reply
* Re: [PATCH v10 08/12] kvm: Define EXPORT_STATIC_CALL_FOR_KVM()
From: Sean Christopherson @ 2026-04-16 22:44 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260414-vmscape-bhb-v10-8-efa924abae5f@linux.intel.com>
On Tue, Apr 14, 2026, Pawan Gupta wrote:
> EXPORT_SYMBOL_FOR_KVM() exists to export symbols to KVM modules. Static
> calls need the same treatment when the core kernel defines a static_call
> that KVM needs access to (e.g. from a VM-exit path).
>
> Define EXPORT_STATIC_CALL_FOR_KVM() as the static_call analogue of
> EXPORT_SYMBOL_FOR_KVM(). The same three-way logic applies:
>
> - KVM_SUB_MODULES defined: export to "kvm," plus all sub-modules
> - KVM=m, no sub-modules: export to "kvm" only
> - KVM built-in: no export needed (noop)
>
> As with EXPORT_SYMBOL_FOR_KVM(), allow architectures to override the
> definition (e.g. to suppress the export when kvm.ko itself will not be
> built despite CONFIG_KVM=m). Add the x86 no-op override in
> arch/x86/include/asm/kvm_types.h for that case.
>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> arch/x86/include/asm/kvm_types.h | 1 +
> include/linux/kvm_types.h | 13 ++++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/kvm_types.h b/arch/x86/include/asm/kvm_types.h
> index d7c704ed1be9..bceeaed2940e 100644
> --- a/arch/x86/include/asm/kvm_types.h
> +++ b/arch/x86/include/asm/kvm_types.h
> @@ -15,6 +15,7 @@
> * at least one vendor module is enabled.
> */
> #define EXPORT_SYMBOL_FOR_KVM(symbol)
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
> #endif
>
> #define KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE 40
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index a568d8e6f4e8..c81f4fdba625 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -13,6 +13,8 @@
> EXPORT_SYMBOL_FOR_MODULES(symbol, __stringify(KVM_SUB_MODULES))
> #define EXPORT_SYMBOL_FOR_KVM(symbol) \
> EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol) \
> + EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
> #else
> #define EXPORT_SYMBOL_FOR_KVM_INTERNAL(symbol)
> /*
> @@ -27,7 +29,16 @@
> #define EXPORT_SYMBOL_FOR_KVM(symbol)
> #endif /* IS_MODULE(CONFIG_KVM) */
> #endif /* EXPORT_SYMBOL_FOR_KVM */
> -#endif
> +
> +#ifndef EXPORT_STATIC_CALL_FOR_KVM
> +#if IS_MODULE(CONFIG_KVM)
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol) EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm")
> +#else
> +#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
> +#endif /* IS_MODULE(CONFIG_KVM) */
> +#endif /* EXPORT_STATIC_CALL_FOR_KVM */
> +
> +#endif /* KVM_SUB_MODULES */
I think I'd prefer to require EXPORT_SYMBOL_FOR_KVM and EXPORT_STATIC_CALL_FOR_KVM
to come as a pair from arch code. I can't think of a scenario where arch code
should override one but not the other. The end result is slightly less ugly :-)
---
arch/x86/include/asm/kvm_types.h | 1 +
include/linux/kvm_types.h | 10 +++++++++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_types.h b/arch/x86/include/asm/kvm_types.h
index d7c704ed1be9..bceeaed2940e 100644
--- a/arch/x86/include/asm/kvm_types.h
+++ b/arch/x86/include/asm/kvm_types.h
@@ -15,6 +15,7 @@
* at least one vendor module is enabled.
*/
#define EXPORT_SYMBOL_FOR_KVM(symbol)
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
#endif
#define KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE 40
diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
index a568d8e6f4e8..be602d3f287e 100644
--- a/include/linux/kvm_types.h
+++ b/include/linux/kvm_types.h
@@ -13,6 +13,8 @@
EXPORT_SYMBOL_FOR_MODULES(symbol, __stringify(KVM_SUB_MODULES))
#define EXPORT_SYMBOL_FOR_KVM(symbol) \
EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol) \
+ EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm," __stringify(KVM_SUB_MODULES))
#else
#define EXPORT_SYMBOL_FOR_KVM_INTERNAL(symbol)
/*
@@ -23,11 +25,17 @@
#ifndef EXPORT_SYMBOL_FOR_KVM
#if IS_MODULE(CONFIG_KVM)
#define EXPORT_SYMBOL_FOR_KVM(symbol) EXPORT_SYMBOL_FOR_MODULES(symbol, "kvm")
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol) EXPORT_STATIC_CALL_FOR_MODULES(symbol, "kvm")
#else
#define EXPORT_SYMBOL_FOR_KVM(symbol)
+#define EXPORT_STATIC_CALL_FOR_KVM(symbol)
#endif /* IS_MODULE(CONFIG_KVM) */
+#else
+#ifndef EXPORT_STATIC_CALL_FOR_KVM
+#error Must #define EXPORT_STATIC_CALL_FOR_KVM if #defining EXPORT_SYMBOL_FOR_KVM
+#endif
#endif /* EXPORT_SYMBOL_FOR_KVM */
-#endif
+#endif /* KVM_SUB_MODULES */
#ifndef __ASSEMBLER__
base-commit: 56b7ace84970ff647b095849e80bc36c094760aa
--
^ permalink raw reply related
* Re: [PATCH V10 00/10] famfs: port into fuse
From: Darrick J. Wong @ 2026-04-16 22:43 UTC (permalink / raw)
To: Dan Williams
Cc: Gregory Price, Joanne Koong, John Groves, Miklos Szeredi,
Bernd Schubert, John Groves, Dan J Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Randy Dunlap, Jeff Layton, Amir Goldstein, Jonathan Cameron,
Stefan Hajnoczi, Josef Bacik, Bagas Sanjaya, Chen Linxuan,
James Morse, Fuad Tabba, Sean Christopherson, Shivank Garg,
Ackerley Tng, Aravind Ramesh, Ajay Joshi, venkataravis@micron.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org,
linux-fsdevel@vger.kernel.org
In-Reply-To: <43d36427-4629-4712-a262-391e64006eb5@app.fastmail.com>
On Thu, Apr 16, 2026 at 01:53:27PM -0700, Dan Williams wrote:
>
>
> On Thu, Apr 16, 2026, at 1:14 PM, Gregory Price wrote:
> > On Thu, Apr 16, 2026 at 08:56:46AM -0700, Joanne Koong wrote:
> >> On Tue, Apr 14, 2026 at 5:10 PM John Groves <John@groves.net> wrote:
> >> >
> >> > There is a FUSE_DAX_FMAP capability that the kernel may advertise or not
> >> > at init time; this capability "is" the famfs GET_FMAP AND GET_DAXDEV
> >> > commands. In the future, if we find a way to use BPF (or some other
> >> > mechanism) to avoid needing those fuse messages, the kernel could be updated
> >> > to NEVER advertise the FUSE_DAX_FMAP capability. All of the famfs-specific
> >> > code could be taken out of kernels that never advertise that capability.
> >>
> >> I’m not sure the capability bit can be used like that (though I am
> >> hoping it can!). As I understand it, once the kernel advertises a
> >> capability, it must continue supporting it in future kernels else
> >> userspace programs that rely on it will break.
So don't break fuse servers. If you wanted to (say) get rid of
GET_FMAP in favor of IOMAP_BEGIN, you could alter libfuse to translate a
fuse server's ->get_fmap implementation into the equivalent
->iomap_begin, and eventually the kernel can stop making GET_FMAP calls
to userspace.
The trouble here is that I've also seen half a dozen projects vendoring
libfuse so that's a nightmare that will have to be dealt with. But
maybe that doesn't even matter, because...
> > FUSE_DAX_FMAP is already conditional on CONFIG_FUSE_DAX, the kernel is
> > not required to continue advertising FUSE_DAX_FMAP in perpetuity.
> >
> > Setting CONFIG_FUSE_DAX=n does not mean userland "is broken", this would
> > only be the case if FUSE_DAX_FMAP was advertised but not actually
> > supported.
...the memory interleaving is a rather interesting quality of famfs.
There's no good way to express a formulaic meta-mapping in traditional
iomap parlance, and famfs needs that to interleave across memory
controllers/dimm boxen/whatever. Throwing individual iomaps at the
kernel is a very inefficient way to do that. So I don't think there's a
good reason to get rid of GET_FMAP at this time...
> > If DAX were removed from the kernel (unlikely, but stick with me) this
> > would be equivalent to permanently changing CONFIG_FUSE_DAX to always
> > off, and there would be no squabbles over whether that particular
> > change broke userland (there would be much strife over removing dax).
...however the strongest case (IMO) would be if (having merged famfs) we
then merge fuse-iomap after famfs. Then we extend the existing
fuse-iomap-bpf prototype to allow per-mount and per-inode iomap bpf ops.
That enables us to analyze thoroughly the performance characteristics of:
a) Using GET_FMAP as-is
b) Uploading raw iomaps (HA)
c) Uploading a single bpf program to make iomaps, exchanging fmap-style
mapping data into a bpf map, and having the single bpf program walk
through the map
d) Uploading a custom bpf program per famfs file to make iomaps. No
bpfmap required, but the setup and compilation are now much more complex
Then we'll finally know which approach is the best, having broken the
Gordian Knot of how to merge famfs and fuse-iomap.
If we decide that (c) or (d) are actually better, then guess what? To
get any of the iomap functionality, you have to set an inode flag, and
that (FUSE_CAP_FAMFS && FUSE_CAP_IOMAP && FUSE_ATTR_IOMAP) is the signal
for "don't call GET_FMAP". FUSE_CAP_FAMFS && (!FUSE_CAP_IOMAP ||
!FUSE_ATTR_IOMAP) means "call GET_FMAP".
Yes, we burn a couple of fuse command values to find out, but that's all.
(TBH I still dislike GET_DAXDEV, that really should just be another
application of backing files, and the backing file id gets passed to
GET_FMAP.)
What do you all think of doing that?
> > While not a deprecation method, this is what capability bits are
> > designed for. Same as cpuid capability bits - just because the bit is
> > there doesn't mean a processor is required to support it in perpetuity.
> >
> > They're only required to support it if the bit is turned on.
> >
>
> Right, if the protocol on day one is "user space must ask which method
> is available", then userspace can not be surprised when one option
> disappears. So to give time for the bpf approach to mature the kernel
> can do something like "famfs and bpf mapping support are available".
> In some future kernel the famfs native option disappears after a
> deprecation period.
>
> When folks ask 10 years from now why this ever supported optionality
> the explanation is "oh because famfs enjoyed first mover advantage to
> prove out fs semantics layered on dax devices", or "turns out there
> are some cases where bpf is not fast enough but it still stops the
> proliferation of more in kernel mapping implementations".
Yes. We're not *capable* of determining the best mechanism unless we
can start shipping these things to users to get their feedback. Only
then can we iterate and make real improvements.
> Something like FUSE_DAX_FMAP is always available but the backend to
> that is optionally native vs bpf. ...or some other arrangement to make
> it clear that native might be gone someday.
--D
^ permalink raw reply
* Re: [PATCH v11 07/20] gpu: nova-core: mm: Add TLB flush support
From: Joel Fernandes @ 2026-04-16 22:18 UTC (permalink / raw)
To: Danilo Krummrich
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <DHUWPQX14ZGZ.26BV7GQCJDZQI@kernel.org>
On 4/16/2026 5:45 PM, Danilo Krummrich wrote:
> On Thu Apr 16, 2026 at 11:23 PM CEST, Joel Fernandes wrote:
>> Btw, I changed this to doing it in 2 phases to avoid holding the RCU readlock
>> across read_poll_timeout, which can sleep. Will squash it in for v12.
>
> Why do we need the try_access() dance in the first place? I assume this ends up
> being called from the BarAccess destructor?
BarAccess is different. The try_access() calls here are in tlb.rs and
pramin.rs for Bar0. BarAccess uses &'a Bar1 directly — its Drop impl just
calls self.vmm.unmap_pages(self.mm, mapped), without needing try_access().
>
> If so, I think this is solvable. Gary and me are currently working on
> higher-ranked types and a chained Devres type.
Hmm, the issue here is we cannot hold revocable guard while sleeping, but
we have read the bar as a condition in the body of the poll. So I split the
try_access()'es. First phase for writing and second for reading (bar 0).
>
> With that, such use-cases should be cleanly solvable without the need for
> try_access().
>
> Besides that, I can't find where BarAccess is ever constructed.
BarUser::map() constructs it.
https://lore.kernel.org/all/20260415210548.3776595-18-joelagnelf@nvidia.com/
>
> It already has a lifetime 'a for &'a Bar1, so I don't see why you can't do the
> same for Bar0.>
> But again, I don't see this being constructed and I'm not sure the whole
> construct works in the first place.
BarAccess uses &'a Bar1 because it's a short-lived scoped object. In long
lived objects I am trying to avoid this. I guess I would be Ok with
switching &'a Bar1 to Devres as well. But let me know your suggestions!
If it is easier to look at a git tree to get a complete picture, here is
the git tag of v11:
https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/tag/?h=nova-mm-v11-20260415
Thanks.
^ permalink raw reply
* Re: [PATCH v11 07/20] gpu: nova-core: mm: Add TLB flush support
From: Danilo Krummrich @ 2026-04-16 21:45 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260416212312.GA667928@joelbox2>
On Thu Apr 16, 2026 at 11:23 PM CEST, Joel Fernandes wrote:
> Btw, I changed this to doing it in 2 phases to avoid holding the RCU readlock
> across read_poll_timeout, which can sleep. Will squash it in for v12.
Why do we need the try_access() dance in the first place? I assume this ends up
being called from the BarAccess destructor?
If so, I think this is solvable. Gary and me are currently working on
higher-ranked types and a chained Devres type.
With that, such use-cases should be cleanly solvable without the need for
try_access().
Besides that, I can't find where BarAccess is ever constructed.
It already has a lifetime 'a for &'a Bar1, so I don't see why you can't do the
same for Bar0.
But again, I don't see this being constructed and I'm not sure the whole
construct works in the first place.
^ permalink raw reply
* Re: [PATCH 0/8] Auto-generate maintainer profile entries
From: Randy Dunlap @ 2026-04-16 21:32 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Albert Ou, Jonathan Corbet, Mauro Carvalho Chehab, Palmer Dabbelt,
Paul Walmsley, linux-doc, linux-kernel, linux-riscv, workflows,
Alexandre Ghiti, Shuah Khan, Dan Williams
In-Reply-To: <20260416100026.3df67a72@foz.lan>
On 4/16/26 1:00 AM, Mauro Carvalho Chehab wrote:
> On Wed, 15 Apr 2026 13:41:16 -0700
> Randy Dunlap <rdunlap@infradead.org> wrote:
>
>> Hi Mauro,
>>
>> Thanks for tackling this issue.
>>
>> On 4/15/26 1:52 AM, Mauro Carvalho Chehab wrote:
>>> Date: Tue, 14 Apr 2026 16:29:03 +0200
>>> From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>>> To: Albert Ou <aou@eecs.berkeley.edu>, Jonathan Corbet <corbet@lwn.net>, Dan Williams <djbw@kernel.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <pjw@kernel.org>
>>> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Randy Dunlap <rdunlap@infradead.org>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, workflows@vger.kernel.org, Alexandre Ghiti <alex@ghiti.fr>, Shuah Khan <skhan@linuxfoundation.org>
>>> Message-ID: <cover.1776176108.git.mchehab+huawei@kernel.org>
>>>
>>> Hi Dan/Jon,
>>>
>>> This patch series change the way maintainer entry profile links
>>> are added to the documentation. Instead of having an entry for
>>> each of them at an ReST file, get them from MAINTAINERS content.
>>>
>>> That should likely make easier to maintain, as there will be a single
>>> point to place all such profiles.
>>>
>>> On this version, I added Dan's text to patch 4.
>>>
>>> I also added a couple of other patches to improve its output. While
>>> I could have them merged at the first patch, I opted to make them
>>> separate, as, in case of problems or needed changes, it would be
>>> easier to revert or modify the corresponding logic. Also, it should
>>> be better to review, in case one wants some changes there.
>>>
>>> The main changes against RFC are:
>>>
>>> - now, the TOC will be presented with 1 depth identation level,
>>> meaning that it would look like a list;
>>> - for files outside Documentation/process, it will use the name of
>>> the subsystem with title capitalization for the name of the
>>> profile entry;
>>> - the logic also parses and produces a list of profiles that are
>>> maintained elsewhere, picking its http/https link;
>>> - entries are now better sorted: first by subsystem name, then
>>> by its name.
>>>
>>> Suggested-by: Dan Williams <djbw@kernel.org>
>>> Closes: https://lore.kernel.org/linux-doc/69dd6299440be_147c801005b@djbw-dev.notmuch/
>>>
>>> Mauro Carvalho Chehab (8):
>>> docs: maintainers_include: auto-generate maintainer profile TOC
>>> MAINTAINERS: add an entry for media maintainers profile
>>> MAINTAINERS: add maintainer-tip.rst to X86
>>> docs: auto-generate maintainer entry profile links
>>> docs: maintainers_include: use a better title for profiles
>>> docs: maintainers_include: add external profile URLs
>>> docs: maintainers_include: preserve names for files under process/
>>> docs: maintainers_include: Only show main entry for profiles
>>>
>>> .../maintainer/maintainer-entry-profile.rst | 24 +---
>>> .../process/maintainer-handbooks.rst | 17 ++-
>>> Documentation/sphinx/maintainers_include.py | 131 +++++++++++++++---
>>> MAINTAINERS | 2 +
>>> 4 files changed, 128 insertions(+), 46 deletions(-)
>>
>> When building htmldocs with O=DOCS, I get a bunch of warnings.
>> I tested against today's linux-next tree.
>>
>> The 'make O=DOCS htmldocs' warnings are (subset of all warnings):
>>
>> linux-next/MAINTAINERS:38: WARNING: toctree contains reference to nonexisting document 'DOCS/Documentation/process/maintainer-kvm-x86' [toc.not_readable]
>> linux-next/MAINTAINERS:38: WARNING: toctree contains reference to nonexisting document 'DOCS/Documentation/filesystems/xfs/xfs-maintainer-entry-profile' [toc.not_readable]
>> linux-next/MAINTAINERS:38: WARNING: toctree contains reference to nonexisting document 'DOCS/Documentation/process/maintainer-soc-clean-dts' [toc.not_readable]
>> linux-next/MAINTAINERS:38: WARNING: toctree contains reference to nonexisting document 'DOCS/Documentation/process/maintainer-netdev' [toc.not_readable]
>> linux-next/MAINTAINERS:38: WARNING: toctree contains reference to nonexisting document 'DOCS/Documentation/process/maintainer-tip' [toc.not_readable]
>>
>> linux-next/Documentation/filesystems/nfs/nfsd-maintainer-entry-profile.rst: WARNING: document isn't included in any toctree [toc.not_included]
>> linux-next/Documentation/process/maintainer-kvm-x86.rst: WARNING: document isn't included in any toctree [toc.not_included]
>> linux-next/Documentation/process/maintainer-netdev.rst: WARNING: document isn't included in any toctree [toc.not_included]
>> linux-next/Documentation/process/maintainer-soc.rst: WARNING: document isn't included in any toctree [toc.not_included]
>> linux-next/Documentation/process/maintainer-soc-clean-dts.rst: WARNING: document isn't included in any toctree [toc.not_included]
>> linux-next/Documentation/process/maintainer-tip.rst: WARNING: document isn't included in any toctree [toc.not_included]
>>
>> linux-next/MAINTAINERS:1: WARNING: unknown document: '../../DOCS/Documentation/process/maintainer-soc' [ref.doc]
>> linux-next/MAINTAINERS:2: WARNING: unknown document: '../../DOCS/Documentation/process/maintainer-soc-clean-dts' [ref.doc]
>> linux-next/MAINTAINERS:3: WARNING: unknown document: '../../DOCS/Documentation/process/maintainer-soc-clean-dts' [ref.doc]
>> linux-next/MAINTAINERS:5: WARNING: unknown document: '../../DOCS/Documentation/process/maintainer-tip' [ref.doc]
>> linux-next/MAINTAINERS:6: WARNING: unknown document: '../../DOCS/Documentation/process/maintainer-tip' [ref.doc]
>
> Heh, os.path.relpath() does the wrong thing here.
>
> The enclosed patch should handle it better.
>
> Thanks,
> Mauro
>
> [PATCH] docs: maintainers_include: fix support for O=dir
>
> os.path.relpath() will do the wrong thing with O=dir, as the build
> system uses "cd <dir>" internally.
>
> Solve it by using app.srcdir, which, on normal cases, point to
> Documentation/, or, when SPHINXDIRS=process, it will be set with
> Documentation/process.
>
> While here, remove a dead code while writing maintainer profiles,
> as now all entries should have both profile and entry.
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Closes: https://lore.kernel.org/linux-doc/88335220-3527-4b1f-9500-417f7ebb7a02@infradead.org/T/#m6854cbd8d30e2c5d3e8c4173bae1c3d6922ff970
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>
> diff --git a/Documentation/sphinx/maintainers_include.py b/Documentation/sphinx/maintainers_include.py
> index 5413c1350bba..fff9bdd55a56 100755
> --- a/Documentation/sphinx/maintainers_include.py
> +++ b/Documentation/sphinx/maintainers_include.py
> @@ -27,15 +27,24 @@ from docutils import statemachine
> from docutils.parsers.rst import Directive
> from docutils.parsers.rst.directives.misc import Include
>
> +#
> +# Base URL for intersphinx-like links to maintainer profiles
> +#
> +KERNELDOC_URL = "https://docs.kernel.org/"
> +
> def ErrorString(exc): # Shamelessly stolen from docutils
> return f'{exc.__class__.__name}: {exc}'
>
> __version__ = '1.0'
>
> +base_dir = "."
> +
> class MaintainersParser:
> """Parse MAINTAINERS file(s) content"""
>
> - def __init__(self, base_path, path):
> + def __init__(self, path):
> + global base_dir
> +
> self.profile_toc = set()
> self.profile_entries = {}
>
> @@ -76,9 +85,18 @@ class MaintainersParser:
> #
> # Handle profile entries - either as files or as https refs
> #
> - match = re.match(r"P:\s*(Documentation/\S+)\.rst", line)
> + match = re.match(r"P:\s*Documentation(/\S+)\.rst", line)
> if match:
> - entry = os.path.relpath(match.group(1), base_path)
> + entry = os.path.relpath(match.group(1), base_dir)
> +
> + #
> + # When SPHINXDIRS is used, it will try to reference files
> + # outside srctree, causing warnings. To avoid that, point
> + # to the latest official documentation
> + #
> + if entry.startswith("../"):
> + entry = KERNELDOC_URL + match.group(1) + ".html"
> +
> if "*" in entry:
> for e in glob(entry):
> self.profile_toc.add(e)
> @@ -189,10 +207,10 @@ class MaintainersInclude(Include):
> """MaintainersInclude (``maintainers-include``) directive"""
> required_arguments = 0
>
> - def emit(self, base_path, path):
> + def emit(self, path):
> """Parse all the MAINTAINERS lines into ReST for human-readability"""
>
> - output = MaintainersParser(base_path, path).output
> + output = MaintainersParser(path).output
>
> # For debugging the pre-rendered results...
> #print(output, file=open("/tmp/MAINTAINERS.rst", "w"))
> @@ -213,11 +231,10 @@ class MaintainersInclude(Include):
>
> # Append "MAINTAINERS"
> path = os.path.join(path, "MAINTAINERS")
> - base_path = os.path.dirname(self.state.document.document.current_source)
>
> try:
> self.state.document.settings.record_dependencies.add(path)
> - lines = self.emit(base_path, path)
> + lines = self.emit(path)
> except IOError as error:
> raise self.severe('Problems with "%s" directive path:\n%s.' %
> (self.name, ErrorString(error)))
> @@ -227,27 +244,20 @@ class MaintainersInclude(Include):
> class MaintainersProfile(Include):
> required_arguments = 0
>
> - def emit(self, base_path, path):
> + def emit(self, path):
> """Parse all the MAINTAINERS lines looking for profile entries"""
>
> - maint = MaintainersParser(base_path, path)
> + maint = MaintainersParser(path)
>
> #
> # Produce a list with all maintainer profiles, sorted by subsystem name
> #
> output = ""
> -
> - for profile, entry in maint.profile_entries.items():
> + for profile, entry in sorted(maint.profile_entries.items()):
> if entry.startswith("http"):
> - if profile:
> - output += f"- `{profile} <{entry}>`_\n"
> - else:
> - output += f"- `<{entry}>_`\n"
> + output += f"- `{profile} <{entry}>`_\n"
> else:
> - if profile:
> - output += f"- :doc:`{profile} <{entry}>`\n"
> - else:
> - output += f"- :doc:`<{entry}>`\n"
> + output += f"- :doc:`{profile} <{entry}>`\n"
>
> #
> # Create a hidden TOC table with all profiles. That allows adding
> @@ -277,11 +287,10 @@ class MaintainersProfile(Include):
>
> # Append "MAINTAINERS"
> path = os.path.join(path, "MAINTAINERS")
> - base_path = os.path.dirname(self.state.document.document.current_source)
>
> try:
> self.state.document.settings.record_dependencies.add(path)
> - lines = self.emit(base_path, path)
> + lines = self.emit(path)
> except IOError as error:
> raise self.severe('Problems with "%s" directive path:\n%s.' %
> (self.name, ErrorString(error)))
> @@ -289,6 +298,15 @@ class MaintainersProfile(Include):
> return []
>
> def setup(app):
> + global base_dir
> +
> + #
> + # partition will pick the path after Documentation.
> + # NOTE: we're using os.fspath() here because of a Sphinx warning:
> + # RemovedInSphinx90Warning: Sphinx 9 will drop support for representing paths as strings. Use "pathlib.Path" or "os.fspath" instead.
> + #
> + _, _, base_dir = os.fspath(app.srcdir).partition("Documentation")
> +
> app.add_directive("maintainers-include", MaintainersInclude)
> app.add_directive("maintainers-profile-toc", MaintainersProfile)
> return dict(
With that patch I still see 6 warnings:
linux-next/Documentation/filesystems/nfs/nfsd-maintainer-entry-profile.rst: WARNING: document isn't included in any toctree [toc.not_included]
linux-next/Documentation/process/maintainer-kvm-x86.rst: WARNING: document isn't included in any toctree [toc.not_included]
linux-next/Documentation/process/maintainer-netdev.rst: WARNING: document isn't included in any toctree [toc.not_included]
linux-next/Documentation/process/maintainer-soc.rst: WARNING: document isn't included in any toctree [toc.not_included]
linux-next/Documentation/process/maintainer-soc-clean-dts.rst: WARNING: document isn't included in any toctree [toc.not_included]
linux-next/Documentation/process/maintainer-tip.rst: WARNING: document isn't included in any toctree [toc.not_included]
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Conor Dooley @ 2026-04-16 21:31 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alexis Czezar Torreno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, linux-hwmon,
devicetree, linux-kernel, linux-doc
In-Reply-To: <84a5154f-1139-425e-94ae-31d7e662cd0e@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]
On Thu, Apr 16, 2026 at 11:01:49AM -0700, Guenter Roeck wrote:
> On Thu, Apr 16, 2026 at 04:51:37PM +0100, Conor Dooley wrote:
> > On Thu, Apr 16, 2026 at 03:59:10PM +0800, Alexis Czezar Torreno wrote:
> > > Add device tree documentation for MAX20830 step-down DC-DC switching
> > > regulator with PMBus interface.
> > >
> > > Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> > > ---
> > > .../bindings/hwmon/pmbus/adi,max20830.yaml | 61 ++++++++++++++++++++++
> > > MAINTAINERS | 7 +++
> > > 2 files changed, 68 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..8b3ec1ffa0c9460de2122f6606ce3dcbcdfbbcc7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> > > @@ -0,0 +1,61 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/hwmon/pmbus/adi,max20830.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Analog Devices MAX20830 Step-Down Switching Regulator with PMBus
> > > +
> > > +maintainers:
> > > + - Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> > > +
> > > +description: |
> > > + The MAX20830 is a fully integrated step-down DC-DC switching regulator with
> > > + PMBus interface. It provides 2.7V to 16V input, 0.4V to 5.8V adjustable
> > > + output, and up to 30A output current. It allows monitoring of input/output
> > > + voltage, output current and temperature through the PMBus serial interface.
> > > + Datasheet:
> > > + https://www.analog.com/en/products/max20830.html
> > > +
> > > +allOf:
> > > + - $ref: /schemas/regulator/regulator.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + const: adi,max20830
> > > +
> > > + reg:
> > > + maxItems: 1
> >
> > On the previous version, you got an LLM comment about not having the
> > interrupts property amongst other things.
> > I think the other things got implemented, but I didn't see any reply to
> > the bot about that?
> > I think the answer is that it shouldn't because the pin it referenced
> > doesn't exist, but when looking at the schematic I have to wonder if
>
> I had to look this up in the datasheet. A SMBus chip with no alert pin is
> a bit odd, but you are correct.
>
> > there should be an interrupts property for dealing with "pgood"?
> >
> FWIW, I have never seen that. Normally such pins are used to take devices
> out of reset.
It's an output on this device seemingly. I don't care if the driver
ignores it, but for completeness (and we like completeness with
bindings) I think it should be documented as an interrupt or gpio.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v11 07/20] gpu: nova-core: mm: Add TLB flush support
From: Joel Fernandes @ 2026-04-16 21:23 UTC (permalink / raw)
To: linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260415210548.3776595-7-joelagnelf@nvidia.com>
On Wed, Apr 15, 2026 at 05:05:34PM -0400, Joel Fernandes wrote:
> Add TLB (Translation Lookaside Buffer) flush support for GPU MMU.
>
> After modifying page table entries, the GPU's TLB must be invalidated
> to ensure the new mappings take effect. The Tlb struct provides flush
> functionality through BAR0 registers.
>
> The flush operation writes the page directory base address and triggers
> an invalidation, polling for completion with a 2 second timeout matching
> the Nouveau driver.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/mm.rs | 1 +
> drivers/gpu/nova-core/mm/tlb.rs | 97 +++++++++++++++++++++++++++++++++
> drivers/gpu/nova-core/regs.rs | 44 +++++++++++++++
> 3 files changed, 142 insertions(+)
> create mode 100644 drivers/gpu/nova-core/mm/tlb.rs
>
> diff --git a/drivers/gpu/nova-core/mm.rs b/drivers/gpu/nova-core/mm.rs
> index fa29f525f282..314d660d898b 100644
> --- a/drivers/gpu/nova-core/mm.rs
> +++ b/drivers/gpu/nova-core/mm.rs
> @@ -25,6 +25,7 @@ fn from(pfn: Pfn) -> Self {
> }
>
> pub(crate) mod pramin;
> +pub(super) mod tlb;
>
> use kernel::{
> bitfield,
> diff --git a/drivers/gpu/nova-core/mm/tlb.rs b/drivers/gpu/nova-core/mm/tlb.rs
> new file mode 100644
> index 000000000000..6d384f447635
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm/tlb.rs
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! TLB (Translation Lookaside Buffer) flush support for GPU MMU.
> +//!
> +//! After modifying page table entries, the GPU's TLB must be flushed to
> +//! ensure the new mappings take effect. This module provides TLB flush
> +//! functionality for virtual memory managers.
> +//!
> +//! # Examples
> +//!
> +//! ```ignore
> +//! use crate::mm::tlb::Tlb;
> +//!
> +//! fn page_table_update(tlb: &Tlb, pdb_addr: VramAddress) -> Result<()> {
> +//! // ... modify page tables ...
> +//!
> +//! // Flush TLB to make changes visible (polls for completion).
> +//! tlb.flush(pdb_addr)?;
> +//!
> +//! Ok(())
> +//! }
> +//! ```
> +
> +use kernel::{
> + devres::Devres,
> + io::poll::read_poll_timeout,
> + io::Io,
> + new_mutex,
> + prelude::*,
> + sync::{
> + Arc,
> + Mutex, //
> + },
> + time::Delta, //
> +};
> +
> +use crate::{
> + driver::Bar0,
> + mm::VramAddress,
> + regs, //
> +};
> +
> +/// TLB manager for GPU translation buffer operations.
> +#[pin_data]
> +pub(crate) struct Tlb {
> + bar: Arc<Devres<Bar0>>,
> + /// TLB flush serialization lock: This lock is designed to be acquired during
> + /// the DMA fence signalling critical path. It should NEVER be held across any
> + /// reclaimable CPU memory allocations because the memory reclaim path can
> + /// call `dma_fence_wait()` (when implemented), which would deadlock if lock held.
> + #[pin]
> + lock: Mutex<()>,
> +}
> +
> +impl Tlb {
> + /// Create a new TLB manager.
> + pub(super) fn new(bar: Arc<Devres<Bar0>>) -> impl PinInit<Self> {
> + pin_init!(Self {
> + bar,
> + lock <- new_mutex!((), "tlb_flush"),
> + })
> + }
> +
> + /// Flush the GPU TLB for a specific page directory base.
> + ///
> + /// This invalidates all TLB entries associated with the given PDB address.
> + /// Must be called after modifying page table entries to ensure the GPU sees
> + /// the updated mappings.
> + pub(super) fn flush(&self, pdb_addr: VramAddress) -> Result {
> + let _guard = self.lock.lock();
> +
> + let bar = self.bar.try_access().ok_or(ENODEV)?;
> +
> + // Write PDB address.
> + bar.write_reg(regs::NV_TLB_FLUSH_PDB_LO::from_pdb_addr(pdb_addr.raw_u64()));
> + bar.write_reg(regs::NV_TLB_FLUSH_PDB_HI::from_pdb_addr(pdb_addr.raw_u64()));
> +
> + // Trigger flush: invalidate all pages, require global acknowledgment
> + // from all engines before completion.
> + bar.write_reg(
> + regs::NV_TLB_FLUSH_CTRL::zeroed()
> + .with_page_all(true)
> + .with_ack_globally(true)
> + .with_enable(true),
> + );
> +
> + // Poll for completion - enable bit clears when flush is done.
> + read_poll_timeout(
> + || Ok(bar.read(regs::NV_TLB_FLUSH_CTRL)),
> + |ctrl: ®s::NV_TLB_FLUSH_CTRL| !ctrl.enable(),
> + Delta::ZERO,
> + Delta::from_secs(2),
> + )?;
> +
> + Ok(())
> + }
> +}
Btw, I changed this to doing it in 2 phases to avoid holding the RCU readlock
across read_poll_timeout, which can sleep. Will squash it in for v12.
---8<-----------------------
diff --git a/drivers/gpu/nova-core/mm/tlb.rs b/drivers/gpu/nova-core/mm/tlb.rs
index 6d384f447635..3a65db7d9a1a 100644
--- a/drivers/gpu/nova-core/mm/tlb.rs
+++ b/drivers/gpu/nova-core/mm/tlb.rs
@@ -69,24 +69,35 @@ pub(super) fn new(bar: Arc<Devres<Bar0>>) -> impl PinInit<Self> {
pub(super) fn flush(&self, pdb_addr: VramAddress) -> Result {
let _guard = self.lock.lock();
- let bar = self.bar.try_access().ok_or(ENODEV)?;
+ // Broken into 2 phases with scopes (Write and Poll) to avoid holding
+ // RevecablableGuard (and hence RCU read-side critical section) across
+ // the read_poll_timeout() call that can sleep.
- // Write PDB address.
- bar.write_reg(regs::NV_TLB_FLUSH_PDB_LO::from_pdb_addr(pdb_addr.raw_u64()));
- bar.write_reg(regs::NV_TLB_FLUSH_PDB_HI::from_pdb_addr(pdb_addr.raw_u64()));
+ // Write phase — hold bar access briefly for register writes only.
+ {
+ let bar = self.bar.try_access().ok_or(ENODEV)?;
- // Trigger flush: invalidate all pages, require global acknowledgment
- // from all engines before completion.
- bar.write_reg(
- regs::NV_TLB_FLUSH_CTRL::zeroed()
- .with_page_all(true)
- .with_ack_globally(true)
- .with_enable(true),
- );
+ // Write PDB address.
+ bar.write_reg(regs::NV_TLB_FLUSH_PDB_LO::from_pdb_addr(pdb_addr.raw_u64()));
+ bar.write_reg(regs::NV_TLB_FLUSH_PDB_HI::from_pdb_addr(pdb_addr.raw_u64()));
- // Poll for completion - enable bit clears when flush is done.
+ // Trigger flush: invalidate all pages, require global acknowledgment
+ // from all engines before completion.
+ bar.write_reg(
+ regs::NV_TLB_FLUSH_CTRL::zeroed()
+ .with_page_all(true)
+ .with_ack_globally(true)
+ .with_enable(true),
+ );
+ }
+
+ // Poll for completion — re-acquire bar access each iteration to avoid
+ // holding the RCU read-side lock (via RevocableGuard) across sleep.
read_poll_timeout(
- || Ok(bar.read(regs::NV_TLB_FLUSH_CTRL)),
+ || {
+ let bar = self.bar.try_access().ok_or(ENODEV)?;
+ Ok(bar.read(regs::NV_TLB_FLUSH_CTRL))
+ },
|ctrl: ®s::NV_TLB_FLUSH_CTRL| !ctrl.enable(),
Delta::ZERO,
Delta::from_secs(2),
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 1/8] ARM: zte: Add zx297520v3 platform support
From: Randy Dunlap @ 2026-04-16 21:17 UTC (permalink / raw)
To: Stefan Dösinger, Jonathan Corbet, Shuah Khan, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial
In-Reply-To: <20260416-send-v4-1-e19d02b944ec@gmail.com>
On 4/16/26 1:19 PM, Stefan Dösinger wrote:
> diff --git a/arch/arm/mach-zte/Kconfig b/arch/arm/mach-zte/Kconfig
> new file mode 100644
> index 000000000000..24699256863b
> --- /dev/null
> +++ b/arch/arm/mach-zte/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0
> +menuconfig ARCH_ZTE
> + bool "ZTE zx family"
> + depends on ARCH_MULTI_V7
> + help
> + Support for ZTE zx-based family of processors.
> +
> +if ARCH_ZTE
> +
> +config SOC_ZX297520V3
> + default y if ARCH_ZTE
> + bool "ZX297520v3"
> + select ARM_GIC_V3
> + select ARM_AMBA
> + select HAVE_ARM_ARCH_TIMER
> + select PM_GENERIC_DOMAINS if PM
> + help
> + Support for ZTE zx297520v3 SoC. It a single core SoC used in cheap LTE to WiFi routers.
It is
> + These devices can be Identified by the occurrence of the string "zx297520v3" in the boot
identified
> + output and /proc/cpuinfo of their stock firmware.
> +
> + Please read Documentation/arch/arm/zte/zx297520v3.rst on how to boot the kernel.
--
~Randy
^ permalink raw reply
* Re: [PATCH] docs: staging: fix various typos and grammar issues
From: Randy Dunlap @ 2026-04-16 21:10 UTC (permalink / raw)
To: Zhang Xiaolei, corbet, ebiggers, andersson, mathieu.poirier
Cc: ardb, skhan, linux-crypto, linux-doc, linux-remoteproc,
linux-kernel
In-Reply-To: <20260416105854.788-1-zxl434815272@gmail.com>
On 4/16/26 3:58 AM, Zhang Xiaolei wrote:
> Fix a few typographical and grammatical issues across several
> staging documentation files to improve readability:
> - crc32.rst: replace "decide in" with "decide on"
> - lzo.rst: replace "independent on" with "independent of"
> - remoteproc.rst: fix word order in dependent clause
> - static-keys.rst: add hyphen to "low-level"
>
> Signed-off-by: Zhang Xiaolei <zxl434815272@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> Documentation/staging/crc32.rst | 2 +-
> Documentation/staging/lzo.rst | 2 +-
> Documentation/staging/remoteproc.rst | 2 +-
> Documentation/staging/static-keys.rst | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/staging/crc32.rst b/Documentation/staging/crc32.rst
> index 64f3dd430a6c..fc0d9564b99c 100644
> --- a/Documentation/staging/crc32.rst
> +++ b/Documentation/staging/crc32.rst
> @@ -119,7 +119,7 @@ the byte-at-a-time table method, popularized by Dilip V. Sarwate,
> v.31 no.8 (August 1988) p. 1008-1013.
>
> Here, rather than just shifting one bit of the remainder to decide
> -in the correct multiple to subtract, we can shift a byte at a time.
> +on the correct multiple to subtract, we can shift a byte at a time.
> This produces a 40-bit (rather than a 33-bit) intermediate remainder,
> and the correct multiple of the polynomial to subtract is found using
> a 256-entry lookup table indexed by the high 8 bits.
> diff --git a/Documentation/staging/lzo.rst b/Documentation/staging/lzo.rst
> index f65b51523014..2d48b2667dd2 100644
> --- a/Documentation/staging/lzo.rst
> +++ b/Documentation/staging/lzo.rst
> @@ -75,7 +75,7 @@ Description
> are called under the assumption that a certain number of bytes follow
> because it has already been guaranteed before parsing the instructions.
> They just have to "refill" this credit if they consume extra bytes. This
> - is an implementation design choice independent on the algorithm or
> + is an implementation design choice independent of the algorithm or
> encoding.
>
> Versions
> diff --git a/Documentation/staging/remoteproc.rst b/Documentation/staging/remoteproc.rst
> index 5c226fa076d6..c117b060e76c 100644
> --- a/Documentation/staging/remoteproc.rst
> +++ b/Documentation/staging/remoteproc.rst
> @@ -24,7 +24,7 @@ handlers, and then all rpmsg drivers will then just work
> (for more information about the virtio-based rpmsg bus and its drivers,
> please read Documentation/staging/rpmsg.rst).
> Registration of other types of virtio devices is now also possible. Firmwares
> -just need to publish what kind of virtio devices do they support, and then
> +just need to publish what kind of virtio devices they support, and then
> remoteproc will add those devices. This makes it possible to reuse the
> existing virtio drivers with remote processor backends at a minimal development
> cost.
> diff --git a/Documentation/staging/static-keys.rst b/Documentation/staging/static-keys.rst
> index b0a519f456cf..e8dc3a87c381 100644
> --- a/Documentation/staging/static-keys.rst
> +++ b/Documentation/staging/static-keys.rst
> @@ -90,7 +90,7 @@ out-of-line true branch. Thus, changing branch direction is expensive but
> branch selection is basically 'free'. That is the basic tradeoff of this
> optimization.
>
> -This lowlevel patching mechanism is called 'jump label patching', and it gives
> +This low-level patching mechanism is called 'jump label patching', and it gives
> the basis for the static keys facility.
>
> Static key label API, usage and examples
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 10/10] ipe: Add BPF program load policy enforcement via Hornet integration
From: Fan Wu @ 2026-04-16 21:03 UTC (permalink / raw)
To: Blaise Boscaccy
Cc: Jonathan Corbet, Paul Moore, James Morris, Serge E. Hallyn,
Mickaël Salaün, Günther Noack,
Dr. David Alan Gilbert, Andrew Morton, James.Bottomley, dhowells,
Fan Wu, Ryan Foster, Randy Dunlap, linux-security-module,
linux-doc, linux-kernel, bpf, Song Liu
In-Reply-To: <20260416173500.176716-11-bboscaccy@linux.microsoft.com>
On Thu, Apr 16, 2026 at 10:35 AM Blaise Boscaccy
<bboscaccy@linux.microsoft.com> wrote:
>
> Add support for the bpf_prog_load_post_integrity LSM hook, enabling IPE
> to make policy decisions about BPF program loading based on integrity
> verdicts provided by the Hornet LSM.
>
> New policy operation:
> op=BPF_PROG_LOAD - Matches BPF program load events
>
> New policy properties:
> bpf_signature=NONE - No Verdict
> bpf_signature=OK - Program signature and map hashes verified
> bpf_signature=UNSIGNED - No signature provided
> bpf_signature=PARTIALSIG - Signature OK but no map hash data
> bpf_signature=UNKNOWNKEY - Cert not trusted
> bpf_signature=UNEXPECTED - An unexpected hash value was encountered
> bpf_signature=FAULT - System error during verification
> bpf_signature=BADSIG - Signature or map hash verification failed
> bpf_keyring=BUILTIN - Program was signed using a builtin keyring
> bpf_keyring=SECONDARY - Program was signed using the secondary keyring
> bpf_keyring=PLATFORM - Program was signed using the platform keyring
> bpf_kernel=TRUE - Program originated from kernelspace
> bpf_kernel=FALSE - Program originated from userspace
>
> These properties map directly to the lsm_integrity_verdict enum values
> provided by the Hornet LSM through security_bpf_prog_load_post_integrity.
>
> The feature is gated on CONFIG_IPE_PROP_BPF_SIGNATURE which depends on
> CONFIG_SECURITY_HORNET.
>
> Example policy for bpf signature enforcement:
> DEFAULT op=BPF_PROG_LOAD action=DENY
> op=BPF_PROG_LOAD is_kernel=TRUE action=ALLOW
> op=BPF_PROG_LOAD bpf_signature=OK action=ALLOW
>
> Signed-off-by: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
Hi Blaise,
I have not finished reviewing the code yet, so I do not have
implementation comments at this point.
Since this code introduces new policy semantics, it would be helpful
to also reflect that in the IPE documentation, and perhaps include a
link to the Hornet documentation for context.
-Fan
^ permalink raw reply
* Re: [PATCH V10 00/10] famfs: port into fuse
From: Dan Williams @ 2026-04-16 20:53 UTC (permalink / raw)
To: Gregory Price, Joanne Koong
Cc: John Groves, Darrick J. Wong, Miklos Szeredi, Bernd Schubert,
John Groves, Dan J Williams, Bernd Schubert, Alison Schofield,
John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Dave Jiang, Matthew Wilcox, Jan Kara, Alexander Viro,
David Hildenbrand, Christian Brauner, Randy Dunlap, Jeff Layton,
Amir Goldstein, Jonathan Cameron, Stefan Hajnoczi, Josef Bacik,
Bagas Sanjaya, Chen Linxuan, James Morse, Fuad Tabba,
Sean Christopherson, Shivank Garg, Ackerley Tng, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <aeFDCeqZDPI3rm3s@gourry-fedora-PF4VCD3F>
On Thu, Apr 16, 2026, at 1:14 PM, Gregory Price wrote:
> On Thu, Apr 16, 2026 at 08:56:46AM -0700, Joanne Koong wrote:
>> On Tue, Apr 14, 2026 at 5:10 PM John Groves <John@groves.net> wrote:
>> >
>> > There is a FUSE_DAX_FMAP capability that the kernel may advertise or not
>> > at init time; this capability "is" the famfs GET_FMAP AND GET_DAXDEV
>> > commands. In the future, if we find a way to use BPF (or some other
>> > mechanism) to avoid needing those fuse messages, the kernel could be updated
>> > to NEVER advertise the FUSE_DAX_FMAP capability. All of the famfs-specific
>> > code could be taken out of kernels that never advertise that capability.
>>
>> I’m not sure the capability bit can be used like that (though I am
>> hoping it can!). As I understand it, once the kernel advertises a
>> capability, it must continue supporting it in future kernels else
>> userspace programs that rely on it will break.
>>
>
> FUSE_DAX_FMAP is already conditional on CONFIG_FUSE_DAX, the kernel is
> not required to continue advertising FUSE_DAX_FMAP in perpetuity.
>
> Setting CONFIG_FUSE_DAX=n does not mean userland "is broken", this would
> only be the case if FUSE_DAX_FMAP was advertised but not actually
> supported.
>
> If DAX were removed from the kernel (unlikely, but stick with me) this
> would be equivalent to permanently changing CONFIG_FUSE_DAX to always
> off, and there would be no squabbles over whether that particular
> change broke userland (there would be much strife over removing dax).
>
> While not a deprecation method, this is what capability bits are
> designed for. Same as cpuid capability bits - just because the bit is
> there doesn't mean a processor is required to support it in perpetuity.
>
> They're only required to support it if the bit is turned on.
>
Right, if the protocol on day one is "user space must ask which method is available", then userspace can not be surprised when one option disappears. So to give time for the bpf approach to mature the kernel can do something like "famfs and bpf mapping support are available". In some future kernel the famfs native option disappears after a deprecation period.
When folks ask 10 years from now why this ever supported optionality the explanation is "oh because famfs enjoyed first mover advantage to prove out fs semantics layered on dax devices", or "turns out there are some cases where bpf is not fast enough but it still stops the proliferation of more in kernel mapping implementations".
Something like FUSE_DAX_FMAP is always available but the backend to that is optionally native vs bpf. ...or some other arrangement to make it clear that native might be gone someday.
^ permalink raw reply
* Re: [PATCH v2 07/28] fsnotify: add FSNOTIFY_EVENT_RENAME data type
From: Jeff Layton @ 2026-04-16 20:52 UTC (permalink / raw)
To: Amir Goldstein
Cc: Alexander Viro, Christian Brauner, Jan Kara, Chuck Lever,
Alexander Aring, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, NeilBrown,
Olga Kornievskaia, Dai Ngo, Tom Talpey, Trond Myklebust,
Anna Schumaker, Calum Mackay, linux-fsdevel, linux-kernel,
linux-trace-kernel, linux-doc, linux-nfs
In-Reply-To: <CAOQ4uxg2jHxCi77A1DGtopjZHsTNg4etdboW2GjL85N3uc_KqQ@mail.gmail.com>
On Thu, 2026-04-16 at 21:24 +0200, Amir Goldstein wrote:
> On Thu, Apr 16, 2026 at 7:35 PM Jeff Layton <jlayton@kernel.org> wrote:
> >
> > Add a new fsnotify_rename_data struct and FSNOTIFY_EVENT_RENAME data
> > type that carries both the moved dentry and the inode that was
> > overwritten by the rename (if any).
> >
> > Update fsnotify_data_inode(), fsnotify_data_dentry(), and
> > fsnotify_data_sb() to handle the new type, and add a new
> > fsnotify_data_rename_target() helper for extracting the overwritten
> > target inode.
> >
> > Update fsnotify_move() to use the new data type for FS_RENAME and
> > FS_MOVED_TO events, passing the overwritten target inode through the
> > event data. FS_MOVED_FROM is unchanged since the source directory
> > doesn't need overwrite information.
> >
> > This is done so that fsnotify consumers like nfsd can atomically
> > observe the overwritten file when a rename replaces an existing entry,
> > without needing a separate FS_DELETE event.
> >
> > Assisted-by: Claude (Anthropic Claude Code)
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > include/linux/fsnotify.h | 8 ++++++--
> > include/linux/fsnotify_backend.h | 20 ++++++++++++++++++++
> > 2 files changed, 26 insertions(+), 2 deletions(-)
>
> It is strange to me that the NFS protocol needs to report the overwritten
> node in the same event of the rename, but oh well, fine by me.
>
Yeah, it's not very useful, but the protocol requires it. Unfortunately
RFC5661 was written before anyone had made a real implementation of
directory delegations. If we were rewriting it today, we'd probably
make that info optional.
> Feel free to add:
> Reviewed-by: Amir Goldstein <amir73il@gmail.com>
>
>
Thanks, Amir!
> >
> > diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> > index 079c18bcdbde..bda798bc67bc 100644
> > --- a/include/linux/fsnotify.h
> > +++ b/include/linux/fsnotify.h
> > @@ -257,6 +257,10 @@ static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
> > __u32 new_dir_mask = FS_MOVED_TO;
> > __u32 rename_mask = FS_RENAME;
> > const struct qstr *new_name = &moved->d_name;
> > + struct fsnotify_rename_data rd = {
> > + .moved = moved,
> > + .target = target,
> > + };
> >
> > if (isdir) {
> > old_dir_mask |= FS_ISDIR;
> > @@ -265,12 +269,12 @@ static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
> > }
> >
> > /* Event with information about both old and new parent+name */
> > - fsnotify_name(rename_mask, moved, FSNOTIFY_EVENT_DENTRY,
> > + fsnotify_name(rename_mask, &rd, FSNOTIFY_EVENT_RENAME,
> > old_dir, old_name, 0);
> >
> > fsnotify_name(old_dir_mask, source, FSNOTIFY_EVENT_INODE,
> > old_dir, old_name, fs_cookie);
> > - fsnotify_name(new_dir_mask, source, FSNOTIFY_EVENT_INODE,
> > + fsnotify_name(new_dir_mask, &rd, FSNOTIFY_EVENT_RENAME,
> > new_dir, new_name, fs_cookie);
> >
> > if (target)
> > diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
> > index 66e185bd1b1b..f8c8fb7f34ae 100644
> > --- a/include/linux/fsnotify_backend.h
> > +++ b/include/linux/fsnotify_backend.h
> > @@ -311,6 +311,7 @@ enum fsnotify_data_type {
> > FSNOTIFY_EVENT_DENTRY,
> > FSNOTIFY_EVENT_MNT,
> > FSNOTIFY_EVENT_ERROR,
> > + FSNOTIFY_EVENT_RENAME,
> > };
> >
> > struct fs_error_report {
> > @@ -335,6 +336,11 @@ struct fsnotify_mnt {
> > u64 mnt_id;
> > };
> >
> > +struct fsnotify_rename_data {
> > + struct dentry *moved; /* the dentry that was renamed */
> > + struct inode *target; /* inode overwritten by rename, or NULL */
> > +};
> > +
> > static inline struct inode *fsnotify_data_inode(const void *data, int data_type)
> > {
> > switch (data_type) {
> > @@ -348,6 +354,8 @@ static inline struct inode *fsnotify_data_inode(const void *data, int data_type)
> > return d_inode(file_range_path(data)->dentry);
> > case FSNOTIFY_EVENT_ERROR:
> > return ((struct fs_error_report *)data)->inode;
> > + case FSNOTIFY_EVENT_RENAME:
> > + return d_inode(((const struct fsnotify_rename_data *)data)->moved);
> > default:
> > return NULL;
> > }
> > @@ -363,6 +371,8 @@ static inline struct dentry *fsnotify_data_dentry(const void *data, int data_typ
> > return ((const struct path *)data)->dentry;
> > case FSNOTIFY_EVENT_FILE_RANGE:
> > return file_range_path(data)->dentry;
> > + case FSNOTIFY_EVENT_RENAME:
> > + return ((struct fsnotify_rename_data *)data)->moved;
> > default:
> > return NULL;
> > }
> > @@ -395,6 +405,8 @@ static inline struct super_block *fsnotify_data_sb(const void *data,
> > return file_range_path(data)->dentry->d_sb;
> > case FSNOTIFY_EVENT_ERROR:
> > return ((struct fs_error_report *) data)->sb;
> > + case FSNOTIFY_EVENT_RENAME:
> > + return ((const struct fsnotify_rename_data *)data)->moved->d_sb;
> > default:
> > return NULL;
> > }
> > @@ -430,6 +442,14 @@ static inline struct fs_error_report *fsnotify_data_error_report(
> > }
> > }
> >
> > +static inline struct inode *fsnotify_data_rename_target(const void *data,
> > + int data_type)
> > +{
> > + if (data_type == FSNOTIFY_EVENT_RENAME)
> > + return ((const struct fsnotify_rename_data *)data)->target;
> > + return NULL;
> > +}
> > +
> > static inline const struct file_range *fsnotify_data_file_range(
> > const void *data,
> > int data_type)
> >
> > --
> > 2.53.0
> >
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [RFC, PATCH 00/12] userfaultfd: working set tracking for VM guest memory
From: Kiryl Shutsemau @ 2026-04-16 20:25 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Andrew Morton, Peter Xu, Lorenzo Stoakes, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Liam R . Howlett, Zi Yan,
Jonathan Corbet, Shuah Khan, Sean Christopherson, Paolo Bonzini,
linux-mm, linux-kernel, linux-doc, linux-kselftest, kvm
In-Reply-To: <1a499781-1115-44bc-adbf-2ac3769354ca@kernel.org>
On Thu, Apr 16, 2026 at 08:32:19PM +0200, David Hildenbrand (Arm) wrote:
> On 4/16/26 15:49, Kiryl Shutsemau wrote:
> > On Tue, Apr 14, 2026 at 06:10:44PM +0100, Kiryl Shutsemau wrote:
> >> On Tue, Apr 14, 2026 at 05:37:50PM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> I would rather tackle this from the other direction: it's another form
> >>> of protection (like WP), not really a "minor" mode.
> >>>
> >>> Could we add a UFFDIO_REGISTER_MODE_RWP (or however we would call it)
> >>> and support it for anon+shmem, avoiding the zapping for shmem completely?
> >>
> >> I like this idea.
> >>
> >> It should be functionally equivalent, but your interface idea fits
> >> better with the rest.
> >>
> >> Thanks! Will give it a try.
> >
> > Here is an updated version:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git/log/?h=uffd/rfc-v2
> >
> > will post after -rc1 is tagged.
> >
> > I like it more. It got substantially cleaner.
>
> I don't have time to look into the details just yet, but my thinking was
> that
>
> a) It would avoid the zap+refault
Yep.
> b) We could reuse the uffd-wp PTE bit + marker to indicate/remember the
> protection, making it co-exist with NUMA hinting naturally.
>
> b) obviously means that we cannot use uffd-wp and uffd-rwp at the same
> time in the same uffd area. I guess that should be acceptable for the
> use cases we you should have in mind?
I took a different path: I still use PROT_NONE PTEs, so it cannot
co-exist with NUMA balancing [fully], but WP + RWP should be fine. I
need to add a test for this.
I didn't give up on NUMA balancing completely. task_numa_fault() is
called on RWP fault. So it should help scheduler decisions somewhat.
I think an RWP user might want to use WP too.
Do you see this trade-off as reasonable?
> But I also haven't taken a closer look at this patch set, whether you
> would already be using a PTE bit somehow (I suspect not :) )
No. I didn't want to allocate a new bit or invent some arch-specific
trick for this. This functionality is available everywhere where
PAGE_NONE exists.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* [PATCH v4 8/8] ARM: defconfig: Add a zx29 defconfig file
From: Stefan Dösinger @ 2026-04-16 20:19 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260416-send-v4-0-e19d02b944ec@gmail.com>
This enables existing drivers that already are (UART) or will be (USB,
GPIO) necessary to operate this board even if they aren't declared in
the DTS yet.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
arch/arm/configs/zx29_defconfig | 90 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/arch/arm/configs/zx29_defconfig b/arch/arm/configs/zx29_defconfig
new file mode 100644
index 000000000000..dae2d86c7583
--- /dev/null
+++ b/arch/arm/configs/zx29_defconfig
@@ -0,0 +1,90 @@
+CONFIG_SYSVIPC=y
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EXPERT=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_MMU=y
+CONFIG_ARCH_MULTI_V7=y
+CONFIG_ARCH_ZTE=y
+CONFIG_SOC_ZX297520V3=y
+# FIXME: There is no PSCI on this board, but ARM_GIC_V3 depends on it
+CONFIG_ARM_PSCI=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttyAMA1 earlyprintk root=/dev/ram rw"
+# CONFIG_SUSPEND is not set
+CONFIG_BINFMT_FLAT=y
+# CONFIG_UEVENT_HELPER is not set
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_ALLOW_DEV_COREDUMP is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_CPU_FREQ=y
+CONFIG_CPUFREQ_DT_PLATDEV=y
+CONFIG_PM=y
+CONFIG_PM_CLK=y
+CONFIG_PM_GENERIC_DOMAINS=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_DEVTMPFS=y # FIXME: This is specific to my initrd. Remove before upstream
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_KEYBOARD_GPIO_POLLED=y
+CONFIG_GPIOLIB=y
+CONFIG_OF_GPIO=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_DEV_BUS=y
+CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_MFD_SYSCON=y
+# CONFIG_HID is not set
+CONFIG_PINCTRL=y
+CONFIG_GENERIC_PINCTRL_GROUPS=y
+CONFIG_PINMUX=y
+CONFIG_GENERIC_PINMUX_FUNCTIONS=y
+CONFIG_PINCONF=y
+CONFIG_GENERIC_PINCONF=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_POWER_RESET=y
+CONFIG_RESET_SIMPLE=y
+CONFIG_LEDS_GPIO=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_GADGET=y
+CONFIG_MTD=y
+CONFIG_MTD_OF_PARTS=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_SPI_NAND=y
+CONFIG_SPI_MASTER=y
+CONFIG_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_PLTFM=y
+CONFIG_STMMAC_ETH=y
+CONFIG_STMMAC_PLATFORM=y
+CONFIG_MDIO_BUS=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_SRAM=y
+CONFIG_MISC_FILESYSTEMS=y
+CONFIG_JFFS2_FS=y
+CONFIG_CONFIG_TMPFS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_PRINTK_TIME=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_DEBUG_LL=y
+CONFIG_DEBUG_ZTE_ZX=y
+CONFIG_DEBUG_LL_INCLUDE="debug/pl01x.S"
+CONFIG_DEBUG_UART_PL01X=y
+CONFIG_DEBUG_UART_PHYS=0x01408000
+CONFIG_DEBUG_UART_VIRT=0xf4708000
--
2.52.0
^ permalink raw reply related
* [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Stefan Dösinger @ 2026-04-16 20:19 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260416-send-v4-0-e19d02b944ec@gmail.com>
This is the UART that sends Uboot messages and is accessible via pins on
the boards I have seen so far. UART0 and UART2 exist as well in the SoC
and can be used with the right pinmux settings on some boards. They will
be added later.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
stable regardless of the other enabled UARTs. UART0, as the name
implies, has a lower MMIO address, but uart1 is the one that usually has
the boot output and console.
---
arch/arm/boot/dts/zte/zx297520v3.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index ecd07f3fb8b3..09fbb1d052e3 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -6,6 +6,10 @@ / {
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ serial1 = &uart1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -57,5 +61,23 @@ timer {
*/
arm,cpu-registers-not-fw-configured;
};
+
+ /* The UART clock defaults to 26 mhz. It will be replaced when the zx29 clock
+ * framework is added.
+ */
+ uartclk: uartclk: clock-26000000 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ };
+
+ uart1: serial@1408000 {
+ compatible = "arm,pl011", "arm,primecell";
+ arm,primecell-periphid = <0x001feffe>;
+ reg = <0x01408000 0x1000>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>;
+ clock-names = "apb_pclk";
+ };
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v4 6/8] ARM: zte: Bring back zx29 UART support
From: Stefan Dösinger @ 2026-04-16 20:19 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260416-send-v4-0-e19d02b944ec@gmail.com>
This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform"). I did not bring back the zx29-uart .compatible as the
arm,primecell-periphid does the job.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
drivers/tty/serial/amba-pl011.c | 37 +++++++++++++++++++++++++++++++++++++
include/linux/amba/bus.h | 6 ++++++
2 files changed, 43 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f17d288c807..858a0edd3e3b 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -216,6 +216,38 @@ static struct vendor_data vendor_st = {
.get_fifosize = get_fifosize_st,
};
+static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
+ [REG_DR] = ZX_UART011_DR,
+ [REG_FR] = ZX_UART011_FR,
+ [REG_LCRH_RX] = ZX_UART011_LCRH,
+ [REG_LCRH_TX] = ZX_UART011_LCRH,
+ [REG_IBRD] = ZX_UART011_IBRD,
+ [REG_FBRD] = ZX_UART011_FBRD,
+ [REG_CR] = ZX_UART011_CR,
+ [REG_IFLS] = ZX_UART011_IFLS,
+ [REG_IMSC] = ZX_UART011_IMSC,
+ [REG_RIS] = ZX_UART011_RIS,
+ [REG_MIS] = ZX_UART011_MIS,
+ [REG_ICR] = ZX_UART011_ICR,
+ [REG_DMACR] = ZX_UART011_DMACR,
+};
+
+static unsigned int get_fifosize_zte(struct amba_device *dev)
+{
+ return 16;
+}
+
+static struct vendor_data vendor_zte = {
+ .reg_offset = pl011_zte_offsets,
+ .access_32b = true,
+ .ifls = UART011_IFLS_RX4_8 | UART011_IFLS_TX4_8,
+ .fr_busy = ZX_UART01x_FR_BUSY,
+ .fr_dsr = ZX_UART01x_FR_DSR,
+ .fr_cts = ZX_UART01x_FR_CTS,
+ .fr_ri = ZX_UART011_FR_RI,
+ .get_fifosize = get_fifosize_zte,
+};
+
/* Deals with DMA transactions */
struct pl011_dmabuf {
@@ -3081,6 +3113,11 @@ static const struct amba_id pl011_ids[] = {
.mask = 0x00ffffff,
.data = &vendor_st,
},
+ {
+ .id = AMBA_LINUX_ID(0x00, 0x1, 0xffe),
+ .mask = 0x00ffffff,
+ .data = &vendor_zte,
+ },
{ 0, 0 },
};
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 9946276aff73..854c962d70f5 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -103,8 +103,14 @@ enum amba_vendor {
AMBA_VENDOR_ST = 0x80,
AMBA_VENDOR_QCOM = 0x51,
AMBA_VENDOR_LSI = 0xb6,
+ AMBA_VENDOR_LINUX = 0xfe, /* This value is not official */
};
+/* This is used to generate pseudo-ID for AMBA device */
+#define AMBA_LINUX_ID(conf, rev, part) \
+ (((conf) & 0xff) << 24 | ((rev) & 0xf) << 20 | \
+ AMBA_VENDOR_LINUX << 12 | ((part) & 0xfff))
+
extern const struct bus_type amba_bustype;
#define to_amba_device(d) container_of_const(d, struct amba_device, dev)
--
2.52.0
^ permalink raw reply related
* [PATCH v4 5/8] ARM: dts: Add an armv7 timer for zx297520v3
From: Stefan Dösinger @ 2026-04-16 20:19 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260416-send-v4-0-e19d02b944ec@gmail.com>
The stock kernel does not use this timer, but it seems to work fine. The
board has other board-specific timers that would need a driver and I see
no reason to bother with them since the arm standard timer works.
The caveat is the non-standard GIC setup needed to handle the timer's
level-low PPI. This is the responsibility of the boot loader and
documented in Documentation/arch/arm/zte/zx297520v3.rst.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
arch/arm/boot/dts/zte/zx297520v3.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
index d6c71d52b26c..ecd07f3fb8b3 100644
--- a/arch/arm/boot/dts/zte/zx297520v3.dtsi
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -24,6 +24,15 @@ soc {
interrupt-parent = <&gic>;
ranges;
+ /* The GIC has a non-standard way of configuring ints between level-low/level
+ * high or rising edge/falling edge at 0xf2202070 and onwards. See AP_INT_MODE_BASE
+ * and AP_PPI_MODE_REG in the ZTE kernel, although the offsets in the kernel source
+ * seem wrong.
+ *
+ * Everything defaults to active-high/rising edge, but the timer is active-low. We
+ * currently rely on the boot loader to change timer IRQs to active-low for us for
+ * now.
+ */
gic: interrupt-controller@f2000000 {
compatible = "arm,gic-v3";
interrupt-controller;
@@ -33,5 +42,20 @@ gic: interrupt-controller@f2000000 {
reg = <0xf2000000 0x10000>,
<0xf2040000 0x20000>;
};
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ clock-frequency = <26000000>;
+ interrupt-parent = <&gic>;
+ /* I don't think uboot sets CNTVOFF and the stock kernel doesn't use the
+ * arm timer at all. Since this is a single CPU system I don't think it
+ * really matters that the offset is random though.
+ */
+ arm,cpu-registers-not-fw-configured;
+ };
};
};
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox