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:	Thu, 28 Apr 2011 13:27:46 +0300
From:	Sakari Ailus <sakari.ailus@...ia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	kalle.jokiniemi@...ia.com, lrg@...mlogic.co.uk,
	mchehab@...radead.org, svarbatov@...sol.com, saaguirre@...com,
	grosikopulos@...sol.com, vimarsh.zutshi@...ia.com,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	laurent.pinchart@...asonboard.com
Subject: Re: [RFC] Regulator state after regulator_get

Mark Brown wrote:
> On Thu, Apr 28, 2011 at 09:44:10AM +0000, kalle.jokiniemi@...ia.com wrote:
> 
>>  > Another alternative to the first option you proposed could be to add a
>>  > flags field to regulator_consumer_supply, and use a flag to recognise
>>  > regulators which need to be disabled during initialisation. The flag
>>  > could be set by using a new macro e.g. REGULATOR_SUPPLY_NASTY() when
>>  > defining the regulator.
> 
>> This sounds like a good option actually. Liam, Mark, any opinions?
> 
> I'm not sure what "supply_nasty" would mean?  This also doesn't seem
> like something that we can set up per supply - it's going to affect the
> whole regulator state, it's not something that only affects a single
> supply.

supply_nasty() would be used to define a regulator which is enabled by
the boot loader when it shouldn't be, which is the actual problem.

We have a regulator which is enabled by the boot loader. However, this
regulator shouldn't be on at boot since it's not needed by any devices
--- the drivers for those devices will use proper regulator framework
calls to use the regulator when it's needed. There's no chance to have
the boot loader fixed, as stated by Kalle.

How should this regulator be turned off in the boot by the kernel?

Regards,

-- 
Sakari Ailus
sakari.ailus@...well.research.nokia.com
--
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