linux-kernel - RE: [PATCH 2/3] regulator-core: update all enable GPIO state in

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <A874F61F95741C4A9BA573A70FE3998F69E1BD93@DQHE02.ent.ti.com>
Date:	Mon, 21 Jan 2013 23:59:11 +0000
From:	"Kim, Milo" <Milo.Kim@...com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Axel Lin <axel.lin@...ics.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>
Subject: RE: [PATCH 2/3] regulator-core: update all enable GPIO state in
	_enable/disable

> > OK, the consumer just cares about the regulator(s) which is(are)
> obtained.
> > However it doesn't show exact state of regulator in case that enable
> GPIOs are
> > shared.
> 
> It would do if my suggestion that we use a shared state for the GPIO
> were implemented!
> 
> > (6) CB tries to get the state of LDO3 before disabling it,
> > regulator_is_enabled() returns 1, but real state is 0.
> 
> > 	if(!regulator_is_enabled(rdev))
> > 		regulator_disable(rdev);
> 
> > 	Therefore CB never disables LDO3, use_count is always 1.
> 
> > This patch solves this unmatched situation.
> 
> This is just a buggy consumer - the consumer would also break if there
> were a single regulator shared by two consumers.  There's almost no
> case
> outside of bootstrapping where it makes sense to check if the regulator
> is enabled for anything other than diagnostics.
> 
> > Regulator APIs may show unmatched value, but it can be handled in
> each consumer
> > driver *separately*.
> > Therefore, we should not update 'ena_gpio_state' of other regulators.
> > This patch should be ignored.
> > Is that correct?
> 
> No, we need to reference count over all the regualtors sharing the
> enable line.  Otherwise we won't pay attention to references held by
> anything other than the regulator currently being enabled or disabled.

Updated patch-set was sent recently.

  [PATCH v2 1/4] regulator-core: support shared enable GPIO concept
  https://lkml.org/lkml/2013/1/14/564

  [PATCH v2 2/4] regulator-core: manage enable GPIO list
  https://lkml.org/lkml/2013/1/14/565

  [PATCH v2 3/4] regulator-core: free requested GPIOs and manage the enable list
  https://lkml.org/lkml/2013/1/14/567

  [PATCH v2 4/4] lp8788-ldo: use ena_pin of regulator-core for external control
  https://lkml.org/lkml/2013/1/14/566

I'd like to get some feedback from you.
Thank you.

Best Regards,
Milo
--
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/