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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 02 Jul 2018 15:58:26 +0200
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Leonard Crestez <leonard.crestez@....com>
Cc:     dl-linux-imx <linux-imx@....com>,
        "A.s. Dong" <aisheng.dong@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Fabio Estevam <fabio.estevam@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "andrew.smirnov@...il.com" <andrew.smirnov@...il.com>,
        Anson Huang <anson.huang@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Robin Gong <yibin.gong@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: Re: [PATCH 0/2] soc: imx: gpc: Power off PU domain in
 suspend/resume on 6qp

Am Montag, den 02.07.2018, 13:49 +0000 schrieb Leonard Crestez:
> On Mon, 2018-07-02 at 14:15 +0200, Lucas Stach wrote:
> > Am Montag, den 02.07.2018, 14:52 +0300 schrieb Leonard Crestez:
> > > With current code (even without my patches) attempting to dynamically
> > > remove/probe the GPC fils since since the per-pgc platform_device
> > > instances are not removed. I'm trying something like this:
> > > 
> > > echo 130000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> > > echo 134000.gpu > /sys/bus/platform/drivers/etnaviv-gpu/unbind
> > > echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/unbind
> > > echo 20dc000.gpc  > /sys/bus/platform/drivers/imx-gpc/bind
> > > 
> > > But is there any usecase for dynamically removing the GPC? Instead of
> > > trying to fix it I'd rather delete imx_gpc_driver.remove, just like
> > > for gpcv2. Would anyone object to a patch doing this?
> > 
> > Yes, as this is taking things in wrong direction. With device-links we
> > are able to unbind consumer devices when a provider is removed. As the
> > GPC is a consumer of a regulator, not having the ability to unbind it
> > would break that use case.
> 
> The GPC is a "consumer" of the LDO regulators which are built into the
> SOC. Why would you want to unbind any of this stuff?

Which in turn might be consumers of external regulators, which may have
a module driver that can be reloaded by the user at will.

> I don't understand the usecase, maybe you can elaborate?

You could make that argument for almost every device on a SoC, yet the
explicit default in Linux is for device drivers to be hot-pluggable.

Anything that changes the system layout at Linux runtime, like
devicetree overlays or dynamic system partition solutions like
Jailhouse depend on driver/device hotplug to work. I know that there
are quite a few bugs in this area, because it's less tested than other
code paths, but I'm unwilling to accept that we are actively going in
the direction of breaking this stuff.

Regards,
Lucas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ