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]

Message-ID: <20160525104103.GV8206@sirena.org.uk>
Date:	Wed, 25 May 2016 11:41:03 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Meng Yi <meng.yi@....com>
Cc:	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	David Airlie <airlied@...ux.ie>,
	Stefan Agner <stefan@...er.ch>,
	"airlied@...hat.com" <airlied@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: fsl-dcu not works on latest "drm-next"

On Wed, May 25, 2016 at 09:59:39AM +0000, Meng Yi wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> 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.

You've not specifically described the problem here - what are the
endiannesses of both the CPU and the device you're talking to?  What
specifically is the endianess problem you are seeing, what are you
seeing and what do you expect to see?

> I am not familiar with regmap, can you give some advices?

Is the device described in the DT or regmap_config as having the
endianess that it actually has?  

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