d __iomem*op;
> >>size_t size;
> >> - void __iomem**regmap;
> >> + void __iomem*regmap[OP_LAST];
> >
> > OP_LAST + 1?
>
> Yes. Why didn't the compiler detect the out of bounds access of the array?
I cannot find it in my C book, but IIRC for an array
sometype name[20];
in some contexts 20 is an allowed subscript (e.g. for &name[20]). Maybe
that's why gcc doesn't warn. But in general don't consider you program
to be OK just because you don't get a gcc warning :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
blems with it that a
plain request_irq doesn't have. But I wonder about the details and if
others are aware of the possible problems. Mark, maybe you can describe
in more detail the downsides you see?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König
On Wed, Jul 31, 2013 at 04:20:55PM +0800, Peter Chen wrote:
> On Wed, Jul 31, 2013 at 09:33:06AM +0200, Uwe Kleine-König wrote:
> > On Tue, Jul 30, 2013 at 10:04:29PM -0300, Fabio Estevam wrote:
> > > From: Fabio Estevam
> > >
> > > By using devm_request_
[Expanded Cc: a bit]
Hello,
On Wed, Jul 31, 2013 at 10:05:12AM +0100, Mark Brown wrote:
> On Wed, Jul 31, 2013 at 10:46:45AM +0200, Uwe Kleine-König wrote:
We're discussing about devm_request_irq and wonder what happens at
remove time when the irq is still active.
> > OK, s
On Wed, Jul 31, 2013 at 05:54:11AM -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Jul 31, 2013 at 11:44:34AM +0200, Uwe Kleine-König wrote:
> > > > OK, so the possible problem is that remove is called while the irq is
> > > > still active. That means you have to
t/select failed, err=%ld\n",
> PTR_ERR(pinctrl));
>
> data->clk = devm_clk_get(&pdev->dev, NULL);
> --
> 1.7.9.5
>
>
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions
On Fri, Apr 26, 2013 at 03:36:42PM +0300, Alexander Shishkin wrote:
> Uwe Kleine-König writes:
>
> > On Wed, Apr 24, 2013 at 02:19:19PM -0300, Fabio Estevam wrote:
> >> From: Fabio Estevam
> >>
> >> Currently we always get the following message durin
anged, 42 insertions(+)
> ...
> > At this point might be good to patch the imx27.dtsi with the usb defines.
> ...
>
> I have a working configuration for i.MX27 USB, but I prefer to make a few more
> tests before the addition of definitions in DTS. This will be a next step.
&
= <54>;
> + clocks = <&clks 75>, <&clks 62>;
> + clock-names = "ipg", "ahb";
> + dr_mode = "host";
> + phy_type
On Sat, Jan 11, 2014 at 06:01:48PM +0400, Alexander Shiyan wrote:
> Суббота, 11 января 2014, 13:55 +01:00 от Uwe Kleine-König
> :
> > On Mon, Nov 11, 2013 at 11:09:16AM +0400, Alexander Shiyan wrote:
> > > Hello.
> > >
> > > > >>>> On Sund
Hello Alexander,
On Tue, Jan 14, 2014 at 07:30:46AM +0400, Alexander Shiyan wrote:
> I'll send you a personal letter with DT configuration.
That would be great. You didn't send it yet, did you?
Best regards
Uwe
--
Pengutronix e.K. | Uwe
Hello Chris,
On Tue, Jan 14, 2014 at 11:53:47AM +0800, Chris Ruehl wrote:
> On Tuesday, January 14, 2014 11:30 AM, Alexander Shiyan wrote:
> >Понедельник, 13 января 2014, 22:31 +01:00 от Uwe Kleine-König
> >:
> >>On Sat, Jan 11, 2014 at 06:01:48PM +0400, Alexander Shiyan
Hello Alexander,
On Tue, Jan 14, 2014 at 02:47:39PM +0100, Uwe Kleine-König wrote:
> On Tue, Jan 14, 2014 at 07:30:46AM +0400, Alexander Shiyan wrote:
> > I'll send you a personal letter with DT configuration.
> That would be great. You didn't send it yet, did you?
I take th
r patches. If you Cc: on new attempts for b) I will
try to test it.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
arch/arm/boot/dts/imx27-pingrp.h | 14 +
arch
g
USB_CHIPIDEA to bool :-)?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a mess
Hello,
On Wed, Jan 22, 2014 at 10:49:51AM +0100, Uwe Kleine-König wrote:
> On Tue, Dec 03, 2013 at 04:01:50PM +0800, Chris Ruehl wrote:
> > usb: chipidea: hw_phymode_configure moved before ci_usb_phy_init
> > hw_phymode_configure configures the PORTSC registers and allow th
Hello Peter,
On Thu, Jan 23, 2014 at 09:22:41AM +0800, Peter Chen wrote:
> On Wed, Jan 22, 2014 at 10:41:33PM +0100, Uwe Kleine-König wrote:
> > On Wed, Jan 22, 2014 at 10:49:51AM +0100, Uwe Kleine-König wrote:
> > > On Tue, Dec 03, 2013 at 04:01:50PM +0800, Chris Ruehl
access the PMC using regmap")
> Reported-by: Uwe Kleine-König
I played with the AT91 during my non-work time, so please use
u...@kleine-koenig.org as my email address.
> Signed-off-by: Alexandre Belloni
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 2 ++
> 1 file changed
takes
precedence by just overwriting the defaults added here.
Signed-off-by: Uwe Kleine-König
---
arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts | 2 --
arch/arm/boot/dts/imx25-pdk.dts| 2 --
arch/arm/boot/dts/imx25.dtsi | 2 ++
3 files ch
ing for
PORT_OCC.
Fixes: 81463c1d7071 ("EHCI: only power off port if over-current is active")
Signed-off-by: Uwe Kleine-König
---
drivers/usb/host/ehci-hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
ind
is workflow such that it doesn't include
manually transfering changes from one tree to another for submission.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsu
Hello Alan,
On Fri, Oct 20, 2017 at 01:58:14PM -0400, Alan Stern wrote:
> On Fri, 20 Oct 2017, Uwe Kleine-König wrote:
> > diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
> > index df169c8e7225..08f59654654b 100644
> > --- a/drivers/usb/host/ehci-hub.c
Hey Fabio,
On Fri, Oct 20, 2017 at 05:27:09PM -0200, Fabio Estevam wrote:
> On Fri, Oct 20, 2017 at 5:20 PM, Uwe Kleine-König
> wrote:
>
> > It also works. However I wonder if it's right that I'm spammed by
> > over-current messages now (independent of which fix
Hello Alan,
On Fri, Oct 20, 2017 at 03:47:37PM -0400, Alan Stern wrote:
> On Fri, 20 Oct 2017, Uwe [iso-8859-1] Kleine-König wrote:
> > On Fri, Oct 20, 2017 at 05:27:09PM -0200, Fabio Estevam wrote:
> > > On Fri, Oct 20, 2017 at 5:20 PM, Uwe Kleine-König
> > > wrote:
&
ri, Oct 20, 2017 at 05:27:09PM -0200, Fabio Estevam wrote:
> > > > > On Fri, Oct 20, 2017 at 5:20 PM, Uwe Kleine-König
> > > > > wrote:
> > > > >
> > > > > > It also works. However I wonder if it's right that I'm spamm
ow logic. This could only be
circumvented with another property "over-current-active-low" and
different default handling for imx6/7 vs imx25 if none (or both) of the
properties are present. For simplicity I stick to the easier and better
understandable alternative at the cost of dt incompat
a per-port is_overcurrent flag. If the port has an
> > > overcurrent status and the flag is clear, log the error and set the
> > > flag. If the port doesn't have an overcurrent status, clear the flag.
> > > In other words, report each overcurrent event only once.
I wonder if it was better/simpler to handle devm_clk_get returning
-ENOENT and assume this means there is no need for a clock in this case.
(I think devm_clk_get prints an error message in this case. That's ugly
when the error is handled just fine.)
Best regards
Uwe
--
Pengutronix e.K.
g_reg(Y5_USB2_RCV);
> - // FIXME omap_cfg_reg(USB2_SPEED);
> + /* Depend on boatloader for USB speed to be stated for board */
bootloader?
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://ww
This is needed to let the omap3 otg controller make use of a generic
usb-nop-xceiv phy.
---
drivers/usb/phy/phy-generic.c | 50 ---
drivers/usb/phy/phy-generic.h | 1 +
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-gene
Todo: binding document, more properties
Signed-off-by: Uwe Kleine-König
---
drivers/usb/phy/phy-ulpi.c | 129 +
1 file changed, 119 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/phy/phy-ulpi.c b/drivers/usb/phy/phy-ulpi.c
index f48a7a21e3c2
The phy's init routine must be called before it can be used. Do so in
musb_init_controller and the matching shutdown in musb_remove.
Signed-off-by: Uwe Kleine-König
---
Note I'm not entirely sure this is the right place, but this made usb
working on my omap3 machine here (at leas
Hello,
these patches make it possible to use USB on an omap3 machine with an
USB3320 external phy.
Best regards
Uwe
Uwe Kleine-König (3):
usb: musb: core: call init and shutdown for the usb phy
usb: phy-generic: register a struct phy device
usb: phy: ulpi: implement creating a phy via
On Tue, Dec 22, 2015 at 12:06:14PM -0600, Felipe Balbi wrote:
> Uwe Kleine-König writes:
>
> > This is needed to let the omap3 otg controller make use of a generic
> > usb-nop-xceiv phy.
>
> missing SoB
If this is your only concern I will happily resend the series
tory
for 4.3. I already sent the respective change to Linus Walleij to pull
for next and my commit to fix phy-tusb1210 is included to not break this
driver.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www
allow dropping this hack convert callers to explictly pass a value
for flags.
Signed-off-by: Uwe Kleine-König
---
drivers/usb/gadget/udc/pxa27x_udc.c | 2 +-
drivers/usb/phy/phy-generic.c | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc
Hello,
On Sat, Mar 28, 2015 at 09:38:12AM +0100, Robert Jarzmik wrote:
> Alexandre Courbot writes:
>
> > On 03/28/2015 04:30 AM, Uwe Kleine-König wrote:
> > Looks good, but can't we also merge the call to gpiod_direction to avoid
> > using
> > GPIOD_ASIS?
gpios. Also use devm_gpiod_get* because otherwise the gpio
might be grabbed by a different driver.
Simplify driver accordingly.
Signed-off-by: Uwe Kleine-König
---
Hello,
This usage without flags was introduced by commit a89d977cc04c (usb:
dwc3: pci: add quirk for Baytrails) that is currently in
gpios.
Simplify driver accordingly. Furthermore this is one caller less that
stops us making the flags argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-König
---
Hello,
[for the initial submission I forgot linux-usb on Cc, Felipe Balbi
requested a resend]
note I plan to make the
Hello,
On Fri, Mar 27, 2015 at 08:30:42PM +0100, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value f
and improve error handling. Also expand the comment to explain
why it's not sensible to switch to devm_gpiod_get and why the gpiod_put
is also necessary.
Furthermore this is one caller less that stops us making the flags
argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-
me to adapt their patches.
Thanks
Uwe
Uwe Kleine-König (10):
drm/msm/dp: use flags argument of devm_gpiod_get to set direction
drm/tilcdc: panel: make better use of gpiod API
iio: light: stk3310: use flags argument of devm_gpiod_get
iio: magn: bmc150: use flags argument of d
gpios.
Simplify driver accordingly.
Signed-off-by: Uwe Kleine-König
---
drivers/phy/phy-tusb1210.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
index 07efdd318bdc..93dd45f2f26e 100644
allow dropping this hack convert callers to explictly pass a value
for flags.
Acked-by: Felipe Balbi
Acked-by: Robert Jarzmik
Signed-off-by: Uwe Kleine-König
---
drivers/usb/gadget/udc/pxa27x_udc.c | 2 +-
drivers/usb/phy/phy-generic.c | 6 --
2 files changed, 5 insertions(+), 3 deletions
ff-by: Uwe Kleine-König
---
drivers/usb/dwc3/dwc3-pci.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 27e4fc896e9d..f62617999f3c 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/driver
ethod.
Without following all that fwnode discussion:
gpiod_get et al. should work for you here, doesn't it? It just takes a
struct device * and I'm happy with it.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions
of struct usb_phy_io_ops's write.
Fixes: ffb865b1e460 ("usb: musb: add ulpi access operations")
Signed-off-by: Uwe Kleine-König
---
Note that doing this might break callers that got the order wrong, too.
So I'd prefer to have this patch in a release before backporting it to
stable.
dri
the platform lookup
table. That would be devm_phy_get_optional(..) here. And this one would
just ignore -ENOENT which would be better here, too.
Best regards
Uwe
> hsotg->phy = NULL;
> uphy = devm_usb_get_phy(&dev->dev, USB_PHY_TYPE_USB2);
>
Hello Alex,
On Mon, Oct 26, 2015 at 10:24:58AM +0100, Alexander Aring wrote:
> On Sun, Oct 25, 2015 at 08:00:11PM +0100, Uwe Kleine-König wrote:
> > On Sun, Oct 25, 2015 at 08:57:31AM +0100, Alexander Aring wrote:
> > > This patch adds support to return -EPROBE_DEFER if de
> an old USB PHY when devm_phy_get returns -ENOENT only. Other values like
> -EPROBE_DEFER need to be returned from the probe function, because it
> could be that a phy is specified but not probed before.
>
> Suggested-by: Uwe Kleine-König
Acked-by: Uwe Kleine-König
Best regards
U
ndle_with_args(np, "phys", "#phy-cells",
index, &args);
if (ret)
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(ret);
in _of_phy_get (drivers/phy/phy-core.c) to make the phy functions behave
identically?
Best regards
Uwe
--
but restricts itself to either an ERR value or
The relevant part is that for a function with "optinal" in it's name not
finding the respective resource isn't an error. So checking for NULL
isn't error handling but handling the 2nd valid case.
Best regards
Uwe
--
Pengutroni
Hello,
On Tue, Oct 27, 2015 at 09:08:27AM -0600, Stephen Warren wrote:
> On 10/27/2015 01:41 AM, Uwe Kleine-König wrote:
> >Hello,
> >
> >On Mon, Oct 26, 2015 at 08:08:58PM -0600, Stephen Warren wrote:
> >>On 10/26/2015 03:28 AM, Alexander Aring wrote:
> >
Hello Stephen,
On Wed, Oct 28, 2015 at 09:55:05PM -0600, Stephen Warren wrote:
> On 10/27/2015 12:18 PM, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Tue, Oct 27, 2015 at 09:08:27AM -0600, Stephen Warren wrote:
> >> On 10/27/2015 01:41 AM, Uwe Kleine-König wrote:
&
MX53 and
i.MX6*.
Among these SoCs is really only the i.MX35 affected?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsu
e attribute handling of the led-trigger core and is more in line with
the other triggers.
> I'll apply this, but this feels like a problem in the led api if the
> above really is true.
>
> also, please wrap your changelogs at 72 columns, making it easier to
> read. I di
On Fri, Jan 18, 2019 at 10:13:37AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 18, 2019 at 10:07:05AM +0100, Uwe Kleine-König wrote:
> > But I still agree that there seems to be something "unusual" about the
> > usb led trigger ...
> >
> > Instead of pr
On Fri, Jan 18, 2019 at 10:28:34AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 18, 2019 at 10:22:02AM +0100, Uwe Kleine-König wrote:
> > On Fri, Jan 18, 2019 at 10:13:37AM +0100, Greg Kroah-Hartman wrote:
> > > On Fri, Jan 18, 2019 at 10:07:05AM +0100, Uwe Kleine-König wr
doesn't matter if active high is
configured because that's the default or because it is configured
explicitly.
Signed-off-by: Uwe Kleine-König
---
.../devicetree/bindings/usb/ci-hdrc-usb2.txt | 1 +
drivers/usb/chipidea/ci_hdrc_imx.c| 9 -
drivers/usb/chipidea/ci_hdrc_im
Hello Fabio,
On Fri, Nov 30, 2018 at 07:16:39PM -0200, Fabio Estevam wrote:
> [Adding Matt]
>
> On Fri, Nov 30, 2018 at 6:53 PM Uwe Kleine-König
> wrote:
> >
> > The status quo is:
> > - on i.MX25 the overcurrent polarity is always explicitly configured as
> &
BM_OVER_CUR_DIS);
> + reg |= MX6_BM_OVER_CUR_POLARITY;
> + else {
> reg &= ~(MX6_BM_OVER_CUR_DIS | MX6_BM_OVER_CUR_POLARITY);
You break machines here that use active low signaling but don't use the
new property (yet).
Also it's not nice to
of an explicit configuration the
bit is kept as is. On i.MX7 over current detection is used unless
disabled in the device tree.
Signed-off-by: Uwe Kleine-König
---
.../devicetree/bindings/usb/ci-hdrc-usb2.txt | 5 ++--
drivers/usb/chipidea/ci_hdrc_imx.c| 9 --
drivers/usb/chipide
The polarity of the over current detection pin isn't configured on i.MX6/7
if it's unspecified in the device tree. So the actual configuration depends
on bootloader behavior which is bad.
So encourage users to fix their device tree by issuing a warning in this
case.
Signed-off-by:
.
Signed-off-by: Uwe Kleine-König
---
drivers/usb/chipidea/usbmisc_imx.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 4a8de1b37f67..47eee5cade84 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b
ly;
> otherwise, we set it as low explicitly.
>
> Cc: stable
> Cc: Peter Chen
> Cc: Uwe Kleine-König
> Cc: Matthew Starr
> Signed-off-by: Peter Chen
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
> drivers/usb/chipidea/ci_hdrc_imx.h | 3 ++-
> drivers/usb/c
gt; "over-current-active-high" property unchanging to reduce users effort.
> > > If this property is set, we set OC polarity as high explicitly;
> > > otherwise, we set it as low explicitly.
> > >
> > > Cc: stable
> > > Cc: Peter Chen
On Mon, Dec 03, 2018 at 04:10:37PM +, Matthew Starr wrote:
> > -Original Message-
> > From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de]
> > Sent: Sunday, December 02, 2018 3:33 PM
> >
> > The status quo on i.MX6 is that if "over-curre
larity property only "disable-over-current" is not found at patch 1.
Right, just fixed that up and will send out v3 in a moment.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello,
compared to v2 (which starts with Message-Id:
<20181202213325.26017-1-u.kleine-koe...@pengutronix.de>) I adapted patch
1 that the oc polarity is only determined if oc isn't disabled. This
results in the warning that is introduced in patch 2 not to be emitted
in this case.
Best regards
Uwe
The polarity of the over current detection pin isn't configured on i.MX6/7
if it's unspecified in the device tree. So the actual configuration depends
on bootloader behavior which is bad.
So encourage users to fix their device tree by issuing a warning in this
case.
Signed-off-by:
.
Signed-off-by: Uwe Kleine-König
---
drivers/usb/chipidea/usbmisc_imx.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 4a8de1b37f67..47eee5cade84 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b
of an explicit configuration the
bit is kept as is. On i.MX7 over current detection is used unless
disabled in the device tree.
Signed-off-by: Uwe Kleine-König
---
.../devicetree/bindings/usb/ci-hdrc-usb2.txt | 5 ++--
drivers/usb/chipidea/ci_hdrc_imx.c| 16 ---
drive
Hello Stefan,
On Tue, Dec 04, 2018 at 09:40:26AM +0100, Stefan Wahren wrote:
> Am 04.12.18 um 09:31 schrieb Uwe Kleine-König:
> > The status quo on i.MX6 is that if "over-current-active-high" is
> > specified in the device tree this is configured as expected. If
&g
Hello,
On Tue, Dec 04, 2018 at 12:43:21PM +0100, Stefan Wahren wrote:
> Am 04.12.18 um 09:52 schrieb Uwe Kleine-König:
> > But for the review you are right, I added the dt people to Cc for them
> > to comment. In v2 Matthew also noted that he would prefer to handle the
> >
: usbphy:usb-phy@1 supply vcc not
found, using dummy regulator
Signed-off-by: Uwe Kleine-König
---
Hello,
note I'm an USB noob, so please consider carefully before applying :-)
I also put the regulator near the usbphy node instead of in alphabetic
order. Not sure what is sensible/usual here
+ nop->vcc = devm_regulator_get_optional(dev, "vcc");
> >
> > Is the regulator optional? IMHO this shouldn't be the fix. I think the
> > right fix is Uwe's
> > approach.
> >
>
> Add Felipe.
>
> Some USB PHY's powe
Signed-off-by: Uwe Kleine-König
---
drivers/usb/misc/usb251xb.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 5f7734c729b1..e2d36da52663 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -25,10
On Mon, Aug 19, 2019 at 12:41:04PM +0200, Greg KH wrote:
> On Mon, Aug 19, 2019 at 12:02:11PM +0200, Uwe Kleine-König wrote:
> > Signed-off-by: Uwe Kleine-König
> > ---
> > drivers/usb/misc/usb251xb.c | 5 -
> > 1 file changed, 5 deletions(-)
>
> I can
On Wed, Jul 24, 2019 at 03:09:39PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Jun 27, 2019 at 03:15:10AM +, Peter Chen wrote:
> >
> > > On 19-06-26 02:40, Peter Chen wrote:
> > > >
> > > > > Subject: [PATCH] ARM: imx25: provide a f
debug session that led to
39cee200c23e, and I don't have access to the hardware in question any
more.
But your commit logs makes sense, so
Acked-by: Uwe Kleine-König
Given that it took 2+ years to find this, backporting to stable and a
Fixes: line are probably not neces
The five removed symbols are unused since they were introduced in commit
3ec72a2a1e5d ("usb: misc: add USB251xB/xBi Hi-Speed Hub Controller
Driver") back in 2017.
Signed-off-by: Uwe Kleine-König
---
drivers/usb/misc/usb251xb.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/d
The USB2422 uses a different package that the USB251x and only comes in
a variant with 2 downstream ports. Other than that it is software
compatible.
Tested-by: Carsten Stelling
Signed-off-by: Uwe Kleine-König
---
drivers/usb/misc/usb251xb.c | 12
1 file changed, 12 insertions
The next patch introduces support for the USB2422. Add it to the list of
devices supported by the binding.
Signed-off-by: Uwe Kleine-König
---
Documentation/devicetree/bindings/usb/usb251xb.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings
83 matches
Mail list logo
