All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Javier Carrasco <javier.carrasco@wolfvision.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Abdel Alkuor <abdelalkuor@geotab.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH RESEND 2/2] usb: typec: tipd: fix event checking for tps6598x
Date: Fri, 5 Apr 2024 09:49:51 +0300	[thread overview]
Message-ID: <Zg+fD6w1MykCsEe6@kuha.fi.intel.com> (raw)
In-Reply-To: <b6bf7f8e-7d46-4b70-930c-9483f13fd80a@wolfvision.net>

On Wed, Apr 03, 2024 at 10:55:29AM +0200, Javier Carrasco wrote:
> >> -	ret = tps6598x_read64(tps, TPS_REG_INT_EVENT1, &event1);
> >> -	ret |= tps6598x_read64(tps, TPS_REG_INT_EVENT2, &event2);
> >> +	ret = tps6598x_block_read(tps, TPS_REG_INT_EVENT1, event1, 11);
> > 
> > This is not going to work with the older TI PD controllers.
> > 
> > The lenght of these registers is 8 bytes on the older TI PD
> > controllers (TPS65981, TPS65982, etc.). I think we need to split this
> > function.
> > 
> 
> That is a good point. I had a look at the older TI PD controllers and I
> agree with you that we should split the function to cover both register
> lengths separately.
> 
> I was thinking about adding a new compatible for the newer PD
> controllers (tps65987 and tps65988), keeping the current tps6598x for
> the older ones as well as backwards compatibility. But backwards
> compatibility would also mean that flags beyond the first 8 bytes would
> be ignored.
> 
> On the other hand, the upper flags are only relevant for firmware
> updates, so we could check those (i.e. read 11 bytes) if a firmware was
> provided via "firmware-name", and ignore them (i.e. read 8 bytes) otherwise.
> 
> Other ideas or improvements to mine are more than welcome.

I don't have any good ideas. On ACPI platforms the same device ID may
be used with all of these, so we should actually try to figure out the
version from registers like VID, DID and Version (if they are
available).

thanks,

-- 
heikki

  reply	other threads:[~2024-04-05  6:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 16:55 [PATCH RESEND 0/2] usb: typec: tipd: fix event checking in interrupt service routines Javier Carrasco
2024-03-28 16:55 ` [PATCH RESEND 1/2] usb: typec: tipd: fix event checking for tps25750 Javier Carrasco
2024-04-02 10:21   ` Heikki Krogerus
2024-03-28 16:55 ` [PATCH RESEND 2/2] usb: typec: tipd: fix event checking for tps6598x Javier Carrasco
2024-04-02 10:29   ` Heikki Krogerus
2024-04-03  8:55     ` Javier Carrasco
2024-04-05  6:49       ` Heikki Krogerus [this message]
2024-04-11 20:13         ` Javier Carrasco
2024-04-02 10:21 ` [PATCH RESEND 0/2] usb: typec: tipd: fix event checking in interrupt service routines Heikki Krogerus
2024-04-02 17:39   ` Javier Carrasco
  -- strict thread matches above, loose matches on Subject: below --
2024-03-28 16:25 Javier Carrasco
2024-03-28 16:25 ` [PATCH RESEND 2/2] usb: typec: tipd: fix event checking for tps6598x Javier Carrasco

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=Zg+fD6w1MykCsEe6@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=abdelalkuor@geotab.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=javier.carrasco@wolfvision.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@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.