linux-kernel - Re: [spi-devel-general] [patch 05/14] mfd: PCAP2 driver

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: <1227423962.3148.74.camel@brutus>
Date:	Sun, 23 Nov 2008 05:06:02 -0200
From:	Daniel Ribeiro <drwyrm@...il.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Stefan Schmidt <stefan@...enfreihafen.org>,
	spi-devel-general@...ts.sourceforge.net,
	Stefan Schmidt <stefan@...nmoko.org>, eric.y.miao@...il.com,
	linux-kernel@...r.kernel.org, sameo@...nedhand.com,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [spi-devel-general] [patch 05/14] mfd: PCAP2 driver

Em Sáb, 2008-11-22 às 20:59 -0800, David Brownell escreveu:
> > I tried spi_write_then_read before, but it didn't work. I supposed it
> > was because it was doing 2 transfers as the second transfer rx_buf
> > always came zeroed.
> 
> You may have been using it wrong.  Also, verify against
> current kernels ... there have been bugfixes to pxa2xx_spi.
> 
> > I see that commit 
> > f9b90e39cbc5c4d6ef60022fd1f25d541df0aad1 changed it to do a single
> > transfer, so i will try it again.
> 
> Unless it needs the full duplex capability of SPI, then
> you should be able to make write_then_read work ... on
> the other hand, if you do need full duplex, then you
> should address the DMA.  (And byteswapping, either way.)

Well, i guess it is full duplex, as i set spi_transfer.len to 4 bytes,
write 4 bytes _and_ read 4 bytes to/from the chip.

I'm looking at write_then_read and if I read it correctly, it sends n_tx
bytes of data plus n_rx bytes of nothing, and discards n_tx bytes from
the start of the receive buffer considering only n_rx bytes from the end
of the receive buffer. This is not what i want.

Can you be more descriptive on "address the DMA"? Im not familiar on
what is the issue here.

I will take care of byte swapping for the next patch.

-- 
Daniel Ribeiro

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