linux-kernel - Re: fsl-dcu not works on latest "drm-next"

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:	Wed, 25 May 2016 14:16:20 +0200
From:	Alexander Stein <alexander.stein@...tec-electronic.com>
To:	Meng Yi <meng.yi@....com>
Cc:	Stefan Agner <stefan@...er.ch>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	David Airlie <airlied@...ux.ie>,
	"airlied@...hat.com" <airlied@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>
Subject: Re: fsl-dcu not works on latest "drm-next"

On Wednesday 25 May 2016 10:25:29, Meng Yi wrote:
> Hi Alexander,
> Thanks for your reply.
> 
> > Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> > commit in my repo. Both touch only i915 related things. Please do a proper
> > bisect and name the offending commit. On which commit you got that
> > backtrace BTW?
> > From your backtrace I can't see anything related to regmap.
> 
> It is weird that using bisect, for the commit log is not linear.
> I mean a newer date commit may be merged before an older date commit, when
> jump to that older date commit, the newer one will be lost, even though it
> is merged before older one. So, I think it's difficult to use git bisect.
> " d761701c55a99598477f3cb25c03d939a7711e74 " is just an older one, I mean
> between this commit and the next commit, maybe lots of commits are lost.
> So, it looks like this commit have nothing to do with the problem.

Why are commits lost? The order of commit dates is not straightforward, yes, 
but that's not a problem at all.

> According to the backtrace, looks like the vblank interrupt is not happen or
>  handled. Then I found the irq is installed successfully, so the problem
> seems like the vblank irq is not properly setup. And here is the point ,
> irq initia, irq handler and timing control code are using regmap.

>From your backtrace I guess wait_event_timeout is called in some atomic 
context (might_sleep(); is called inside wait_event_timeout). This has nothing 
to do with regmap.

> I read out the value of relevant register using "CodeWarrior TAP", find that
> endianness is not right.
> 
> Then I changed endianness of the value to be written that using "
> regmap_write" . It works. But "regmap_update_bits" still have the problem.
> 
> I had checked log of regmap, and didn't find which commit caused that.

The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923 
("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The commits 
9f9f8b863ad130ec0c25f378bdbad64ba71291de, 
4f7d6dd4df8b388e2056c89b528254cdd79dea2a and 
0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I could 
successfully probe DCU.

Best regards,
Alexander