linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: 'Dmitry Torokhov' <dmitry.torokhov@gmail.com>
To: jingle <jingle.wu@emc.com.tw>
Cc: 'linux-kernel' <linux-kernel@vger.kernel.org>,
	'linux-input' <linux-input@vger.kernel.org>,
	'phoenix' <phoenix@emc.com.tw>,
	"'josh.chen'" <josh.chen@emc.com.tw>,
	"'kai.heng.feng'" <kai.heng.feng@canonical.com>
Subject: Re: [PATCH 2/2] Input: elan_i2c - Modify the IAP related functio n for page sizes 128, 512 bytes.
Date: Fri, 17 Jul 2020 09:02:34 -0700	[thread overview]
Message-ID: <20200717160234.GE1665100@dtor-ws> (raw)
In-Reply-To: <002c01d65c14$bccb9c10$3662d430$@emc.com.tw>

Hi Jingle,

On Fri, Jul 17, 2020 at 04:31:58PM +0800, jingle wrote:
> Hi Dmitry:
> 
> 1. 
> 
> In this function elan_get_fwinfo().
> 
> +static int elan_get_fwinfo(u16 ic_type, u8 iap_version, u8 pattern,
> +			   u16 *validpage_count, u32 *signature_address,
> +			   u16 *page_size)
>  {
> -	switch (ic_type) {
> +	u16 type = pattern >= 0x01 ? ic_type : iap_version;
> +
> +	switch (type) {
> 
> This iap_version in pattern0 is read from this command
> ETP_I2C_IAP_VERSION_CMD_OLD ,it is not from this command
> ETP_I2C_IAP_VERSION.
> So u16 type = pattern >= 0x01 ? ic_type : iap_version; <- wrong
> 
> 2. In this "static int elan_i2c_prepare_fw_update(struct i2c_client *client,
> u16 ic_type, u8 iap_version)" function.
> The ic is old pattern must be modify correct ic_type. (cmd is
> ETP_I2C_IAP_VERSION)

I see. It looks like there is some confusion on my part between IAP
version, IC type, and the commands that we want to use. Please let me
know if I understand this correctly:

- For patterns >=1 (newer)
  IAP version is retrieved with ETP_I2C_IAP_VERSION_CMD
  IC type is fetched with ETP_I2C_IC_TYPE_CMD
  Version comes from ETP_I2C_NSM_VERSION_CMD

- For pattern 0 (old)
  Before your patches
    IAP version was using ETP_I2C_IAP_VERSION_CMD (and you are saying
    it is wrong)
    Version comes from 1st byte of ETP_I2C_OSM_VERSION_CMD
    IC type comes from 2nd byte of ETP_I2C_OSM_VERSION_CMD (and you are
    saying it is some other bit of data - what is it then?)

  After your patches
    IAP version is retrieved with ETP_I2C_IAP_VERSION_CMD_OLD
    Version comes from 1st byte of ETP_I2C_OSM_VERSION_CMD
    IC type is retrieved with ETP_I2C_IAP_VERSION_CMD (should we rename
    it then?)

So the difference is where the the IC type is coming from for old
patterns. However, as I mentioned, we have the following body of code:

static int elan_check_ASUS_special_fw(struct elan_tp_data *data)
{
	if (data->ic_type == 0x0E) {
		switch (data->product_id) {
		case 0x05 ... 0x07:
		case 0x09:
		case 0x13:
			return true;
		}
	} else if (data->ic_type == 0x08 && data->product_id == 0x26) {
		/* ASUS EeeBook X205TA */
		return true;
	}

	return false;
}

And before your patches ic_type here would be the 2nd byte of response
to ETP_I2C_OSM_VERSION_CMD for older devices and my concern that
replacing it with data from ETP_I2C_IAP_VERSION_CMD would break these
checks.

We need to reconcile what we have in this function with what you are
proposing for firmware update code.

Thanks,
Dmitry

      reply	other threads:[~2020-07-17 16:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14 10:56 [PATCH 2/2] Input: elan_i2c - Modify the IAP related function for page sizes 128, 512 bytes Jingle Wu
2020-07-16  5:39 ` Dmitry Torokhov
2020-07-16  6:15   ` [PATCH 2/2] Input: elan_i2c - Modify the IAP related functio n " jingle.wu
2020-07-17  1:27     ` Dmitry Torokhov
2020-07-17  6:10       ` Dmitry Torokhov
2020-07-17  8:20         ` jingle
2020-07-17  8:31         ` jingle
2020-07-17 16:02           ` 'Dmitry Torokhov' [this message]

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=20200717160234.GE1665100@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=jingle.wu@emc.com.tw \
    --cc=josh.chen@emc.com.tw \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phoenix@emc.com.tw \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).