* [PATCH] staging: sm750fb: fix coding style issues in sm750.h
From: Yiming Qian @ 2025-09-08 5:21 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang
Cc: gregkh, linux-fbdev, linux-staging, linux-kernel, Yiming Qian
This patch addresses several coding style warnings
reported by checkpatch.pl:
1. Replaces CamelCase variable names with snake_case:
- dprBase -> dpr_base
- dpPortBase -> dp_port_base
2. Removes unnecessary use of 'volatile' qualifier
from the lynx_share_struct members.
These changes improve code readability and maintain
consistency with the kernel coding style guidelines.
No functional changes are introduced.
Signed-off-by: Yiming Qian <qianym1996@gmail.com>
---
drivers/staging/sm750fb/sm750.h | 6 +++---
drivers/staging/sm750fb/sm750_accel.c | 7 +++----
drivers/staging/sm750fb/sm750_hw.c | 4 ++--
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d7f40efe3..fcb7d586e 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -50,9 +50,9 @@ struct init_status {
struct lynx_accel {
/* base virtual address of DPR registers */
- volatile unsigned char __iomem *dprBase;
+ unsigned char __iomem *dpr_base;
/* base virtual address of de data port */
- volatile unsigned char __iomem *dpPortBase;
+ unsigned char __iomem *dp_port_base;
/* function pointers */
void (*de_init)(struct lynx_accel *accel);
@@ -128,7 +128,7 @@ struct lynx_cursor {
char __iomem *vstart;
int offset;
/* mmio addr of hw cursor */
- volatile char __iomem *mmio;
+ char __iomem *mmio;
};
struct lynxfb_crtc {
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 44b9e3fe3..6bee37bf5 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -19,17 +19,17 @@
#include "sm750_accel.h"
static inline void write_dpr(struct lynx_accel *accel, int offset, u32 regValue)
{
- writel(regValue, accel->dprBase + offset);
+ writel(regValue, accel->dpr_base + offset);
}
static inline u32 read_dpr(struct lynx_accel *accel, int offset)
{
- return readl(accel->dprBase + offset);
+ return readl(accel->dpr_base + offset);
}
static inline void write_dpPort(struct lynx_accel *accel, u32 data)
{
- writel(data, accel->dpPortBase);
+ writel(data, accel->dp_port_base);
}
void sm750_hw_de_init(struct lynx_accel *accel)
@@ -410,4 +410,3 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
return 0;
}
-
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 7119b67ef..ce46f240c 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -58,8 +58,8 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
pr_info("mmio virtual addr = %p\n", sm750_dev->pvReg);
- sm750_dev->accel.dprBase = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dpPortBase = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
mmio750 = sm750_dev->pvReg;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Greg KH @ 2025-09-06 11:36 UTC (permalink / raw)
To: Mukesh Rathor
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, deller, arnd, sgarzare, horms
In-Reply-To: <20250906010952.2145389-3-mrathor@linux.microsoft.com>
On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
> hypervisor support, such as hypercalls, clocks/timers, Confidential
> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
> devices.
But why are you making it so that this can not be a module anymore? You
are now forcing ALL Linux distro users to always have this code in their
system, despite not ever using the feature. That feels like a waste to
me.
What is preventing this from staying as a module? Why must you always
have this code loaded at all times for everyone?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250906010952.2145389-1-mrathor@linux.microsoft.com>
With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
hypervisor support, such as hypercalls, clocks/timers, Confidential
Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
devices.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/Makefile | 2 +-
drivers/hv/Kconfig | 2 +-
drivers/hv/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index b5749cf67044..7ad5744db0b6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE) += soundwire/
# Virtualization drivers
obj-$(CONFIG_VIRT_DRIVERS) += virt/
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
+obj-$(CONFIG_HYPERV) += hv/
obj-$(CONFIG_PM_DEVFREQ) += devfreq/
obj-$(CONFIG_EXTCON) += extcon/
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index fe29f8dca2b5..7e56c51c5080 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -3,7 +3,7 @@
menu "Microsoft Hyper-V guest support"
config HYPERV
- tristate "Microsoft Hyper-V client drivers"
+ bool "Microsoft Hyper-V core hypervisor support"
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|| (ARM64 && !CPU_BIG_ENDIAN)
select PARAVIRT
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 050517756a82..8b04a33e4dd8 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -18,7 +18,7 @@ mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
mshv_vtl-y := mshv_vtl_main.o
# Code that must be built-in
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
+obj-$(CONFIG_HYPERV) += hv_common.o
obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o
ifneq ($(CONFIG_MSHV_ROOT) $(CONFIG_MSHV_VTL),)
obj-y += mshv_common.o
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v1 1/2] Driver: hv: Add CONFIG_HYPERV_VMBUS option
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250906010952.2145389-1-mrathor@linux.microsoft.com>
At present VMBus driver is hinged off of CONFIG_HYPERV which entails
lot of builtin code and encompasses too much. It's not always clear
what depends on builtin hv code and what depends on VMBus. Setting
CONFIG_HYPERV as a module and fudging the Makefile to switch to builtin
adds even more confusion. VMBus is an independent module and should have
its own config option. Also, there are scenarios like baremetal dom0/root
where support is built in with CONFIG_HYPERV but without VMBus. Lastly,
there are more features coming down that use CONFIG_HYPERV and add more
dependencies on it.
So, create a fine grained HYPERV_VMBUS option and update Kconfigs for
dependency on VMBus.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 13 ++++++++++---
drivers/hv/Makefile | 2 +-
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
12 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7ea8e895c0c..58f34da061c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
- depends on DRM && PCI && HYPERV
+ depends on DRM && PCI && HYPERV_VMBUS
select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb..fe3dc8c0db99 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1162,7 +1162,7 @@ config GREENASIA_FF
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Select this option to enable the Hyper-V mouse driver.
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 2e8df09db599..fe29f8dca2b5 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -44,18 +44,25 @@ config HYPERV_TIMER
config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
- depends on HYPERV && CONNECTOR && NLS
+ depends on HYPERV_VMBUS && CONNECTOR && NLS
depends on PTP_1588_CLOCK_OPTIONAL
help
Select this option to enable the Hyper-V Utilities.
config HYPERV_BALLOON
tristate "Microsoft Hyper-V Balloon driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select PAGE_REPORTING
help
Select this option to enable Hyper-V Balloon driver.
+config HYPERV_VMBUS
+ tristate "Microsoft Hyper-V VMBus driver"
+ depends on HYPERV
+ default HYPERV
+ help
+ Select this option to enable Hyper-V Vmbus driver.
+
config MSHV_ROOT
tristate "Microsoft Hyper-V root partition support"
depends on HYPERV && (X86_64 || ARM64)
@@ -75,7 +82,7 @@ config MSHV_ROOT
config MSHV_VTL
tristate "Microsoft Hyper-V VTL driver"
- depends on X86_64 && HYPERV_VTL_MODE
+ depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS
# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
# specially with large memory requirements.
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index c53a0df746b7..050517756a82 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_HYPERV) += hv_vmbus.o
+obj-$(CONFIG_HYPERV_VMBUS) += hv_vmbus.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 17edc1597446..c7ef347a4dff 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
config HYPERV_KEYBOARD
tristate "Microsoft Synthetic Keyboard driver"
- depends on HYPERV
- default HYPERV
+ depends on HYPERV_VMBUS
+ default HYPERV_VMBUS
help
Select this option to enable the Hyper-V Keyboard driver.
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index c8cbd85adcf9..982964c1a9fb 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select UCS2_STRING
select NLS
help
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9a249c65aedc..7065a8e5f9b1 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -221,7 +221,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
+ depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
select PCI_HYPERV_INTERFACE
select IRQ_MSI_LIB
help
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5522310bab8d..19d0884479a2 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
config HYPERV_STORAGE
tristate "Microsoft Hyper-V virtual storage driver"
- depends on SCSI && HYPERV
+ depends on SCSI && HYPERV_VMBUS
depends on m || SCSI_FC_ATTRS != m
default HYPERV
help
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b060dcd7c635..6f86a61231e6 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -140,7 +140,7 @@ config UIO_MF624
config UIO_HV_GENERIC
tristate "Generic driver for Hyper-V VMBus"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Generic driver that you can bind, dynamically, to any
Hyper-V VMBus device. It is useful to provide direct access
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c21484d15f0c..72c63eaeb983 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1774,7 +1774,7 @@ config FB_BROADSHEET
config FB_HYPERV
tristate "Microsoft Hyper-V Synthetic Video support"
- depends on FB && HYPERV
+ depends on FB && HYPERV_VMBUS
select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
select FB_IOMEM_HELPERS_DEFERRED
help
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 1d2ad1304ad4..66c58c91b530 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
void __init hv_mark_resources(void);
+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
/* Free the message slot and signal end-of-message if required */
static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
{
@@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
}
}
+extern int vmbus_interrupt;
+extern int vmbus_irq;
+#endif /* CONFIG_HYPERV_VMBUS */
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
void hv_setup_vmbus_handler(void (*handler)(void));
@@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
void hv_remove_crash_handler(void);
void hv_setup_mshv_handler(void (*handler)(void));
-extern int vmbus_interrupt;
-extern int vmbus_irq;
-
#if IS_ENABLED(CONFIG_HYPERV)
/*
* Hypervisor's notion of virtual processor ID is different from
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index 56356d2980c8..8e803c4828c4 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
config HYPERV_VSOCKETS
tristate "Hyper-V transport for Virtual Sockets"
- depends on VSOCKETS && HYPERV
+ depends on VSOCKETS && HYPERV_VMBUS
help
This module implements a Hyper-V transport for Virtual Sockets.
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v1 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh Rathor @ 2025-09-06 1:09 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV
for hv subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
hv_common.c that is needed for the drivers. Moreover, vmbus driver is
built if CONFIG_HYPER is set, either loadable or builtin.
This is not a good approach. CONFIG_HYPERV is really an umbrella
config that encompasses builtin code and various other things and not
a dedicated config option for VMBus. VMBus should really have a config
option just like CONFIG_HYPERV_BALLOON etc. This small series introduces
CONFIG_HYPERV_VMBUS to build VMBus driver and make that distinction
explicit. With that CONFIG_HYPERV could be changed to bool.
For now, hv_common.c is left as is to reduce conflicts for upcoming
patches, but once merges are mostly done, that and some others should
be moved to virt/hyperv directory.
V1:
o Change subject from hyper-v to "Drivers: hv:"
o Rewrite commit messages paying attention to VMBus and not vmbus
o Change some wordings in Kconfig
o Make new VMBUS config option default to HYPERV option for a smoother
transition
Mukesh Rathor (2):
Driver: hv: Add CONFIG_HYPERV_VMBUS option
Drivers: hv: Make CONFIG_HYPERV bool
drivers/Makefile | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 15 +++++++++++----
drivers/hv/Makefile | 4 ++--
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
13 files changed, 29 insertions(+), 20 deletions(-)
--
2.36.1.vfs.0.0
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-06 0:34 UTC (permalink / raw)
To: Nuno Das Neves, Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <6a26cbf8-7877-4f39-0ed3-7bbc306f9fe5@linux.microsoft.com>
On 9/5/25 14:41, Mukesh R wrote:
> On 9/5/25 13:08, Nuno Das Neves wrote:
>> On 9/4/2025 11:18 AM, Mukesh R wrote:
>>> On 9/4/25 09:26, Michael Kelley wrote:
>>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>>>
>>>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>>>
>>>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>>>
>>>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>>>> CONFIG_HYPERV could be changed to bool.
>>>>>>
>>>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>>>> is already mostly in separate source files code, though there's some
>>>>>> entanglement in the handling of VMBus interrupts, which could be
>>>>>> improved later.
>>>>>>
>>>>>> However, I have a compatibility concern. Consider this scenario:
>>>>>>
>>>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>>>> built with CONFIG_HYPERV=m.
>>>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>>>> 4) Build the new kernel. This succeeds.
>>>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>>>
>>>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>>>> newly built kernel has no Hyper-V support and won't run in a
>>>>>> Hyper-V VM.
>>
>> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
>> I guess any invalid value turns to =n, which makes sense most of the time.
>>
>>>>>>
>>>>>> As a second issue, if in Step 1 the current kernel was built with
>>>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>>>> and won't run in a typical Hyper-V VM.
>>>>>>
>>>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>>>> I'm not sure how to fix the first issue, except by continuing to
>>>>>> allow CONFIG_HYPERV=m.
>>
>> I'm wondering, is there a path for this change, then? Are there some
>> intermediate step/s we could take to minimize the problem?
>>
>>>>>
>>>>> To certain extent, imo, users are expected to check config files
>>>>> for changes when moving to new versions/releases, so it would be a
>>>>> one time burden.
>>>>
>>>> I'm not so sanguine about the impact. For those of us who work with
>>>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>>>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>>>> the details of how the Kconfig files are put together. And the issue occurs
>>>> with no error messages that something has gone wrong in building
>>>> the kernel, except that it won't boot. Just running "make olddefconfig"
>>>> has worked in the past, so some users will be befuddled and end up
>>>> generating Azure support incidents. I also wonder about breaking
>>>> automated test suites for new kernels, as they are likely to be running
>>>> "make olddefconfig" or something similar as part of the automation.
>>>>
>>>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>>>
>>>>
>>>> I agree that's not ideal. But note that some Hyper-V code and symbols
>>>> like ms_hyperv_init_platform() and related functions show up when
>>>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>>>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>>>> is one of the recognized and somewhat hardwired hypervisors (like
>>>> VMware, for example).
>>>>
>>>> Finally, there are about a dozen other places in the kernel that use
>>>> the same Makefile construct to make some code built-in even though
>>>> the CONFIG option is set to "m". That may not be enough occurrences
>>>> to make it standard practice, but Hyper-V guests are certainly not the
>>>> only case.
>>>>
>>>> In my mind, this is judgment call with no absolute right answer. What
>>>> do others think about the tradeoffs?
>>>
>>> Wei had said in private message that he agrees this is a good idea. Nuno
>>> said earlier above:
>>>
>>> "FWIW I think it's a good idea, interested to hear what others think."
>>>
>> That was before Michael pointed out the potential issues which I was
>> unaware of. Let's see if there's a path that is smoother for all the
>> downstream users who may be compiling with CONFIG_HYPERV=m.
>
> Ok, we've already thought of it for sometime and not able to come up
> with any. IMO, it's a minor hickup, not major. This is stalling
> upcoming iommu and other patches which will use CONFIG_HYPERV and
> add more dependencies, and it would be much harder to straighten
> out then. So I hope you guys can come up with some solution sooner than
> later, I can't think of any.
Played around a bit, setting it to "default HYPERV" like Michael suggested
gives it a default value of y. I thought it fail if one is bool and other
is tristate. So that should help with transition.
Thanks,
-Mukesh
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-05 21:41 UTC (permalink / raw)
To: Nuno Das Neves, Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <231f05cb-4f33-48ac-bb2e-1359ed52e606@linux.microsoft.com>
On 9/5/25 13:08, Nuno Das Neves wrote:
> On 9/4/2025 11:18 AM, Mukesh R wrote:
>> On 9/4/25 09:26, Michael Kelley wrote:
>>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>>
>>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>>
>>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>>
>>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>>> CONFIG_HYPERV could be changed to bool.
>>>>>
>>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>>> is already mostly in separate source files code, though there's some
>>>>> entanglement in the handling of VMBus interrupts, which could be
>>>>> improved later.
>>>>>
>>>>> However, I have a compatibility concern. Consider this scenario:
>>>>>
>>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>>> built with CONFIG_HYPERV=m.
>>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>>> 4) Build the new kernel. This succeeds.
>>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>>
>>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>>> newly built kernel has no Hyper-V support and won't run in a
>>>>> Hyper-V VM.
>
> It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
> I guess any invalid value turns to =n, which makes sense most of the time.
>
>>>>>
>>>>> As a second issue, if in Step 1 the current kernel was built with
>>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>>> and won't run in a typical Hyper-V VM.
>>>>>
>>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>>> I'm not sure how to fix the first issue, except by continuing to
>>>>> allow CONFIG_HYPERV=m.
>
> I'm wondering, is there a path for this change, then? Are there some
> intermediate step/s we could take to minimize the problem?
>
>>>>
>>>> To certain extent, imo, users are expected to check config files
>>>> for changes when moving to new versions/releases, so it would be a
>>>> one time burden.
>>>
>>> I'm not so sanguine about the impact. For those of us who work with
>>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>>> the details of how the Kconfig files are put together. And the issue occurs
>>> with no error messages that something has gone wrong in building
>>> the kernel, except that it won't boot. Just running "make olddefconfig"
>>> has worked in the past, so some users will be befuddled and end up
>>> generating Azure support incidents. I also wonder about breaking
>>> automated test suites for new kernels, as they are likely to be running
>>> "make olddefconfig" or something similar as part of the automation.
>>>
>>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>>
>>>
>>> I agree that's not ideal. But note that some Hyper-V code and symbols
>>> like ms_hyperv_init_platform() and related functions show up when
>>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>>> is one of the recognized and somewhat hardwired hypervisors (like
>>> VMware, for example).
>>>
>>> Finally, there are about a dozen other places in the kernel that use
>>> the same Makefile construct to make some code built-in even though
>>> the CONFIG option is set to "m". That may not be enough occurrences
>>> to make it standard practice, but Hyper-V guests are certainly not the
>>> only case.
>>>
>>> In my mind, this is judgment call with no absolute right answer. What
>>> do others think about the tradeoffs?
>>
>> Wei had said in private message that he agrees this is a good idea. Nuno
>> said earlier above:
>>
>> "FWIW I think it's a good idea, interested to hear what others think."
>>
> That was before Michael pointed out the potential issues which I was
> unaware of. Let's see if there's a path that is smoother for all the
> downstream users who may be compiling with CONFIG_HYPERV=m.
Ok, we've already thought of it for sometime and not able to come up
with any. IMO, it's a minor hickup, not major. This is stalling
upcoming iommu and other patches which will use CONFIG_HYPERV and
add more dependencies, and it would be much harder to straighten
out then. So I hope you guys can come up with some solution sooner than
later, I can't think of any.
Thanks,
-Mukesh
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Nuno Das Neves @ 2025-09-05 20:08 UTC (permalink / raw)
To: Mukesh R, Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <4f38c613-255c-eaf6-0d50-28f8ffc02fff@linux.microsoft.com>
On 9/4/2025 11:18 AM, Mukesh R wrote:
> On 9/4/25 09:26, Michael Kelley wrote:
>> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>>
>>> On 9/2/25 07:42, Michael Kelley wrote:
>>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>>
>>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>>
>>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>>> encompasses builtin code and various other things and not a dedicated config
>>>>> option for VMBUS. Vmbus should really have a config option just like
>>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>>> to build VMBUS driver and make that distinction explicit. With that
>>>>> CONFIG_HYPERV could be changed to bool.
>>>>
>>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>>> is already mostly in separate source files code, though there's some
>>>> entanglement in the handling of VMBus interrupts, which could be
>>>> improved later.
>>>>
>>>> However, I have a compatibility concern. Consider this scenario:
>>>>
>>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>>> built with CONFIG_HYPERV=m.
>>>> 2) Grab a new version of kernel source code that contains this patch set.
>>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>>> 4) Build the new kernel. This succeeds.
>>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>>
>>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>>> newly built kernel has no Hyper-V support and won't run in a
>>>> Hyper-V VM.
It surprises me a little that =m doesn't get 'fixed up' to =y in this case.
I guess any invalid value turns to =n, which makes sense most of the time.
>>>>
>>>> As a second issue, if in Step 1 the current kernel was built with
>>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>>> and won't run in a typical Hyper-V VM.
>>>>
>>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>>> I'm not sure how to fix the first issue, except by continuing to
>>>> allow CONFIG_HYPERV=m.
I'm wondering, is there a path for this change, then? Are there some
intermediate step/s we could take to minimize the problem?
>>>
>>> To certain extent, imo, users are expected to check config files
>>> for changes when moving to new versions/releases, so it would be a
>>> one time burden.
>>
>> I'm not so sanguine about the impact. For those of us who work with
>> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
>> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
>> the details of how the Kconfig files are put together. And the issue occurs
>> with no error messages that something has gone wrong in building
>> the kernel, except that it won't boot. Just running "make olddefconfig"
>> has worked in the past, so some users will be befuddled and end up
>> generating Azure support incidents. I also wonder about breaking
>> automated test suites for new kernels, as they are likely to be running
>> "make olddefconfig" or something similar as part of the automation.
>>
>>> CONFIG_HYPERV=m is just broken imo as one sees that
>>> in .config but magically symbols in drivers/hv are in kerenel.
>>>
>>
>> I agree that's not ideal. But note that some Hyper-V code and symbols
>> like ms_hyperv_init_platform() and related functions show up when
>> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
>> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
>> is one of the recognized and somewhat hardwired hypervisors (like
>> VMware, for example).
>>
>> Finally, there are about a dozen other places in the kernel that use
>> the same Makefile construct to make some code built-in even though
>> the CONFIG option is set to "m". That may not be enough occurrences
>> to make it standard practice, but Hyper-V guests are certainly not the
>> only case.
>>
>> In my mind, this is judgment call with no absolute right answer. What
>> do others think about the tradeoffs?
>
> Wei had said in private message that he agrees this is a good idea. Nuno
> said earlier above:
>
> "FWIW I think it's a good idea, interested to hear what others think."
>
That was before Michael pointed out the potential issues which I was
unaware of. Let's see if there's a path that is smoother for all the
downstream users who may be compiling with CONFIG_HYPERV=m.
Nuno
> Thanks,> -Mukesh
>
>
^ permalink raw reply
* Re: [PATCH 1/6] fbcon: Fix empty lines in fbcon.h
From: Sam Ravnborg @ 2025-09-05 19:00 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: simona, deller, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250818104655.235001-2-tzimmermann@suse.de>
On Mon, Aug 18, 2025 at 12:36:36PM +0200, Thomas Zimmermann wrote:
> Add and remove empty lines as necessary to fix coding style. No
> functional changes.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply
* Re: [PATCH 6/6] fbcon: Pass struct fbcon to callbacks in struct fbcon_bitops
From: Sam Ravnborg @ 2025-09-05 19:00 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: simona, deller, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250818104655.235001-7-tzimmermann@suse.de>
On Mon, Aug 18, 2025 at 12:36:41PM +0200, Thomas Zimmermann wrote:
> The callbacks in struct fbcon_bitops are for struct fbcon. Pass an
> instance to the callbacks; instead of the respective struct fb_info.
This looks looks like a pointless change.
All the operations requires fb_info and needs to pcik it anyway.
Sam
^ permalink raw reply
* Re: [PATCH 4/6] fbcon: Move fbcon callbacks into struct fbcon_bitops
From: Sam Ravnborg @ 2025-09-05 18:53 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: simona, deller, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250818104655.235001-5-tzimmermann@suse.de>
Hi Thomas.
On Mon, Aug 18, 2025 at 12:36:39PM +0200, Thomas Zimmermann wrote:
> Depending on rotation settings, fbcon sets different callback
> functions in struct fbcon from within fbcon_set_bitops(). Declare
> the callback functions in the new type struct fbcon_bitops. Then
> only replace the single bitops pointer in struct fbcon.
>
> Keeping callbacks in constant instances of struct fbcon_bitops
> makes it harder to exploit the callbacks. Also makes the code slightly
> easier to maintain.
>
> For tile-based consoles, there's a separate instance of the bitops
> structure.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/core/bitblit.c | 17 ++++---
> drivers/video/fbdev/core/fbcon.c | 67 +++++++++++++++-------------
> drivers/video/fbdev/core/fbcon.h | 7 ++-
> drivers/video/fbdev/core/fbcon_ccw.c | 18 +++++---
> drivers/video/fbdev/core/fbcon_cw.c | 18 +++++---
> drivers/video/fbdev/core/fbcon_ud.c | 18 +++++---
> drivers/video/fbdev/core/tileblit.c | 16 ++++---
> 7 files changed, 94 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
> index a2202cae0691..267bd1635a41 100644
> --- a/drivers/video/fbdev/core/bitblit.c
> +++ b/drivers/video/fbdev/core/bitblit.c
> @@ -384,15 +384,18 @@ static int bit_update_start(struct fb_info *info)
> return err;
> }
>
> +static const struct fbcon_bitops bit_fbcon_bitops = {
> + .bmove = bit_bmove,
> + .clear = bit_clear,
> + .putcs = bit_putcs,
> + .clear_margins = bit_clear_margins,
> + .cursor = bit_cursor,
> + .update_start = bit_update_start,
> +};
> +
> void fbcon_set_bitops(struct fbcon *confb)
> {
> - confb->bmove = bit_bmove;
> - confb->clear = bit_clear;
> - confb->putcs = bit_putcs;
> - confb->clear_margins = bit_clear_margins;
> - confb->cursor = bit_cursor;
> - confb->update_start = bit_update_start;
> - confb->rotate_font = NULL;
> + confb->bitops = &bit_fbcon_bitops;
>
> if (confb->rotate)
> fbcon_set_rotate(confb);
fbcon_set_rotate() is only used to set the correct bitops.
It would be simpler to just do
if (confb->rotate)
confb->bitops = fbcon_rotate_get_ops();
And rename fbcon_set_rotate() to fbcon_rotate_get_ops() and return the
pointer to the struct.
The no need to pass the struct, and it is obvious that the bitops are
overwritten.
Sam
^ permalink raw reply
* Re: [PATCH 3/6] fbcon: Set rotate_font callback with related callbacks
From: Sam Ravnborg @ 2025-09-05 18:37 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: simona, deller, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250818104655.235001-4-tzimmermann@suse.de>
On Mon, Aug 18, 2025 at 12:36:38PM +0200, Thomas Zimmermann wrote:
> The field struct fbcon.rotate_font points to fbcon_rotate_font() if
> the console is rotated. Set the callback in the same place as the other
> callbacks. Prepares for declaring all fbcon callbacks in a dedicated
> struct type.
>
> If not rotated, fbcon_set_bitops() still clears the callback to NULL.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply
* Re: [PATCH 2/6] fbcon: Rename struct fbcon_ops to struct fbcon
From: Sam Ravnborg @ 2025-09-05 18:31 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: simona, deller, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20250818104655.235001-3-tzimmermann@suse.de>
Hi Thomas.
(I needed a distraction - this patchset was my excuse).
On Mon, Aug 18, 2025 at 12:36:37PM +0200, Thomas Zimmermann wrote:
> The type struct fbcon_ops contains fbcon state and callbacks. As the
> callbacks will be removed from struct fbcon_ops, rename the data type
> to struct fbcon. Also rename the variables from ops to confb.
My personal preference would be to name the variable fbcon.
This matches the name of the struct, and I did not see any conflicts
while browsing the diff.
But this is bikeshedding..
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Assuming the bug reported by the kernel robot is fixed.
Sam
^ permalink raw reply
* Re: [PATCH 0/6] fbcon: Move bitops callbacks into separate struct
From: Thomas Zimmermann @ 2025-09-05 6:56 UTC (permalink / raw)
To: simona, deller, linux-fbdev, dri-devel; +Cc: linux-kernel
In-Reply-To: <20250818104655.235001-1-tzimmermann@suse.de>
ping for a review
Am 18.08.25 um 12:36 schrieb Thomas Zimmermann:
> Instances of fbcon use a number callbacks to support tile-based
> drawing or console rotation. The fields are writeable in struct
> fbcon_ops. Each case; unrotated, various rotated and tile-based
> drawing; uses a set of related calbacks. Updating these 'bitops'
> at runtime is spread throughout various helper functions.
>
> This series puts related callbacks into dedicated instances of the
> new type struct fbcon_bitops. Changing the callbacks at runtime
> then only requires to pick the correct instance. It further allows
> the various struct fbcon_bitops' to be declared 'static const', which
> makes them write-protected at runtime.
>
> Makes the fbcon bitops easier and safer to use and modify.
>
> Thomas Zimmermann (6):
> fbcon: Fix empty lines in fbcon.h
> fbcon: Rename struct fbcon_ops to struct fbcon
> fbcon: Set rotate_font callback with related callbacks
> fbcon: Move fbcon callbacks into struct fbcon_bitops
> fbcon: Streamline setting rotated/unrotated bitops
> fbcon: Pass struct fbcon to callbacks in struct fbcon_bitops
>
> drivers/video/fbdev/core/bitblit.c | 148 ++++----
> drivers/video/fbdev/core/fb_internal.h | 2 +
> drivers/video/fbdev/core/fbcon.c | 459 ++++++++++++------------
> drivers/video/fbdev/core/fbcon.h | 33 +-
> drivers/video/fbdev/core/fbcon_ccw.c | 180 +++++-----
> drivers/video/fbdev/core/fbcon_cw.c | 172 ++++-----
> drivers/video/fbdev/core/fbcon_rotate.c | 47 +--
> drivers/video/fbdev/core/fbcon_rotate.h | 18 +-
> drivers/video/fbdev/core/fbcon_ud.c | 192 +++++-----
> drivers/video/fbdev/core/softcursor.c | 18 +-
> drivers/video/fbdev/core/tileblit.c | 49 +--
> 11 files changed, 681 insertions(+), 637 deletions(-)
>
--
--
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)
^ permalink raw reply
* [PATCH] fbdev: Delay the setting of fbcon_ops to fix KASAN issues
From: Zizhi Wo @ 2025-09-05 2:43 UTC (permalink / raw)
To: deller, tzimmermann, lee, jani.nikula, oushixiong, soci
Cc: linux-kernel, linux-fbdev, dri-devel, yangerkun, wozizhi
[BUG]
Recently, we encountered a KASAN warning as follows:
kasan_report+0xaf/0xe0 mm/kasan/report.c:588
fb_pad_aligned_buffer+0x12f/0x150 drivers/video/fbdev/core/fbmem.c:116
ccw_putcs_aligned drivers/video/fbdev/core/fbcon_ccw.c:119 [inline]
ccw_putcs+0x9ac/0xbb0 drivers/video/fbdev/core/fbcon_ccw.c:175
fbcon_putcs+0x329/0x3f0 drivers/video/fbdev/core/fbcon.c:1297
do_update_region+0x3de/0x670 drivers/tty/vt/vt.c:623
invert_screen+0x1de/0x600 drivers/tty/vt/vt.c:748
highlight drivers/tty/vt/selection.c:57 [inline]
clear_selection+0x5e/0x70 drivers/tty/vt/selection.c:81
vc_do_resize+0xc8e/0xf40 drivers/tty/vt/vt.c:1206
fbcon_modechanged+0x489/0x7a0 drivers/video/fbdev/core/fbcon.c:2705
fbcon_set_all_vcs+0x1e0/0x600 drivers/video/fbdev/core/fbcon.c:2752
fbcon_rotate_all drivers/video/fbdev/core/fbcon.c:250 [inline]
...
reproduce[probabilistic, depending on the width and height of vc_font, as
well as the value of "p" in do_update_region()]:
1) echo 2 > /sys/devices/virtual/graphics/fbcon/rotate_all
2) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all
[CAUSE]
The root cause is that fbcon_modechanged() first sets the current rotate's
corresponding ops. Subsequently, during vc_resize(), it may trigger
clear_selection(), and in fbcon_putcs->ccw_putcs[rotate=3], this can result
in an out-of-bounds access to "src". This happens because ops->fontbuffer
is reallocated in fbcon_rotate_font():
1) When rotate=2, its size is (width + 7) / 8 * height
2) When rotate=3, its size is (height + 7) / 8 * width
And the call to fbcon_rotate_font() occurs after clear_selection(). In
other words, the fontbuffer is allocated using the size calculated from the
previous rotation[2], but before reallocating it with the new size,
con_putcs is already using the new rotation[3]:
rotate_all_store
fbcon_rotate_all
fbcon_set_all_vcs
fbcon_modechanged
...
fbcon_set_rotate
fbcon_rotate_ccw
ops->putcs = ccw_putcs // set rotate 3 ops
vc_resize
...
clear_selection
highlight
...
do_update_region
fbcon_putcs
ccw_putcs_aligned
src = ops->fontbuffer + (scr_readw(s--) & charmask)*cellsize
fb_pad_aligned_buffer----[src KASAN!!!]
update_screen
redraw_screen
fbcon_switch
fbcon_rotate_font
dst = kmalloc_array(len, d_cellsize, GFP_KERNEL)
ops->fontbuffer = dst
[FIX]
Considering that when the rotation changes, clear_selection() should clear
the previously selected region and not consider the new rotation yet.
Therefore, the assignment to fbcon_ops for the newly set rotate can be
postponed to fbcon_rotate_font(), since the fontbuffer is regenerated
there. To avoid affecting other code paths, fbcon_set_rotate() will
temporarily continue assigning fbcon_ops based on cur_rotate not rotate.
Signed-off-by: Zizhi Wo <wozizhi@huaweicloud.com>
---
drivers/video/fbdev/core/fbcon_rotate.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon_rotate.c b/drivers/video/fbdev/core/fbcon_rotate.c
index ec3c883400f7..d76446da24d4 100644
--- a/drivers/video/fbdev/core/fbcon_rotate.c
+++ b/drivers/video/fbdev/core/fbcon_rotate.c
@@ -70,6 +70,7 @@ static int fbcon_rotate_font(struct fb_info *info, struct vc_data *vc)
src += s_cellsize;
dst += d_cellsize;
}
+ fbcon_rotate_ud(ops);
break;
case FB_ROTATE_CW:
for (i = len; i--; ) {
@@ -78,6 +79,7 @@ static int fbcon_rotate_font(struct fb_info *info, struct vc_data *vc)
src += s_cellsize;
dst += d_cellsize;
}
+ fbcon_rotate_cw(ops);
break;
case FB_ROTATE_CCW:
for (i = len; i--; ) {
@@ -86,6 +88,7 @@ static int fbcon_rotate_font(struct fb_info *info, struct vc_data *vc)
src += s_cellsize;
dst += d_cellsize;
}
+ fbcon_rotate_ccw(ops);
break;
}
@@ -97,7 +100,7 @@ void fbcon_set_rotate(struct fbcon_ops *ops)
{
ops->rotate_font = fbcon_rotate_font;
- switch(ops->rotate) {
+ switch (ops->cur_rotate) {
case FB_ROTATE_CW:
fbcon_rotate_cw(ops);
break;
--
2.39.2
^ permalink raw reply related
* subscribe
From: Zizhi Wo @ 2025-09-05 1:00 UTC (permalink / raw)
To: linux-fbdev
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-04 18:18 UTC (permalink / raw)
To: Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <SN6PR02MB41573C5451F21286667C5441D400A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 9/4/25 09:26, Michael Kelley wrote:
> From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>>
>> On 9/2/25 07:42, Michael Kelley wrote:
>>> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>>>
>>>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>>>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>>>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>>>> built if CONFIG_HYPER is set, either loadable or builtin.
>>>>
>>>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>>>> encompasses builtin code and various other things and not a dedicated config
>>>> option for VMBUS. Vmbus should really have a config option just like
>>>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>>>> to build VMBUS driver and make that distinction explicit. With that
>>>> CONFIG_HYPERV could be changed to bool.
>>>
>>> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
>>> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
>>> is already mostly in separate source files code, though there's some
>>> entanglement in the handling of VMBus interrupts, which could be
>>> improved later.
>>>
>>> However, I have a compatibility concern. Consider this scenario:
>>>
>>> 1) Assume running in a Hyper-V VM with a current Linux kernel version
>>> built with CONFIG_HYPERV=m.
>>> 2) Grab a new version of kernel source code that contains this patch set.
>>> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
>>> 4) Build the new kernel. This succeeds.
>>> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>>>
>>> The failure occurs because CONFIG_HYPERV=m is no longer legal,
>>> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
>>> newly built kernel has no Hyper-V support and won't run in a
>>> Hyper-V VM.
>>>
>>> As a second issue, if in Step 1 the current kernel was built with
>>> CONFIG_HYPERV=y, then the .config file for the new kernel will have
>>> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
>>> defaults to 'n', so the new kernel doesn't have any VMBus drivers
>>> and won't run in a typical Hyper-V VM.
>>>
>>> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
>>> a default value, such as whatever CONFIG_HYPERV is set to. But
>>> I'm not sure how to fix the first issue, except by continuing to
>>> allow CONFIG_HYPERV=m.
>>
>> To certain extent, imo, users are expected to check config files
>> for changes when moving to new versions/releases, so it would be a
>> one time burden.
>
> I'm not so sanguine about the impact. For those of us who work with
> Hyper-V frequently, yes, it's probably not that big of an issue -- we can
> figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
> the details of how the Kconfig files are put together. And the issue occurs
> with no error messages that something has gone wrong in building
> the kernel, except that it won't boot. Just running "make olddefconfig"
> has worked in the past, so some users will be befuddled and end up
> generating Azure support incidents. I also wonder about breaking
> automated test suites for new kernels, as they are likely to be running
> "make olddefconfig" or something similar as part of the automation.
>
>> CONFIG_HYPERV=m is just broken imo as one sees that
>> in .config but magically symbols in drivers/hv are in kerenel.
>>
>
> I agree that's not ideal. But note that some Hyper-V code and symbols
> like ms_hyperv_init_platform() and related functions show up when
> CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
> the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
> is one of the recognized and somewhat hardwired hypervisors (like
> VMware, for example).
>
> Finally, there are about a dozen other places in the kernel that use
> the same Makefile construct to make some code built-in even though
> the CONFIG option is set to "m". That may not be enough occurrences
> to make it standard practice, but Hyper-V guests are certainly not the
> only case.
>
> In my mind, this is judgment call with no absolute right answer. What
> do others think about the tradeoffs?
Wei had said in private message that he agrees this is a good idea. Nuno
said earlier above:
"FWIW I think it's a good idea, interested to hear what others think."
Thanks,
-Mukesh
^ permalink raw reply
* RE: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Michael Kelley @ 2025-09-04 16:26 UTC (permalink / raw)
To: Mukesh R, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <ff4c58f1-564d-ddfa-bdff-48ffee6e0d72@linux.microsoft.com>
From: Mukesh R <mrathor@linux.microsoft.com> Sent: Wednesday, September 3, 2025 7:17 PM
>
> On 9/2/25 07:42, Michael Kelley wrote:
> > From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
> >>
> >> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
> >> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> >> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> >> built if CONFIG_HYPER is set, either loadable or builtin.
> >>
> >> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
> >> encompasses builtin code and various other things and not a dedicated config
> >> option for VMBUS. Vmbus should really have a config option just like
> >> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
> >> to build VMBUS driver and make that distinction explicit. With that
> >> CONFIG_HYPERV could be changed to bool.
> >
> > Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
> > support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
> > is already mostly in separate source files code, though there's some
> > entanglement in the handling of VMBus interrupts, which could be
> > improved later.
> >
> > However, I have a compatibility concern. Consider this scenario:
> >
> > 1) Assume running in a Hyper-V VM with a current Linux kernel version
> > built with CONFIG_HYPERV=m.
> > 2) Grab a new version of kernel source code that contains this patch set.
> > 3) Run 'make olddefconfig' to create the .config file for the new kernel.
> > 4) Build the new kernel. This succeeds.
> > 5) Install and run the new kernel in the Hyper-V VM. This fails.
> >
> > The failure occurs because CONFIG_HYPERV=m is no longer legal,
> > so the .config file created in Step 3 has CONFIG_HYPERV=n. The
> > newly built kernel has no Hyper-V support and won't run in a
> > Hyper-V VM.
> >
> > As a second issue, if in Step 1 the current kernel was built with
> > CONFIG_HYPERV=y, then the .config file for the new kernel will have
> > CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
> > defaults to 'n', so the new kernel doesn't have any VMBus drivers
> > and won't run in a typical Hyper-V VM.
> >
> > The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
> > a default value, such as whatever CONFIG_HYPERV is set to. But
> > I'm not sure how to fix the first issue, except by continuing to
> > allow CONFIG_HYPERV=m.
>
> To certain extent, imo, users are expected to check config files
> for changes when moving to new versions/releases, so it would be a
> one time burden.
I'm not so sanguine about the impact. For those of us who work with
Hyper-V frequently, yes, it's probably not that big of an issue -- we can
figure it out. But a lot of Azure/Hyper-V users aren't that familiar with
the details of how the Kconfig files are put together. And the issue occurs
with no error messages that something has gone wrong in building
the kernel, except that it won't boot. Just running "make olddefconfig"
has worked in the past, so some users will be befuddled and end up
generating Azure support incidents. I also wonder about breaking
automated test suites for new kernels, as they are likely to be running
"make olddefconfig" or something similar as part of the automation.
> CONFIG_HYPERV=m is just broken imo as one sees that
> in .config but magically symbols in drivers/hv are in kerenel.
>
I agree that's not ideal. But note that some Hyper-V code and symbols
like ms_hyperv_init_platform() and related functions show up when
CONFIG_HYPERVISOR_GUEST=y, even if CONFIG_HYPERV=n. That's
the code in arch/x86/kernel/cpu/mshyperv.c and it's because Hyper-V
is one of the recognized and somewhat hardwired hypervisors (like
VMware, for example).
Finally, there are about a dozen other places in the kernel that use
the same Makefile construct to make some code built-in even though
the CONFIG option is set to "m". That may not be enough occurrences
to make it standard practice, but Hyper-V guests are certainly not the
only case.
In my mind, this is judgment call with no absolute right answer. What
do others think about the tradeoffs?
Michael
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-04 2:16 UTC (permalink / raw)
To: Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <SN6PR02MB4157917D84D00DBDAF54BD69D406A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 9/2/25 07:42, Michael Kelley wrote:
> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>
>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>> built if CONFIG_HYPER is set, either loadable or builtin.
>>
>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>> encompasses builtin code and various other things and not a dedicated config
>> option for VMBUS. Vmbus should really have a config option just like
>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>> to build VMBUS driver and make that distinction explicit. With that
>> CONFIG_HYPERV could be changed to bool.
>
> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
> is already mostly in separate source files code, though there's some
> entanglement in the handling of VMBus interrupts, which could be
> improved later.
>
> However, I have a compatibility concern. Consider this scenario:
>
> 1) Assume running in a Hyper-V VM with a current Linux kernel version
> built with CONFIG_HYPERV=m.
> 2) Grab a new version of kernel source code that contains this patch set.
> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
> 4) Build the new kernel. This succeeds.
> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>
> The failure occurs because CONFIG_HYPERV=m is no longer legal,
> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
> newly built kernel has no Hyper-V support and won't run in a
> Hyper-V VM.
>
> As a second issue, if in Step 1 the current kernel was built with
> CONFIG_HYPERV=y, then the .config file for the new kernel will have
> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
> defaults to 'n', so the new kernel doesn't have any VMBus drivers
> and won't run in a typical Hyper-V VM.
>
> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
> a default value, such as whatever CONFIG_HYPERV is set to. But
> I'm not sure how to fix the first issue, except by continuing to
> allow CONFIG_HYPERV=m.
To certain extent, imo, users are expected to check config files
for changes when moving to new versions/releases, so it would be a
one time burden. CONFIG_HYPERV=m is just broken imo as one sees that
in .config but magically symbols in drivers/hv are in kerenel.
Thanks,
-Mukesh
> See additional minor comments in Patches 1 and 2.
>
> Michael
>
>>
>> For now, hv_common.c is left as is to reduce conflicts for upcoming patches,
>> but once merges are mostly done, that and some others should be moved to
>> virt/hyperv directory.
>>
>> Mukesh Rathor (2):
>> hyper-v: Add CONFIG_HYPERV_VMBUS option
>> hyper-v: Make CONFIG_HYPERV bool
>>
>> drivers/Makefile | 2 +-
>> drivers/gpu/drm/Kconfig | 2 +-
>> drivers/hid/Kconfig | 2 +-
>> drivers/hv/Kconfig | 14 ++++++++++----
>> drivers/hv/Makefile | 4 ++--
>> drivers/input/serio/Kconfig | 4 ++--
>> drivers/net/hyperv/Kconfig | 2 +-
>> drivers/pci/Kconfig | 2 +-
>> drivers/scsi/Kconfig | 2 +-
>> drivers/uio/Kconfig | 2 +-
>> drivers/video/fbdev/Kconfig | 2 +-
>> include/asm-generic/mshyperv.h | 8 +++++---
>> net/vmw_vsock/Kconfig | 2 +-
>> 13 files changed, 28 insertions(+), 20 deletions(-)
>>
>> --
>> 2.36.1.vfs.0.0
>>
^ permalink raw reply
* [PATCH] fbdev: s3fb: revert mclk stop in suspend
From: Zsolt Kajtar @ 2025-09-03 19:14 UTC (permalink / raw)
To: linux-fbdev, deller; +Cc: Zsolt Kajtar
There are systems which want to wait for as long as it takes for the
stopped video memory to answer. Mapping it out helps to avoid that
while the system is running but standby still hangs somehow. So just
leave the memory on in standby same as it was before my change.
Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org>
---
drivers/video/fbdev/s3fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index a6cfed0a87..ba30e5568c 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -1510,7 +1510,7 @@ static int __maybe_unused s3_pci_suspend(struct device *dev)
fb_set_suspend(info, 1);
svga_wseq_mask(par->state.vgabase, 0x18, 0x20, 0x20);
- svga_wseq_mask(par->state.vgabase, 0x14, 0x03, 0x03);
+ svga_wseq_mask(par->state.vgabase, 0x14, 0x01, 0x01);
mutex_unlock(&(par->open_lock));
console_unlock();
@@ -1539,7 +1539,7 @@ static int __maybe_unused s3_pci_resume(struct device *dev)
vga_wseq(par->state.vgabase, 0x08, 0x06);
svga_wseq_mask(par->state.vgabase, 0x18, 0x00, 0x20);
- svga_wseq_mask(par->state.vgabase, 0x14, 0x00, 0x03);
+ svga_wseq_mask(par->state.vgabase, 0x14, 0x00, 0x01);
s3fb_set_par(info);
fb_set_suspend(info, 0);
--
2.30.2
^ permalink raw reply related
* RE: [PATCH V0 2/2] hyper-v: Make CONFIG_HYPERV bool
From: Michael Kelley @ 2025-09-02 14:42 UTC (permalink / raw)
To: Mukesh Rathor, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <20250828005952.884343-3-mrathor@linux.microsoft.com>
From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
Same comment about patch "Subject:" prefix.
> CONFIG_HYPERV is an umbrella config option involved in enabling hyperv
s/hyperv/Hyper-V/
> support and build of modules like hyperv-balloon, hyperv-vmbus, etc..
With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, I think
of CONFIG_HYPERV as the core Hyper-V hypervisor support, such as
hypercalls, clocks/timers, Confidential Computing setup, etc. that
doesn't involve VMBus or VMBus devices.
> As such it should be bool and the hack in Makefile be removed.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
> drivers/Makefile | 2 +-
> drivers/hv/Kconfig | 2 +-
> drivers/hv/Makefile | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index b5749cf67044..7ad5744db0b6 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE) += soundwire/
>
> # Virtualization drivers
> obj-$(CONFIG_VIRT_DRIVERS) += virt/
> -obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
> +obj-$(CONFIG_HYPERV) += hv/
>
> obj-$(CONFIG_PM_DEVFREQ) += devfreq/
> obj-$(CONFIG_EXTCON) += extcon/
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 08c4ed005137..b860bc1026b7 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -3,7 +3,7 @@
> menu "Microsoft Hyper-V guest support"
>
> config HYPERV
> - tristate "Microsoft Hyper-V client drivers"
> + bool "Microsoft Hyper-V client drivers"
I would want to change the prompt here to be more specific, such as:
bool "Microsoft Hyper-V core hypervisor support"
As noted in my comments on the cover letter, this change causes
.config file compatibility problems. I can't immediately think of
a way to deal with the compatibility problem and still change this
from tristate to bool.
> depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
> || (ARM64 && !CPU_BIG_ENDIAN)
> select PARAVIRT
> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
> index 050517756a82..8b04a33e4dd8 100644
> --- a/drivers/hv/Makefile
> +++ b/drivers/hv/Makefile
> @@ -18,7 +18,7 @@ mshv_root-y := mshv_root_main.o mshv_synic.o
> mshv_eventfd.o mshv_irq.o \
> mshv_vtl-y := mshv_vtl_main.o
>
> # Code that must be built-in
> -obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
> +obj-$(CONFIG_HYPERV) += hv_common.o
> obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o
> ifneq ($(CONFIG_MSHV_ROOT) $(CONFIG_MSHV_VTL),)
> obj-y += mshv_common.o
> --
> 2.36.1.vfs.0.0
>
^ permalink raw reply
* RE: [PATCH V0 1/2] hyper-v: Add CONFIG_HYPERV_VMBUS option
From: Michael Kelley @ 2025-09-02 14:42 UTC (permalink / raw)
To: Mukesh Rathor, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <20250828005952.884343-2-mrathor@linux.microsoft.com>
From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>
Even though this patch touches multiple subdirectories under "drivers",
I'd suggest the patch "Subject:" prefix should be "Drivers: hv:" (not "hyper-v:")
to be consistent with historical usage.
> Somehow vmbus driver is hinged on CONFIG_HYPERV. It appears this is initial
In text, "vmbus" should be spelled as "VMBus". This includes patch Subjects,
commit messages, code comments, kernel messages, and kernel documentation.
Originally, the spelling was all over the map, but we've tried to be more consistent
lately in matching Microsoft's public documentation on Hyper-V, which uses
"VMBus". Of course, C language code variable and function names use all lowercase.
> code that did not get addressed when the scope of CONFIG_HYPERV went beyond
> vmbus. This commit creates a fine grained HYPERV_VMBUS option and updates
> drivers that depend on VMBUS.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
> drivers/gpu/drm/Kconfig | 2 +-
> drivers/hid/Kconfig | 2 +-
> drivers/hv/Kconfig | 12 +++++++++---
> drivers/hv/Makefile | 2 +-
> drivers/input/serio/Kconfig | 4 ++--
> drivers/net/hyperv/Kconfig | 2 +-
> drivers/pci/Kconfig | 2 +-
> drivers/scsi/Kconfig | 2 +-
> drivers/uio/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> include/asm-generic/mshyperv.h | 8 +++++---
> net/vmw_vsock/Kconfig | 2 +-
> 12 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f7ea8e895c0c..58f34da061c6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
>
> config DRM_HYPERV
> tristate "DRM Support for Hyper-V synthetic video device"
> - depends on DRM && PCI && HYPERV
> + depends on DRM && PCI && HYPERV_VMBUS
> select DRM_CLIENT_SELECTION
> select DRM_KMS_HELPER
> select DRM_GEM_SHMEM_HELPER
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a57901203aeb..fe3dc8c0db99 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1162,7 +1162,7 @@ config GREENASIA_FF
>
> config HID_HYPERV_MOUSE
> tristate "Microsoft Hyper-V mouse driver"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> help
> Select this option to enable the Hyper-V mouse driver.
>
> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 2e8df09db599..08c4ed005137 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -44,18 +44,24 @@ config HYPERV_TIMER
>
> config HYPERV_UTILS
> tristate "Microsoft Hyper-V Utilities driver"
> - depends on HYPERV && CONNECTOR && NLS
> + depends on HYPERV_VMBUS && CONNECTOR && NLS
> depends on PTP_1588_CLOCK_OPTIONAL
> help
> Select this option to enable the Hyper-V Utilities.
>
> config HYPERV_BALLOON
> tristate "Microsoft Hyper-V Balloon driver"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> select PAGE_REPORTING
> help
> Select this option to enable Hyper-V Balloon driver.
>
> +config HYPERV_VMBUS
> + tristate "Microsoft Hyper-V Vmbus driver"
As described above,
s/Vmbus/VMBus/
> + depends on HYPERV
Per my comments on the cover letter, could add
"default HYPERV" here to help ease the transition.
> + help
> + Select this option to enable Hyper-V Vmbus driver.
s/Vmbus/VMBus/
> +
> config MSHV_ROOT
> tristate "Microsoft Hyper-V root partition support"
> depends on HYPERV && (X86_64 || ARM64)
> @@ -75,7 +81,7 @@ config MSHV_ROOT
>
> config MSHV_VTL
> tristate "Microsoft Hyper-V VTL driver"
> - depends on X86_64 && HYPERV_VTL_MODE
> + depends on X86_64 && HYPERV_VTL_MODE && HYPERV_VMBUS
An observation: conceptually I would not expect this driver to
depend on HYPERV_VMBUS because it is not a VMBus driver. But
looking at the code, this is a place where VMBus interrupt handling
bleeds into code that is otherwise just hypervisor functionality. So
evidently the HYPERV_VMBUS dependency is needed for now.
Getting better separation and avoiding the dependency could be
done later.
> # Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
> # VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
> # specially with large memory requirements.
> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
> index c53a0df746b7..050517756a82 100644
> --- a/drivers/hv/Makefile
> +++ b/drivers/hv/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_HYPERV) += hv_vmbus.o
> +obj-$(CONFIG_HYPERV_VMBUS) += hv_vmbus.o
> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index 17edc1597446..c7ef347a4dff 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
>
> config HYPERV_KEYBOARD
> tristate "Microsoft Synthetic Keyboard driver"
> - depends on HYPERV
> - default HYPERV
> + depends on HYPERV_VMBUS
> + default HYPERV_VMBUS
> help
> Select this option to enable the Hyper-V Keyboard driver.
>
> diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
> index c8cbd85adcf9..982964c1a9fb 100644
> --- a/drivers/net/hyperv/Kconfig
> +++ b/drivers/net/hyperv/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config HYPERV_NET
> tristate "Microsoft Hyper-V virtual network driver"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> select UCS2_STRING
> select NLS
> help
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 9a249c65aedc..7065a8e5f9b1 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -221,7 +221,7 @@ config PCI_LABEL
>
> config PCI_HYPERV
> tristate "Hyper-V PCI Frontend"
> - depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
> + depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI
> && SYSFS
> select PCI_HYPERV_INTERFACE
> select IRQ_MSI_LIB
> help
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 5522310bab8d..19d0884479a2 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
>
> config HYPERV_STORAGE
> tristate "Microsoft Hyper-V virtual storage driver"
> - depends on SCSI && HYPERV
> + depends on SCSI && HYPERV_VMBUS
> depends on m || SCSI_FC_ATTRS != m
> default HYPERV
> help
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index b060dcd7c635..6f86a61231e6 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -140,7 +140,7 @@ config UIO_MF624
>
> config UIO_HV_GENERIC
> tristate "Generic driver for Hyper-V VMBus"
> - depends on HYPERV
> + depends on HYPERV_VMBUS
> help
> Generic driver that you can bind, dynamically, to any
> Hyper-V VMBus device. It is useful to provide direct access
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c21484d15f0c..72c63eaeb983 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1774,7 +1774,7 @@ config FB_BROADSHEET
>
> config FB_HYPERV
> tristate "Microsoft Hyper-V Synthetic Video support"
> - depends on FB && HYPERV
> + depends on FB && HYPERV_VMBUS
> select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
> select FB_IOMEM_HELPERS_DEFERRED
> help
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
> index 1d2ad1304ad4..66c58c91b530 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -165,6 +165,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
>
> void __init hv_mark_resources(void);
>
> +#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
> /* Free the message slot and signal end-of-message if required */
> static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
> {
> @@ -200,6 +201,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
> }
> }
>
> +extern int vmbus_interrupt;
> +extern int vmbus_irq;
> +#endif /* CONFIG_HYPERV_VMBUS */
> +
> int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
>
> void hv_setup_vmbus_handler(void (*handler)(void));
> @@ -213,9 +218,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
> void hv_remove_crash_handler(void);
> void hv_setup_mshv_handler(void (*handler)(void));
>
> -extern int vmbus_interrupt;
> -extern int vmbus_irq;
> -
> #if IS_ENABLED(CONFIG_HYPERV)
> /*
> * Hypervisor's notion of virtual processor ID is different from
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> index 56356d2980c8..8e803c4828c4 100644
> --- a/net/vmw_vsock/Kconfig
> +++ b/net/vmw_vsock/Kconfig
> @@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
>
> config HYPERV_VSOCKETS
> tristate "Hyper-V transport for Virtual Sockets"
> - depends on VSOCKETS && HYPERV
> + depends on VSOCKETS && HYPERV_VMBUS
> help
> This module implements a Hyper-V transport for Virtual Sockets.
>
> --
> 2.36.1.vfs.0.0
>
^ permalink raw reply
* RE: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Michael Kelley @ 2025-09-02 14:42 UTC (permalink / raw)
To: Mukesh Rathor, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <20250828005952.884343-1-mrathor@linux.microsoft.com>
From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>
> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
> built if CONFIG_HYPER is set, either loadable or builtin.
>
> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
> encompasses builtin code and various other things and not a dedicated config
> option for VMBUS. Vmbus should really have a config option just like
> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
> to build VMBUS driver and make that distinction explicit. With that
> CONFIG_HYPERV could be changed to bool.
Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
is already mostly in separate source files code, though there's some
entanglement in the handling of VMBus interrupts, which could be
improved later.
However, I have a compatibility concern. Consider this scenario:
1) Assume running in a Hyper-V VM with a current Linux kernel version
built with CONFIG_HYPERV=m.
2) Grab a new version of kernel source code that contains this patch set.
3) Run 'make olddefconfig' to create the .config file for the new kernel.
4) Build the new kernel. This succeeds.
5) Install and run the new kernel in the Hyper-V VM. This fails.
The failure occurs because CONFIG_HYPERV=m is no longer legal,
so the .config file created in Step 3 has CONFIG_HYPERV=n. The
newly built kernel has no Hyper-V support and won't run in a
Hyper-V VM.
As a second issue, if in Step 1 the current kernel was built with
CONFIG_HYPERV=y, then the .config file for the new kernel will have
CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
defaults to 'n', so the new kernel doesn't have any VMBus drivers
and won't run in a typical Hyper-V VM.
The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
a default value, such as whatever CONFIG_HYPERV is set to. But
I'm not sure how to fix the first issue, except by continuing to
allow CONFIG_HYPERV=m.
See additional minor comments in Patches 1 and 2.
Michael
>
> For now, hv_common.c is left as is to reduce conflicts for upcoming patches,
> but once merges are mostly done, that and some others should be moved to
> virt/hyperv directory.
>
> Mukesh Rathor (2):
> hyper-v: Add CONFIG_HYPERV_VMBUS option
> hyper-v: Make CONFIG_HYPERV bool
>
> drivers/Makefile | 2 +-
> drivers/gpu/drm/Kconfig | 2 +-
> drivers/hid/Kconfig | 2 +-
> drivers/hv/Kconfig | 14 ++++++++++----
> drivers/hv/Makefile | 4 ++--
> drivers/input/serio/Kconfig | 4 ++--
> drivers/net/hyperv/Kconfig | 2 +-
> drivers/pci/Kconfig | 2 +-
> drivers/scsi/Kconfig | 2 +-
> drivers/uio/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> include/asm-generic/mshyperv.h | 8 +++++---
> net/vmw_vsock/Kconfig | 2 +-
> 13 files changed, 28 insertions(+), 20 deletions(-)
>
> --
> 2.36.1.vfs.0.0
>
^ permalink raw reply
* Re: (subset) [PATCH] backlight: led_bl: Use devm_kcalloc() for array space allocation
From: Lee Jones @ 2025-09-02 10:40 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller, dri-devel,
linux-fbdev, linux-kernel, Qianfeng Rong
In-Reply-To: <20250819035804.433615-1-rongqianfeng@vivo.com>
On Tue, 19 Aug 2025 11:58:03 +0800, Qianfeng Rong wrote:
> Replace calls of devm_kzalloc() with devm_kcalloc() in led_bl_get_leds()
> and led_bl_parse_levels() for safer memory allocation with built-in
> overflow protection.
>
>
Applied, thanks!
[1/1] backlight: led_bl: Use devm_kcalloc() for array space allocation
commit: 7a5e9040f418c2dd5d30fbdc2cad4446a004c6c5
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 2/2] backlight: mp3309c: Initialize backlight properties without memset
From: Lee Jones @ 2025-09-02 10:36 UTC (permalink / raw)
To: Daniel Thompson
Cc: Uwe Kleine-König, Flavio Suligoi, Daniel Thompson,
Jingoo Han, Helge Deller, dri-devel, linux-fbdev, linux-pwm
In-Reply-To: <aKLvaP55PIVhyFSc@aspen.lan>
On Mon, 18 Aug 2025, Daniel Thompson wrote:
> On Tue, Jul 01, 2025 at 11:22:37AM +0200, Uwe Kleine-König wrote:
> > Assigning values to a struct using a compound literal (since C99) also
> > guarantees that all unspecified struct members are empty-initialized, so
> > it properly replaces the memset to zero.
> >
> > The code looks a bit nicer and more idiomatic (though that might be
> > subjective?). The resulting binary is a bit smaller. On ARCH=arm with
> > an allnoconfig + minimal changes to enable the mp3309c driver the
> > difference is 12 bytes.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
>
> Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Looks like you cannot send tags from non-related email accounts:
NOTE: some trailers ignored due to from/email mismatches:
! Trailer: Reviewed-by: "Daniel Thompson (RISCstar)" <danielt@kernel.org>
Msg From: Daniel Thompson <daniel@riscstar.com>
I'll add the tags manually this time.
--
Lee Jones [李琼斯]
^ permalink raw reply
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