On Thu, Aug 21, 2014 at 11:45:01AM -0700, Guenter Roeck wrote:
> On Wed, Aug 13, 2014 at 10:40:37AM +0200, Andreas Werner wrote:
> > Added driver to support the 14F021P00 BMC Hardware Monitoring.
> > The BMC is a Board Management Controller including monitoring of the
>
On Thu, Aug 21, 2014 at 11:37:52AM -0700, Guenter Roeck wrote:
> On Wed, Aug 13, 2014 at 10:40:37AM +0200, Andreas Werner wrote:
> > Added driver to support the 14F021P00 BMC Hardware Monitoring.
> > The BMC is a Board Management Controller including monitoring of the
>
On Thu, Aug 21, 2014 at 12:30:46PM +0100, Lee Jones wrote:
> On Wed, 13 Aug 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 Microntrol
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig | 7 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/menf21bmc_wdt.c | 203
Added driver to support the 14F021P00 BMC Hardware Monitoring.
The BMC is a Board Management Controller including monitoring of the
board voltages.
Signed-off-by: Andreas Werner
---
drivers/hwmon/Kconfig | 7 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controller including four LEDs which
can be switched on and off.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-menf21bmc.c | 131
communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
- Hwmon (voltage monitoring)
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 132
2:
- changed i2c_smbus_read wrapper function to return both, value
and error.
- 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.
And
On Fri, Aug 08, 2014 at 04:36:55PM +0200, Wim Van Sebroeck wrote:
> > On 08/08/2014 12:49 AM, Andreas Werner wrote:
> > >On Wed, Jul 30, 2014 at 06:57:46AM -0700, Guenter Roeck wrote:
> > >>On 07/30/2014 01:08 AM, Andreas Werner wrote:
> > >>>On Tue, Jul 2
On Wed, Jul 30, 2014 at 06:57:46AM -0700, Guenter Roeck wrote:
> On 07/30/2014 01:08 AM, Andreas Werner wrote:
> >On Tue, Jul 29, 2014 at 02:47:08PM -0700, Guenter Roeck wrote:
> >>On 07/29/2014 02:12 PM, Wim Van Sebroeck wrote:
> >>>Hi Andreas,
> >>>
Hi Joseph,
> Julius, I was hoping to get your feedback, since you are the patch
> author. Do you think gathering any additional data will help diagnose
> this issue, or would it be best to continue with this revert request?
As I understand it, this crash will disappear with Mathias' new rework
f
On Tue, Jul 29, 2014 at 02:47:08PM -0700, Guenter Roeck wrote:
> On 07/29/2014 02:12 PM, Wim Van Sebroeck wrote:
> >Hi Andreas,
> >
> >>aOn Thu, Jul 24, 2014 at 03:00:09PM -0700, Bryan Wu wrote:
> >>>On Thu, Jul 17, 2014 at 6:18 AM, Andreas Werner
> >
aOn Thu, Jul 24, 2014 at 03:00:09PM -0700, Bryan Wu wrote:
> On Thu, Jul 17, 2014 at 6:18 AM, Andreas Werner wrote:
> > 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.
> &
On Wed, Jun 25, 2014 at 04:10:55PM -0700, Bryan Wu wrote:
> On Tue, May 27, 2014 at 2:08 AM, Andreas Werner wrote:
> > 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.
> >
> 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
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 Microntrol
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 | 136
3
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
> 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, facilitat
> 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
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 xhci'
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, facilitate
ernels as 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(
> +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
> +
n can 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
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,
>>>
> 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
.
(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 Document
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
oelektronik
> > 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
> 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 c
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
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. (I
following features:
> > > > - Watchdog
> > > > - LEDs
> > > >
> > > > Signed-off-by: Andreas Werner
> > > > ---
> > > > drivers/mfd/Kconfig | 12 +++
> > > > drivers/mfd/Makefile
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
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 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 Micro
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
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
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 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 featur
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 han
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/
sting 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 W
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 majord...@vger.kernel.o
*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
+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 xhci_find_new_dequ
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 anyw
> http://marc.info/?l=linux-usb&m=137158978503741&w=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 contex
ld 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 in
blems 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
> 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 m
ned-off-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
blems 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/driver
tain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 66
drivers/usb/host/xhci.c | 1 -
drivers/usb/host/xhci.h | 2 --
3 files changed, 30 insertions(
-ds1307 does.
Tested on AMD G Series Platform (i2c-piix4 adapter driver).
Signed-off-by: Andreas Werner
---
drivers/rtc/rtc-rx8581.c | 81
1 file changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/rtc-rx8581.c b/drivers/rtc/rtc-rx8581
>> ...although, the spec says that it does not wait for the port resets
>> to complete. As far as I can see re-issuing a warm reset and waiting
>> is the only way to guarantee the core times the recovery. Presumably
>> the portstatus debounce in hub_activate() mitigates this, but that
>> 100ms is
> Sorry for not getting back to this sooner. Ironically, it looks like
> this change isn't needed any more, thanks to Thomas Pugliese's patch:
>
> http://marc.info/?l=linux-usb&m=13866180520&w=2
Yes... thanks for pointing it out, that would make this patch
obsolete. I'll wait a few da
> I don't know what you mean by "fails". The system goes to sleep and
> then later on wakes up, doesn't it?
>
> Do you mean that the Jetflash device gets disconnected when the system
> wakes up? That's _supposed_ to happen under those circumstances.
> When hub_activate() sees HUB_RESET_RESUME, al
On Tue, Dec 10, 2013 at 2:55 AM, Vivek Gautam wrote:
> The DWC3-exynos eXtensible host controller on Exynos5420 SoC
> is quirky in a way that the PHY needs to be tuned to get it
> working at SuperSpeed.
> By default this PHY works as High-speed phy and therefore
> detects even Super-speed devices
B device can always be marked as
unconfigured (reclaiming its bandwidth) in the kernel, regardless of
communication problems. This patch changes usb_set_configuration() to
ignore all failures in the case where no new configuration is being set.
Signed-off-by: Julius Werner
---
drivers/usb/core/m
> Instead, how about changing usb_set_configuration() so that it will
> never fail when the new config is -1? Except perhaps for -ENODEV
> errors (the device has been disconnected), which
> usb_deauthorize_device() could check for.
Yes, that should work as well. It's really just one autoresume an
res that usb_deauthorize_device() aborts when
usb_set_configuration() fails, and the underlying status code (such as
ENODEV) is returned to userspace.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b
*ping*
Is anyone still reading this or should I resubmit? Sorry for being
annoying, just please let me know if this is already considered to get
picked up at the next opportunity or if you've intentionally decided
against it for now. I want to make sure it didn't fall through the
cracks somewhere.
I'm not sure if it's worth it further looking into this for the
SUSPENDED state (Sarah's post sounds like that shouldn't happen)...
but at any rate, that would be orthogonal to my patch, right? I'm
really only interested in the NOTATTACHED case, which solves a real
issue on my system. Do you still
function and add the
read to pch_i2c_wait_for_check_xfer.
If no ACK is received, the Message will be printed as a dbg
message.
Fixed print message to be a one liner so we can grep for the
error message.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner
---
Revision 2
On Sun, Nov 17, 2013 at 06:08:38PM +0100, Wolfram Sang wrote:
> On Sun, Nov 17, 2013 at 05:53:29PM +0100, Andreas Werner wrote:
> > On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
> > >
> > > > Is there another reason why pch_i2c_getack returned EP
On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
>
> > Is there another reason why pch_i2c_getack returned EPROTO?
> > May be ENXIO was introduced later?
>
> Imperfect review :)
>
> > I think we can just replace the -EIO with -ENXIO or do you want to pick up
> > the return
> > vale
On Sun, Nov 17, 2013 at 12:08:46PM +0100, Wolfram Sang wrote:
> On Sun, Nov 17, 2013 at 09:58:51AM +0100, Andreas Werner wrote:
> > Revision 2:
> > - delete the pch_err completly instead of changing to pch_dbg
> > because there is already a pch_dbg at t
On Thu, Nov 14, 2013 at 08:57:58PM +, One Thousand Gnomes wrote:
> > but if you checkout the PCI table in the driver, there is the device
> > and vendor ID mentioned, that means for me that the driver supports
> > the Graphic core in E680.
> > And after loading the driver, it will parse for $VB
On Thu, Nov 14, 2013 at 05:39:52AM -0800, Joe Perches wrote:
> On Wed, 2013-11-13 at 20:24 +0100, Marek Vasut wrote:
> > > On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
> > > > > > That is because if you look at the only caller of this function,
> > > > > > which is pch_i2c_wait_for_
On Thu, Nov 14, 2013 at 01:52:09PM +, One Thousand Gnomes wrote:
> > My question now is, is it a bug in the driver or in the VGA Bios?
> >
> > I´ve checked the VGA bios and did a hex dump but there is really no "$VBT"
> > string.
> > On an Atom Gen1 CPU with intel GMA500 Graphic there is the
I´ve a question about the GMA 500 driver (gma500_gfx) with an Intel Atom E680.
Since the gma500 driver is in the Kernel, i get a black screen after loading
the driver.
The last message i can see are "Invalid VBT signature".
I have check the driver file "intel_bios.c" and there the driver map
the
On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
> Dear Andreas Werner,
>
> > On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
> > > Dear Andreas Werner,
> > >
> > > > Using the i2c-eg20t driver and call i2cdetect or probe on th
On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
> Dear Andreas Werner,
>
> > Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
> > the driver will print a lot of error messages if there was no ACK
> > received.
> >
> > i2cdetect
-eg20t driver, the table is not visible because
the error messages destroy the table.
Error message: pch_i2c_getack return -71
This patch prevent the driver to print the messages to syslog if debug is not
set.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner
---
drivers
port broken.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e6b682c..0188056 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4799,8 +4799,9
> I don't know either. But Sarah has said that ports can spontaneously
> go into Compliance Mode for no apparent reason. If that can happen,
> maybe it can happen while the port is in U3 and the device is
> suspended. In such cases, though, you'd need to do a reset-resume
> rather than a simple
> Who makes those calls, drivers? Any specific ones that you know need to
be fixed?
Well, the one I'm worried about is the one this patch is fixing, in
hub_events(). I have seen this happen when having certain USB3 devices
plugged into a host controller that always looses power on
suspend-to-ram
*bump*
Hi Sarah, is there anything else that needs to be resolved to pick
this patch up? Looks like Matthias' recent LPM fixes are all in now so
there should be no way this could cause any trouble?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
port broken.
Also bumped the messages about this kind of reset failure from dev_dbg()
to dev_warn() to make it easier to notice, since calling that function
with a NOTATTACHED device would almost always be a bug
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 9 +
1 file changed
On Sun, Nov 03, 2013 at 09:44:46AM -0800, H. Peter Anvin wrote:
> On 11/03/2013 04:02 AM, Andreas Werner wrote:
> >
> > Since marking IO Memory as cachable is not valid, WT is the
> > best way for caching/bursting on MMIO Devices.
> >
>
> Uh... WT *is* cachabl
following combination:
PAT=Write-Back + MTRR=Write-Through.
Since marking IO Memory as cachable is not valid, WT is the
best way for caching/bursting on MMIO Devices.
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner
---
arch/x86/mm/
On Mon, Oct 28, 2013 at 02:58:47PM +0100, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 01:03:58PM +0100, Andreas Werner wrote:
> > > That doesn't mean you can return _PAGE_CACHE_WB for MTRR_TYPE_WRTHROUGH.
> > > The correct thing to do, IMHO, would be to set the PW
On Mon, Oct 28, 2013 at 12:45:41PM +0100, Borislav Petkov wrote:
> Drop Dave's stale mail address.
>
> On Mon, Oct 28, 2013 at 12:25:05PM +0100, Andreas Werner wrote:
> > > but you end up doing
> > >
> > > PAT=Write-Back + MTRR=Write-Through = Effect
On Mon, Oct 28, 2013 at 11:57:31AM +0100, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 11:34:28AM +0100, Andreas Werner wrote:
> > Yes the reads are only for packet data, the commands or configuration
> > registers are mapped non cachable.
> >
> > I´ve tried WB, but
On Mon, Oct 28, 2013 at 11:51:01AM +0100, Ingo Molnar wrote:
>
> * Andreas Werner wrote:
>
> > On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote:
> > >
> > > * Borislav Petkov wrote:
> > >
> > > > On Mon, Oct 28, 2013 at 11:1
On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote:
> >
> > > And regular write-back cacheable isn't sufficient because the
> > > CPU could do things like prefetch your range automatically?
201 - 300 of 526 matches
Mail list logo
