On Thu, Feb 20, 2020 at 11:47:41AM -0800, John Stultz wrote:
On Thu, Feb 20, 2020 at 11:15 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Fri, Feb 21, 2020 at 01:37:04AM +0800, Orson Zhai wrote:
This reverts commit 4585fbcb5331fc910b7e553ad3efd0dd7b320d14.
The name changing as devfreq(X) breaks some user space applications, such as Android HAL from Unisoc and Hikey [1]. The device name will be changed unexpectly after every boot depending on module init sequence. It will make trouble to setup some system configuration like selinux for Android.
So we'd like to revert it back to old naming rule before any better way being found.
[1] https://lkml.org/lkml/2018/5/8/1042
Cc: John Stultz john.stultz@linaro.org Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: stable@vger.kernel.org Signed-off-by: Orson Zhai orson.unisoc@gmail.com
drivers/devfreq/devfreq.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index cceee8b..7dcf209 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -738,7 +738,6 @@ struct devfreq *devfreq_add_device(struct device *dev, { struct devfreq *devfreq; struct devfreq_governor *governor;
static atomic_t devfreq_no = ATOMIC_INIT(-1); int err = 0; if (!dev || !profile || !governor_name) {@@ -800,8 +799,7 @@ struct devfreq *devfreq_add_device(struct device *dev, devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev); atomic_set(&devfreq->suspend_count, 0);
dev_set_name(&devfreq->dev, "devfreq%d",atomic_inc_return(&devfreq_no));
dev_set_name(&devfreq->dev, "%s", dev_name(dev)); err = device_register(&devfreq->dev); if (err) { mutex_unlock(&devfreq->lock);-- 2.7.4
Thanks for this, I agree, this needs to get back to the way things were as it seems to break too many existing systems as-is.
I'll queue this up in my tree now, thanks.
Oof this old thing. I unfortunately didn't get back to look at the devfreq name node issue or the compatibility links, since the impact of the regression (breaking the powerHAL's interactions with the gpu) wasn't as big as other problems we had. While the regression was frustrating, my only hesitancy at this point is that its been this way since 4.10, so reverting the problematic patch is likely to break any new users since then.
4.11 :)