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:	Sun, 26 Jul 2015 16:26:38 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	b38611@...escale.com
Cc:	netdev@...r.kernel.org, Frank.Li@...escale.com,
	stephen@...workplumber.org
Subject: Re: [PATCH v1 net-next 1/1] net: fec: add stop mode request on/off
 implemention

From: Fugang Duan <b38611@...escale.com>
Date: Wed, 22 Jul 2015 18:13:43 +0800

> The current driver depends on platform data to implement stop mode
> request on/off that call api pdata->sleep_mode_enable().
> 
> To reduce arch platform redundancy code, since the function only set
> SOC GPR register bit to request stop mode of/off, so we can move the
> function into driver. And the specifix GPR register offset and MASK
> bit can be transferred from DTS.
> 
> Signed-off-by: Fugang Duan <B38611@...escale.com>

Doesn't this break stop mode on those devices until the DTS is
updated?

That's really unfortunate, because you're leaving all of the platform
data and implementation there, yet it's going to be unused.

I really think you need to keep the code using the platform data bits
around until all the DTSs are updated.

No matter what you tell me about how DTSs are updated (don't even
mention the details, I do not care) you simply cannot keep the
platform data code around and not use it.  It is completely
nonsensible to have code that would properly function and properly
support a feature for the device in the kernel, yet not use it.

Period.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ