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:	Mon, 27 Jul 2015 01:27:40 +0000
From:	Duan Andy <fugang.duan@...escale.com>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Li Frank <Frank.Li@...escale.com>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>
Subject: RE: [PATCH v1 net-next 1/1] net: fec: add stop mode request on/off
 implemention

From: David Miller <davem@...emloft.net> Sent: Monday, July 27, 2015 7:27 AM
> To: Duan Fugang-B38611
> Cc: netdev@...r.kernel.org; Li Frank-B20596; 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.

Thanks for your comments.

Firstly, I will send some board dts patches (and test).
Secondly, the net/next tree have no platform data for stop mode because others suggest us to use dts not platform data, and there have no any boards support stop mode in net/next, so this doesn't break any boards in net/next.

Regards,
Andy
--
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