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:	Thu, 25 Apr 2013 23:20:53 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Yijing Wang <wangyijing@...wei.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Huang Ying <ying.huang@...el.com>,
	David Bulkow <David.Bulkow@...atus.com>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiang Liu <jiang.liu@...wei.com>
Subject: Re: [PATCH] PCI: Remove duplicate pci_disable_device for pcie port

On Thu, Apr 25, 2013 at 9:02 PM, Yijing Wang <wangyijing@...wei.com> wrote:
> Hi Yinghai,
>    We should not remove this additional pci_disable_device().
> Because we enable pcie port device twice before. The first is pci_enable_brides(),
> in x86, it was called in pci_assign_unassigned_resources(). The second in pcie_port_device_register().
> So we should call pci_disable_device() twice for pci_dev->enable_cnt balance.
>
> But there is still a problem here. If we unbind a pcie port device pcie port driver, we can not
> use its child devices again, because this pcie port device was disabled absolutely.
>
> So I think we should move the second pci_disable_device() to remove.c.
>
> I sent this patch to Bjorn and following is Bjorn reply
> "And it's not clear to me whether unbinding the
> pcie port driver should disable the bridge at all.  I think one could
> argue that the bridge should remain functional even if the driver is
> unloaded, because the PCI core *enables* the bridge even if the driver
> is never loaded."
>
> Yinghai, how do you think about this issue?

1. we always enable bridges after assign unassigned resource for boot path
and hotplug path.
we should never call disable for that.

2. driver should be keep enable/disable during probe/remove

looks like we need to rethink pci enable bridge.

if we want to enable one pci device, we should go up  to enable all bridges till
root.

let if we disable one pci device, we need to go up to disable bridge if its all
pci device children get disabled.

if there is pci driver is bound with bridge device, those
disable/enable bridge should be skipped.

Thanks

Yinghai
--
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