All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Nikita Travkin <nikita@trvn.ru>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 0/7] usb: typec: ucsi: rework glue driver interface
Date: Thu, 27 Jun 2024 17:02:43 +0200	[thread overview]
Message-ID: <2024062724-petty-twine-afd5@gregkh> (raw)
In-Reply-To: <CAA8EJprAshnt3YchBv0ssi4Vet9b6oMcf3z8nuRkoZVYNBq64w@mail.gmail.com>

On Thu, Jun 27, 2024 at 05:57:30PM +0300, Dmitry Baryshkov wrote:
> On Thu, 27 Jun 2024 at 17:54, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Jun 27, 2024 at 05:44:39PM +0300, Dmitry Baryshkov wrote:
> > > The interface between UCSI and the glue driver is very low-level. It
> > > allows reading the UCSI data from any offset (but in reality the UCSI
> > > driver reads only VERSION, CCI an MESSAGE_IN data). All event handling
> > > is to be done by the glue driver (which already resulted in several
> > > similar-but-slightly different implementations). It leaves no place to
> > > optimize the write-read-read sequence for the command execution (which
> > > might be beneficial for some of the drivers), etc.
> > >
> > > The patchseries attempts to restructure the UCSI glue driver interface
> > > in order to provide sensible operations instead of a low-level read /
> > > write calls.
> > >
> > > If this approach is found to be acceptable, I plan to further rework the
> > > command interface, moving reading CCI and MESSAGE_IN to the common
> > > control code, which should simplify driver's implementation and remove
> > > necessity to split quirks between sync_control and read_message_in e.g.
> > > as implemented in the ucsi_ccg.c.
> > >
> > > Note, the series was tested only on the ucsi_glink platforms. Further
> > > testing is appreciated.
> > >
> > > Depends: [1], [2]
> > >
> > > [1] https://lore.kernel.org/linux-usb/20240612124656.2305603-1-fabrice.gasnier@foss.st.com/
> > >
> > > [2] https://lore.kernel.org/linux-usb/20240621-ucsi-yoga-ec-driver-v8-1-e03f3536b8c6@linaro.org/
> > >
> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > ---
> > > Changes in v4:
> > > - Rebased on top of Greg's tree to resolve conflicts.
> >
> > Nope, still got conflicts, are you sure you updated properly?  Patch 1
> > applied, but #2 did not.
> 
> I feel stupid enough now. I rebased on top of usb-next instead of
> usb-testing. Let me spam it once again

Both branches should be identical right now, perhaps you missed when I
synced them up.

  reply	other threads:[~2024-06-27 15:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27 14:44 [PATCH v4 0/7] usb: typec: ucsi: rework glue driver interface Dmitry Baryshkov
2024-06-27 14:44 ` [PATCH v4 1/7] usb: typec: ucsi: move ucsi_acknowledge() from ucsi_read_error() Dmitry Baryshkov
2024-06-27 14:44 ` [PATCH v4 2/7] usb: typec: ucsi: simplify command sending API Dmitry Baryshkov
2024-06-27 14:44 ` [PATCH v4 3/7] usb: typec: ucsi: split read operation Dmitry Baryshkov
2024-06-27 14:44 ` [PATCH v4 4/7] usb: typec: ucsi: rework command execution functions Dmitry Baryshkov
2024-06-27 14:44 ` [PATCH v4 5/7] usb: typec: ucsi: inline ucsi_read_message_in Dmitry Baryshkov
2024-06-27 14:44 ` [PATCH v4 6/7] usb: typec: ucsi: extract common code for command handling Dmitry Baryshkov
2024-06-27 14:44 ` [PATCH v4 7/7] usb: typec: ucsi: reorder operations in ucsi_run_command() Dmitry Baryshkov
2024-06-27 14:54 ` [PATCH v4 0/7] usb: typec: ucsi: rework glue driver interface Greg Kroah-Hartman
2024-06-27 14:57   ` Dmitry Baryshkov
2024-06-27 15:02     ` Greg Kroah-Hartman [this message]
2024-06-27 15:08     ` Dmitry Baryshkov
2024-06-28 14:24       ` Greg Kroah-Hartman
2024-06-28 14:25         ` Dmitry Baryshkov
2024-07-03 14:05           ` Greg Kroah-Hartman

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=2024062724-petty-twine-afd5@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=neil.armstrong@linaro.org \
    --cc=nikita@trvn.ru \
    /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.