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: <EE11001F9E5DDD47B7634E2F8A612F2E40B10632@FRAEML521-MBX.china.huawei.com>
Date:   Mon, 3 Jul 2017 16:23:40 +0000
From:   Gabriele Paoloni <gabriele.paoloni@...wei.com>
To:     Gabriele Paoloni <gabriele.paoloni@...wei.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
CC:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "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>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "brian.starkey@....com" <brian.starkey@....com>,
        "olof@...om.net" <olof@...om.net>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "minyard@....org" <minyard@....org>,
        John Garry <john.garry@...wei.com>,
        "xuwei (O)" <xuwei5@...ilicon.com>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>
Subject: RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO
 devices before scanning

+CC Lee Jones

> -----Original Message-----
> From: Gabriele Paoloni
> Sent: 03 July 2017 17:08
> To: Gabriele Paoloni; Mika Westerberg
> Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> catalin.marinas@....com; will.deacon@....com; robh+dt@...nel.org;
> frowand.list@...il.com; bhelgaas@...gle.com; arnd@...db.de; linux-arm-
> kernel@...ts.infradead.org; mark.rutland@....com;
> brian.starkey@....com; olof@...om.net; benh@...nel.crashing.org; linux-
> kernel@...r.kernel.org; linux-acpi@...r.kernel.org; Linuxarm; linux-
> pci@...r.kernel.org; minyard@....org; John Garry; xuwei (O)
> Subject: RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO
> devices before scanning
> 
> Hi Mika
> 
> > -----Original Message-----
> > From: linux-pci-owner@...r.kernel.org [mailto:linux-pci-
> > owner@...r.kernel.org] On Behalf Of Gabriele Paoloni
> > Sent: 19 June 2017 11:05
> > To: Mika Westerberg
> > Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> > catalin.marinas@....com; will.deacon@....com; robh+dt@...nel.org;
> > frowand.list@...il.com; bhelgaas@...gle.com; arnd@...db.de; linux-
> arm-
> > kernel@...ts.infradead.org; mark.rutland@....com;
> > brian.starkey@....com; olof@...om.net; benh@...nel.crashing.org;
> linux-
> > kernel@...r.kernel.org; linux-acpi@...r.kernel.org; Linuxarm; linux-
> > pci@...r.kernel.org; minyard@....org; John Garry; xuwei (O)
> > Subject: RE: [PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO
> > devices before scanning
> >
> > Hi Mika
> >
> > > -----Original Message-----
> > > From: Mika Westerberg [mailto:mika.westerberg@...ux.intel.com]
> > > Sent: 19 June 2017 11:02
> > > To: Gabriele Paoloni
> > > Cc: Rafael J. Wysocki; Lorenzo Pieralisi; Rafael J. Wysocki;
> > > catalin.marinas@....com; will.deacon@....com; robh+dt@...nel.org;
> > > frowand.list@...il.com; bhelgaas@...gle.com; arnd@...db.de; linux-
> > arm-
> > > kernel@...ts.infradead.org; mark.rutland@....com;
> > > brian.starkey@....com; olof@...om.net; benh@...nel.crashing.org;
> > linux-
> > > kernel@...r.kernel.org; linux-acpi@...r.kernel.org; Linuxarm;
> linux-
> > > pci@...r.kernel.org; minyard@....org; John Garry; xuwei (O)
> > > Subject: Re: [PATCH v9 5/7] ACPI: Translate the I/O range of non-
> MMIO
> > > devices before scanning
> > >
> > > On Mon, Jun 19, 2017 at 09:50:49AM +0000, Gabriele Paoloni wrote:
> > > > Many thanks for your response and your help here.
> > > >
> > > > I guess that as conclusion with respect to the current v9
> patchset
> > we
> > > can
> > > > disregard the idea of MFD and modify the current v9 so that it
> > > doesn't
> > > > touch directly ACPI resources.
> > > > Instead as I proposed before we can have the scan handler to
> > > enumerate
> > > > the children devices and translate its addresses filling dev-
> > > >resources[] and
> > > > at the same time we can modify acpi_default_enumeration to check
> > > > acpi_device_enumerated() before continuing with device
> > > enumeration...?
> > > >
> > > > Do you think it as a viable solution?
> > >
> > > No, I think MFD + scan handler inside the MFD driver is the way to
> > go.
> > > We don't want to trash ACPI core with stuff that does not belong
> > there
> > > IMHO.
> >
> > Ok Many thanks I will investigate this direction
> 
> I had a look into the MFD framework. If my understanding is correct the
> mfd
> framework create a platform device for each declared mfd_cell that is
> passed
> to mfd_add_devices().
> However there is something that I do not quite understand:
> from
> http://elixir.free-electrons.com/linux/latest/source/drivers/mfd/mfd-
> core.c#L207
> it seems that mfd_add_device() will create the platform device using
> the
> resources that are statically declared in the respective mfd_cell.
> 
> In my case I'd like to have a platform device using the resources that
> are
> parsed from the ACPI table (i.e. as it is done now by
> acpi_create_platform_device()).
> 
> If my understanding is correct, if I declared an mfd_cell for my IPMI
> child
> the mfd subsystem would create a platform device for such child and
> therefore acpi_create_platform_device() would fail to create a new
> platform
> device as adev->physical_node_count will be non zero.
> However as things stand now mfd_cell devices can only use the resources
> that are statically defined in the code (and therefore not the ones in
> the
> ACPI nodes)...am I right?
> 
> Thanks
> Gab
> 
> >
> > >
> > > Also you don't need to modify acpi_default_enumeration() because
> you
> > > can
> > > mark your device enumerated in the MFD driver. So all the dirty
> > details
> > > will be in the MFD driver and not in ACPI core.
> >
> > Ok got it :)
> >
> > Cheers
> > Gab

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ