linux-kernel - Re: [PATCH 10/11] viafb: rework the I2C support in the VIA framebuffer 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]

Message-ID: <20100424073359.349b4397@bike.lwn.net>
Date:	Sat, 24 Apr 2010 07:33:59 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	linux-kernel@...r.kernel.org, Harald Welte <laforge@...monks.org>,
	Deepak Saxena <dsaxena@...top.org>,
	linux-fbdev@...r.kernel.org, JosephChan@....com.tw,
	ScottFang@...tech.com.cn
Subject: Re: [PATCH 10/11] viafb: rework the I2C support in the VIA
 framebuffer driver

On Sat, 24 Apr 2010 12:47:34 +0200
Florian Tobias Schandinat <FlorianSchandinat@....de> wrote:

> I was able to narrow this issue down to the fourth bus. So with
> if (i == 4)
> 	continue;
> in the bus creation loop I'm able to get a working framebuffer which 
> does not have the issues mentioned. Any ideas what should be done now?

That is useful information indeed, thanks.

This patch creates an i2c bus on every port which could conceivably
have one.  That's rather different from the original code, which
created a single bus (in the kernel) then swapped it between ports 31
and 2c in weird ways.  In particular, it takes over ports which,
conceivably, somebody else could be using for GPIO.  So, perhaps, there
is some contention going on there.

If my hypothesis is correct, this problem will go away with the
application of the second series, which doesn't create i2c buses on
ports used for GPIO.  But the problem should be fixed here so we don't
have things broken in the middle.

Harald, does this reasoning make sense to you?  If so, what I should do
is bring forward just enough of the via-core code to be able to
configure which ports actually get i2c buses created on them.  Easily
done.

Thanks,

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