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: <CAL_JsqJnOWcydUmkjrs-0DjpbhJytyA1zw8c8Ue7-W6PNY4CnA@mail.gmail.com>
Date: Fri, 19 Jan 2024 10:45:04 -0600
From: Rob Herring <robh+dt@...nel.org>
To: Lukas Wunner <lukas@...ner.de>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, 
	Kalle Valo <kvalo@...nel.org>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Heiko Stuebner <heiko@...ech.de>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Chris Morgan <macromorgan@...mail.com>, 
	Linus Walleij <linus.walleij@...aro.org>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Arnd Bergmann <arnd@...db.de>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Nícolas F . R . A . Prado <nfraprado@...labora.com>, 
	Marek Szyprowski <m.szyprowski@...sung.com>, Peng Fan <peng.fan@....com>, 
	Robert Richter <rrichter@....com>, Dan Williams <dan.j.williams@...el.com>, 
	Jonathan Cameron <Jonathan.Cameron@...wei.com>, Terry Bowman <terry.bowman@....com>, 
	Huacai Chen <chenhuacai@...nel.org>, Alex Elder <elder@...aro.org>, 
	Srini Kandagatla <srinivas.kandagatla@...aro.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Abel Vesa <abel.vesa@...aro.org>, 
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-pci@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 0/9] PCI: introduce the concept of power sequencing of
 PCIe devices

On Fri, Jan 19, 2024 at 10:34 AM Lukas Wunner <lukas@...ner.de> wrote:
>
> On Fri, Jan 19, 2024 at 12:52:00PM +0100, Bartosz Golaszewski wrote:
> > We have two separate issues: one is powering-up a PCI device so that
> > it can be detected
>
> Just wondering, I note in really_probe() we configure the pin controller,
> active the pm_domain etc before probing a driver.
>
> Would it make sense for the issue you mention above to similarly
> amend pci_scan_device() to enable whatever clocks or regulators
> are described in the devicetree as providers for the given PCI device?

If you mean via a callback to some device specific code, then yes, I
think that's exactly what should be done here. That's roughly what
MDIO does. If firmware says there is a device present, then probe it
anyways even if not detected. I don't think that will work for PCI
because it accesses a lot of registers before probe. We'd need some
sort of pre-probe hook instead called after reading vendor and device
ID, but before anything else.

If you mean PCI core just enable whatever clocks and regulators (and
GPIOs), then no, because what is the correct order and timing for each
of those? You don't know because that is device specific information
just as how to program a device is.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ