linux-kernel - Re: xsysace driver support on arches other than PPC/Microblaze

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: <4881796E12491D4BB15146FE0209CE643F5F15DE@DE02WEMBXB.internal.synopsys.com>
Date:	Wed, 19 Jun 2013 12:56:37 +0000
From:	Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
CC:	Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>, Michal Simek <monstr@...str.eu>,
	Grant Likely <grant.likely@...retlab.ca>,
	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Geert Uytterhoeven" <geert@...ux-m68k.org>,
	"dahinds@...rs.sourceforge.net" <dahinds@...rs.sourceforge.net>,
	Mischa Jonker <Mischa.Jonker@...opsys.com>
Subject: Re: xsysace driver support on arches other than PPC/Microblaze

On 06/19/2013 04:13 PM, Andy Shevchenko wrote:
> On Wed, Jun 19, 2013 at 11:56 AM, Alexey Brodkin
> <Alexey.Brodkin@...opsys.com> wrote:
[]
> If you have a way to detect endianess run-time then you have to
> introduce kinda ops structure
>
> struct access {
>   .read = read_func(),
>   .write = write_func(),
> };
>
> ops_le = {...};
> ops_be = {...};
>
> And provide a pointer to the chosen structure.
>
> If there no posibility to get it run-time, use kernel config option.
>
> I wonder if there is any "modern" way to do such things.

Andy, if I understand your idea correctly then this kind of 
functionality is already there.

============
static struct ace_reg_ops ace_reg_be16_ops = {
	.in = ace_in_be16,
	.out = ace_out_be16,
	.datain = ace_datain_be16,
	.dataout = ace_dataout_be16,
};

static struct ace_reg_ops ace_reg_le16_ops = {
	.in = ace_in_le16,
	.out = ace_out_le16,
	.datain = ace_datain_le16,
	.dataout = ace_dataout_le16,
};
============
And in run-time we select which one to use. So no problem here.

The problem I'm facing there is a bit more complex.

Please refer to an extract below:
============
static void ace_out_be16(struct ace_device *ace, int reg, u16 val)
{
	out_be16(ace->baseaddr + reg, val);
}

static void ace_dataout_be16(struct ace_device *ace)
{
	int i = ACE_FIFO_SIZE / 2;
	u16 *src = ace->data_ptr;
	while (i--)
		out_le16(ace->baseaddr + 0x40, *src++);
	ace->data_ptr = src;
}
============

 From it you may see that one high-level big-endian accessor 
("ace_out_be16") uses big-endian low-level accessor ("out_be16") while 
another high-level big-endian accessor ("ace_dataout_be16") uses 
little-endian low-level accessor ("out_be16").

It seems like access to 16-bit data words should be done always with LE 
accessors (after all it's always just a window to a device's memory).

-Alexey




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