linux-kernel - Re: [PATCH V3 1/2] mfd: add TI TPS80031 mfd core driver

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:	Tue, 13 Nov 2012 21:35:45 -0500
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"lrg@...com" <lrg@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 1/2] mfd: add TI TPS80031 mfd core driver

On 11/13/2012 08:22 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Tue, Nov 13, 2012 at 11:18:34PM +0530, Laxman Dewangan wrote:
>> On Tuesday 13 November 2012 01:16 PM, Mark Brown wrote:
>>> I'm not sure your wake_base setting is sane here - this is expected to
>>> be a register.  If it is a register why is it not a #define?
>> There is no wake register. Here I kept for the incerease the wake
>> conut so that irq_set_irq_wake() can be called.
> So you want to write to random registers in the chip instead...  that
> doesn't seem like a terribly clever idea.

Yes, this is not a good idea, We will need support for wakeup without 
wakeup registers.
Probably we need to add one more parameter, wake enable to control 
without wake_base.


>
>> I think it is also not correct after change
>> regmap: irq: initialize all irqs to wake disabled
>> I need to set the irq_wake(0 without the register.
> I can't really parse any of the above, sorry.
>
>> There is 2 sets of registers which need to be configure, MASK and
>> LINE enable.
> So what does the second one do?


The MASK register used for updating status register when interrupt 
occurs and LINE register used to pass the status to actual interrupt line.
As per datasheet:

When INT_MSK_LINE [i] is set to 1, the associated interrupt number i is 
INT line masked, which means that no interrupt is generated on the INT line.
When INT_MSK_LINE [i] is set to 0, the associated interrupt number i is  
line enabled: An interrupt is generated on the INT line.
In any case, the INT_STS [i] status bit may or may not be updated, only 
linked to the INT_MSK_STS [i] configuration register bit.


When INT_MSK_STS [i] is set to 1, the associated interrupt number i is
status masked, which means that no interrupt is stored in the INT_STS 
[i]status bit. Note that no interrupt number i is generated on the INT 
line, even if the INT_MSK_LINE [i] register bit is set to 0.
When INT_MSK_STS [i] is set to 0, the associated interrupt number i is 
status enabled: An interrupt status is updated in the INT_STS [i] register.
The interrupt may or may not be generated on the INT line, depending on 
the INT_MSK_LINE [i] configuration register bit.
--
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/