linux-kernel - Re: Nokia N900 - audio TPA6130A2 problems

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]

Message-ID: <20160306152339.GA428@earth>
Date:	Sun, 6 Mar 2016 16:23:39 +0100
From:	Sebastian Reichel <sre@...nel.org>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	Peter Ujfalusi <peter.ujfalusi@...com>,
	Jarkko Nikula <jarkko.nikula@...mer.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Pavel Machek <pavel@....cz>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Tony Lindgren <tony@...mide.com>, Nishanth Menon <nm@...com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	merlijn@...zup.org
Subject: Re: Nokia N900 - audio TPA6130A2 problems

Hi Pali,

On Tue, Jan 05, 2016 at 12:34:12AM +0100, Pali Rohár wrote:
> On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote:
> > On 08/03/2015 09:48 PM, Jarkko Nikula wrote:
> > > It is well possible that some regression got introduced to
> > > TPA6130A2 I2C communication over the years without nobody than you
> > > now notices. We used to do QA back in Meego N900 days but that was
> > > pre 3.x kernels.
> > 
> > No major changes has been done to the tpa driver during the past
> > years... I wanted to do some updates, like moving it to regmap, but
> > as you said, n900 is the only user (and n9) and I do not feel
> > comfortable to hack on a device where I do not have serial
> > console... And I'm using the n900 time to time also.
> > 
> > >> So maybe something similar? Kernel expects that some PM or
> > >> regulator parts are initialized, but they are only sometimes?
> > >> Just speculation...
> > > 
> > > I'm thinking the same. I could figure SCL could be stuck low if TPA
> > > or some other chip connected to the same I2C bus is without power
> > > and is pulling I2C signals down.
> > 
> > What would happen with the SCL stuck on i2c.2 bus if you remove the
> > tpa driver from the kernel? If you remove the other drivers for the
> > devices on i2c.2?
> 
> Hi Peter and Jarkko! Do you have some code samples for testing? Or 
> something else which I can test? This problem is still reproducible on 
> more N900 devices and I would like to see it fixed.

I have not seen your error with N900, but while working on N950 I
noticed similar problems when I added lp5523. I think the lp5523
reset routine locks up the omap i2c controller, since the lp5523
will stop responding in the middle of an ongoing communication:

static void lp55xx_reset_device(struct lp55xx_chip *chip)
{
	struct lp55xx_device_config *cfg = chip->cfg;
	u8 addr = cfg->reset.addr;
	u8 val  = cfg->reset.val;

	/* no error checking here because no ACK from the device after reset */
	lp55xx_write(chip, addr, val);
}

Since tpa6130a2 is on the same i2c bus, it would be affected by
this. You can check this by just commenting out the call to
lp55xx_reset_device() in the probe function, since it's not
needed on N900 (chip reset is done via enable gpio anyways).

I'm pretty sure, there were no bus lock problems when I added
lp5523 to N900 dts, so this having problems with this is probably
a regression in the omap-i2c driver.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)