linux-kernel - Re: [RFC/PATCH 3/3] mfd: twl4030-irq: implement bus

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Dec 2010 23:58:36 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Felipe Balbi <balbi@...com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	David Brownell <david-b@...bell.net>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC/PATCH 3/3] mfd: twl4030-irq: implement bus_*lock

On Tue, Dec 28, 2010 at 07:14:19PM +0200, Felipe Balbi wrote:

> +static void twl4030_sih_bus_sync_unlock(unsigned int irq)
> +{
> +       struct sih_agent        *agent = get_irq_chip_data(irq);
> +
> +       mutex_unlock(&agent->irq_lock);
> +}

I suspect you need to do some sort of sync with the hardware here - the
_sync bit of the name comes from the fact that the mask and unmask stuff
is still called with IRQs disabled and so can't touch and I2C chip, this
is called after reenabling them give a chance for the updates done to
be reflected in the hardware.  The implementation everyone else has done
is to update a register cache in the other functions then write that
out here before dropping the mutex.

>  static struct irq_chip twl4030_sih_irq_chip = {
>  	.name		= "twl4030",
>  	.mask		= twl4030_sih_mask,
>  	.unmask		= twl4030_sih_unmask,
>  	.set_type	= twl4030_sih_set_type,
> +	.bus_lock	= twl4030_sih_bus_lock,
> +	.bus_sync_unlock = twl4030_sih_bus_sync_unlock,
>  };

I just realised that this collides with the conversion to the irq_
versions that has been done on the driver in -next by either myself or
Lennart (we both submitted essentially the same patches and a couple of
his went in) - that was a purely mechanical conversion that didn't
address any of the issues this patch addresses but they're touching the
same code.
--
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/