linux-kernel - Re: [PATCH 06/16] viafb: complete support for VX800/VX855 accelerated framebuffer

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: <20100409141834.4e45f18d@bike.lwn.net>
Date:	Fri, 9 Apr 2010 14:18:34 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	linux-kernel@...r.kernel.org, Harald Welte <laforge@...monks.org>,
	JosephChan@....com.tw, ScottFang@...tech.com.cn,
	Deepak Saxena <dsaxena@...top.org>,
	linux-fbdev-devel@...ts.sourceforge.net
Subject: Re: [PATCH 06/16] viafb: complete support for VX800/VX855
 accelerated framebuffer

On Fri, 09 Apr 2010 06:21:18 +0200
Florian Tobias Schandinat <FlorianSchandinat@....de> wrote:

> > +	for (i = 0; i <= highest_reg; i+= 4)
> > +		writel(0x0, engine + i);
> > +
> 
> this obsoletes
> 	/* Init 2D engine reg to reset 2D engine */
> 	writel(0x0, engine + VIA_REG_KEYCONTROL);
> as VIA_REG_KEYCONTROL is 0x02C.

Ah, good point, the separate write is superfluous.  Removed.


[...]
> > +#define VIA_REG_MONOPATBGC_M1   0x05C       /* Add FG color of Pattern. */
> > +#define VIA_REG_COLORPAT_M1     0x100       /* from 0x100 to 0x1ff */
> > +
> 
> All of these defines are unused. I admit that it is my fault. I've not 
> yet found a way I like to use them as the meaning of the same hardware 
> address changed. I think the most clean long term solution would be to 
> put the engines in separate files and the definitions in private headers 
> to at least avoid the need to decode the engine version in the name.
> However as the old headers already contain a bunch of trash feel free to 
> ignore this issue and add it for now.

Harald's initial patch included a mechanism for remapping register writes
on the fly depending on which engine was in use; these defines were used
for that purpose.  Your reworking of the 2D code obliterated that patch,
and made it mostly unnecessary.  I kept the defines around, though, because
I thought that documenting the registers can only be a good thing.

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/