Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig | 7 ++
drivers
mfd core.
- fixed some return values in the watchdog driver to return the original
error value instead of -EIO.
Andreas Werner (3):
drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog
driver
values in the watchdog driver to return the original
error value instead of -EIO.
Andreas Werner (3):
drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog
driver
drivers/leds/leds-menf21bmc
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/watchdog/Kconfig
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/leds
communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 136
On Thu, Jul 17, 2014 at 01:41:56PM +0100, Lee Jones wrote:
On Thu, 17 Jul 2014, Andreas Werner wrote:
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from
Hmm. Wouldn't it be safer to have a quirk for this, and only enable
the workaround if the Asmedia controller is detected? This code is so
complicated that it is difficult to see whether this could have a
harmful effect on controllers without the bug.
Sorry for making it complicated, but it
> Nope - since CONFIG_USB_XHCI_MVEBU can be 'y' or 'm' we need the ifneq
> here (which matches against both) to ensure xhci-mvebu.o is built is
> part of xhci-plat-hcd.o.
Oh... does it make sense to have it tristate at all, then? Looks like
was never really buildable as an independent module (and
On Mon, Jul 14, 2014 at 5:49 AM, Vivek Gautam wrote:
> The host controller by itself may sometimes need to handle PHY
> and/or calibrate some of the PHY settings to get full support out
> of the PHY controller. The PHY core provides a calibration
> funtionality now to do so.
> Therefore,
On Mon, Jul 14, 2014 at 5:49 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Nope - since CONFIG_USB_XHCI_MVEBU can be 'y' or 'm' we need the ifneq
here (which matches against both) to ensure xhci-mvebu.o is built is
part of xhci-plat-hcd.o.
Oh... does it make sense to have it tristate at all, then? Looks like
was never really buildable as an independent module (and
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index af89a90..bafba71 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -15,19 +15,19 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
> xhci-hcd-y := xhci.o xhci-mem.o
> xhci-hcd-y += xhci-ring.o
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index af89a90..bafba71 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -15,19 +15,19 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
xhci-hcd-y := xhci.o xhci-mem.o
xhci-hcd-y += xhci-ring.o xhci-hub.o
On Wed, Jul 9, 2014 at 3:01 AM, Vivek Gautam wrote:
> Some quirky PHYs may require to be calibrated post the host
> controller initialization.
> The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along with
> Synopsys's DWC3 controller, is one such PHY which needs to be
> calibrated post
On Wed, Jul 9, 2014 at 3:01 AM, Vivek Gautam wrote:
> The host controller by itself may sometimes need to handle PHY
> and/or calibrate some of the PHY settings to get full support out
> of the PHY controller. The PHY core provides a calibration
> funtionality now to do so.
> Therefore,
On Wed, Jul 9, 2014 at 3:01 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
On Wed, Jul 9, 2014 at 3:01 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
Some quirky PHYs may require to be calibrated post the host
controller initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along with
Synopsys's DWC3 controller, is one such PHY which needs to be
old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."
Cc: sta...@vger.kernel.org
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git
the commit ae636747146ea97efa18e04576acd3416e2514f5 USB: xhci: URB
cancellation support.
Cc: sta...@vger.kernel.org
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-ring.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/usb
> +static const struct hc_driver tegra_xhci_hc_driver = {
> + .description = "tegra-xhci-hcd",
> + .product_desc = "Tegra xHCI Host Controller",
> + .hcd_priv_size =sizeof(struct xhci_hcd *),
> +
> + /*
> +* generic hardware linkage
> +
+static const struct hc_driver tegra_xhci_hc_driver = {
+ .description = tegra-xhci-hcd,
+ .product_desc = Tegra xHCI Host Controller,
+ .hcd_priv_size =sizeof(struct xhci_hcd *),
+
+ /*
+* generic hardware linkage
+*/
+
be seen at http://crosreview.com/203371,
which will be submitted at a later point.)
Change-Id: I97609d461d306f85851e5efc26c675ca1e2d7e9d
Signed-off-by: Julius Werner
---
.../devicetree/bindings/firmware/coreboot.txt | 32 ++
1 file changed, 32 insertions(+)
create mode
On Mon, Jun 16, 2014 at 6:30 AM, Rob Herring wrote:
> On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner wrote:
>>> This is just to export a fixed log to userspace (like a DMI table) or
>>> the kernel will actually use the data in some way? Based on the link,
>>>
On Mon, Jun 16, 2014 at 6:30 AM, Rob Herring robherri...@gmail.com wrote:
On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner jwer...@chromium.org wrote:
This is just to export a fixed log to userspace (like a DMI table) or
the kernel will actually use the data in some way? Based on the link
be seen at http://crosreview.com/203371,
which will be submitted at a later point.)
Change-Id: I97609d461d306f85851e5efc26c675ca1e2d7e9d
Signed-off-by: Julius Werner jwer...@chromium.org
---
.../devicetree/bindings/firmware/coreboot.txt | 32 ++
1 file changed, 32
> This is just to export a fixed log to userspace (like a DMI table) or
> the kernel will actually use the data in some way? Based on the link,
> it looks like the former to me.
I could imagine both. The link is an in-kernel driver that exposes a
log through a sysfs node (in a way that has
).
(An example implementation can be seen at http://crosreview.com/203371,
which will be submitted at a later point.)
Signed-off-by: Julius Werner
---
.../devicetree/bindings/firmware/coreboot.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation
).
(An example implementation can be seen at http://crosreview.com/203371,
which will be submitted at a later point.)
Signed-off-by: Julius Werner jwer...@chromium.org
---
.../devicetree/bindings/firmware/coreboot.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644
This is just to export a fixed log to userspace (like a DMI table) or
the kernel will actually use the data in some way? Based on the link,
it looks like the former to me.
I could imagine both. The link is an in-kernel driver that exposes a
log through a sysfs node (in a way that has already
Wir wünschen Ihnen einen schönen guten Tag,
ich habe eine gute Nachricht für Sie.
Süd-amerikanische Banken drängen ins deutsche Kreditgeschäft, bspw. mit solchen
Konditionen: Weniger als 3 Prozent Zinsen für Firmen und unter 3,5 Prozent für
PrivatKredite.
Auch bei laufenden Verpflichtungen und
Wir wünschen Ihnen einen schönen guten Tag,
ich habe eine gute Nachricht für Sie.
Süd-amerikanische Banken drängen ins deutsche Kreditgeschäft, bspw. mit solchen
Konditionen: Weniger als 3 Prozent Zinsen für Firmen und unter 3,5 Prozent für
PrivatKredite.
Auch bei laufenden Verpflichtungen und
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 9ffecd5..453d89e 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
> u32 port_status_u0;
> /* Compliance Mode Timer Triggered every 2
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
u32 port_status_u0;
/* Compliance Mode Timer Triggered every 2
gt; > Mikroelektronik
> > and on a few Box/Display Computer.
> >
> > Added MFD Core driver, supporting the I2C communication to the device.
> >
> > The MFD driver currently supports the following features:
> > - Watchdog
> > - LEDs
> >
> > S
/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/mfd/Kconfig | 12
> Ok, there was already a patch posted by you for this[1], which had
> quite a much discussion
> on it.
> Would you like to give some pointers based on that ?
> One that Olof had suggested was to use gpio-reset driver which is yet
> to make to mainline.
> But i think with that too we need to take
On Wed, May 28, 2014 at 06:52:56AM -0700, Guenter Roeck wrote:
> On 05/28/2014 06:29 AM, Guenter Roeck wrote:
> >On 05/28/2014 04:51 AM, Andreas Werner wrote:
> >>aOn Wed, May 28, 2014 at 09:24:05AM +0100, Lee Jones wrote:
> >>>>>>The MEN 14F021P
On Wed, May 28, 2014 at 06:52:56AM -0700, Guenter Roeck wrote:
On 05/28/2014 06:29 AM, Guenter Roeck wrote:
On 05/28/2014 04:51 AM, Andreas Werner wrote:
aOn Wed, May 28, 2014 at 09:24:05AM +0100, Lee Jones wrote:
The MEN 14F021P00 Board Management Controller provides an
I2C interface
Ok, there was already a patch posted by you for this[1], which had
quite a much discussion
on it.
Would you like to give some pointers based on that ?
One that Olof had suggested was to use gpio-reset driver which is yet
to make to mainline.
But i think with that too we need to take care of
We originally tried using this driver on ChromiumOS and never got it
to work reliably. IIRC the issue was that if the hub had already been
initialized by firmware, the USB stack might enumerate it before the
usb3503 driver is probed and then the later reset will silently
disrupt that connection.
following features:
> > > > - Watchdog
> > > > - LEDs
> > > >
> > > > Signed-off-by: Andreas Werner
> > > > ---
> > > > drivers/mfd/Kconfig | 12 +++
> > > > drivers/mfd/Makefile
We originally tried using this driver on ChromiumOS and never got it
to work reliably. IIRC the issue was that if the hub had already been
initialized by firmware, the USB stack might enumerate it before the
usb3503 driver is probed and then the later reset will silently
disrupt that connection.
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/mfd
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig| 7 ++
drivers
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6
communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/menf21bmc.c | 220
.
- moved "leave production mode" from Watchdog driver to mfd core.
- fixed some return values in the watchdog driver to return the original
error value instead of -EIO.
Andreas Werner (3):
drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
driver
.
- moved leave production mode from Watchdog driver to mfd core.
- fixed some return values in the watchdog driver to return the original
error value instead of -EIO.
Andreas Werner (3):
drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
drivers/watchdog
communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/menf21bmc.c | 220
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/leds
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/watchdog/Kconfig
aOn Mon, May 19, 2014 at 06:39:53PM +0100, Lee Jones wrote:
> On Mon, 19 May 2014, Guenter Roeck wrote:
>
> > On 05/19/2014 05:43 AM, Andreas Werner wrote:
> > >aOn Sat, May 17, 2014 at 08:47:42AM -0700, Guenter Roeck wrote:
> > >>On 05/16/2014 09:37 AM, And
aOn Mon, May 19, 2014 at 06:39:53PM +0100, Lee Jones wrote:
On Mon, 19 May 2014, Guenter Roeck wrote:
On 05/19/2014 05:43 AM, Andreas Werner wrote:
aOn Sat, May 17, 2014 at 08:47:42AM -0700, Guenter Roeck wrote:
On 05/16/2014 09:37 AM, Andreas Werner wrote:
The MEN 14F021P00 Board
aOn Sat, May 17, 2014 at 08:47:42AM -0700, Guenter Roeck wrote:
> On 05/16/2014 09:37 AM, Andreas Werner wrote:
> >The MEN 14F021P00 Board Management Controller provides an
> >I2C interface to the host to access the feature implemented in the BMC.
> >The BMC is a PIC Mi
aOn Sat, May 17, 2014 at 08:57:27AM -0700, Guenter Roeck wrote:
> On 05/16/2014 09:37 AM, Andreas Werner wrote:
> >Added driver to support the 14F021P00 BMC Watchdog.
> >The BMC is a Board Management Controller including watchdog functionality.
> >
> >This driver use t
aOn Sat, May 17, 2014 at 08:57:27AM -0700, Guenter Roeck wrote:
On 05/16/2014 09:37 AM, Andreas Werner wrote:
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using
aOn Sat, May 17, 2014 at 08:47:42AM -0700, Guenter Roeck wrote:
On 05/16/2014 09:37 AM, Andreas Werner wrote:
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig| 7 ++
drivers
communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/menf21bmc.c | 193
features which can be accessed using an I2C Host
interface.
Features supported in this Patchset:
- Watchdog
- LEDs
The Patchset includes a MFD Core driver, Watchdog and LEDs driver.
Andreas Werner (3):
drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
drivers
features which can be accessed using an I2C Host
interface.
Features supported in this Patchset:
- Watchdog
- LEDs
The Patchset includes a MFD Core driver, Watchdog and LEDs driver.
Andreas Werner (3):
drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
drivers
communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/menf21bmc.c | 193
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/leds
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/watchdog/Kconfig
On Sat, May 10, 2014 at 08:32:40AM -0700, Guenter Roeck wrote:
> On 05/10/2014 09:02 AM, Andreas Werner wrote:
> >On Sat, May 10, 2014 at 05:32:13AM -0700, Guenter Roeck wrote:
> >>On 05/10/2014 06:22 AM, Andreas Werner wrote:
> >>>Hi,
> >>>i am current
On Sat, May 10, 2014 at 08:32:40AM -0700, Guenter Roeck wrote:
On 05/10/2014 09:02 AM, Andreas Werner wrote:
On Sat, May 10, 2014 at 05:32:13AM -0700, Guenter Roeck wrote:
On 05/10/2014 06:22 AM, Andreas Werner wrote:
Hi,
i am currently working on an implemenation of my Board Management
On Sat, May 10, 2014 at 05:32:13AM -0700, Guenter Roeck wrote:
> On 05/10/2014 06:22 AM, Andreas Werner wrote:
> >Hi,
> >i am currently working on an implemenation of my Board Management Controller
> >(BMC).
> >
> >This Controller is a MCR assembled on almost all
Hi,
i am currently working on an implemenation of my Board Management Controller
(BMC).
This Controller is a MCR assembled on almost all of our Compact PCI or Compact
PCI Serial
Cards as well as on some other CPU Boards.
The BMC includes LED´s, Watchdog, Voltage Monitoring and some other
Hi,
i am currently working on an implemenation of my Board Management Controller
(BMC).
This Controller is a MCR assembled on almost all of our Compact PCI or Compact
PCI Serial
Cards as well as on some other CPU Boards.
The BMC includes LED´s, Watchdog, Voltage Monitoring and some other
On Sat, May 10, 2014 at 05:32:13AM -0700, Guenter Roeck wrote:
On 05/10/2014 06:22 AM, Andreas Werner wrote:
Hi,
i am currently working on an implemenation of my Board Management Controller
(BMC).
This Controller is a MCR assembled on almost all of our Compact PCI or
Compact PCI Serial
Hmmm... very odd. I unfortunately don't have a machine that can easily
do S4 at hand, but I did test this on an IVB with XHCI_RESET_ON_RESUME
in S3 (essentially the same code path), and I didn't run into any
problems.
How exactly does your machine fail on resume? Is it a kernel crash or
just a
Hmmm... very odd. I unfortunately don't have a machine that can easily
do S4 at hand, but I did test this on an IVB with XHCI_RESET_ON_RESUME
in S3 (essentially the same code path), and I didn't run into any
problems.
How exactly does your machine fail on resume? Is it a kernel crash or
just a
Reviewed-by: Andreas Werner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reviewed-by: Andreas Werner andreas.wer...@men.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().
Signed-off-by: Julius Werner
Okay, thanks, sounds good. I personally don't care that much about the
stable backport. Let me respin this with a fixed commit message and
the type change Felipe suggested.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Okay, thanks, sounds good. I personally don't care that much about the
stable backport. Let me respin this with a fixed commit message and
the type change Felipe suggested.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().
Signed-off-by: Julius Werner
*bump*
Sarah, Mathias, can we decide how to proceed with this? I think the
section Alan quoted is a pretty good argument in favor of my
interpretation (although of course this would not be the first time
that two sections of a spec contradict each other). But more
importantly, we have a case that
*bump*
Sarah, Mathias, can we decide how to proceed with this? I think the
section Alan quoted is a pretty good argument in favor of my
interpretation (although of course this would not be the first time
that two sections of a spec contradict each other). But more
importantly, we have a case that
> You don't actually add the stable@ tag here, why not?
>
> You have read Documentation/stable_kernel_rules.txt for how stable
> kernel trees work, so why not add the label here?
Sorry... I actually didn't know about that file, I just added the
"should be backported" line because I have seen that
You don't actually add the stable@ tag here, why not?
You have read Documentation/stable_kernel_rules.txt for how stable
kernel trees work, so why not add the label here?
Sorry... I actually didn't know about that file, I just added the
should be backported line because I have seen that in
+hdegoede
> I tried to apply this patch on top of 3.15-rc1, but it fails because of the
> streams support added to xhci_find_new_dequeue_state()
>
> After some manual editing the interesting parts of
> xhci_find_new_dequeue_state() looks like this:
>
> @@ -577,46 +568,57 @@ void
+hdegoede
I tried to apply this patch on top of 3.15-rc1, but it fails because of the
streams support added to xhci_find_new_dequeue_state()
After some manual editing the interesting parts of
xhci_find_new_dequeue_state() looks like this:
@@ -577,46 +568,57 @@ void
Hi Mathias,
> The patch looks fine. Mathias is taking over for xHCI driver
> maintainership in 3.15. He's currently handling queuing bug fix patches
> for 3.14 while I finish queueing feature patches for 3.15. Mathias,
> will you test and queue this up for 3.14?
Did you pick this patch up
Hi Mathias,
The patch looks fine. Mathias is taking over for xHCI driver
maintainership in 3.15. He's currently handling queuing bug fix patches
for 3.14 while I finish queueing feature patches for 3.15. Mathias,
will you test and queue this up for 3.14?
Did you pick this patch up
> http://marc.info/?l=linux-usb=137158978503741=2
>
> There's an xHCI spec ambiguity: Does the last valid context entry refer
> to the last valid endpoint context in the *input* device context or the
> *output* device context?
>
> The code currently assumes it refers to the input device context,
http://marc.info/?l=linux-usbm=137158978503741w=2
There's an xHCI spec ambiguity: Does the last valid context entry refer
to the last valid endpoint context in the *input* device context or the
*output* device context?
The code currently assumes it refers to the input device context,
be backported to kernels as old as 2.6.31 that contain
the commit f94e0186312b0fc39f41eed4e21836ed74b7efe1 "USB: xhci:
Bandwidth allocation support".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci.c | 51 +
1 file changed, 18 inserti
be backported to kernels as old as 2.6.31 that contain
the commit f94e0186312b0fc39f41eed4e21836ed74b7efe1 USB: xhci:
Bandwidth allocation support.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci.c | 51 +
1 file changed, 18
with these webcams.
Signed-off-by: Julius Werner
---
drivers/usb/core/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 8d72f0c..062967c 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -717,6 +717,10
> What am I supposed to do with this line? :)
>
Oh damn, sorry, forgot to take that out on the second one. We have
this really annoying commit hook that adds them automatically. v2
incoming...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
-by: Julius Werner
---
drivers/usb/core/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 8f37063..739ee8e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -47,6 +47,10 @@ static const struct usb_device_id
with these webcams.
Change-Id: Ibf738426307fe8ef362768db2decc9bc2b30a930
Signed-off-by: Julius Werner
---
drivers/usb/core/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 8d72f0c..062967c 100644
--- a/drivers/usb/core
with these webcams.
Change-Id: Ibf738426307fe8ef362768db2decc9bc2b30a930
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 8d72f0c..062967c 100644
-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 8f37063..739ee8e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -47,6 +47,10 @@ static const
What am I supposed to do with this line? :)
Oh damn, sorry, forgot to take that out on the second one. We have
this really annoying commit hook that adds them automatically. v2
incoming...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
with these webcams.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 8d72f0c..062967c 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
401 - 500 of 1003 matches
Mail list logo
