devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Abel Vesa <abel.vesa@linaro.org>
To: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC PATCH 1/3] usb: Add USB repeater generic framework
Date: Mon, 21 Nov 2022 16:21:18 +0200	[thread overview]
Message-ID: <Y3uJXlz0EOSyBzts@linaro.org> (raw)
In-Reply-To: <71ced60f-d43b-003a-843d-c2a8364dbf79@collabora.com>

On 22-11-18 09:59:43, Andrzej Pietrasiewicz wrote:
> Hi Abel,
> 
> W dniu 16.11.2022 o 13:30, Abel Vesa pisze:
> > With more SoCs moving towards eUSB2,
> 
> Can you name a few?

Right now, for SoCs, I can only name the SM8550 from Qualcomm. But I
would think there will be more from now on, not just from Qualcomm.

But I found a couple of more repeaters already existent. Like TUSB2E11
or TUSB2E22 from TI or PTN3222 from NXP. I'm not sure if they are used
already alongside any specific SoC though (yet).

Anyway, I can rephrase that.

> 
> such platforms will have to use
> > a USB 2.0 compliance repeater. This repeater HW-wise usually deals with
> > level shifting, but depending on the implementation it can do much more.
> > So add a ganeric USB framework that would allow either a generic PHY or
> > some USB host controller to control and get a repeater from a devicetree
> > phandle. This framework will further be used by platform specific
> > drivers to register the repeater and implement platform specific ops.
> > 
> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> > ---
> >   drivers/usb/Kconfig             |   2 +
> >   drivers/usb/Makefile            |   2 +
> >   drivers/usb/repeater/Kconfig    |   9 ++
> >   drivers/usb/repeater/Makefile   |   6 +
> >   drivers/usb/repeater/repeater.c | 198 ++++++++++++++++++++++++++++++++
> >   include/linux/usb/repeater.h    |  78 +++++++++++++
> >   6 files changed, 295 insertions(+)
> >   create mode 100644 drivers/usb/repeater/Kconfig
> >   create mode 100644 drivers/usb/repeater/Makefile
> >   create mode 100644 drivers/usb/repeater/repeater.c
> >   create mode 100644 include/linux/usb/repeater.h
> > 
> 
> <snip>
> 
> > diff --git a/include/linux/usb/repeater.h b/include/linux/usb/repeater.h
> > new file mode 100644
> > index 000000000000..e68e0936f1e5
> > --- /dev/null
> > +++ b/include/linux/usb/repeater.h
> > @@ -0,0 +1,78 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * USB Repeater defines
> > + */
> > +
> > +#ifndef __LINUX_USB_REPEATER_H
> > +#define __LINUX_USB_REPEATER_H
> > +
> > +struct usb_repeater {
> > +	struct device		*dev;
> > +	const char		*label;
> > +	unsigned int		 flags;
> > +
> > +	struct list_head	head;
> 
> This member serves the purpose of a list _entry_, no?
> The _head_ is static LIST_HEAD(usb_repeater_list);
> Maybe call it "entry"?

Sure thing. Will do.

> 
> > +	int	(*reset)(struct usb_repeater *rptr, bool assert);
> > +	int	(*init)(struct usb_repeater *rptr);
> > +	int	(*power_on)(struct usb_repeater *rptr);
> > +	int	(*power_off)(struct usb_repeater *rptr);
> 
> Would you document these ops somehow? Potential driver writers need to
> understand when they are called and what they are supposed to do.
> In particular, how do these relate to what's in "Embedded USB2 (eUSB2)
> Physical Layer Supplement to the USB Revision 2.0 Specification"?

Yes. Will document them appropriately.

> 
> Regards,
> 
> Andrzej

Thanks,
Abel


  reply	other threads:[~2022-11-21 14:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 12:30 [RFC PATCH 0/3] usb: Add generic repeater framework and SM8550 driver Abel Vesa
2022-11-16 12:30 ` [RFC PATCH 1/3] usb: Add USB repeater generic framework Abel Vesa
2022-11-18  8:59   ` Andrzej Pietrasiewicz
2022-11-21 14:21     ` Abel Vesa [this message]
2022-11-16 12:30 ` [RFC PATCH 2/3] dt-bindings: usb: Add qcom,snps-eusb2-repeater schema Abel Vesa
2022-11-16 15:29   ` Rob Herring
2022-11-16 12:30 ` [RFC PATCH 3/3] usb: repeater: Add Qualcomm PMIC eUSB2 driver Abel Vesa

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=Y3uJXlz0EOSyBzts@linaro.org \
    --to=abel.vesa@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=andrzej.p@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=robh+dt@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 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).