On Tue, Mar 11 2025 at 18:10, Jonathan Cameron wrote:
> On Sun, 9 Mar 2025 09:41:49 +0100 (CET)
> Thomas Gleixner wrote:
>
> This one runs into some of the stuff that the docs say
> to not do. I don't there there are bugs in here as such
> but it gets harder to reason a
On Tue, Mar 11 2025 at 18:00, Jonathan Cameron wrote:
> On Sun, 9 Mar 2025 09:41:44 +0100 (CET)
> Thomas Gleixner wrote:
>>
>> @@ -1037,25 +1032,23 @@ bool msi_create_device_irq_domain(struct
>> if (msi_setup_device_data(dev))
>
> Hmm. We might want to m
On Mon, Mar 10 2025 at 11:51, Bjorn Helgaas wrote:
> For the drivers/pci/ parts:
>
> Acked-by: Bjorn Helgaas
>
> I assume you'll merge this somewhere, let me know if otherwise.
Yes. I intend to get it through tip.
Provide a lock guard for MSI descriptor locking and update the core code
accordingly.
No functional change intended.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h |3 +
kernel/irq/msi.c| 104 +++-
2 files changed, 42 insertions
Convert the code to use the new guard(msi_descs_lock).
No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/pci/msi/api.c |6 ++
drivers/pci/msi/msi.c | 30 --
2 files changed, 14
ned-off-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: Wei Huang
Cc: linux-...@vger.kernel.org
---
drivers/pci/tph.c | 44 +---
1 file changed, 1 insertion(+), 43 deletions(-)
--- a/drivers/pci/tph.c
+++ b/drivers/pci/tph.c
@@ -204,48 +204,6 @@
code so it uses dedicated storage to hand the required
information to the interrupt handler.
No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Manivannan Sadhasivam
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vger.kernel.org
---
drivers
Now that all abuse is gone and the legit users are converted to
guard(msi_descs_lock), rename the lock functions and document them as
internal.
No functional chance.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h |8
kernel/irq/msi.c| 16 ++--
2 files
larger pile of infrastructure
and indirections for dubious value.
Signed-off-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: Wei Huang
Cc: linux-...@vger.kernel.org
---
drivers/pci/msi/msi.c | 47 +++
drivers/pci/pci.h |9 +
2 files changed
Convert the code to use the new guard(msi_descs_lock).
No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Jon Mason
Cc: Dave Jiang
Cc: Allen Hubbe
Cc: n...@lists.linux.dev
---
drivers/ntb/msi.c | 22 --
1 file changed, 8 insertions(+), 14 deletions
Convert the code to use the new guard(msi_descs_lock).
No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Haiyang Zhang
Cc: Wei Liu
Cc: Bjorn Helgaas
Cc: linux-hyperv@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/pci-hyperv.c | 14
Convert the code to use the new guard(msi_descs_lock).
No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Nishanth Menon
Cc: Tero Kristo
Cc: Santosh Shilimkar
---
drivers/soc/ti/ti_sci_inta_msi.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
--- a
While converting the MSI descriptor locking to a lock guard() I stumbled
over various abuse of MSI descriptors (again).
The following series cleans up the offending code and converts the MSI
descriptor locking over to lock guard().
The series applies on Linus tree and is also available from git:
None of these functions are used outside of the MSI core.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h |5 -
kernel/irq/msi.c| 40 +++-
2 files changed, 7 insertions(+), 38 deletions(-)
--- a/include/linux/msi.h
+++ b/include/linux
gt; kvmclock resume hook runs before timekeeping_resume()).
>
> Note, there is no evidence that any clocksource supported by the kernel
> depends on a persistent clock.
>
> Signed-off-by: Sean Christopherson
Reviewed-by: Thomas Gleixner
On Fri, Jan 17 2025 at 15:33, Hamza Mahfooz wrote:
> If CONFIG_HYPERV=m, lockdep_assert_cpus_held() is undefined for HyperV.
> So, export the function so that GPL drivers can use it more broadly.
>
> Cc: Michael Kelley
> Signed-off-by: Hamza Mahfooz
Acked-by: Thomas Gleixner
teven Rostedt (Google) # for kernel/trace/
> Reviewed-by: Martin K. Petersen # SCSI
> Reviewed-by: Darrick J. Wong # xfs
> Acked-by: Jani Nikula
> Acked-by: Corey Minyard
> Signed-off-by: Joel Granados
Acked-by: Thomas Gleixner
On Wed, Nov 06 2024 at 22:19, David Laight wrote:
> From: Thomas Gleixner
>> Still the macro should be documented.
>
> I was wondering if it really had any purpose at all.
> It just obfuscates code, doesn't even make it smaller.
What is obfuscated here?
secs_to_jiffies(
On Tue, Oct 29 2024 at 17:22, Geert Uytterhoeven wrote:
> On Tue, Oct 29, 2024 at 5:08 PM Thomas Gleixner wrote:
>> On Mon, Oct 28 2024 at 19:11, Easwar Hariharan wrote:
>> > diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
>> > index 1220f0fbe5bf..e52
On Mon, Oct 28 2024 at 19:11, Easwar Hariharan wrote:
> diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
> index 1220f0fbe5bf..e5256bb5f851 100644
> --- a/include/linux/jiffies.h
> +++ b/include/linux/jiffies.h
> @@ -526,6 +526,8 @@ static __always_inline unsigned long
> msecs_to_jif
On Tue, Aug 06 2024 at 15:12, Yunhong Jiang wrote:
> +static void __init hv_reserve_real_mode(void)
> +{
> + phys_addr_t mem;
> + size_t size = real_mode_size_needed();
> +
> + /*
> + * We only need the memory to be <4GB since the 64-bit trampoline goes
> + * down to 32-bit mo
On Tue, Aug 06 2024 at 15:12, Yunhong Jiang wrote:
> The ACPI wakeup mailbox is accessed by the OS and the firmware, both are
> in the guest's context, instead of the hypervisor/VMM context. Mark the
> address private explicitly.
This lacks information why the realmode area must be reserved and
in
On Tue, Aug 06 2024 at 15:12, Yunhong Jiang wrote:
>
> -static int __init acpi_mp_setup_reset(u64 reset_vector)
> +static int __init __maybe_unused acpi_mp_setup_reset(u64 reset_vector)
> {
> struct x86_mapping_info info = {
> .alloc_pgt_page = alloc_pgt_page,
> @@ -226,7 +22
On Fri, Aug 02 2024 at 12:04, David Woodhouse wrote:
> On Fri, 2024-08-02 at 12:49 +0200, Thomas Gleixner wrote:
>> So fine, we can go with the patch from Li, but the changelog needs a
>> rewrite and the code want's a big fat comment.
>
> Nah, it wants to be MODE, COUNT,
On Fri, Aug 02 2024 at 09:07, David Woodhouse wrote:
> On Thu, 2024-08-01 at 20:57 +0200, Thomas Gleixner wrote:
>> It's not counting right out of reset. But once it started counting it's
>> tedious to stop :)
>
> My reading of the data sheet definitely suggests tha
On Thu, Aug 01 2024 at 21:49, David Woodhouse wrote:
> On Thu, 2024-08-01 at 22:00 +0200, Thomas Gleixner wrote:
>> > I justify my cowardice on the basis that it doesn't *matter* if a
>> > hardware implementation is still toggling the IRQ pin; in that case
>&
On Thu, Aug 01 2024 at 16:22, David Woodhouse wrote:
> On Thu, 2024-08-01 at 10:00 +0100, David Woodhouse wrote:
> bool __init pit_timer_init(void)
> {
> - if (!use_pit())
> + if (!use_pit()) {
> + if (!hypervisor_is_type(X86_HYPER_NATIVE)) {
> + /*
> +
On Thu, Aug 01 2024 at 20:21, David Woodhouse wrote:
> On Thu, 2024-08-01 at 21:06 +0200, Thomas Gleixner wrote:
>> Yes. So the sequence should stop KVM from trying to inject
>> interrupts. Maybe someone fixes it to actually stop fiddling with the
>> counter too :)
>
>
On Thu, Aug 01 2024 at 18:49, David Woodhouse wrote:
> On Thu, 2024-08-01 at 16:21 +0200, Thomas Gleixner wrote:
>> The stop sequence is wrong:
>>
>> When there is a count in progress, writing a new LSB before the
>> counter has counted down to 0 and roll
On Thu, Aug 01 2024 at 19:25, David Woodhouse wrote:
> On Thu, 2024-08-01 at 18:49 +0100, David Woodhouse wrote:
>> > The stop sequence is wrong:
>> >
>> > When there is a count in progress, writing a new LSB before the
>> > counter has counted down to 0 and rolled over to h, WILL stop
On Thu, Aug 01 2024 at 16:14, Michael Kelley wrote:
> From: Thomas Gleixner Sent: Thursday, August 1, 2024
> 7:21 AM
> FWIW, in Hyper-V guests with the Hyper-V quirk removed, tglx's new
> sequence does *not* stop the PIT. But this sequence does:
>
> outb_p(0x30, PIT_MODE);
On Tue, Feb 07 2023 at 09:14, lirongq...@baidu.com wrote:
> @@ -117,11 +110,6 @@ static int pit_shutdown(struct clock_event_device *evt)
>
> outb_p(0x30, PIT_MODE);
>
> - if (i8253_clear_counter_on_shutdown) {
> - outb_p(0, PIT_CH0);
> - outb_p(0, PIT_CH0);
> -
On Thu, Jun 06 2024 at 03:14, Michael Kelley wrote:
> From: Thomas Gleixner Sent: Wednesday, June 5, 2024 7:20
> AM
>>
>> On Wed, Jun 05 2024 at 13:45, Michael Kelley wrote:
>> > From: Thomas Gleixner Sent: Wednesday, June 5, 2024
>> > 6:20 AM
>&
On Wed, Jun 05 2024 at 13:45, Michael Kelley wrote:
> From: Thomas Gleixner Sent: Wednesday, June 5, 2024 6:20
> AM
>
> In /proc/interrupts, the double-counting isn't a problem, and is
> potentially helpful as you say. But /proc/stat, for example, shows a total
> interru
On Tue, Jun 04 2024 at 23:03, Michael Kelley wrote:
> From: Thomas Gleixner Sent: Tuesday, June 4, 2024 11:14
> AM
>>1) Move the inner workings of handle_percpu_irq() out into
>> a static function which returns the 'handled' value and
>> share it
Michael!
On Mon, Jun 03 2024 at 22:09, mhkelle...@gmail.com wrote:
> Hyper-V VMBus devices generate interrupts that are multiplexed
> onto a single per-CPU architectural interrupt. The top-level VMBus
> driver ISR demultiplexes these interrupts and invokes per-device
> handlers. Currently, these p
On Fri, Nov 03 2023 at 19:58, Andrew Cooper wrote:
> On 02/11/2023 12:26 pm, Andrew Cooper wrote:
> Another dodgy construct spotted while doing this work is
>
> #ifdef CONFIG_X86_32
> #define BAD_APICID 0xFFu
> #else
> #define BAD_APICID 0xu
> #endif
>
> considering that both of those "bad" v
On Thu, Nov 02 2023 at 12:26, Andrew Cooper wrote:
> This field is set to APIC_DELIVERY_MODE_FIXED in all cases, and is read
> exactly once. Fold the constant in uv_program_mmr() and drop the field.
>
> Searching for the origin of the stale HyperV comment reveals commit
> a31e58e129f7 ("x86/apic:
38 matches
Mail list logo
