All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Winiarska, Iwona" <iwona.winiarska@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>, "bp@alien8.de" <bp@alien8.de>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"Lutomirski, Andy" <luto@kernel.org>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	"andrew@aj.id.au" <andrew@aj.id.au>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"jdelvare@suse.com" <jdelvare@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"olof@lixom.net" <olof@lixom.net>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"zweiss@equinix.com" <zweiss@equinix.com>,
	"d.mueller@elsoft.ch" <d.mueller@elsoft.ch>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"joel@jms.id.au" <joel@jms.id.au>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"andriy.shevchenko@linux.intel.com" 
	<andriy.shevchenko@linux.intel.com>,
	"yazen.ghannam@amd.com" <yazen.ghannam@amd.com>,
	"pierre-louis.bossart@linux.intel.com" 
	<pierre-louis.bossart@linux.intel.com>
Subject: Re: [PATCH v2 01/15] x86/cpu: Move intel-family to arch-independent headers
Date: Mon, 11 Oct 2021 20:53:51 +0000	[thread overview]
Message-ID: <43e367e452c6c8d9c6a275299d7ff6f2bb26b8e3.camel@intel.com> (raw)
In-Reply-To: <67f2cfda-c78b-6282-f5a3-2f345f8e2849@intel.com>

On Mon, 2021-10-11 at 12:40 -0700, Dave Hansen wrote:
> On 10/11/21 12:21 PM, Winiarska, Iwona wrote:
> > On Mon, 2021-10-04 at 21:03 +0200, Borislav Petkov wrote:
> > > On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:
> > > > Baseboard management controllers (BMC) often run Linux but are usually
> > > > implemented with non-X86 processors. They can use PECI to access package
> > > > config space (PCS) registers on the host CPU and since some information,
> > > > e.g. figuring out the core count, can be obtained using different
> > > > registers on different CPU generations, they need to decode the family
> > > > and model.
> > > > 
> > > > Move the data from arch/x86/include/asm/intel-family.h into a new file
> > > > include/linux/x86/intel-family.h so that it can be used by other
> > > > architectures.
> > > > 
> > > > Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
> > > > Reviewed-by: Tony Luck <tony.luck@intel.com>
> > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > > ---
> > > > To limit tree-wide changes and help people that were expecting
> > > > intel-family defines in arch/x86 to find it more easily without going
> > > > through git history, we're not removing the original header
> > > > completely, we're keeping it as a "stub" that includes the new one.
> > > > If there is a consensus that the tree-wide option is better,
> > > > we can choose this approach.
> > > Why can't the linux/ namespace header include the x86 one so that
> > > nothing changes for arch/x86/?
> > Same reason why PECI can't just include arch/x86 directly (we're building
> > for
> > ARM, not x86).
> If you're in include/linux/x86-hacks.h, what prevents you from doing
> 
> #include "../../arch/x86/include/asm/intel-family.h"
> 
> ?
> 
> In the end, to the compiler, it's just a file in a weird location in the
> tree.  I think I'd prefer one weird include to moving that file out of
> arch/x86.

Using relative includes in include/linux is uncommon (I can see just one usage
in libfdt.h pulling stuff from scripts), so I thought I can't use it in this way
(seems slightly hacky to pull stuff from outside include path).

But if that would be ok, it looks like a good alternative to avoid duplication
in this case.

Thanks
-Iwona

WARNING: multiple messages have this Message-ID (diff)
From: "Winiarska, Iwona" <iwona.winiarska@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>, "bp@alien8.de" <bp@alien8.de>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"Lutomirski, Andy" <luto@kernel.org>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	"andrew@aj.id.au" <andrew@aj.id.au>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"jdelvare@suse.com" <jdelvare@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"olof@lixom.net" <olof@lixom.net>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"zweiss@equinix.com" <zweiss@equinix.com>,
	"d.mueller@elsoft.ch" <d.mueller@elsoft.ch>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"joel@jms.id.au" <joel@jms.id.au>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	"yazen.ghannam@amd.com" <yazen.ghannam@amd.com>,
	"pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.com>
Subject: Re: [PATCH v2 01/15] x86/cpu: Move intel-family to arch-independent headers
Date: Mon, 11 Oct 2021 20:53:51 +0000	[thread overview]
Message-ID: <43e367e452c6c8d9c6a275299d7ff6f2bb26b8e3.camel@intel.com> (raw)
In-Reply-To: <67f2cfda-c78b-6282-f5a3-2f345f8e2849@intel.com>

On Mon, 2021-10-11 at 12:40 -0700, Dave Hansen wrote:
> On 10/11/21 12:21 PM, Winiarska, Iwona wrote:
> > On Mon, 2021-10-04 at 21:03 +0200, Borislav Petkov wrote:
> > > On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:
> > > > Baseboard management controllers (BMC) often run Linux but are usually
> > > > implemented with non-X86 processors. They can use PECI to access package
> > > > config space (PCS) registers on the host CPU and since some information,
> > > > e.g. figuring out the core count, can be obtained using different
> > > > registers on different CPU generations, they need to decode the family
> > > > and model.
> > > > 
> > > > Move the data from arch/x86/include/asm/intel-family.h into a new file
> > > > include/linux/x86/intel-family.h so that it can be used by other
> > > > architectures.
> > > > 
> > > > Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
> > > > Reviewed-by: Tony Luck <tony.luck@intel.com>
> > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > > ---
> > > > To limit tree-wide changes and help people that were expecting
> > > > intel-family defines in arch/x86 to find it more easily without going
> > > > through git history, we're not removing the original header
> > > > completely, we're keeping it as a "stub" that includes the new one.
> > > > If there is a consensus that the tree-wide option is better,
> > > > we can choose this approach.
> > > Why can't the linux/ namespace header include the x86 one so that
> > > nothing changes for arch/x86/?
> > Same reason why PECI can't just include arch/x86 directly (we're building
> > for
> > ARM, not x86).
> If you're in include/linux/x86-hacks.h, what prevents you from doing
> 
> #include "../../arch/x86/include/asm/intel-family.h"
> 
> ?
> 
> In the end, to the compiler, it's just a file in a weird location in the
> tree.  I think I'd prefer one weird include to moving that file out of
> arch/x86.

Using relative includes in include/linux is uncommon (I can see just one usage
in libfdt.h pulling stuff from scripts), so I thought I can't use it in this way
(seems slightly hacky to pull stuff from outside include path).

But if that would be ok, it looks like a good alternative to avoid duplication
in this case.

Thanks
-Iwona
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "Winiarska, Iwona" <iwona.winiarska@intel.com>
To: "Hansen, Dave" <dave.hansen@intel.com>, "bp@alien8.de" <bp@alien8.de>
Cc: "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"zweiss@equinix.com" <zweiss@equinix.com>,
	"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"jdelvare@suse.com" <jdelvare@suse.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"Lutomirski, Andy" <luto@kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	"andrew@aj.id.au" <andrew@aj.id.au>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"yazen.ghannam@amd.com" <yazen.ghannam@amd.com>,
	"olof@lixom.net" <olof@lixom.net>
Subject: Re: [PATCH v2 01/15] x86/cpu: Move intel-family to arch-independent headers
Date: Mon, 11 Oct 2021 20:53:51 +0000	[thread overview]
Message-ID: <43e367e452c6c8d9c6a275299d7ff6f2bb26b8e3.camel@intel.com> (raw)
In-Reply-To: <67f2cfda-c78b-6282-f5a3-2f345f8e2849@intel.com>

On Mon, 2021-10-11 at 12:40 -0700, Dave Hansen wrote:
> On 10/11/21 12:21 PM, Winiarska, Iwona wrote:
> > On Mon, 2021-10-04 at 21:03 +0200, Borislav Petkov wrote:
> > > On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:
> > > > Baseboard management controllers (BMC) often run Linux but are usually
> > > > implemented with non-X86 processors. They can use PECI to access package
> > > > config space (PCS) registers on the host CPU and since some information,
> > > > e.g. figuring out the core count, can be obtained using different
> > > > registers on different CPU generations, they need to decode the family
> > > > and model.
> > > > 
> > > > Move the data from arch/x86/include/asm/intel-family.h into a new file
> > > > include/linux/x86/intel-family.h so that it can be used by other
> > > > architectures.
> > > > 
> > > > Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
> > > > Reviewed-by: Tony Luck <tony.luck@intel.com>
> > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > > ---
> > > > To limit tree-wide changes and help people that were expecting
> > > > intel-family defines in arch/x86 to find it more easily without going
> > > > through git history, we're not removing the original header
> > > > completely, we're keeping it as a "stub" that includes the new one.
> > > > If there is a consensus that the tree-wide option is better,
> > > > we can choose this approach.
> > > Why can't the linux/ namespace header include the x86 one so that
> > > nothing changes for arch/x86/?
> > Same reason why PECI can't just include arch/x86 directly (we're building
> > for
> > ARM, not x86).
> If you're in include/linux/x86-hacks.h, what prevents you from doing
> 
> #include "../../arch/x86/include/asm/intel-family.h"
> 
> ?
> 
> In the end, to the compiler, it's just a file in a weird location in the
> tree.  I think I'd prefer one weird include to moving that file out of
> arch/x86.

Using relative includes in include/linux is uncommon (I can see just one usage
in libfdt.h pulling stuff from scripts), so I thought I can't use it in this way
(seems slightly hacky to pull stuff from outside include path).

But if that would be ok, it looks like a good alternative to avoid duplication
in this case.

Thanks
-Iwona

  reply	other threads:[~2021-10-11 20:54 UTC|newest]

Thread overview: 147+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03 11:31 [PATCH v2 00/15] Introduce PECI subsystem Iwona Winiarska
2021-08-03 11:31 ` Iwona Winiarska
2021-08-03 11:31 ` Iwona Winiarska
2021-08-03 11:31 ` [PATCH v2 01/15] x86/cpu: Move intel-family to arch-independent headers Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-10-04 19:03   ` Borislav Petkov
2021-10-04 19:03     ` Borislav Petkov
2021-10-04 19:03     ` Borislav Petkov
2021-10-11 19:21     ` Winiarska, Iwona
2021-10-11 19:21       ` Winiarska, Iwona
2021-10-11 19:21       ` Winiarska, Iwona
2021-10-11 19:40       ` Dave Hansen
2021-10-11 19:40         ` Dave Hansen
2021-10-11 19:40         ` Dave Hansen
2021-10-11 20:53         ` Winiarska, Iwona [this message]
2021-10-11 20:53           ` Winiarska, Iwona
2021-10-11 20:53           ` Winiarska, Iwona
2021-10-11 23:12           ` Dave Hansen
2021-10-11 23:12             ` Dave Hansen
2021-10-11 23:12             ` Dave Hansen
2021-10-11 20:06       ` Borislav Petkov
2021-10-11 20:06         ` Borislav Petkov
2021-10-11 20:06         ` Borislav Petkov
2021-10-11 20:38         ` Winiarska, Iwona
2021-10-11 20:38           ` Winiarska, Iwona
2021-10-11 20:38           ` Winiarska, Iwona
2021-10-11 21:31           ` Borislav Petkov
2021-10-11 21:31             ` Borislav Petkov
2021-10-11 21:31             ` Borislav Petkov
2021-10-12 23:15             ` Winiarska, Iwona
2021-10-12 23:15               ` Winiarska, Iwona
2021-10-12 23:15               ` Winiarska, Iwona
2021-10-13  6:42               ` Borislav Petkov
2021-10-13  6:42                 ` Borislav Petkov
2021-10-13  6:42                 ` Borislav Petkov
2021-08-03 11:31 ` [PATCH v2 02/15] x86/cpu: Extract cpuid helpers to arch-independent Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-10-04 19:08   ` Borislav Petkov
2021-10-04 19:08     ` Borislav Petkov
2021-10-04 19:08     ` Borislav Petkov
2021-10-11 19:32     ` Winiarska, Iwona
2021-10-11 19:32       ` Winiarska, Iwona
2021-10-11 19:32       ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 03/15] dt-bindings: Add generic bindings for PECI Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-11 18:11   ` Rob Herring
2021-08-11 18:11     ` Rob Herring
2021-08-11 18:11     ` Rob Herring
2021-08-03 11:31 ` [PATCH v2 04/15] dt-bindings: Add bindings for peci-aspeed Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-11 18:11   ` Rob Herring
2021-08-11 18:11     ` Rob Herring
2021-08-11 18:11     ` Rob Herring
2021-08-03 11:31 ` [PATCH v2 05/15] ARM: dts: aspeed: Add PECI controller nodes Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31 ` [PATCH v2 06/15] peci: Add core infrastructure Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-25 22:58   ` Dan Williams
2021-08-25 22:58     ` Dan Williams
2021-08-25 22:58     ` Dan Williams
2021-08-26 22:40     ` Winiarska, Iwona
2021-08-26 22:40       ` Winiarska, Iwona
2021-08-26 22:40       ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 07/15] peci: Add peci-aspeed controller driver Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-26  1:35   ` Dan Williams
2021-08-26  1:35     ` Dan Williams
2021-08-26  1:35     ` Dan Williams
2021-08-26 23:54     ` Winiarska, Iwona
2021-08-26 23:54       ` Winiarska, Iwona
2021-08-26 23:54       ` Winiarska, Iwona
2021-08-27 16:24       ` Dan Williams
2021-08-27 16:24         ` Dan Williams
2021-08-27 16:24         ` Dan Williams
2021-08-29 19:42         ` Winiarska, Iwona
2021-08-29 19:42           ` Winiarska, Iwona
2021-08-29 19:42           ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 08/15] peci: Add device detection Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-27 19:01   ` Dan Williams
2021-08-27 19:01     ` Dan Williams
2021-08-27 19:01     ` Dan Williams
2021-11-15 22:18     ` Winiarska, Iwona
2021-11-15 22:18       ` Winiarska, Iwona
2021-11-15 22:18       ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 09/15] peci: Add sysfs interface for PECI bus Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-27 19:11   ` Dan Williams
2021-08-27 19:11     ` Dan Williams
2021-08-27 19:11     ` Dan Williams
2021-11-15 22:19     ` Winiarska, Iwona
2021-11-15 22:19       ` Winiarska, Iwona
2021-11-15 22:19       ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 10/15] peci: Add support for PECI device drivers Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-27 21:19   ` Dan Williams
2021-08-27 21:19     ` Dan Williams
2021-08-27 21:19     ` Dan Williams
2021-11-15 22:20     ` Winiarska, Iwona
2021-11-15 22:20       ` Winiarska, Iwona
2021-11-15 22:20       ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 11/15] peci: Add peci-cpu driver Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31 ` [PATCH v2 12/15] hwmon: peci: Add cputemp driver Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 15:24   ` Guenter Roeck
2021-08-03 15:24     ` Guenter Roeck
2021-08-03 15:24     ` Guenter Roeck
2021-08-04 10:43     ` Winiarska, Iwona
2021-08-04 10:43       ` Winiarska, Iwona
2021-08-04 10:43       ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 13/15] hwmon: peci: Add dimmtemp driver Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 15:39   ` Guenter Roeck
2021-08-03 15:39     ` Guenter Roeck
2021-08-03 15:39     ` Guenter Roeck
2021-08-04 10:46     ` Winiarska, Iwona
2021-08-04 10:46       ` Winiarska, Iwona
2021-08-04 10:46       ` Winiarska, Iwona
2021-08-04 17:33       ` Guenter Roeck
2021-08-04 17:33         ` Guenter Roeck
2021-08-04 17:33         ` Guenter Roeck
2021-08-05 21:48         ` Winiarska, Iwona
2021-08-05 21:48           ` Winiarska, Iwona
2021-08-05 21:48           ` Winiarska, Iwona
2021-08-03 11:31 ` [PATCH v2 14/15] docs: hwmon: Document PECI drivers Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31 ` [PATCH v2 15/15] docs: Add PECI documentation Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-03 11:31   ` Iwona Winiarska
2021-08-05 12:17 ` [PATCH v2 00/15] Introduce PECI subsystem Greg Kroah-Hartman
2021-08-05 12:17   ` Greg Kroah-Hartman
2021-08-05 12:17   ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43e367e452c6c8d9c6a275299d7ff6f2bb26b8e3.camel@intel.com \
    --to=iwona.winiarska@intel.com \
    --cc=andrew@aj.id.au \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=d.mueller@elsoft.ch \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jae.hyun.yoo@linux.intel.com \
    --cc=jdelvare@suse.com \
    --cc=joel@jms.id.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luto@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mingo@redhat.com \
    --cc=olof@lixom.net \
    --cc=openbmc@lists.ozlabs.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.com \
    --cc=zweiss@equinix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.