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

From: Andy Shevchenko
Date: Wed Jun 19 2013 - 08:13:18 EST


On Wed, Jun 19, 2013 at 11:56 AM, Alexey Brodkin
<Alexey.Brodkin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/