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] [day] [month] [year] [list]
Date:	Mon, 5 Aug 2013 03:32:23 -0700
From:	Bill Huang <bilhuang@...dia.com>
To:	Nishanth Menon <nm@...com>
CC:	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"swarren@...dotorg.org" <swarren@...dotorg.org>,
	"ian.campbell@...rix.com" <ian.campbell@...rix.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"lee.jones@...aro.org" <lee.jones@...aro.org>,
	"broonie@...aro.org" <broonie@...aro.org>,
	"j-keerthy@...com" <j-keerthy@...com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"ian@...mlogic.co.uk" <ian@...mlogic.co.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mallikarjun Kasoju <mkasoju@...dia.com>
Subject: Re: [PATCH v2 1/1] mfd: palmas: Add power off control

On Fri, 2013-08-02 at 22:39 +0800, Nishanth Menon wrote:
> On 08/02/2013 12:45 AM, Bill Huang wrote:
> > On Thu, 2013-08-01 at 21:08 +0800, Nishanth Menon wrote:
> >> On 04:08-20130801, Bill Huang wrote:
> >>> On Wed, 2013-07-31 at 19:57 +0800, Nishanth Menon wrote:
> >>>>
> >>>> If you notice the reference code I send, atleast on TWL6035/37 variants
> >>>> of Palmas, USB IRQ unmask is mandatory for power on with USB cable -
> >>>> example usage scenario: extremely low battery, device powered off, plug
> >>>> in usb cable to restart charging - you'd like to initiate charging logic
> >>>> in bootloader, but that wont work if the device does not do OFF-ON
> >>>> transition with usb cable plugged in for vbus.
> >>>>
> >>> Why do we need to add Palmas USB_IRQ unmask logic in shutdown? Does that
> >>> mean for all platform using Palmas has to unmask USB IRQ (including
> >>> those do not power vbus through Palmas)? Can't we just have a simple
> >>> shutdown function but have the VBus programming been done in USB driver
> >>> or maybe platform driver since it is platform specific control?
> >> we dont have a irq cleanup, irq handling is done in palmas-mfd. Further,
> >>
> >> Why would USB driver care about vbus supply needs in complete power off
> >> - it is the job of palmas driver? Further, palmas-mfd shutdown
> >> handler(currently missing) if probably cleansup things:
> >>
> >>   mfd_remove_devices(palmas->dev);
> >>    palmas_irq_exit(palmas);
> >>
> >> shutdown sequence becomes complicated further esp if things are
> >> cleanedup in shutdown (Dummy patch[1]).
> >>
> >>
> >> All I am saying is this: shutdown should allow powerup functionality to
> >> work as well, how we do that is upto us - I personally found it a little
> >> easier to keep the IRQ unmask in shutdown easier to deal with, but other
> >> options might be possible as well.
> >
> > I'm not sure if I understand your comments completely (maybe due to I'm
> > not familiar with the mechanism of unmasking USB IRQ in Palmas driver)
> 
> This is IMHO an weird configuration I saw on TWL6035/6037 Palmas device 
> - so I suspect should be the case in probably other palmas devices as 
> well. I hit power off, and I can start up the device again by supplying 
> vbus -(usecase was, at that point in time, battery charging)
> 
> anyways, I was working with busybox and no usb driver even enabled, but 
> I am told by the twl6035/7 support folks that due to design USB IRQ 
> needs to be unmasked at shutdown/poweroff to allow OFF->ON transition 
> sequence to start inside Palmas when vbus is supplied.
> 
> 
> > but doing cleanup in each driver shutdown handler makes sense to me, if
> > those clean up can be done in shutdown then we can make power off
> > function as simple as possible and being part of Palmas mfd driver?
> 
> not really, mfd shutdown does not guarantee rest of the drivers' 
> shutdown functions are safely called, pm_power_off unfortunately is the 
> only "official point" where we can safely and cleanly shutdown the system.
> 
It looks to me whether or not adding those extra control in a generic
Palmas driver is still in doubt, will you send your patch for this in
the near future? If not, any objection on making it as a basic and
simple power off control (that said, any further processing which has to
be in power off routine can be added on top of that, or can be moved to
be under drivers/reset if needed) using the existing mechanism?


--
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