Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1347919 > unrolled thread

Re: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to amba_match()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to amba_match() Ulf Hansson <ulf.hansson@linaro.org> - 2016-03-02 11:20 +0100

#1347919 — Re: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to amba_match()

On 17 February 2016 at 21:08, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 17, 2016 at 08:52:36AM +0100, Marek Szyprowski wrote:
>> Then the only solution right now I see is to get back to v1:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388199.html
>> which at least handles correctly device registration when power domain
>> driver is available.
>
> ... and which has the ability to break platforms if the PM domain is
> not already available.
>
> What's wrong with the patch in the link above _combined_ with a patch
> which addresses the concern I have with that patch: build a list of
> the failed-to-register devices, and retry them later - maybe from a
> late_initcall(), or a similar mechanism?

This will improve the robustness of the device registration process,
but I wonder if it's really worth the efforts of complicating the amba
device registration code.

The problem I see with such approach, is to know *when* shall we retry
to register the devices.

We will rely on the PM domain driver to be probed, as to have the
corresponding OF genpd provider registered, else the device
registration will continue to fail.
Now, I don't think there are PM domain drivers as removable modules
(yet), but in such cases a late_initcall won't help much.

>
> My view is the risk to existing systems is _too_ high to apply either
> this patch, or the patch you link to above, and I refuse to play the
> "lets apply it and see if we break anything" lottery with this.

I agree!

Although I think with some adjustments, perhaps we can move forward with v1?

The adjustments I think is needed:
Instead of propagating the error code from dev_pm_domain_attach(),
let's print a debug message and continue the device registration.
In that way, we shouldn't introduce regressions for cases where the OF
genpd provider hasn't yet been registered, but the issue Marek is
trying to solve for Exynos should be fixed.

What do you think?

Kind regards
Uffe

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web