platform/x86: intel: Add 'intel' prefix to the modules automatically

Rework Makefile to add 'intel' prefix to the modules automatically.
This removes a lot of boilerplate code in it and also makes r

platform/x86: intel: Add 'intel' prefix to the modules automatically

Rework Makefile to add 'intel' prefix to the modules automatically.
This removes a lot of boilerplate code in it and also makes robust
against mistypos in the prefix.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

platform/x86/intel/tpmi: Add new auxiliary driver for performance limits

Add new auxiliary driver that exposes the SoC performance limit reasons
via debugfs interface.

Reviewed-by: Andy Shevchenko

platform/x86/intel/tpmi: Add new auxiliary driver for performance limits

Add new auxiliary driver that exposes the SoC performance limit reasons
via debugfs interface.

Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Tero Kristo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

platform/x86/intel: TPMI domain id and CPU mapping

Each TPMI power domain includes a group of CPUs. Several power
management settings in this case applicable to a group of CPUs.
There can be several

platform/x86/intel: TPMI domain id and CPU mapping

Each TPMI power domain includes a group of CPUs. Several power
management settings in this case applicable to a group of CPUs.
There can be several power domains in a CPU package. So, provide
interfaces for:
- Get power domain id for a Linux CPU
- Get mask of Linux CPUs in a power domain

Hardware Punit uses different CPU numbering, which is not based on
APIC (Advanced Programmable Interrupt Controller) CPU numbering.
The Linux CPU numbering is based on APIC CPU numbering. Some PM features
like Intel Speed Select, the CPU core mask provided by the hardware is
based on the Punit CPU numbering. To use the core mask, this mask
needs to be converted to a Linux CPUs mask. So, provide interfaces for:
- Convert to a Linux CPU number from a Punit CPU number
- Convert to a Punit CPU number from a Linux CPU number

On each CPU online, MSR 0x54 is used to read the mapping and stores in
a per cpu array. Create a hash for faster searching of a Linux CPU number
from a Punit CPU number.

Signed-off-by: Srinivas Pandruvada <[email protected]>
[tero.kristo: minor updates]
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Tero Kristo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ilpo Järvinen <[email protected]>

show more ...

platform/x86: Add intel_bytcrc_pwrsrc driver

Add a new driver for the power-, wake- and reset-source functionality
of the Bay Trail (BYT) version of the Crystal Cove PMIC.

The main functionality he

platform/x86: Add intel_bytcrc_pwrsrc driver

Add a new driver for the power-, wake- and reset-source functionality
of the Bay Trail (BYT) version of the Crystal Cove PMIC.

The main functionality here is detecting which power-sources (USB /
DC in / battery) are active. This is normally exposed to userspace as
a power_supply class charger device with an online sysfs attribute.

But if a charger is online or not is already exposed on BYT-CRC devices
through either an ACPI AC power_supply device, or through a native driver
for the battery charger chip (e.g. a BQ24292i).

So instead of adding duplicate info under the power_supply class this
driver exports the info through debugfs and likewise adds debugfs files
for the reset- and wake-source info / registers.

Despite this driver only exporting debugfs bits it is still useful to
have this driver because it clears the wake- and reset-source registers
after reading them. Not clearing these can have undesirable side-effects.

Specifically if the WAKESRC register contains 0x01 (wake by powerbutton)
on reboot then the firmware on some tablets turns the reboot into
a poweroff. I guess this may be necessary to make long power-presses turn
into a poweroff somehow?

Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86/intel: Intel TPMI enumeration driver

The TPMI (Topology Aware Register and PM Capsule Interface) provides a
flexible, extendable and PCIe enumerable MMIO interface for PM features.

For

platform/x86/intel: Intel TPMI enumeration driver

The TPMI (Topology Aware Register and PM Capsule Interface) provides a
flexible, extendable and PCIe enumerable MMIO interface for PM features.

For example Intel RAPL (Running Average Power Limit) provides a MMIO
interface using TPMI. This has advantage over traditional MSR
(Model Specific Register) interface, where a thread needs to be scheduled
on the target CPU to read or write. Also the RAPL features vary between
CPU models, and hence lot of model specific code. Here TPMI provides an
architectural interface by providing hierarchical tables and fields,
which will not need any model specific implementation.

The TPMI interface uses a PCI VSEC structure to expose the location of
MMIO region.

This VSEC structure is present in the PCI configuration space of the
Intel Out-of-Band (OOB) device, which is handled by the Intel VSEC
driver. The Intel VSEC driver parses VSEC structures present in the PCI
configuration space of the given device and creates an auxiliary device
object for each of them. In particular, it creates an auxiliary device
object representing TPMI that can be bound by an auxiliary driver.

Introduce a TPMI driver that will bind to the TPMI auxiliary device
object created by the Intel VSEC driver.

The TPMI specification defines a PFS (PM Feature Structure) table.
This table is present in the TPMI MMIO region. The starting address
of PFS is derived from the tBIR (Bar Indicator Register) and "Address"
field from the VSEC header.

Each TPMI PM feature has one entry in the PFS with a unique TPMI
ID and its access details. The TPMI driver creates device nodes
for the supported PM features.

The names of the devices created by the TPMI driver start with the
"intel_vsec.tpmi-" prefix which is followed by a specific name of the
given PM feature (for example, "intel_vsec.tpmi-rapl.0").

The device nodes are create by using interface "intel_vsec_add_aux()"
provided by the Intel VSEC driver.

Signed-off-by: Srinivas Pandruvada <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: p2sb: Move out of X86_PLATFORM_DEVICES dependency

The P2SB library is used for various drivers, including server
platforms. That's why the dependency on X86_PLATFORM_DEVICES
seems supe

platform/x86: p2sb: Move out of X86_PLATFORM_DEVICES dependency

The P2SB library is used for various drivers, including server
platforms. That's why the dependency on X86_PLATFORM_DEVICES
seems superfluous.

Reported-by: kernel test robot <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86/intel: Add Primary to Sideband (P2SB) bridge support

SoC features such as GPIO are accessed via a reserved MMIO area,
we don't know its address but can obtain it from the BAR of
the P2S

platform/x86/intel: Add Primary to Sideband (P2SB) bridge support

SoC features such as GPIO are accessed via a reserved MMIO area,
we don't know its address but can obtain it from the BAR of
the P2SB device, that device is normally hidden so we have to
temporarily unhide it, read address and hide it back.

There are already a few users and at least one more is coming which
require an access to Primary to Sideband (P2SB) bridge in order
to get IO or MMIO BAR hidden by BIOS.

Create a library to access P2SB for x86 devices in a unified way.

Background information
======================
Note, the term "bridge" is used in the documentation and it has nothing
to do with a PCI (host) bridge as per the PCI specifications.

The P2SB is an interesting device by its nature and hardware design.
First of all, it has several devices in the hardware behind it. These
devices may or may not be represented as ACPI devices by a firmware.

It also has a hardwired (to 0s) the least significant bits of the
base address register which is represented by the only 64-bit BAR0.
It means that OS mustn't reallocate the BAR.

On top of that in some cases P2SB is represented by function 0 on PCI
slot (in terms of B:D.F) and according to the PCI specification any
other function can't be seen until function 0 is present and visible.

In the PCI configuration space of P2SB device the full 32-bit register
is allocated for the only purpose of hiding the entire P2SB device. As
per [3]:

3.1.39 P2SB Control (P2SBC)—Offset E0h

Hide Device (HIDE): When this bit is set, the P2SB will return 1s on
any PCI Configuration Read on IOSF-P. All other transactions including
PCI Configuration Writes on IOSF-P are unaffected by this. This does
not affect reads performed on the IOSF-SB interface.

This doesn't prevent MMIO accesses, although preventing the OS from
assigning these addresses. The firmware on the affected platforms marks
the region as unusable (by cutting it off from the PCI host bridge
resources) as depicted in the Apollo Lake example below:

PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0070-0x0077]
pci_bus 0000:00: root bus resource [io 0x0000-0x006f window]
pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x7c000001-0x7fffffff window]
pci_bus 0000:00: root bus resource [mem 0x7b800001-0x7bffffff window]
pci_bus 0000:00: root bus resource [mem 0x80000000-0xcfffffff window]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff window]
pci_bus 0000:00: root bus resource [bus 00-ff]

The P2SB 16MB BAR is located at 0xd0000000-0xd0ffffff memory window.

The generic solution
====================
The generic solution for all cases when we need to access to the information
behind P2SB device is a library code where users ask for necessary resources
by demand and hence those users take care of not being run on the systems
where this access is not required.

The library provides the p2sb_bar() API to retrieve the MMIO of the BAR0 of
the device from P2SB device slot.

P2SB unconditional unhiding awareness
=====================================
Technically it's possible to unhide the P2SB device and devices on
the same PCI slot and access them at any time as needed. But there are
several potential issues with that:

- the systems were never tested against such configuration and hence
nobody knows what kind of bugs it may bring, especially when we talk
about SPI NOR case which contains Intel FirmWare Image (IFWI) code
(including BIOS) and already known to be problematic in the past for
end users

- the PCI by its nature is a hotpluggable bus and in case somebody
attaches a driver to the functions of a P2SB slot device(s) the
end user experience and system behaviour can be unpredictable

- the kernel code would need some ugly hacks (or code looking as an
ugly hack) under arch/x86/pci in order to enable these devices on
only selected platforms (which may include CPU ID table followed by
a potentially growing number of DMI strings

The future improvements
=======================
The future improvements with this code may go in order to gain some kind
of cache, if it's possible at all, to prevent unhiding and hiding many
times to take static information that may be saved once per boot.

Links
=====
[1]: https://lab.whitequark.org/notes/2017-11-08/accessing-intel-ich-pch-gpios/
[2]: https://cdrdv2.intel.com/v1/dl/getContent/332690?wapkw=332690
[3]: https://cdrdv2.intel.com/v1/dl/getContent/332691?wapkw=332691
[4]: https://medium.com/@jacksonchen_43335/bios-gpio-p2sb-70e9b829b403

Signed-off-by: Jonathan Yong <[email protected]>
Co-developed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Tested-by: Henning Schild <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Lee Jones <[email protected]>

show more ...

platform/x86/intel/ifs: Add stub driver for In-Field Scan

Cloud Service Providers that operate fleets of servers have reported
[1] occasions where they can detect that a CPU has gone bad due to
effe

platform/x86/intel/ifs: Add stub driver for In-Field Scan

Cloud Service Providers that operate fleets of servers have reported
[1] occasions where they can detect that a CPU has gone bad due to
effects like electromigration, or isolated manufacturing defects.
However, that detection method is A/B testing seemingly random
application failures looking for a pattern. In-Field Scan (IFS) is
a driver for a platform capability to load a crafted 'scan image'
to run targeted low level diagnostics outside of the CPU's architectural
error detection capabilities.

Stub version of driver just does initial part of check for the IFS
feature. MSR_IA32_CORE_CAPS must enumerate the presence of the
MSR_INTEGRITY_CAPS MSR.

[1]: https://www.youtube.com/watch?v=QMF3rqhjYuM

Reviewed-by: Dan Williams <[email protected]>
Signed-off-by: Tony Luck <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86/intel/uncore-freq: Move to uncore-frequency folder

Move the current driver from platform/x86/intel/uncore-frequency.c
to platform/x86/intel/uncore-frequency/uncore-frequency.c.

No func

platform/x86/intel/uncore-freq: Move to uncore-frequency folder

Move the current driver from platform/x86/intel/uncore-frequency.c
to platform/x86/intel/uncore-frequency/uncore-frequency.c.

No functional changes are expected.

Signed-off-by: Srinivas Pandruvada <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: Add Intel Software Defined Silicon driver

Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for
activating additional silicon features. Features are enabled throu

platform/x86: Add Intel Software Defined Silicon driver

Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for
activating additional silicon features. Features are enabled through a
license activation process. The SDSi driver provides a per socket, sysfs
attribute interface for applications to perform 3 main provisioning
functions:

1. Provision an Authentication Key Certificate (AKC), a key written to
internal NVRAM that is used to authenticate a capability specific
activation payload.

2. Provision a Capability Activation Payload (CAP), a token authenticated
using the AKC and applied to the CPU configuration to activate a new
feature.

3. Read the SDSi State Certificate, containing the CPU configuration
state.

The operations perform function specific mailbox commands that forward the
requests to SDSi hardware to perform authentication of the payloads and
enable the silicon configuration (to be made available after power
cycling).

The SDSi device itself is enumerated as an auxiliary device from the
intel_vsec driver and as such has a build dependency on CONFIG_INTEL_VSEC.

Link: https://github.com/intel/intel-sdsi
Signed-off-by: David E. Box <[email protected]>
Reviewed-by: Mark Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel_cht_int33fe: Move to intel directory

Now that there is only 1 c-file left of the intel_cht_int33fe code,
move it to the intel directory instead of it having its own int33fe
sub-d

platform/x86: intel_cht_int33fe: Move to intel directory

Now that there is only 1 c-file left of the intel_cht_int33fe code,
move it to the intel directory instead of it having its own int33fe
sub-directory.

Note this also renames the module from intel_cht_int33fe_typec to
intel_chtwc_int33fe, to better match the names of other PMIC related
modules like the intel_chtdc_ti_pwrbtn module.

Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86: Add intel_crystal_cove_charger driver

Driver for the external-charger IRQ pass-through function of the
Intel Bay Trail Crystal Cove PMIC.

Note this is NOT a power_supply class driver,

platform/x86: Add intel_crystal_cove_charger driver

Driver for the external-charger IRQ pass-through function of the
Intel Bay Trail Crystal Cove PMIC.

Note this is NOT a power_supply class driver, it just deals with IRQ
pass-through, this requires this separate driver because the PMIC's
level 2 interrupt for this must be explicitly acked.

This new driver gets enabled by the existing X86_ANDROID_TABLETS Kconfig
option because the x86-android-tablets module is the only consumer of the
exported external-charger IRQ.

Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

platform/x86/intel: Move intel_pmt from MFD to Auxiliary Bus

Intel Platform Monitoring Technology (PMT) support is indicated by presence
of an Intel defined PCIe Designated Vendor Specific Extended

platform/x86/intel: Move intel_pmt from MFD to Auxiliary Bus

Intel Platform Monitoring Technology (PMT) support is indicated by presence
of an Intel defined PCIe Designated Vendor Specific Extended Capabilities
(DVSEC) structure with a PMT specific ID. The current MFD implementation
creates child devices for each PMT feature, currently telemetry, watcher,
and crashlog. However DVSEC structures may also be used by Intel to
indicate support for other features. The Out Of Band Management Services
Module (OOBMSM) uses DVSEC to enumerate several features, including PMT.
In order to support them it is necessary to modify the intel_pmt driver to
handle the creation of the child devices more generically. To that end,
modify the driver to create child devices for any VSEC/DVSEC features on
supported devices (indicated by PCI ID). Additionally, move the
implementation from MFD to the Auxiliary bus. VSEC/DVSEC features are
really multifunctional PCI devices, not platform devices as MFD was
designed for. Auxiliary bus gives more flexibility by allowing the
definition of custom structures that can be shared between associated
auxiliary devices and the parent device. Also, rename the driver from
intel_pmt to intel_vsec to better reflect the purpose.

This series also removes the current runtime pm support which was not
complete to begin with. None of the current devices require runtime pm.
However the support will be replaced when a device is added that requires
it.

Reviewed-by: Mark Gross <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Signed-off-by: David E. Box <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

platform/x86: Add Intel ishtp eclite driver

This driver is for accessing the PSE (Programmable Service Engine) - an
Embedded Controller like IP - using ISHTP (Integratd Sensor Hub Transport
Protocol

platform/x86: Add Intel ishtp eclite driver

This driver is for accessing the PSE (Programmable Service Engine) - an
Embedded Controller like IP - using ISHTP (Integratd Sensor Hub Transport
Protocol) to get battery, thermal and UCSI (USB Type-C Connector System
Software Interface) related data from the platform.

Signed-off-by: K Naduvalath, Sumesh <[email protected]>
Reviewed-by: Mark Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel-wmi-sbl-fw-update: Move to intel sub-directory

Move Intel WMI Slim Bootloader FW update driver to intel sub-directory
to improve readability.

Signed-off-by: Kate Hsuan <hpa@redh

platform/x86: intel-wmi-sbl-fw-update: Move to intel sub-directory

Move Intel WMI Slim Bootloader FW update driver to intel sub-directory
to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel-vbtn: Move to intel sub-directory

Move Intel vButton driver to intel sub-directory to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede

platform/x86: intel-vbtn: Move to intel sub-directory

Move Intel vButton driver to intel sub-directory to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel_oaktrail: Move to intel sub-directory

Move Intel Oaktrail driver to intel sub-directory to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de G

platform/x86: intel_oaktrail: Move to intel sub-directory

Move Intel Oaktrail driver to intel sub-directory to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel_int0002_vgpio: Move to intel sub-directory

Move Intel vGPIO (INT0002) driver to intel sub-directory
to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-b

platform/x86: intel_int0002_vgpio: Move to intel sub-directory

Move Intel vGPIO (INT0002) driver to intel sub-directory
to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel-hid: Move to intel sub-directory

Move Intel HID driver to intel sub-directory to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <hdeg

platform/x86: intel-hid: Move to intel sub-directory

Move Intel HID driver to intel sub-directory to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel_atomisp2: Move to intel sub-directory

Move Intel AtomISP v2 drivers to intel sub-directory
to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans d

platform/x86: intel_atomisp2: Move to intel sub-directory

Move Intel AtomISP v2 drivers to intel sub-directory
to improve readability.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel_speed_select_if: Move to intel sub-directory

Move Intel Speed Select interface driver to intel sub-directory to improve
readability and rename it from intel_speed_select_if to sp

platform/x86: intel_speed_select_if: Move to intel sub-directory

Move Intel Speed Select interface driver to intel sub-directory to improve
readability and rename it from intel_speed_select_if to speed_select_if.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel-uncore-frequency: Move to intel sub-directory

Move Intel Uncore frequency driver to intel sub-directory to improve
readability and rename it from intel-uncore-frequency.c to
unco

platform/x86: intel-uncore-frequency: Move to intel sub-directory

Move Intel Uncore frequency driver to intel sub-directory to improve
readability and rename it from intel-uncore-frequency.c to
uncore-frequency.c.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel_turbo_max_3: Move to intel sub-directory

Move Intel Turbo Max 3 driver to intel sub-directory to improve readability
and rename it from intel_turbo_max_3.c to turbo_max_3.c.

Sig

platform/x86: intel_turbo_max_3: Move to intel sub-directory

Move Intel Turbo Max 3 driver to intel sub-directory to improve readability
and rename it from intel_turbo_max_3.c to turbo_max_3.c.

Signed-off-by: Kate Hsuan <[email protected]>
Acked-by: Srinivas Pandruvada <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel-smartconnect: Move to intel sub-directory

Move Intel Smart Connect driver to intel sub-directory to improve
readability and rename it from intel-smartconnect.c to smartconnect.c.

platform/x86: intel-smartconnect: Move to intel sub-directory

Move Intel Smart Connect driver to intel sub-directory to improve
readability and rename it from intel-smartconnect.c to smartconnect.c.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...

platform/x86: intel-rst: Move to intel sub-directory

Move Intel RST driver to intel sub-directory to improve readability
and rename it from intel-rst.c to rst.c.

Signed-off-by: Kate Hsuan <hpa@redh

platform/x86: intel-rst: Move to intel sub-directory

Move Intel RST driver to intel sub-directory to improve readability
and rename it from intel-rst.c to rst.c.

Signed-off-by: Kate Hsuan <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>

show more ...