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]

Date:	Wed, 19 Jun 2013 15:13:11 +0300
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Cc:	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 Wed, Jun 19, 2013 at 11:56 AM, Alexey Brodkin
<Alexey.Brodkin@...opsys.com> wrote:
> Hi all,
>
> I've been trying to get "xsysace" driver working properly on ARC
> architecture.
> And I was able to get it built and running, but it required me to do 2
> changes - please refer to description below. Now I'd like to get this
> driver working for me righ from upstream sources and this is where my
> questions appear.
>
> While in general I believe any device driver should be easily build and
> then used on virtually any architecture I faced 2 issues with "xsysace":
>
> 1. It uses PPC/Microblaze specific accessors "{in|out}_{le|be}16".
> I sent a patch to this mailing list which replaces these custom
> accessors with common "ioread16{|be}" but a long discussion silently
> ended up with nothing (at least for proposed patch).
> Patch and discussion is available here:
> https://patchwork.kernel.org/patch/2062701/
>
> 2. Inverted logic in "ace_data{in|out}_{be|le}16".
> For example in "ace_dataout_le16" "out_be16" accessor is used which
> simply doesn't work for ARC. We need to have "le" accessor in "le"
> function and vice versa. Implementation of "be" ARC accessor with
> inverted logic doesn't help. Because "ace_{in|out}_{be|le}16" uses plain
> logic.
>
> So I'm wondering what is a best way for me to proceed?
>
> For (1) we may implement custom "{in|out}_{le|be}16" accessors, but is
> it a good way to go?
> For (2) I may expect that plain change of used accessor from "le" to
> "be" will break "xsysace" on PPC/Micropblaze.

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.

--
With Best Regards,
Andy Shevchenko
--
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/