[pm:bleeding-edge] BUILD SUCCESS 42326a293954f11eadf31161b8315bf6dc2279da
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 42326a293954f11eadf31161b8315bf6dc2279da Merge branch 'pm-opp' into linux-next
elapsed time: 722m
configs tested: 125
configs skipped: 2
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
h8300 h8s-sim_defconfig
arm imx_v4_v5_defconfig
powerpc tqm8541_defconfig
m68k m5475evb_defconfig
powerpc64 alldefconfig
arm mxs_defconfig
h8300 edosk2674_defconfig
sh kfr2r09-romimage_defconfig
arm iop32x_defconfig
arm badge4_defconfig
arc vdk_hs38_smp_defconfig
riscv allnoconfig
powerpc mpc85xx_cds_defconfig
sh defconfig
powerpc64 defconfig
xtensa iss_defconfig
sh hp6xx_defconfig
sh sh7710voipgw_defconfig
xtensa virt_defconfig
m68k m5407c3_defconfig
csky alldefconfig
sh sh2007_defconfig
sh r7785rp_defconfig
mips maltaup_xpa_defconfig
arm assabet_defconfig
arm ixp4xx_defconfig
arm pxa168_defconfig
m68k hp300_defconfig
powerpc linkstation_defconfig
powerpc walnut_defconfig
csky defconfig
powerpc ps3_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
sh shx3_defconfig
mips gcw0_defconfig
m68k alldefconfig
sh espt_defconfig
powerpc eiger_defconfig
arm simpad_defconfig
xtensa cadence_csp_defconfig
arm imx_v6_v7_defconfig
mips malta_defconfig
mips jmr3927_defconfig
mips capcella_defconfig
m68k bvme6000_defconfig
nios2 10m50_defconfig
sparc sparc64_defconfig
arc tb10x_defconfig
mips tb0226_defconfig
mips cu1830-neo_defconfig
riscv allyesconfig
sh edosk7705_defconfig
m68k defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
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 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210312
i386 randconfig-a005-20210312
i386 randconfig-a002-20210312
i386 randconfig-a003-20210312
i386 randconfig-a004-20210312
i386 randconfig-a006-20210312
x86_64 randconfig-a011-20210312
x86_64 randconfig-a016-20210312
x86_64 randconfig-a013-20210312
x86_64 randconfig-a014-20210312
x86_64 randconfig-a015-20210312
x86_64 randconfig-a012-20210312
i386 randconfig-a013-20210312
i386 randconfig-a016-20210312
i386 randconfig-a011-20210312
i386 randconfig-a015-20210312
i386 randconfig-a014-20210312
i386 randconfig-a012-20210312
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a001-20210312
x86_64 randconfig-a003-20210312
x86_64 randconfig-a002-20210312
x86_64 randconfig-a004-20210312
x86_64 randconfig-a006-20210312
x86_64 randconfig-a005-20210312
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months, 1 week
Re: [PATCH 1/1] ACPI: fix acpi table use after free
by Rafael J. Wysocki
On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand <david(a)redhat.com> wrote:
>
> >>>>> The same could be reproduced via zone shuffling with a little luck.
> >>>>
> >>>> But nobody does that in practice.
> >>>>
> >>
> >> Dan will most certainly object. And I don't know what makes you speak in
> >> absolute words here.
> >>
> >>>> This would be relatively straightforward to address if ACPICA was not
> >>>> involved in it, but unfortunately that's not the case.
> >>>>
> >>>> Changing this part of ACPICA is risky, because such changes may affect
> >>>> other OSes using it, so that requires some serious consideration.
> >>>> Alternatively, the previous memory allocation order in Linux could be
> >>>> restored.
> >>>
> >>> Of course, long-term this needs to be addressed in the ACPI
> >>> initialization code, because it clearly is not robust enough, but in
> >>> the meantime there's practical breakage observable in the field, so
> >>> what can be done about that?
> >>
> >> *joke* enable zone shuffling.
> >>
> >> No seriously, fix the latent BUG. What again is problematic about excluding
> >> these pages from the page allcoator, for example, via memblock_reserve()?
> >>
> >> @Mike?
> >
> > There is some care that should be taken to make sure we get the order
> > right, but I don't see a fundamental issue here.
Me neither.
> > If I understand correctly, Rafael's concern is about changing the parts of
> > ACPICA that should be OS agnostic, so I think we just need another place to
> > call memblock_reserve() rather than acpi_tb_install_table_with_override().
Something like this.
There is also the problem that memblock_reserve() needs to be called
for all of the tables early enough, which will require some reordering
of the early init code.
> > Since the reservation should be done early in x86::setup_arch() (and
> > probably in arm64::setup_arch()) we might just have a function that parses
> > table headers and reserves them, similarly to how we parse the tables
> > during KASLR setup.
Right.
>
> FWIW, something like below would hide our latent BUG again properly (lol).
> But I guess I don't have to express how ugly and wrong that is. Not to mention
> what happens if memblock decides to allocate that memory area earlier
> for some other user (including CMA, ...).
Fair enough.
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3e4b29ee2b1e..ec71b7c63dbe 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1566,6 +1566,21 @@ void __free_pages_core(struct page *page, unsigned int order)
>
> atomic_long_add(nr_pages, &page_zone(page)->managed_pages);
>
> + /*
> + * BUG ALERT: x86-64 ACPI code has latent BUGs where ACPI tables
> + * that must not get allocated/modified will get exposed to the buddy
> + * as free pages; anybody can allocate and use them once in the free
> + * lists.
> + *
> + * Instead of fixing the BUG, revert the change to the
> + * freeing/allocation order during boot that revealed it and cross
> + * fingers that everything will be fine.
> + */
> + if (system_state < SYSTEM_RUNNING) {
> + __free_pages_ok(page, order, FPI_NONE);
> + return;
> + }
> +
> /*
> * Bypass PCP and place fresh pages right to the tail, primarily
> * relevant for memory onlining.
>
>
> --
7 months, 1 week
[pm:bleeding-edge] BUILD SUCCESS 8608bdeb4cdb5608b4073077e6e5d7bdedefd169
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 8608bdeb4cdb5608b4073077e6e5d7bdedefd169 Merge branch 'devprop' into linux-next
elapsed time: 725m
configs tested: 141
configs skipped: 2
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
sparc allyesconfig
mips db1xxx_defconfig
powerpc tqm8540_defconfig
powerpc ppc44x_defconfig
powerpc xes_mpc85xx_defconfig
arm lubbock_defconfig
m68k bvme6000_defconfig
arc axs103_defconfig
arm imx_v4_v5_defconfig
csky defconfig
arm s5pv210_defconfig
arm h5000_defconfig
ia64 bigsur_defconfig
powerpc motionpro_defconfig
nios2 alldefconfig
arm eseries_pxa_defconfig
powerpc sbc8548_defconfig
sh dreamcast_defconfig
parisc alldefconfig
arm mxs_defconfig
sh r7785rp_defconfig
sh titan_defconfig
sh se7712_defconfig
powerpc mpc7448_hpc2_defconfig
powerpc sam440ep_defconfig
powerpc akebono_defconfig
mips jmr3927_defconfig
mips nlm_xlp_defconfig
sh defconfig
powerpc mpc832x_rdb_defconfig
arm cns3420vb_defconfig
m68k m5275evb_defconfig
h8300 defconfig
mips bcm63xx_defconfig
s390 debug_defconfig
mips loongson1c_defconfig
arm mv78xx0_defconfig
powerpc tqm8548_defconfig
m68k sun3_defconfig
ia64 allyesconfig
h8300 h8s-sim_defconfig
arm moxart_defconfig
arm tegra_defconfig
sh ul2_defconfig
arm multi_v7_defconfig
arm mvebu_v7_defconfig
sh hp6xx_defconfig
openrisc simple_smp_defconfig
powerpc mpc8540_ads_defconfig
arc haps_hs_defconfig
powerpc skiroot_defconfig
powerpc ep88xc_defconfig
mips jazz_defconfig
powerpc storcenter_defconfig
arm versatile_defconfig
mips bcm47xx_defconfig
powerpc pmac32_defconfig
ia64 allmodconfig
ia64 defconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
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 defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20210308
i386 randconfig-a003-20210308
i386 randconfig-a002-20210308
i386 randconfig-a006-20210308
i386 randconfig-a004-20210308
i386 randconfig-a001-20210308
i386 randconfig-a005-20210309
i386 randconfig-a003-20210309
i386 randconfig-a002-20210309
i386 randconfig-a006-20210309
i386 randconfig-a004-20210309
i386 randconfig-a001-20210309
x86_64 randconfig-a013-20210309
x86_64 randconfig-a016-20210309
x86_64 randconfig-a015-20210309
x86_64 randconfig-a014-20210309
x86_64 randconfig-a011-20210309
x86_64 randconfig-a012-20210309
i386 randconfig-a016-20210309
i386 randconfig-a012-20210309
i386 randconfig-a014-20210309
i386 randconfig-a013-20210309
i386 randconfig-a011-20210309
i386 randconfig-a015-20210309
i386 randconfig-a013-20210310
i386 randconfig-a016-20210310
i386 randconfig-a011-20210310
i386 randconfig-a014-20210310
i386 randconfig-a015-20210310
i386 randconfig-a012-20210310
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210309
x86_64 randconfig-a001-20210309
x86_64 randconfig-a004-20210309
x86_64 randconfig-a002-20210309
x86_64 randconfig-a005-20210309
x86_64 randconfig-a003-20210309
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months, 1 week
Re: [PATCH 1/1] ACPI: fix acpi table use after free
by Rafael J. Wysocki
On Fri, Mar 5, 2021 at 2:40 PM David Hildenbrand <david(a)redhat.com> wrote:
>
> >> The ibft table, for example, is mapped in via acpi_map() and kmap(). The
> >> page for the ibft table is not reserved, so it can end up on the freelist.
> >
> > You appear to be saying that it is not sufficient to kmap() a page in
> > order to use it safely. It is also necessary to reserve it upfront,
> > for example with the help of memblock_reserve(). Is that correct? If
> > so, is there an alternative way to reserve a page frame?
>
> If the memory is indicated by the BIOS/firmware as valid memory
> (!reserved) but contains actual tables that have to remain untouched
> what happens is:
>
> 1) Memblock thinks the memory should be given to the buddy, because it
> is valid memory and was not reserved by anyone (i.e., the bios, early
> allocations).
>
> 2) Memblock will expose the pages to the buddy, adding them to the free
> page list.
>
> 3) Anybody can allocate them, e.g., via alloc_pages().
>
> The root issue is that pages that should not get exposed to the buddy as
> free pages get exposed to the buddy as free pages. We have to teach
> memblock that these pages are not actually to be used, but instead, area
> reserved.
>
> >
> >>>
> >>>> Use memblock_reserve() to reserve all the ACPI table pages.
> >>> How is this going to help?
> >> If the ibft table page is not reserved, it will end up on the freelist
> >> and potentially be allocated before ibft_init() is called.
> >>
> >> I believe this is the call that causes the ibft table page (in this case
> >> pfn=0xbe453) to end up on the freelist:
> >>
> >> memmap_init_range: size=bd49b, nid=0, zone=1, start_pfn=1000,
> >> zone_end_pfn=100000
> >
> > David, is commit 7fef431be9c9 related to this and if so, then how?
> >
>
> Memory gets allocated and used in a different order, which seems to have
> exposed (yet another) latent BUG.
Well, you can call it that, or you can say that things worked under
certain assumptions regarding the memory allocation order which are
not met any more.
> The same could be reproduced via zone shuffling with a little luck.
But nobody does that in practice.
This would be relatively straightforward to address if ACPICA was not
involved in it, but unfortunately that's not the case.
Changing this part of ACPICA is risky, because such changes may affect
other OSes using it, so that requires some serious consideration.
Alternatively, the previous memory allocation order in Linux could be
restored.
7 months, 1 week
Re: [PATCH 1/1] ACPI: fix acpi table use after free
by Rafael J. Wysocki
On Tue, Mar 9, 2021 at 6:54 PM Mike Rapoport <rppt(a)linux.ibm.com> wrote:
>
> On Sun, Mar 07, 2021 at 09:46:22AM +0200, Mike Rapoport wrote:
> > Hello Rafael,
> >
> > On Fri, Mar 05, 2021 at 02:30:07PM +0100, Rafael J. Wysocki wrote:
> > > On Fri, Mar 5, 2021 at 12:14 AM George Kennedy <george.kennedy(a)oracle.com> wrote:
> > >
> > > > The ibft table, for example, is mapped in via acpi_map() and kmap(). The
> > > > page for the ibft table is not reserved, so it can end up on the freelist.
> > >
> > > You appear to be saying that it is not sufficient to kmap() a page in
> > > order to use it safely. It is also necessary to reserve it upfront,
> > > for example with the help of memblock_reserve(). Is that correct? If
> > > so, is there an alternative way to reserve a page frame?
> >
> > Like David said in the other reply, if a BIOS does not mark the memory that
> > contains an ACPI table as used (e.g. reserved or ACPI data), we need to
> > make sure the kernel knows that such memory is in use and an early call to
> > memblock_reserve() is exactly what we need here.
> > George had this issue with iBFT, but in general this could be any table
> > that a buggy BIOS forgot to mark as ACPI data.
>
> BTW, I wonder is there a fundamental reason to use ioremap() to access ACPI
> tables at all?
> In the end, they reside in RAM and, apparently, they live at the same DIMM
> as neighboring "normal memory" so why cannot we just map them normally as
> read-only not executable?
This may be NVS memory (depending on the configuration of the system)
which isn't "normal" RAM AFAICS.
7 months, 1 week
ACPI table testing with ACPICA
by Jakub Czapiga
Hello everyone,
I am working on a system for AML testing. Basically I want to create some
kind of unit-testing environment allowing to load generated ACPI tables
(preferably from memory buffer) and check methods' behavior, check
variables, check if all required objects are present etc.
My first idea was to dump generated ACPI tables into files, load them into
AcpiExec process and communicate with it using Python. I wonder if it is
possible to use provided source code as a library and write tests in C
instead of Python with a custom framework.
Could you please guide me in the right direction?
P.S.
https://acpica.org/contact does not work. Captcha is empty.
Regards,
Jakub Czapiga
jacz(a)semihalf.com
7 months, 1 week
[pm:bleeding-edge] BUILD SUCCESS 4612c104e41532886aeae80f37d15e14fdad6cbf
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 4612c104e41532886aeae80f37d15e14fdad6cbf Merge branch 'acpi-messages' into bleeding-edge
elapsed time: 723m
configs tested: 95
configs skipped: 2
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
mips workpad_defconfig
sh se7724_defconfig
mips bigsur_defconfig
mips ath25_defconfig
m68k sun3_defconfig
sh ap325rxa_defconfig
m68k m5208evb_defconfig
powerpc ppc64_defconfig
riscv nommu_k210_sdcard_defconfig
mips ci20_defconfig
sh rsk7201_defconfig
powerpc tqm8541_defconfig
powerpc pq2fads_defconfig
arm stm32_defconfig
mips decstation_r4k_defconfig
powerpc ge_imp3a_defconfig
powerpc pcm030_defconfig
um x86_64_defconfig
mips rbtx49xx_defconfig
arm integrator_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
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 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20210308
i386 randconfig-a003-20210308
i386 randconfig-a002-20210308
i386 randconfig-a006-20210308
i386 randconfig-a004-20210308
i386 randconfig-a001-20210308
i386 randconfig-a016-20210308
i386 randconfig-a012-20210308
i386 randconfig-a014-20210308
i386 randconfig-a013-20210308
i386 randconfig-a011-20210308
i386 randconfig-a015-20210308
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210309
x86_64 randconfig-a001-20210309
x86_64 randconfig-a004-20210309
x86_64 randconfig-a002-20210309
x86_64 randconfig-a005-20210309
x86_64 randconfig-a003-20210309
x86_64 randconfig-a013-20210308
x86_64 randconfig-a016-20210308
x86_64 randconfig-a015-20210308
x86_64 randconfig-a014-20210308
x86_64 randconfig-a011-20210308
x86_64 randconfig-a012-20210308
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months, 1 week
Re: [PATCH v3 1/6] ACPI: scan: Extend acpi_walk_dep_device_list()
by Rafael J. Wysocki
On Mon, Feb 22, 2021 at 2:07 PM Daniel Scally <djrscally(a)gmail.com> wrote:
>
> The acpi_walk_dep_device_list() is not as generalisable as its name
> implies, serving only to decrement the dependency count for each
> dependent device of the input. Extend the function to instead accept
> a callback which can be applied to all the dependencies in acpi_dep_list.
> Replace all existing calls to the function with calls to a wrapper, passing
> a callback that applies the same dependency reduction.
>
> Suggested-by: Rafael J. Wysocki <rafael(a)kernel.org>
> Signed-off-by: Daniel Scally <djrscally(a)gmail.com>
> ---
> Changes in v3:
> - patch introduced
>
> drivers/acpi/ec.c | 2 +-
> drivers/acpi/pmic/intel_pmic_chtdc_ti.c | 2 +-
> drivers/acpi/scan.c | 58 ++++++++++++++++-------
> drivers/gpio/gpiolib-acpi.c | 2 +-
> drivers/i2c/i2c-core-acpi.c | 2 +-
> drivers/platform/surface/surface3_power.c | 2 +-
> include/acpi/acpi_bus.h | 7 +++
> include/linux/acpi.h | 4 +-
> 8 files changed, 55 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 13565629ce0a..a258db713bd2 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -1627,7 +1627,7 @@ static int acpi_ec_add(struct acpi_device *device)
> WARN(!ret, "Could not request EC cmd io port 0x%lx", ec->command_addr);
>
> /* Reprobe devices depending on the EC */
> - acpi_walk_dep_device_list(ec->handle);
> + acpi_dev_flag_dependency_met(ec->handle);
>
> acpi_handle_debug(ec->handle, "enumerated.\n");
> return 0;
> diff --git a/drivers/acpi/pmic/intel_pmic_chtdc_ti.c b/drivers/acpi/pmic/intel_pmic_chtdc_ti.c
> index a5101b07611a..59cca504325e 100644
> --- a/drivers/acpi/pmic/intel_pmic_chtdc_ti.c
> +++ b/drivers/acpi/pmic/intel_pmic_chtdc_ti.c
> @@ -117,7 +117,7 @@ static int chtdc_ti_pmic_opregion_probe(struct platform_device *pdev)
> return err;
>
> /* Re-enumerate devices depending on PMIC */
> - acpi_walk_dep_device_list(ACPI_HANDLE(pdev->dev.parent));
> + acpi_dev_flag_dependency_met(ACPI_HANDLE(pdev->dev.parent));
> return 0;
> }
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 80b668c80073..c9e4190316ef 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -49,12 +49,6 @@ static DEFINE_MUTEX(acpi_hp_context_lock);
> */
> static u64 spcr_uart_addr;
>
> -struct acpi_dep_data {
> - struct list_head node;
> - acpi_handle supplier;
> - acpi_handle consumer;
> -};
> -
> void acpi_scan_lock_acquire(void)
> {
> mutex_lock(&acpi_scan_lock);
> @@ -2099,30 +2093,58 @@ static void acpi_bus_attach(struct acpi_device *device, bool first_pass)
> device->handler->hotplug.notify_online(device);
> }
>
> -void acpi_walk_dep_device_list(acpi_handle handle)
> +static int __acpi_dev_flag_dependency_met(struct acpi_dep_data *dep,
> + void *data)
> {
> - struct acpi_dep_data *dep, *tmp;
> struct acpi_device *adev;
>
> + acpi_bus_get_device(dep->consumer, &adev);
> + if (!adev)
> + return 0;
> +
> + adev->dep_unmet--;
> + if (!adev->dep_unmet)
> + acpi_bus_attach(adev, true);
> +
> + list_del(&dep->node);
> + kfree(dep);
> + return 0;
> +}
> +
> +void acpi_walk_dep_device_list(acpi_handle handle,
> + int (*callback)(struct acpi_dep_data *, void *),
> + void *data)
> +{
> + struct acpi_dep_data *dep, *tmp;
> + int ret;
> +
> mutex_lock(&acpi_dep_list_lock);
> list_for_each_entry_safe(dep, tmp, &acpi_dep_list, node) {
> if (dep->supplier == handle) {
> - acpi_bus_get_device(dep->consumer, &adev);
> - if (!adev)
> - continue;
> -
> - adev->dep_unmet--;
> - if (!adev->dep_unmet)
> - acpi_bus_attach(adev, true);
The above code in the mainline has changed recently, so you need to
rebase the above and adjust for the change of behavior.
> -
> - list_del(&dep->node);
> - kfree(dep);
> + ret = callback(dep, data);
> + if (ret)
> + break;
> }
> }
> mutex_unlock(&acpi_dep_list_lock);
> }
> EXPORT_SYMBOL_GPL(acpi_walk_dep_device_list);
>
> +/**
> + * acpi_dev_flag_dependency_met() - Inform consumers of @handle that the device
> + * is now active
No parens here, please, and make it fit one line.
Also the description should be something like "Clear dependencies on
the given device."
> + * @handle: acpi_handle for the supplier device
> + *
> + * This function walks through the dependencies list and informs each consumer
> + * of @handle that their dependency upon it is now met. Devices with no more
> + * unmet dependencies will be attached to the acpi bus.
> + */
> +void acpi_dev_flag_dependency_met(acpi_handle handle)
> +{
> + acpi_walk_dep_device_list(handle, __acpi_dev_flag_dependency_met, NULL);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dev_flag_dependency_met);
> +
> /**
> * acpi_bus_scan - Add ACPI device node objects in a given namespace scope.
> * @handle: Root of the namespace scope to scan.
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> index e37a57d0a2f0..e4d728fda982 100644
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@ -1254,7 +1254,7 @@ void acpi_gpiochip_add(struct gpio_chip *chip)
>
> acpi_gpiochip_request_regions(acpi_gpio);
> acpi_gpiochip_scan_gpios(acpi_gpio);
> - acpi_walk_dep_device_list(handle);
> + acpi_dev_flag_dependency_met(handle);
> }
>
> void acpi_gpiochip_remove(struct gpio_chip *chip)
> diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
> index 37c510d9347a..38647cf34bde 100644
> --- a/drivers/i2c/i2c-core-acpi.c
> +++ b/drivers/i2c/i2c-core-acpi.c
> @@ -283,7 +283,7 @@ void i2c_acpi_register_devices(struct i2c_adapter *adap)
> if (!handle)
> return;
>
> - acpi_walk_dep_device_list(handle);
> + acpi_dev_flag_dependency_met(handle);
> }
>
> static const struct acpi_device_id i2c_acpi_force_400khz_device_ids[] = {
> diff --git a/drivers/platform/surface/surface3_power.c b/drivers/platform/surface/surface3_power.c
> index cc4f9cba6856..ad895285d3e9 100644
> --- a/drivers/platform/surface/surface3_power.c
> +++ b/drivers/platform/surface/surface3_power.c
> @@ -478,7 +478,7 @@ static int mshw0011_install_space_handler(struct i2c_client *client)
> return -ENOMEM;
> }
>
> - acpi_walk_dep_device_list(handle);
> + acpi_dev_flag_dependency_met(handle);
> return 0;
> }
>
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 02a716a0af5d..91172af3a04d 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -278,6 +278,12 @@ struct acpi_device_power {
> struct acpi_device_power_state states[ACPI_D_STATE_COUNT]; /* Power states (D0-D3Cold) */
> };
>
> +struct acpi_dep_data {
> + struct list_head node;
> + acpi_handle supplier;
> + acpi_handle consumer;
> +};
> +
> /* Performance Management */
>
> struct acpi_device_perf_flags {
> @@ -683,6 +689,7 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev)
>
> bool acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2, const char *uid2);
>
> +void acpi_dev_flag_dependency_met(acpi_handle handle);
> struct acpi_device *
> acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid, const char *uid, s64 hrv);
> struct acpi_device *
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 2630c2e953f7..2d5e6e88e8a0 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -655,7 +655,9 @@ extern bool acpi_driver_match_device(struct device *dev,
> const struct device_driver *drv);
> int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
> int acpi_device_modalias(struct device *, char *, int);
> -void acpi_walk_dep_device_list(acpi_handle handle);
> +void acpi_walk_dep_device_list(acpi_handle handle,
> + int (*callback)(struct acpi_dep_data *, void *),
> + void *data);
>
> struct platform_device *acpi_create_platform_device(struct acpi_device *,
> struct property_entry *);
> --
> 2.25.1
>
7 months, 1 week
Re: [PATCH v3 1/6] ACPI: scan: Extend acpi_walk_dep_device_list()
by Andy Shevchenko
On Sun, Mar 7, 2021 at 3:36 PM Daniel Scally <djrscally(a)gmail.com> wrote:
> On 22/02/2021 13:34, Andy Shevchenko wrote:
> > On Mon, Feb 22, 2021 at 3:12 PM Daniel Scally <djrscally(a)gmail.com> wrote:
> >> The acpi_walk_dep_device_list() is not as generalisable as its name
> >> implies, serving only to decrement the dependency count for each
> >> dependent device of the input. Extend the function to instead accept
> >> a callback which can be applied to all the dependencies in acpi_dep_list.
> >> Replace all existing calls to the function with calls to a wrapper, passing
> >> a callback that applies the same dependency reduction.
> > The code looks okay to me, if it was the initial idea, feel free to add
> > Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com>
>
>
> Thank you!
>
>
> >> + */
> >> +void acpi_dev_flag_dependency_met(acpi_handle handle)
> >> +{
> > Since it's acpi_dev_* namespace, perhaps it should take struct acpi_device here?
>
>
> I can do this, but I avoided it because in most of the uses in the
> kernel currently there's no struct acpi_device, they're just passing
> ACPI_HANDLE(dev) instead, so I'd need to get the adev with
> ACPI_COMPANION() in each place. It didn't seem worth it...but happy to
> do it if you'd prefer it that way?
I see, let Rafael decide then. I'm not pushing here.
--
With Best Regards,
Andy Shevchenko
7 months, 1 week
[pm:bleeding-edge] BUILD SUCCESS 5c476073a9df062a501edf9ea7b11ccc53c27bf7
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 5c476073a9df062a501edf9ea7b11ccc53c27bf7 Merge branches 'acpi-drivers' and 'acpi-bus' into linux-next
elapsed time: 721m
configs tested: 140
configs skipped: 2
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
sh sh7763rdp_defconfig
powerpc g5_defconfig
xtensa smp_lx200_defconfig
csky alldefconfig
arm orion5x_defconfig
powerpc pasemi_defconfig
arc allyesconfig
powerpc klondike_defconfig
sh titan_defconfig
arm aspeed_g4_defconfig
mips malta_kvm_defconfig
arm lubbock_defconfig
mips e55_defconfig
powerpc ppc44x_defconfig
powerpc ge_imp3a_defconfig
arm hackkit_defconfig
arc nsimosci_hs_smp_defconfig
arc haps_hs_defconfig
powerpc arches_defconfig
sh rsk7264_defconfig
arm bcm2835_defconfig
mips decstation_defconfig
powerpc mpc8560_ads_defconfig
arm pcm027_defconfig
arm lpd270_defconfig
riscv nommu_k210_defconfig
sparc allyesconfig
mips maltaup_defconfig
sh sh7785lcr_defconfig
mips maltasmvp_eva_defconfig
powerpc ep8248e_defconfig
powerpc sbc8548_defconfig
parisc generic-32bit_defconfig
powerpc tqm8555_defconfig
sh r7780mp_defconfig
powerpc bamboo_defconfig
parisc generic-64bit_defconfig
arc tb10x_defconfig
ia64 defconfig
sparc sparc64_defconfig
mips ci20_defconfig
s390 zfcpdump_defconfig
mips cu1000-neo_defconfig
arm keystone_defconfig
sh se7705_defconfig
nios2 alldefconfig
sh sh7724_generic_defconfig
xtensa xip_kc705_defconfig
m68k q40_defconfig
mips rs90_defconfig
arm pxa3xx_defconfig
arc axs103_smp_defconfig
mips decstation_64_defconfig
powerpc tqm8560_defconfig
microblaze defconfig
mips tb0287_defconfig
powerpc tqm8541_defconfig
sh landisk_defconfig
mips rbtx49xx_defconfig
arm versatile_defconfig
arm pxa910_defconfig
mips decstation_r4k_defconfig
mips tb0219_defconfig
powerpc redwood_defconfig
m68k sun3x_defconfig
sh apsh4ad0a_defconfig
arm shmobile_defconfig
sh se7724_defconfig
powerpc holly_defconfig
powerpc allmodconfig
ia64 allyesconfig
ia64 allmodconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
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 defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
i386 randconfig-a005-20210307
i386 randconfig-a003-20210307
i386 randconfig-a002-20210307
i386 randconfig-a004-20210307
i386 randconfig-a006-20210307
i386 randconfig-a001-20210307
x86_64 randconfig-a013-20210307
x86_64 randconfig-a016-20210307
x86_64 randconfig-a015-20210307
x86_64 randconfig-a014-20210307
x86_64 randconfig-a012-20210307
x86_64 randconfig-a011-20210307
i386 randconfig-a016-20210307
i386 randconfig-a012-20210307
i386 randconfig-a013-20210307
i386 randconfig-a011-20210307
i386 randconfig-a015-20210307
i386 randconfig-a014-20210307
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210307
x86_64 randconfig-a001-20210307
x86_64 randconfig-a004-20210307
x86_64 randconfig-a005-20210307
x86_64 randconfig-a002-20210307
x86_64 randconfig-a003-20210307
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
7 months, 1 week
