[rafael-pm:bleeding-edge] BUILD SUCCESS 3577b2bc2275c245e5632e50b1acf84a1cf4e01a
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 3577b2bc2275c245e5632e50b1acf84a1cf4e01a Merge branch 'thermal-docs' into bleeding-edge
elapsed time: 1516m
configs tested: 104
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc mpc866_ads_defconfig
mips omega2p_defconfig
sh apsh4ad0a_defconfig
arm oxnas_v6_defconfig
arm collie_defconfig
s390 zfcpdump_defconfig
m68k m5475evb_defconfig
sparc alldefconfig
sparc sparc64_defconfig
sh sh7757lcr_defconfig
h8300 h8s-sim_defconfig
sh rsk7264_defconfig
powerpc holly_defconfig
sh migor_defconfig
sh ecovec24_defconfig
arm davinci_all_defconfig
sh polaris_defconfig
xtensa iss_defconfig
arm multi_v4t_defconfig
powerpc ksi8560_defconfig
mips bcm63xx_defconfig
x86_64 randconfig-c001-20211003
i386 randconfig-c001-20211003
arm randconfig-c002-20211003
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a015-20211004
x86_64 randconfig-a012-20211004
x86_64 randconfig-a016-20211004
x86_64 randconfig-a014-20211004
x86_64 randconfig-a013-20211004
x86_64 randconfig-a011-20211004
i386 randconfig-a013-20211004
i386 randconfig-a016-20211004
i386 randconfig-a014-20211004
i386 randconfig-a011-20211004
i386 randconfig-a012-20211004
i386 randconfig-a015-20211004
arc randconfig-r043-20211007
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
i386 randconfig-a001-20211004
i386 randconfig-a003-20211004
i386 randconfig-a005-20211004
i386 randconfig-a002-20211004
i386 randconfig-a004-20211004
i386 randconfig-a006-20211004
x86_64 randconfig-a003-20211004
x86_64 randconfig-a005-20211004
x86_64 randconfig-a001-20211004
x86_64 randconfig-a002-20211004
x86_64 randconfig-a004-20211004
x86_64 randconfig-a006-20211004
hexagon randconfig-r045-20211007
hexagon randconfig-r041-20211007
s390 randconfig-r044-20211007
riscv randconfig-r042-20211007
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
10 months
Re: [PATCH] PCI: Put power resources not tied to a physical node in D3cold
by Rafael J. Wysocki
On Friday, October 8, 2021 5:47:53 PM CEST Limonciello, Mario wrote:
> On 10/8/2021 09:05, Rafael J. Wysocki wrote:
> > On Thursday, October 7, 2021 10:51:26 PM CEST Mario Limonciello wrote:
> >> I found a case that a system that two physical SATA controllers share
> >> the same ACPI Power Resource. When a drive is connected to one of
> >> the controllers then it will bind with PCI devices with the ahci driver
> >> and form a relationship with the firmware node and physical node. During
> >> s2idle I see that the constraints are met for this device as it is
> >> transitioned into the appropriate state. However the second ACPI node
> >> doesn't have any relationship with a physical node and stays in "D0":
> >>
> >> ```
> >> ACPI: \_SB_.PCI0.GP18.SATA: ACPI: PM: Power state change: D0 -> D3cold
> >> ACPI: PM: Power resource [P0SA] still in use
> >> acpi device:2a: Power state changed to D3cold
> >> ```
> >>
> >> Due to the refcounting used on the shared power resource putting the
> >> device with a physical node into D3 doesn't result in the _OFF method
> >> being called.
> >>
> >> To help with this type of problem, make a new helper function that can
> >> be used to check all the children of an ACPI device and put any firmware
> >> nodes that don't have physical devices into D3cold to allow shared
> >> resources to transition. Call this helper function after PCI devices have
> >> been scanned and ACPI companions have had a chance to associate.
> >>
> >> After making this change, here is what the flow looks like:
> >> ```
> >> <snip:bootup>
> >> ACPI: \_SB_.PCI0.GP18.SAT1: ACPI: PM: Power state change: D0 -> D3cold
> >> ACPI: PM: Power resource [P0SA] still in use
> >> acpi device:2c: Power state changed to D3cold
> >> <snip:suspend>
> >> ACPI: \_SB_.PCI0.GP18.SATA: ACPI: PM: Power state change: D0 -> D3cold
> >> ACPI: PM: Power resource [P0SA] turned off
> >> acpi device:2a: Power state changed to D3cold
> >> ```
> >>
> >> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke...
> >> BugLink: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzill...
> >> Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
> >> ---
> >> drivers/acpi/device_pm.c | 34 ++++++++++++++++++++++++++++++++++
> >> drivers/pci/probe.c | 5 +++++
> >> include/acpi/acpi_bus.h | 1 +
> >> 3 files changed, 40 insertions(+)
> >>
> >> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
> >> index 0028b6b51c87..0fb0bbeeae9e 100644
> >> --- a/drivers/acpi/device_pm.c
> >> +++ b/drivers/acpi/device_pm.c
> >> @@ -149,6 +149,40 @@ static int acpi_dev_pm_explicit_set(struct acpi_device *adev, int state)
> >> return 0;
> >> }
> >>
> >> +/**
> >> + * acpi_device_turn_off_absent_children - Turn off power resources for
> >> + * children not physically present.
> >> + * @parent: ACPI bridge device
> >> + */
> >> +int acpi_device_turn_off_absent_children(struct acpi_device *parent)
> >> +{
> >> + struct acpi_device *adev;
> >> + int ret = 0;
> >> +
> >> + if (!parent)
> >> + return -EINVAL;
> >> +
> >> + list_for_each_entry(adev, &parent->children, node) {
> >
> > It is better to use device_for_each_child() for this, walking the children list
> > without locking is questionable.
> >
> >> + int state;
> >> +
> >> + if (!adev->flags.power_manageable ||
> >
> > This need not be checked, acpi_device_set_power() checks it.
> >
> >> + !adev->power.flags.power_resources)
> >
> > And I'm not sure about this too. Even if there are no power resources, it
> > would be still prudent to release PM resources referred to by unused device
> > objects by calling _PS3 on them.
> >
> >> + continue;
> >> + if (acpi_get_first_physical_node(adev))
> >> + continue;
> >
> > In addition to this, I would check if the device object has _ADR, because
> > there are legitimate cases when device objects with a _HID have no physical
> > nodes.
> >
> >> + ret = acpi_device_get_power(adev, &state);
> >> + if (ret)
> >> + return ret;
> >> + if (state == ACPI_STATE_D3_COLD)
> >> + continue;
> >
> > The above is not necessary.
> >
> >> + ret = acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
> >> + if (ret)
> >> + return ret;
> >> + }
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_device_turn_off_absent_children);
> >
> > And I would put this function into glue.c.
> >
> >> +
> >> /**
> >> * acpi_device_set_power - Set power state of an ACPI device.
> >> * @device: Device to set the power state of.
> >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> >> index 79177ac37880..1a45182394d1 100644
> >> --- a/drivers/pci/probe.c
> >> +++ b/drivers/pci/probe.c
> >> @@ -2939,6 +2939,11 @@ static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
> >> }
> >> }
> >>
> >> + /* check for and turn off dangling power resources */
> >> + for_each_pci_bridge(dev, bus) {
> >> + acpi_device_turn_off_absent_children(ACPI_COMPANION(&dev->dev));
> >
> > IMO it would be better to call this from inside of the ACPI subsystem and
> > after scanning the entire bus.
> >
> >> + }
> >> +
> >> /*
> >> * We've scanned the bus and so we know all about what's on
> >> * the other side of any bridges that may be on this bus plus
> >> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> >> index 13d93371790e..0eba08b60e13 100644
> >> --- a/include/acpi/acpi_bus.h
> >> +++ b/include/acpi/acpi_bus.h
> >> @@ -510,6 +510,7 @@ int acpi_bus_get_status(struct acpi_device *device);
> >>
> >> int acpi_bus_set_power(acpi_handle handle, int state);
> >> const char *acpi_power_state_string(int state);
> >> +int acpi_device_turn_off_absent_children(struct acpi_device *parent);
> >> int acpi_device_set_power(struct acpi_device *device, int state);
> >> int acpi_bus_init_power(struct acpi_device *device);
> >> int acpi_device_fix_up_power(struct acpi_device *device);
> >>
> >
> > Overall, something like the appended patch might work. >
> > Note that on my test-bed machine it makes no difference, though.
>
> Yes this helps the resources on the identified problematic machine.
>
> >
> > ---
> > drivers/acpi/glue.c | 28 ++++++++++++++++++++++++++++
> > drivers/acpi/internal.h | 2 ++
> > drivers/acpi/pci_root.c | 1 +
> > 3 files changed, 31 insertions(+)
> >
> > Index: linux-pm/drivers/acpi/glue.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/glue.c
> > +++ linux-pm/drivers/acpi/glue.c
> > @@ -350,3 +350,31 @@ void acpi_device_notify_remove(struct de
> >
> > acpi_unbind_one(dev);
> > }
> > +
> > +static int acpi_dev_turn_off_if_unused(struct device *dev, void *not_used)
> > +{
> > + struct acpi_device *adev = to_acpi_device(dev);
> > +
> > + acpi_dev_turn_off_unused_descendants(adev);
> > +
> > + if (adev->pnp.type.bus_address && !acpi_get_first_physical_node(adev))
> > + acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * acpi_dev_turn_off_unused_descendants - Put unused descendants into D3cold.
> > + * @adev: ACPI device object at the top of a branch of device hierarchy.
> > + *
> > + * Walk the branch of the hierarchy of ACPI device objects starting at @adev
> > + * and put all of the objects in it that have _ADR and have no corresponding
> > + * physical nodes into D3cold.
> > + *
> > + * This allows power resources that are only referred to by unused ACPI device
> > + * objects to be turned off.
> > + */
> > +void acpi_dev_turn_off_unused_descendants(struct acpi_device *adev)
> > +{
> > + device_for_each_child(&adev->dev, NULL, acpi_dev_turn_off_if_unused);
> > +}
> > Index: linux-pm/drivers/acpi/internal.h
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/internal.h
> > +++ linux-pm/drivers/acpi/internal.h
> > @@ -88,6 +88,8 @@ bool acpi_scan_is_offline(struct acpi_de
> > acpi_status acpi_sysfs_table_handler(u32 event, void *table, void *context);
> > void acpi_scan_table_notify(void);
> >
> > +void acpi_dev_turn_off_unused_descendants(struct acpi_device *adev);
> > +
> > /* --------------------------------------------------------------------------
> > Device Node Initialization / Removal
> > -------------------------------------------------------------------------- */
> > Index: linux-pm/drivers/acpi/pci_root.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/pci_root.c
> > +++ linux-pm/drivers/acpi/pci_root.c
> > @@ -630,6 +630,7 @@ static int acpi_pci_root_add(struct acpi
> >
> > pci_lock_rescan_remove();
> > pci_bus_add_devices(root->bus);
> > + acpi_dev_turn_off_unused_descendants(root->device);
> > pci_unlock_rescan_remove();
> > return 1;
> >
> >
> >
> >
>
> When you submit this if no other changes, please include:
>
> Tested-by: Mario Limonciello <mario.limonciello(a)amd.com>
Thanks, but we may do better in a couple of ways.
First off, there's no particular reason to restrict the walk to the device
objects below the host bridge one.
Second, if the physical node appears while we're removing power from the
device, whoever adds it may be confused, so it's better to avoid that.
Please check if the appended one still works for you.
---
drivers/acpi/glue.c | 16 ++++++++++++++++
drivers/acpi/internal.h | 1 +
drivers/acpi/scan.c | 6 ++++++
3 files changed, 23 insertions(+)
Index: linux-pm/drivers/acpi/scan.c
===================================================================
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -2559,6 +2559,12 @@ int __init acpi_scan_init(void)
}
}
+ /*
+ * Make sure that power management resources are not blocked by ACPI
+ * device objects with no users.
+ */
+ bus_for_each_dev(&acpi_bus_type, NULL, NULL, acpi_dev_turn_off_if_unused);
+
acpi_turn_off_unused_power_resources();
acpi_scan_initialized = true;
Index: linux-pm/drivers/acpi/glue.c
===================================================================
--- linux-pm.orig/drivers/acpi/glue.c
+++ linux-pm/drivers/acpi/glue.c
@@ -350,3 +350,19 @@ void acpi_device_notify_remove(struct de
acpi_unbind_one(dev);
}
+
+int acpi_dev_turn_off_if_unused(struct device *dev, void *not_used)
+{
+ struct acpi_device *adev = to_acpi_device(dev);
+
+ if (adev->pnp.type.bus_address) {
+ mutex_lock(&adev->physical_node_lock);
+
+ if (list_empty(&adev->physical_node_list))
+ acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
+
+ mutex_unlock(&adev->physical_node_lock);
+ }
+
+ return 0;
+}
Index: linux-pm/drivers/acpi/internal.h
===================================================================
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -117,6 +117,7 @@ bool acpi_device_is_battery(struct acpi_
bool acpi_device_is_first_physical_node(struct acpi_device *adev,
const struct device *dev);
int acpi_bus_register_early_device(int type);
+int acpi_dev_turn_off_if_unused(struct device *dev, void *not_used);
/* --------------------------------------------------------------------------
Device Matching and Notification
10 months
Re: [PATCH] PCI: Put power resources not tied to a physical node in D3cold
by Rafael J. Wysocki
On Thursday, October 7, 2021 10:51:26 PM CEST Mario Limonciello wrote:
> I found a case that a system that two physical SATA controllers share
> the same ACPI Power Resource. When a drive is connected to one of
> the controllers then it will bind with PCI devices with the ahci driver
> and form a relationship with the firmware node and physical node. During
> s2idle I see that the constraints are met for this device as it is
> transitioned into the appropriate state. However the second ACPI node
> doesn't have any relationship with a physical node and stays in "D0":
>
> ```
> ACPI: \_SB_.PCI0.GP18.SATA: ACPI: PM: Power state change: D0 -> D3cold
> ACPI: PM: Power resource [P0SA] still in use
> acpi device:2a: Power state changed to D3cold
> ```
>
> Due to the refcounting used on the shared power resource putting the
> device with a physical node into D3 doesn't result in the _OFF method
> being called.
>
> To help with this type of problem, make a new helper function that can
> be used to check all the children of an ACPI device and put any firmware
> nodes that don't have physical devices into D3cold to allow shared
> resources to transition. Call this helper function after PCI devices have
> been scanned and ACPI companions have had a chance to associate.
>
> After making this change, here is what the flow looks like:
> ```
> <snip:bootup>
> ACPI: \_SB_.PCI0.GP18.SAT1: ACPI: PM: Power state change: D0 -> D3cold
> ACPI: PM: Power resource [P0SA] still in use
> acpi device:2c: Power state changed to D3cold
> <snip:suspend>
> ACPI: \_SB_.PCI0.GP18.SATA: ACPI: PM: Power state change: D0 -> D3cold
> ACPI: PM: Power resource [P0SA] turned off
> acpi device:2a: Power state changed to D3cold
> ```
>
> Link: https://lore.kernel.org/linux-acpi/[email protected]
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091
> Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
> ---
> drivers/acpi/device_pm.c | 34 ++++++++++++++++++++++++++++++++++
> drivers/pci/probe.c | 5 +++++
> include/acpi/acpi_bus.h | 1 +
> 3 files changed, 40 insertions(+)
>
> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
> index 0028b6b51c87..0fb0bbeeae9e 100644
> --- a/drivers/acpi/device_pm.c
> +++ b/drivers/acpi/device_pm.c
> @@ -149,6 +149,40 @@ static int acpi_dev_pm_explicit_set(struct acpi_device *adev, int state)
> return 0;
> }
>
> +/**
> + * acpi_device_turn_off_absent_children - Turn off power resources for
> + * children not physically present.
> + * @parent: ACPI bridge device
> + */
> +int acpi_device_turn_off_absent_children(struct acpi_device *parent)
> +{
> + struct acpi_device *adev;
> + int ret = 0;
> +
> + if (!parent)
> + return -EINVAL;
> +
> + list_for_each_entry(adev, &parent->children, node) {
It is better to use device_for_each_child() for this, walking the children list
without locking is questionable.
> + int state;
> +
> + if (!adev->flags.power_manageable ||
This need not be checked, acpi_device_set_power() checks it.
> + !adev->power.flags.power_resources)
And I'm not sure about this too. Even if there are no power resources, it
would be still prudent to release PM resources referred to by unused device
objects by calling _PS3 on them.
> + continue;
> + if (acpi_get_first_physical_node(adev))
> + continue;
In addition to this, I would check if the device object has _ADR, because
there are legitimate cases when device objects with a _HID have no physical
nodes.
> + ret = acpi_device_get_power(adev, &state);
> + if (ret)
> + return ret;
> + if (state == ACPI_STATE_D3_COLD)
> + continue;
The above is not necessary.
> + ret = acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
> + if (ret)
> + return ret;
> + }
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_device_turn_off_absent_children);
And I would put this function into glue.c.
> +
> /**
> * acpi_device_set_power - Set power state of an ACPI device.
> * @device: Device to set the power state of.
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 79177ac37880..1a45182394d1 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2939,6 +2939,11 @@ static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
> }
> }
>
> + /* check for and turn off dangling power resources */
> + for_each_pci_bridge(dev, bus) {
> + acpi_device_turn_off_absent_children(ACPI_COMPANION(&dev->dev));
IMO it would be better to call this from inside of the ACPI subsystem and
after scanning the entire bus.
> + }
> +
> /*
> * We've scanned the bus and so we know all about what's on
> * the other side of any bridges that may be on this bus plus
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 13d93371790e..0eba08b60e13 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -510,6 +510,7 @@ int acpi_bus_get_status(struct acpi_device *device);
>
> int acpi_bus_set_power(acpi_handle handle, int state);
> const char *acpi_power_state_string(int state);
> +int acpi_device_turn_off_absent_children(struct acpi_device *parent);
> int acpi_device_set_power(struct acpi_device *device, int state);
> int acpi_bus_init_power(struct acpi_device *device);
> int acpi_device_fix_up_power(struct acpi_device *device);
>
Overall, something like the appended patch might work.
Note that on my test-bed machine it makes no difference, though.
---
drivers/acpi/glue.c | 28 ++++++++++++++++++++++++++++
drivers/acpi/internal.h | 2 ++
drivers/acpi/pci_root.c | 1 +
3 files changed, 31 insertions(+)
Index: linux-pm/drivers/acpi/glue.c
===================================================================
--- linux-pm.orig/drivers/acpi/glue.c
+++ linux-pm/drivers/acpi/glue.c
@@ -350,3 +350,31 @@ void acpi_device_notify_remove(struct de
acpi_unbind_one(dev);
}
+
+static int acpi_dev_turn_off_if_unused(struct device *dev, void *not_used)
+{
+ struct acpi_device *adev = to_acpi_device(dev);
+
+ acpi_dev_turn_off_unused_descendants(adev);
+
+ if (adev->pnp.type.bus_address && !acpi_get_first_physical_node(adev))
+ acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
+
+ return 0;
+}
+
+/**
+ * acpi_dev_turn_off_unused_descendants - Put unused descendants into D3cold.
+ * @adev: ACPI device object at the top of a branch of device hierarchy.
+ *
+ * Walk the branch of the hierarchy of ACPI device objects starting at @adev
+ * and put all of the objects in it that have _ADR and have no corresponding
+ * physical nodes into D3cold.
+ *
+ * This allows power resources that are only referred to by unused ACPI device
+ * objects to be turned off.
+ */
+void acpi_dev_turn_off_unused_descendants(struct acpi_device *adev)
+{
+ device_for_each_child(&adev->dev, NULL, acpi_dev_turn_off_if_unused);
+}
Index: linux-pm/drivers/acpi/internal.h
===================================================================
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -88,6 +88,8 @@ bool acpi_scan_is_offline(struct acpi_de
acpi_status acpi_sysfs_table_handler(u32 event, void *table, void *context);
void acpi_scan_table_notify(void);
+void acpi_dev_turn_off_unused_descendants(struct acpi_device *adev);
+
/* --------------------------------------------------------------------------
Device Node Initialization / Removal
-------------------------------------------------------------------------- */
Index: linux-pm/drivers/acpi/pci_root.c
===================================================================
--- linux-pm.orig/drivers/acpi/pci_root.c
+++ linux-pm/drivers/acpi/pci_root.c
@@ -630,6 +630,7 @@ static int acpi_pci_root_add(struct acpi
pci_lock_rescan_remove();
pci_bus_add_devices(root->bus);
+ acpi_dev_turn_off_unused_descendants(root->device);
pci_unlock_rescan_remove();
return 1;
10 months
Re: [PATCH] ACPI: tools: fix compilation error
by Rafael J. Wysocki
On Wed, Oct 6, 2021 at 7:13 AM Miguel Bernal Marin
<miguel.bernal.marin(a)linux.intel.com> wrote:
>
> When acpi tools are compiled the following error is showed:
>
> $ cd tools/power/acpi
> $ make
> DESCEND tools/acpidbg
> MKDIR include
> CP include
> CC tools/acpidbg/acpidbg.o
> In file included from /home/linux/tools/power/acpi/include/acpi/platform/acenv.h:152,
> from /home/linux/tools/power/acpi/include/acpi/acpi.h:22,
> from acpidbg.c:9:
> /home/linux/tools/power/acpi/include/acpi/platform/acgcc.h:25:10: fatal error: linux/stdarg.h: No such file or directory
> 29 | #include <linux/stdarg.h>
> | ^~~~~~~~~~~~~~~~
> compilation terminated.
>
> Keep the same logic from ACPICA, just identify when is used inside kernel
> or by acpi tool.
>
> Fixes: c0891ac15f04 ("isystem: ship and use stdarg.h")
> Signed-off-by: Miguel Bernal Marin <miguel.bernal.marin(a)linux.intel.com>
> ---
> include/acpi/platform/acgcc.h | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/platform/acgcc.h b/include/acpi/platform/acgcc.h
> index fb172a03a753..20ecb004f5a4 100644
> --- a/include/acpi/platform/acgcc.h
> +++ b/include/acpi/platform/acgcc.h
> @@ -22,9 +22,14 @@ typedef __builtin_va_list va_list;
> #define va_arg(v, l) __builtin_va_arg(v, l)
> #define va_copy(d, s) __builtin_va_copy(d, s)
> #else
> +#ifdef __KERNEL__
> #include <linux/stdarg.h>
> -#endif
> -#endif
> +#else
> +/* Used to build acpi tools */
> +#include <stdarg.h>
> +#endif /* __KERNEL__ */
> +#endif /* ACPI_USE_BUILTIN_STDARG */
> +#endif /* ! va_arg */
>
> #define ACPI_INLINE __inline__
>
> --
Applied as 5.16 material, thanks!
10 months
Re: [PATCH] ACPICA: drop unneeded initialization value
by Rafael J. Wysocki
On Wed, Oct 6, 2021 at 1:37 PM Sohaib Mohamed <sohaib.amhmd(a)gmail.com> wrote:
>
> Do not initialise statics to 0
>
> Signed-off-by: Sohaib Mohamed <sohaib.amhmd(a)gmail.com>
> ---
> drivers/acpi/acpica/dbhistry.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dbhistry.c b/drivers/acpi/acpica/dbhistry.c
> index fd813c5d3952..60b77b11c0f2 100644
> --- a/drivers/acpi/acpica/dbhistry.c
> +++ b/drivers/acpi/acpica/dbhistry.c
> @@ -24,9 +24,9 @@ typedef struct history_info {
> } HISTORY_INFO;
>
> static HISTORY_INFO acpi_gbl_history_buffer[HISTORY_SIZE];
> -static u16 acpi_gbl_lo_history = 0;
> -static u16 acpi_gbl_num_history = 0;
> -static u16 acpi_gbl_next_history_index = 0;
> +static u16 acpi_gbl_lo_history;
> +static u16 acpi_gbl_num_history;
> +static u16 acpi_gbl_next_history_index;
>
> /*******************************************************************************
> *
> --
Please submit ACPICA changes like this to the upstream ACPICA project
as per MAINTANIERS.
Thanks!
10 months
Re: [rafael-pm:bleeding-edge 47/54] drivers/cpufreq/mediatek-cpufreq-hw.c:112:17: error: too few arguments to function 'cpufreq_table_find_index_dl'
by Rafael J. Wysocki
On Thu, Oct 7, 2021 at 1:26 PM Vincent Donnefort
<vincent.donnefort(a)arm.com> wrote:
>
>
> On Thu, Oct 07, 2021 at 06:35:55PM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
> > head: 6cb3f7cfca6963de4f486c4bd99fdefa56f75870
> > commit: 1f39fa0dccff71d4788089b5e617229b19166867 [47/54] cpufreq: Introducing CPUFREQ_RELATION_E
> > config: arm-buildonly-randconfig-r001-20211007 (attached as .config)
> > compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
> > reproduce (this is a W=1 build):
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commi...
> > git remote add rafael-pm https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> > git fetch --no-tags rafael-pm bleeding-edge
> > git checkout 1f39fa0dccff71d4788089b5e617229b19166867
> > # save the attached .config to linux build tree
> > mkdir build_dir
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash drivers/cpufreq/
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp(a)intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> > drivers/cpufreq/mediatek-cpufreq-hw.c: In function 'mtk_cpufreq_hw_fast_switch':
> > >> drivers/cpufreq/mediatek-cpufreq-hw.c:112:17: error: too few arguments to function 'cpufreq_table_find_index_dl'
> > 112 | index = cpufreq_table_find_index_dl(policy, target_freq);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from drivers/cpufreq/mediatek-cpufreq-hw.c:7:
> > include/linux/cpufreq.h:814:19: note: declared here
> > 814 | static inline int cpufreq_table_find_index_dl(struct cpufreq_policy *policy,
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>
> Rafael,
>
> The issue is this patch
>
> cpufreq: Introducing CPUFREQ_RELATION_E
>
> How would you like to proceed? Do you want a v8 patch-set with the fix or just
> that patch updated?
Please send an incremental fix on top of the series.
10 months
[rafael-pm:bleeding-edge 47/54] drivers/cpufreq/mediatek-cpufreq-hw.c:112:17: error: too few arguments to function 'cpufreq_table_find_index_dl'
by kernel test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
head: 6cb3f7cfca6963de4f486c4bd99fdefa56f75870
commit: 1f39fa0dccff71d4788089b5e617229b19166867 [47/54] cpufreq: Introducing CPUFREQ_RELATION_E
config: arm-buildonly-randconfig-r001-20211007 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commi...
git remote add rafael-pm https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
git fetch --no-tags rafael-pm bleeding-edge
git checkout 1f39fa0dccff71d4788089b5e617229b19166867
# save the attached .config to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash drivers/cpufreq/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
All errors (new ones prefixed by >>):
drivers/cpufreq/mediatek-cpufreq-hw.c: In function 'mtk_cpufreq_hw_fast_switch':
>> drivers/cpufreq/mediatek-cpufreq-hw.c:112:17: error: too few arguments to function 'cpufreq_table_find_index_dl'
112 | index = cpufreq_table_find_index_dl(policy, target_freq);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/cpufreq/mediatek-cpufreq-hw.c:7:
include/linux/cpufreq.h:814:19: note: declared here
814 | static inline int cpufreq_table_find_index_dl(struct cpufreq_policy *policy,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/cpufreq_table_find_index_dl +112 drivers/cpufreq/mediatek-cpufreq-hw.c
4855e26bcf4d28 Hector.Yuan 2021-09-03 105
4855e26bcf4d28 Hector.Yuan 2021-09-03 106 static unsigned int mtk_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
4855e26bcf4d28 Hector.Yuan 2021-09-03 107 unsigned int target_freq)
4855e26bcf4d28 Hector.Yuan 2021-09-03 108 {
4855e26bcf4d28 Hector.Yuan 2021-09-03 109 struct mtk_cpufreq_data *data = policy->driver_data;
4855e26bcf4d28 Hector.Yuan 2021-09-03 110 unsigned int index;
4855e26bcf4d28 Hector.Yuan 2021-09-03 111
4855e26bcf4d28 Hector.Yuan 2021-09-03 @112 index = cpufreq_table_find_index_dl(policy, target_freq);
4855e26bcf4d28 Hector.Yuan 2021-09-03 113
4855e26bcf4d28 Hector.Yuan 2021-09-03 114 writel_relaxed(index, data->reg_bases[REG_FREQ_PERF_STATE]);
4855e26bcf4d28 Hector.Yuan 2021-09-03 115
4855e26bcf4d28 Hector.Yuan 2021-09-03 116 return policy->freq_table[index].frequency;
4855e26bcf4d28 Hector.Yuan 2021-09-03 117 }
4855e26bcf4d28 Hector.Yuan 2021-09-03 118
:::::: The code at line 112 was first introduced by commit
:::::: 4855e26bcf4d28956f3e33231b961610a0d4a72d cpufreq: mediatek-hw: Add support for CPUFREQ HW
:::::: TO: Hector.Yuan <hector.yuan(a)mediatek.com>
:::::: CC: Viresh Kumar <viresh.kumar(a)linaro.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
10 months
Question about ACPICA, QNX and making beeps
by Devin Steffler
Hello,
I am using ACPICA to read battery information in QNX. That part is working
great so far. However, now some code that is being used to make beeps via
the PC speaker stopped working.
Strangely, this code stops working on a few devices only after ACPICA runs.
It works fine if I don't start ACPICA. The code is using I/O ports 0x43,
0x42, and 0x61 to generate beeps. This seems to be an industry standard way
to make beeps on x86 based PCs using a Programmable Interval Timer (PIT).
What could my ACPICA be doing (or failing to do) that could cause the beeps
to stop working with the code below? Is the PIT being disabled somehow? I
guess I'll need to learn more about the PIT and how to check its status to
see if it's being disabled after ACPICA runs.
Here's example code for QNX to generate a beep using the PC speaker:
// -----------------------------------------------
#include <sys/neutrino.h>
#include <hw/inout.h>
#include <unistd.h>
int main(void) {
ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions
// start a beep
int freq = 1000;
int scale = 1193046 / freq;
out8(0x43, 0xb6);
out8(0x42, scale & 0xff);
out8(0x42, scale >> 8);
out8(0x61, in8(0x61) | 3);
// let the beep play for a second
delay(1000);
// stop the beep
out8(0x61, in8(0x61) & ~3);
return 0;
}
// -----------------------------------------------
Thanks,
Devin
10 months, 1 week