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]
Date:	Fri, 29 Mar 2013 17:18:05 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Whitehead <mwhitehe@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCH 2/2] eisa, PCI: init eisa early before pnp step in

On Fri, Mar 29, 2013 at 3:22 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> [+cc Rafael, just FYI since it involves PNP resources]
>
> On Wed, Mar 27, 2013 at 10:28 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> Mathhew reported kernels fail the pci_eisa probe and are later successful
>> with the virtual_eisa_root_init force probe without slot0.
>>
>> The reason for that is: pnp probing is early than pci_eisa_init get called
>> as pci_eisa_init is called via pci_driver.
>>
>> pnp 00:0f has 0xc80 - 0xc84 reserved.
>> [    9.700409] pnp 00:0f: [io  0x0c80-0x0c84]
>>
>> so eisa_probe will fail from pci_eisa_init
>>                                 ==>eisa_root_register
>>                                         ==>eisa_probe path.
>> as force_probe is not set in pci_eisa_root, it will bail early when
>> slot0 is not probed and initialized.
>>
>> Try to use subsys_initcall_sync instead, and will keep following sequence:
>>         pci_subsys_init
>>         pci_eisa_init_early
>>         pnpacpi_init/isapnp_init
>
> Is this a regression?  This must have worked at one time, but it seems
> like we've had pnpacpi_init/isapnp_init/pnpbios_init before PCI
> drivers for quite a while.

Yes.

>
>> After this patch eisa can be initialized properly, and pnp overlapping
>> resource will not be reserved.
>> [   10.104434] system 00:0f: [io  0x0c80-0x0c84] could not be reserved
>
> I think we should add logging in eisa_request_resources() similar to
> what drivers/pnp/system.c does so it's more clear what resources EISA
> is using.

Those eisa resource does get registered into io port resource tree.

>
>> Reported-by: Matthew Whitehead <mwhitehe@...hat.com>
>> Tested-by: Matthew Whitehead <mwhitehe@...hat.com>
>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>> Cc: stable@...nel.org
>>
>> ---
>>  drivers/eisa/pci_eisa.c |   41 ++++++++++++++++++++++-------------------
>>  1 file changed, 22 insertions(+), 19 deletions(-)
>>
>> Index: linux-2.6/drivers/eisa/pci_eisa.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/eisa/pci_eisa.c
>> +++ linux-2.6/drivers/eisa/pci_eisa.c
>> @@ -19,8 +19,7 @@
>>  /* There is only *one* pci_eisa device per machine, right ? */
>>  static struct eisa_root_device pci_eisa_root;
>>
>> -static int __init pci_eisa_init(struct pci_dev *pdev,
>> -                               const struct pci_device_id *ent)
>> +static int __init pci_eisa_init(struct pci_dev *pdev)
>>  {
>>         int rc, n = 0;
>>         struct resource *bus_res;
>> @@ -49,22 +48,26 @@ static int __init pci_eisa_init(struct p
>>         return 0;
>>  }
>>
>> -static struct pci_device_id pci_eisa_pci_tbl[] = {
>> -       { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
>> -         PCI_CLASS_BRIDGE_EISA << 8, 0xffff00, 0 },
>> -       { 0, }
>> -};
>> -
>> -static struct pci_driver __refdata pci_eisa_driver = {
>> -       .name           = "pci_eisa",
>> -       .id_table       = pci_eisa_pci_tbl,
>> -       .probe          = pci_eisa_init,
>> -};
>> -
>> -static int __init pci_eisa_init_module (void)
>> +/*
>> + * We have to call pci_eisa_init_early() before pnpacpi_init()/isapnp_init().
>> + *   Otherwise pnp resource will get enabled early and could prevent eisa
>> + *   to be initialized.
>> + * Also need to make sure pci_eisa_init_early() is called after
>> + * x86/pci_subsys_init().
>> + * So need to use subsys_initcall_sync with it.
>> + */
>> +static int __init pci_eisa_init_early(void)
>>  {
>> -       return pci_register_driver (&pci_eisa_driver);
>> -}
>> +       struct pci_dev *dev = NULL;
>> +       int ret;
>> +
>> +       for_each_pci_dev(dev)
>> +               if ((dev->class >> 8) == PCI_CLASS_BRIDGE_EISA) {
>> +                       ret = pci_eisa_init(dev);
>> +                       if (ret)
>> +                               return ret;
>> +               }
>>
>> -device_initcall(pci_eisa_init_module);
>> -MODULE_DEVICE_TABLE(pci, pci_eisa_pci_tbl);
>> +       return 0;
>> +}
>> +subsys_initcall_sync(pci_eisa_init_early);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ