* [PATCH AUTOSEL 6.3 06/17] x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline
From: Sasha Levin @ 2023-06-29 19:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Michael Kelley, Vitaly Kuznetsov, Borislav Petkov, Dexuan Cui,
Wei Liu, Sasha Levin, kys, haiyangz, tglx, mingo, dave.hansen,
x86, peterz, linux-hyperv
In-Reply-To: <20230629190049.907558-1-sashal@kernel.org>
From: Michael Kelley <mikelley@microsoft.com>
[ Upstream commit 9636be85cc5bdd8b7a7f6a53405cbcc52161c93c ]
These commits
a494aef23dfc ("PCI: hv: Replace retarget_msi_interrupt_params with hyperv_pcpu_input_arg")
2c6ba4216844 ("PCI: hv: Enable PCI pass-thru devices in Confidential VMs")
update the Hyper-V virtual PCI driver to use the hyperv_pcpu_input_arg
because that memory will be correctly marked as decrypted or encrypted
for all VM types (CoCo or normal). But problems ensue when CPUs in the
VM go online or offline after virtual PCI devices have been configured.
When a CPU is brought online, the hyperv_pcpu_input_arg for that CPU is
initialized by hv_cpu_init() running under state CPUHP_AP_ONLINE_DYN.
But this state occurs after state CPUHP_AP_IRQ_AFFINITY_ONLINE, which
may call the virtual PCI driver and fault trying to use the as yet
uninitialized hyperv_pcpu_input_arg. A similar problem occurs in a CoCo
VM if the MMIO read and write hypercalls are used from state
CPUHP_AP_IRQ_AFFINITY_ONLINE.
When a CPU is taken offline, IRQs may be reassigned in state
CPUHP_TEARDOWN_CPU. Again, the virtual PCI driver may fault trying to
use the hyperv_pcpu_input_arg that has already been freed by a
higher state.
Fix the onlining problem by adding state CPUHP_AP_HYPERV_ONLINE
immediately after CPUHP_AP_ONLINE_IDLE (similar to CPUHP_AP_KVM_ONLINE)
and before CPUHP_AP_IRQ_AFFINITY_ONLINE. Use this new state for
Hyper-V initialization so that hyperv_pcpu_input_arg is allocated
early enough.
Fix the offlining problem by not freeing hyperv_pcpu_input_arg when
a CPU goes offline. Retain the allocated memory, and reuse it if
the CPU comes back online later.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lore.kernel.org/r/1684862062-51576-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/hyperv/hv_init.c | 2 +-
drivers/hv/hv_common.c | 48 +++++++++++++++++++-------------------
include/linux/cpuhotplug.h | 1 +
3 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 41ef036ebb7ba..5e26ac43552b0 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -414,7 +414,7 @@ void __init hyperv_init(void)
goto free_vp_assist_page;
}
- cpuhp = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/hyperv_init:online",
+ cpuhp = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "x86/hyperv_init:online",
hv_cpu_init, hv_cpu_die);
if (cpuhp < 0)
goto free_ghcb_page;
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 52a6f89ccdbd4..2d19118adf95b 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -133,13 +133,20 @@ int hv_common_cpu_init(unsigned int cpu)
flags = irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL;
inputarg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
- *inputarg = kmalloc(pgcount * HV_HYP_PAGE_SIZE, flags);
- if (!(*inputarg))
- return -ENOMEM;
- if (hv_root_partition) {
- outputarg = (void **)this_cpu_ptr(hyperv_pcpu_output_arg);
- *outputarg = (char *)(*inputarg) + HV_HYP_PAGE_SIZE;
+ /*
+ * hyperv_pcpu_input_arg and hyperv_pcpu_output_arg memory is already
+ * allocated if this CPU was previously online and then taken offline
+ */
+ if (!*inputarg) {
+ *inputarg = kmalloc(pgcount * HV_HYP_PAGE_SIZE, flags);
+ if (!(*inputarg))
+ return -ENOMEM;
+
+ if (hv_root_partition) {
+ outputarg = (void **)this_cpu_ptr(hyperv_pcpu_output_arg);
+ *outputarg = (char *)(*inputarg) + HV_HYP_PAGE_SIZE;
+ }
}
msr_vp_index = hv_get_register(HV_REGISTER_VP_INDEX);
@@ -154,24 +161,17 @@ int hv_common_cpu_init(unsigned int cpu)
int hv_common_cpu_die(unsigned int cpu)
{
- unsigned long flags;
- void **inputarg, **outputarg;
- void *mem;
-
- local_irq_save(flags);
-
- inputarg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
- mem = *inputarg;
- *inputarg = NULL;
-
- if (hv_root_partition) {
- outputarg = (void **)this_cpu_ptr(hyperv_pcpu_output_arg);
- *outputarg = NULL;
- }
-
- local_irq_restore(flags);
-
- kfree(mem);
+ /*
+ * The hyperv_pcpu_input_arg and hyperv_pcpu_output_arg memory
+ * is not freed when the CPU goes offline as the hyperv_pcpu_input_arg
+ * may be used by the Hyper-V vPCI driver in reassigning interrupts
+ * as part of the offlining process. The interrupt reassignment
+ * happens *after* the CPUHP_AP_HYPERV_ONLINE state has run and
+ * called this function.
+ *
+ * If a previously offlined CPU is brought back online again, the
+ * originally allocated memory is reused in hv_common_cpu_init().
+ */
return 0;
}
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 0f1001dca0e00..3ceb9dfa09933 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -200,6 +200,7 @@ enum cpuhp_state {
/* Online section invoked on the hotplugged CPU from the hotplug thread */
CPUHP_AP_ONLINE_IDLE,
+ CPUHP_AP_HYPERV_ONLINE,
CPUHP_AP_KVM_ONLINE,
CPUHP_AP_SCHED_WAIT_EMPTY,
CPUHP_AP_SMPBOOT_THREADS,
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 07/17] arm64/hyperv: Use CPUHP_AP_HYPERV_ONLINE state to fix CPU online sequencing
From: Sasha Levin @ 2023-06-29 19:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Michael Kelley, Dexuan Cui, Wei Liu, Sasha Levin, kys, haiyangz,
catalin.marinas, will, linux-hyperv, linux-arm-kernel
In-Reply-To: <20230629190049.907558-1-sashal@kernel.org>
From: Michael Kelley <mikelley@microsoft.com>
[ Upstream commit 52ae076c3a9b366b6fa9f7c7e67aed8b28716ed9 ]
State CPUHP_AP_HYPERV_ONLINE has been introduced to correctly sequence the
initialization of hyperv_pcpu_input_arg. Use this new state for Hyper-V
initialization so that hyperv_pcpu_input_arg is allocated early enough.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lore.kernel.org/r/1684862062-51576-2-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/hyperv/mshyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index a406454578f07..f1b8a04ee9f26 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -67,7 +67,7 @@ static int __init hyperv_init(void)
if (ret)
return ret;
- ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm64/hyperv_init:online",
+ ret = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "arm64/hyperv_init:online",
hv_common_cpu_init, hv_common_cpu_die);
if (ret < 0) {
hv_common_free();
--
2.39.2
^ permalink raw reply related
* RE: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving packets
From: Long Li @ 2023-06-29 18:19 UTC (permalink / raw)
To: Jakub Kicinski, longli@linuxonhyperv.com
Cc: Paolo Abeni, Jason Gunthorpe, Leon Romanovsky, Ajay Sharma,
Dexuan Cui, KY Srinivasan, Haiyang Zhang, Wei Liu,
David S. Miller, Eric Dumazet, linux-rdma@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20230629091129.19217388@kernel.org>
> Subject: Re: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving
> packets
>
> On Thu, 29 Jun 2023 10:42:34 +0200 Paolo Abeni wrote:
> > > While we are making changes in this code path, change the code for
> > > ringing doorbell to set the WQE_COUNT to 0 for Receive Queue. The
> > > hardware specification specifies that it should set to 0. Although
> > > currently the hardware doesn't enforce the check, in the future
> > > releases it may do.
>
> And please split this cleanup into a separate patch, it doesn't sound like it has to
> be done as part of the optimization.
Will do, thanks.
Long
^ permalink raw reply
* RE: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving packets
From: Long Li @ 2023-06-29 18:18 UTC (permalink / raw)
To: Paolo Abeni, longli@linuxonhyperv.com, Jason Gunthorpe,
Leon Romanovsky, Ajay Sharma, Dexuan Cui, KY Srinivasan,
Haiyang Zhang, Wei Liu, David S. Miller, Eric Dumazet,
Jakub Kicinski
Cc: linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <36c95dd6babb2202f70594d5dde13493af62dcad.camel@redhat.com>
> Subject: Re: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving
> packets
>
> On Mon, 2023-06-26 at 16:57 -0700, longli@linuxonhyperv.com wrote:
> > From: Long Li <longli@microsoft.com>
> >
> > It's inefficient to ring the doorbell page every time a WQE is posted
> > to the received queue. Excessive MMIO writes result in CPU spending
> > more time waiting on LOCK instructions (atomic operations), resulting
> > in poor scaling performance.
> >
> > Move the code for ringing doorbell page to where after we have posted
> > all WQEs to the receive queue during a callback from napi_poll().
> >
> > With this change, tests showed an improvement from 120G/s to 160G/s on
> > a 200G physical link, with 16 or 32 hardware queues.
> >
> > Tests showed no regression in network latency benchmarks on single
> > connection.
> >
> > While we are making changes in this code path, change the code for
> > ringing doorbell to set the WQE_COUNT to 0 for Receive Queue. The
> > hardware specification specifies that it should set to 0. Although
> > currently the hardware doesn't enforce the check, in the future
> > releases it may do.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure
> > Network Adapter (MANA)")
>
> Uhmmm... this looks like a performance improvement to me, more suitable for
> the net-next tree ?!? (Note that net-next is closed now).
This issue is a blocker for usage on 200G physical link. I think it can be categorized as a fix.
>
> In any case you must avoid empty lines in the tag area.
>
> If you really intend targeting the -net tree, please repost fixing the above and
> explicitly specifying the target tree in the subj prefix.
Will do, thank you.
Long
>
> thanks!
>
> Paolo
^ permalink raw reply
* Re: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving packets
From: Jakub Kicinski @ 2023-06-29 17:06 UTC (permalink / raw)
To: Haiyang Zhang
Cc: Paolo Abeni, longli@linuxonhyperv.com, Jason Gunthorpe,
Leon Romanovsky, Ajay Sharma, Dexuan Cui, KY Srinivasan, Wei Liu,
David S. Miller, Eric Dumazet, linux-rdma@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Long Li, stable@vger.kernel.org
In-Reply-To: <PH7PR21MB3116276E09BFD0950FB0FB49CA25A@PH7PR21MB3116.namprd21.prod.outlook.com>
On Thu, 29 Jun 2023 16:53:42 +0000 Haiyang Zhang wrote:
> This web page shows the net-next is "open":
> http://vger.kernel.org/~davem/net-next.html
>
> Is this still the right place to check net-next status?
We're working on fixing it. Unfortunately it's a private page and most
of the netdev maintainers don't have access to changing it :(
^ permalink raw reply
* RE: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving packets
From: Haiyang Zhang @ 2023-06-29 16:53 UTC (permalink / raw)
To: Paolo Abeni, longli@linuxonhyperv.com, Jason Gunthorpe,
Leon Romanovsky, Ajay Sharma, Dexuan Cui, KY Srinivasan, Wei Liu,
David S. Miller, Eric Dumazet, Jakub Kicinski
Cc: linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Long Li,
stable@vger.kernel.org
In-Reply-To: <36c95dd6babb2202f70594d5dde13493af62dcad.camel@redhat.com>
> -----Original Message-----
> From: Paolo Abeni <pabeni@redhat.com>
> Sent: Thursday, June 29, 2023 4:43 AM
> To: longli@linuxonhyperv.com; Jason Gunthorpe <jgg@ziepe.ca>; Leon
> Romanovsky <leon@kernel.org>; Ajay Sharma <sharmaajay@microsoft.com>;
> Dexuan Cui <decui@microsoft.com>; KY Srinivasan <kys@microsoft.com>;
> Haiyang Zhang <haiyangz@microsoft.com>; Wei Liu <wei.liu@kernel.org>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>
> Cc: linux-rdma@vger.kernel.org; linux-hyperv@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Long Li
> <longli@microsoft.com>; stable@vger.kernel.org
> Subject: Re: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving
> packets
>
> On Mon, 2023-06-26 at 16:57 -0700, longli@linuxonhyperv.com wrote:
> > From: Long Li <longli@microsoft.com>
> >
> > It's inefficient to ring the doorbell page every time a WQE is posted to
> > the received queue. Excessive MMIO writes result in CPU spending more
> > time waiting on LOCK instructions (atomic operations), resulting in
> > poor scaling performance.
> >
> > Move the code for ringing doorbell page to where after we have posted all
> > WQEs to the receive queue during a callback from napi_poll().
> >
> > With this change, tests showed an improvement from 120G/s to 160G/s on a
> > 200G physical link, with 16 or 32 hardware queues.
> >
> > Tests showed no regression in network latency benchmarks on single
> > connection.
> >
> > While we are making changes in this code path, change the code for
> > ringing doorbell to set the WQE_COUNT to 0 for Receive Queue. The
> > hardware specification specifies that it should set to 0. Although
> > currently the hardware doesn't enforce the check, in the future releases
> > it may do.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network
> Adapter (MANA)")
>
> Uhmmm... this looks like a performance improvement to me, more suitable
> for the net-next tree ?!? (Note that net-next is closed now).
This web page shows the net-next is "open":
http://vger.kernel.org/~davem/net-next.html
Is this still the right place to check net-next status?
- Haiyang
^ permalink raw reply
* Re: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving packets
From: Jakub Kicinski @ 2023-06-29 16:11 UTC (permalink / raw)
To: longli
Cc: Paolo Abeni, Jason Gunthorpe, Leon Romanovsky, Ajay Sharma,
Dexuan Cui, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
David S. Miller, Eric Dumazet, linux-rdma, linux-hyperv, netdev,
linux-kernel, Long Li, stable
In-Reply-To: <36c95dd6babb2202f70594d5dde13493af62dcad.camel@redhat.com>
On Thu, 29 Jun 2023 10:42:34 +0200 Paolo Abeni wrote:
> > While we are making changes in this code path, change the code for
> > ringing doorbell to set the WQE_COUNT to 0 for Receive Queue. The
> > hardware specification specifies that it should set to 0. Although
> > currently the hardware doesn't enforce the check, in the future releases
> > it may do.
And please split this cleanup into a separate patch, it doesn't sound
like it has to be done as part of the optimization.
^ permalink raw reply
* Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/
From: Arnd Bergmann @ 2023-06-29 14:42 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: Linux-Arch, linux-hyperv, linux-efi, linux-ia64, linux-sh,
linux-hexagon, linux-staging, linux-kernel,
linux-csky@vger.kernel.org, linux-mips, linux-fbdev, dri-devel,
loongarch, linux-alpha, sparclinux, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <f9185435-74bb-a325-8fe6-3beb51a66e0a@suse.de>
On Thu, Jun 29, 2023, at 16:15, Thomas Zimmermann wrote:
> Am 29.06.23 um 15:31 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>> Future directions: with the patchset in place, it will become possible
>>> to provide screen_info and edid_info only if there are users. Some
>>> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
>>> etc. A more uniform approach would be nice. We should also attempt
>>> to minimize access to the global screen_info as much as possible. To
>>> do so, some drivers, such as efifb and vesafb, would require an update.
>>> The firmware's EDID data could possibly made available outside of fbdev.
>>> For example, the simpledrm and ofdrm drivers could provide such data
>>> to userspace compositors.
>>
>> I suspect that most architectures that provide a screen_info only
>> have this in order to compile the framebuffer drivers, and provide
>> hardcoded data that does not even reflect any real hardware.
>
> That's quite possible. Only x86's bootparam and EFI code sets
> screen_info from external data. The rest is hardcoded. A number of
> architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE,
> etc. In a later patchset, I wanted to change this such that these users
> of screen_info would enable the feature via select in their Kconfig.
>
> Do you know the reason for this branch in dummycon:
>
> https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21
>
> What is special about arm that dummycon uses the screeninfo?
I can only guess myself, but I see that the values are only ever
set from the old ATAGS data, and not from DT on any of the
modern ones, and my interpretation is that this is meant to
match whatever the vga console was set to on the three
platforms that support vgacon.
I see this was added in linux-2.1.111, just before the
corresponding sparc specific hack was removed, but I don't have
patch descriptions from that era. Russell might remember, or know
if that is actually still needed.
Arnd
^ permalink raw reply
* Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/
From: Arnd Bergmann @ 2023-06-29 14:29 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: Linux-Arch, linux-hyperv, linux-efi, linux-ia64, linux-sh,
linux-hexagon, linux-staging, linux-kernel,
linux-csky@vger.kernel.org, linux-mips, linux-fbdev, dri-devel,
loongarch, linux-alpha, sparclinux, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <4d711508-c299-49f2-8691-e75d68f2485e@app.fastmail.com>
On Thu, Jun 29, 2023, at 15:31, Arnd Bergmann wrote:
> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>
>> Future directions: with the patchset in place, it will become possible
>> to provide screen_info and edid_info only if there are users. Some
>> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
>> etc. A more uniform approach would be nice. We should also attempt
>> to minimize access to the global screen_info as much as possible. To
>> do so, some drivers, such as efifb and vesafb, would require an update.
>> The firmware's EDID data could possibly made available outside of fbdev.
>> For example, the simpledrm and ofdrm drivers could provide such data
>> to userspace compositors.
>
> I suspect that most architectures that provide a screen_info only
> have this in order to compile the framebuffer drivers, and provide
> hardcoded data that does not even reflect any real hardware.
>
> We can probably reduce the number of architectures that do this
> a lot, especially if we get EFI out of the picture.
I tried to have another look at who uses what, and here are
some observations:
- EFIFB and hyperv are the only ones that are relevant on modern
systmes, and they are only used on systems using EFI, so they
could use a separate data structure that is defined as part of
drivers/firmware/efi. This would likely mean we don't have to
define a separate screen_info for arm64, loongarch, ia64 and
riscv, and could separate the legacy vgacon/vesafb stuff on
arm32 from the efi side.
- FB_SIS can likely be marked 'depends on X86' like FB_INTEL,
it seems to depend on x86 BOOT_VESA_SUPPORT.
- FB_VGA16 is currently support on powerpc and enabled on
one defconfig (pasemi), which I'm fairly sure is a mistake,
so this could be made x86 specific as well.
- VGA_CONSOLE has a complicated Kconfig dependency list that
lists platforms without VGA support but I think this is better
expressed with a positive list. It looks like csky, hexagon,
nios2 and xtensa should be excluded here and not provide
screen_info.
- arm and mips only need to provide screen_info on machines
with VGA_CONSOLE. On Arm we have a dependency on
footbridge/integrator/netwinder, while on mips the
dependency can be added to the platforms that fill
the info (mips, malta, sibyte, sni).
- DUMMY_CONSOLE only uses screen_info on arm, and this should
likely be limited to the three obsolete machines that
support VGACON. Almost all Arm machines use DT these days
and won't ever fill the screen info dynamically.
Arnd
^ permalink raw reply
* Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/
From: Thomas Zimmermann @ 2023-06-29 14:15 UTC (permalink / raw)
To: Arnd Bergmann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: Linux-Arch, linux-hyperv, linux-efi, linux-ia64, linux-sh,
linux-hexagon, linux-staging, linux-kernel,
linux-csky@vger.kernel.org, linux-mips, linux-fbdev, dri-devel,
loongarch, linux-alpha, sparclinux, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <4d711508-c299-49f2-8691-e75d68f2485e@app.fastmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3299 bytes --]
Hi
Am 29.06.23 um 15:31 schrieb Arnd Bergmann:
> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>> The variables screen_info and edid_info provide information about
>> the system's screen, and possibly EDID data of the connected display.
>> Both are defined and set by architecture code. But both variables are
>> declared in non-arch header files. Dependencies are at bease loosely
>> tracked. To resolve this, move the global state screen_info and its
>> companion edid_info into arch/. Only declare them on architectures
>> that define them. List dependencies on the variables in the Kconfig
>> files. Also clean up the callers.
>>
>> Patch 1 to 4 resolve a number of unnecessary include statements of
>> <linux/screen_info.h>. The header should only be included in source
>> files that access struct screen_info.
>>
>> Patches 5 to 7 move the declaration of screen_info and edid_info to
>> <asm-generic/screen_info.h>. Architectures that provide either set
>> a Kconfig token to enable them.
>>
>> Patches 8 to 9 make users of screen_info depend on the architecture's
>> feature.
>>
>> Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
>> data to make use of existing helpers and the refactored edid_info.
>>
>> Tested on x86-64. Built for a variety of platforms.
>
> This all looks like a nice cleanup!
I guess that patches 1 to 4 are uncontroversial and could be landed
quickly. Patches 10 to 12 are probably as well.
>
>> Future directions: with the patchset in place, it will become possible
>> to provide screen_info and edid_info only if there are users. Some
>> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
>> etc. A more uniform approach would be nice. We should also attempt
>> to minimize access to the global screen_info as much as possible. To
>> do so, some drivers, such as efifb and vesafb, would require an update.
>> The firmware's EDID data could possibly made available outside of fbdev.
>> For example, the simpledrm and ofdrm drivers could provide such data
>> to userspace compositors.
>
> I suspect that most architectures that provide a screen_info only
> have this in order to compile the framebuffer drivers, and provide
> hardcoded data that does not even reflect any real hardware.
That's quite possible. Only x86's bootparam and EFI code sets
screen_info from external data. The rest is hardcoded. A number of
architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. In a later patchset, I wanted to change this such that these users
of screen_info would enable the feature via select in their Kconfig.
Do you know the reason for this branch in dummycon:
https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21
What is special about arm that dummycon uses the screeninfo?
>
> We can probably reduce the number of architectures that do this
> a lot, especially if we get EFI out of the picture.
Can you elaborate?
Best regards
Thomas
>
> Arnd
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/
From: Arnd Bergmann @ 2023-06-29 13:31 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: Linux-Arch, linux-hyperv, linux-efi, linux-ia64, linux-sh,
linux-hexagon, linux-staging, linux-kernel,
linux-csky@vger.kernel.org, linux-mips, linux-fbdev, dri-devel,
loongarch, linux-alpha, sparclinux, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20230629121952.10559-1-tzimmermann@suse.de>
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
> The variables screen_info and edid_info provide information about
> the system's screen, and possibly EDID data of the connected display.
> Both are defined and set by architecture code. But both variables are
> declared in non-arch header files. Dependencies are at bease loosely
> tracked. To resolve this, move the global state screen_info and its
> companion edid_info into arch/. Only declare them on architectures
> that define them. List dependencies on the variables in the Kconfig
> files. Also clean up the callers.
>
> Patch 1 to 4 resolve a number of unnecessary include statements of
> <linux/screen_info.h>. The header should only be included in source
> files that access struct screen_info.
>
> Patches 5 to 7 move the declaration of screen_info and edid_info to
> <asm-generic/screen_info.h>. Architectures that provide either set
> a Kconfig token to enable them.
>
> Patches 8 to 9 make users of screen_info depend on the architecture's
> feature.
>
> Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
> data to make use of existing helpers and the refactored edid_info.
>
> Tested on x86-64. Built for a variety of platforms.
This all looks like a nice cleanup!
> Future directions: with the patchset in place, it will become possible
> to provide screen_info and edid_info only if there are users. Some
> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
> etc. A more uniform approach would be nice. We should also attempt
> to minimize access to the global screen_info as much as possible. To
> do so, some drivers, such as efifb and vesafb, would require an update.
> The firmware's EDID data could possibly made available outside of fbdev.
> For example, the simpledrm and ofdrm drivers could provide such data
> to userspace compositors.
I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.
We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.
Arnd
^ permalink raw reply
* Re: [PATCH 07/12] arch/x86: Declare edid_info in <asm/screen_info.h>
From: Arnd Bergmann @ 2023-06-29 13:21 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky@vger.kernel.org, linux-hexagon, linux-ia64, loongarch,
linux-mips, linuxppc-dev, linux-riscv, linux-sh, sparclinux,
dri-devel, linux-hyperv, linux-fbdev, linux-staging, Linux-Arch,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Paul E. McKenney, Peter Zijlstra,
Andrew Morton, Frederic Weisbecker, Nicholas Piggin,
Ard Biesheuvel, Sami Tolvanen, Juerg Haefliger
In-Reply-To: <d3de124c-6aa8-e930-e238-7bd6dd7929a6@suse.de>
On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
> Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>> The global variable edid_info contains the firmware's EDID information
>>> as an extension to the regular screen_info on x86. Therefore move it to
>>> <asm/screen_info.h>.
>>>
>>> Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
>>> architectures that don't provide edid_info. Select it on x86.
>>
>> I'm not sure we need another symbol in addition to
>> CONFIG_FIRMWARE_EDID. Since all the code behind that
>> existing symbol is also x86 specific, would it be enough
>> to just add either 'depends on X86' or 'depends on X86 ||
>> COMPILE_TEST' there?
>
> FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
> announces an architecture feature. They do different things.
I still have trouble seeing the difference.
> Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA
> systems. In the future, I want to add support for EDID data from EFI and
> OF as well. It would be stored in edid_info. I assume that the new
> symbol will become useful then.
I don't see why an OF based system would have the same limitation
as legacy BIOS with supporting only a single monitor, if we need
to have a generic representation of EDID data in DT, that would
probably be in a per device property anyway.
I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.
Arnd
^ permalink raw reply
* Re: [PATCH 06/12] arch: Declare screen_info in <asm/screen_info.h>
From: Thomas Zimmermann @ 2023-06-29 13:18 UTC (permalink / raw)
To: Arnd Bergmann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky@vger.kernel.org, linux-hexagon, linux-ia64, loongarch,
linux-mips, linuxppc-dev, linux-riscv, linux-sh, sparclinux,
dri-devel, linux-hyperv, linux-fbdev, linux-staging, Linux-Arch,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
Catalin Marinas, Will Deacon, guoren, Brian Cain, Huacai Chen,
WANG Xuerui, Thomas Bogendoerfer, Dinh Nguyen, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
David S . Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Chris Zankel, Max Filippov,
Kees Cook, Paul E. McKenney, Peter Zijlstra, Frederic Weisbecker,
Andrew Morton, Ard Biesheuvel, Sami Tolvanen, Juerg Haefliger,
Geert Uytterhoeven, Anshuman Khandual, Niklas Schnelle,
Russell King, Linus Walleij, Sebastian Reichel, Mike Rapoport,
Kirill A. Shutemov, Zi Yan
In-Reply-To: <b31f42c1-4283-4793-b448-f7b9326be5d4@app.fastmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1819 bytes --]
Hi
Am 29.06.23 um 15:03 schrieb Arnd Bergmann:
> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>
>> diff --git a/include/asm-generic/screen_info.h
>> b/include/asm-generic/screen_info.h
>> new file mode 100644
>> index 0000000000000..6fd0e50fabfcd
>> --- /dev/null
>> +++ b/include/asm-generic/screen_info.h
>> @@ -0,0 +1,12 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +
>> +#ifndef _ASM_GENERIC_SCREEN_INFO_H
>> +#define _ASM_GENERIC_SCREEN_INFO_H
>> +
>> +#include <uapi/linux/screen_info.h>
>> +
>> +#if defined(CONFIG_ARCH_HAS_SCREEN_INFO)
>> +extern struct screen_info screen_info;
>> +#endif
>> +
>> +#endif /* _ASM_GENERIC_SCREEN_INFO_H */
>> diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
>> index eab7081392d50..c764b9a51c24b 100644
>> --- a/include/linux/screen_info.h
>> +++ b/include/linux/screen_info.h
>> @@ -4,6 +4,6 @@
>>
>> #include <uapi/linux/screen_info.h>
>>
>> -extern struct screen_info screen_info;
>> +#include <asm/screen_info.h>
>>
>
> What is the purpose of adding a file in asm-generic? If all
> architectures use the same generic file, I'd just leave the
> declaration in include/linux/. I wouldn't bother adding the
That appears a bit 'un-clean' for something that is defined in
architecture? But OK, I would not object.
> #ifdef either, but I can see how that helps turn a link
> error into an earlier compile error.
Yes, that's intentional. If there's a Kconfig token anyway, we can also
fail early during the build.
Best regards
Thomas
>
> Arnd
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH 06/12] arch: Declare screen_info in <asm/screen_info.h>
From: Arnd Bergmann @ 2023-06-29 13:03 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky@vger.kernel.org, linux-hexagon, linux-ia64, loongarch,
linux-mips, linuxppc-dev, linux-riscv, linux-sh, sparclinux,
dri-devel, linux-hyperv, linux-fbdev, linux-staging, Linux-Arch,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
Catalin Marinas, Will Deacon, guoren, Brian Cain, Huacai Chen,
WANG Xuerui, Thomas Bogendoerfer, Dinh Nguyen, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
David S . Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Chris Zankel, Max Filippov,
Kees Cook, Paul E. McKenney, Peter Zijlstra, Frederic Weisbecker,
Andrew Morton, Ard Biesheuvel, Sami Tolvanen, Juerg Haefliger,
Geert Uytterhoeven, Anshuman Khandual, Niklas Schnelle,
Russell King, Linus Walleij, Sebastian Reichel, Mike Rapoport,
Kirill A. Shutemov, Zi Yan
In-Reply-To: <20230629121952.10559-7-tzimmermann@suse.de>
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
> diff --git a/include/asm-generic/screen_info.h
> b/include/asm-generic/screen_info.h
> new file mode 100644
> index 0000000000000..6fd0e50fabfcd
> --- /dev/null
> +++ b/include/asm-generic/screen_info.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _ASM_GENERIC_SCREEN_INFO_H
> +#define _ASM_GENERIC_SCREEN_INFO_H
> +
> +#include <uapi/linux/screen_info.h>
> +
> +#if defined(CONFIG_ARCH_HAS_SCREEN_INFO)
> +extern struct screen_info screen_info;
> +#endif
> +
> +#endif /* _ASM_GENERIC_SCREEN_INFO_H */
> diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
> index eab7081392d50..c764b9a51c24b 100644
> --- a/include/linux/screen_info.h
> +++ b/include/linux/screen_info.h
> @@ -4,6 +4,6 @@
>
> #include <uapi/linux/screen_info.h>
>
> -extern struct screen_info screen_info;
> +#include <asm/screen_info.h>
>
What is the purpose of adding a file in asm-generic? If all
architectures use the same generic file, I'd just leave the
declaration in include/linux/. I wouldn't bother adding the
#ifdef either, but I can see how that helps turn a link
error into an earlier compile error.
Arnd
^ permalink raw reply
* Re: [PATCH 07/12] arch/x86: Declare edid_info in <asm/screen_info.h>
From: Thomas Zimmermann @ 2023-06-29 13:01 UTC (permalink / raw)
To: Arnd Bergmann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky@vger.kernel.org, linux-hexagon, linux-ia64, loongarch,
linux-mips, linuxppc-dev, linux-riscv, linux-sh, sparclinux,
dri-devel, linux-hyperv, linux-fbdev, linux-staging, Linux-Arch,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Paul E. McKenney, Peter Zijlstra,
Andrew Morton, Frederic Weisbecker, Nicholas Piggin,
Ard Biesheuvel, Sami Tolvanen, Juerg Haefliger
In-Reply-To: <80e3a583-805e-4e8f-a67b-ebe2e4b9a7e5@app.fastmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1578 bytes --]
Hi
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>> The global variable edid_info contains the firmware's EDID information
>> as an extension to the regular screen_info on x86. Therefore move it to
>> <asm/screen_info.h>.
>>
>> Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
>> architectures that don't provide edid_info. Select it on x86.
>
> I'm not sure we need another symbol in addition to
> CONFIG_FIRMWARE_EDID. Since all the code behind that
> existing symbol is also x86 specific, would it be enough
> to just add either 'depends on X86' or 'depends on X86 ||
> COMPILE_TEST' there?
FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
announces an architecture feature. They do different things.
Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA
systems. In the future, I want to add support for EDID data from EFI and
OF as well. It would be stored in edid_info. I assume that the new
symbol will become useful then.
Before this patchset, I originally wanted to make use of edid_info in
the simpledrm graphics driver. But I found that the rsp code could use
some work first. Maybe the patchset are already tailored towards the
future changes.
Best regards
Thomas
>
> Arnd
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: [PATCH 06/12] arch: Declare screen_info in <asm/screen_info.h>
From: WANG Xuerui @ 2023-06-29 12:55 UTC (permalink / raw)
To: Thomas Zimmermann, arnd, deller, daniel, airlied
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky, linux-hexagon, linux-ia64, loongarch, linux-mips,
linuxppc-dev, linux-riscv, linux-sh, sparclinux, dri-devel,
linux-hyperv, linux-fbdev, linux-staging, linux-arch,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Russell King,
Catalin Marinas, Will Deacon, Guo Ren, Brian Cain, Huacai Chen,
Thomas Bogendoerfer, Dinh Nguyen, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Chris Zankel, Max Filippov,
Kees Cook, Paul E. McKenney, Peter Zijlstra, Frederic Weisbecker,
Andrew Morton, Ard Biesheuvel, Sami Tolvanen, Juerg Haefliger,
Geert Uytterhoeven, Anshuman Khandual, Niklas Schnelle,
Russell King (Oracle), Linus Walleij, Sebastian Reichel,
Mike Rapoport (IBM), Kirill A. Shutemov, Zi Yan
In-Reply-To: <20230629121952.10559-7-tzimmermann@suse.de>
On 2023/6/29 19:45, Thomas Zimmermann wrote:
> The variable screen_info does not exist on all architectures. Declare
> it in <asm-generic/screen_info.h>. All architectures that do declare it
> will provide it via <asm/screen_info.h>.
>
> Add the Kconfig token ARCH_HAS_SCREEN_INFO to guard against access on
> architectures that don't provide screen_info.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
> Cc: Matt Turner <mattst88@gmail.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Guo Ren <guoren@kernel.org>
> Cc: Brian Cain <bcain@quicinc.com>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Dinh Nguyen <dinguyen@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Albert Ou <aou@eecs.berkeley.edu>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: "Paul E. McKenney" <paulmck@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: Juerg Haefliger <juerg.haefliger@canonical.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Niklas Schnelle <schnelle@linux.ibm.com>
> Cc: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
> Cc: "Mike Rapoport (IBM)" <rppt@kernel.org>
> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> Cc: Zi Yan <ziy@nvidia.com>
> ---
> arch/Kconfig | 6 ++++++
> arch/alpha/Kconfig | 1 +
> arch/arm/Kconfig | 1 +
> arch/arm64/Kconfig | 1 +
> arch/csky/Kconfig | 1 +
> arch/hexagon/Kconfig | 1 +
> arch/ia64/Kconfig | 1 +
> arch/loongarch/Kconfig | 1 +
> arch/mips/Kconfig | 1 +
> arch/nios2/Kconfig | 1 +
> arch/powerpc/Kconfig | 1 +
> arch/riscv/Kconfig | 1 +
> arch/sh/Kconfig | 1 +
> arch/sparc/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> arch/xtensa/Kconfig | 1 +
> drivers/video/Kconfig | 3 +++
> include/asm-generic/Kbuild | 1 +
> include/asm-generic/screen_info.h | 12 ++++++++++++
> include/linux/screen_info.h | 2 +-
> 20 files changed, 38 insertions(+), 1 deletion(-)
> create mode 100644 include/asm-generic/screen_info.h
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 205fd23e0cada..2f58293fd7bcb 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1466,6 +1466,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
> address translations. Page table walkers that clear the accessed bit
> may use this capability to reduce their search space.
>
> +config ARCH_HAS_SCREEN_INFO
> + bool
> + help
> + Selected by architectures that provide a global instance of
> + screen_info.
> +
> source "kernel/gcov/Kconfig"
>
> source "scripts/gcc-plugins/Kconfig"
> [snip]
> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index d38b066fc931b..6aab2fb7753da 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -13,6 +13,7 @@ config LOONGARCH
> select ARCH_HAS_FORTIFY_SOURCE
> select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
> select ARCH_HAS_PTE_SPECIAL
> + select ARCH_HAS_SCREEN_INFO
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_INLINE_READ_LOCK if !PREEMPTION
> select ARCH_INLINE_READ_LOCK_BH if !PREEMPTION
> [snip]
Acked-by: WANG Xuerui <git@xen0n.name> # loongarch
Thanks!
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
^ permalink raw reply
* RE: [PATCH] hv_netvsc: support a new host capability AllowRscDisabledStatus
From: Haiyang Zhang @ 2023-06-29 12:44 UTC (permalink / raw)
To: Shradha Gupta, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, KY Srinivasan, Wei Liu,
Dexuan Cui, Long Li, Michael Kelley (LINUX), David S. Miller
In-Reply-To: <1688032719-22847-1-git-send-email-shradhagupta@linux.microsoft.com>
> -----Original Message-----
> From: Shradha Gupta <shradhagupta@linux.microsoft.com>
> Sent: Thursday, June 29, 2023 5:59 AM
> To: linux-kernel@vger.kernel.org; linux-hyperv@vger.kernel.org;
> netdev@vger.kernel.org
> Cc: Shradha Gupta <shradhagupta@linux.microsoft.com>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Wei Liu <wei.liu@kernel.org>; Dexuan Cui
> <decui@microsoft.com>; Long Li <longli@microsoft.com>; Michael Kelley
> (LINUX) <mikelley@microsoft.com>; David S. Miller <davem@davemloft.net>
> Subject: [PATCH] hv_netvsc: support a new host capability
> AllowRscDisabledStatus
>
> A future Azure host update has the potential to change RSC behavior
> in the VMs. To avoid this invisble change, Vswitch will check the
> netvsc version of a VM before sending its RSC capabilities, and will
> always indicate that the host performs RSC if the VM doesn't have an
> updated netvsc driver regardless of the actual host RSC capabilities.
> Netvsc now advertises a new capability: AllowRscDisabledStatus
> The host will check for this capability before sending RSC status,
> and if a VM does not have this capability it will send RSC enabled
> status regardless of host RSC settings
>
> Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> ---
> drivers/net/hyperv/hyperv_net.h | 3 +++
> drivers/net/hyperv/netvsc.c | 8 ++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index dd5919ec408b..218e0f31dd66 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@ -572,6 +572,9 @@ struct nvsp_2_vsc_capability {
> u64 teaming:1;
> u64 vsubnetid:1;
> u64 rsc:1;
> + u64 timestamp:1;
> + u64 reliablecorrelationid:1;
> + u64 allowrscdisabledstatus:1;
> };
> };
> } __packed;
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index da737d959e81..2eb1e85ba940 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -619,6 +619,14 @@ static int negotiate_nvsp_ver(struct hv_device
> *device,
> init_packet->msg.v2_msg.send_ndis_config.mtu = ndev->mtu +
> ETH_HLEN;
> init_packet->msg.v2_msg.send_ndis_config.capability.ieee8021q = 1;
>
> + /* Don't need a version check while setting this bit because if we
> + * have a New VM on an old host, the VM will set the bit but the host
> + * won't check it. If we have an old VM on a new host, the host will
> + * check the bit, see its zero, and it'll know the VM has an
> + * older NetVsc
> + */
> + init_packet-
> >msg.v2_msg.send_ndis_config.capability.allowrscdisabledstatus = 1;
Have you tested on the new host to verify: Before this patch, the host shows
RSC status on, and after this patch the host shows it's off?
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH 07/12] arch/x86: Declare edid_info in <asm/screen_info.h>
From: Arnd Bergmann @ 2023-06-29 12:35 UTC (permalink / raw)
To: Thomas Zimmermann, Helge Deller, Daniel Vetter, Dave Airlie
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky@vger.kernel.org, linux-hexagon, linux-ia64, loongarch,
linux-mips, linuxppc-dev, linux-riscv, linux-sh, sparclinux,
dri-devel, linux-hyperv, linux-fbdev, linux-staging, Linux-Arch,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Kees Cook, Paul E. McKenney, Peter Zijlstra,
Andrew Morton, Frederic Weisbecker, Nicholas Piggin,
Ard Biesheuvel, Sami Tolvanen, Juerg Haefliger
In-Reply-To: <20230629121952.10559-8-tzimmermann@suse.de>
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
> The global variable edid_info contains the firmware's EDID information
> as an extension to the regular screen_info on x86. Therefore move it to
> <asm/screen_info.h>.
>
> Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
> architectures that don't provide edid_info. Select it on x86.
I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?
Arnd
^ permalink raw reply
* Re: [PATCH RFC net-next v4 6/8] virtio/vsock: support dgrams
From: Stefano Garzarella @ 2023-06-29 12:30 UTC (permalink / raw)
To: Bobby Eshleman
Cc: linux-hyperv, Bobby Eshleman, kvm, Michael S. Tsirkin,
VMware PV-Drivers Reviewers, Simon Horman, Stefan Hajnoczi,
virtualization, Eric Dumazet, Dan Carpenter, Xuan Zhuo, Wei Liu,
Dexuan Cui, Bryan Tan, Jakub Kicinski, Paolo Abeni, Haiyang Zhang,
Arseniy Krasnov, Vishnu Dasa, netdev, linux-kernel, bpf,
David S. Miller
In-Reply-To: <ZJo5L+IM1P3kFAhe@bullseye>
On Tue, Jun 27, 2023 at 01:19:43AM +0000, Bobby Eshleman wrote:
>On Mon, Jun 26, 2023 at 05:03:15PM +0200, Stefano Garzarella wrote:
>> On Fri, Jun 23, 2023 at 04:37:55AM +0000, Bobby Eshleman wrote:
>> > On Thu, Jun 22, 2023 at 06:09:12PM +0200, Stefano Garzarella wrote:
>> > > On Sun, Jun 11, 2023 at 11:49:02PM +0300, Arseniy Krasnov wrote:
>> > > > Hello Bobby!
>> > > >
>> > > > On 10.06.2023 03:58, Bobby Eshleman wrote:
>> > > > > This commit adds support for datagrams over virtio/vsock.
>> > > > >
>> > > > > Message boundaries are preserved on a per-skb and per-vq entry basis.
>> > > >
>> > > > I'm a little bit confused about the following case: let vhost sends 4097 bytes
>> > > > datagram to the guest. Guest uses 4096 RX buffers in it's virtio queue, each
>> > > > buffer has attached empty skb to it. Vhost places first 4096 bytes to the first
>> > > > buffer of guests RX queue, and 1 last byte to the second buffer. Now IIUC guest
>> > > > has two skb in it rx queue, and user in guest wants to read data - does it read
>> > > > 4097 bytes, while guest has two skb - 4096 bytes and 1 bytes? In seqpacket there is
>> > > > special marker in header which shows where message ends, and how it works here?
>> > >
>> > > I think the main difference is that DGRAM is not connection-oriented, so
>> > > we don't have a stream and we can't split the packet into 2 (maybe we
>> > > could, but we have no guarantee that the second one for example will be
>> > > not discarded because there is no space).
>> > >
>> > > So I think it is acceptable as a restriction to keep it simple.
>> > >
>> > > My only doubt is, should we make the RX buffer size configurable,
>> > > instead of always using 4k?
>> > >
>> > I think that is a really good idea. What mechanism do you imagine?
>>
>> Some parameter in sysfs?
>>
>
>I comment more on this below.
>
>> >
>> > For sendmsg() with buflen > VQ_BUF_SIZE, I think I'd like -ENOBUFS
>>
>> For the guest it should be easy since it allocates the buffers, but for
>> the host?
>>
>> Maybe we should add a field in the configuration space that reports some
>> sort of MTU.
>>
>> Something in addition to what Laura had proposed here:
>> https://markmail.org/message/ymhz7wllutdxji3e
>>
>
>That sounds good to me.
>
>IIUC vhost exposes the limit via the configuration space, and the guest
>can configure the RX buffer size up to that limit via sysfs?
>
>> > returned even though it is uncharacteristic of Linux sockets.
>> > Alternatively, silently dropping is okay... but seems needlessly
>> > unhelpful.
>>
>> UDP takes advantage of IP fragmentation, right?
>> But what happens if a fragment is lost?
>>
>> We should try to behave in a similar way.
>>
>
>AFAICT in UDP the sending socket will see EHOSTUNREACH on its error
>queue and the packet will be dropped.
>
>For more details:
>- the IP defragmenter will emit an ICMP_TIME_EXCEEDED from ip_expire()
> if the fragment queue is not completed within time.
>- Upon seeing ICMP_TIME_EXCEEDED, the sending stack will then add
> EHOSTUNREACH to the socket's error queue, as seen in __udp4_lib_err().
>
>Given some updated man pages I think enqueuing EHOSTUNREACH is okay for
>vsock too. This also reserves ENOBUFS/ENOMEM only for shortage on local
>buffers / mem.
>
>What do you think?
Yep, makes sense to me!
Stefano
^ permalink raw reply
* [PATCH 05/12] arch: Remove trailing whitespaces
From: Thomas Zimmermann @ 2023-06-29 11:45 UTC (permalink / raw)
To: arnd, deller, daniel, airlied
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky, linux-hexagon, linux-ia64, loongarch, linux-mips,
linuxppc-dev, linux-riscv, linux-sh, sparclinux, dri-devel,
linux-hyperv, linux-fbdev, linux-staging, linux-arch,
Thomas Zimmermann, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, Andrew Morton, Geert Uytterhoeven,
Arnd Bergmann, Kirill A. Shutemov, Anshuman Khandual,
Niklas Schnelle, Zi Yan, Mike Rapoport (IBM), Peter Zijlstra
In-Reply-To: <20230629121952.10559-1-tzimmermann@suse.de>
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: "Mike Rapoport (IBM)" <rppt@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
---
arch/ia64/Kconfig | 4 ++--
arch/sh/Kconfig | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 21fa63ce5ffc0..e79f15e32a451 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -260,7 +260,7 @@ config PERMIT_BSP_REMOVE
default n
help
Say Y here if your platform SAL will support removal of BSP with HOTPLUG_CPU
- support.
+ support.
config FORCE_CPEI_RETARGET
bool "Force assumption that CPEI can be re-targeted"
@@ -335,7 +335,7 @@ config IA64_PALINFO
config IA64_MC_ERR_INJECT
tristate "MC error injection support"
help
- Adds support for MC error injection. If enabled, the kernel
+ Adds support for MC error injection. If enabled, the kernel
will provide a sysfs interface for user applications to
call MC error injection PAL procedures to inject various errors.
This is a useful tool for MCA testing.
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 9652d367fc377..04b9550cf0070 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -234,7 +234,7 @@ config CPU_SUBTYPE_SH7201
select CPU_SH2A
select CPU_HAS_FPU
select SYS_SUPPORTS_SH_MTU2
-
+
config CPU_SUBTYPE_SH7203
bool "Support SH7203 processor"
select CPU_SH2A
@@ -496,7 +496,7 @@ config CPU_SUBTYPE_SH7366
endchoice
source "arch/sh/mm/Kconfig"
-
+
source "arch/sh/Kconfig.cpu"
source "arch/sh/boards/Kconfig"
@@ -647,7 +647,7 @@ config GUSA
This is the default implementation for both UP and non-ll/sc
CPUs, and is used by the libc, amongst others.
- For additional information, design information can be found
+ For additional information, design information can be found
in <http://lc.linux.or.jp/lc2002/papers/niibe0919p.pdf>.
This should only be disabled for special cases where alternate
--
2.41.0
^ permalink raw reply related
* [PATCH 07/12] arch/x86: Declare edid_info in <asm/screen_info.h>
From: Thomas Zimmermann @ 2023-06-29 11:45 UTC (permalink / raw)
To: arnd, deller, daniel, airlied
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky, linux-hexagon, linux-ia64, loongarch, linux-mips,
linuxppc-dev, linux-riscv, linux-sh, sparclinux, dri-devel,
linux-hyperv, linux-fbdev, linux-staging, linux-arch,
Thomas Zimmermann, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Kees Cook, Paul E. McKenney,
Peter Zijlstra, Andrew Morton, Frederic Weisbecker,
Nicholas Piggin, Ard Biesheuvel, Sami Tolvanen, Juerg Haefliger
In-Reply-To: <20230629121952.10559-1-tzimmermann@suse.de>
The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
<asm/screen_info.h>.
Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Juerg Haefliger <juerg.haefliger@canonical.com>
---
arch/Kconfig | 6 ++++++
arch/x86/Kconfig | 1 +
drivers/video/Kconfig | 3 ---
include/asm-generic/screen_info.h | 6 ++++++
include/video/edid.h | 3 ---
5 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 2f58293fd7bcb..ee9866e4df2b0 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1466,6 +1466,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
address translations. Page table walkers that clear the accessed bit
may use this capability to reduce their search space.
+config ARCH_HAS_EDID_INFO
+ bool
+ help
+ Selected by architectures that provide a global instance of
+ edid_info.
+
config ARCH_HAS_SCREEN_INFO
bool
help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d7c2bf4ee403d..ee81855116be7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -76,6 +76,7 @@ config X86
select ARCH_HAS_DEBUG_VM_PGTABLE if !X86_PAE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_EARLY_DEBUG if KGDB
+ select ARCH_HAS_EDID_INFO
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d4a72bea56be0..8b2b9ac37c3df 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,9 +21,6 @@ config STI_CORE
config VIDEO_CMDLINE
bool
-config ARCH_HAS_SCREEN_INFO
- bool
-
config VIDEO_NOMODESET
bool
default n
diff --git a/include/asm-generic/screen_info.h b/include/asm-generic/screen_info.h
index 6fd0e50fabfcd..5efc99c296b40 100644
--- a/include/asm-generic/screen_info.h
+++ b/include/asm-generic/screen_info.h
@@ -5,6 +5,12 @@
#include <uapi/linux/screen_info.h>
+#include <video/edid.h>
+
+#if defined(CONFIG_ARCH_HAS_EDID_INFO)
+extern struct edid_info edid_info;
+#endif
+
#if defined(CONFIG_ARCH_HAS_SCREEN_INFO)
extern struct screen_info screen_info;
#endif
diff --git a/include/video/edid.h b/include/video/edid.h
index f614371e9116a..52aabb7060321 100644
--- a/include/video/edid.h
+++ b/include/video/edid.h
@@ -4,7 +4,4 @@
#include <uapi/video/edid.h>
-#ifdef CONFIG_X86
-extern struct edid_info edid_info;
-#endif
#endif /* __linux_video_edid_h__ */
--
2.41.0
^ permalink raw reply related
* [PATCH 11/12] fbdev/core: Protect edid_info with CONFIG_ARCH_HAS_EDID_INFO
From: Thomas Zimmermann @ 2023-06-29 11:45 UTC (permalink / raw)
To: arnd, deller, daniel, airlied
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky, linux-hexagon, linux-ia64, loongarch, linux-mips,
linuxppc-dev, linux-riscv, linux-sh, sparclinux, dri-devel,
linux-hyperv, linux-fbdev, linux-staging, linux-arch,
Thomas Zimmermann, Randy Dunlap
In-Reply-To: <20230629121952.10559-1-tzimmermann@suse.de>
Guard usage of edid_info with CONFIG_ARCH_HAS_EDID_INFO instead
of CONFIG_X86. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
---
drivers/video/fbdev/core/fbmon.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 35be4431f649a..9ae063021e431 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1480,17 +1480,19 @@ int fb_validate_mode(const struct fb_var_screeninfo *var, struct fb_info *info)
-EINVAL : 0;
}
-#if defined(CONFIG_FIRMWARE_EDID) && defined(CONFIG_X86)
+#if defined(CONFIG_FIRMWARE_EDID)
const unsigned char *fb_firmware_edid(struct fb_info *info)
{
unsigned char *edid = NULL;
+#if defined(CONFIG_ARCH_HAS_EDID_INFO)
/*
* We need to ensure that the EDID block is only
* returned for the primary graphics adapter.
*/
if (fb_is_primary_device(info))
edid = edid_info.dummy;
+#endif
return edid;
}
--
2.41.0
^ permalink raw reply related
* [PATCH 01/12] efi: Do not include <linux/screen_info.h> from EFI header
From: Thomas Zimmermann @ 2023-06-29 11:45 UTC (permalink / raw)
To: arnd, deller, daniel, airlied
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky, linux-hexagon, linux-ia64, loongarch, linux-mips,
linuxppc-dev, linux-riscv, linux-sh, sparclinux, dri-devel,
linux-hyperv, linux-fbdev, linux-staging, linux-arch,
Thomas Zimmermann, Ard Biesheuvel, Russell King, Catalin Marinas,
Will Deacon
In-Reply-To: <20230629121952.10559-1-tzimmermann@suse.de>
The header file <linux/efi.h> does not need anything from
<linux/screen_info.h>. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm/kernel/efi.c | 2 ++
arch/arm64/kernel/efi.c | 1 +
drivers/firmware/efi/libstub/efi-stub-entry.c | 2 ++
drivers/firmware/efi/libstub/screen_info.c | 2 ++
include/linux/efi.h | 3 ++-
5 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c
index e2b9d2618c672..e94655ef16bb3 100644
--- a/arch/arm/kernel/efi.c
+++ b/arch/arm/kernel/efi.c
@@ -5,6 +5,8 @@
#include <linux/efi.h>
#include <linux/memblock.h>
+#include <linux/screen_info.h>
+
#include <asm/efi.h>
#include <asm/mach/map.h>
#include <asm/mmu_context.h>
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index baab8dd3ead3c..3afbe503b066f 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -9,6 +9,7 @@
#include <linux/efi.h>
#include <linux/init.h>
+#include <linux/screen_info.h>
#include <asm/efi.h>
#include <asm/stacktrace.h>
diff --git a/drivers/firmware/efi/libstub/efi-stub-entry.c b/drivers/firmware/efi/libstub/efi-stub-entry.c
index cc4dcaea67fa6..2f1902e5d4075 100644
--- a/drivers/firmware/efi/libstub/efi-stub-entry.c
+++ b/drivers/firmware/efi/libstub/efi-stub-entry.c
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
#include <linux/efi.h>
+#include <linux/screen_info.h>
+
#include <asm/efi.h>
#include "efistub.h"
diff --git a/drivers/firmware/efi/libstub/screen_info.c b/drivers/firmware/efi/libstub/screen_info.c
index 4be1c4d1f922b..a51ec201ca3cb 100644
--- a/drivers/firmware/efi/libstub/screen_info.c
+++ b/drivers/firmware/efi/libstub/screen_info.c
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/efi.h>
+#include <linux/screen_info.h>
+
#include <asm/efi.h>
#include "efistub.h"
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 571d1a6e1b744..360895a5572c0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -24,10 +24,11 @@
#include <linux/range.h>
#include <linux/reboot.h>
#include <linux/uuid.h>
-#include <linux/screen_info.h>
#include <asm/page.h>
+struct screen_info;
+
#define EFI_SUCCESS 0
#define EFI_LOAD_ERROR ( 1 | (1UL << (BITS_PER_LONG-1)))
#define EFI_INVALID_PARAMETER ( 2 | (1UL << (BITS_PER_LONG-1)))
--
2.41.0
^ permalink raw reply related
* [PATCH 09/12] drivers: Add dependencies on CONFIG_ARCH_HAS_SCREEN_INFO
From: Thomas Zimmermann @ 2023-06-29 11:45 UTC (permalink / raw)
To: arnd, deller, daniel, airlied
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky, linux-hexagon, linux-ia64, loongarch, linux-mips,
linuxppc-dev, linux-riscv, linux-sh, sparclinux, dri-devel,
linux-hyperv, linux-fbdev, linux-staging, linux-arch,
Thomas Zimmermann, Ard Biesheuvel, Maarten Lankhorst,
Maxime Ripard, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Greg Kroah-Hartman, Javier Martinez Canillas,
Randy Dunlap, Andy Shevchenko
In-Reply-To: <20230629121952.10559-1-tzimmermann@suse.de>
Various files within drivers/ depend on the declaration of the
screen_info variable. Add this information to Kconfig.
In the case of the dummy console, the dependency exists only
on ARM. Ignore it on !ARM platforms.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/firmware/Kconfig | 1 +
drivers/firmware/efi/Kconfig | 1 +
drivers/gpu/drm/Kconfig | 1 +
drivers/hv/Kconfig | 1 +
drivers/video/console/Kconfig | 2 ++
drivers/video/fbdev/Kconfig | 4 ++++
6 files changed, 10 insertions(+)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 0432737bbb8b4..65bbf7422f1db 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -228,6 +228,7 @@ config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
config SYSFB
bool
+ depends on ARCH_HAS_SCREEN_INFO
select BOOT_VESA_SUPPORT
config SYSFB_SIMPLEFB
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 043ca31c114eb..963d305421e50 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -225,6 +225,7 @@ config EFI_DISABLE_PCI_DMA
config EFI_EARLYCON
def_bool y
depends on SERIAL_EARLYCON && !ARM && !IA64
+ depends on ARCH_HAS_SCREEN_INFO
select FONT_SUPPORT
select ARCH_USE_MEMREMAP_PROT
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f4253..63dfc3391d2ff 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -366,6 +366,7 @@ source "drivers/gpu/drm/sprd/Kconfig"
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
depends on DRM && PCI && MMU && HYPERV
+ depends on ARCH_HAS_SCREEN_INFO
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
help
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 00242107d62e0..3730c9b42a9bd 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -6,6 +6,7 @@ config HYPERV
tristate "Microsoft Hyper-V client drivers"
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
+ depends on ARCH_HAS_SCREEN_INFO
select PARAVIRT
select X86_HV_CALLBACK_VECTOR if X86
select OF_EARLY_FLATTREE if OF
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index a2a88d42edf0c..b39e2ae039783 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -10,6 +10,7 @@ config VGA_CONSOLE
depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !SUPERH && \
(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) && \
!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390 && !UML
+ depends on ARCH_HAS_SCREEN_INFO
select APERTURE_HELPERS if (DRM || FB || VFIO_PCI_CORE)
default y
help
@@ -48,6 +49,7 @@ config SGI_NEWPORT_CONSOLE
config DUMMY_CONSOLE
bool
+ depends on ARCH_HAS_SCREEN_INFO || !ARM
default y
config DUMMY_CONSOLE_COLUMNS
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index cecf15418632d..e11d85e802bc7 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -655,6 +655,7 @@ config FB_UVESA
config FB_VESA
bool "VESA VGA graphics support"
depends on (FB = y) && X86
+ depends on ARCH_HAS_SCREEN_INFO
select APERTURE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -669,6 +670,7 @@ config FB_VESA
config FB_EFI
bool "EFI-based Framebuffer Support"
depends on (FB = y) && !IA64 && EFI
+ depends on ARCH_HAS_SCREEN_INFO
select APERTURE_HELPERS
select DRM_PANEL_ORIENTATION_QUIRKS
select FB_CFB_FILLRECT
@@ -1089,6 +1091,7 @@ config FB_CARILLO_RANCH
config FB_INTEL
tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support"
depends on FB && PCI && X86 && AGP_INTEL && EXPERT
+ depends on ARCH_HAS_SCREEN_INFO
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -2185,6 +2188,7 @@ config FB_BROADSHEET
config FB_HYPERV
tristate "Microsoft Hyper-V Synthetic Video support"
depends on FB && HYPERV
+ depends on ARCH_HAS_SCREEN_INFO
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
2.41.0
^ permalink raw reply related
* [PATCH 12/12] fbdev/core: Define empty fb_firmware_edid() in <linux/fb.h>
From: Thomas Zimmermann @ 2023-06-29 11:45 UTC (permalink / raw)
To: arnd, deller, daniel, airlied
Cc: linux-kernel, linux-alpha, linux-arm-kernel, linux-efi,
linux-csky, linux-hexagon, linux-ia64, loongarch, linux-mips,
linuxppc-dev, linux-riscv, linux-sh, sparclinux, dri-devel,
linux-hyperv, linux-fbdev, linux-staging, linux-arch,
Thomas Zimmermann, Randy Dunlap
In-Reply-To: <20230629121952.10559-1-tzimmermann@suse.de>
Move the empty declaration of fb_firmware_edid() to <linux/fb.h>.
Follow common style and avoid the overhead of exporting the symbol.
No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
---
drivers/video/fbdev/core/fbmon.c | 7 +------
include/linux/fb.h | 10 +++++++++-
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 9ae063021e431..d45bd8a18c2f2 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1496,13 +1496,8 @@ const unsigned char *fb_firmware_edid(struct fb_info *info)
return edid;
}
-#else
-const unsigned char *fb_firmware_edid(struct fb_info *info)
-{
- return NULL;
-}
-#endif
EXPORT_SYMBOL(fb_firmware_edid);
+#endif
EXPORT_SYMBOL(fb_parse_edid);
EXPORT_SYMBOL(fb_edid_to_monspecs);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5ffd2223326bf..e949532ffc109 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -761,7 +761,6 @@ extern int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var,
extern int fb_validate_mode(const struct fb_var_screeninfo *var,
struct fb_info *info);
extern int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var);
-extern const unsigned char *fb_firmware_edid(struct fb_info *info);
extern void fb_edid_to_monspecs(unsigned char *edid,
struct fb_monspecs *specs);
extern void fb_destroy_modedb(struct fb_videomode *modedb);
@@ -774,6 +773,15 @@ extern int of_get_fb_videomode(struct device_node *np,
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
+#if defined(CONFIG_FIRMWARE_EDID)
+const unsigned char *fb_firmware_edid(struct fb_info *info);
+#else
+static inline const unsigned char *fb_firmware_edid(struct fb_info *info)
+{
+ return NULL;
+}
+#endif
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 43
#define DMT_SIZE 0x50
--
2.41.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