All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Zaidman <michael.zaidman@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-input@vger.kernel.org
Subject: Re: [bug report] HID: ft260: add usb hid to i2c host bridge driver
Date: Fri, 19 Mar 2021 18:33:12 +0200	[thread overview]
Message-ID: <20210319163312.GA1940@michael-VirtualBox> (raw)
In-Reply-To: <YFMt+VFuiZlCVFyP@mwanda>

On Thu, Mar 18, 2021 at 01:39:53PM +0300, Dan Carpenter wrote:
> 
> drivers/hid/hid-ft260.c
>   1017  static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
>   1018                             u8 *data, int size)
>   1019  {
>   1020          struct ft260_device *dev = hid_get_drvdata(hdev);
>   1021          struct ft260_i2c_input_report *xfer = (void *)data;
>   1022  
>   1023          if (xfer->report >= FT260_I2C_REPORT_MIN &&
>   1024              xfer->report <= FT260_I2C_REPORT_MAX) {
>   1025                  ft260_dbg("i2c resp: rep %#02x len %d\n", xfer->report,
>   1026                            xfer->length);
>   1027  
>   1028                  memcpy(&dev->read_buf[dev->read_idx], &xfer->data,
>   1029                         xfer->length);
> 
> Do we need to check if "xfer->len <= dev->read_len"?
The dev->read_len is a total length to be read, passed into ft260_i2c_read()
by a user. This length is divided into 60 bytes chanks to be retrieved from
the ft260 controller. The ft260_raw_event() receives these chanks and counts
the total number of bytes received in read_idx. Once it matches the read_len,
we conclude on the i2c read transfer completion. We do not need to check the
xfer->len against the dev->read_len since the ft260 controller never returns
more bytes than was asked to read.
> 
>   1030                  dev->read_idx += xfer->length;
>   1031  
>   1032                  if (dev->read_idx == dev->read_len)
>   1033                          complete(&dev->wait);
>   1034  
>   1035          } else {
>   1036                  hid_err(hdev, "unknown report: %#02x\n", xfer->report);
>   1037                  return 0;
>   1038          }
>   1039          return 1;
>   1040  }
> 
> regards,
> dan carpenter

  reply	other threads:[~2021-03-19 16:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 10:39 [bug report] HID: ft260: add usb hid to i2c host bridge driver Dan Carpenter
2021-03-19 16:33 ` Michael Zaidman [this message]
2021-04-09 12:32 Dan Carpenter
2021-04-10 12:27 ` Michael Zaidman
2021-04-10 15:37   ` Dan Carpenter
2021-04-10 21:04     ` Michael Zaidman
2021-04-12  9:11       ` Dan Carpenter
2021-04-13 15:52         ` Michael Zaidman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210319163312.GA1940@michael-VirtualBox \
    --to=michael.zaidman@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.