lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E204822B1@FRAEML521-MBX.china.huawei.com>
Date:   Tue, 14 Mar 2017 08:14:51 +0000
From:   Gabriele Paoloni <gabriele.paoloni@...wei.com>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Yuanzhichang <yuanzhichang@...ilicon.com>
CC:     "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "frowand.list@...il.com" <frowand.list@...il.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "minyard@....org" <minyard@....org>,
        "liviu.dudau@....com" <liviu.dudau@....com>,
        "zourongrong@...il.com" <zourongrong@...il.com>,
        John Garry <john.garry@...wei.com>,
        "zhichang.yuan02@...il.com" <zhichang.yuan02@...il.com>,
        "kantyzc@....com" <kantyzc@....com>,
        "xuwei (O)" <xuwei5@...ilicon.com>
Subject: RE: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose
  dependency has not met

Hi Rafael

Many thanks for your review

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@...ysocki.net]
> Sent: 13 March 2017 21:25
> To: Yuanzhichang
> Cc: catalin.marinas@....com; will.deacon@....com; robh+dt@...nel.org;
> frowand.list@...il.com; bhelgaas@...gle.com; rafael@...nel.org;
> mark.rutland@....com; arnd@...db.de; linux-arm-
> kernel@...ts.infradead.org; linux-acpi@...r.kernel.org;
> lorenzo.pieralisi@....com; benh@...nel.crashing.org; linux-
> kernel@...r.kernel.org; Linuxarm; devicetree@...r.kernel.org; linux-
> pci@...r.kernel.org; linux-serial@...r.kernel.org; minyard@....org;
> liviu.dudau@....com; zourongrong@...il.com; John Garry; Gabriele
> Paoloni; zhichang.yuan02@...il.com; kantyzc@....com; xuwei (O)
> Subject: Re: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices
> whose dependency has not met
> 
> On Monday, March 13, 2017 10:42:41 AM zhichang.yuan wrote:
> > In commit 40e7fcb1929(ACPI: Add _DEP support to fix battery issue on
> Asus
> > T100TA), the '_DEP' was supported to solve the dependency of Asus
> battery. But
> > this patch is specific to Asus battery device.
> > In the real world, there are other devices which need the dependency
> to play the
> > role on the enumeration order. For example, all the Hip06 LPC
> > periperals(IPMI-BT, uart, etc) must be scanned after the LPC host
> driver
> > finished the probing. So, it makes sense to add a checking whether
> the ACPI
> > device meet all the dependencies during its enumeration slot, if not,
> the
> > enumeration will be delayed till all dependency master finish their
> work.
> >
> > This patch adds the dependency checking in ACPI enumeration, also the
> > corresponding handling to retrigger the Hip06 LPC peripherals'
> scanning.
> 
> AFAICS, _DEP is generally abused in the wild and cannot be made
> generic.  Sorry.

Another option here would be to revert this patch and add a dependency
check in the probe functions of the LPC possible children nodes (e.g. 
in the IPMI driver:
http://elixir.free-electrons.com/source/drivers/char/ipmi/ipmi_si_intf.c?v=4.10#L2683
)  

we could add 

	if (device->dep_unmet)
		return -EPROBE_DEFER;

as we now have in acpi/battery.c...

I think this should not make any difference for current shipped FW that has
got no DEP method...

What do you think?

Many Thanks
Gab

> 
> Thanks,
> Rafael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ