linux-kernel - Re: xilinx_spi in linux-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>] [day] [month] [year] [list]

Date:	Thu, 4 Feb 2010 07:36:05 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Richard Röjfors <richard.rojfors@...agicore.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-embedded@...r.kernel.org
Subject: Re: xilinx_spi in linux-next

[cc'ing linux-kernel & linux-embedded]

On Thu, Feb 4, 2010 at 2:07 AM, Richard Röjfors
<richard.rojfors@...agicore.com> wrote:
> On 02/04/2010 05:14 AM, Andrew Morton wrote:
>>
>> Breaks sparc64 allmodconfig:
>>
>>
>> drivers/spi/xilinx_spi.c: In function `xspi_write32_be':
>> drivers/spi/xilinx_spi.c:108: error: implicit declaration of function
>> `iowrite32be'
>> drivers/spi/xilinx_spi.c: In function `xspi_read32_be':
>> drivers/spi/xilinx_spi.c:113: error: implicit declaration of function
>> `ioread32be'
>
> I did a quick grep in the sparc's arch tree and the big endian versions of
> io(read/write) are not implemented. So the driver can not be compiled on
> sparc,
> I think we have to put harder limits in the Kconfig. The driver has not
> worked on sparc
> before anyway.

I can easily tighten up the Kconfig limits (ARM has the same problem),
but I'd like to know what the right thing to do here is to write a
portable driver.  This device is implemented on a Xilinx FPGA, so it
is totally feasable it to be wired up to any architecture, especially
on embedded stuff.  So far it works with PowerPC, Microblaze and x86,
and it will most likely show up on ARM in the near future.

The most likely deviation is byte lane ordering either being big or
little endian, hence the driver using both io{read,write}32() and
io{read,write}32be(), but the 'be' variants aren't implemented on all
architectures.  What's a driver author to do when trying to write
portable code?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/