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:	Wed, 29 Jul 2009 12:58:17 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	Ian Molton <ian@...menth.co.uk>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	linux-kernel@...r.kernel.org, Pierre Ossman <drzeus@...eus.cx>,
	Magnus Damm <damm@...nsource.se>
Subject: Re: MMC: Make the configuration memory resource optional

On Wed, Jul 29, 2009 at 11:48:51AM +0900, Magnus Damm wrote:

> I understand that you want to have clocklib so you can manage clocks
> dynamically for your mfd drivers, but in our use case we already have
> working clock framework implementations withing our SoC. There is no
> need for any dynamic clock registration and unregistration. With that
> in mind it can't be very difficult to understand that there is no
> point for SoC vendors to work on clocklib. If's mainly an issue for
> mfd.

While it's true that this doesn't bother SoCs the fact that most clock
API implementations don't allow any off-chip drivers to register clocks
renders the clock API essentially unusable for fairly large parts of the
kernel.  This is especially problematic where the clocks cross from
the SoC domain to the off-SoC domain and clocks from each domain may be
used interchangably.

Looking at the original patch I'm not sure exactly why it runs into
clock API issues so I'm not sure if this is a relevant concern or not
here but I'm mentioning it since I'd kind of expect an impact on the
SoCs from addressing it due to the way the clock API functions are
currently provided.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ