linux-kernel - Re: [PATCH 3/3] Input: cyttsp - add support for Cypress TTSP touchscreen SPI bus interface

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:	Sat, 03 Sep 2011 07:31:58 +0200
From:	Javier Martinez Canillas <martinez.javier@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Kevin McNeely <kev@...ress.com>,
	Henrik Rydberg <rydberg@...omail.se>,
	Srikar <ext-srikar.1.bhavanarayana@...ia.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] Input: cyttsp - add support for Cypress TTSP
 touchscreen SPI bus interface

Hello Dmitry,

On Sun, 2011-08-21 at 19:44 -0700, Dmitry Torokhov wrote:
> Hi Javier,
> 
> > +
> > +	memset((void *)xfer, 0, sizeof(xfer));
> > +	spi_message_init(&msg);
> > +	xfer[0].tx_buf = wr_buf;
> > +	xfer[0].rx_buf = rd_buf;
> 
> Since we are setting both TX and RX buffer here does this mean that the
> device will not work with controllers in half-duplex mode? What is the
> amount of data that will be placed in rd_buf?
> 

Both TX and RX buffers are set because Cypress requires full duplex
operation always.

> > +	retval = spi_sync_tmo(ts, &msg);
> > +	if (retval < 0) {
> > +		dev_dbg(ts->ops.dev, "%s: spi sync error %d, len=%d, op=%d\n",
> > +			__func__, retval, xfer[1].len, op);
> > +		retval = 0;
> 
> Why do we ignore the error?
> 

Fixed: In next version a following ACK check code return the status to
the cyttsp core so it can retry after waiting with an msleep() call.

> > +	}
> > +
> > +	if (op == CY_SPI_RD_OP) {
> > +		if ((rd_buf[CY_SPI_SYNC_BYTE] == CY_SPI_SYNC_ACK1) &&
> > +			(rd_buf[CY_SPI_SYNC_BYTE+1] == CY_SPI_SYNC_ACK2))
> > +			retval = 0;
> 
> What about write operation? Does the device send anything in rd_buf for
> write command?
> 

Fixed: Both read and write operations check the ACK bytes now.

> > +
> > +	if (op == CY_SPI_RD_OP) {
> > +		for (tries = CY_NUM_RETRY; tries; tries--) {
> > +			retval = cyttsp_spi_xfer_(op, ts, reg, buf, length);
> > +			if (retval == 0)
> > +				break;
> > +			else
> > +				msleep(20);
> 
> Why do we need retry in SPI case but do not need it when device is
> connected via I2C? And not on writes?
> 

Fixed: The retries now are made in the cyttsp core so it works both for
SPI and I2C.

> > +
> > +	if (retval == -EIO)
> > +		return 0;
> 
> Why is -EIO special?
> 

Fixed: Now special EIO has been fixed to show meaning.

> > +	else
> > +		return retval;
> > +}
> > +
> 
> Thanks.
> 
> -- 
> Dmitry

Best regards,

Javier Martinez Canillas

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